From serb at openjdk.org  Sat Feb  1 00:29:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 1 Feb 2025 00:29:53 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v9]
In-Reply-To: <JxV-k99mwSBRNyEbWzyeXi_QoA9IZpG7ScKFVGQgrDs=.442fa174-758a-41bc-bde0-1761cda8a303@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <w59klf7rxjl0-6-NhwvKZmCqvS8cJ2VZKINLJ1L1w1E=.40e88333-28b4-4c07-b4d4-ce08b47f5db5@github.com>
 <RPqTDjE6NOvoQ5us_FQX4Mtqr9YfVAh0uoPU-4oU6f4=.5154adec-7a08-42da-a92f-d58f05f7eb02@github.com>
 <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
 <JxV-k99mwSBRNyEbWzyeXi_QoA9IZpG7ScKFVGQgrDs=.442fa174-758a-41bc-bde0-1761cda8a303@github.com>
Message-ID: <VoWBQ9jqCCELNlha537T3QK7hHwK2_94CtxZaRIg0E8=.cddffc7b-e6ef-41a2-8f1d-0c020fb5767d@github.com>

On Fri, 31 Jan 2025 21:11:10 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>When Rendering Intent validation is skipped, it means that along with non-icc intents other random invalid values are also allowed while updating the profile.. Is it okay to allow invalid Rendering Intents that successfully updated the profile only to cause exception later by LCMS (as below during color transform)?

I think there is an API to check if an intent is supported or not: `cmsIsIntentSupported` we can try to reuse it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2628614903

From abhiscxk at openjdk.org  Mon Feb  3 06:40:53 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Feb 2025 06:40:53 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
Message-ID: <jOWQeiLTF4ZLAn4tcFOaW_-PwBgjzaJcSgg16sh3-co=.b8839459-8c9e-4606-bf0e-93221e716d15@github.com>

On Fri, 31 Jan 2025 20:40:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows.
>> 
>> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely.
>> 
>> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails.
>> 
>> The updated test passes in the CI.
>
> Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update the test summary
>  - Remove the redundant button

test/jdk/javax/swing/JButton/4796987/bug4796987.java line 30:

> 28:  * @requires (os.family == "windows")
> 29:  * @summary Verify JButton.setBorderPainted(false) removes border
> 30:  *      for Windows visual styles (Windows XP and later)

Is it necessary to mention about Windows XP ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1938850102

From abhiscxk at openjdk.org  Mon Feb  3 07:10:47 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Feb 2025 07:10:47 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac
In-Reply-To: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
Message-ID: <WYz8DxD1VNh2ChF7DIj4QEFAFO81ftiN1hibJ4RUbF0=.0557b7be-1607-4a5b-b85c-d48addbcadc0@github.com>

On Fri, 31 Jan 2025 19:54:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.

You may remove `.rows((int) INSTRUCTIONS.lines().count() + 2)`, not mandatory though.

test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 50:

> 48:           - Menu is disabled
> 49:           - Menu has caption 'Popup menu' (only applicable for linux)
> 50:           - Menu items don't show shortcuts (except on MacOS)

Is it good to restrict the test for "Windows and Linux" only ?

test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 84:

> 82:         //Get things going.  Request focus, set size, et cetera
> 83:         frame = new Frame("PopupMenuVisuals");
> 84:         frame.setSize(200,200);

Suggestion:

        frame.setSize(200, 200);

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

PR Review: https://git.openjdk.org/jdk/pull/23402#pullrequestreview-2589061929
PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1938875484
PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1938880535

From azvegint at openjdk.org  Mon Feb  3 11:17:00 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Feb 2025 11:17:00 GMT
Subject: Integrated: 8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland
In-Reply-To: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com>
References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com>
Message-ID: <dZTxkBvZC4wbNkOnSYLX35fW9y6TqPIYqteEpavyf_8=.87315a01-738a-4a82-a4be-c370c0d01904@github.com>

On Tue, 28 Jan 2025 11:28:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API.
> 
> Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990)
>>  the reason is this is using XTEST, an X11 protocol which will not work outside of X11.
>>
>> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. 
> 
> I also tested the same tests by clicking manually instead of using the robot, and it works as expected.
> So for now, skip those tests on Wayland (and do some minor cleanup).
> 
> Testing after modifications is also green.

This pull request has now been integrated.

Changeset: 6f4fc821
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f4fc82149b52dd91289fe42def7d1cacad31212
Stats:     204 lines in 4 files changed: 91 ins; 22 del; 91 mod

8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland

Reviewed-by: aivanov, dnguyen

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

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

From mbaesken at openjdk.org  Mon Feb  3 12:23:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 3 Feb 2025 12:23:49 GMT
Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST
In-Reply-To: <SLSw-asFoNyGesCI63lYE1XcMnKt6eB_bgDW2mveUoA=.846a0afa-71d6-40c0-9d6b-850d76ac667b@github.com>
References: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
 <kbMpDioYGnmsYKvujapuNaKSeCfNhDYKzIcWG0FLovI=.63dc7220-d014-4834-bc61-bd321e6e7834@github.com>
 <fTozCe7sL7M4H2Gs_6ytw37tp5MTE4KB2Qcm3ISkk-Q=.00bfb0e2-9e09-41c8-a845-99e9e0559921@github.com>
 <SLSw-asFoNyGesCI63lYE1XcMnKt6eB_bgDW2mveUoA=.846a0afa-71d6-40c0-9d6b-850d76ac667b@github.com>
Message-ID: <MC86x_UCd_0Jok5ac7p5W4HIOZo4j6q7a_ku-RJ27EE=.8694284a-86eb-4d1b-9c95-92f0a0a52df4@github.com>

On Fri, 31 Jan 2025 13:59:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Still, for some simple cases like e.g. BUILD_LIBSPLASHSCREEN changing the opt level from LOW to SIZE is probably the best 
> thing to do after some more testing.

The size optimization worked pretty well on most platforms , have to look still more into the compilation times of the this lib for a complete picture. No jtreg/jck failures seen.
These are the sizes when comparing LOW to SIZE optimization
Linux ppc64le   500K -> 376K
Linux x86_64    364k -> 304 K
macOS aarch64  468K -> 404K
AIX   2.5M  -> 2.1M
The debuginfo files get smaller too by ~ 10 - 20 %  (AIX has no separate debuginfo file that's why the large binary)

However for MSVC the SIZE optimization flags seem to be bad , the binaries get *LARGER* not smaller !   I opened  https://bugs.openjdk.org/browse/JDK-8349214 .

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

PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2630793171

From azvegint at openjdk.org  Mon Feb  3 17:24:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Feb 2025 17:24:53 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
Message-ID: <vVeHGgTDZR2GgosI-c2dAopuaTwiY6ujXA658I9SHGM=.49d0f9dd-4e54-4168-9b31-f9a89901cce3@github.com>

On Tue, 28 Jan 2025 23:21:26 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - helper function
>  - grab screen data on mouseMove

src/java.desktop/share/classes/java/awt/Robot.java line 229:

> 227: 
> 228:         GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
> 229:         GraphicsDevice[] gs = ge.getScreenDevices();

Suggestion:

        GraphicsDevice[] gds = ge.getScreenDevices();


I found that `gds` is a more common name in our code and testbase. At least for me, I immediately read `gds` as GraphicsDeviceS, array of `GraphicsDevice`.
Same applies for the test.

P.S. It's not a call to action, it's more of an invitation for discussion.

src/java.desktop/share/classes/java/awt/Robot.java line 258:

> 256: 
> 257:         if (leastXDiff > leastYDiff) {
> 258:             peer.mouseMove(finX2, finY2);

Let's say I have the following display configuration on Linux. Since it uses Xinerama, it shares the same coordinate system. 

java.awt.Rectangle[x=0,y=0,width=3440,height=1440]
java.awt.Rectangle[x=3440,y=0,width=1440,height=2560]

![image](https://github.com/user-attachments/assets/1953442c-fa18-49a0-99eb-b633152d83f6)

When I try to move the mouse to `x=20000,y=200`, I see that it clamps to `x=3439,y=200` (a point between 2 screens), while before it was `x=4879,y=200`(a rightmost point).

The old behavior seems more logical to me.

src/java.desktop/share/classes/java/awt/Robot.java line 268:

> 266:     private Point calcClosestPoint(int x, int y, Rectangle screenBounds) {
> 267:         return new Point(Math.min(Math.max(x, screenBounds.x), screenBounds.x + screenBounds.width-1),
> 268:                 Math.min(Math.max(y, screenBounds.y), screenBounds.y + screenBounds.height-1));

Suggestion:

        return new Point(Math.min(Math.max(x, screenBounds.x), screenBounds.x + screenBounds.width - 1),
                Math.min(Math.max(y, screenBounds.y), screenBounds.y + screenBounds.height - 1));


minor spacing issue

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1939749017
PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1939760680
PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1939747548

From aivanov at openjdk.org  Mon Feb  3 17:47:46 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Feb 2025 17:47:46 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <jOWQeiLTF4ZLAn4tcFOaW_-PwBgjzaJcSgg16sh3-co=.b8839459-8c9e-4606-bf0e-93221e716d15@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
 <jOWQeiLTF4ZLAn4tcFOaW_-PwBgjzaJcSgg16sh3-co=.b8839459-8c9e-4606-bf0e-93221e716d15@github.com>
Message-ID: <jMzIKtZGM72OeXO80A3CbYFjhLmA0Bk7RRUPht9EFI0=.a963f6f9-5bfd-418c-8470-9cde8ecf383b@github.com>

On Mon, 3 Feb 2025 06:38:28 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update the test summary
>>  - Remove the redundant button
>
> test/jdk/javax/swing/JButton/4796987/bug4796987.java line 30:
> 
>> 28:  * @requires (os.family == "windows")
>> 29:  * @summary Verify JButton.setBorderPainted(false) removes border
>> 30:  *      for Windows visual styles (Windows XP and later)
> 
> Is it necessary to mention about Windows XP ?

Why not? Visual styles were introduced in Windows XP.

Even though the test was written when both Windows Vista and Windows 7 had already been released, it was limited to Windows XP only for some reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1939789226

From dnguyen at openjdk.org  Mon Feb  3 17:49:15 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 3 Feb 2025 17:49:15 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v2]
In-Reply-To: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
Message-ID: <pf5fYoBnMtWwxhbKBBjmyg9TFJmaKvpPKG45WgjeolU=.a24b8649-f8cb-4d5d-888d-3fed75adb7b5@github.com>

> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23402/files
  - new: https://git.openjdk.org/jdk/pull/23402/files/145cf9fd..1cc6c40e

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

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

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

From dnguyen at openjdk.org  Mon Feb  3 17:49:15 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 3 Feb 2025 17:49:15 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v2]
In-Reply-To: <WYz8DxD1VNh2ChF7DIj4QEFAFO81ftiN1hibJ4RUbF0=.0557b7be-1607-4a5b-b85c-d48addbcadc0@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <WYz8DxD1VNh2ChF7DIj4QEFAFO81ftiN1hibJ4RUbF0=.0557b7be-1607-4a5b-b85c-d48addbcadc0@github.com>
Message-ID: <L7N5BsE1Ps_U2IUn9EXI2ps5h2-IR3ditnzvRugy5TQ=.de298725-e170-4584-965a-5c3db7e1eeb7@github.com>

On Mon, 3 Feb 2025 07:00:58 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 50:
> 
>> 48:           - Menu is disabled
>> 49:           - Menu has caption 'Popup menu' (only applicable for linux)
>> 50:           - Menu items don't show shortcuts (except on MacOS)
> 
> Is it good to restrict the test for "Windows and Linux" only ?

It still tests for PopupMenu visuals on MacOS I suppose. We can still see if a disabled PopupMenu appears correctly. It's also a manual test. Not sure if restricting the test is actually required unless there's a bigger reason I'm missing.

> test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 84:
> 
>> 82:         //Get things going.  Request focus, set size, et cetera
>> 83:         frame = new Frame("PopupMenuVisuals");
>> 84:         frame.setSize(200,200);
> 
> Suggestion:
> 
>         frame.setSize(200, 200);

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1939788579
PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1939791371

From abhiscxk at openjdk.org  Mon Feb  3 18:09:46 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Feb 2025 18:09:46 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <jMzIKtZGM72OeXO80A3CbYFjhLmA0Bk7RRUPht9EFI0=.a963f6f9-5bfd-418c-8470-9cde8ecf383b@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
 <jOWQeiLTF4ZLAn4tcFOaW_-PwBgjzaJcSgg16sh3-co=.b8839459-8c9e-4606-bf0e-93221e716d15@github.com>
 <jMzIKtZGM72OeXO80A3CbYFjhLmA0Bk7RRUPht9EFI0=.a963f6f9-5bfd-418c-8470-9cde8ecf383b@github.com>
Message-ID: <m-j9WfvnyJh32RregYb-vx5BcuYmwY4-SzeJygNHRvw=.94c41c4e-872a-42d2-9a94-4ded53cc3434@github.com>

On Mon, 3 Feb 2025 17:45:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JButton/4796987/bug4796987.java line 30:
>> 
>>> 28:  * @requires (os.family == "windows")
>>> 29:  * @summary Verify JButton.setBorderPainted(false) removes border
>>> 30:  *      for Windows visual styles (Windows XP and later)
>> 
>> Is it necessary to mention about Windows XP ?
>
> Why not? Visual styles were introduced in Windows XP.
> 
> Even though the test was written when both Windows Vista and Windows 7 had already been released, it was limited to Windows XP only for some reason.

Since it will never be tested on Windows XP machine, I thought it's not worth to mention.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1939816320

From abhiscxk at openjdk.org  Mon Feb  3 18:14:51 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 3 Feb 2025 18:14:51 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v2]
In-Reply-To: <pf5fYoBnMtWwxhbKBBjmyg9TFJmaKvpPKG45WgjeolU=.a24b8649-f8cb-4d5d-888d-3fed75adb7b5@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <pf5fYoBnMtWwxhbKBBjmyg9TFJmaKvpPKG45WgjeolU=.a24b8649-f8cb-4d5d-888d-3fed75adb7b5@github.com>
Message-ID: <MnIywRw3aHTz3FIgi2SVtmGcNw5gkZSNtMvq8Zj_Wds=.4a1fdcd8-c5b7-4e4b-8db3-6de7ae197730@github.com>

On Mon, 3 Feb 2025 17:49:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Test changes looks good to me.

test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 81:

> 79:         Menu sm = new Menu("Submenu");
> 80: 
> 81:         //Get things going.  Request focus, set size, et cetera

minor formatting change
Suggestion:

        // Get things going. Request focus, set size, et cetera

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

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23402#pullrequestreview-2590664941
PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1939819092

From azvegint at openjdk.org  Mon Feb  3 18:34:50 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Feb 2025 18:34:50 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v2]
In-Reply-To: <pf5fYoBnMtWwxhbKBBjmyg9TFJmaKvpPKG45WgjeolU=.a24b8649-f8cb-4d5d-888d-3fed75adb7b5@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <pf5fYoBnMtWwxhbKBBjmyg9TFJmaKvpPKG45WgjeolU=.a24b8649-f8cb-4d5d-888d-3fed75adb7b5@github.com>
Message-ID: <30aIco5_NJUPcqJjbVmAxUdmkzEPY3E13H1j3CZzRTs=.422eb396-0fa2-4abd-8bf3-b772548297f3@github.com>

On Mon, 3 Feb 2025 17:49:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 49:

> 47:          If following conditions are met:
> 48:           - Menu is disabled
> 49:           - Menu has caption 'Popup menu' (only applicable for linux)

I believe we can only print instructions that are specific to the current platform.

e.g.:


--- a/test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java
+++ b/test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java
@@ -20,14 +20,17 @@
  * or visit www.oracle.com if you need additional information or have any
  * questions.
  */
+
 /*
  * @test
  * @bug 6180413 6184485 6267144
  * @summary test for popup menu visual bugs in XAWT
- * @library /java/awt/regtesthelpers
- * @build PassFailJFrame
+ * @library /java/awt/regtesthelpers /test/lib
+ * @build PassFailJFrame jdk.test.lib.Platform
  * @run main/manual PopupMenuVisuals
-*/
+ */
+
+import jdk.test.lib.Platform;
 
 import java.awt.Button;
 import java.awt.CheckboxMenuItem;
@@ -45,11 +48,13 @@ public class PopupMenuVisuals {
          This test should show a button 'Popup'.
          Click on the button. A popup menu should be shown.
          If following conditions are met:
-          - Menu is disabled
-          - Menu has caption 'Popup menu' (only applicable for linux)
-          - Menu items don't show shortcuts (except on MacOS)
+          - Menu is disabled %s%s
 
-         Click Pass else click Fail.""";
+         Click Pass else click Fail."""
+            .formatted(
+                    Platform.isLinux() ? "\n - Menu has caption 'Popup menu'" : "",
+                    !Platform.isOSX() ? "\n - Menu items don't show shortcuts" : ""
+            );
 
     static PopupMenu pm;
     static Frame frame;


I think it will improve a test user experience.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1939837571

From aivanov at openjdk.org  Mon Feb  3 18:48:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 3 Feb 2025 18:48:45 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <m-j9WfvnyJh32RregYb-vx5BcuYmwY4-SzeJygNHRvw=.94c41c4e-872a-42d2-9a94-4ded53cc3434@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
 <jOWQeiLTF4ZLAn4tcFOaW_-PwBgjzaJcSgg16sh3-co=.b8839459-8c9e-4606-bf0e-93221e716d15@github.com>
 <jMzIKtZGM72OeXO80A3CbYFjhLmA0Bk7RRUPht9EFI0=.a963f6f9-5bfd-418c-8470-9cde8ecf383b@github.com>
 <m-j9WfvnyJh32RregYb-vx5BcuYmwY4-SzeJygNHRvw=.94c41c4e-872a-42d2-9a94-4ded53cc3434@github.com>
Message-ID: <Pw7aQEz6lzrjogkNSyG5nJNvuiIdU9RWmL4l2FglRNs=.c777ccd1-4d75-4d41-9b2c-b6d04f5d768a@github.com>

On Mon, 3 Feb 2025 18:07:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Why not? Visual styles were introduced in Windows XP.
>> 
>> Even though the test was written when both Windows Vista and Windows 7 had already been released, it was limited to Windows XP only for some reason.
>
> Since it will never be tested on Windows XP machine, I thought it's not worth to mention.

It just references the point where the feature was introduced.

Currently supported versions of Java likely don't start on Windows XP any more, but it doesn't change the fact that visual styles were introduced in Windows XP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1939863738

From dnguyen at openjdk.org  Mon Feb  3 19:02:30 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 3 Feb 2025 19:02:30 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v3]
In-Reply-To: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
Message-ID: <1T3XJsT6uDfsJ4J8HCultUGATWEoa4Xio27Um6dKJLI=.b0de2a72-a20c-45ac-90f1-47ee04b6886b@github.com>

> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.

Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:

 - Separate comment blocks
 - Add platform conditionals to test instructions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23402/files
  - new: https://git.openjdk.org/jdk/pull/23402/files/1cc6c40e..fb78b9ef

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

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

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

From dnguyen at openjdk.org  Mon Feb  3 19:02:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 3 Feb 2025 19:02:31 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v2]
In-Reply-To: <30aIco5_NJUPcqJjbVmAxUdmkzEPY3E13H1j3CZzRTs=.422eb396-0fa2-4abd-8bf3-b772548297f3@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <pf5fYoBnMtWwxhbKBBjmyg9TFJmaKvpPKG45WgjeolU=.a24b8649-f8cb-4d5d-888d-3fed75adb7b5@github.com>
 <30aIco5_NJUPcqJjbVmAxUdmkzEPY3E13H1j3CZzRTs=.422eb396-0fa2-4abd-8bf3-b772548297f3@github.com>
Message-ID: <1v65Rq58gO6DNc814J64uJlYWzTbXAC7xGkS7FFmx6M=.aca0645d-d99b-4594-86e8-ad5073f3c4af@github.com>

On Mon, 3 Feb 2025 18:25:47 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 49:
> 
>> 47:          If following conditions are met:
>> 48:           - Menu is disabled
>> 49:           - Menu has caption 'Popup menu' (only applicable for linux)
> 
> I believe we can only print instructions that are specific to the current platform.
> 
> e.g.:
> 
> 
> --- a/test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java
> +++ b/test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java
> @@ -20,14 +20,17 @@
>   * or visit www.oracle.com if you need additional information or have any
>   * questions.
>   */
> +
>  /*
>   * @test
>   * @bug 6180413 6184485 6267144
>   * @summary test for popup menu visual bugs in XAWT
> - * @library /java/awt/regtesthelpers
> - * @build PassFailJFrame
> + * @library /java/awt/regtesthelpers /test/lib
> + * @build PassFailJFrame jdk.test.lib.Platform
>   * @run main/manual PopupMenuVisuals
> -*/
> + */
> +
> +import jdk.test.lib.Platform;
>  
>  import java.awt.Button;
>  import java.awt.CheckboxMenuItem;
> @@ -45,11 +48,13 @@ public class PopupMenuVisuals {
>           This test should show a button 'Popup'.
>           Click on the button. A popup menu should be shown.
>           If following conditions are met:
> -          - Menu is disabled
> -          - Menu has caption 'Popup menu' (only applicable for linux)
> -          - Menu items don't show shortcuts (except on MacOS)
> +          - Menu is disabled %s%s
>  
> -         Click Pass else click Fail.""";
> +         Click Pass else click Fail."""
> +            .formatted(
> +                    Platform.isLinux() ? "\n - Menu has caption 'Popup menu'" : "",
> +                    !Platform.isOSX() ? "\n - Menu items don't show shortcuts" : ""
> +            );
>  
>      static PopupMenu pm;
>      static Frame frame;
> 
> 
> I think it will improve a test user experience.

Neat! Learned something new. Will definitely use this where applicable in the future. Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1939878279

From dnguyen at openjdk.org  Mon Feb  3 19:02:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 3 Feb 2025 19:02:31 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v2]
In-Reply-To: <MnIywRw3aHTz3FIgi2SVtmGcNw5gkZSNtMvq8Zj_Wds=.4a1fdcd8-c5b7-4e4b-8db3-6de7ae197730@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <pf5fYoBnMtWwxhbKBBjmyg9TFJmaKvpPKG45WgjeolU=.a24b8649-f8cb-4d5d-888d-3fed75adb7b5@github.com>
 <MnIywRw3aHTz3FIgi2SVtmGcNw5gkZSNtMvq8Zj_Wds=.4a1fdcd8-c5b7-4e4b-8db3-6de7ae197730@github.com>
Message-ID: <Z8kL8Of4GQxu09JTCjPvUecIYrtYwEjJR5b7F_nLeq0=.9ab7ab10-248c-4b0f-bbaa-c4cdb00d5b65@github.com>

On Mon, 3 Feb 2025 18:10:04 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 81:
> 
>> 79:         Menu sm = new Menu("Submenu");
>> 80: 
>> 81:         //Get things going.  Request focus, set size, et cetera
> 
> minor formatting change
> Suggestion:
> 
>         // Get things going. Request focus, set size, et cetera

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1939878437

From azvegint at openjdk.org  Mon Feb  3 19:18:29 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Feb 2025 19:18:29 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
Message-ID: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>

This changeset updates the pipewire headers to the latest available version.
It contains the minimum set of required header files needed to build the JDK.

The updated headers are a direct copy from the 
https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
 
Testing looks good.

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

Commit messages:
 - replace "\t" with "    ", part 2
 - replace "\t" with "    "
 - 8348600: Update PipeWire to 1.3.81

Changes: https://git.openjdk.org/jdk/pull/23426/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348600
  Stats: 2369 lines in 72 files changed: 1728 ins; 59 del; 582 mod
  Patch: https://git.openjdk.org/jdk/pull/23426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23426/head:pull/23426

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

From azvegint at openjdk.org  Mon Feb  3 19:20:47 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Feb 2025 19:20:47 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v3]
In-Reply-To: <1T3XJsT6uDfsJ4J8HCultUGATWEoa4Xio27Um6dKJLI=.b0de2a72-a20c-45ac-90f1-47ee04b6886b@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <1T3XJsT6uDfsJ4J8HCultUGATWEoa4Xio27Um6dKJLI=.b0de2a72-a20c-45ac-90f1-47ee04b6886b@github.com>
Message-ID: <7HZuP1im2YeyXZWJdhSjuwohZp8Z2lDY8kkxUxNPAu4=.c2ec04a9-c524-45fc-8c13-91539e126c23@github.com>

On Mon, 3 Feb 2025 19:02:30 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.
>
> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Separate comment blocks
>  - Add platform conditionals to test instructions

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23402#pullrequestreview-2590801759

From azvegint at openjdk.org  Mon Feb  3 19:29:45 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 3 Feb 2025 19:29:45 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
Message-ID: <8hWsXJEfZNSGcgra16JYoDKYK45rI-nuZVvWOaxFKOI=.dc6a6b68-274f-45f7-b8ec-eb77d7da692f@github.com>

On Mon, 3 Feb 2025 18:50:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset updates the pipewire headers to the latest available version.
> It contains the minimum set of required header files needed to build the JDK.
> 
> The updated headers are a direct copy from the 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
>  
> Testing looks good.

@MBaesken I guess it will break the AIX build again, as it did before(see https://github.com/openjdk/jdk/pull/14390)

Could you please check if that this PR plus the following patch is sufficient to avoid this?

 ```patch
--- a/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h
+++ b/src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h
@@ -11,7 +11,15 @@ extern "C" {
 
 #include <stdint.h>
 
-#include <spa/utils/endian.h>
+#if !defined(__FreeBSD__) && !defined(__MidnightBSD__) && !defined(AIX)
+#include <endian.h>
+#endif
+
+#if defined(AIX)
+#include <sys/machine.h>
+#define __BIG_ENDIAN      BIG_ENDIAN
+#define __BYTE_ORDER      BIG_ENDIAN
+#endif
 
 /**
  * \addtogroup spa_param

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

PR Comment: https://git.openjdk.org/jdk/pull/23426#issuecomment-2631882168

From achung at openjdk.org  Mon Feb  3 22:58:17 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 3 Feb 2025 22:58:17 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v6]
In-Reply-To: <-xcXsVV9DmHoMMQI-syIIF-k7gxxlPLtSyzPLhCespY=.3b4a6dda-e0ef-4849-9889-508e0d6c73cc@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <tJlq_oMOMAZgPGUDkGh5vGKolqBRAIQrMEgQI_tYAgg=.e8208e49-0dc6-46c1-a895-c5aed42c4b5d@github.com>
 <XicoKbM5VfaVUORshn-Eqlj9jiDvq53T6zs6XUgpe5o=.c1336854-7e9b-439f-b4b2-8b23d20ff1e9@github.com>
 <hqnqdZKWMbzE_SxhguY5bQcJEjfCsEe7udhEPEgVfww=.0ed0aed5-43e1-4202-be35-32f922810f02@github.com>
 <PLtocBZ8gs1OZ4SCcMLcbZwvrmJEJlTM0wwQuaUUTJE=.b906076f-f9c4-4b39-8b59-de7582b82595@github.com>
 <-xcXsVV9DmHoMMQI-syIIF-k7gxxlPLtSyzPLhCespY=.3b4a6dda-e0ef-4849-9889-508e0d6c73cc@github.com>
Message-ID: <awhfwcPIG-C_spuu_CqH91q_8C8LWFdOtfZLK7YZ2sw=.8df7f580-7853-485f-a557-4471927b9a39@github.com>

On Fri, 31 Jan 2025 19:51:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> In macOS? Do you mean in macOS-specific code in JDK?
> 
> ~If the code to clamp mouse coordinates has already been written, why are you writing new code instead of re-using the existing code?~

Yes, I meant macOS-specific code in JDK. The idea was I'm moving the macOS-specific code into shared code since I think clamping should be part of mouseMove behavior.


> > But why this coordinates nonexistent, you at least can move undecorated windows there, that coordinates just is not visible on teh screen.
> 
> This is the question we have to answer first: Are the coordinates off the virtual screen invalid, non-existent?


> Then, when you use a physical mouse, the OS doesn't allow moving the mouse cursor outside of the virtual screen bounds. Does this imply Java should prevent moving the mouse cursor off the virtual screen, too?

I do think that robot should emulate what you can manually do with a mouse/keyboard, and since we can't interact with a window offscreen normally robot shouldn't be able to do so either. Also, since mousePress and mouseRelease can't be done offscreen either because of the checkMousePos() call anyway, it doesn't make sense to keep mouseMove behavior as is as the only mouse function to be able to go offscreen.

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2632364505

From duke at openjdk.org  Tue Feb  4 00:12:28 2025
From: duke at openjdk.org (anass baya)
Date: Tue, 4 Feb 2025 00:12:28 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
Message-ID: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>

8303904: [macos]Transparent Windows Paint Wrong (Opaque, Pixelated) w/o Volatile Buffering

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

Commit messages:
 - fix for pixelated images
 - Add test for pixelated images at high resolution
 - Test for Mac platfotm
 - Unit Test to Verify Window Transparency and Black Border Presence
 - fix 1 : fix for non-transparency and black borders

Changes: https://git.openjdk.org/jdk/pull/23430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303904
  Stats: 244 lines in 4 files changed: 237 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23430/head:pull/23430

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

From achung at openjdk.org  Tue Feb  4 00:27:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 4 Feb 2025 00:27:15 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v3]
In-Reply-To: <1T3XJsT6uDfsJ4J8HCultUGATWEoa4Xio27Um6dKJLI=.b0de2a72-a20c-45ac-90f1-47ee04b6886b@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <1T3XJsT6uDfsJ4J8HCultUGATWEoa4Xio27Um6dKJLI=.b0de2a72-a20c-45ac-90f1-47ee04b6886b@github.com>
Message-ID: <q8zJhhF9kT1mODvUxKO0fk8oS8lffaW9X_WZrB0aepg=.c93e4892-42b0-4df5-a27b-e1ed8c690bc0@github.com>

On Mon, 3 Feb 2025 19:02:30 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.
>
> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Separate comment blocks
>  - Add platform conditionals to test instructions

Marked as reviewed by achung (Committer).

test/jdk/java/awt/PopupMenu/PopupMenuVisuals.java line 86:

> 84:         Menu sm = new Menu("Submenu");
> 85: 
> 86:         // Get things going.  Request focus, set size, et cetera

can just remove this comment since it's an artifact from Applet testing

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

PR Review: https://git.openjdk.org/jdk/pull/23402#pullrequestreview-2591429446
PR Review Comment: https://git.openjdk.org/jdk/pull/23402#discussion_r1940307967

From duke at openjdk.org  Tue Feb  4 01:04:13 2025
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 4 Feb 2025 01:04:13 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <xdg9z3kO4NRYjAl9k1_h_EE-_Glr0kIy_fv2i8Qvx-0=.b162d766-60aa-4a21-8349-9c75c9f71a3b@github.com>

On Tue, 4 Feb 2025 00:07:48 GMT, anass baya <duke at openjdk.org> wrote:

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

test/jdk/javax/swing/JWindow/NonVolatileTransparentWindows/PixelatedImageTest.java line 2:

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

Looks like this is the new test please fix the year

test/jdk/javax/swing/JWindow/NonVolatileTransparentWindows/TransparentWindowTest.java line 71:

> 69:         setLocationRelativeTo(null);
> 70: 
> 71:         // Check transparency and border color

Move the comment to the testWindowProperties() method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940333511
PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940335366

From duke at openjdk.org  Tue Feb  4 05:08:16 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Feb 2025 05:08:16 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
Message-ID: <NkgIagfV2RzKgkyXcDiKjqDbY4lFF4SnqcDLQRJOjzc=.318ccf5e-b4aa-4c65-9a39-f1ef6665edd2@github.com>

On Fri, 19 Apr 2024 14:53:09 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearranged if based on suggesion

@Renjithkannath 
Your change (at version be168e9d331ead58503ac3a01dae0bd98ae42d5e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/18670#issuecomment-2632888405

From abhiscxk at openjdk.org  Tue Feb  4 05:30:21 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Feb 2025 05:30:21 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
Message-ID: <61pmrNxs27Urk3OD4yq9_32FUCZdwfhkI3TJMCDaLW8=.39a191e8-b352-479c-9555-1b618f923cd6@github.com>

On Fri, 31 Jan 2025 20:40:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows.
>> 
>> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely.
>> 
>> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails.
>> 
>> The updated test passes in the CI.
>
> Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update the test summary
>  - Remove the redundant button

LGTM

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

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23336#pullrequestreview-2591770404

From abhiscxk at openjdk.org  Tue Feb  4 05:30:22 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Feb 2025 05:30:22 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <Pw7aQEz6lzrjogkNSyG5nJNvuiIdU9RWmL4l2FglRNs=.c777ccd1-4d75-4d41-9b2c-b6d04f5d768a@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
 <jOWQeiLTF4ZLAn4tcFOaW_-PwBgjzaJcSgg16sh3-co=.b8839459-8c9e-4606-bf0e-93221e716d15@github.com>
 <jMzIKtZGM72OeXO80A3CbYFjhLmA0Bk7RRUPht9EFI0=.a963f6f9-5bfd-418c-8470-9cde8ecf383b@github.com>
 <m-j9WfvnyJh32RregYb-vx5BcuYmwY4-SzeJygNHRvw=.94c41c4e-872a-42d2-9a94-4ded53cc3434@github.com>
 <Pw7aQEz6lzrjogkNSyG5nJNvuiIdU9RWmL4l2FglRNs=.c777ccd1-4d75-4d41-9b2c-b6d04f5d768a@github.com>
Message-ID: <w6ue-uHMJYbOQgHsMM40Q8xF_X9jYIOTM9JNjJth5uU=.5600bd9b-ca7b-4108-94bf-1736e5cc0873@github.com>

On Mon, 3 Feb 2025 18:45:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Since it will never be tested on Windows XP machine, I thought it's not worth to mention.
>
> It just references the point where the feature was introduced.
> 
> Currently supported versions of Java likely don't start on Windows XP any more, but it doesn't change the fact that visual styles were introduced in Windows XP.

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1940525618

From duke at openjdk.org  Tue Feb  4 06:19:19 2025
From: duke at openjdk.org (ScientificWare)
Date: Tue, 4 Feb 2025 06:19:19 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v10]
In-Reply-To: <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
 <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
Message-ID: <_bMB1ydhV0NraiXc7eGlwrQMsbZTDlmpyzKROo93R4Q=.a21ad25e-b086-4959-9ddc-8b31d818d315@github.com>

On Mon, 9 Dec 2024 09:56:15 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731)
>> 
>> This is tracked in JBS as
>> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731)
>> 
>> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input)
>> 
>> `alt` is not an attribute of the `input` element.
>> 
>> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : 
>> 
>>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ...
>> 
>> This feature is not implemented in `FormView.java`.
>> 
>> ??  ~~This also affects the HTML 32 DTD~~
>> 
>> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138)
>> 
>> Left before the patch and right after the patch.
>> 
>> 
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import javax.swing.JEditorPane;
>> import javax.swing.JFrame;
>> import javax.swing.JScrollPane;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.Document;
>> import javax.swing.text.html.HTMLEditorKit;
>> import javax.swing.text.html.StyleSheet;
>> 
>> public class HTMLAddsSupportAltInputTag {
>>   public static void main(String[] args) {
>>     new HTMLAddsSupportAltInputTag();
>>   }
>>   
>>   public HTMLAddsSupportAltInputTag() {
>>     SwingUtilities.invokeLater(new Runnable(){
>>       public void run(){
>>         JEditorPane jEditorPane = new JEditorPane();
>>         jEditorPane.setEditable(false);
>>         JScrollPane scrollPane = new JScrollPane(jEditorPane);
>>         HTMLEditorKit kit = new HTMLEditorKit();
>>         jEditorPane.setEditorKit(kit);
>>         StyleSheet styleSheet = kit.getStyleSheet();
>>         styleSheet.addRule("""
>>             body {
>>                 color: #000;
>>                 font-family:times;
>>                 margin: 4px;
>>             }
>>             """);
>>         String htmlString = """
>>             <html>
>>                 <body>
>>                     <input type=image name=point src="file:oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>>                     <p>
>>                     <input type=image name=point src="file:none_ora...
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge master
>  - JDK-8314731 : Remove all indentations accidentally introduced by the previous commit.
>  - Merge master
>  - Merge master
>  - jdk-8314731 : FormView Alt Support.
>    
>    FormView.java :
>    - revert ALL unrelated changing to formatting.
>    
>    bug8314731.java :
>    - Fix the test description.
>    - Change where the user interface is created.
>    - Add a finall block to be sure the Frame is disposed.
>    - Replace "testPassed" with "testFailed".
>  - Merge master
>  - Replaces this title with "alt attribute test in HTML image type input".
>    
>    Moves this test to /jdk/test/jdk/javax/swing/text/html.
>  - bug8314731.java : Corrects the CopyRight date.
>  - FormView.java :
>    Removes a whitespace
>    
>    bug8314731.java :
>    Adds a newline at end of file.
>  - getMaximumSpan(int axis) method
>    doc -> Not used
>    
>    mouseReleased(MouseEvent evt) method
>    elem and hdoc -> not used
>    return -> could be removed, method returns void
>    
>    loadElementDataIntoBuffer(Element elem, StringBuilder buffer) method
>    value != null -> name can't be null at this point
>    
>    getInputElementData(AttributeSet attr) method
>    value = null -> Already set at null
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/69e664de...9b423808

Awaiting review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-2632976254

From duke at openjdk.org  Tue Feb  4 07:35:11 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 4 Feb 2025 07:35:11 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <R2BGlbK9V2a0D_a0xWKdaj_8P65a9cb6Yg8eRwWHnKQ=.934e7af2-35c4-4aa0-b15a-60d14aa1072a@github.com>

On Tue, 4 Feb 2025 00:07:48 GMT, anass baya <duke at openjdk.org> wrote:

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 246:

> 244:         int fullResWidth = Math.round( scaleFactor * width);
> 245:         int fullResHeight = Math.round( scaleFactor * height);
> 246:         WritableRaster wr = model.createCompatibleWritableRaster(fullResWidth, fullResHeight);

Thanks for working on this. :)

I have a couple of questions:

1. This math looks great for the simple case of a 200% high-res monitor; is the rounding safe for non-integer resolutions?

For ex if width is 33 and scaleFactor is 1.25, then we'll call `round(41.25)`, so `fullResWidth = 41`.

Will the native windowing system allocate 41px for our Window? (Because if so: great. We have a perfect fit.) Or could it allocate 42px? (In which case we may have a thin border on the right/bottom that becomes unpaintable...)

2. I'm assuming if `fullResWidth`/`fullResHeight` is ever zero we'll get a RTE. I don't think it's stated, but the preexisting code suggests `width` and `height` were never zero. Is it possible `scaleFactor` can ever be less than .5? (I've never observed that in my day-to-day life, but I'm just thinking about edge cases and RTE's...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940637680

From duke at openjdk.org  Tue Feb  4 08:05:11 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 4 Feb 2025 08:05:11 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <UJKPU00GA0SvyPHXNCUoFIiRyTn_NyOKiHEQnrCUWBc=.3bd66306-b4d9-426f-9789-6fb5d5eb6cb8@github.com>

On Tue, 4 Feb 2025 00:07:48 GMT, anass baya <duke at openjdk.org> wrote:

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 260:

> 258:             }
> 259:         };
> 260:     }

This may be outside the scope of this ticket, but I'm seeing similar code in Win32GraphicsConfig#createAcceleratedImage(..), X11GraphicsConfig#createAcceleratedImage(..), and GLXGraphicsConfig#createAcceleratedImage(..) .

Should those be looked at, or is there another ticket to explore those? (That is: are they also going to be opaque and the wrong resolution?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940682099

From duke at openjdk.org  Tue Feb  4 08:18:10 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 4 Feb 2025 08:18:10 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <M39CTHixECWmy-ArKd6MDcaCK9Qp9Qi2qsX69xwVOYk=.17e1a418-46d4-411b-a697-020e3303037f@github.com>

On Tue, 4 Feb 2025 00:07:48 GMT, anass baya <duke at openjdk.org> wrote:

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java line 279:

> 277:             }
> 278:         };
> 279:     }

Should this new `createAcceleratedImage(..)` logic be moved to `CGraphicsConfig`?

This looks like copied and pasted code in two subclasses that could be abstracted into the parent class. (I could be wrong here; I just wanted to check opinions...?)

It looks like these two classes (MTLGraphicsConfig and CGLGraphicsConfig) are the only subclasses for CGraphicsConfig.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940699051

From abhiscxk at openjdk.org  Tue Feb  4 10:06:19 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Feb 2025 10:06:19 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
Message-ID: <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>

On Thu, 30 Jan 2025 15:47:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Draw checkmark skin at same location with/without icon

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 884:

> 882:                 }
> 883:                 if (icon != null) {
> 884:                     icon.paintIcon(c, g, x + 3 * OFFSET, y + OFFSET);

Why offset is multiplied by 3? does it depend on the icon size?

Buffered Image in test code is of size 16x16. Is it possible that the icon can be of different size?

If Icon size is more then I guess it may overlap with radio button skin.

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

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

From duke at openjdk.org  Tue Feb  4 10:13:10 2025
From: duke at openjdk.org (anass baya)
Date: Tue, 4 Feb 2025 10:13:10 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <R2BGlbK9V2a0D_a0xWKdaj_8P65a9cb6Yg8eRwWHnKQ=.934e7af2-35c4-4aa0-b15a-60d14aa1072a@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
 <R2BGlbK9V2a0D_a0xWKdaj_8P65a9cb6Yg8eRwWHnKQ=.934e7af2-35c4-4aa0-b15a-60d14aa1072a@github.com>
Message-ID: <PhqR-PRF5cJk00Cd_RyiS4eS9hOSYBP477YHqAtMTjo=.24a41290-09d4-4cbb-8d7e-0981c2e56f80@github.com>

On Tue, 4 Feb 2025 07:32:07 GMT, Jeremy <duke at openjdk.org> wrote:

>> The PR includes two fix : 
>> 1 - The first fix targets proper rendering of the transparent image.
>> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 246:
> 
>> 244:         int fullResWidth = Math.round( scaleFactor * width);
>> 245:         int fullResHeight = Math.round( scaleFactor * height);
>> 246:         WritableRaster wr = model.createCompatibleWritableRaster(fullResWidth, fullResHeight);
> 
> Thanks for working on this. :)
> 
> I have a couple of questions:
> 
> 1. This math looks great for the simple case of a 200% high-res monitor; is the rounding safe for non-integer resolutions?
> 
> For ex if width is 33 and scaleFactor is 1.25, then we'll call `round(41.25)`, so `fullResWidth = 41`.
> 
> Will the native windowing system allocate 41px for our Window? (Because if so: great. We have a perfect fit.) Or could it allocate 42px? (In which case we may have a thin border on the right/bottom that becomes unpaintable...)
> 
> 2. I'm assuming if `fullResWidth`/`fullResHeight` is ever zero we'll get a RTE. I don't think it's stated, but the preexisting code suggests `width` and `height` were never zero. Is it possible `scaleFactor` can ever be less than .5? (I've never observed that in my day-to-day life, but I'm just thinking about edge cases and RTE's...)

Hello @mickleness , 
Thank you for your review.
It is well known that we can lose a fraction of a pixel. For example in https://github.com/openjdk/jdk/pull/23183 we allowed a 1-pixel margin of error to compensate for that as the rounding error could accumulate

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940876427

From duke at openjdk.org  Tue Feb  4 10:16:11 2025
From: duke at openjdk.org (anass baya)
Date: Tue, 4 Feb 2025 10:16:11 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <UJKPU00GA0SvyPHXNCUoFIiRyTn_NyOKiHEQnrCUWBc=.3bd66306-b4d9-426f-9789-6fb5d5eb6cb8@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
 <UJKPU00GA0SvyPHXNCUoFIiRyTn_NyOKiHEQnrCUWBc=.3bd66306-b4d9-426f-9789-6fb5d5eb6cb8@github.com>
Message-ID: <Mmmss6KBvzV6xkYFyIjRM6nQXA8kuy20edJ0yZ2EgGg=.8189bbeb-38dd-4f4c-935c-0ec39e5b420e@github.com>

On Tue, 4 Feb 2025 08:02:08 GMT, Jeremy <duke at openjdk.org> wrote:

>> The PR includes two fix : 
>> 1 - The first fix targets proper rendering of the transparent image.
>> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 260:
> 
>> 258:             }
>> 259:         };
>> 260:     }
> 
> This may be outside the scope of this ticket, but I'm seeing similar code in Win32GraphicsConfig#createAcceleratedImage(..), X11GraphicsConfig#createAcceleratedImage(..), and GLXGraphicsConfig#createAcceleratedImage(..) .
> 
> Should those be looked at, or is there another ticket to explore those? (That is: are they also going to be opaque and the wrong resolution?)

Hello @mickleness,
The problem is not reproduced on windows !! I can see it only on mac

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1940881969

From aivanov at openjdk.org  Tue Feb  4 11:09:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 11:09:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
Message-ID: <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>

On Tue, 4 Feb 2025 10:02:22 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Why offset is multiplied by 3?

I believe this is likely how layout is calculated.

> Buffered Image in test code is of size 16x16. Is it possible that the icon can be of different size?

It's definitely possible? Yet it's pretty common to use 16?16 (small) icons in menus.

This question is applicable to other L&Fs, yet the problem could be more prominent in Windows L&F.

> does it depend on the icon size?
> If Icon size is more then I guess it may overlap with radio button skin.

This is why we should re-work the layout of menus with icons if there's any radio- or check-menu item as I [suggested above](https://github.com/openjdk/jdk/pull/23324#discussion_r1935784688).

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

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

From abhiscxk at openjdk.org  Tue Feb  4 11:09:25 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Feb 2025 11:09:25 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
Message-ID: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>

VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 

Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).

Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.

Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.

The proposed change can be verified the manual test in the PR.

CI pipeline testing is `OK`, link posted in JBS.

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

Commit messages:
 - Whitespace jcheck fix
 - Manual test and copyright year update
 - CheckBox and ToggleButton untick state fix

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

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

From aivanov at openjdk.org  Tue Feb  4 11:12:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 11:12:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <d0NdKVFNl6alcc054tgyWtDnpTHXPSjWLiMzSp_VI2M=.0196a71d-02a5-4b71-843d-47d1843b1f83@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com>
 <d0NdKVFNl6alcc054tgyWtDnpTHXPSjWLiMzSp_VI2M=.0196a71d-02a5-4b71-843d-47d1843b1f83@github.com>
Message-ID: <dAzHlsFG86r7jIxTYGdzjLJX3wIMxHQX5csTT4H2miM=.785d047c-c52c-4db8-a920-8ad3a3ea8b53@github.com>

On Thu, 30 Jan 2025 07:41:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatting
>
> test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java line 45:
> 
>> 43: public class TestImageIconWithJRadioButtonMenuItem {
>> 44: 
>> 45:     private static final String instructionsText = """
> 
> Suggestion:
> 
>     private static final String INSTRUCTIONSTEXT = """

For what it's worth, it should be `INSTRUCTIONS_TEXT` with the underscore separating words.

It's not required to capitalise private constants, only public constants use all capitals with underscores between words.

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

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

From aivanov at openjdk.org  Tue Feb  4 11:13:18 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 11:13:18 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v10]
In-Reply-To: <_bMB1ydhV0NraiXc7eGlwrQMsbZTDlmpyzKROo93R4Q=.a21ad25e-b086-4959-9ddc-8b31d818d315@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
 <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
 <_bMB1ydhV0NraiXc7eGlwrQMsbZTDlmpyzKROo93R4Q=.a21ad25e-b086-4959-9ddc-8b31d818d315@github.com>
Message-ID: <XMGghc3cmRT6QLp9IUd-EVhz62kVsgHOKOw3uX096oA=.9c6e8e8c-9ddb-4066-9b94-38ed2c29842b@github.com>

On Tue, 4 Feb 2025 06:16:29 GMT, ScientificWare <duke at openjdk.org> wrote:

> Awaiting review.

I've been unable to take a look at the updated code yet. I'll look at the changes as soon as I can.

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

PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-2633589047

From psadhukhan at openjdk.org  Tue Feb  4 11:16:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Feb 2025 11:16:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
 <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
Message-ID: <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>

On Tue, 4 Feb 2025 11:06:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is why we should re-work the layout of menus with icons if there's any radio- or check-menu item as I [suggested above](https://github.com/openjdk/jdk/pull/23324#discussion_r1935784688).

Not sure I understand...As in windows11 Explorer, radiobutton checkmark and icon are at the same position as in jdk..
what more you are suggesting to change?

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

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

From aivanov at openjdk.org  Tue Feb  4 11:17:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 11:17:16 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
Message-ID: <CHlhD16Vw09-lR9NK0E5obWDfM1RVEt0AMkWaT8ZtEE=.4a5817f7-8212-4f4b-abe3-802838f31f54@github.com>

On Fri, 19 Apr 2024 14:53:09 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearranged if based on suggesion

I believe it's premature to integrate it right away. At the very least, you should merge master and re-run all the client tests before integrating.

Even though the PR is approved, there's [an unresolved discussion](https://github.com/openjdk/jdk/pull/18670#pullrequestreview-2048663406).

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

PR Comment: https://git.openjdk.org/jdk/pull/18670#issuecomment-2633596869

From psadhukhan at openjdk.org  Tue Feb  4 11:21:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Feb 2025 11:21:10 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <dAzHlsFG86r7jIxTYGdzjLJX3wIMxHQX5csTT4H2miM=.785d047c-c52c-4db8-a920-8ad3a3ea8b53@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com>
 <d0NdKVFNl6alcc054tgyWtDnpTHXPSjWLiMzSp_VI2M=.0196a71d-02a5-4b71-843d-47d1843b1f83@github.com>
 <dAzHlsFG86r7jIxTYGdzjLJX3wIMxHQX5csTT4H2miM=.785d047c-c52c-4db8-a920-8ad3a3ea8b53@github.com>
Message-ID: <zcRore0W3JgFGVyZ11cwgw6RfwXl6J0cj5_85ehpM8s=.16dc2fc2-cb67-4c80-968f-43f3d9ea979e@github.com>

On Tue, 4 Feb 2025 11:09:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java line 45:
>> 
>>> 43: public class TestImageIconWithJRadioButtonMenuItem {
>>> 44: 
>>> 45:     private static final String instructionsText = """
>> 
>> Suggestion:
>> 
>>     private static final String INSTRUCTIONSTEXT = """
>
> For what it's worth, it should be `INSTRUCTIONS_TEXT` with the underscore separating words.
> 
> It's not required to capitalise private constants, only public constants use all capitals with underscores between words.

FWIW, it is changed to "INSTRUCTIONS" in test..

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

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

From aivanov at openjdk.org  Tue Feb  4 11:26:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 11:26:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
 <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
 <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>
Message-ID: <yRj0FD8SfxIpkdPaF0yKcatAzH4zNL_rTu8Hj83fFzs=.bc1b549a-630d-4489-8760-a3fb72c1b6fe@github.com>

On Tue, 4 Feb 2025 11:13:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Why offset is multiplied by 3?
>> 
>> I believe this is likely how layout is calculated.
>> 
>>> Buffered Image in test code is of size 16x16. Is it possible that the icon can be of different size?
>> 
>> It's definitely possible? Yet it's pretty common to use 16?16 (small) icons in menus.
>> 
>> This question is applicable to other L&Fs, yet the problem could be more prominent in Windows L&F.
>> 
>>> does it depend on the icon size?
>>> If Icon size is more then I guess it may overlap with radio button skin.
>> 
>> This is why we should re-work the layout of menus with icons if there's any radio- or check-menu item as I [suggested above](https://github.com/openjdk/jdk/pull/23324#discussion_r1935784688).
>
>> This is why we should re-work the layout of menus with icons if there's any radio- or check-menu item as I [suggested above](https://github.com/openjdk/jdk/pull/23324#discussion_r1935784688).
> 
> Not sure I understand...As in windows11 Explorer, radiobutton checkmark and icon are at the same position as in jdk..
> what more you are suggesting to change?

Radio- or checks are in the same position but ***the icon itself** is moved to the right* so that both the bullet or check and the icon are displayed.

Currently, only the icon is rendered at the place where the bullet or checkmark are if there's no icon.

The result should like this

![Proposed layout for icons and bullets](https://github.com/user-attachments/assets/c3809aaa-3219-4b9a-b86e-7850a747f652)

instead of

![Windows 10 - red square item selected](https://github.com/user-attachments/assets/343adf20-b3ca-4c06-af93-e63736bce123)

It is the former image that corresponds to File Explorer in Windows 11: https://github.com/openjdk/jdk/pull/23324#discussion_r1935744523

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

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

From psadhukhan at openjdk.org  Tue Feb  4 11:42:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Feb 2025 11:42:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <yRj0FD8SfxIpkdPaF0yKcatAzH4zNL_rTu8Hj83fFzs=.bc1b549a-630d-4489-8760-a3fb72c1b6fe@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
 <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
 <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>
 <yRj0FD8SfxIpkdPaF0yKcatAzH4zNL_rTu8Hj83fFzs=.bc1b549a-630d-4489-8760-a3fb72c1b6fe@github.com>
Message-ID: <U0nr1mSssHPg6vffBpb5s-23tmG8aWipfshWBblcG1o=.63740827-489f-46bd-9304-12e807e612e1@github.com>

On Tue, 4 Feb 2025 11:23:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> This is why we should re-work the layout of menus with icons if there's any radio- or check-menu item as I [suggested above](https://github.com/openjdk/jdk/pull/23324#discussion_r1935784688).
>> 
>> Not sure I understand...As in windows11 Explorer, radiobutton checkmark and icon are at the same position as in jdk..
>> what more you are suggesting to change?
>
> Radio- or checks are in the same position but ***the icon itself** is moved to the right* so that both the bullet or check and the icon are displayed.
> 
> Currently, only the icon is rendered at the place where the bullet or checkmark are if there's no icon.
> 
> The result should like this
> 
> ![Proposed layout for icons and bullets](https://github.com/user-attachments/assets/c3809aaa-3219-4b9a-b86e-7850a747f652)
> 
> instead of
> 
> ![Windows 10 - red square item selected](https://github.com/user-attachments/assets/343adf20-b3ca-4c06-af93-e63736bce123)
> 
> It is the former image that corresponds to File Explorer in Windows 11: https://github.com/openjdk/jdk/pull/23324#discussion_r1935744523

But that's what I believe is been done now in the PR test, corresponding to your 1st image and corresponds to windows11

![image](https://github.com/user-attachments/assets/2ddab37a-0513-4e08-8df9-9a3a2a054b8b)

If icon is present, it will be drawn at x+3*OFFSET...and button/checkmark is always drawn at x-OFFSET irrespective of icon
 present or not..
Are you suggesting to keep more gap in between checkmark and button?

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

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

From aivanov at openjdk.org  Tue Feb  4 12:27:17 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 12:27:17 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <U0nr1mSssHPg6vffBpb5s-23tmG8aWipfshWBblcG1o=.63740827-489f-46bd-9304-12e807e612e1@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
 <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
 <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>
 <yRj0FD8SfxIpkdPaF0yKcatAzH4zNL_rTu8Hj83fFzs=.bc1b549a-630d-4489-8760-a3fb72c1b6fe@github.com>
 <U0nr1mSssHPg6vffBpb5s-23tmG8aWipfshWBblcG1o=.63740827-489f-46bd-9304-12e807e612e1@github.com>
Message-ID: <jg_oOP8j7X6G6_DMbBpezUVchs51obNnnNbp5cRKs_U=.77e5677c-9b7b-4c3f-9ff2-e97b12732989@github.com>

On Tue, 4 Feb 2025 11:39:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> But that's what I believe is been done now in the PR test, corresponding to your 1st image and corresponds to windows11

No, it doesn't.

On Windows 10 which has a selected background around the bullet, it looks completely off.

![radio-menuitem-with-icon-01-2025-02-04](https://github.com/user-attachments/assets/6a0dd6b6-c611-4fc7-9f25-5125c539fa5b)

![radio-menuitem-with-icon-02-2025-02-04](https://github.com/user-attachments/assets/1e5a7540-d74e-4a5a-b338-2f04a5076c9d)

[The original behaviour](https://github.com/openjdk/jdk/pull/23324#issuecomment-2624726843) was consistent at least.

Yet what the currently proposed fix produces doesn't look right at all.

The bullet or check-mark should remain centered in their own place as if there's no icon.

> Are you suggesting to keep more gap in between checkmark and button?

Yes, but not only.

If there's an icon, it should move the text to the right to accommodate the additional icon, if we're going this route.

In addition to that, the text in all other menu items should move to the right for consistency so that all the menu items are aligned and items without an icon render an empty icon in this case.

We may introduce a property that controls this behaviour: whether the text aligns in all the menu items or not.

The first option corresponds to this layout:  
![Proposed layout - aligned text](https://github.com/user-attachments/assets/60ef0c8c-544c-44fd-8e7a-a0a52254f9b6)  
where all the text moves right to add space for menu icons. This corresponds to menu layout in File Explorer in Windows 11.

The second option corresponds to this layout:  
![Proposed layout - unaligned text](https://github.com/user-attachments/assets/7ee4a124-ed16-4606-b325-d9dafc96d4d8)  
where the second menu item remains at the position where it's rendered now.

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

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

From abhiscxk at openjdk.org  Tue Feb  4 12:51:12 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 4 Feb 2025 12:51:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
Message-ID: <uP1Shw60WlurOcJgFXvbZP-FQI7KsnnizbBJvFgm5hE=.020f286c-e0ee-4e8a-ba33-b434d0f96b74@github.com>

On Thu, 30 Jan 2025 15:47:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Draw checkmark skin at same location with/without icon

> I believe this is likely how layout is calculated.

I just wanted to know "why 3 is chosen as a magic number ?". Actually the spacing with "4 * OFFSET" looks better between radio, icon and text of menu item (on win 11).

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2633809263

From mbaesken at openjdk.org  Tue Feb  4 13:03:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Feb 2025 13:03:16 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
Message-ID: <-kZPpbSMZCv-L-CMAo4QIXSwkN1CcLey9vIzhyXU1qU=.4ca08f32-306d-4881-ba6c-f725abdba09f@github.com>

On Mon, 3 Feb 2025 18:50:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset updates the pipewire headers to the latest available version.
> It contains the minimum set of required header files needed to build the JDK.
> 
> The updated headers are a direct copy from the 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
>  
> Testing looks good.

Thanks for reaching out !  The PR with the small change above to raw.h added ,  compiles on AIX  (opt build tested).

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

PR Comment: https://git.openjdk.org/jdk/pull/23426#issuecomment-2633838002

From psadhukhan at openjdk.org  Tue Feb  4 13:18:30 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Feb 2025 13:18:30 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v7]
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: <5o66767aHMJOSTAcPZlPVffi-Z5jMU6kXTLbJd_VSLw=.d2e22740-4a14-451d-8677-c71a536afc4b@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:

  Move icon w.r.t bullet skin width

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/9482b261..6a9f914b

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

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

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

From psadhukhan at openjdk.org  Tue Feb  4 13:18:30 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Feb 2025 13:18:30 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <jg_oOP8j7X6G6_DMbBpezUVchs51obNnnNbp5cRKs_U=.77e5677c-9b7b-4c3f-9ff2-e97b12732989@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
 <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
 <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>
 <yRj0FD8SfxIpkdPaF0yKcatAzH4zNL_rTu8Hj83fFzs=.bc1b549a-630d-4489-8760-a3fb72c1b6fe@github.com>
 <U0nr1mSssHPg6vffBpb5s-23tmG8aWipfshWBblcG1o=.63740827-489f-46bd-9304-12e807e612e1@github.com>
 <jg_oOP8j7X6G6_DMbBpezUVchs51obNnnNbp5cRKs_U=.77e5677c-9b7b-4c3f-9ff2-e97b12732989@github.com>
Message-ID: <1pvJwX2-55YbMOo3TkSR62d7kfGBYRvs_M-B6lEOJkY=.5351ed3e-8c51-4afe-a49c-e929d340b68c@github.com>

On Tue, 4 Feb 2025 12:24:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> But that's what I believe is been done now in the PR test, corresponding to your 1st image and corresponds to windows11
>> 
>> ![image](https://github.com/user-attachments/assets/2ddab37a-0513-4e08-8df9-9a3a2a054b8b)
>> 
>> If icon is present, it will be drawn at x+3*OFFSET...and button/checkmark is always drawn at x-OFFSET irrespective of icon
>>  present or not..
>> Are you suggesting to keep more gap in between checkmark and button?
>
>> But that's what I believe is been done now in the PR test, corresponding to your 1st image and corresponds to windows11
> 
> No, it doesn't.
> 
> On Windows 10 which has a selected background around the bullet, it looks completely off.
> 
> ![radio-menuitem-with-icon-01-2025-02-04](https://github.com/user-attachments/assets/6a0dd6b6-c611-4fc7-9f25-5125c539fa5b)
> 
> ![radio-menuitem-with-icon-02-2025-02-04](https://github.com/user-attachments/assets/1e5a7540-d74e-4a5a-b338-2f04a5076c9d)
> 
> [The original behaviour](https://github.com/openjdk/jdk/pull/23324#issuecomment-2624726843) was consistent at least.
> 
> Yet what the currently proposed fix produces doesn't look right at all.
> 
> The bullet or check-mark should remain centered in their own place as if there's no icon.
> 
>> Are you suggesting to keep more gap in between checkmark and button?
> 
> Yes, but not only.
> 
> If there's an icon, it should move the text to the right to accommodate the additional icon, if we're going this route.
> 
> In addition to that, the text in all other menu items should move to the right for consistency so that all the menu items are aligned and items without an icon render an empty icon in this case.
> 
> We may introduce a property that controls this behaviour: whether the text aligns in all the menu items or not.
> 
> The first option corresponds to this layout:  
> ![Proposed layout - aligned text](https://github.com/user-attachments/assets/60ef0c8c-544c-44fd-8e7a-a0a52254f9b6)  
> where all the text moves right to add space for menu icons. This corresponds to menu layout in File Explorer in Windows 11.
> 
> The second option corresponds to this layout:  
> ![Proposed layout - unaligned text](https://github.com/user-attachments/assets/7ee4a124-ed16-4606-b325-d9dafc96d4d8)  
> where the second menu item remains at the position where it's rendered now.

I have modified the PR to move the icon w.r.t bullet skin width and it looks like this in windows 11..I believe this should work for windows 10 also but I dont have windows10 to check

![image](https://github.com/user-attachments/assets/953eee76-ee88-4189-9ed8-681854c27363)


I dont think we can tamper with text location as it is done in WindowsMenuItemUI#paintText which does not have any knowledge of bullet/icon presence.
Also, ideally I dont think this should be applicable for windows10 and we should do this only for windows11 but I am not sure if there is version check in our code and anyway, windows10 would be EOL-ed and unsupported platform in few months

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

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

From asemenov at openjdk.org  Tue Feb  4 13:27:11 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 4 Feb 2025 13:27:11 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <_rzTmuf18BbVT2o2XdK1P3qiTAQji19Udqet4AMgzPs=.a488bdba-38b6-4d14-96c8-a9e15f8758dc@github.com>

On Tue, 4 Feb 2025 10:58:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 186:

> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
> 185:                         if ((newValue != null && !newValue.equals(oldValue)) ||
> 186:                                 oldValue != null && !oldValue.equals(newValue)) {

At first glance, these conditions look like the same thing. equals() above will return false if oldValue is null. oldValue.equals(newValue) and newValue.equals(oldValue) are also the same thing. Try to rewrite this condition more clearly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1941160719

From psadhukhan at openjdk.org  Tue Feb  4 13:36:34 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Feb 2025 13:36:34 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v8]
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: <jGnmJg5iaPu2QbzQN6etiha1uyR8HkGc9s8euxfm52c=.fa169c74-8d38-4ab7-abdc-850574ad78a4@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 two additional commits since the last revision:

 - remove debug
 - Move icon w.r.t bullet skin width

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/6a9f914b..d5a252b5

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

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

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

From psadhukhan at openjdk.org  Tue Feb  4 14:16:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 4 Feb 2025 14:16:16 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v9]
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: <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@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:

  retain diff of OFFSET between skin background start coord and skin coordinate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/d5a252b5..31cdc707

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

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

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

From rmarchenko at openjdk.org  Tue Feb  4 16:18:47 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 4 Feb 2025 16:18:47 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
Message-ID: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>

Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.

Also fixed the test, and added the approptiate test case.

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/23443/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347826
  Stats: 118 lines in 2 files changed: 64 ins; 6 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

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

From aivanov at openjdk.org  Tue Feb  4 16:24:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 16:24:12 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>

On Tue, 4 Feb 2025 10:58:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 186:

> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
> 185:                         if ((newValue != null && !newValue.equals(oldValue)) ||
> 186:                                 oldValue != null && !oldValue.equals(newValue)) {

Suggestion:

                        if (!Objects.equals(newValue, oldValue)) {

This handles all the cases, including `null` values.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 212:

> 210:                     // Do send toggle button state changes to native side
> 211:                     if (thisRole == AccessibleRole.TOGGLE_BUTTON) {
> 212:                         if ((newValue != null && !newValue.equals(oldValue)) ||

I believe the new condition should be used for `RADIO_BUTTON` too:

https://github.com/openjdk/jdk/blob/b985347c2383a7a637ffa9a4a8687f7f7cde1369/src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java#L197-L200

test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 34:

> 32: /*
> 33:  * @test
> 34:  * @bug 8348936

Suggestion:

 * @bug 8348936 8345728

Two bugs are fixed by one changeset, and your summary implies either issue is tested by this single test.

test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 58:

> 56:                 7. Press Tab to move focus to ToggleButton
> 57:                 8. Repeat steps 3 to 6 and listen the announcement
> 58:                 9. If announcements are incorrect, Press Fail

Suggestion:

                9. If announcements are incorrect, press Fail

test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 87:

> 85: 
> 86:                 Press Pass if you are able to hear correct VoiceOver announcements and
> 87:                 able to see the correct screen magnifier behaviour. """;

These long instructions may benefit from using HTML for formatting instructions.

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

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2593380133
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1941484674
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1941487923
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1941492200
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1941493443
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1941495810

From rmarchenko at openjdk.org  Tue Feb  4 16:25:25 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 4 Feb 2025 16:25:25 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v2]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <IYvuhPMqlCLj3LISLpwvK8xUrw1dLjU3bf9xzSk7xvc=.bebb0e76-f018-45a8-8965-0ecf52cff347@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also fixed the test, and added the approptiate test case.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  test refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/605ec5a5..3cea2bb2

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

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

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

From rmarchenko at openjdk.org  Tue Feb  4 16:28:51 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 4 Feb 2025 16:28:51 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v3]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <FZ6PhsDebL8OhJhypoLBvNPuiuiZqZB2fIePOqFICk4=.63dc2d16-e7bd-485b-8c82-22e3d7ad11e0@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also fixed the test, and added the approptiate test case.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  minor test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/3cea2bb2..a913b86b

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

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

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

From dgredler at openjdk.org  Tue Feb  4 16:25:16 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 4 Feb 2025 16:25:16 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout
In-Reply-To: <ZpjSNvg_SQI1hfdlWHhNPR2EZMu4a-6PfTnKIsyUHkI=.835a79ad-6846-43f8-8bef-78ff0d6324a2@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <ZpjSNvg_SQI1hfdlWHhNPR2EZMu4a-6PfTnKIsyUHkI=.835a79ad-6846-43f8-8bef-78ff0d6324a2@github.com>
Message-ID: <XwkMZeUQ5cx5CTy1Fosh3X23r1-RQjme3h_Sh_6JkhE=.d0b3d0b7-7ae6-4abd-8d35-31ca37207bde@github.com>

On Wed, 18 Dec 2024 21:05:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Soft hyphens should never render, regardless of the rendering path used internally.
>> 
>> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
>> 
>> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
>> 
>> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.
>
> Here's the full error if it helps you debug
> 
> java.lang.RuntimeException: stringWidth for char 00ad using font Dialog: 101 != 333
> 	at FormatCharAdvanceTest.assertEqual(FormatCharAdvanceTest.java:209)
> 	at FormatCharAdvanceTest.testChar(FormatCharAdvanceTest.java:124)
> 	at FormatCharAdvanceTest.testChars(FormatCharAdvanceTest.java:94)
> 	at FormatCharAdvanceTest.main(FormatCharAdvanceTest.java:83)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1576)

@alisenchung Would you have time to finish your review this week?

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

PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2634465184

From vdyakov at openjdk.org  Tue Feb  4 17:19:17 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Tue, 4 Feb 2025 17:19:17 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <m7ztzwgYUkwfRTj7Muam39zNyNZrOKqBGevHzT1p3yE=.6244b27e-3144-450b-a0bc-f40673b90ab2@github.com>

On Tue, 4 Feb 2025 10:58:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

@azuev-java please review

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

PR Comment: https://git.openjdk.org/jdk/pull/23436#issuecomment-2634593432

From aivanov at openjdk.org  Tue Feb  4 17:59:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 17:59:11 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <FLJrOQzW0Fs4EiMY9qFRoe0ubarEXo74K-07uiQaYqI=.9343aec2-d7e7-45b4-94bf-b5b845c60009@github.com>

On Tue, 4 Feb 2025 00:07:48 GMT, anass baya <duke at openjdk.org> wrote:

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

@anass-baya If your fix is based on @mickleness's previous PR, you should him as co-author using the [`/contributor`](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/contributor) command.

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

PR Comment: https://git.openjdk.org/jdk/pull/23430#issuecomment-2634683856

From aivanov at openjdk.org  Tue Feb  4 18:22:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 18:22:29 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <OWtUl5AdJULXFlOGiEsUnuYgW2bLNfabOEZCNS7jkfw=.51af3f99-3ea0-4ee4-ac69-51f75f108159@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
 <OWtUl5AdJULXFlOGiEsUnuYgW2bLNfabOEZCNS7jkfw=.51af3f99-3ea0-4ee4-ac69-51f75f108159@github.com>
Message-ID: <D0BryChOwJJFN5InLRvMgetUNaH10RPdzAgH6dMpdpA=.dd21867a-c57e-480c-9fd8-bb45298222eb@github.com>

On Thu, 9 May 2024 19:27:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Changes seem fine, but I would like to hear how this was tested ?

@prrace Renjith and I went over all the cases. We tried to move the cases where no action is needed to the top of the method.

> And if there is a specific test that exists for this, or why one could not be created.

Both of us ran the client tests.

I'm unaware of any test in the OpenJDK which tests this functionality? It's hard to test reliably, especially the asynchronous cases? However, it may still be possible to test some scenarios?

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

PR Comment: https://git.openjdk.org/jdk/pull/18670#issuecomment-2634734034

From aivanov at openjdk.org  Tue Feb  4 21:53:24 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 21:53:24 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <wIdU3BuBDzceHeKM5OBGbf4TcMZeLMSaWFV0nv8YhRg=.5b0c917f-b1ba-4bfe-9615-9254d2d1e17b@github.com>

On Tue, 4 Feb 2025 00:07:48 GMT, anass baya <duke at openjdk.org> wrote:

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

@mickleness I wonder what is your preferred email address and name. You were referenced by another email in [your recent contribution](https://bugs.openjdk.org/browse/JDK-8342782?focusedId=14733170&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14733170).

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

PR Comment: https://git.openjdk.org/jdk/pull/23430#issuecomment-2635153763

From aivanov at openjdk.org  Tue Feb  4 22:25:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 4 Feb 2025 22:25:19 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <D0BryChOwJJFN5InLRvMgetUNaH10RPdzAgH6dMpdpA=.dd21867a-c57e-480c-9fd8-bb45298222eb@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
 <OWtUl5AdJULXFlOGiEsUnuYgW2bLNfabOEZCNS7jkfw=.51af3f99-3ea0-4ee4-ac69-51f75f108159@github.com>
 <D0BryChOwJJFN5InLRvMgetUNaH10RPdzAgH6dMpdpA=.dd21867a-c57e-480c-9fd8-bb45298222eb@github.com>
Message-ID: <ilp7HmxyvgtadYXakrwtzJERTOE79TSC3zrVjFMXmfw=.6a0d620e-9cfb-4b2c-8aa2-64bbe1ea5bf4@github.com>

On Tue, 4 Feb 2025 18:19:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Both of us ran the client tests.

I might misremember things?

Yet I see test failures with the proposed changeset.

**The PR should not be *sponsored***.

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

PR Comment: https://git.openjdk.org/jdk/pull/18670#issuecomment-2635202834

From dnguyen at openjdk.org  Tue Feb  4 23:40:25 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 4 Feb 2025 23:40:25 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if switch
 to another window and return back
Message-ID: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>

Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.

Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.

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

Commit messages:
 - Initial commit
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Initial commit for backout

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

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

From psadhukhan at openjdk.org  Wed Feb  5 02:36:20 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Feb 2025 02:36:20 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <uP1Shw60WlurOcJgFXvbZP-FQI7KsnnizbBJvFgm5hE=.020f286c-e0ee-4e8a-ba33-b434d0f96b74@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <uP1Shw60WlurOcJgFXvbZP-FQI7KsnnizbBJvFgm5hE=.020f286c-e0ee-4e8a-ba33-b434d0f96b74@github.com>
Message-ID: <1hZSBQD8EjnGgiQ2sIBICVZr5iyDEnRsm75dXN0BMXs=.8f96de88-f434-4c04-bccc-bacb3f006e57@github.com>

On Tue, 4 Feb 2025 12:48:10 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > I believe this is likely how layout is calculated.
> 
> I just wanted to know "why 3 is chosen as a magic number ?". Actually the spacing with "4 * OFFSET" looks better between radio, icon and text of menu item (on win 11).

I guess this is now taken care of in latest PR..

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2635568007

From abhiscxk at openjdk.org  Wed Feb  5 06:17:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 06:17:10 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
In-Reply-To: <_rzTmuf18BbVT2o2XdK1P3qiTAQji19Udqet4AMgzPs=.a488bdba-38b6-4d14-96c8-a9e15f8758dc@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <_rzTmuf18BbVT2o2XdK1P3qiTAQji19Udqet4AMgzPs=.a488bdba-38b6-4d14-96c8-a9e15f8758dc@github.com>
Message-ID: <jrHTBeYGn4D38tNazOmKrIeqYoRlgf0pFiGYnIoKIwk=.c75730f9-ce27-46e3-bbca-0c6be82c73f3@github.com>

On Tue, 4 Feb 2025 13:24:29 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 186:
> 
>> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
>> 185:                         if ((newValue != null && !newValue.equals(oldValue)) ||
>> 186:                                 oldValue != null && !oldValue.equals(newValue)) {
> 
> At first glance, these conditions look like the same thing. equals() above will return false if oldValue is null. oldValue.equals(newValue) and newValue.equals(oldValue) are also the same thing. Try to rewrite this condition more clearly.

When CheckBox state is `checked`, `newValue is Checked` and `oldValue is null` and the existing condition `if (newValue != null && !newValue.equals(oldValue))` works well. But when CheckBox is `unchecked`, `newValue is null` and `oldValue is checked`, the existing condition returns `false` when `newValue != null` is evaluated.

oldValue.equals(newValue) and newValue.equals(oldValue) looks same but when newValue is null, newValue.equals(oldValue) throws NPE.

So, I think these conditions are not exactly same. We need to evaluate the `oldValue!=null` when CheckBox is unchecked for the correct behaviour.

@aivanov-jdk suggested simpler way for comparing oldValue and newValue [here](https://github.com/openjdk/jdk/pull/23436#discussion_r1941484674). I will check and update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942299553

From kizune at openjdk.org  Wed Feb  5 06:21:19 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Feb 2025 06:21:19 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <gFpMtHEw1YWk7h9oSJw4Uyr_y1uvdwyWRazJeQLUeHI=.53dbcf90-85ae-47f7-a26f-cdf217351df6@github.com>

On Tue, 4 Feb 2025 10:58:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

Looks good functionally.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2594725017

From abhiscxk at openjdk.org  Wed Feb  5 06:47:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 06:47:10 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
In-Reply-To: <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
Message-ID: <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>

On Tue, 4 Feb 2025 16:15:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 212:
> 
>> 210:                     // Do send toggle button state changes to native side
>> 211:                     if (thisRole == AccessibleRole.TOGGLE_BUTTON) {
>> 212:                         if ((newValue != null && !newValue.equals(oldValue)) ||
> 
> I believe the new condition should be used for `RADIO_BUTTON` too:
> 
> https://github.com/openjdk/jdk/blob/b985347c2383a7a637ffa9a4a8687f7f7cde1369/src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java#L197-L200

RadioButtons are mostly used in a group out of which only one can be selected at a time and the selected state is well notified to VO. When another RadioButton is selected from the group, previously selected RadioButton is de-selected and currently selected RadioButton's value is notified to VO.

Don't think RadioButton can be used stand-alone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942325127

From abhiscxk at openjdk.org  Wed Feb  5 07:04:21 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 07:04:21 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <buKqa4XiBlKH0Lhdw0W6ZKl3LQgltuDKVXHBxVwjLkw=.50ea17bf-322c-4d36-9d65-be01c15c9d4e@github.com>

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

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

  Condition evaluation simplified

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23436/files
  - new: https://git.openjdk.org/jdk/pull/23436/files/ca0d758c..1bfa6d98

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

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

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

From abhiscxk at openjdk.org  Wed Feb  5 07:16:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 07:16:10 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
Message-ID: <VNswYI2VrEXJAJsDFuiOKIutMFNPFfbgJkrCbr4BGkU=.1f482016-cf75-4a21-aefb-3b3933e013e0@github.com>

On Tue, 4 Feb 2025 16:20:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Condition evaluation simplified
>
> test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 87:
> 
>> 85: 
>> 86:                 Press Pass if you are able to hear correct VoiceOver announcements and
>> 87:                 able to see the correct screen magnifier behaviour. """;
> 
> These long instructions may benefit from using HTML for formatting instructions.

Are you suggesting to change entire instruction set with HTML formatting ?

I would appreciate if you add some sample changes. you are referring

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942351309

From psadhukhan at openjdk.org  Wed Feb  5 07:42:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Feb 2025 07:42:13 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <1fjzUR1RxWAEpbja0uaJmAeSZgln-UQsZ4ESiBUL7Gc=.8e307676-4331-4336-bf37-8968b7db3ed2@github.com>

On Tue, 4 Feb 2025 23:35:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1625:

> 1623:                     scrollbar.setValueIsAdjusting(false);
> 1624:                     return;
> 1625:                 }

Can't it be merged with below frame disable logic as it does the same thing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1942377136

From asemenov at openjdk.org  Wed Feb  5 08:13:18 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 5 Feb 2025 08:13:18 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <buKqa4XiBlKH0Lhdw0W6ZKl3LQgltuDKVXHBxVwjLkw=.50ea17bf-322c-4d36-9d65-be01c15c9d4e@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <buKqa4XiBlKH0Lhdw0W6ZKl3LQgltuDKVXHBxVwjLkw=.50ea17bf-322c-4d36-9d65-be01c15c9d4e@github.com>
Message-ID: <H5qELEhV--JHxb_TxhS-kiaGH0rkdXkBz-3TRto0qg0=.c376b1ce-9a67-48ed-8b3e-7cbca5698b79@github.com>

On Wed, 5 Feb 2025 07:04:21 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Condition evaluation simplified

LGTM

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

Marked as reviewed by asemenov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2594910443

From tr at openjdk.org  Wed Feb  5 11:03:10 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 5 Feb 2025 11:03:10 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
Message-ID: <6R8PSgxD-Hoh7f_0bKvVYGbdt2OFDe7uta9ro-CcbrE=.c92f7926-62b0-47dc-811c-9f933b2d0f42@github.com>

On Fri, 31 Jan 2025 20:40:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows.
>> 
>> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely.
>> 
>> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails.
>> 
>> The updated test passes in the CI.
>
> Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update the test summary
>  - Remove the redundant button

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23336#pullrequestreview-2595331966

From aivanov at openjdk.org  Wed Feb  5 11:37:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Feb 2025 11:37:11 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <_rzTmuf18BbVT2o2XdK1P3qiTAQji19Udqet4AMgzPs=.a488bdba-38b6-4d14-96c8-a9e15f8758dc@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <_rzTmuf18BbVT2o2XdK1P3qiTAQji19Udqet4AMgzPs=.a488bdba-38b6-4d14-96c8-a9e15f8758dc@github.com>
Message-ID: <wOqQqHvbAWFrpJ-ZkL5sv_1y6PJJNYeZ_hBPinlC7pA=.c5fa0b9c-72d0-4b94-a5c2-bcfa03604441@github.com>

On Tue, 4 Feb 2025 13:24:29 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Condition evaluation simplified
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 186:
> 
>> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
>> 185:                         if ((newValue != null && !newValue.equals(oldValue)) ||
>> 186:                                 oldValue != null && !oldValue.equals(newValue)) {
> 
> At first glance, these conditions look like the same thing. equals() above will return false if oldValue is null. oldValue.equals(newValue) and newValue.equals(oldValue) are also the same thing. Try to rewrite this condition more clearly.

I think @savoptik meant that `!oldValue.equals(newValue)` was redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942708541

From aivanov at openjdk.org  Wed Feb  5 11:43:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Feb 2025 11:43:11 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <buKqa4XiBlKH0Lhdw0W6ZKl3LQgltuDKVXHBxVwjLkw=.50ea17bf-322c-4d36-9d65-be01c15c9d4e@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <buKqa4XiBlKH0Lhdw0W6ZKl3LQgltuDKVXHBxVwjLkw=.50ea17bf-322c-4d36-9d65-be01c15c9d4e@github.com>
Message-ID: <JUoGMUeXp8O2MMyzzLQMERvCCN2OOKPD5VU1K-xhYKc=.b13d8a03-9199-4d00-a87c-d9ae5961b89d@github.com>

On Wed, 5 Feb 2025 07:04:21 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Condition evaluation simplified

I [insist](https://github.com/openjdk/jdk/pull/23436#discussion_r1942712616) on changing the condition for radio buttons, too.

Other than that, it looks good to me.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2595421026

From abhiscxk at openjdk.org  Wed Feb  5 11:43:12 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 11:43:12 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <wOqQqHvbAWFrpJ-ZkL5sv_1y6PJJNYeZ_hBPinlC7pA=.c5fa0b9c-72d0-4b94-a5c2-bcfa03604441@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <_rzTmuf18BbVT2o2XdK1P3qiTAQji19Udqet4AMgzPs=.a488bdba-38b6-4d14-96c8-a9e15f8758dc@github.com>
 <wOqQqHvbAWFrpJ-ZkL5sv_1y6PJJNYeZ_hBPinlC7pA=.c5fa0b9c-72d0-4b94-a5c2-bcfa03604441@github.com>
Message-ID: <zTZCZjvzPQ4VAoIFfT4j5Pg9QKIgz5jV4C4uobayXzM=.f3403c01-21da-4a03-8520-67b2e657ebb3@github.com>

On Wed, 5 Feb 2025 11:34:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java line 186:
>> 
>>> 184:                     if (thisRole == AccessibleRole.CHECK_BOX) {
>>> 185:                         if ((newValue != null && !newValue.equals(oldValue)) ||
>>> 186:                                 oldValue != null && !oldValue.equals(newValue)) {
>> 
>> At first glance, these conditions look like the same thing. equals() above will return false if oldValue is null. oldValue.equals(newValue) and newValue.equals(oldValue) are also the same thing. Try to rewrite this condition more clearly.
>
> I think @savoptik meant that `!oldValue.equals(newValue)` was redundant.

Yes,` oldValue.equals(newValue)` or `newValue.equals(oldValue)` always return same value. But when `newValue` was null, I couldn't use `newValue.equals(oldValue)` as it throws NPE. Anyway, the condition is simplified now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942715423

From aivanov at openjdk.org  Wed Feb  5 11:43:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Feb 2025 11:43:13 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
Message-ID: <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>

On Wed, 5 Feb 2025 06:44:45 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Don't think RadioButton can be used stand-alone.

Nothing stops you from doing so?

I still think the condition in the radio button case should be the same: `Object.equals` handles all the cases, and the code becomes *consistent*. Otherwise, the radio button stands out? for no apparent reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942712616

From abhiscxk at openjdk.org  Wed Feb  5 11:46:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 11:46:10 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
Message-ID: <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>

On Wed, 5 Feb 2025 11:38:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Nothing stops you from doing so? 
I agree but I have never seen any application which is having a single RadioButton for selection.

> I still think the condition in the radio button case should be the same: Object.equals handles all the cases, and the code becomes consistent. Otherwise, the radio button stands out? for no apparent reason.

For consistency, it can be done. I need to check if it impacts on VO announcement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942719542

From aivanov at openjdk.org  Wed Feb  5 11:53:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Feb 2025 11:53:11 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
Message-ID: <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>

On Wed, 5 Feb 2025 11:43:18 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> For consistency, it can be done. I need to check if it impacts on VO announcement.

It shouldn't impact the announcements. One button gets deselected, another one gets selected?

Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when selection moves to another button.

What about the case where currently focused or unfocused selected button gets deselected programmatically? Is there an interactive way to deselect a radio button when it's the only button in its own group?

This *needs more testing*.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942729376

From aivanov at openjdk.org  Wed Feb  5 11:54:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Feb 2025 11:54:11 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <Sj4f4iDnR9UBwinX_FeSbV4H4tbE8bCpYYQ_70GvD-A=.0f23dcca-4acd-4128-b321-b7a61b4e307e@github.com>
Message-ID: <1PTP-hcscFZaQPm94zqWIZJ_UTQ35HQSSCzRWfVp05o=.56d9e317-5c8c-48a4-b1e7-cc5417dfbfec@github.com>

On Fri, 31 Jan 2025 20:40:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows.
>> 
>> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely.
>> 
>> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails.
>> 
>> The updated test passes in the CI.
>
> Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update the test summary
>  - Remove the redundant button

@mrserb Any other comments?

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

PR Comment: https://git.openjdk.org/jdk/pull/23336#issuecomment-2636516796

From aivanov at openjdk.org  Wed Feb  5 12:21:24 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 5 Feb 2025 12:21:24 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
Message-ID: <S9dCdr9PFuQ5fKA1LUPECSnBV3o6JNjwkgmzN-fmN-o=.e4fecad8-a404-4580-875b-d0f8a5b3a937@github.com>

On Fri, 19 Apr 2024 14:53:09 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearranged if based on suggesion

There are lots of failures with the message: _java.lang.NullPointerException: Cannot invoke "java.net.URL.getProtocol()" because "u2" is null_

For example, the `javax/swing/JEditorPane/4492274/bug4492274.java` test fails with the following stack traces:


----------System.err:(32/2233)----------
java.lang.reflect.InvocationTargetException
	at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1312)
	at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1287)
	at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1474)
	at bug4492274.main(bug4492274.java:50)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)
Caused by: java.lang.RuntimeException: java.lang.NullPointerException: Cannot invoke "java.net.URL.getProtocol()" because "u2" is null
	at bug4492274.createAndShowGUI(bug4492274.java:113)
	at bug4492274$1.run(bug4492274.java:53)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at ?
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.NullPointerException: Cannot invoke "java.net.URL.getProtocol()" because "u2" is null
	at java.base/java.net.URLStreamHandler.sameFile(URLStreamHandler.java:413)
	at java.base/java.net.URL.sameFile(URL.java:1123)
	at java.desktop/javax.swing.JEditorPane.setPage(JEditorPane.java:478)
	at bug4492274.createAndShowGUI(bug4492274.java:104)
	... 10 more

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 480:

> 478:         final String reference = page.getRef();
> 479: 
> 480:         if ((postData == null) && page.sameFile(loaded)) {

This line of code causes lots of test failures because `page.sameFile(loaded)` doesn't accept a `null` parameter, which results in `NullPointerException`.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18670#pullrequestreview-2595528235
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1942776674

From abhiscxk at openjdk.org  Wed Feb  5 12:55:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 12:55:10 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
Message-ID: <maS431czqxziC6XO3fQIrirhyXAamnI5Ug5pZn9g1IM=.2aad1e09-eefe-43c6-879b-7baaf39e9cd4@github.com>

On Wed, 5 Feb 2025 11:50:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It shouldn't impact the announcements. One button gets deselected, another one gets selected?

 >Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when > selection moves to another button.

I checked with the changes you suggested for RadioButton and that impacts the announcement. Checked with Swingset2 application and VO announce the RadioButtons incorrect.

No such issue with existing condition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942892163

From duke at openjdk.org  Wed Feb  5 13:10:04 2025
From: duke at openjdk.org (anass baya)
Date: Wed, 5 Feb 2025 13:10:04 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v2]
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <f-y2AiJoFXTV8nyN6bBNmiluBKSc1VSimX6Z_NO7L9A=.989aa119-1db6-44e3-a947-5f89a0d98584@github.com>

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

anass baya has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unnecessary comment
 - Update Copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23430/files
  - new: https://git.openjdk.org/jdk/pull/23430/files/9cf273bf..e65d7344

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

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

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

From mbaesken at openjdk.org  Wed Feb  5 13:47:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Feb 2025 13:47:16 GMT
Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST
In-Reply-To: <C2jji5UHIc98vnELhGJm2JnRniwR86Z72UFlHKXyW1c=.ebf7130b-b2ed-463e-a4c1-25d18e3a207b@github.com>
References: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
 <C2jji5UHIc98vnELhGJm2JnRniwR86Z72UFlHKXyW1c=.ebf7130b-b2ed-463e-a4c1-25d18e3a207b@github.com>
Message-ID: <9EBd4_uzR14Jk6dLeU0EcvLaDXZRTqGj5X9L96ajSyc=.d65857d8-bd69-46a2-b1d0-c577df8525c9@github.com>

On Wed, 29 Jan 2025 23:25:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>  (hint: Use e.g. make java.desktop-libs-only JOBS=1 LOG=info to get a build speed number that you can compare across compiler flag changes)

That does not work/compile,  it leads to 


make java.desktop-libs-only JOBS=1 LOG=info
Generating main target list
Running make as 'make JOBS=1 LOG=info java.desktop-libs-only'
Building target 'java.desktop-libs-only' in configuration '/myjdk'
Creating support/modules_libs/java.desktop/libawt.so from 72 file(s)
Compiling AlphaMacros.c (for libawt.so)
In file included from /myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/AlphaMacros.h:29,
                 from /myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/AlphaMacros.c:26:
/myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h:36:10: fatal error: java_awt_AlphaComposite.h: No such file or directory


Seems the dependencies do not work for some reason, so I need to build  the whole jdk with LOG=info I guess.

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

PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2636895021

From duke at openjdk.org  Wed Feb  5 13:50:27 2025
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Wed, 5 Feb 2025 13:50:27 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v12]
In-Reply-To: <mnQda0YPGQO7lBRppDk7K1vCq0smOOYBZjVUc3T0aAY=.f91a8246-9db8-4484-b7c1-7cbcb4883687@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <mnQda0YPGQO7lBRppDk7K1vCq0smOOYBZjVUc3T0aAY=.f91a8246-9db8-4484-b7c1-7cbcb4883687@github.com>
Message-ID: <k2dDL0cvUc8Oeg60gqSJvWgEIWzvbQQdeVNZgvWiZ5g=.cb9f55c2-68e4-4f13-9f98-e8be0232c781@github.com>

On Thu, 12 Dec 2024 00:05:33 GMT, ??? <duke at openjdk.org> wrote:

>> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem.
>> 
>> 1, I wrote a example for linux:
>> https://github.com/quantum6/X11InputMethod
>> 
>> I tried all parameters to test and as my research:
>> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret.
>> If you use XIMPreeditNothing, it works.
>> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes.
>> 
>> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux.
>> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK.
>> 4, I am not sure for AIX( no environment).
>> 
>> 
>> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea
>> Type: Bug
>> Component: client-libs
>> Sub-Component: java.awt:i18n
>> Affected Version: 8,9,15,16
>> Priority: P3
>> Status: Open
>> Resolution: Unresolved
>> OS: linux
>> CPU: x86_64
>
> ??? 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 11 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Update to lastest
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Remove tab
>  - Update to latest and make code safer
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/0d3eac6e...0ab7a467

> A few another issues with the current patch:
> 
> * On KDE the preedit popup isn't positioned correctly. Most likely this is because HiDPI settings aren't taken into account - I observed the issue with 200% scale set (the used IM engine is _iBus_) ;
> * Preedit text doesn't get discarded when a mouse click happens in a different place _of the same component_, e.g. in a multi-lined `JTextArea` ;
> * The preedit popup isn't moved when the focused component is scrolled .
> 
> Also please don't forget to take a look at my question in [#13055 (comment)](https://github.com/openjdk/jdk/pull/13055#issuecomment-2100914601)

I am back. This is my work result:
1, I study many codes of libX11 input method, all of them can't work correctly. So, it is a bug on libX11.
2, I research libX11, 1.8.2 fixed this bug.
commit 62c3337d89d31e0d3ed807004e73ad711fad3342
Author: Kirill Chibisov <contact at kchibisov.com>
Date:   Thu Sep 8 22:50:30 2022 +0000
    ximcp/imRm.c: allow XNSpotLocation with OnTheSpot
3, I tried to ask ubuntu to update libX11, I can't login to edit. I really don't know why.
https://help.ubuntu.com/community/ReportingBugs

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

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2636902575

From duke at openjdk.org  Wed Feb  5 13:50:28 2025
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Wed, 5 Feb 2025 13:50:28 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v11]
In-Reply-To: <h0l4-wgUqkVePjmlgrpMuiAALhI2ynOyIH2MqqN-ohQ=.6c1587e5-6774-47e9-9024-0e997cc81d38@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com>
 <YpFR6w4_p-uw1YX5cND44LQLHLDK5TlJa6dmGRnaaI4=.779fae80-8d1a-4bc7-9f86-3b6b0d26d802@github.com>
 <3cK_SZBr0b9GYvwoJp0vKDX_jSVmeekAJsYmGVjUBu8=.1140fd2e-48ee-497d-9734-0183378f278f@github.com>
 <KiJjEtCIusnLTGgYGd0ACfg0R2HTolAg3OOFoRIwGOE=.12dffe6d-e27a-4bef-a06d-3cbc98934e49@github.com>
 <h0l4-wgUqkVePjmlgrpMuiAALhI2ynOyIH2MqqN-ohQ=.6c1587e5-6774-47e9-9024-0e997cc81d38@github.com>
Message-ID: <PGC9iQd2owFnz-I3JmpP4e4mmyVe6QSWsvHUmQv9Mus=.7f805025-c3db-42c8-8170-b1b285b962f6@github.com>

On Tue, 19 Nov 2024 01:25:11 GMT, ??? <duke at openjdk.org> wrote:

> cc @quantum6
> 
> I tracked down this PR from your Zhihu answer: https://www.zhihu.com/question/360671800/answer/3481640228
> 
> It's your irresponsiveness (towards this question) which lead this PR to be deprecated by the bot, and you blame the OpenJDK community for the atmosphere of laziness?
> 
> But things might be more complicated than this. There might be other reviewers who have limited time / interests in looking at your PR (which is extremely frustrating).

I am back. This is my work result:
1, I study many codes of libX11 input method, all of them can't work correctly. So, it is a bug on libX11.
2, I research libX11, 1.8.2 fixed this bug.
commit 62c3337d89d31e0d3ed807004e73ad711fad3342
Author: Kirill Chibisov <contact at kchibisov.com>
Date:   Thu Sep 8 22:50:30 2022 +0000
    ximcp/imRm.c: allow XNSpotLocation with OnTheSpot
3, I tried to ask ubuntu to update libX11, I can't login to edit. I really don't know why.
https://help.ubuntu.com/community/ReportingBugs

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13055#discussion_r1942976034

From abhiscxk at openjdk.org  Wed Feb  5 13:51:12 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 13:51:12 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <maS431czqxziC6XO3fQIrirhyXAamnI5Ug5pZn9g1IM=.2aad1e09-eefe-43c6-879b-7baaf39e9cd4@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
 <maS431czqxziC6XO3fQIrirhyXAamnI5Ug5pZn9g1IM=.2aad1e09-eefe-43c6-879b-7baaf39e9cd4@github.com>
Message-ID: <fN17WfKPN_hZTiRTynrrKz50w5h63vKt-vYdssGQWpE=.743ccd16-e83f-445f-b9cc-4c25a0849c1b@github.com>

On Wed, 5 Feb 2025 12:52:23 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when selection moves to another button.

Deselected state is not announced but RadioButton labels are incorrectly announced with the changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942979058

From psadhukhan at openjdk.org  Wed Feb  5 14:01:22 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 5 Feb 2025 14:01:22 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <1pvJwX2-55YbMOo3TkSR62d7kfGBYRvs_M-B6lEOJkY=.5351ed3e-8c51-4afe-a49c-e929d340b68c@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
 <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
 <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>
 <yRj0FD8SfxIpkdPaF0yKcatAzH4zNL_rTu8Hj83fFzs=.bc1b549a-630d-4489-8760-a3fb72c1b6fe@github.com>
 <U0nr1mSssHPg6vffBpb5s-23tmG8aWipfshWBblcG1o=.63740827-489f-46bd-9304-12e807e612e1@github.com>
 <jg_oOP8j7X6G6_DMbBpezUVchs51obNnnNbp5cRKs_U=.77e5677c-9b7b-4c3f-9ff2-e97b12732989@github.com>
 <1pvJwX2-55YbMOo3TkSR62d7kfGBYRvs_M-B6lEOJkY=.5351ed3e-8c51-4afe-a49c-e929d340b68c@github.com>
Message-ID: <wmMLN82bG3DKSG1YkUDIQGE0pEAvBgIF1IO3m_cgS9U=.f749e6ed-2645-463b-bf42-e6a4f842438a@github.com>

On Tue, 4 Feb 2025 13:15:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> But that's what I believe is been done now in the PR test, corresponding to your 1st image and corresponds to windows11
>> 
>> No, it doesn't.
>> 
>> On Windows 10 which has a selected background around the bullet, it looks completely off.
>> 
>> ![radio-menuitem-with-icon-01-2025-02-04](https://github.com/user-attachments/assets/6a0dd6b6-c611-4fc7-9f25-5125c539fa5b)
>> 
>> ![radio-menuitem-with-icon-02-2025-02-04](https://github.com/user-attachments/assets/1e5a7540-d74e-4a5a-b338-2f04a5076c9d)
>> 
>> [The original behaviour](https://github.com/openjdk/jdk/pull/23324#issuecomment-2624726843) was consistent at least.
>> 
>> Yet what the currently proposed fix produces doesn't look right at all.
>> 
>> The bullet or check-mark should remain centered in their own place as if there's no icon.
>> 
>>> Are you suggesting to keep more gap in between checkmark and button?
>> 
>> Yes, but not only.
>> 
>> If there's an icon, it should move the text to the right to accommodate the additional icon, if we're going this route.
>> 
>> In addition to that, the text in all other menu items should move to the right for consistency so that all the menu items are aligned and items without an icon render an empty icon in this case.
>> 
>> We may introduce a property that controls this behaviour: whether the text aligns in all the menu items or not.
>> 
>> The first option corresponds to this layout:  
>> ![Proposed layout - aligned text](https://github.com/user-attachments/assets/60ef0c8c-544c-44fd-8e7a-a0a52254f9b6)  
>> where all the text moves right to add space for menu icons. This corresponds to menu layout in File Explorer in Windows 11.
>> 
>> The second option corresponds to this layout:  
>> ![Proposed layout - unaligned text](https://github.com/user-attachments/assets/7ee4a124-ed16-4606-b325-d9dafc96d4d8)  
>> where the second menu item remains at the position where it's rendered now.
>
> I have modified the PR to move the icon w.r.t bullet skin width and it looks like this in windows 11..I believe this should work for windows 10 also but I dont have windows10 to check
> 
> ![image](https://github.com/user-attachments/assets/953eee76-ee88-4189-9ed8-681854c27363)
> 
> 
> I dont think we can tamper with text location as it is done in WindowsMenuItemUI#paintText which does not have any knowledge of bullet/icon presence.
> Also, ideally I dont think this should be applicable for windows10 and we should do this only for windows11 but I am not sure if there is version check in our code and anyway, windows10 would be EOL-ed and unsupported platform in few months

It looks ok in windows 11 with both icon selected/unselected

![image](https://github.com/user-attachments/assets/34fd2ba2-40c7-47f5-a241-6f16a90d3b26)

![image](https://github.com/user-attachments/assets/0d175b8f-f2f8-489b-a6e9-2aa9f17d1a70)

I would like to know how it looks in windows 10? Is there any issue?

Although, as per https://bugs.openjdk.org/browse/JDK-8349268 windows 10 is not supported in JDK25 and this fix is going in mainline jdk25

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

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

From abhiscxk at openjdk.org  Wed Feb  5 14:02:30 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 14:02:30 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <fN17WfKPN_hZTiRTynrrKz50w5h63vKt-vYdssGQWpE=.743ccd16-e83f-445f-b9cc-4c25a0849c1b@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
 <maS431czqxziC6XO3fQIrirhyXAamnI5Ug5pZn9g1IM=.2aad1e09-eefe-43c6-879b-7baaf39e9cd4@github.com>
 <fN17WfKPN_hZTiRTynrrKz50w5h63vKt-vYdssGQWpE=.743ccd16-e83f-445f-b9cc-4c25a0849c1b@github.com>
Message-ID: <bDBmx-1q6gdfV7sSwsCZp71UnuBWbqNSUqDGvSYAWRk=.98015dec-d134-42ec-9d91-a4a2f6b48afd@github.com>

On Wed, 5 Feb 2025 13:49:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>>> It shouldn't impact the announcements. One button gets deselected, another one gets selected?
>> 
>>  >Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when > selection moves to another button.
>> 
>> I checked with the changes you suggested for RadioButton and that impacts the announcement. Checked with Swingset2 application and VO announce the RadioButtons incorrect.
>> 
>> No such issue with existing condition.
>
>> Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when selection moves to another button.
> 
> Deselected state is not announced but RadioButton labels are incorrectly announced with the changes.

>What about the case where currently focused or unfocused selected button gets deselected programmatically? Is there an interactive way to deselect a radio button when it's the only button in its own group?

I tried deselecting a RadioButton programmatically by clicking on a button.
If RadioButton is a part of ButtonGroup, it won't get deselected. In case of standalone RadioButton, it will get deselected but VO won't announce anything as the focused element is the Button (clicked to change state of RB).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1942995883

From erikj at openjdk.org  Wed Feb  5 14:14:15 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 5 Feb 2025 14:14:15 GMT
Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST
In-Reply-To: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
References: <ukSS1Ex6lAgR-CoyPFBE9HtJ583TMJEX99Q52hmdpEQ=.1129e71e-f0a4-4032-b51a-d93c4c5b2d6e@github.com>
Message-ID: <GzWcs5f1WSEYzMywz-ey1JZQDoMswQaDzjpfNv6MewQ=.fc4279b4-1c9a-4da6-9349-e0711e2eb1df@github.com>

On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting.

> > (hint: Use e.g. make java.desktop-libs-only JOBS=1 LOG=info to get a build speed number that you can compare across compiler flag changes)

> Seems the dependencies do not work for some reason, so I need to build the whole jdk with LOG=info I guess.

Adding the `-only` suffix does indeed disable dependencies, so you have to manually set up your build directory state to have all the dependencies built already. This would be a reasonable sequence for getting relevant timings. First make sure all dependencies have been built:


$ make java.desktop-libs

Then delete only the things you want to rebuild and run the part of the build that is relevant. This can be repeated.

$ rm -rf build/<your-build-dir>/support/modules_libs/java.desktop
$ time make java.desktop-libs-only JOBS=1

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

PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2636960207

From duke at openjdk.org  Wed Feb  5 14:16:20 2025
From: duke at openjdk.org (anass baya)
Date: Wed, 5 Feb 2025 14:16:20 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File
Message-ID: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>

While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.

The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.

The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.

Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.

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

Commit messages:
 - Conbine Screen Insets Tests
 - Combine Screen Insets Tests

Changes: https://git.openjdk.org/jdk/pull/23449/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349351
  Stats: 205 lines in 2 files changed: 16 ins; 145 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/23449.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23449/head:pull/23449

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

From abhiscxk at openjdk.org  Wed Feb  5 14:20:18 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 5 Feb 2025 14:20:18 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <1hZSBQD8EjnGgiQ2sIBICVZr5iyDEnRsm75dXN0BMXs=.8f96de88-f434-4c04-bccc-bacb3f006e57@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <uP1Shw60WlurOcJgFXvbZP-FQI7KsnnizbBJvFgm5hE=.020f286c-e0ee-4e8a-ba33-b434d0f96b74@github.com>
 <1hZSBQD8EjnGgiQ2sIBICVZr5iyDEnRsm75dXN0BMXs=.8f96de88-f434-4c04-bccc-bacb3f006e57@github.com>
Message-ID: <BL-b5sjhW8NOGOqUoaYZoZiyb8zgy4cKJlrhzHtdM7k=.3fb162f2-99cf-4bc1-90d7-17ef47071b4d@github.com>

On Wed, 5 Feb 2025 02:33:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> I believe this is likely how layout is calculated.
>> 
>> I just wanted to know "why 3 is chosen as a magic number ?". Actually the spacing with "4 * OFFSET" looks better between radio, icon and text of menu item (on win 11).
>
>> > I believe this is likely how layout is calculated.
>> 
>> I just wanted to know "why 3 is chosen as a magic number ?". Actually the spacing with "4 * OFFSET" looks better between radio, icon and text of menu item (on win 11).
> 
> I guess this is now taken care of in latest PR..

@prsadhuk I tested on win11 and I think this should be OK.
Although the gap is not equal between RadioButton icon, imageIcon and text but as you said above `text location as it is done in WindowsMenuItemUI#paintText which does not have any knowledge of bullet/icon presence`, this may not be an issue.

After changing `icon.paintIcon(c, g, x - OFFSET + ((skinWidth != -1) ? skinWidth : 16), y + OFFSET);` to `icon.paintIcon(c, g, x - OFFSET + ((skinWidth != -1) ? skinWidth - 1 : 15), y + OFFSET);` looks better (my personal opinion)

Same issue exist for JCheckBoxMenuItem as well, it's better to extend the test for JCheckBoxMenuItem as well.
The components can be re-arranged in a grid panel to give better visual alignment (vertically aligned).

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2636977269

From duke at openjdk.org  Wed Feb  5 16:42:49 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Wed, 5 Feb 2025 16:42:49 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time
Message-ID: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>

Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.

**Reason of the bug**:  
execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.

**Fix description**: 
make the size of the execCmd array dependent on the number of options.

**Test**: 
new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

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

Commit messages:
 - use array for option args
 - Fix ArrayIndexOutOfBoundsException at PSPrinterJob printExecCmd

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

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

From kizune at openjdk.org  Wed Feb  5 16:59:13 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Feb 2025 16:59:13 GMT
Subject: RFR: 8347836: Disabled PopupMenu shows shortcuts on Mac [v3]
In-Reply-To: <1T3XJsT6uDfsJ4J8HCultUGATWEoa4Xio27Um6dKJLI=.b0de2a72-a20c-45ac-90f1-47ee04b6886b@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
 <1T3XJsT6uDfsJ4J8HCultUGATWEoa4Xio27Um6dKJLI=.b0de2a72-a20c-45ac-90f1-47ee04b6886b@github.com>
Message-ID: <LGsx7WCTHS74ac2McuQhuD-177jbWiQ01_Tg_RCLsFU=.5f78539f-1e1b-4440-bdf2-fe5170b130f1@github.com>

On Mon, 3 Feb 2025 19:02:30 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.
>
> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Separate comment blocks
>  - Add platform conditionals to test instructions

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23402#pullrequestreview-2596418929

From dnguyen at openjdk.org  Wed Feb  5 18:46:16 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 5 Feb 2025 18:46:16 GMT
Subject: Integrated: 8347836: Disabled PopupMenu shows shortcuts on Mac
In-Reply-To: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
References: <Lup_B4ju-2BfXKYewxJFXdzIwsDix7ULLm-8bTe0Q3E=.0a453cfe-fb93-4114-975c-317c524cfd65@github.com>
Message-ID: <TgWWvY2j1Jko_bUyqTv1LEb7TmscupCDh5lcuzCMeY8=.10bdd875-bbdb-41f9-b383-70d2a05b5c39@github.com>

On Fri, 31 Jan 2025 19:54:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The test instructions say that disabled PopupMenus should not have shortcuts shown, but on MacOS, these shortcuts still appear. When checking native MacOS15 behavior, disabled PopupMenus still have shortcuts shown. Since the test doesn't modify the popup's shortcuts other than adding the shortcut for `A`, it makes sense that the result matches native behavior. So, I modified the test instructions instead to exclude MacOS from this step.

This pull request has now been integrated.

Changeset: 379c3f99
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/379c3f99665829c5d8c373d1fb324dc7ef4d84cf
Stats:     17 lines in 1 file changed: 7 ins; 3 del; 7 mod

8347836: Disabled PopupMenu shows shortcuts on Mac

Reviewed-by: azvegint, achung, kizune, abhiscxk

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

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

From rmahajan at openjdk.org  Wed Feb  5 18:47:49 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Wed, 5 Feb 2025 18:47:49 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
Message-ID: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>

**Issue:**
The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.

The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.

**Solution:**

Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.

Testing done.

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

Commit messages:
 - remove unrelated change
 - remove unrelated change
 - 8348106: Catch C++ exception in Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon

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

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

From prr at openjdk.org  Wed Feb  5 19:25:12 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 5 Feb 2025 19:25:12 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v9]
In-Reply-To: <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <w59klf7rxjl0-6-NhwvKZmCqvS8cJ2VZKINLJ1L1w1E=.40e88333-28b4-4c07-b4d4-ce08b47f5db5@github.com>
 <RPqTDjE6NOvoQ5us_FQX4Mtqr9YfVAh0uoPU-4oU6f4=.5154adec-7a08-42da-a92f-d58f05f7eb02@github.com>
 <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
Message-ID: <8Sj3SToTviecMDZ-chc4NjOaK37UU1DY4yl50dgZ6qM=.2630a783-2536-4c1d-9bb3-921bc908854c@github.com>

On Fri, 31 Jan 2025 10:17:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Non-ICC intents are not something we'd support. I see absolutely no problem with that.
> > If a profile has an intent that is unknown to JDK APIs, it doesn't matter what LCMS might do with it
> > if you were programming directly to LCMS as a CMM.
> 
> non-cc intents in lcms are just examples of profiles in the wild that don't violate the icc spec, currently such profiles can be loaded and used for conversion, this patch will break that. Why we should apply this limit and do that now?
> 
> Note that it is possible to use custom intents as well, and we will break it:
> 
> > Little CMS plug-in architecture allows to implement user-defined intents
> 
> > Who knows how many things we'd have to do in order to support 'custom' ICC intents.
> 
> Then let's at least not break it intentionally. Then test and fix if it does not work.

I am 100% for breaking it. We should never have allowed it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2637833734

From honkar at openjdk.org  Wed Feb  5 19:52:44 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Feb 2025 19:52:44 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v9]
In-Reply-To: <VoWBQ9jqCCELNlha537T3QK7hHwK2_94CtxZaRIg0E8=.cddffc7b-e6ef-41a2-8f1d-0c020fb5767d@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <w59klf7rxjl0-6-NhwvKZmCqvS8cJ2VZKINLJ1L1w1E=.40e88333-28b4-4c07-b4d4-ce08b47f5db5@github.com>
 <RPqTDjE6NOvoQ5us_FQX4Mtqr9YfVAh0uoPU-4oU6f4=.5154adec-7a08-42da-a92f-d58f05f7eb02@github.com>
 <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
 <JxV-k99mwSBRNyEbWzyeXi_QoA9IZpG7ScKFVGQgrDs=.442fa174-758a-41bc-bde0-1761cda8a303@github.com>
 <VoWBQ9jqCCELNlha537T3QK7hHwK2_94CtxZaRIg0E8=.cddffc7b-e6ef-41a2-8f1d-0c020fb5767d@github.com>
Message-ID: <Lne9mhic8T4zIhntsDa9glO-7ghjULKq8F5Uj22yLPA=.6c822e4b-719f-4b03-91ca-92f4596172eb@github.com>

On Sat, 1 Feb 2025 00:26:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think there is an API to check if an intent is supported or not: cmsIsIntentSupported we can try to reuse it.

Again this API returns true for both ICC as well as Non-ICC intents which may not be what we want here as we are restricting the RenderingIntent values to what is explicitly specified in ICC Spec Doc.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2637886679

From honkar at openjdk.org  Wed Feb  5 19:52:45 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 5 Feb 2025 19:52:45 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v3]
In-Reply-To: <A4PRnLqBguv6mo_zw_IERBgACZwx8NRPQmySU7ubEoY=.0c90dd4e-8f66-4f82-9520-f8cc78d2c341@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <OBj_CkvtZbicDmPPzUM9FYMelhhDYlJpxLN1RxqEQeQ=.4866021d-8c50-4c9a-bc6f-a8c61f48c6f4@github.com>
 <T5TTpWT2mYOWhL2kPgDwKpAar4Bxbewy3PITGKUhGfQ=.da262afd-6ce6-40e1-92ee-acd9b6de54fe@github.com>
 <X9a36q9CDroDdhinPIW-TGVFapcjxewlKTv8kmaUdCU=.185af415-3f63-4078-85ad-aa473d185bc3@github.com>
 <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com>
 <yLAWChl73RVApySeYrUI9jP3GfaWu01Nq8iddr-iaRQ=.a0516440-d032-4fc7-ad64-e5c845c73217@github.com>
 <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com>
 <sVx6tOOJ4K-FpFKO1oy3nQTlBPrFSjZk-oPm1JyR2ks=.58ccbda8-414c-4276-9553-95b33d579795@github.com>
 <GOoSDyTCTr581fl5xkrFBaWQDYByGJEywJWxsIPxH80=.c320dc8a-2a53-41e1-90c6-f9405c22f994@github.com>
 <qVCWS9V6BILTQV1qDfxfAW1omJYOPCRKKDCwYWFqSHc=.0b69bd95-c2c2-4b01-81e9-0b6cd890f1f3@github.com>
 <LqizGh8P1tBNGlhB6zU9nhH9YmrEhSnklBX
 ZE1UJZBg=.43a0e4c0-bd37-4488-91ab-2fafa28f384a@github.com>
 <og6uimRuDYYnUfIHNnjuriaQqus7Y2qJ563dW9JUp5M=.020a2839-695d-4bd7-ad6a-8271968922aa@github.com>
 <iGMnDF52We7I-uUGCK4txtPzBx7jCzcct2Cy0S2ZUKs=.48c7e03a-e2ce-40c3-a484-ad018d8357a2@github.com>
 <HHCgSwB95d8ud0bbE4cXKhLdOx1HGk_FNIHU3qH1MUw=.5b79c48f-b37e-438a-be1e-dcea56cbaefd@github.com>
 <HK0j3FwOq-Sh3AHfVYGSmvbG6cguvXnrTB-fVXw8IJM=.dcda81fd-562b-4b20-86d0-ffd71c8af4de@github.com>
 <HXBUdyHcnYMx4rfyagTC-xr7luKebOXMT0qmqmcbVDo=.4f5ef4f8-c6bd-4119-babe-8ffc5abc880a@github.com>
 <A4PRnLqBguv6mo_zw_IERBgACZwx8NRPQmySU7ubEoY=.0c90dd4e-8f66-4f82-9520-f8cc78d2c341@github.com>
Message-ID: <K_dOlRPCQ2iIUIdacYDChUFWmQQi55pQW_UnJrFK8gI=.0ef7320b-e315-4f74-a70f-a6618d291086@github.com>

On Mon, 27 Jan 2025 09:59:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Since you already mentioned "non-ICC intent", please specify the part of the specification in ICC.1-2022-05 where their use is prohibited.
>> 
>> @mrserb 
>> The ICC Spec doesn't explicitly say that certain values are prohibited. Although it does not list Non-ICC Intent values under Rendering Intent (pg#23, Table 23) either.
>> 
>> What do you suggest is the best solution here to address the difference in ICC Spec Doc vs LCMS API doc? 
>> 
>> 1. Add the missing constants present in LCMS API doc to Java?
>> 2. Or skip validating Rendering Intent? 
>> 3. Since Color Space has few extra constants in LCMS API do we need to address it too?
>> 
>> @prrace Can you please suggest how to address Sergey's concern, since the last time we discussed we agreed to follow ICC Spec Doc.
>> 
>>> there may be a reason why the most common library for icc profiles accepts that data. We shouldn't be more strict than that, it will limit java applications compared to the alternatives.
>
>>Add the missing constants present in LCMS API doc to Java?
> 
> No, we definitely don't need to add any custom values ??to the Java API, the question is whether we need to reject them or not, since the ICC specification allows it(?).

@mrserb 

The ICC Spec Doc states just 4 values for rendering intent (Table#23)
Perceptual : 0
Media-relative colorimetric : 1
Saturation : 2
ICC-absolute colorimetric : 3 

> the question is whether we need to reject them or not, since the ICC specification allows it(?).

I did not come across any statement in ICC Spec doc that states other RenderingIntents are allowed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1943571878

From liach at openjdk.org  Wed Feb  5 23:45:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Feb 2025 23:45:25 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
Message-ID: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>

`MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.

To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

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

Commit messages:
 - Update bug id
 - copyright years and comments
 - Consolidate multi-byte io into ByteArray

Changes: https://git.openjdk.org/jdk/pull/23478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349503
  Stats: 2042 lines in 17 files changed: 714 ins; 1134 del; 194 mod
  Patch: https://git.openjdk.org/jdk/pull/23478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23478/head:pull/23478

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

From dholmes at openjdk.org  Thu Feb  6 01:52:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 01:52:57 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion and
 parsing
Message-ID: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>

This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.

JDK-8348190: Framework for tracing makefile inclusion and parsing

The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.

Thanks.

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

Commit messages:
 - Revert "8348190: Framework for tracing makefile inclusion and parsing"

Changes: https://git.openjdk.org/jdk/pull/23481/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349511
  Stats: 2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod
  Patch: https://git.openjdk.org/jdk/pull/23481.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23481/head:pull/23481

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

From darcy at openjdk.org  Thu Feb  6 02:04:15 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 6 Feb 2025 02:04:15 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Approving clean backout.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597463613

From dholmes at openjdk.org  Thu Feb  6 02:44:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:44:08 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <uvRLkBJvAGvaMzXB3z4ky8gVK_Q2AwKApT7C--KZ2D0=.43c2a39f-4682-4def-8d32-fd492ce6fdcb@github.com>
Message-ID: <AWJoVSTeygOR6BO1A3fQOGLPGVzlF6zuRNMw4TMiVZc=.cf4c9f9e-75b8-45ef-b295-8fb57846fa24@github.com>

On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Approving clean backout.

Thanks @jddarcy !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638687813

From mikael at openjdk.org  Thu Feb  6 02:54:17 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 6 Feb 2025 02:54:17 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23481#pullrequestreview-2597531112

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: RFR: 8349511: [BACKOUT] Framework for tracing makefile inclusion
 and parsing
In-Reply-To: <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
 <CoG403Vao1Q1xXY5lL-B9qpbZ8zJq7uZTT46oPeAuK0=.41479778-dad6-4e86-84d9-4d95fff87373@github.com>
Message-ID: <o_LWA-N7-KZ6e3MLu8U2GOcgFRK6rgW58IWj5sGK_6s=.12f73a3c-70ce-49c3-b486-1585990fefac@github.com>

On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>> 
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>> 
>> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
>> 
>> Thanks.
>
> Marked as reviewed by mikael (Reviewer).

Thanks @vidmik !

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

PR Comment: https://git.openjdk.org/jdk/pull/23481#issuecomment-2638701374

From dholmes at openjdk.org  Thu Feb  6 02:54:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Feb 2025 02:54:18 GMT
Subject: Integrated: 8349511: [BACKOUT] Framework for tracing makefile
 inclusion and parsing
In-Reply-To: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
References: <2bf6g3iLVTSpqlp0ka4LeAovJRyPvdibwFZsONUGPI4=.3d01a784-5e93-4c78-87c6-a31c948a81c0@github.com>
Message-ID: <aWuh7nyeGLH2h82Pk0IN4KD8wwSrAXkioaZ_EWlOWN4=.5e1f6202-37f7-4b5a-a36a-2adf4ca85b10@github.com>

On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
> 
> JDK-8348190: Framework for tracing makefile inclusion and parsing
> 
> The above issue caused problems in the Oracle closed builds and so needs to be backed out until that is addressed.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 64bd8d25
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64bd8d2592d26e02a7f2f96caa47cba5e158aaa2
Stats:     2717 lines in 273 files changed: 501 ins; 1663 del; 553 mod

8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing

Reviewed-by: darcy, mikael

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

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

From psadhukhan at openjdk.org  Thu Feb  6 05:48:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 6 Feb 2025 05:48:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <1hZSBQD8EjnGgiQ2sIBICVZr5iyDEnRsm75dXN0BMXs=.8f96de88-f434-4c04-bccc-bacb3f006e57@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <uP1Shw60WlurOcJgFXvbZP-FQI7KsnnizbBJvFgm5hE=.020f286c-e0ee-4e8a-ba33-b434d0f96b74@github.com>
 <1hZSBQD8EjnGgiQ2sIBICVZr5iyDEnRsm75dXN0BMXs=.8f96de88-f434-4c04-bccc-bacb3f006e57@github.com>
Message-ID: <CeU48wWuvkAMNnR3lfpj9sdHJgFQSQ2DRP98S_tu5Hc=.039225b6-f1a1-4a95-9113-35190e246947@github.com>

On Wed, 5 Feb 2025 02:33:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> I believe this is likely how layout is calculated.
>> 
>> I just wanted to know "why 3 is chosen as a magic number ?". Actually the spacing with "4 * OFFSET" looks better between radio, icon and text of menu item (on win 11).
>
>> > I believe this is likely how layout is calculated.
>> 
>> I just wanted to know "why 3 is chosen as a magic number ?". Actually the spacing with "4 * OFFSET" looks better between radio, icon and text of menu item (on win 11).
> 
> I guess this is now taken care of in latest PR..

> @prsadhuk I tested on win11 and I think this should be OK. Although the gap is not equal between RadioButton icon, imageIcon and text but as you said above `text location as it is done in WindowsMenuItemUI#paintText which does not have any knowledge of bullet/icon presence`, this may not be an issue.
> 
> After changing `icon.paintIcon(c, g, x - OFFSET + ((skinWidth != -1) ? skinWidth : 16), y + OFFSET);` to `icon.paintIcon(c, g, x - OFFSET + ((skinWidth != -1) ? skinWidth - 1 : 15), y + OFFSET);` looks better (my personal opinion)
> 
> Same issue exist for JCheckBoxMenuItem as well, it's better to extend the test for JCheckBoxMenuItem as well. The components can be re-arranged in a grid panel to give better visual alignment (vertically aligned).

It may look better with skinWidth -1 and 16-1 but the icon may overlap with bullet/checkmark skin by 1 pixel in that case, so for better consistency, I have kept it adrift of skinWidth and 16 is because normal icon is of 16x16 size, so in case there is no skin, then also 16 width is maintained

I will work on the testcase to extend for JCheckBoxMenuItem..

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2638890130

From serb at openjdk.org  Thu Feb  6 10:36:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Feb 2025 10:36:07 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v9]
In-Reply-To: <8Sj3SToTviecMDZ-chc4NjOaK37UU1DY4yl50dgZ6qM=.2630a783-2536-4c1d-9bb3-921bc908854c@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <w59klf7rxjl0-6-NhwvKZmCqvS8cJ2VZKINLJ1L1w1E=.40e88333-28b4-4c07-b4d4-ce08b47f5db5@github.com>
 <RPqTDjE6NOvoQ5us_FQX4Mtqr9YfVAh0uoPU-4oU6f4=.5154adec-7a08-42da-a92f-d58f05f7eb02@github.com>
 <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
 <8Sj3SToTviecMDZ-chc4NjOaK37UU1DY4yl50dgZ6qM=.2630a783-2536-4c1d-9bb3-921bc908854c@github.com>
Message-ID: <aeyjcyic9_JQkn_FjNMnRcU47mB84_rXQwSQrqT0JfI=.bf587809-4a37-4124-8e0c-3c2baa0e64f2@github.com>

On Wed, 5 Feb 2025 19:22:40 GMT, Phil Race <prr at openjdk.org> wrote:

> I am 100% for breaking it. We should never have allowed it.

But why? It is allowed by the icc spec, such profiles do not break any rules.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2639429806

From serb at openjdk.org  Thu Feb  6 10:59:14 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 6 Feb 2025 10:59:14 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
Message-ID: <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>

On Tue, 28 Jan 2025 23:21:26 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point.
>> 
>> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native.
>> 
>> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds.
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - helper function
>  - grab screen data on mouseMove

The Robot API is just a wrapper around the native API with a basic functionality that works across all platforms. If a native macOS application can move the mouse in a certain way, why should Java be restricted?

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2639487470

From gennadiy.krivoshein at bell-sw.com  Thu Feb  6 11:58:39 2025
From: gennadiy.krivoshein at bell-sw.com (Gennadiy Krivoshein)
Date: Thu, 6 Feb 2025 11:58:39 +0000
Subject: Unable to use borderless printing on Linux and Mac
Message-ID: <CAKj09HdsUifGHodmgxeryqE7Aho6kBEv0NryERHMT_Fke1VodA@mail.gmail.com>

Hi, client-libs-dev.

I faced a problem with borderless printing on Linux and Mac. It's
impossible to use borderless printing if I print without a print dialog or
use a common print dialog.

After my investigation, I found two problems.
    1. It's impossible to select borderless media in the common print
dialog because it has the same name as bordered media. For example, I see
two "A4 (ISO/DIN & JIS)" media in the media combobox, but my printer's PPD
file contains A4 and A4_borderless media with the same paper size and
different imageable areas.
    2. PSPrinterJob doesn't provide the required borderless media to CUPS.
I can select InputSlot, but I can't select the necessary borderless media.

I see two possible options to solve the first problem.
    1. Squash the same media names. In this case, there are no media name
collisions, but it requires a new selector to select the type of margins.
It might be a combobox with 3 values ("No margins", "minimal margins",
"custom margins"), the first value means borderless printing. But there is
no one-to-one mapping of the MediaSizeName to the MediaPrintableArea; one
MediaSizeName will be mapped to 2 MediaPrintableAreas (bordered and
borderless);
    2. Do not map media names from the CUPS to the standard names to see
all media without name collision. This case requires mapping of all CUPS
media to the MediaSize so the MediaSize's static mediaMap field will
contain duplicates (one value for bordered media and one for borderless).

Two possible options to pass borderless selection to CUPS:
    1. Add four new IPP attributes (media-left-margin, media-right-margin,
media-top-margin, media-bottom-margin) and use them as described in 6.3.1.1
"Media Selection and Full-Bleed Printing" of the "IPP Job Extensions v2.1"
, use borderless print option if a user passes all of them with 0 value and
necessary MediaSizeName ("margin-left=0 margin-right=0 margin-top=0
margin-bottom=0 media=A4"). But it's impossible to use it as described in
the IPP standard with CUPS, because CUPS ignores these attributes, it
should be mapped to the particular CUPS media name (for example, use
"media=A4_borderless" instead of "media=A4 margin-left=0 margin-right=0
margin-top=0 margin-bottom=0").
    2. Add a new PrintRequestAttribute class (Borderless.class) and pass it
as a marker with MediaSizeName attribute if a user wants to use the
borderless print option. This attribute is not an IPP attribute but
requires less effort.

All of these options require a new public API and I would like to ask for
advice before proceeding with a PR&CSR.

BR,
Gennadiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250206/ebd417e8/attachment.htm>

From rgiulietti at openjdk.org  Thu Feb  6 12:16:11 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Feb 2025 12:16:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <Bh31yb9xNkCWAW0XkAen5i4e_hvBJkYFsjNIcL5Ybjs=.7e9077dd-f8a3-4479-85bd-6e61b35aa746@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

What about dropping "BE" from all big-endian method names?
This would reduces the number of files to review in `java.io` to 0 (admittedly, it's a rather mechanical review).
I know this would be less symmetrical, but...

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 53:

> 51: 
> 52:     public static char getCharBO(byte[] array, int index, boolean big) {
> 53:         Preconditions.checkIndex(index, array.length - Character.BYTES + 1, Preconditions.AIOOBE_FORMATTER);

Suggestion:

        Preconditions.checkIndex(index, array.length - (Character.BYTES - 1), Preconditions.AIOOBE_FORMATTER);


Similarly for all cases below.

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

PR Comment: https://git.openjdk.org/jdk/pull/23478#issuecomment-2639657316
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944571743

From azvegint at openjdk.org  Thu Feb  6 13:16:10 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 6 Feb 2025 13:16:10 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v3]
In-Reply-To: <FZ6PhsDebL8OhJhypoLBvNPuiuiZqZB2fIePOqFICk4=.63dc2d16-e7bd-485b-8c82-22e3d7ad11e0@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <FZ6PhsDebL8OhJhypoLBvNPuiuiZqZB2fIePOqFICk4=.63dc2d16-e7bd-485b-8c82-22e3d7ad11e0@github.com>
Message-ID: <gtnFFJ_EiNYHrTjoYBUaWUT5AU3LOKXNhCe3BQ95yYw=.f947be0b-8daa-455c-b0e2-d1ad1869a0f5@github.com>

On Tue, 4 Feb 2025 16:28:51 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test fix

Looks good.

test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java line 152:

> 150:         );
> 151:     }
> 152: 

Suggestion:


//////////////////////////////////////
//                                  //
//          SCENARIO 4              //
//                                  //
//////////////////////////////////////



I think this can be added for consistency with the rest of the test.

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23443#pullrequestreview-2598637065
PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r1944702211

From duke at openjdk.org  Thu Feb  6 13:23:15 2025
From: duke at openjdk.org (anuj-ion)
Date: Thu, 6 Feb 2025 13:23:15 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v3]
In-Reply-To: <FZ6PhsDebL8OhJhypoLBvNPuiuiZqZB2fIePOqFICk4=.63dc2d16-e7bd-485b-8c82-22e3d7ad11e0@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <FZ6PhsDebL8OhJhypoLBvNPuiuiZqZB2fIePOqFICk4=.63dc2d16-e7bd-485b-8c82-22e3d7ad11e0@github.com>
Message-ID: <14ezFns5YFKtkBwFj_BspwEOLwPortyXf_LvvmIeTOI=.84225295-0bbf-421f-9ff6-634fcdd01533@github.com>

On Tue, 4 Feb 2025 16:28:51 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor test fix

Hi, As this PR is approved, hopefully it will be merged to master soon. But ticket JDK-8347826 doesn't mention Java 17 backporting. Can you please also add request for backporting to Java 17 also. Many Thanks,

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2639809821

From mbaesken at openjdk.org  Thu Feb  6 13:57:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Feb 2025 13:57:22 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
Message-ID: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>

The splashscreen lib is currently built with LOW optimization.
This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.

current settings (LOW optimization) :
---------------------------------------------------
2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so

468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM

368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo


new settings (SIZE optimization) :
--------------------------------------------------
2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so

404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM

372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo

On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
Other UNIX platforms have a reduction by ~ 10-20 % .
For Windows, LOW and SIZE optimization have currently the same O - flags so no reduction.

Build times are the same on Windows (because LOW and SIZE are currently 'optimize for size').
On Linux x86_64 it seems that the build times of java.desktop native libs get slightly better but only very little.

time make java.desktop-libs-only JOBS=1

LOW (current)
real   5m38.074s
user   4m16.709s
sys    0m26.335s

real   5m29.081s
user   4m17.838s
sys    0m26.749s

real   5m25.496s
user   4m17.906s
sys    0m25.506s

SIZE for libsplashscreen
real  5m18.468s
user  4m13.024s
sys   0m25.129s

real  5m31.944s
user  4m12.922s
sys   0m26.333s

real  5m12.874s
user  4m12.253s
sys   0m25.206s

real has a bit of variance but  user time is  4m16 / 4m17   for LOW  and  4m12/4m13  for SIZE for libsplashscreen.

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

Commit messages:
 - JDK-8349378

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

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

From erikj at openjdk.org  Thu Feb  6 14:06:09 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Feb 2025 14:06:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX platforms have a reduction by ~ 10-20 % .
> For Windows, LOW and SIZE optimization have currentl...

I think this looks good, but someone from client should probably also weigh in.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2598774548

From rgiulietti at openjdk.org  Thu Feb  6 14:09:13 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 6 Feb 2025 14:09:13 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <x2haSwVHMihhu6JZXvMj3r3RnQVbLF3n94boptanIBM=.b63e6cc4-2ff5-49f6-9a92-a0feae5758c2@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

test/jdk/jdk/internal/util/ByteArray/Types.java line 27:

> 25:  * @test
> 26:  * @bug 8349503
> 27:  * @library /test/lib

Suggestion:

 * @library /test/lib
 * @key randomness

test/jdk/jdk/internal/util/ByteArray/Types.java line 64:

> 62:                 new ReadCase<>("u2", ByteArray::getUnsignedShortBO, ByteArray::getUnsignedShortBE, ByteArray::getUnsignedShortLE, 2, u2 -> ((u2 >> Byte.SIZE) & 0xFF) | ((u2 << Byte.SIZE) & 0xFF00), Comparator.naturalOrder()),
> 63:                 new ReadCase<>("int", ByteArray::getIntBO, ByteArray::getIntBE, ByteArray::getIntLE, Integer.BYTES, Integer::reverseBytes, Comparator.naturalOrder()),
> 64:                 new ReadCase<>("float", ByteArray::getFloatBO, ByteArray::getFloatBE, ByteArray::getFloatLE, Float.BYTES, null, Comparator.comparing(Float::floatToRawIntBits)),

Would it be possible to have a local `reverseBytes` for `float` and `double` as well?

test/jdk/jdk/internal/util/ByteArray/Types.java line 124:

> 122:                 new WriteCase<>("int", ByteArray::setIntBO, ByteArray::setIntBE, ByteArray::setIntLE, Integer.BYTES, List.of(42)),
> 123:                 new WriteCase<>("float", ByteArray::setFloatBO, ByteArray::setFloatBE, ByteArray::setFloatLE, Float.BYTES, List.of(Float.NaN, Float.intBitsToFloat(0x7FF23847))),
> 124:                 new WriteCase<>("float raw", ByteArray::setFloatRawBO, ByteArray::setFloatRawBE, ByteArray::setFloatRawLE, Float.BYTES, List.of(1.0F)),

Raw seems to be exercised only on unproblematic cases, not on NaNs.

Similarly for "double raw".

test/jdk/jdk/internal/util/ByteArray/Types.java line 152:

> 150:         assertThrows(IndexOutOfBoundsException.class, () -> leWriter.set(arr, arrayLen - size + 1, value));
> 151: 
> 152:         int index = 0;

This is always 0.

test/jdk/jdk/internal/util/ByteArray/Types.java line 173:

> 171:             var arrBe1 = arr.clone();
> 172:             beWriter.set(arrBe1, index, v1);
> 173:             assertArrayEquals(arrBe, arrBe1);

What about the little-endian case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944742266
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944786100
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944783068
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944769063
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944772926

From rmarchenko at openjdk.org  Thu Feb  6 14:13:50 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 6 Feb 2025 14:13:50 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also fixed the test, and added the approptiate test case.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
  
  Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/a913b86b..5782dd7e

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

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

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

From azvegint at openjdk.org  Thu Feb  6 14:13:50 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 6 Feb 2025 14:13:50 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <s9AfjkHXedzR_BcMnWynA8Yl4MWbQzV-c61PSoK6q1c=.cc3f51ad-5334-4d9d-be6f-049a139d234d@github.com>

On Thu, 6 Feb 2025 14:10:52 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23443#pullrequestreview-2598792951

From mbaesken at openjdk.org  Thu Feb  6 14:18:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Feb 2025 14:18:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <Ur1Tr3C85b7t-gBebU9s6AtUnQLUxD65E0Nz7lLnSl8=.64c496f3-6a6b-4bb6-b538-b7006fd195fd@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

For the record, those are the lib sizes on Windows x86_64, VS2019 (LOW and SIZE uses currently the same opt flag, so same sizes)

204K    /windows_x86_64/jdk-opt/images/jdk/bin/splashscreen.dll
1.4M    /windows_x86_64/jdk-opt/images/jdk/bin/splashscreen.dll.pdb
352K    /windows_x86_64/jdk-opt/images/jdk/bin/splashscreen.dll.stripped.pdb

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2639948726

From pminborg at openjdk.org  Thu Feb  6 14:28:11 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 14:28:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <En1fQAmnypO9c23r8ncpx9_VlO1NRAW9XcRMz59BTM4=.ab82b928-4c04-40f7-a686-b8de36b4cea2@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 57:

> 55:     }
> 56: 
> 57:     public static short getShortBO(byte[] array, int index, boolean big) {

If we have methods `getShortBE` and `getShortLE` then perhaps this method should just be called `getShort`.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 62:

> 60:     }
> 61: 
> 62:     public static int getIntBO(byte[] array, int index, boolean big) {

I suggest to rename `big` to `bigEndian` to use the same naming conventions as in `Unsafe`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944819768
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944817837

From psandoz at openjdk.org  Thu Feb  6 14:33:11 2025
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 6 Feb 2025 14:33:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <yaJWeScAM3bCyZx8Tg7SYFdRlXHsPufTXUEOFjf7zss=.a7e82b8d-4b5b-4f4c-97de-067d386913be@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

This looks reasonable, not looked in detail at all of it. Although i understand the motivation can you please revert the changes to VarHandle. VarHandle is intended to be as thin as possible safe wrapper around unsafe. This PR changes how this is for one particular kind of handle thus differing from the others, and it also creates an indirection with a potential independently moving part.

Also, some guidance in Java on ByteArray would be useful on when to use it e.g., enumerating the cases such as early execution of the JVM etc.

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

PR Review: https://git.openjdk.org/jdk/pull/23478#pullrequestreview-2598852813

From pminborg at openjdk.org  Thu Feb  6 14:33:12 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 14:33:12 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <evAenTOjoERTQqzy0mFSRfPw3pkiKTJGAGWWtUXBFnc=.288e0965-3e4b-4b91-946c-351d89c976f5@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 131:

> 129:     // BE methods
> 130: 
> 131:     public static char getCharBE(byte[] array, int offset) {

I think it is worth making the effort to document these methods as they are used across the JDK. We could just take the docs from the old class and modify it slightly.

src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java line 245:

> 243:             throw new EOFException();
> 244:         }
> 245:         return (byteOrder == ByteOrder.BIG_ENDIAN)

This could just be `ByteArray.getShortBO(byteBuff, 0, byteOrder == ByteOrder.BIG_ENDIAN)`. Same for the others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944825706
PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944828604

From pminborg at openjdk.org  Thu Feb  6 14:36:14 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 6 Feb 2025 14:36:14 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <bxO42XUIIjw5Pju8039DcZoQI-WAwOD6hN2Jvz0397c=.8215bc1b-e843-450b-9c5d-1395b419e98a@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

test/jdk/jdk/internal/util/ByteArray/Types.java line 82:

> 80:         byte[] arr = new byte[arrayLen];
> 81: 
> 82:         assertThrows(NullPointerException.class, () -> orderedReader.get(null, 0, true));

I suggest breaking out the invariant tests in a separate test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1944834882

From rriggs at openjdk.org  Thu Feb  6 14:39:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Feb 2025 14:39:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <0DK9LJKJvNPIUaWuV8y8U6t6W0YmmVG7VqyZlpr_q2Y=.b7e801fa-070a-40ce-ac66-a266544b6425@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

It would have been useful to get agreement on the concept and the naming before committing to the implementation.

The BE/BO/LE are noise in the API.  The little endian cases are a minority and should attract more attention in the API.
The network byte-order/big-endian cases should keep the simple names.

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

PR Comment: https://git.openjdk.org/jdk/pull/23478#issuecomment-2640004192

From rmarchenko at openjdk.org  Thu Feb  6 14:41:11 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 6 Feb 2025 14:41:11 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v3]
In-Reply-To: <14ezFns5YFKtkBwFj_BspwEOLwPortyXf_LvvmIeTOI=.84225295-0bbf-421f-9ff6-634fcdd01533@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <FZ6PhsDebL8OhJhypoLBvNPuiuiZqZB2fIePOqFICk4=.63dc2d16-e7bd-485b-8c82-22e3d7ad11e0@github.com>
 <14ezFns5YFKtkBwFj_BspwEOLwPortyXf_LvvmIeTOI=.84225295-0bbf-421f-9ff6-634fcdd01533@github.com>
Message-ID: <BbflXHmBmlKCYNL7VbRLoMAVeiGIxZbZnhiref1uWcM=.844bf46d-aaba-4112-982e-cba03c0697e2@github.com>

On Thu, 6 Feb 2025 13:19:26 GMT, anuj-ion <duke at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor test fix
>
> Hi, As this PR is approved, hopefully it will be merged to master soon. But ticket JDK-8347826 doesn't mention Java 17 backporting. Can you please also add request for backporting to Java 17 also. Many Thanks,

@anuj-ion 
> Hi, As this PR is approved, hopefully it will be merged to master soon. But ticket JDK-8347826 doesn't mention Java 17 backporting. Can you please also add request for backporting to Java 17 also. Many Thanks,

Sure, however usually backports are requested in backward order (23, 21, 17, ...) after the change is integrated to the upstream. So, I'm going to backport this after the integration is completed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2640007195

From duke at openjdk.org  Thu Feb  6 14:41:12 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Feb 2025 14:41:12 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <UW0nECCvsLyfABGWqFXnkAJi45B-QN5ifQ7R4FsZiYU=.bb4c29bd-cf65-4c0a-9d48-a7c774d87577@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

@wkia 
Your change (at version 5782dd7ebf4135a5a5b419234004331ce492cbc9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2640011788

From dnguyen at openjdk.org  Thu Feb  6 17:15:14 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 6 Feb 2025 17:15:14 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <1fjzUR1RxWAEpbja0uaJmAeSZgln-UQsZ4ESiBUL7Gc=.8e307676-4331-4336-bf37-8968b7db3ed2@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <1fjzUR1RxWAEpbja0uaJmAeSZgln-UQsZ4ESiBUL7Gc=.8e307676-4331-4336-bf37-8968b7db3ed2@github.com>
Message-ID: <Bl_10if9N9POKQAp0xJ-qHJFSgrV76cUU0G76DV0-XE=.bff59cae-88bf-4fd0-9d52-b6c49ed0b593@github.com>

On Wed, 5 Feb 2025 07:39:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1625:
> 
>> 1623:                     scrollbar.setValueIsAdjusting(false);
>> 1624:                     return;
>> 1625:                 }
> 
> Can't it be merged with below frame disable logic as it does the same thing?

I initially separated it to make it clear that this is for focus. I'll edit this and modify the existing comment to include null focus.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1945128597

From dnguyen at openjdk.org  Thu Feb  6 17:31:15 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 6 Feb 2025 17:31:15 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <Bl_10if9N9POKQAp0xJ-qHJFSgrV76cUU0G76DV0-XE=.bff59cae-88bf-4fd0-9d52-b6c49ed0b593@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <1fjzUR1RxWAEpbja0uaJmAeSZgln-UQsZ4ESiBUL7Gc=.8e307676-4331-4336-bf37-8968b7db3ed2@github.com>
 <Bl_10if9N9POKQAp0xJ-qHJFSgrV76cUU0G76DV0-XE=.bff59cae-88bf-4fd0-9d52-b6c49ed0b593@github.com>
Message-ID: <Eu0XxQ_F8x4ZMF7t0Qozg8q8MOZEHrwNbhTFH0zPmvY=.179cd061-bd3f-4552-b1d1-946c24759b37@github.com>

On Thu, 6 Feb 2025 17:13:00 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1625:
>> 
>>> 1623:                     scrollbar.setValueIsAdjusting(false);
>>> 1624:                     return;
>>> 1625:                 }
>> 
>> Can't it be merged with below frame disable logic as it does the same thing?
>
> I initially separated it to make it clear that this is for focus. I'll edit this and modify the existing comment to include null focus.

I tested different ways to merge this block with the below blocks. I'm not sure if it makes sense to do so now because it wouldn't be as simple as adding `|| focusOwner == null` to the first if-statement or appending the logic to the `else` block. I would still need another if or else/if block regardless. And I think it's harder to follow than the current implementation. Let me know if you prefer it a different way, but I think the current implementation is better for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1945149888

From kbarrett at openjdk.org  Thu Feb  6 17:31:22 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 6 Feb 2025 17:31:22 GMT
Subject: RFR: 8348286: [AIX] clang 17 introduces new warning
 Wtentative-Definitions which produces Build errors [v3]
In-Reply-To: <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
References: <Y1MNMWR4cYqet2mgF9EgeWosB6eG5ImOVjyn3ncjAW8=.3a771b94-ba15-4e2d-a8ac-cc7aca483653@github.com>
 <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
Message-ID: <Sw25chLxLKYMumjFze-_j3-GhTkBcPC9uvhY85Wr8jE=.7620de53-cf27-4de9-9ca2-5cd0c8b1320d@github.com>

On Thu, 23 Jan 2025 13:48:06 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan.
>> Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror.
>> One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found:
>> /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions]
>>    36 | IMGEXTERN jfieldID g_BImgRasterID;
>>       | ^
>> From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g.
>> imageInitIDs.h:36:20
>>    36 extern jfieldID g_BImgRasterID;
>> and the corresponding c-File
>>    jfieldID g_BImgRasterID;
>> 
>> The other possible solution would be to compile everything with
>> -Wno-tentative-definitions
>> which could be set in flags-cflags.m4, if compiling with clang 17.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove old solution

Coming late to the party, since this PR has already been integrated.

First, tentative definitions are only applicable to C, not to C++.

I think `-Wtentative-definition` doesn't really buy all that much. It looks
like it turns a *potential* link-time failure into a definite compile-time
warning. But I don't think I'd want to globally disable it, as it seems like
it would usually be a valid complaint (unless the code is jumping through some
hoops as done by imageInitIDs.[ch]), and probably provides a better error
message too.

gcc provides `-fcommon`, which controls the placement of tentative
definitions. We're not using that, instead implicitly using the default
`-fno-common`. (There is one place where we unnecessarily use `-fno-common`
explicitly: https://bugs.openjdk.org/browse/JDK-8349565.)

With `-fcommon`, tentative definitions in different translation units are
merged, with potential access penalties. With `-fno-common`, instead of
merging one gets multiple definition errors at link time. Note that code that
relies on `-fcommon` has never been standards compliant.

The changes related to fp_pipewire.h seem fine.

I'm not keen on the large copy-paste-modify for imageInitIDs.[ch]. I kind of
prefer a different approach, of locally suppressing the warning, i.e.
something like (untested, may need version conditionalization):

In imageInitIDs.c

+ PRAGMA_DIAG_PUSH
+ #pragma clang diagnostic ignored "-Wtentative-definition"
  #define IMGEXTERN
  #include "imageInitIDs.h"
+ PRAGMA_DIAG_POP


I'll leave it up to the client team to decide whether they want to make such a
change, or leave things as-is.

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

PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2640539884

From aivanov at openjdk.org  Thu Feb  6 17:56:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 6 Feb 2025 17:56:15 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v9]
In-Reply-To: <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
Message-ID: <ajz_y1KcQABJCOOpVvS-SC3gRl3-lbphOjlBzmp10q0=.4b00a2aa-2e75-4a83-824d-fd29aefccb0b@github.com>

On Tue, 4 Feb 2025 14:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retain diff of OFFSET between skin background start coord and skin coordinate

I tested it on Windows 11 and 10.

**Windows 11**  
![Windows-11-menu-items-2025-02-06](https://github.com/user-attachments/assets/e368f0ce-3c0f-45d6-a485-3c5331471204)  
It looks reasonably well?

But it doesn't look like the menu in Windows 11 File Explorer, does it?  
![Windows 11 File Explorer View with icons (100%)](https://github.com/user-attachments/assets/53fd8ba9-00f7-4126-a238-ab162ff54325)  
Windows L&F should look like native apps do, and we're not there yet with the menu rendering.

**Windows 10**  
![Windows-10-menu-items-2025-02-06](https://github.com/user-attachments/assets/e2d64c81-3831-4f20-93ea-f9e85f5ce5aa)  
It looks bad because neither icon is where it should be.

Without the fix, it looks good:  
![Windows-10-menu-items-no-fix-2025-02-06](https://github.com/user-attachments/assets/684c9461-e47e-46de-a609-7bd9724099cb)  
And one can see if an item is selected or not. Yet they changed the skin in Windows 11, now it's impossible to tell distinguish them.

---

The updated test is available at [commit 7aa4de1](https://github.com/openjdk/jdk/blob/7aa4de1b5446126a7732f11a6c94839a396ff8bf/test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java).

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2640591767

From aivanov at openjdk.org  Thu Feb  6 18:02:25 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 6 Feb 2025 18:02:25 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v6]
In-Reply-To: <wmMLN82bG3DKSG1YkUDIQGE0pEAvBgIF1IO3m_cgS9U=.f749e6ed-2645-463b-bf42-e6a4f842438a@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <cTpmDo92c_HOhjuYETOx4qy1Gi_2sD5n5cYhU3kZFEA=.cf8cc786-bbca-4a13-84b3-b75cd5ba3c7d@github.com>
 <Lof-SAf_MvJ0cEN1yWOKvUp_Zq__gO_PtKGVs8BjC4k=.73a5e70c-3cdf-4e67-96c3-1a9ce5ebdba5@github.com>
 <gzGk4xOztqiqv336qIope8fAI45DuamLXbDpuJm2DvQ=.31f15164-68b4-4101-9ede-07d489ad2b09@github.com>
 <0OZnHD4uKU26S9DwoJMjO-a_0b23YYbxe6DVsmjisUk=.a0dc410a-6ccb-4baa-b0d7-efa8413e3b11@github.com>
 <yRj0FD8SfxIpkdPaF0yKcatAzH4zNL_rTu8Hj83fFzs=.bc1b549a-630d-4489-8760-a3fb72c1b6fe@github.com>
 <U0nr1mSssHPg6vffBpb5s-23tmG8aWipfshWBblcG1o=.63740827-489f-46bd-9304-12e807e612e1@github.com>
 <jg_oOP8j7X6G6_DMbBpezUVchs51obNnnNbp5cRKs_U=.77e5677c-9b7b-4c3f-9ff2-e97b12732989@github.com>
 <1pvJwX2-55YbMOo3TkSR62d7kfGBYRvs_M-B6lEOJkY=.5351ed3e-8c51-4afe-a49c-e929d340b68c@github.com>
 <wmMLN82bG3DKSG1YkUDIQGE0pEAvBgIF1IO3m_cgS9U=.f749e6ed-2645-463b-bf42-e6a4f842438a@github.com>
Message-ID: <03kKZvRn4W9vkNEGKnuVg4kxaao0SeC63TCQ8LeXwAI=.95b32320-94b5-42f5-a09d-b30e0aeb688a@github.com>

On Wed, 5 Feb 2025 13:59:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I have modified the PR to move the icon w.r.t bullet skin width and it looks like this in windows 11..I believe this should work for windows 10 also but I dont have windows10 to check
>> 
>> ![image](https://github.com/user-attachments/assets/953eee76-ee88-4189-9ed8-681854c27363)
>> 
>> 
>> I dont think we can tamper with text location as it is done in WindowsMenuItemUI#paintText which does not have any knowledge of bullet/icon presence.
>> Also, ideally I dont think this should be applicable for windows10 and we should do this only for windows11 but I am not sure if there is version check in our code and anyway, windows10 would be EOL-ed and unsupported platform in few months
>
> It looks ok in windows 11 with both icon selected/unselected
> 
> ![image](https://github.com/user-attachments/assets/34fd2ba2-40c7-47f5-a241-6f16a90d3b26)
> 
> ![image](https://github.com/user-attachments/assets/0d175b8f-f2f8-489b-a6e9-2aa9f17d1a70)
> 
> I would like to know how it looks in windows 10? Is there any issue?
> 
> Although, as per https://bugs.openjdk.org/browse/JDK-8349268 windows 10 is not supported in JDK25 and this fix is going in mainline jdk25

> I dont think we can tamper with text location as it is done in WindowsMenuItemUI#paintText which does not have any knowledge of bullet/icon presence.

Why can't we?

`paintText` paints the text into a rectangle that's passed to it. It's up to menu layout code to determine at what location the text should be painted.

If we want to mimic Windows 11 File Explorer menu, which we should because it's the platform app that renders both radio-bullets and icons in its menu, then we need to update the menu layout code???otherwise the spacing between icons and text is way off.

The currently suggested fix can be used as a workaround, however, I'd rather we do it in a consistent way with what Windows 11 File Explorer does.

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

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

From prr at openjdk.org  Thu Feb  6 18:11:26 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Feb 2025 18:11:26 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <RfR3HY5eX4XBw4RrR0e51_RIx5FY54uAgHbFnb1nqN4=.74a0e725-9994-47b0-9dea-36f524579933@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

https://openjdk.org/groups/client-libs/
See "Code Reviews" where it says
"The standard requirement in the JDK project is for one reviewer to approve the fix.
The Java Client Library Group has always standardized on two approvals."
...
"The fixer therefore needs to understand the policies and wait for a second approval."

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2640628859

From aivanov at openjdk.org  Thu Feb  6 18:16:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 6 Feb 2025 18:16:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v9]
In-Reply-To: <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
Message-ID: <W8s1Z5i3oU3g2Nu14qqyQ3wyennkRaOWZeUOfv3M9w4=.9dfb1aac-12a6-47c1-9bf4-f92b59f7d4bf@github.com>

On Tue, 4 Feb 2025 14:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retain diff of OFFSET between skin background start coord and skin coordinate

On that note, Swing's menu rendering doesn't blend with the way Windows 11 renders menus:

1. Menu has rounded corners,
2. The highlight color is just slightly darked than the menu background,
3. The highlight rectangle also has rounded.
 
![A highlighted menu item Windows-11-highlighted-menu-item-in-Explorer](https://github.com/user-attachments/assets/0f7de244-58f4-42c5-b8da-2461ce04b1d0)

This is out of scope of this issue, I just wanted to bring it up. I guess I should submit a bug against this, it would be more relevant as support for Windows 10 is phased out. Swing uses the theming API to paint menus, yet it differs now.

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2640637956

From prr at openjdk.org  Thu Feb  6 18:24:17 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 6 Feb 2025 18:24:17 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v9]
In-Reply-To: <aeyjcyic9_JQkn_FjNMnRcU47mB84_rXQwSQrqT0JfI=.bf587809-4a37-4124-8e0c-3c2baa0e64f2@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <w59klf7rxjl0-6-NhwvKZmCqvS8cJ2VZKINLJ1L1w1E=.40e88333-28b4-4c07-b4d4-ce08b47f5db5@github.com>
 <RPqTDjE6NOvoQ5us_FQX4Mtqr9YfVAh0uoPU-4oU6f4=.5154adec-7a08-42da-a92f-d58f05f7eb02@github.com>
 <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
 <8Sj3SToTviecMDZ-chc4NjOaK37UU1DY4yl50dgZ6qM=.2630a783-2536-4c1d-9bb3-921bc908854c@github.com>
 <aeyjcyic9_JQkn_FjNMnRcU47mB84_rXQwSQrqT0JfI=.bf587809-4a37-4124-8e0c-3c2baa0e64f2@github.com>
Message-ID: <CY1ZhgSu-b648v3DRWRm9P_pzRMWZwQKwt9-X544PH8=.bd3f5f48-db6b-4521-9440-cea454abfd6b@github.com>

On Thu, 6 Feb 2025 10:30:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I am 100% for breaking it. We should never have allowed it.
> 
> But why? It is allowed by the icc spec, such profiles do not break any rules.

You are the only person who reads it this way.
What is a CMM implementation to do when it sees values, tags, etc which are not in the spec. ?
In most cases, probably not what was intended.

So we have seen your concern, discussed it, responded, and are satisfied that our response is sufficient to address those concern.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2640639861

From honkar at openjdk.org  Thu Feb  6 18:24:17 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 6 Feb 2025 18:24:17 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v9]
In-Reply-To: <aeyjcyic9_JQkn_FjNMnRcU47mB84_rXQwSQrqT0JfI=.bf587809-4a37-4124-8e0c-3c2baa0e64f2@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <w59klf7rxjl0-6-NhwvKZmCqvS8cJ2VZKINLJ1L1w1E=.40e88333-28b4-4c07-b4d4-ce08b47f5db5@github.com>
 <RPqTDjE6NOvoQ5us_FQX4Mtqr9YfVAh0uoPU-4oU6f4=.5154adec-7a08-42da-a92f-d58f05f7eb02@github.com>
 <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
 <8Sj3SToTviecMDZ-chc4NjOaK37UU1DY4yl50dgZ6qM=.2630a783-2536-4c1d-9bb3-921bc908854c@github.com>
 <aeyjcyic9_JQkn_FjNMnRcU47mB84_rXQwSQrqT0JfI=.bf587809-4a37-4124-8e0c-3c2baa0e64f2@github.com>
Message-ID: <LWqZK5V7mHO943RwBbwbx7JDFmDr-xDS8MH0uVX3w5A=.8856bdd4-e002-4268-8c78-e595c43d10f3@github.com>

On Thu, 6 Feb 2025 10:30:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > Non-ICC intents are not something we'd support. I see absolutely no problem with that.
>>> > If a profile has an intent that is unknown to JDK APIs, it doesn't matter what LCMS might do with it
>>> > if you were programming directly to LCMS as a CMM.
>>> 
>>> non-cc intents in lcms are just examples of profiles in the wild that don't violate the icc spec, currently such profiles can be loaded and used for conversion, this patch will break that. Why we should apply this limit and do that now?
>>> 
>>> Note that it is possible to use custom intents as well, and we will break it:
>>> 
>>> > Little CMS plug-in architecture allows to implement user-defined intents
>>> 
>>> > Who knows how many things we'd have to do in order to support 'custom' ICC intents.
>>> 
>>> Then let's at least not break it intentionally. Then test and fix if it does not work.
>> 
>> I am 100% for breaking it. We should never have allowed it.
>
>> I am 100% for breaking it. We should never have allowed it.
> 
> But why? It is allowed by the icc spec, such profiles do not break any rules.

@mrserb 
Thank you for taking time to review this PR. Your suggestions to move up the validation check logic in `.getInstance()` and to check deserialization path helped to make the fix better.

At this point, going with what is explicitly stated in ICC Spec seems to be a reasonable fix and the current fix will be integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2640645806

From honkar at openjdk.org  Thu Feb  6 18:33:19 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 6 Feb 2025 18:33:19 GMT
Subject: Integrated: JDK-8347377 : Add validation checks for ICC_Profile header
 fields
In-Reply-To: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
Message-ID: <44rFeuCdCT_jZGjgner64mslTyYO97G54SKRMXEMIMg=.ca8530fe-0946-4452-bb4b-f88d7f619395@github.com>

On Fri, 10 Jan 2025 19:06:41 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases.
> 
>  `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). 
> 
> - Profile/Device class
> - Color Space
> - Rendering Intent
> - PCS
> - Header Size check (ICC Header Size = 128 bytes)
> 
> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods.
> 
> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf

This pull request has now been integrated.

Changeset: ed8945a6
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed8945a68a67dd51a7cfa332905941afccc12b36
Stats:     327 lines in 4 files changed: 325 ins; 0 del; 2 mod

8347377: Add validation checks for ICC_Profile header fields

Reviewed-by: prr, jdv

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

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

From achung at openjdk.org  Thu Feb  6 22:03:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 6 Feb 2025 22:03:54 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v15]
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: <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>

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

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - merge
 - update specifications, replace default values in specifications with links to default var
 - update glide in test
 - merge
 - fix test with removed robot.glide using points
 - add code tag to specifications in Robot
 - fix syncdelay in ER
 - removing lesser used overridden methods
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
 - update specification to public default fields, add waitforidle exceptions to specifications
 - ... and 12 more: https://git.openjdk.org/jdk/compare/10791477...30ca6a6b

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

Changes: https://git.openjdk.org/jdk/pull/22044/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=14
  Stats: 818 lines in 236 files changed: 205 ins; 433 del; 180 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 honkar at openjdk.org  Thu Feb  6 23:53:10 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 6 Feb 2025 23:53:10 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File
In-Reply-To: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
Message-ID: <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>

On Tue, 4 Feb 2025 20:26:45 GMT, anass baya <duke at openjdk.org> wrote:

> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
> 
> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
> 
> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
> 
> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.

Tested it on Windows. Changes look good. 
Does CI testing look good on all platforms?

test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java line 26:

> 24: /*
> 25:   @test
> 26:   @key headful

Suggestion:

/*
 * @test
 * @key headful

test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java line 47:

> 45:     private static final int SIZE = 100;
> 46:     // Allow a margin tolerance of 1 pixel due to scaling
> 47:     private static final int MARGIN_TOLERANCE = 1;

Since this test is extended to both single and multi monitor, I think tolerance can be increased to 2-3 (considering this test runs on CI now).

test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java line 106:

> 104:                     || bounds.y + insets.top != frameBounds.y
> 105:                     || Math.abs((bounds.width - insets.right - insets.left) - frameBounds.width) > MARGIN_TOLERANCE
> 106:                     || Math.abs((bounds.height - insets.bottom - insets.top) - frameBounds.height) > MARGIN_TOLERANCE) {

Line length exceeds 80 characters.

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

PR Review: https://git.openjdk.org/jdk/pull/23449#pullrequestreview-2600183614
PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1945626262
PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1945623601
PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1945568847

From psadhukhan at openjdk.org  Fri Feb  7 03:12:15 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 03:12:15 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v9]
In-Reply-To: <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
Message-ID: <vtvwnh6bVamrPKYY-p3G2hRlIrX2KAvt4xviIpMcybc=.1417ccf1-4a73-4106-aec2-42428ef07507@github.com>

On Tue, 4 Feb 2025 14:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retain diff of OFFSET between skin background start coord and skin coordinate

> I tested it on Windows 11 and 10.
> 
> **Windows 11** ![Windows-11-menu-items-2025-02-06](https://private-user-images.githubusercontent.com/70774172/410576669-e368f0ce-3c0f-45d6-a485-3c5331471204.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg4OTc0MzIsIm5iZiI6MTczODg5NzEzMiwicGF0aCI6Ii83MDc3NDE3Mi80MTA1NzY2NjktZTM2OGYwY2UtM2MwZi00NWQ2LWE0ODUtM2M1MzMxNDcxMjA0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA3VDAyNTg1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE2NTY2YmRmZDliMmU5ODcyNjUyMjI2MWQxOTMxNGIxMzhkMmJkOGQzNThmNWM4ZTYxYzA5ZTFjNDA2NjBjMGYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.FdAMEYOhNS3AyYW9pX0ia7pAsvR1mhpyNFN9h01MuL8) It looks reasonably well?
> 
> But it doesn't look like the menu in Windows 11 File Explorer, does it? ![Windows 11 File Explorer View with icons (100%)](https://private-user-images.githubusercontent.com/70774172/410576902-53fd8ba9-00f7-4126-a238-ab162ff54325.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg4OTc0MzIsIm5iZiI6MTczODg5NzEzMiwicGF0aCI6Ii83MDc3NDE3Mi80MTA1NzY5MDItNTNmZDhiYTktMDBmNy00MTI2LWEyMzgtYWIxNjJmZjU0MzI1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA3VDAyNTg1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTQ5YjRhYWUyZGYxODkyMmMxNWQyMTQ4OGNkM2M5N2M0ZWUwMTllYTJiMDBjYTUxNmM3YTg1YzcxYmU1MmI0YjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.LNaIqN5mjLKZDjElsheeNpWhqqL41c9wqXfCFMdtBTc) Windows L&F should look like native apps do, and we're not there yet with the menu rendering.
> 
> **Windows 10** ![Windows-10-menu-items-2025-02-06](https://private-user-images.githubusercontent.com/70774172/410577351-e2d64c81-3831-4f20-93ea-f9e85f5ce5aa.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg4OTc0MzIsIm5iZiI6MTczODg5NzEzMiwicGF0aCI6Ii83MDc3NDE3Mi80MTA1NzczNTEtZTJkNjRjODEtMzgzMS00ZjIwLTkzZWEtZjllODVmNWNlNWFhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA3VDAyNTg1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTE1NjUyZWQ2ZjJmZjQzM2VmMzZiMTNkNjhhZTU2N2NkMjA1ZDU5YzA2MGVlM2EzZGRhZGI0ZjU0ZDgzNGZkOGImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.jM3mD5sW8UzdiY6i_BIF7Dm9SvuImyVYDp831E-2sYk) It looks bad because neither icon is where it should be.
> 
> Without the fix, it looks good: ![Windows-10-menu-items-no-fix-2025-02-06](https://private-user-images.githubusercontent.com/70774172/410577950-684c9461-e47e-46de-a609-7bd9724099cb.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg4OTc0MzIsIm5iZiI6MTczODg5NzEzMiwicGF0aCI6Ii83MDc3NDE3Mi80MTA1Nzc5NTAtNjg0Yzk0NjEtZTQ3ZS00NmRlLWE2MDktN2JkOTcyNDA5OWNiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA3VDAyNTg1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTZlOTMxODdkNTQxMjhkNDZjMzZiYjhlNDkxNzBjODI3MTBlZGQ5MTA5ZTExYTQ5OWU5YTA1MzJhYjE5Y2VhODMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.A8WiqJm1sFLaPXUmbYHiigZiO9c6ZH6UUrjI7Ndy0bU) And one can see if an item is selected or not. Yet they changed the skin in Windows 11, now it's impossible to distinguish them.

I am not sure if we can satisfy both windows 10 and windows 11 simultaneously as both design is different for this logic...
Without the fix, it looks good as Windows 10  as it doesn't support separate bullet/checkmark skin whereas windows 11 does...Also, its difficult to test for me as I do not have windows 10 so any change for windows 11 whether it works for windows10 is difficult to make out, also considering the fact mainline jdk is not supporting windows10 so not sure why we should introduce additional logic to satisfy windows10

Also, Windows 11 there is another thing I noticed which is without icon, the bullet/checkmark is drawn at the icon location and do not have its own space, so we need to bring back the if (icon == null) logic which we removed to render the skin always at specified location..

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2641830140

From psadhukhan at openjdk.org  Fri Feb  7 03:30:18 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 03:30:18 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v9]
In-Reply-To: <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
Message-ID: <0O66flWaJaK3dWt7dgU4-fibTwNJMN2tL9nPSuS0eG4=.deab23b0-2dec-458b-8e16-4ff75d4424d7@github.com>

On Tue, 4 Feb 2025 14:16:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retain diff of OFFSET between skin background start coord and skin coordinate

skin =  xp.getSkin(c, backgroundPart);
                            skin.paintSkin(g, x - 2 * OFFSET, y,
                                getIconWidth(), getIconHeight(), backgroundState);
                            skinWidth = getIconWidth();

@aivanov-jdk  Can you please check if we use getIconWidth() instead of skin.getWidth, does the icon stay clear of the bullet/checkmark background skin in windows 10?

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2641846800

From psadhukhan at openjdk.org  Fri Feb  7 05:26:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 05:26:10 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
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: <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@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 two additional commits since the last revision:

 - remove test file
 - Move text position w.r.t menuItem icon

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/31cdc707..5742db5b

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

  Stats: 252 lines in 4 files changed: 153 ins; 97 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

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

From psadhukhan at openjdk.org  Fri Feb  7 05:31:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 05:31:12 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
Message-ID: <0OyCWA7Dx6O4NIxaD84PBNXL75PsmpXNW1zqaHHSHtw=.83064f23-c39e-4263-948e-f7bb7c75c1c8@github.com>

On Fri, 7 Feb 2025 05:26:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test file
>  - Move text position w.r.t menuItem icon

It seems in windows 11, the menuitem text location is dependant on presence of menuitem icon. As per this screenshot, the bullet/checkmark seems to be in its fixed location but text is shifted depending on menuitem icon.

![image](https://github.com/user-attachments/assets/6b6e4570-8f3b-41f3-a200-4d9362321e8d)

![image](https://github.com/user-attachments/assets/f26a71f4-d6e2-4848-9c48-27c3f40f763e)

Modified the PR to look the same.

![image](https://github.com/user-attachments/assets/7d636add-f336-4db3-96cd-d8fe06737b3a)

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2641979241

From psadhukhan at openjdk.org  Fri Feb  7 06:55:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 06:55:12 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <Eu0XxQ_F8x4ZMF7t0Qozg8q8MOZEHrwNbhTFH0zPmvY=.179cd061-bd3f-4552-b1d1-946c24759b37@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <1fjzUR1RxWAEpbja0uaJmAeSZgln-UQsZ4ESiBUL7Gc=.8e307676-4331-4336-bf37-8968b7db3ed2@github.com>
 <Bl_10if9N9POKQAp0xJ-qHJFSgrV76cUU0G76DV0-XE=.bff59cae-88bf-4fd0-9d52-b6c49ed0b593@github.com>
 <Eu0XxQ_F8x4ZMF7t0Qozg8q8MOZEHrwNbhTFH0zPmvY=.179cd061-bd3f-4552-b1d1-946c24759b37@github.com>
Message-ID: <ixG11q2tDAjejiEu7xOATivRqRjMujprpTU9zlU9eoQ=.02c08853-6931-4914-8821-31842a28bfad@github.com>

On Thu, 6 Feb 2025 17:28:59 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> I initially separated it to make it clear that this is for focus. I'll edit this and modify the existing comment to include null focus.
>
> I tested different ways to merge this block with the below blocks. I'm not sure if it makes sense to do so now because it wouldn't be as simple as adding `|| focusOwner == null` to the first if-statement or appending the logic to the `else` block. I would still need another if or else/if block regardless. And I think it's harder to follow than the current implementation. Let me know if you prefer it a different way, but I think the current implementation is better for now.

I was thinking more of `if (!par.isEnabled() !! focusOwner == null)` as the parent is still JFrame.

But, I was trying to run the testcase mentioned in the JBS and this regression test but I am not able to reproduce without the fix..
It doesn't keep on scrolling when it regains focus in my windows 11 machine..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1946037272

From psadhukhan at openjdk.org  Fri Feb  7 06:59:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 06:59:11 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
Message-ID: <9X3rSbuK4FK1Qk_KFmyZtJI2Ar7jSIpgR0W6a8mEABo=.28a5d0f0-828d-4198-a904-e87d00f7225d@github.com>

On Mon, 3 Feb 2025 18:50:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset updates the pipewire headers to the latest available version.
> It contains the minimum set of required header files needed to build the JDK.
> 
> The updated headers are a direct copy from the 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
>  
> Testing looks good.

When you say "Testing looks good" you mean the normal jtreg client testsuite or any other specific testing that was done?

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23426#pullrequestreview-2600940292

From psadhukhan at openjdk.org  Fri Feb  7 07:49:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 07:49:55 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <jO6bZ4tJBaaU_rY2DnxtQO-5jdyzKmyowx2m4IhJOTM=.5d334cee-ce5c-4fef-a2a9-bf10c70fa4d8@github.com>

On Wed, 5 Feb 2025 07:03:26 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 1578:

> 1576:         }
> 1577:         if (options != null && !options.isEmpty()) {
> 1578:             optionArgs = options.trim().split("\\s+");

In what format the options are expected for this regex to work? Is it same for both linux and mac?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1946078572

From duke at openjdk.org  Fri Feb  7 08:11:10 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 7 Feb 2025 08:11:10 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time
In-Reply-To: <jO6bZ4tJBaaU_rY2DnxtQO-5jdyzKmyowx2m4IhJOTM=.5d334cee-ce5c-4fef-a2a9-bf10c70fa4d8@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <jO6bZ4tJBaaU_rY2DnxtQO-5jdyzKmyowx2m4IhJOTM=.5d334cee-ce5c-4fef-a2a9-bf10c70fa4d8@github.com>
Message-ID: <jFUc2JvaXxK5w4R8pBAabBNAY4_NR_GHliguO_nZ6Fs=.d1c00367-acb4-4770-80e9-4c2dade7bf83@github.com>

On Fri, 7 Feb 2025 07:38:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 1578:
> 
>> 1576:         }
>> 1577:         if (options != null && !options.isEmpty()) {
>> 1578:             optionArgs = options.trim().split("\\s+");
> 
> In what format the options are expected for this regex to work? Is it same for both linux and mac?

The format is space delimited values, each value is a "key=value". 
There is no difference between Linux and Mac and there are no changes in the format of the options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1946119634

From psadhukhan at openjdk.org  Fri Feb  7 08:16:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 7 Feb 2025 08:16:10 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time
In-Reply-To: <jFUc2JvaXxK5w4R8pBAabBNAY4_NR_GHliguO_nZ6Fs=.d1c00367-acb4-4770-80e9-4c2dade7bf83@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <jO6bZ4tJBaaU_rY2DnxtQO-5jdyzKmyowx2m4IhJOTM=.5d334cee-ce5c-4fef-a2a9-bf10c70fa4d8@github.com>
 <jFUc2JvaXxK5w4R8pBAabBNAY4_NR_GHliguO_nZ6Fs=.d1c00367-acb4-4770-80e9-4c2dade7bf83@github.com>
Message-ID: <ZWBf-HwigZajqqEdHTd915RKjcub55ht8nE0Paneu-s=.74a51b69-15c5-4e45-ae54-4d1d0694d350@github.com>

On Fri, 7 Feb 2025 08:08:39 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 1578:
>> 
>>> 1576:         }
>>> 1577:         if (options != null && !options.isEmpty()) {
>>> 1578:             optionArgs = options.trim().split("\\s+");
>> 
>> In what format the options are expected for this regex to work? Is it same for both linux and mac?
>
> The format is space delimited values, each value is a "key=value". 
> There is no difference between Linux and Mac and there are no changes in the format of the options.

If it's a space delimited values, then can't we use "options.trim().split(" ")" 
same as what we have been using below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1946125709

From abhiscxk at openjdk.org  Fri Feb  7 08:17:12 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 7 Feb 2025 08:17:12 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
Message-ID: <skGVSM2e5A0RTsyuVvkYUA0BVGcdY5ycaO7io8_Ceh8=.0fea4521-1408-4721-8715-3da30e1fb32c@github.com>

On Wed, 5 Feb 2025 11:50:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Nothing stops you from doing so? 
>> 
>> I agree but I have never seen any application which is having a single RadioButton for selection.
>> 
>>> I still think the condition in the radio button case should be the same: Object.equals handles all the cases, and the code becomes consistent. Otherwise, the radio button stands out? for no apparent reason.
>> 
>> For consistency, it can be done. I need to check if it impacts on VO announcement.
>
>> For consistency, it can be done. I need to check if it impacts on VO announcement.
> 
> It shouldn't impact the announcements. One button gets deselected, another one gets selected?
> 
> Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when selection moves to another button.
> 
> What about the case where currently focused or unfocused selected button gets deselected programmatically? Is there an interactive way to deselect a radio button when it's the only button in its own group?
> 
> This *needs more testing*.

@aivanov-jdk I think we should not change RadioButton's implementation as the announcement is not consistent. 
Do you have any other suggestion ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1946126891

From duke at openjdk.org  Fri Feb  7 08:24:54 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 7 Feb 2025 08:24:54 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v2]
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <k6TZ0TTd-CQnoB-7SvXWh701Hf_hzScujtVnOSKLSZU=.44ec1d04-559a-4112-8aaa-d363e445fad7@github.com>

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

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

  replace regexp s+ with space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23457/files
  - new: https://git.openjdk.org/jdk/pull/23457/files/03825076..9b35b93a

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

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

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

From duke at openjdk.org  Fri Feb  7 08:24:55 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 7 Feb 2025 08:24:55 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v2]
In-Reply-To: <ZWBf-HwigZajqqEdHTd915RKjcub55ht8nE0Paneu-s=.74a51b69-15c5-4e45-ae54-4d1d0694d350@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <jO6bZ4tJBaaU_rY2DnxtQO-5jdyzKmyowx2m4IhJOTM=.5d334cee-ce5c-4fef-a2a9-bf10c70fa4d8@github.com>
 <jFUc2JvaXxK5w4R8pBAabBNAY4_NR_GHliguO_nZ6Fs=.d1c00367-acb4-4770-80e9-4c2dade7bf83@github.com>
 <ZWBf-HwigZajqqEdHTd915RKjcub55ht8nE0Paneu-s=.74a51b69-15c5-4e45-ae54-4d1d0694d350@github.com>
Message-ID: <wWESl_ypTvrLuu6IFHhFqL23dVlaUbza8NiHVSEyZnw=.2543a4d9-c1e4-4d8c-9c01-8f5575fbb5e0@github.com>

On Fri, 7 Feb 2025 08:13:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The format is space delimited values, each value is a "key=value". 
>> There is no difference between Linux and Mac and there are no changes in the format of the options.
>
> If it's a space delimited values, then can't we use "options.trim().split(" ")" 
> same as what we have been using below?

Sure, done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1946135211

From serb at openjdk.org  Fri Feb  7 08:31:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 7 Feb 2025 08:31:19 GMT
Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header
 fields [v9]
In-Reply-To: <CY1ZhgSu-b648v3DRWRm9P_pzRMWZwQKwt9-X544PH8=.bd3f5f48-db6b-4521-9440-cea454abfd6b@github.com>
References: <EKrtfxeRzdp_z25AHsQC1iG6W2Y8A4_-MMbsF6ToXBc=.893c641c-2526-40ac-9c0d-d7d0a2c67d22@github.com>
 <w59klf7rxjl0-6-NhwvKZmCqvS8cJ2VZKINLJ1L1w1E=.40e88333-28b4-4c07-b4d4-ce08b47f5db5@github.com>
 <RPqTDjE6NOvoQ5us_FQX4Mtqr9YfVAh0uoPU-4oU6f4=.5154adec-7a08-42da-a92f-d58f05f7eb02@github.com>
 <Kib-KYXQXjIutZ8qiX-UyrhbQQpfbIVAyR8xztdpS0A=.b41950d1-7473-4ad3-a998-e5bfd841b098@github.com>
 <8Sj3SToTviecMDZ-chc4NjOaK37UU1DY4yl50dgZ6qM=.2630a783-2536-4c1d-9bb3-921bc908854c@github.com>
 <aeyjcyic9_JQkn_FjNMnRcU47mB84_rXQwSQrqT0JfI=.bf587809-4a37-4124-8e0c-3c2baa0e64f2@github.com>
 <CY1ZhgSu-b648v3DRWRm9P_pzRMWZwQKwt9-X544PH8=.bd3f5f48-db6b-4521-9440-cea454abfd6b@github.com>
Message-ID: <ebP97GJRQz8V0vY0dM-xo8pFrxanpE4clSvx4MPAAHQ=.1ce4c6b9-c57a-4768-8480-d91dee575a16@github.com>

On Thu, 6 Feb 2025 18:14:26 GMT, Phil Race <prr at openjdk.org> wrote:

>You are the only person who reads it this way.

So do you think that kcms/lcms do not follow the icc specification? and the whole feature to support lcms specific and custom/applications specific intents are useless? Its even described in the docs. 

You haven't given any reason why this needed to be changed. And I don't understand why we haven't asked lcms owners for clarification on this.

>What is a CMM implementation to do when it sees values, tags, etc which are not in the spec. ?
>In most cases, probably not what was intended.

Was the decision made based on that "probably"? This will certainly limit the feature pool for Java applications ?ompared to other native libraries that use lcms.

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

PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2642243185

From mbaesken at openjdk.org  Fri Feb  7 10:54:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Feb 2025 10:54:10 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
Message-ID: <GRo80sk7wuvZD6FGwsCDd3G3ZvZ2FzlnNii-V2VWMt8=.f17faf4e-233c-46d4-8608-c52be65bb74e@github.com>

On Thu, 6 Feb 2025 14:03:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The splashscreen lib is currently built with LOW optimization.
>> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
>> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
>> 
>> current settings (LOW optimization) :
>> ---------------------------------------------------
>> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
>> 
>> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> 
>> new settings (SIZE optimization) :
>> --------------------------------------------------
>> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
>> 
>> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> On Linux aarch64 only the debuginfo shrinks but the lib stays abo...
>
> I think this looks good, but someone from client should probably also weigh in.

Hi @erikj79  thanks for the review !

@magicus , @mrserb , @honkar-jdk  any comments?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2642577698

From aivanov at openjdk.org  Fri Feb  7 11:16:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Feb 2025 11:16:16 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v9]
In-Reply-To: <vtvwnh6bVamrPKYY-p3G2hRlIrX2KAvt4xviIpMcybc=.1417ccf1-4a73-4106-aec2-42428ef07507@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <CTK9gIwWXqD5OhMKWRPSjw5Ox1L6Ty9k7QtIYu1-Tuo=.64830d24-d65c-45b7-83cd-2607164f715b@github.com>
 <vtvwnh6bVamrPKYY-p3G2hRlIrX2KAvt4xviIpMcybc=.1417ccf1-4a73-4106-aec2-42428ef07507@github.com>
Message-ID: <4KebE9lR7pvldqnGsD40mMXya0S7fonlSKd9HmhR0WU=.6a2fa329-8c44-4708-9f76-c2b86a2a893d@github.com>

On Fri, 7 Feb 2025 03:10:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I am not sure if we can satisfy both windows 10 and windows 11 simultaneously as both design is different for this logic...

We absolutely can? I'm not proposing using different rendering, instead I'm for following Windows 11 rendering, but it requires updating menu layout code.

> Without the fix, it looks good as Windows 10 as it doesn't support separate bullet/checkmark skin whereas windows 11 does...

I'm unsure Windows 11 does support it natively, likely File Explorer implements custom drawing code.

I'm pretty sure the situation is the same with Windows 10, yet none of use was able to find an app which displays both icons and bullets/check-marks.

The commonly available feature in Windows is to display an icon, which you can see in window menu activated by <kbd>Alt</kbd>+<kbd>Space</kbd> or right-clicking the window title bar: Restore, Minimise, Maximise, and Close items display an icon ? this icon is rendered centred exactly at the position where radio bullet or check mark are.

I may be able to play around in a Win32 app with it.

> Also, its difficult to test for me as I do not have windows 10 so any change for windows 11 whether it works for windows10 is difficult to make out, also considering the fact mainline jdk is not supporting windows10 so not sure why we should introduce additional logic to satisfy windows10

My point here is that the current approach doesn't look similar to how File Explorer renders menu with bullets and icons. If you do it, this style would work just fine for Windows 10 too: the bullet will have its own place, the icon will have its own place.

Even though Windows 10 is not going to be supported by JDK 25, it doesn't make sense to break anything that works there. After all, we had to restore theming support for Windows 7 support for which ended long-long time ago.

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2642621656

From aivanov at openjdk.org  Fri Feb  7 11:26:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Feb 2025 11:26:10 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
Message-ID: <zIJze9EAWB7Xt97gC_RskcX94sasL_eg6hlfI0hi_MA=.81c2eec2-069f-4ab5-a7f8-50be0a2685ee@github.com>

On Wed, 5 Feb 2025 11:50:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Nothing stops you from doing so? 
>> 
>> I agree but I have never seen any application which is having a single RadioButton for selection.
>> 
>>> I still think the condition in the radio button case should be the same: Object.equals handles all the cases, and the code becomes consistent. Otherwise, the radio button stands out? for no apparent reason.
>> 
>> For consistency, it can be done. I need to check if it impacts on VO announcement.
>
>> For consistency, it can be done. I need to check if it impacts on VO announcement.
> 
> It shouldn't impact the announcements. One button gets deselected, another one gets selected?
> 
> Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when selection moves to another button.
> 
> What about the case where currently focused or unfocused selected button gets deselected programmatically? Is there an interactive way to deselect a radio button when it's the only button in its own group?
> 
> This *needs more testing*.

> @aivanov-jdk I think we should not change RadioButton's implementation as the announcement is not consistent. Do you have any other suggestion ?

Yes, I agree.

I just wanted to test it myself too, and I haven't been able to yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1946381166

From aivanov at openjdk.org  Fri Feb  7 11:33:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Feb 2025 11:33:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <0OyCWA7Dx6O4NIxaD84PBNXL75PsmpXNW1zqaHHSHtw=.83064f23-c39e-4263-948e-f7bb7c75c1c8@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <0OyCWA7Dx6O4NIxaD84PBNXL75PsmpXNW1zqaHHSHtw=.83064f23-c39e-4263-948e-f7bb7c75c1c8@github.com>
Message-ID: <9N5jLOCe5RC77ReUfi-1Mg4bBRaC2t4v3ZWIqv1wd8A=.cb9ff327-973a-48ad-94a0-3ae5eb7e1d02@github.com>

On Fri, 7 Feb 2025 05:28:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems in windows 11, the menuitem text location is dependant on presence of menuitem icon. As per this screenshot, the bullet/checkmark seems to be in its fixed location but text is shifted depending on menuitem icon.

That's what [I said](https://github.com/openjdk/jdk/pull/23324#issuecomment-2624442850):

> If we add support for painting both an ImageIcon and the bullet / check-mark, the layout of the menu item has to change.

---

> Modified the PR to look the same.

Thank you. I'll test it.

However, I think that all text in a popup menu should move to the right? that is all text in menu items should remain aligned if there bullets/check-marks and icons in a particular popup menu. That is the text for the third menu items for radio button and for check mark should also move.

Whether all text is aligned [could be controlled by a property](https://github.com/openjdk/jdk/pull/23324#discussion_r1941070014):

> We may introduce a property that controls this behaviour: whether the text aligns in all the menu items or not.

There's a sample in [the linked message](https://github.com/openjdk/jdk/pull/23324#discussion_r1941070014).

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2642667698

From azvegint at openjdk.org  Fri Feb  7 12:33:01 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 7 Feb 2025 12:33:01 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <9X3rSbuK4FK1Qk_KFmyZtJI2Ar7jSIpgR0W6a8mEABo=.28a5d0f0-828d-4198-a904-e87d00f7225d@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
 <9X3rSbuK4FK1Qk_KFmyZtJI2Ar7jSIpgR0W6a8mEABo=.28a5d0f0-828d-4198-a904-e87d00f7225d@github.com>
Message-ID: <S8VQq7IsF5hJGIr7aQjhGVyAV8sJMxFafbsFtyuRz2s=.38f8683a-5f9f-4a4e-aecc-89887d933c9d@github.com>

On Fri, 7 Feb 2025 06:57:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When you say "Testing looks good" you mean the normal jtreg client testsuite or any other specific testing that was done?

normal jtreg client testsuite + manual testing

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

PR Comment: https://git.openjdk.org/jdk/pull/23426#issuecomment-2642793856

From ihse at openjdk.org  Fri Feb  7 13:11:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Feb 2025 13:11:16 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

What tests have you run?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2642863817

From ihse at openjdk.org  Fri Feb  7 13:17:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Feb 2025 13:17:17 GMT
Subject: RFR: 8348286: [AIX] clang 17 introduces new warning
 Wtentative-Definitions which produces Build errors [v3]
In-Reply-To: <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
References: <Y1MNMWR4cYqet2mgF9EgeWosB6eG5ImOVjyn3ncjAW8=.3a771b94-ba15-4e2d-a8ac-cc7aca483653@github.com>
 <oEqtKZ5mGA9GUAdhI_JCfTbyxbWHX8C9ymfXSP7wmvY=.7bd4705a-feb5-45d4-97ef-f59d8b625d62@github.com>
Message-ID: <WDYNPWYMFKfxih_Lk45l_UuXionPmR26TYneKqgLRA4=.58403f7c-93e7-40f8-8880-ebde14d36830@github.com>

On Thu, 23 Jan 2025 13:48:06 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan.
>> Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror.
>> One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found:
>> /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions]
>>    36 | IMGEXTERN jfieldID g_BImgRasterID;
>>       | ^
>> From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g.
>> imageInitIDs.h:36:20
>>    36 extern jfieldID g_BImgRasterID;
>> and the corresponding c-File
>>    jfieldID g_BImgRasterID;
>> 
>> The other possible solution would be to compile everything with
>> -Wno-tentative-definitions
>> which could be set in flags-cflags.m4, if compiling with clang 17.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove old solution

> I think `-Wtentative-definition` doesn't really buy all that much. [...] But I don't think I'd want to globally disable it, as it seems like it would usually be a valid complaint

I think we all agree on that. Apparently clang 17 enables it by default, at least on AIX. So then we have the choice to either disable it or accept to have it on, and deal with what it complains about. 

These were the only problematic places in the entire code base. I think it was the right decision to change the code in these places. The code here was, if not "smelly" so at least not conforming to the practice used everywhere else in the code base. I personally think your workaround with disabling the warning seems like a worse solution compared to what was actually integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2642875242

From mbaesken at openjdk.org  Fri Feb  7 14:14:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Feb 2025 14:14:11 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
Message-ID: <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>

On Fri, 7 Feb 2025 13:08:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> What tests have you run?

Had this in our internal test queue with jtreg / JCK  plus some additional SAP internal tests. No issues seen.
However I think I have to run some more manual tests on client  like  setups.

Unfortunately my Linux terminal server does not like the awt jtreg tests (with and without my patch) , so I have to find something else.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2643047402

From aivanov at openjdk.org  Fri Feb  7 16:37:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Feb 2025 16:37:12 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File
In-Reply-To: <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>
Message-ID: <SxvHNw49f7gWTrpRcYH9q-677-2g5_2SpZULunyFi4s=.b1f1a722-26a4-44cd-96d5-10c066abe3c2@github.com>

On Thu, 6 Feb 2025 23:45:43 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
>> 
>> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
>> 
>> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
>> 
>> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.
>
> test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java line 47:
> 
>> 45:     private static final int SIZE = 100;
>> 46:     // Allow a margin tolerance of 1 pixel due to scaling
>> 47:     private static final int MARGIN_TOLERANCE = 1;
> 
> Since this test is extended to both single and multi monitor, I think tolerance can be increased to 2-3 (considering this test runs on CI now).

Is it needed? If there are no failures, I see no reason to increase the tolerance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1946827397

From honkar at openjdk.org  Fri Feb  7 17:34:14 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Feb 2025 17:34:14 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File
In-Reply-To: <SxvHNw49f7gWTrpRcYH9q-677-2g5_2SpZULunyFi4s=.b1f1a722-26a4-44cd-96d5-10c066abe3c2@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>
 <SxvHNw49f7gWTrpRcYH9q-677-2g5_2SpZULunyFi4s=.b1f1a722-26a4-44cd-96d5-10c066abe3c2@github.com>
Message-ID: <FLNHZA1V3VsK5JYZJoiEKaOfE4Gw5jSOGqzNRlszCyg=.bb7ccc48-639b-4fce-b6a7-a95ee02b7f36@github.com>

On Fri, 7 Feb 2025 16:34:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java line 47:
>> 
>>> 45:     private static final int SIZE = 100;
>>> 46:     // Allow a margin tolerance of 1 pixel due to scaling
>>> 47:     private static final int MARGIN_TOLERANCE = 1;
>> 
>> Since this test is extended to both single and multi monitor, I think tolerance can be increased to 2-3 (considering this test runs on CI now).
>
> Is it needed? If there are no failures, I see no reason to increase the tolerance.

If it test runs fine on CI then it should be okay. Previously, I came across few tests which required increasing tolerance value (although not in this context but particularly for pixel color case).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1946905377

From aivanov at openjdk.org  Fri Feb  7 19:13:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Feb 2025 19:13:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
Message-ID: <zvfb0d2ryRCaS6UkKdNcsUho-r8SfxdXrmBAA-8lB7w=.7a9f5e0b-a90a-47dd-ac44-212d5067f418@github.com>

On Fri, 7 Feb 2025 05:26:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test file
>  - Move text position w.r.t menuItem icon

This is how it looks on Windows 10:  
![latest-fix-2025-02-07](https://github.com/user-attachments/assets/55ce3491-e52b-4491-93a8-1a3ebd686840)

It's close, yet the spacing is wrong.

The bullet / check-mark should be where they were before the fix. There was 8-pixel margin to the left of selected bullet background before the fix, now there are only 2 pixels.

The margin between the bullet background and the text was again 8 pixels, I think we should maintain the same margin between the bullet and the icon as well as between the icon and the menu text.

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2643787270

From aivanov at openjdk.org  Fri Feb  7 19:23:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Feb 2025 19:23:15 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
Message-ID: <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>

On Fri, 7 Feb 2025 05:26:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test file
>  - Move text position w.r.t menuItem icon

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 662:

> 660:         paintCheckIcon(g, lh, lr, holdc, foreground);
> 661:         paintIcon(g, lh, lr, holdc);
> 662:         if (UIManager.getLookAndFeel().getName().equals("Windows")

Can't this be handled in `WindowsMenuItemUI` instead? After all, Metal and Windows L&F looked differently.

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

> 1: /*

Does it have to be that long? `TestRadioAndCheckMenuItemWithIcon.java` looks descriptive enough.

test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItemAndJCheckBoxMenuItem.java line 118:

> 116:         buttonGroup1.add(check1);
> 117:         buttonGroup1.add(check2);
> 118:         buttonGroup1.add(check3);

I expect that each check-box can be selected independently from others.

test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItemAndJCheckBoxMenuItem.java line 137:

> 135:         frame.setJMenuBar(menuBar);
> 136:         frame.setSize(300, 300);
> 137:         frame.setLocationRelativeTo(null);

`setLocationRelativeTo` is redundant, the location of the frame is controlled by `PassFailJFrame`.

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

PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2602598579
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1947041075
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1947049448
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1947056340
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1947057458

From aivanov at openjdk.org  Fri Feb  7 19:33:09 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 7 Feb 2025 19:33:09 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File
In-Reply-To: <FLNHZA1V3VsK5JYZJoiEKaOfE4Gw5jSOGqzNRlszCyg=.bb7ccc48-639b-4fce-b6a7-a95ee02b7f36@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>
 <SxvHNw49f7gWTrpRcYH9q-677-2g5_2SpZULunyFi4s=.b1f1a722-26a4-44cd-96d5-10c066abe3c2@github.com>
 <FLNHZA1V3VsK5JYZJoiEKaOfE4Gw5jSOGqzNRlszCyg=.bb7ccc48-639b-4fce-b6a7-a95ee02b7f36@github.com>
Message-ID: <MKHDkY0sLjs_lIu1NZs88jLLdtfgpQLUsqdxhqBqzx4=.6987cec3-902b-4c80-85b1-2461484b1a31@github.com>

On Fri, 7 Feb 2025 17:29:58 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Is it needed? If there are no failures, I see no reason to increase the tolerance.
>
> If it test runs fine on CI then it should be okay. Previously, I came across few tests which required increasing tolerance value (although not in this context but particularly for pixel color case).

Tolerance when comparing colours is different from comparing sizes.

We know that fractional pixels after scaling up and down may be lost, that's where the tolerance comes from.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1947080032

From honkar at openjdk.org  Fri Feb  7 20:38:21 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Feb 2025 20:38:21 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java
In-Reply-To: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
Message-ID: <0ObwJI9sveEJS9-uLJ_5BZx7utuDzLXWVtuUSgpro9w=.716330e6-a4d6-4ecd-8f9c-efaa8ad91e61@github.com>

On Fri, 7 Feb 2025 19:50:03 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> FileDialogIconTest.java has been updated.
> 
> Following changes were made.
> 
> -  Test instructions updated
> -  BugID associated with the test is updated to the correct one
> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
> -  other minor cleanups

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 45:

> 43:  * @summary Test to verify that PIT File Dialog icon not matching with
> 44:  *          the new java icon (frame Icon) - PIT build
> 45:  * @requires (os.family == "windows")

The original test was created to check if the Frame and FileDialog icons match - [JDK-6425126](https://bugs.openjdk.org/browse/JDK-6425126)

There are some things that are not clear about the expected behavior for FileDialog icons.

- At present the FileDialog inherits the Frame icon (owner window) and does not change when the icon is explicit set to dialog using `dialog.setIconImage()/.setIconImages()`

- The JavaDoc for setIconImage() states - _"Ownerless windows with no icon specified use platform-default icon. The icon of an owned window may be inherited from the owner **unless explicitly overridden**."_
  
- In the test, the FileDialog  icon is overridden but it still inherits the owner window icon (Frame).  This is because the WindowPeer is null in case of FileDialog, thus updateIconImage() is not executed (updateIconImage() is not overriden in WFileDialogPeer). Is this the expected behavior?
https://github.com/openjdk/jdk/blob/f0ea38b3874ac627766768cbcd13f4be68c53797/src/java.desktop/share/classes/java/awt/Window.java#L674C1-L677C10

- There is also the question of additional buttons in the test that are meant to explicitly set icons to the FileDialog (but don't work). FileDialog icon gets updated only works when the Frame icon is updated (owner) and then Dialog is opened (via Load/Save/Simple dialog btn).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1947147492

From honkar at openjdk.org  Fri Feb  7 20:38:21 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Feb 2025 20:38:21 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java
Message-ID: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>

FileDialogIconTest.java has been updated.

Following changes were made.

-  Test instructions updated
-  BugID associated with the test is updated to the correct one
-  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
-  other minor cleanups

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

Commit messages:
 - test changes

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

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

From honkar at openjdk.org  Fri Feb  7 21:18:47 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Feb 2025 21:18:47 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v2]
In-Reply-To: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
Message-ID: <gk8XRh9BFK_rvGND6RMvvlgkILL5WgiGSVoVO47fcAo=.527d8df7-9a25-4d2d-bd32-064fb9a9c9e8@github.com>

> FileDialogIconTest.java has been updated.
> 
> Following changes were made.
> 
> -  Test instructions updated
> -  BugID associated with the test is updated to the correct one
> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
> -  other minor cleanups

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  spacing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23523/files
  - new: https://git.openjdk.org/jdk/pull/23523/files/20352059..5d7d497e

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

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

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

From duke at openjdk.org  Fri Feb  7 21:41:14 2025
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 7 Feb 2025 21:41:14 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v2]
In-Reply-To: <gk8XRh9BFK_rvGND6RMvvlgkILL5WgiGSVoVO47fcAo=.527d8df7-9a25-4d2d-bd32-064fb9a9c9e8@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
 <gk8XRh9BFK_rvGND6RMvvlgkILL5WgiGSVoVO47fcAo=.527d8df7-9a25-4d2d-bd32-064fb9a9c9e8@github.com>
Message-ID: <nhPEkq1Y8q-rFpMBDqneat6yC-LNaPi-qryOc2mRJ48=.d215dbe7-0e45-46fb-98cc-da17db9bd18e@github.com>

On Fri, 7 Feb 2025 21:18:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FileDialogIconTest.java has been updated.
>> 
>> Following changes were made.
>> 
>> -  Test instructions updated
>> -  BugID associated with the test is updated to the correct one
>> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
>> -  other minor cleanups
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spacing

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 152:

> 150:                         image = Toolkit.getDefaultToolkit().getImage(fileName);
> 151:                         PassFailJFrame.log("Loaded image " + "T" + i + ".gif."
> 152:                                            + "Setting to the list for frame");

Add a space before Setting

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1947229342

From honkar at openjdk.org  Fri Feb  7 22:20:26 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Feb 2025 22:20:26 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v3]
In-Reply-To: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
Message-ID: <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>

> FileDialogIconTest.java has been updated.
> 
> Following changes were made.
> 
> -  Test instructions updated
> -  BugID associated with the test is updated to the correct one
> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
> -  other minor cleanups

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23523/files
  - new: https://git.openjdk.org/jdk/pull/23523/files/5d7d497e..c9714431

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

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

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

From honkar at openjdk.org  Fri Feb  7 22:48:09 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 7 Feb 2025 22:48:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
 <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>
Message-ID: <3bZCZUIM5Auo92RuCHxprMpVHHF7CMTo_5xnHpRJryk=.057c47da-d690-478e-9e63-0b0ded583b1d@github.com>

On Fri, 7 Feb 2025 14:11:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> What tests have you run?
>
>> What tests have you run?
> 
> Had this in our internal test queue with jtreg / JCK  plus some additional SAP internal tests. No issues seen.
> However I think I have to run some more manual tests on client  like  setups.
> 
> Unfortunately my Linux terminal server does not like the awt jtreg tests (with and without my patch) , so I have to find something else.

@MBaesken 

> However I think I have to run some more manual tests on client like setups.

SplashScreen clientlib tests are located - test/jdk/java/awt/SplashScreen. Most of them are manual tests invoked by shell script and it is easier to run the whole test folder. I can run the tests to check if the tests work fine with the fix. 

What are we specifically looking for in the tests with this fix?  No degradation in test startup or execution time?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2644266008

From honkar at openjdk.org  Sat Feb  8 01:27:18 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Sat, 8 Feb 2025 01:27:18 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <ixG11q2tDAjejiEu7xOATivRqRjMujprpTU9zlU9eoQ=.02c08853-6931-4914-8821-31842a28bfad@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <1fjzUR1RxWAEpbja0uaJmAeSZgln-UQsZ4ESiBUL7Gc=.8e307676-4331-4336-bf37-8968b7db3ed2@github.com>
 <Bl_10if9N9POKQAp0xJ-qHJFSgrV76cUU0G76DV0-XE=.bff59cae-88bf-4fd0-9d52-b6c49ed0b593@github.com>
 <Eu0XxQ_F8x4ZMF7t0Qozg8q8MOZEHrwNbhTFH0zPmvY=.179cd061-bd3f-4552-b1d1-946c24759b37@github.com>
 <ixG11q2tDAjejiEu7xOATivRqRjMujprpTU9zlU9eoQ=.02c08853-6931-4914-8821-31842a28bfad@github.com>
Message-ID: <S_ph7vtuEi9JvMue6rsE0NLrIVq9HsAStDXL3X3KODM=.52bca7e3-b1f5-485e-b06c-658ee1180586@github.com>

On Fri, 7 Feb 2025 06:52:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I tested different ways to merge this block with the below blocks. I'm not sure if it makes sense to do so now because it wouldn't be as simple as adding `|| focusOwner == null` to the first if-statement or appending the logic to the `else` block. I would still need another if or else/if block regardless. And I think it's harder to follow than the current implementation. Let me know if you prefer it a different way, but I think the current implementation is better for now.
>
> I was thinking more of `if (!par.isEnabled() !! focusOwner == null)` as the parent is still JFrame.
> 
> But, I was trying to run the testcase mentioned in the JBS and this regression test but I am not able to reproduce without the fix..
> It doesn't keep on scrolling when it regains focus in my windows 11 machine..

@prsadhuk  I wasn't able to replicate the issue first few times. When I changed the no. of combobox items to 1000, the issue was reproducible. 

I think the issue with 100 combobox items is the end of combobox is reached quickly while trying to ALT +TAB at the same time and it becomes difficult to replicate the issue unless it is done quickly.

@DamonGuy Maybe it is good to increase the no. of combobox items to reproduce the issue more consistently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1947387199

From serb at openjdk.org  Sat Feb  8 04:05:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 8 Feb 2025 04:05:21 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <YMVQLdEduxpFdPI1qORMLhSEUhFJZspvsKSjLuBKl0U=.99b47036-454a-4891-9ae0-f8a2fdc4302c@github.com>

On Wed, 5 Feb 2025 18:40:07 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

It would be good to check what type of exception the methods chain can throw, is it only std::bad_alloc()? if yes, then we can use TRY + CATCH_BAD_ALLOC. If we can get another exception, we should figure out how we can report this error to the user.

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

PR Comment: https://git.openjdk.org/jdk/pull/23470#issuecomment-2644484873

From prr at openjdk.org  Sat Feb  8 04:13:14 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 8 Feb 2025 04:13:14 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.

I think what we are looking for in testing is no functional regression plus minimal perf impact on startup.
But I don't think any of our jtreg tests are set up to measure the perf so can only ensure the functional.
It would be good to check that as mentioned.
And I don't remember anyone ever testing perf of splash since the point of splash is to mask the much bigger hit of booting up the JVM .. so I doubt we'll be able to test it today.
But I'll make a note to self to ask the people who do perf testing to think about this, or perhaps tell me "gosh Phil, we've been testing that forever, didn't you know" ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2644488159

From serb at openjdk.org  Sat Feb  8 04:24:11 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 8 Feb 2025 04:24:11 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <yVk7fclScB_b7XLjEjPVI241HeNqq8dsNiaqWmOAaPg=.bad85dc6-2323-4e39-b274-c22c85e24b63@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

In jdk 9 we started to sort the list of methods for each class for a few reasons, and the main one was:
 1. We had a number of bugs which state that our JavaBeans randomly does not work, examples: JDK-6807471[1] , JDK-6788525[2], the reason was that the order of methods from Class.getMethods() is not specified.

So MethodOrder is just a workaround to help us reproduce the bugs. I understand how the current change will fix the problem, but it would be nice to update the code that retrieves the method from that list, or at least provide some information why we can't do that.

Example from the past https://github.com/openjdk/jdk/pull/7190 where MethodOrder was simplified due to JDK-8196373

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2644491830

From mbaesken at openjdk.org  Sun Feb  9 14:44:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sun, 9 Feb 2025 14:44:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>
Message-ID: <iBCiitVE2yGf1Hb_Uh615f5FD_Yuq34ijLOrEWnNKC8=.3922d333-52aa-4dcc-a190-f2526ee97832@github.com>

On Sat, 8 Feb 2025 04:10:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.

Please note that AIX has the debuginfo in the same binary (.so file), unlike e.g. Linux.
If you look at the size reduction of the debuginfo files on Linux, this goes down from 1.7M -> 1.4M  on Linux x86_64 so it is also quite a good reduction.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2646332828

From mbaesken at openjdk.org  Sun Feb  9 14:44:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sun, 9 Feb 2025 14:44:10 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <iBCiitVE2yGf1Hb_Uh615f5FD_Yuq34ijLOrEWnNKC8=.3922d333-52aa-4dcc-a190-f2526ee97832@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <AhwhMh6m_bdoh01fho3njJ0UAg_o5sf7Ac8tJW08MYE=.17c8440e-7fbd-4936-a629-e8c65b32c7e1@github.com>
 <iBCiitVE2yGf1Hb_Uh615f5FD_Yuq34ijLOrEWnNKC8=.3922d333-52aa-4dcc-a190-f2526ee97832@github.com>
Message-ID: <CmpH9mrxrYHT5eh7RO79Sfd5sG5r1MYenC1z9MRJJFI=.bd878afe-a164-4108-bec1-fbe7d4019ee2@github.com>

On Sun, 9 Feb 2025 14:39:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.
>> 
>> I think what we are looking for in testing is no functional regression plus minimal perf impact on startup.
>> But I don't think any of our jtreg tests are set up to measure the perf so can only ensure the functional.
>> It would be good to check that as mentioned.
>> And I don't remember anyone ever testing perf of splash since the point of splash is to mask the much bigger hit of booting up the JVM .. so I doubt we'll be able to test it today.
>> But I'll make a note to self to ask the people who do perf testing to think about this, or perhaps tell me "gosh Phil, we've been testing that forever, didn't you know" ?
>
>> I note that AIX seems to be the biggest beneficiary here. It doesn't seem to be a big deal for anything else.
> 
> Please note that AIX has the debuginfo in the same binary (.so file), unlike e.g. Linux.
> If you look at the size reduction of the debuginfo files on Linux, this goes down from 1.7M -> 1.4M  on Linux x86_64 so it is also quite a good reduction.

> @MBaesken
> 
> > However I think I have to run some more manual tests on client like setups.
> 
> SplashScreen clientlib tests are located - test/jdk/java/awt/SplashScreen. Most of them are manual tests invoked by shell script and it is easier to run the whole test folder. I can run the tests on your behalf to check if the tests work fine with the fix.
> 
> What are we specifically looking for in the tests with this fix? No degradation in test startup and execution time?

If you find the time to run those, would be great. And yes a noticeable degradation would be important to know.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2646333958

From duke at openjdk.org  Sun Feb  9 19:56:48 2025
From: duke at openjdk.org (anass baya)
Date: Sun, 9 Feb 2025 19:56:48 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
Message-ID: <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>

> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
> 
> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
> 
> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
> 
> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.

anass baya has updated the pull request incrementally with one additional commit since the last revision:

  Add proposed enhancments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23449/files
  - new: https://git.openjdk.org/jdk/pull/23449/files/81797629..95750a44

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

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

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

From duke at openjdk.org  Sun Feb  9 19:56:48 2025
From: duke at openjdk.org (anass baya)
Date: Sun, 9 Feb 2025 19:56:48 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <MKHDkY0sLjs_lIu1NZs88jLLdtfgpQLUsqdxhqBqzx4=.6987cec3-902b-4c80-85b1-2461484b1a31@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>
 <SxvHNw49f7gWTrpRcYH9q-677-2g5_2SpZULunyFi4s=.b1f1a722-26a4-44cd-96d5-10c066abe3c2@github.com>
 <FLNHZA1V3VsK5JYZJoiEKaOfE4Gw5jSOGqzNRlszCyg=.bb7ccc48-639b-4fce-b6a7-a95ee02b7f36@github.com>
 <MKHDkY0sLjs_lIu1NZs88jLLdtfgpQLUsqdxhqBqzx4=.6987cec3-902b-4c80-85b1-2461484b1a31@github.com>
Message-ID: <DbixoY9a-ZEig4Jmqgp1dfBm0UdDj13ny45ypwNEJeE=.7ef4e073-bdc5-4172-af03-9a7c5dfd9006@github.com>

On Fri, 7 Feb 2025 19:30:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> If it test runs fine on CI then it should be okay. Previously, I came across few tests which required increasing tolerance value (although not in this context but particularly for pixel color case).
>
> Tolerance when comparing colours is different from comparing sizes.
> 
> We know that fractional pixels after scaling up and down may be lost, that's where the tolerance comes from.

Tests seem Okay on CI as well as on my local setup

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1948226109

From psadhukhan at openjdk.org  Mon Feb 10 05:27:20 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Feb 2025 05:27:20 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
Message-ID: <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>

On Fri, 7 Feb 2025 19:09:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove test file
>>  - Move text position w.r.t menuItem icon
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 662:
> 
>> 660:         paintCheckIcon(g, lh, lr, holdc, foreground);
>> 661:         paintIcon(g, lh, lr, holdc);
>> 662:         if (UIManager.getLookAndFeel().getName().equals("Windows")
> 
> Can't this be handled in `WindowsMenuItemUI` instead? After all, Metal and Windows L&F looked differently.

I tried but Many a thing cannot be accessed outside plaf.basic package and I am checking for WIndows L&F so Metal will not be affected..

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

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

From psadhukhan at openjdk.org  Mon Feb 10 05:31:15 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Feb 2025 05:31:15 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
Message-ID: <QsvlGitw6UyoNQQSBc0NJjlpZ3mkKsFr-gEGx82wqVc=.34b20769-9026-46f1-8795-6b201d577e48@github.com>

On Fri, 7 Feb 2025 05:26:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove test file
>  - Move text position w.r.t menuItem icon

> This is how it looks on Windows 10: ![latest-fix-2025-02-07](https://private-user-images.githubusercontent.com/70774172/411051067-55ce3491-e52b-4491-93a8-1a3ebd686840.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxNTMwNjksIm5iZiI6MTczOTE1Mjc2OSwicGF0aCI6Ii83MDc3NDE3Mi80MTEwNTEwNjctNTVjZTM0OTEtZTUyYi00NDkxLTkzYTgtMWEzZWJkNjg2ODQwLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjEwVDAxNTkyOVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTcyMjQ2YmE0NGQwYTQyNzk4Mzg3ZjI4MjlmOTc1OWVmYjIzZGRiNjJlMjdiOWJlMGFkMTFkZTU2YTljZGY4ODImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.mmOJXNV329OKGu6gq-vVTlE4GsfEgQIAD-FR7li12U4)
> 
> It's close, yet the spacing is wrong.
> 
> The bullet / check-mark should be where they were before the fix. There was 8-pixel margin to the left of selected bullet background before the fix, now there are only 2 pixels.
> 
> The margin between the bullet background and the text was again 8 pixels, I think we should maintain the same margin between the bullet and the icon as well as between the icon and the menu text.

Does bullet/checkmark use to appear before the fix in windows 10? I thought you told the icon was getting highlighted/dehighlighted depending on item is selected or not

I am not sure if we can make 8 pixel margin as it will cause MenuItem text or bullet to be outgrow popmenu width ( I faced this issue while experimenting with spacing), which I am not sure if and where we can increase.

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2646955190

From abhiscxk at openjdk.org  Mon Feb 10 07:13:11 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 10 Feb 2025 07:13:11 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v3]
In-Reply-To: <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
 <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
Message-ID: <06VYFfWerq841FjniD2mLjN2C3MQm758Fgz8FEy1-Wo=.d13e2224-d008-4a65-9d8f-ae8997e90f7c@github.com>

On Fri, 7 Feb 2025 22:20:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FileDialogIconTest.java has been updated.
>> 
>> Following changes were made.
>> 
>> -  Test instructions updated
>> -  BugID associated with the test is updated to the correct one
>> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
>> -  other minor cleanups
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 44:

> 42:  * @bug 6425126
> 43:  * @summary Test to verify that PIT File Dialog icon not matching with
> 44:  *          the new java icon (frame Icon) - PIT build

I believe the File Dialog icon should match with the new java icon is correct behaviour. So, isn't it better to remove **not** from the summary?

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 152:

> 150:                         image = Toolkit.getDefaultToolkit().getImage(fileName);
> 151:                         PassFailJFrame.log("Loaded image " + "T" + i + ".gif."
> 152:                                            + " Setting to the list for frame");

Suggestion:

                        PassFailJFrame.log("Loaded image T" + i + ".gif."
                                           + " Setting to the list for frame");

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 172:

> 170:                         image = Toolkit.getDefaultToolkit().getImage(fileName);
> 171:                         PassFailJFrame.log("Loaded image " + "T" + i + ".gif."
> 172:                                            + " Setting to the list for dialog");

Suggestion:

                        PassFailJFrame.log("Loaded image T" + i + ".gif."
                                           + " Setting to the list for dialog");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1948497099
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1948492785
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1948492998

From abhiscxk at openjdk.org  Mon Feb 10 07:16:17 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 10 Feb 2025 07:16:17 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v3]
In-Reply-To: <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
 <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
Message-ID: <wnLvRyz9CkBDbsLyaoOLWrTL5aA_L-oMq5x865b7HEs=.59d44ecb-54b5-40e7-b878-429fd7a735de@github.com>

On Fri, 7 Feb 2025 22:20:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FileDialogIconTest.java has been updated.
>> 
>> Following changes were made.
>> 
>> -  Test instructions updated
>> -  BugID associated with the test is updated to the correct one
>> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
>> -  other minor cleanups
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 45:

> 43:  * @summary Test to verify that PIT File Dialog icon not matching with
> 44:  *          the new java icon (frame Icon) - PIT build
> 45:  * @requires (os.family == "windows")

Bug description says -- `This is reproduce on solaris & cinnabar. This works fine in Mustang b83.`

Why the test is restricted for `windows` only ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1948500724

From duke at openjdk.org  Mon Feb 10 07:16:21 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Mon, 10 Feb 2025 07:16:21 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS [v5]
In-Reply-To: <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
References: <wtiyLzB9pJ_FjSkCJYN5hcWBIk4K3FtTqgbBsWhBz_w=.30c23e5b-3f70-4ee4-bec4-4d0ce217be57@github.com>
 <tbcV6tsZWxfA1AczNQK5SsQR_OMfimse1G8sLPah2SM=.0b18b61c-7e14-4439-b86a-b1c05f00ac37@github.com>
Message-ID: <m4AW7l8M_KmL0_7W_q3NpnZosbX-YsglV0wN7pi1PHE=.4f1e5782-d212-4bf3-85ed-4a29e1f6e1b9@github.com>

On Fri, 27 Dec 2024 11:05:30 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> This update allows users to print with grayscale using color printers.
>> Actually, it is not possible to use the "Monochrome" option from the "Color Appearance" panel. Also Chromaticity.MONOCHROME can't be used to print grayscale on color printers ([JDK-8315113](https://bugs.openjdk.org/browse/JDK-8315113)).
>> 
>> **Fix description**
>> When a printer supports color printing and a user adds Chromaticity.MONOCHROME attribute to a PrintRequestAttributeSet, then the final printing raster is transformed to the grayscale color using java.awt.image.ColorConvertOp. When the job is a PostScript job, then the "setColor" and "setPaint" methods of the Graphics are overridden, and user colors (paints) are transformed to the grayscale form using the new proxy class GrayscaleProxyGraphics2D.
>> 
>> This approach is assumed to be platform, CUPS, and IPP protocol independent.
>> 
>> **Tests**
>> The fix was tested on Ubuntu 22.04 and MacOS 12.6.1.
>
> GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Update copyright, fix typos, move the proxy to the macos
>  - Merge branch 'master' into monochrome-printing
>  - proxy mac only
>  - Revert "grammar fixes"
>    
>    This reverts commit 355b2b8f1dbc71cef433e9a925dfb8a7fff56f99.
>  - Revert "formatting"
>    
>    This reverts commit fde514baeadc2775fa502a2a2d312c6038880e7a.
>  - Revert "update copyright"
>    
>    This reverts commit 60e9b4f024544cfac4ddaddc1ea3653bd4a2fe4c.
>  - Revert "move grayscale methods to PSPathGraphics"
>    
>    This reverts commit 1ef135680645ad2647c4430e852095dda8aa7e0c.
>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>    
>    # Conflicts:
>    #	src/java.desktop/share/classes/sun/print/RasterPrinterJob.java
>  - Merge remote-tracking branch 'openjdk/master' into monochrome-printing
>  - move grayscale methods to PSPathGraphics
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/6c591854...5486473b

I updated the branch according to the comments. I moved updates to the Mac sources and updated color convertion process using override ProxyGraphics2D.

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

PR Comment: https://git.openjdk.org/jdk/pull/21930#issuecomment-2647124348

From abhiscxk at openjdk.org  Mon Feb 10 08:37:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 10 Feb 2025 08:37:10 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <qE3Ad8-RcqZnC9CkFJcIXm2D50LxiGLgVjYNxZ88dKA=.1ab93772-8048-4eed-ba2a-6edfda86888c@github.com>

On Wed, 5 Feb 2025 18:40:07 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

Marked as reviewed by abhiscxk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2605003210

From abhiscxk at openjdk.org  Mon Feb 10 08:41:14 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 10 Feb 2025 08:41:14 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
In-Reply-To: <YMVQLdEduxpFdPI1qORMLhSEUhFJZspvsKSjLuBKl0U=.99b47036-454a-4891-9ae0-f8a2fdc4302c@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <YMVQLdEduxpFdPI1qORMLhSEUhFJZspvsKSjLuBKl0U=.99b47036-454a-4891-9ae0-f8a2fdc4302c@github.com>
Message-ID: <_28HlaeZwNBmzjZwld57mcMhLJzwXDGvpUEM9Tc9CeI=.35538a76-deec-49aa-a855-c253f14ec298@github.com>

On Sat, 8 Feb 2025 04:02:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> It would be good to check what type of exception the methods chain can throw, is it only std::bad_alloc()? if yes, then we can use TRY + CATCH_BAD_ALLOC. If we can get another exception, we should figure out how we can report this error to the user.

This looks good but I agree with @mrserb that if the exception type can be narrowed down to specific types, will be better.

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

PR Comment: https://git.openjdk.org/jdk/pull/23470#issuecomment-2647281825

From rmarchenko at openjdk.org  Mon Feb 10 10:21:13 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Mon, 10 Feb 2025 10:21:13 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <uZpjnCv0VdYhCnnNWff5AV3_KEkP3s9HJKHPuN9pawU=.cac22247-2d7b-441e-ab4c-f8b681b41e0e@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

> it would be nice to update the code that retrieves the method from that list, or at least provide some information why we can't  do that.
> Example from the past #7190 where MethodOrder was simplified due to JDK-8196373 do that.

@mrserb Sorry, I don't feel I completely understand what are you asking for. What do you mean "the code that retrieves the method from that list"? Should I add comments somewhere in source code with the issue details why does Introspector.addMethod() work wrong for now, or with details about sorting? Or should I update the PR description? I couldn't find any clues in #7190, sorry.

And BTW, I'm concerning why I can't find a check in this PR which builds and tests the change. Should I trigger it somehow, or is it just invisible for me?

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2647539955

From psadhukhan at openjdk.org  Mon Feb 10 16:23:23 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 10 Feb 2025 16:23:23 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
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: <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@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:

  Restore Windows 10 behavior

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/5742db5b..46a1cb5a

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

  Stats: 29 lines in 3 files changed: 16 ins; 5 del; 8 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 aivanov at openjdk.org  Mon Feb 10 16:34:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Feb 2025 16:34:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <QsvlGitw6UyoNQQSBc0NJjlpZ3mkKsFr-gEGx82wqVc=.34b20769-9026-46f1-8795-6b201d577e48@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <QsvlGitw6UyoNQQSBc0NJjlpZ3mkKsFr-gEGx82wqVc=.34b20769-9026-46f1-8795-6b201d577e48@github.com>
Message-ID: <OYU-AECaO8-xxnLcd2vC3yM_TIoB3IrSVOdGEpr8IjU=.dc822959-cf42-483c-8fcd-d2771e376552@github.com>

On Mon, 10 Feb 2025 05:28:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > It's close, yet the spacing is wrong.
> >
> > The bullet / check-mark should be where they were before the fix. There was 8-pixel margin to the left of selected bullet background before the fix, now there are only 2 pixels.
> >
> > The margin between the bullet background and the text was again 8 pixels, I think we should maintain the same margin between the bullet and the icon as well as between the icon and the menu text.
> 
> Does bullet/checkmark use to appear before the fix in windows 10? I thought you told the icon was getting highlighted/dehighlighted depending on item is selected or not

That's right! The `ImageIcon` was painted instead of bullet or check-mark.

Now that you moved the `ImageIcon` to the right, the bullet or check-mark has to be painted where the bullets and check-marks are painted when there's no custom icon.

That's what I meant ? the previous location of the bullet / check-mark should be preserved.

> I am not sure if we can make 8 pixel margin as it will cause MenuItem text or bullet to be outgrow popupmenu width ( I faced this issue while experimenting with spacing), which I am not sure if and where we can increase.

This is why I say that the layout and therefore the width of the menu item has to be updated.

Previously, the custom icon was painted over, or instead of, the bullet or check-mark.

This PR proposes painting the custom icon separately, which means the width of the menu item has increase to accommodate the margins around the custom icon as well as the icon itself.

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2648601371

From aivanov at openjdk.org  Mon Feb 10 16:57:23 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Feb 2025 16:57:23 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
 <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>
Message-ID: <NbdvRYDyFGaYKtE2wtBJD_sWFz5dlTuHSv-iSHnpT60=.abb2997d-8c89-485d-90b5-594d914e3541@github.com>

On Mon, 10 Feb 2025 05:24:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I am checking for WIndows L&F so Metal will not be affected.

This is the reason why I don't like this approach: the base class needs to know about Windows L&F and do some customisation based on the current L&F. This code will be included on Linux and macOS where Windows L&F isn't available.

A better solution would be a helper method or a helper class which handles this difference.

As far as I can see, Metal L&F paints both the bullet / check-mark and the custom icon ? this is exactly what you're implementing here. The difference is in margins around these elements.

The layout of the menu is handled by `MenuItemLayoutHelper`. It's customised for Synth L&F in `SynthMenuItemLayoutHelper`. Perhaps, you need to create a customised class for Windows L&F.

Yet there's no hook in `BasicMenuItemUI` to create or pass another `MenuItemLayoutHelper` object which customises the layout. A new method may be added.

---

I haven't looked deeply into how popup menus are laid out and therefore I can't advice on how to customise menu item layout.

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

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

From aivanov at openjdk.org  Mon Feb 10 17:40:25 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Feb 2025 17:40:25 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
In-Reply-To: <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
Message-ID: <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>

On Mon, 10 Feb 2025 16:23:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore Windows 10 behavior

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 663:

> 661:         paintIcon(g, lh, lr, holdc);
> 662:         if (UIManager.getLookAndFeel().getName().equals("Windows")
> 663:             && System.getProperty("os.name").equals("Windows 11")

It's not what I meant.

I suggested painting the menu items *the same way* for Windows 10 and 11. Yet the layout for Windows 11 should be tweaked.

To be clear, the bullet / check-mark is painted at the same location where it would be painted if there were no custom icon for both Windows 10 and 11. The custom icon is painted to the right of the bullet / check-mark, and the menu text moves farther to the right.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 886:

> 884:                                     skin.paintSkin(g, x - OFFSET, y + OFFSET, state);
> 885:                                 }
> 886:                             } else {

Again, it's not what I meant.

Both Windows 10 and 11 should follow the same layout ? the new style that you found in File Explorer in Windows 11.

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

PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2606681172
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1949596849
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1949599874

From aivanov at openjdk.org  Mon Feb 10 18:03:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Feb 2025 18:03:22 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
In-Reply-To: <YMVQLdEduxpFdPI1qORMLhSEUhFJZspvsKSjLuBKl0U=.99b47036-454a-4891-9ae0-f8a2fdc4302c@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <YMVQLdEduxpFdPI1qORMLhSEUhFJZspvsKSjLuBKl0U=.99b47036-454a-4891-9ae0-f8a2fdc4302c@github.com>
Message-ID: <yzIMv0SNVCgkwomUXeHayBhupTwT_djr9Zu6Xmr0kvA=.0a11f8ce-209e-4041-ba67-5d9f6879cb55@github.com>

On Sat, 8 Feb 2025 04:02:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It would be good to check what type of exception the methods chain can throw, is it only std::bad_alloc()? if yes, then we can use TRY + CATCH_BAD_ALLOC. If we can get another exception, we should figure out how we can report this error to the user.

In `CreateIconFromRaster` a catch-all construct is used, and then the exception is re-thrown:

https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2082-L2087

At the same time, `BitmapUtil::CreateTransparencyMaskFromARGB` may throw only `std::bad_alloc` at

https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/awt_BitmapUtil.cpp#L43

where `SAFE_SIZE_NEW_ARRAY2` is defined as

https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/share/native/common/awt/utility/sizecalc.h#L93-L95

Thus, after looking at the chain of calls, `std::bad_alloc` is the only C++ exception that may ever be thrown.

Then, the pair of [`TRY`](https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/alloc.h#L131-L134) and [`CATCH_BAD_ALLOC`](https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/alloc.h#L154-L160) could be a better alternative.

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

PR Comment: https://git.openjdk.org/jdk/pull/23470#issuecomment-2648827456

From aivanov at openjdk.org  Mon Feb 10 18:03:21 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Feb 2025 18:03:21 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <84KRMChhi2tOGRvET08peTlh2-TGawbnoD8yncePTNs=.19dad641-dbe3-4176-bdff-70e92ee000a7@github.com>

On Wed, 5 Feb 2025 18:40:07 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp line 1:

> 1: /*

Please update the copyright year.

src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp line 130:

> 128: {
> 129:     try
> 130:     {

Suggestion:

    try {

I think it makes sense to use Java style and put the opening brace on the same line with `try` as this style is followed by `if`-`else` statements in the file as well as you follow Java style for the `catch` block below.

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2606715517
PR Review Comment: https://git.openjdk.org/jdk/pull/23470#discussion_r1949617073
PR Review Comment: https://git.openjdk.org/jdk/pull/23470#discussion_r1949616538

From kizune at openjdk.org  Mon Feb 10 18:06:20 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 10 Feb 2025 18:06:20 GMT
Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead
 of delay [v2]
In-Reply-To: <XwTLpRpsycLgsLUKtLdogxrNO0tN5JS5u7vIdRdQ7mE=.a9223a78-a3e0-4ba1-b8ba-d1375b984ea0@github.com>
References: <V2WXHyGBdHdO49Q4L0hYCX4lz3HOTdTNzqJnqv6Dib0=.6421e52b-5548-4555-b9a0-fc70a3bcd24a@github.com>
 <XwTLpRpsycLgsLUKtLdogxrNO0tN5JS5u7vIdRdQ7mE=.a9223a78-a3e0-4ba1-b8ba-d1375b984ea0@github.com>
Message-ID: <u7SbiRlRbonwnU9vveRNbiJlLrCqlxaIiPKO6kERYLQ=.b8d3e3b6-93d4-4f1a-8ed7-f2afb81b427d@github.com>

On Wed, 29 Jan 2025 15:46:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay.  
>> Use `Util.hitMnemonics` instead of custom code to handle macOS.
>> 
>> I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for null before dispose()

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23301#pullrequestreview-2606749794

From aivanov at openjdk.org  Mon Feb 10 18:29:21 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 10 Feb 2025 18:29:21 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v3]
In-Reply-To: <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
 <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
Message-ID: <pq3YoZVYOWe9EnubIDEiln0151AIwBkobdi4Pjj3PuU=.fbc3b84c-f167-493d-8596-400a412259a0@github.com>

On Fri, 7 Feb 2025 22:20:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FileDialogIconTest.java has been updated.
>> 
>> Following changes were made.
>> 
>> -  Test instructions updated
>> -  BugID associated with the test is updated to the correct one
>> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
>> -  other minor cleanups
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 59:

> 57:     public static void main(String[] args) throws Exception {
> 58:         String INSTRUCTIONS = """
> 59:                 The 1st row of buttons in testUI are to open Load,

It may not be apparent what `testUI` is? on the other hand, it should still be obvious that you referring to a window on the right.

It could better to refer to it as a ?window?? or a least ?test UI? (with a space).

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 76:

> 74: 
> 75:         PassFailJFrame.builder()
> 76:                 .title("Test Instructions Frame")

I believe the ?frame? is redundant.

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 152:

> 150:                         image = Toolkit.getDefaultToolkit().getImage(fileName);
> 151:                         PassFailJFrame.log("Loaded image " + "T" + i + ".gif."
> 152:                                            + " Setting to the list for frame");

Why can't `fileName` be used in the logging?

Suggestion:

                        PassFailJFrame.log("Loaded image " + fileName + "."
                                           + " Setting to the list for frame");

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 172:

> 170:                         image = Toolkit.getDefaultToolkit().getImage(fileName);
> 171:                         PassFailJFrame.log("Loaded image " + "T" + i + ".gif."
> 172:                                            + " Setting to the list for dialog");

This piece of code looks the save as the one above.

Does it make to isolate the loading of images from setting them (to avoid code duplication)?

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 185:

> 183:         setImageButton5.addActionListener(new ActionListener() {
> 184:             public void actionPerformed(ActionEvent event) {
> 185:                 List<Image> list = new ArrayList<>();

Suggestion:

                List<Image> list = new ArrayList<>(4);

Micro-optimization: we know the number of images, the array in `ArrayList` could be sized accordingly.

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 217:

> 215:                         list.add(image);
> 216:                     }
> 217:                     setImagesToFD(list);

Here, again the code is the same as in `setImageButton5.addActionListener` except for the final call `setImagesToFD` vs `setImagesToFrame`. I suggest moving capture code out of either methods and re-use it.

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 256:

> 254:     static class MyActionListener implements ActionListener {
> 255:         int id;
> 256:         String name;

Suggestion:

        final int id;
        final String name;

If the value of the fields is unchanged, they should be `final`. The may even be `private`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1949668666
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1949652576
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1949653808
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1949657086
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1949658652
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1949661300
PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1949663909

From azvegint at openjdk.org  Mon Feb 10 19:15:21 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 10 Feb 2025 19:15:21 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
Message-ID: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>

Filed as a separate issue to keep the #23426 clean.

Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)

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

Depends on: https://git.openjdk.org/jdk/pull/23426

Commit messages:
 - 8349751: AIX build failure after upgrade pipewire to 1.3.81

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

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

From achung at openjdk.org  Mon Feb 10 19:36:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 10 Feb 2025 19:36:15 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v3]
In-Reply-To: <lt9t4q8rrb5lhHTMTZ6n47xTtywK23rFUxzQdg15_4s=.858daee3-e155-409b-b67e-eaf3603743e5@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <lt9t4q8rrb5lhHTMTZ6n47xTtywK23rFUxzQdg15_4s=.858daee3-e155-409b-b67e-eaf3603743e5@github.com>
Message-ID: <xbXWxw-SyUUw7H8xAHYeDJVAilbephtOGzBPGue0B9o=.927bc33a-f0ef-471c-921a-a539a0826f40@github.com>

On Fri, 20 Dec 2024 00:17:54 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Soft hyphens should never render, regardless of the rendering path used internally.
>> 
>> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
>> 
>> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
>> 
>> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more info about test fonts and default-ignorable chars

src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 2:

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

2025 now since it's the new year

src/java.desktop/share/classes/sun/font/Type1GlyphMapper.java line 2:

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

new year here too

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22670#discussion_r1949763888
PR Review Comment: https://git.openjdk.org/jdk/pull/22670#discussion_r1949764852

From prr at openjdk.org  Mon Feb 10 19:40:15 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Feb 2025 19:40:15 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <aQRYaau4QLQAaLP94AeOYPASg_9kKXp01ixB3b8cPD0=.5b9c27ae-7f59-4aaf-95ac-ff584bb1ebc5@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

Looks OK to me. But Harshitha is going to do a bit of testing, so wait for her.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2606975133

From prr at openjdk.org  Mon Feb 10 19:49:08 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Feb 2025 19:49:08 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
Message-ID: <0UMH4vddWkjdzjNeMmA3L6SSqbD1WGluZnLn9LUbhak=.4ff0c5bb-5baf-4189-9e27-5f2f8d65ac92@github.com>

On Mon, 3 Feb 2025 18:50:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset updates the pipewire headers to the latest available version.
> It contains the minimum set of required header files needed to build the JDK.
> 
> The updated headers are a direct copy from the 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
>  
> Testing looks good.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23426#pullrequestreview-2606993967

From dgredler at openjdk.org  Mon Feb 10 20:29:54 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 10 Feb 2025 20:29:54 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v4]
In-Reply-To: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
Message-ID: <zzG4Cbpk8z2C3z4-SiWcLLqaqfe-Ix-m1LFMsNXI8Jc=.b94e1c7d-ba0b-4afe-b6fd-9fbc4b4edbd8@github.com>

> Soft hyphens should never render, regardless of the rendering path used internally.
> 
> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
> 
> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
> 
> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22670/files
  - new: https://git.openjdk.org/jdk/pull/22670/files/f7a89cff..79604bdc

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

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

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

From dgredler at openjdk.org  Mon Feb 10 20:36:46 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 10 Feb 2025 20:36:46 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v5]
In-Reply-To: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
Message-ID: <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>

> Soft hyphens should never render, regardless of the rendering path used internally.
> 
> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
> 
> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
> 
> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.

Daniel Gredler 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 'master' into JDK-8208377
 - Update copyright year
 - Add more info about test fonts and default-ignorable chars
 - Add macOS-specific char mapper changes
 - Always use invisible glyphs for 'default ignorable' chars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22670/files
  - new: https://git.openjdk.org/jdk/pull/22670/files/79604bdc..e34e0081

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

  Stats: 545123 lines in 11068 files changed: 269687 ins; 227821 del; 47615 mod
  Patch: https://git.openjdk.org/jdk/pull/22670.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22670/head:pull/22670

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

From dgredler at openjdk.org  Mon Feb 10 20:36:46 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 10 Feb 2025 20:36:46 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v3]
In-Reply-To: <xbXWxw-SyUUw7H8xAHYeDJVAilbephtOGzBPGue0B9o=.927bc33a-f0ef-471c-921a-a539a0826f40@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <lt9t4q8rrb5lhHTMTZ6n47xTtywK23rFUxzQdg15_4s=.858daee3-e155-409b-b67e-eaf3603743e5@github.com>
 <xbXWxw-SyUUw7H8xAHYeDJVAilbephtOGzBPGue0B9o=.927bc33a-f0ef-471c-921a-a539a0826f40@github.com>
Message-ID: <Mk-hDpnzbTMoO_KiwCXpGemy62tJqTEp4HF9hLN4wAs=.09f8f297-2f23-494b-a0ad-0a88723beadf@github.com>

On Mon, 10 Feb 2025 19:33:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more info about test fonts and default-ignorable chars
>
> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> 2025 now since it's the new year

Thanks! Copyright years have been updated, let me know if there is anything else that caught your eye, or if I should go ahead and integrate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22670#discussion_r1949841261

From achung at openjdk.org  Mon Feb 10 20:48:22 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 10 Feb 2025 20:48:22 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v5]
In-Reply-To: <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
Message-ID: <9MIdeQZKNZwSpMbrDNbzI7eCMTsl3NjgHWVPPyuEHwI=.e3dfe79b-9907-4967-a283-5310e55c0897@github.com>

On Mon, 10 Feb 2025 20:36:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Soft hyphens should never render, regardless of the rendering path used internally.
>> 
>> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
>> 
>> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
>> 
>> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.
>
> Daniel Gredler 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 'master' into JDK-8208377
>  - Update copyright year
>  - Add more info about test fonts and default-ignorable chars
>  - Add macOS-specific char mapper changes
>  - Always use invisible glyphs for 'default ignorable' chars

Re-tested on my local machine and the test passes with the updated fix, LGTM

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22670#pullrequestreview-2607129159

From azvegint at openjdk.org  Mon Feb 10 21:11:16 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 10 Feb 2025 21:11:16 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <7ixw3YiwKWK3900X6U3PQSGLMUy1PG506GJNETk0sLs=.02992694-3e46-493d-88f4-b4c9534edb9c@github.com>

On Tue, 4 Feb 2025 23:35:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

Unfortunately, the provided test fails for me on Ubuntu 22.04.
On the first `Alt + TAB` it switches to the test frame, so it doesn't trigger the timer to stop.

BTW, the test can be automated, e.g. do something like the following

<details>
  <summary>JComboBoxScrollFocusTestAuto.java</summary>


import javax.swing.JComboBox;
import javax.swing.JFrame;
import javax.swing.JScrollBar;
import javax.swing.JScrollPane;
import javax.swing.SwingUtilities;
import javax.swing.plaf.basic.BasicComboPopup;
import java.awt.Component;
import java.awt.Point;
import java.awt.Rectangle;
import java.awt.Robot;
import java.awt.event.InputEvent;
import java.lang.reflect.InvocationTargetException;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class JComboBoxScrollFocusTestAuto {

    private static Robot robot;
    private static JFrame comboboxFrame;
    private static JComboBox<String> combobox;


    public static void main(String[] args) throws Exception {
        robot = new Robot();
        try {
            SwingUtilities.invokeAndWait(JComboBoxScrollFocusTestAuto::createAndShowGUI);
            doTest();
        } finally {
            SwingUtilities.invokeAndWait(comboboxFrame::dispose);
        }
    }

    private static void createAndShowGUI() {
        comboboxFrame = new JFrame("JComboBoxScrollFocusTest Test Frame");
        combobox = new JComboBox<>();
        for (int i = 0; i < 100; i++) {
            combobox.addItem(String.valueOf(i));
        }
        comboboxFrame.add(combobox);
        comboboxFrame.setSize(400, 200);
        comboboxFrame.setLocationRelativeTo(null);
        comboboxFrame.setVisible(true);
    }

    static Rectangle getOnScreenBoundsOnEDT(Component component)
            throws InterruptedException, TimeoutException, ExecutionException {
        robot.waitForIdle();
        FutureTask<Rectangle> task = new FutureTask<>(()
                -> new Rectangle(component.getLocationOnScreen(), component.getSize()));
        SwingUtilities.invokeLater(task);
        return task.get(500, TimeUnit.MILLISECONDS);
    }

    private static int getScrollbarValue()
            throws InterruptedException, InvocationTargetException, ExecutionException, TimeoutException {

        FutureTask<Integer> task = new FutureTask<>(() -> {
            BasicComboPopup popup = (BasicComboPopup) combobox.getAccessibleContext().getAccessibleChild(0);
            JScrollPane scrollPane = (JScrollPane) popup.getAccessibleContext().getAccessibleChild(0);
            JScrollBar scrollBar = scrollPane.getVerticalScrollBar();
            return scrollBar.getValue();
        });
        SwingUtilities.invokeAndWait(task);

        return task.get(500, TimeUnit.MILLISECONDS);
    }

    private static void doTest() throws Exception {
        robot.waitForIdle();
        robot.delay(500);

        Rectangle rectangle = getOnScreenBoundsOnEDT(combobox);

        Point ptOpenComboboxPopup = new Point(rectangle.x + rectangle.width - 5, rectangle.y + rectangle.height / 2);

        robot.mouseMove(ptOpenComboboxPopup.x, ptOpenComboboxPopup.y);
        robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
        robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
        robot.waitForIdle();
        robot.delay(500);


        BasicComboPopup popup = (BasicComboPopup) combobox.getAccessibleContext().getAccessibleChild(0);
        JScrollBar scrollBar = ((JScrollPane) popup.getAccessibleContext().getAccessibleChild(0)).getVerticalScrollBar();

        // Start scrolling
        Rectangle scrollbarBounds = getOnScreenBoundsOnEDT(scrollBar);
        robot.mouseMove(scrollbarBounds.x + scrollbarBounds.width / 2, scrollbarBounds.y + scrollbarBounds.height - 5);
        robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);

        robot.delay(1000);

        if (getScrollbarValue() == 0) {
            throw new RuntimeException("The scrollbar is not scrolling");
        }

        // closing popup by moving focus to the main window
        comboboxFrame.requestFocus();
        robot.waitForIdle();
        robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);

        robot.waitForIdle();
        robot.delay(500);

        // open popup again
        robot.mouseMove(ptOpenComboboxPopup.x, ptOpenComboboxPopup.y);
        robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
        robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
        robot.waitForIdle();
        robot.delay(500);

        if (getScrollbarValue() != 0) {
            throw new RuntimeException("The scroll bar is scrolling");
        }
    }
}


</details>

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

PR Comment: https://git.openjdk.org/jdk/pull/23451#issuecomment-2649244315

From rmahajan at openjdk.org  Mon Feb 10 21:50:26 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Mon, 10 Feb 2025 21:50:26 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v2]
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <yFXftYoFtKgGt5JSZwvzVB6odANQ1gmkOL6uJhaGvrA=.f387fde1-a375-40ce-9fb8-07b4d85ea382@github.com>

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23470/files
  - new: https://git.openjdk.org/jdk/pull/23470/files/554aaa70..66f0a452

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

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

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

From azvegint at openjdk.org  Mon Feb 10 21:56:13 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 10 Feb 2025 21:56:13 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <oTIP5COO9ALrpDyKjdU48p7izMn_QemI5UXjEKTGumo=.675f15b6-5244-4654-976b-3b445a98329b@github.com>

On Tue, 4 Feb 2025 23:35:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1620:

> 1618:             do {
> 1619:                 // If application isn't in focus, stop the timer
> 1620:                 if (focusOwner == null) {

Suggestion:

            do {
                if (!scrollbar.isShowing()) {


I haven't tested this solution well, but you can try to stop the timer when the scrollbar is not showing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1949949286

From davidalayachew at gmail.com  Mon Feb 10 22:41:13 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Feb 2025 17:41:13 -0500
Subject: Windows Magnifier does not work with my Swing applications
In-Reply-To: <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
Message-ID: <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>

Poke.

Any new info?

On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Phil,
>
> Did you get any more info about this issue?
>
> On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Thanks Phil.
>>
>> Yeah, I am A-OK as long as this something that is looked into and the JBS
>> Bug Report is updated with the findings. If this isn't too bad, this would
>> be a solid inclusion. But if it's not worth the effort, I just want the JBS
>> to be updated, and then I can put that as an answer for my StackOverflow
>> post.
>>
>> Thanks again for taking a look into this.
>>
>> On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com>
>> wrote:
>>
>>> Perhaps .. if it is an easy fix but I do not know the specifics and the
>>> evaluator of that bug wrote
>>> "the magnifier cannot receive PropertyChangeEvents from Swing. This is
>>> a limitation in the Window magnifier.
>>> The Windows magnifier could be modified by Microsoft to receive such
>>> events but the work would need to be done by Microsoft."
>>>
>>> then went on to add that other magnifiers do work ..
>>>
>>> I also don't know how tied in this would be to implementing support for
>>> the Windows Accessibility API.
>>>
>>> Swing apps today use something called JavaAccessBridge and there are
>>> screen readers out there that support it.
>>>
>>> It would be good to have another look at this specific issue, but I
>>> can't make any promises.
>>>
>>> -phil.
>>>
>>> On 12/15/24 1:04 PM, David Alayachew wrote:
>>>
>>> Hello Client Libs Dev Team,
>>>
>>> My eyesite has started to deteriorate significantly, so I have been
>>> using the built-in Accessibility tool called Windows (Screen) Magnifier
>>> (available since Windows XP at least). It zooms in and out of the screen by
>>> pressing the Windows Key and (+) or (-).
>>>
>>> This works great because, as I type stuff, the magnifier will follow my
>>> text, so that I don't have to keep manually moving the magnifier whenever
>>> what I type inevitably ends up off-screen (off-view?).
>>>
>>> This feature works great for basically every other application I have,
>>> except my Swing apps. I make a lot of Swing apps, and I use a bunch too.
>>> And this Magnifier feature that follows text does not work for any of the
>>> ones I have tried.
>>>
>>> This feature does work on basically every other application I have. To
>>> name a few.
>>>
>>> * Notepad++
>>> * WordPad
>>> * Firefox
>>> * Git Bash
>>>
>>> Here is a Bug Report referring to this problem.
>>>
>>> https://bugs.openjdk.org/browse/JDK-5079680
>>>
>>> The resolution was listed as "Future Project". Any chance that the
>>> future can be now?
>>>
>>> I know that Swing is largely in maintenance mode, but if this were to
>>> get added, practically ALL Swing apps would receive a significant boost in
>>> accessibility. I think that's worth making some significant changes for.
>>>
>>> Finally, here is a StackOverflow post I made discussing the same subject.
>>>
>>> https://stackoverflow.com/questions/79281778
>>>
>>> Thank you for your time.
>>> David Alayachew
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250210/d15d82c2/attachment-0001.htm>

From philip.race at oracle.com  Mon Feb 10 22:50:32 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 10 Feb 2025 14:50:32 -0800
Subject: Windows Magnifier does not work with my Swing applications
In-Reply-To: <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
Message-ID: <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>

I think I asked Abhishek to take a look.

-phil.

On 2/10/25 2:41 PM, David Alayachew wrote:
>
> Poke.
>
> Any new info?
>
>
> On Fri, Jan 17, 2025, 8:05?AM David Alayachew 
> <davidalayachew at gmail.com> wrote:
>
>     Hello Phil,
>
>     Did you get any more info about this issue?
>
>
>     On Tue, Dec 17, 2024, 11:58?AM David Alayachew
>     <davidalayachew at gmail.com> wrote:
>
>         Thanks Phil.
>
>         Yeah, I am A-OK as long as this something that is looked into
>         and the JBS Bug Report is updated with the findings. If this
>         isn't too bad, this would be a solid inclusion. But if it's
>         not worth the effort, I just want the JBS to be updated, and
>         then I can put that as an answer for my StackOverflow post.
>
>         Thanks again for taking a look into this.
>
>         On Tue, Dec 17, 2024 at 11:56?AM Philip Race
>         <philip.race at oracle.com> wrote:
>
>             Perhaps .. if it is an easy fix but I do not know the
>             specifics and the evaluator of that bug wrote
>             "the magnifier cannot receive PropertyChangeEvents from
>             Swing. This is a limitation in the Window magnifier.
>             The Windows magnifier could be modified by Microsoft to
>             receive such events but the work would need to be done by
>             Microsoft."
>
>             then went on to add that other magnifiers do work ..
>
>             I also don't know how tied in this would be to
>             implementing support for the Windows Accessibility API.
>
>             Swing apps today use something called JavaAccessBridge and
>             there are screen readers out there that support it.
>
>             It would be good to have another look at this specific
>             issue, but I can't make any promises.
>
>             -phil.
>
>             On 12/15/24 1:04 PM, David Alayachew wrote:
>>             Hello Client Libs Dev Team,
>>
>>             My eyesite has started to deteriorate significantly, so I
>>             have been using the built-in Accessibility tool called
>>             Windows (Screen) Magnifier (available since Windows XP at
>>             least). It zooms in and out of the screen by pressing the
>>             Windows Key and (+) or (-).
>>
>>             This works great because, as I type stuff, the magnifier
>>             will follow my text, so that I don't have to keep
>>             manually moving the magnifier whenever what I type
>>             inevitably ends up off-screen (off-view?).
>>
>>             This feature works great for basically every other
>>             application I have, except my Swing apps. I make a lot of
>>             Swing apps, and I use a bunch too. And this Magnifier
>>             feature that follows text does not work for any of the
>>             ones I have tried.
>>
>>             This feature does work on basically every other
>>             application I have. To name a few.
>>
>>             * Notepad++
>>             * WordPad
>>             * Firefox
>>             * Git Bash
>>
>>             Here is a Bug Report referring to this problem.
>>
>>             https://bugs.openjdk.org/browse/JDK-5079680
>>
>>             The resolution was listed as "Future Project". Any chance
>>             that the future can be now?
>>
>>             I know that Swing is largely in maintenance mode, but if
>>             this were to get added, practically ALL Swing apps would
>>             receive a significant boost in accessibility. I think
>>             that's worth making some significant changes for.
>>
>>             Finally, here is a StackOverflow post I made discussing
>>             the same subject.
>>
>>             https://stackoverflow.com/questions/79281778
>>
>>             Thank you for your time.
>>             David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250210/b8f83db2/attachment.htm>

From dnguyen at openjdk.org  Mon Feb 10 23:03:49 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Feb 2025 23:03:49 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v2]
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <xKmv48_qWC7QwDxWYLOZk4VWQllKweDoR9xfSYmR_Zw=.01d7475c-5e3a-4f9d-9611-3da3e6a8eee3@github.com>

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Increase item count

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23451/files
  - new: https://git.openjdk.org/jdk/pull/23451/files/736a297b..a7856b88

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

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

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

From dnguyen at openjdk.org  Mon Feb 10 23:06:11 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Feb 2025 23:06:11 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <7ixw3YiwKWK3900X6U3PQSGLMUy1PG506GJNETk0sLs=.02992694-3e46-493d-88f4-b4c9534edb9c@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <7ixw3YiwKWK3900X6U3PQSGLMUy1PG506GJNETk0sLs=.02992694-3e46-493d-88f4-b4c9534edb9c@github.com>
Message-ID: <IzSf-OvYQFqr10u3DWYIjeJQTUbpD5gG8oXxfkwLmkc=.2c0a97dc-6d15-4f11-91b8-25b57dca06a3@github.com>

On Mon, 10 Feb 2025 21:08:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Unfortunately, the provided test fails for me on Ubuntu 22.04. On the first `Alt + TAB` it switches to the test frame, so it doesn't trigger the timer to stop.

Ah, I see. Thanks for pointing this out. It wasn't an issue for me because when I ALT+TABed, it went to a different application altogether (and not the test frame for the same java app). I'll test out the `scrollbar.isShowing()` suggestion then.

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

PR Comment: https://git.openjdk.org/jdk/pull/23451#issuecomment-2649452725

From davidalayachew at gmail.com  Mon Feb 10 23:09:29 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Feb 2025 18:09:29 -0500
Subject: Windows Magnifier does not work with my Swing applications
In-Reply-To: <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
Message-ID: <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>

Ok, ty vm. Hey Abhishek, any updates?


On Mon, Feb 10, 2025, 5:50?PM Philip Race <philip.race at oracle.com> wrote:

> I think I asked Abhishek to take a look.
>
> -phil.
>
> On 2/10/25 2:41 PM, David Alayachew wrote:
>
> Poke.
>
> Any new info?
>
> On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hello Phil,
>>
>> Did you get any more info about this issue?
>>
>> On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> Thanks Phil.
>>>
>>> Yeah, I am A-OK as long as this something that is looked into and the
>>> JBS Bug Report is updated with the findings. If this isn't too bad, this
>>> would be a solid inclusion. But if it's not worth the effort, I just want
>>> the JBS to be updated, and then I can put that as an answer for my
>>> StackOverflow post.
>>>
>>> Thanks again for taking a look into this.
>>>
>>> On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com>
>>> wrote:
>>>
>>>> Perhaps .. if it is an easy fix but I do not know the specifics and the
>>>> evaluator of that bug wrote
>>>> "the magnifier cannot receive PropertyChangeEvents from Swing. This is
>>>> a limitation in the Window magnifier.
>>>> The Windows magnifier could be modified by Microsoft to receive such
>>>> events but the work would need to be done by Microsoft."
>>>>
>>>> then went on to add that other magnifiers do work ..
>>>>
>>>> I also don't know how tied in this would be to implementing support for
>>>> the Windows Accessibility API.
>>>>
>>>> Swing apps today use something called JavaAccessBridge and there are
>>>> screen readers out there that support it.
>>>>
>>>> It would be good to have another look at this specific issue, but I
>>>> can't make any promises.
>>>>
>>>> -phil.
>>>>
>>>> On 12/15/24 1:04 PM, David Alayachew wrote:
>>>>
>>>> Hello Client Libs Dev Team,
>>>>
>>>> My eyesite has started to deteriorate significantly, so I have been
>>>> using the built-in Accessibility tool called Windows (Screen) Magnifier
>>>> (available since Windows XP at least). It zooms in and out of the screen by
>>>> pressing the Windows Key and (+) or (-).
>>>>
>>>> This works great because, as I type stuff, the magnifier will follow my
>>>> text, so that I don't have to keep manually moving the magnifier whenever
>>>> what I type inevitably ends up off-screen (off-view?).
>>>>
>>>> This feature works great for basically every other application I have,
>>>> except my Swing apps. I make a lot of Swing apps, and I use a bunch too.
>>>> And this Magnifier feature that follows text does not work for any of the
>>>> ones I have tried.
>>>>
>>>> This feature does work on basically every other application I have. To
>>>> name a few.
>>>>
>>>> * Notepad++
>>>> * WordPad
>>>> * Firefox
>>>> * Git Bash
>>>>
>>>> Here is a Bug Report referring to this problem.
>>>>
>>>> https://bugs.openjdk.org/browse/JDK-5079680
>>>>
>>>> The resolution was listed as "Future Project". Any chance that the
>>>> future can be now?
>>>>
>>>> I know that Swing is largely in maintenance mode, but if this were to
>>>> get added, practically ALL Swing apps would receive a significant boost in
>>>> accessibility. I think that's worth making some significant changes for.
>>>>
>>>> Finally, here is a StackOverflow post I made discussing the same
>>>> subject.
>>>>
>>>> https://stackoverflow.com/questions/79281778
>>>>
>>>> Thank you for your time.
>>>> David Alayachew
>>>>
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250210/2980ec88/attachment-0001.htm>

From dgredler at openjdk.org  Mon Feb 10 23:18:18 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 10 Feb 2025 23:18:18 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v5]
In-Reply-To: <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
Message-ID: <AYQByTZ977epZWO6h_4NAMEatY6NmrlsipcYSkHAxRk=.43403b7e-4da9-4d3a-a8e9-fe4a0d15c2a4@github.com>

On Mon, 10 Feb 2025 20:36:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Soft hyphens should never render, regardless of the rendering path used internally.
>> 
>> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
>> 
>> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
>> 
>> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.
>
> Daniel Gredler 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 'master' into JDK-8208377
>  - Update copyright year
>  - Add more info about test fonts and default-ignorable chars
>  - Add macOS-specific char mapper changes
>  - Always use invisible glyphs for 'default ignorable' chars

The "ready" tag was removed and the reviewed checkbox under "progress" was unchecked when I updated the copyright year today... is there something else I need to do prior to integrating?

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

PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2649470094

From prr at openjdk.org  Mon Feb 10 23:36:18 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Feb 2025 23:36:18 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v5]
In-Reply-To: <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
Message-ID: <KVN8o9P_ZbrcnyoWa63lo4owMfrPF62qyT1W1224FA8=.4803a7fc-ddc0-4b6e-9889-68cfa8dcaaf1@github.com>

On Mon, 10 Feb 2025 20:36:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Soft hyphens should never render, regardless of the rendering path used internally.
>> 
>> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
>> 
>> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
>> 
>> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.
>
> Daniel Gredler 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 'master' into JDK-8208377
>  - Update copyright year
>  - Add more info about test fonts and default-ignorable chars
>  - Add macOS-specific char mapper changes
>  - Always use invisible glyphs for 'default ignorable' chars

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22670#pullrequestreview-2607404483

From prr at openjdk.org  Mon Feb 10 23:36:19 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Feb 2025 23:36:19 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v5]
In-Reply-To: <AYQByTZ977epZWO6h_4NAMEatY6NmrlsipcYSkHAxRk=.43403b7e-4da9-4d3a-a8e9-fe4a0d15c2a4@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
 <AYQByTZ977epZWO6h_4NAMEatY6NmrlsipcYSkHAxRk=.43403b7e-4da9-4d3a-a8e9-fe4a0d15c2a4@github.com>
Message-ID: <2PtDc928dh7R_U9VtgfCG6cBROYN_-ss_ivkgWzqYM8=.6bc7d6f6-c0d2-42ab-b57a-f1a38f7fcda4@github.com>

On Mon, 10 Feb 2025 23:15:49 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> The "ready" tag was removed and the reviewed checkbox under "progress" was unchecked when I updated the copyright year today... is there something else I need to do prior to integrating?

Re-approval is required after any change.
I've re-approved so it should be ready again soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2649492552

From duke at openjdk.org  Mon Feb 10 23:51:19 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Feb 2025 23:51:19 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v5]
In-Reply-To: <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <z-Rz8jJScH4nPg2SOKxwkEhPL34POeal0L377334ivU=.f0d086f3-b24f-4582-9ce1-a6e12e2c8e54@github.com>
Message-ID: <jjQUdAsLycaKBijKdL9LbX3Qmkkr3Fl0KhNRjWFs23I=.79c5ec1f-d6ff-4475-ac66-765d5615e0da@github.com>

On Mon, 10 Feb 2025 20:36:46 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Soft hyphens should never render, regardless of the rendering path used internally.
>> 
>> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
>> 
>> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
>> 
>> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.
>
> Daniel Gredler 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 'master' into JDK-8208377
>  - Update copyright year
>  - Add more info about test fonts and default-ignorable chars
>  - Add macOS-specific char mapper changes
>  - Always use invisible glyphs for 'default ignorable' chars

@gredler 
Your change (at version e34e0081cc30d17f3d82b800e464843386256323) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2649510519

From dgredler at openjdk.org  Tue Feb 11 00:42:17 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 11 Feb 2025 00:42:17 GMT
Subject: Integrated: 8208377: Soft hyphens render if not using TextLayout
In-Reply-To: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
Message-ID: <FlVfC21OXuGTnkxhU4z9YcPxFM8eO5-jcE6lMzdEDCM=.49d2827e-bbc6-4d1b-806e-0daa86441de4@github.com>

On Tue, 10 Dec 2024 20:09:09 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Soft hyphens should never render, regardless of the rendering path used internally.
> 
> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS).
> 
> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
> 
> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated.

This pull request has now been integrated.

Changeset: 41bdc47d
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41bdc47d71340e5d7f4317a5040521868d4c4314
Stats:     468 lines in 6 files changed: 438 ins; 16 del; 14 mod

8208377: Soft hyphens render if not using TextLayout

Reviewed-by: achung, prr

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

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

From honkar at openjdk.org  Tue Feb 11 01:10:20 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Feb 2025 01:10:20 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
Message-ID: <F_fInN-6KG3tplPYNlDetakDVJM3HVZOoC-dExPUfSA=.2a0edd66-5296-4cfd-9d78-442d68592e40@github.com>

On Mon, 3 Feb 2025 18:50:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset updates the pipewire headers to the latest available version.
> It contains the minimum set of required header files needed to build the JDK.
> 
> The updated headers are a direct copy from the 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
>  
> Testing looks good.

@azvegint 
Update looks good. Local build looks good. 
Tests work the same without and with the upgrade. No regression observed.

One thing that I noticed and wanted discuss further: when I delete the screencast-tokens.properties file and the permission is granted for the first screen share (new token generated), it asks for permission every time for subsequent screen share and I see multiple screencast tokens in the .properties file instead of one. IIRC the token setup is one time and the subsequent requests are there after allowed or am I missing some setup step ?

Note: This is not related to the upgrade (happens even without the fix)

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

PR Review: https://git.openjdk.org/jdk/pull/23426#pullrequestreview-2607484981

From dgredler at openjdk.org  Tue Feb 11 01:44:23 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 11 Feb 2025 01:44:23 GMT
Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v3]
In-Reply-To: <1oqys5goIrKZj-y2k6JqgApfncKx27MlfYkdFG7zIzU=.a41f71da-2caa-430e-8e51-95fa094d3531@github.com>
References: <Wd7xl3bFoqv_UElsZ3Aq8W078bsHD3ykjH2urVZGjmQ=.cd0fdaf8-43f6-4902-8dd4-28ff8abba9fb@github.com>
 <lt9t4q8rrb5lhHTMTZ6n47xTtywK23rFUxzQdg15_4s=.858daee3-e155-409b-b67e-eaf3603743e5@github.com>
 <1oqys5goIrKZj-y2k6JqgApfncKx27MlfYkdFG7zIzU=.a41f71da-2caa-430e-8e51-95fa094d3531@github.com>
Message-ID: <sYLWO50rxZQjbKcsy0NPo3M2WuUgSa23LRTYFtZ18D4=.40a95236-573c-4cf3-b30a-a2c81f9b6ac9@github.com>

On Tue, 24 Dec 2024 19:48:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more info about test fonts and default-ignorable chars
>
> src/java.desktop/share/classes/sun/font/FontUtilities.java line 366:
> 
>> 364:                 case 0x20: return (charCode >= 0x200B && charCode <= 0x200F) ||
>> 365:                                   (charCode >= 0x202A && charCode <= 0x202E) ||
>> 366:                                   (charCode >= 0x2060 && charCode <= 0x206F);
> 
> I just noticed this really old open bug
> https://bugs.openjdk.org/browse/JDK-6562489 : Font-Renderer should ignore invisible characters \u2062 and \u2063

Thanks for the pointer, I've created PR #23547 to verify that JDK-6562489 is also fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22670#discussion_r1950122686

From dgredler at openjdk.org  Tue Feb 11 01:46:00 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 11 Feb 2025 01:46:00 GMT
Subject: RFR: 6562489: Font-Renderer should ignore invisible characters \u2062
 and \u2063
Message-ID: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>

Expands regression test to cover bug JDK-6562489.

No additional fix is required after the JDK-8208377 fix (see #22670).

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

Commit messages:
 - Expand regression test to cover bug 6562489

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

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

From serb at openjdk.org  Tue Feb 11 02:53:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 02:53:19 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v2]
In-Reply-To: <2Ur6_ymOMG_ItEYncKnpkPPd0TuAM3Cr93dQM9XAmMA=.c04a9ee1-ad2b-45b3-88b0-0ddaee66ea1f@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <s6wAL7uQQd4ARvjj6uqKBcq0hZUb1se1CFdq0yUKs_s=.ef99abfb-4fb3-4815-a552-3aaacf90147d@github.com>
 <2Ur6_ymOMG_ItEYncKnpkPPd0TuAM3Cr93dQM9XAmMA=.c04a9ee1-ad2b-45b3-88b0-0ddaee66ea1f@github.com>
Message-ID: <ICiPA3XCj1Stj6pVeft_Z1mpOQROo2slFyk7x-w4bvY=.6eed32a4-fc4e-46a2-b443-1865d6ebc7ce@github.com>

On Wed, 29 Jan 2025 12:18:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JButton/4796987/bug4796987.java line 60:
>> 
>>> 58:     public static void main(String[] args) throws Exception {
>>> 59:         try {
>>> 60:             UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>> 
>> maybe we can check all installed L&Fs?
>
> It's not applicable to other L&Fs as far as I can see.

Even for classic windows?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1950170115

From psadhukhan at openjdk.org  Tue Feb 11 03:03:15 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Feb 2025 03:03:15 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
In-Reply-To: <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
 <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>
Message-ID: <nHKrseB4YhnpLc2xLVMXRHFcZwA3WVDgRPA2JRutcoI=.b1a77194-de05-4f6a-88e0-07fa7a231d49@github.com>

On Mon, 10 Feb 2025 17:35:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore Windows 10 behavior
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 663:
> 
>> 661:         paintIcon(g, lh, lr, holdc);
>> 662:         if (UIManager.getLookAndFeel().getName().equals("Windows")
>> 663:             && System.getProperty("os.name").equals("Windows 11")
> 
> It's not what I meant.
> 
> I suggested painting the menu items *the same way* for Windows 10 and 11. Yet the layout for Windows 11 should be tweaked.
> 
> To be clear, the bullet / check-mark is painted at the same location where it would be painted if there were no custom icon for both Windows 10 and 11. The custom icon is painted to the right of the bullet / check-mark, and the menu text moves farther to the right.

This will preserve existing windows 10 behavior and at the same time, it will show Windows 11 File explorer behavior.
What is the need to show the same way for WIndows 10 and 11 when it will not be same as what native does for windows 10.

I am sorry but I dont agree to this...

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

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

From psadhukhan at openjdk.org  Tue Feb 11 03:14:14 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Feb 2025 03:14:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <NbdvRYDyFGaYKtE2wtBJD_sWFz5dlTuHSv-iSHnpT60=.abb2997d-8c89-485d-90b5-594d914e3541@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
 <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>
 <NbdvRYDyFGaYKtE2wtBJD_sWFz5dlTuHSv-iSHnpT60=.abb2997d-8c89-485d-90b5-594d914e3541@github.com>
Message-ID: <4bdkDW7dmnQj6PYp8owb8Bucp9s-MVsYbWJPKX1JM84=.0a5cfea0-eb01-4694-9ce9-37a7e52dc6e3@github.com>

On Mon, 10 Feb 2025 16:54:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I tried but Many a thing cannot be accessed outside plaf.basic package and I am checking for WIndows L&F so Metal will not be affected..
>
>> I am checking for WIndows L&F so Metal will not be affected.
> 
> This is the reason why I don't like this approach: the base class needs to know about Windows L&F and do some customisation based on the current L&F. This code will be included on Linux and macOS where Windows L&F isn't available.
> 
> A better solution would be a helper method or a helper class which handles this difference.
> 
> As far as I can see, Metal L&F paints both the bullet / check-mark and the custom icon ? this is exactly what you're implementing here. The difference is in margins around these elements.
> 
> The layout of the menu is handled by `MenuItemLayoutHelper`. It's customised for Synth L&F in `SynthMenuItemLayoutHelper`. Perhaps, you need to create a customised class for Windows L&F.
> 
> Yet there's no hook in `BasicMenuItemUI` to create or pass another `MenuItemLayoutHelper` object which customises the layout. A new method may be added.
> 
> ---
> 
> I haven't looked deeply into how popup menus are laid out and therefore I can't advice on how to customise menu item layout.

It is just checking for current L&F is Windows or not..I am not even checking for "instanceof WIndowsLookAndFeel" which will not be present in linux and mac so I dont think it will create any problem..
Helper method will create unnecessary changes in all L&F..I dont think I will like to do that..

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

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

From psadhukhan at openjdk.org  Tue Feb 11 03:16:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Feb 2025 03:16:11 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v2]
In-Reply-To: <k6TZ0TTd-CQnoB-7SvXWh701Hf_hzScujtVnOSKLSZU=.44ec1d04-559a-4112-8aaa-d363e445fad7@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <k6TZ0TTd-CQnoB-7SvXWh701Hf_hzScujtVnOSKLSZU=.44ec1d04-559a-4112-8aaa-d363e445fad7@github.com>
Message-ID: <VPeYnr4KWVeDc1RUqO3P1C2fueZD2xXEbNh78Cd4mbQ=.b691290a-b8c3-4182-a649-b57f9494055c@github.com>

On Fri, 7 Feb 2025 08:24:54 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace regexp s+ with space

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23457#pullrequestreview-2607603182

From serb at openjdk.org  Tue Feb 11 03:28:12 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 03:28:12 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <yVk7fclScB_b7XLjEjPVI241HeNqq8dsNiaqWmOAaPg=.bad85dc6-2323-4e39-b274-c22c85e24b63@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <yVk7fclScB_b7XLjEjPVI241HeNqq8dsNiaqWmOAaPg=.bad85dc6-2323-4e39-b274-c22c85e24b63@github.com>
Message-ID: <y_m13jBR4ae7HLFkkZhNSbTyOjvsLMd-dUPJ4itr-Ts=.88e18813-2990-418f-84c3-645d3fd7ca5d@github.com>

On Sat, 8 Feb 2025 04:21:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>>   
>>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>
>
> In jdk 9 we started to sort the list of methods for each class for a few reasons, and the main one was:
>  1. We had a number of bugs which state that our JavaBeans randomly does not work, examples: JDK-6807471[1] , JDK-6788525[2], the reason was that the order of methods from Class.getMethods() is not specified.
> 
> So MethodOrder is just a workaround to help us reproduce the bugs. I understand how the current change will fix the problem, but it would be nice to update the code that retrieves the method from that list, or at least provide some information why we can't do that.
> 
> Example from the past https://github.com/openjdk/jdk/pull/7190 where MethodOrder was simplified due to JDK-8196373

> @mrserb Sorry, I don't feel I completely understand what are you asking for. What do you mean "the code that retrieves the method from that list"? Should I add comments somewhere in source code with the issue details why does Introspector.addMethod() work wrong for now, or with details about sorting? Or should I update the PR description? I couldn't find any clues in #7190, sorry.

In the past we received various reports that were caused by bugs in the Introspector implementation, but we could not reproduce them because that bugs depended on some order of methods returned by the Class.getMethods().

So, the method you updated was added to make the method list stable, it is just a utility wrapper. You don't need to update that method.

But instead you can change the code that uses the result of MethodInfo.get() in `PropertyInfo.get()` or `PropertyInfo.initialize()` where we created the property to pick the correct default/non-default method.

Or, most likely, you can skip adding the default method in MethodInfo.get() if non-default methods are already added.

> 
> And BTW, I'm concerning why I can't find a check in this PR which builds and tests the change. Should I trigger it somehow, or is it just invisible for me?

You should enable that actions/checks in your fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2649725000

From serb at openjdk.org  Tue Feb 11 03:38:17 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 03:38:17 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <7Yk8--fxUHtcRiqugZkgB8AfQylsbDGoOjDOwx3Omi4=.4b785758-0e95-4be8-8b2a-94946a1e2132@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

For example, if you change the return type of getDefault1 to String, the correct method will be chosen, because the code for covariance types will discard the "Object version" and choose the "String version" of the method.

Similar logic should be added to discard default methods if the same non-default method exists.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2649733108

From rkannathpari at openjdk.org  Tue Feb 11 04:27:15 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 11 Feb 2025 04:27:15 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v4]
In-Reply-To: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
Message-ID: <9FygT9Sdo-vUEeU6GFVNDGiLqEkgKHhmhcoTE7alD1A=.c9f2730a-a786-4dd3-892a-1fa7231e707c@github.com>

> Hi Reviewers,
> 
> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
> 
> Regards,
> Renjith.

Renjith Kannath Pariyangad 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 master
 - Rearranged if based on suggesion
 - Suggesions updated
 - Removed space
 - JDK-8328977 : JEditorPane.setPage not thread-safe, pageLoader not cancelled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18670/files
  - new: https://git.openjdk.org/jdk/pull/18670/files/be168e9d..6fccd277

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

  Stats: 1363885 lines in 17112 files changed: 835949 ins; 411674 del; 116262 mod
  Patch: https://git.openjdk.org/jdk/pull/18670.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18670/head:pull/18670

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

From psadhukhan at openjdk.org  Tue Feb 11 04:35:44 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 11 Feb 2025 04:35:44 GMT
Subject: RFR: 8347019: Test javax/swing/JRadioButton/8033699/bug8033699.java
 still fails:  Focus is not on Radio Button Single as Expected
Message-ID: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>

Test seems to fail in ubuntu 22.04 system..It seems removing setAutoDelay is making the test more stable in such systems.
Tested in all platforms where it is still ok without auto delay. CI job link in JBS..

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

Commit messages:
 - Test javax/swing/JRadioButton/8033699/bug8033699.java still fails: Focus is not on Radio Button Single as Expected

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

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

From serb at openjdk.org  Tue Feb 11 04:59:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 04:59:09 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <ksrb_MI8wmxVDOObEh4AtR96MFngsqhchj3nbU7gg9U=.193e2a20-a8c3-4eea-8c03-1bf428f3bf76@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

Also please check the next example:

import java.beans.IntrospectionException;

public class Test {

    public interface A {
        default void setFoo(Integer num) {
        }
    }

    public class D implements A {
        public void setFoo(Number num) {
        }
//        public Integer getFoo() {
//            return null;
//        }
    }

    public class AC {
        public void setFoo(Integer num) {
        }
    }

    public class DC extends AC {
        public void setFoo(Number num) {
        }
//        public Integer getFoo() {
//            return null;
//        }
    }

    public static void main(String[] args) throws java.beans.IntrospectionException {
        test(D.class);
        test(DC.class);
    }

    private static void test(Class beanClass) throws IntrospectionException {
        System.out.println("\nbeanClass = " + beanClass);
        var info = java.beans.Introspector.getBeanInfo(beanClass, Object.class);
        System.out.println(info.getBeanDescriptor());
        System.out.println("--- properties");
        for (var desc : info.getPropertyDescriptors()) {
            System.out.println(desc.getReadMethod());
            System.out.println(desc.getWriteMethod());
        }
    }
}

Is the next output expected()?


beanClass = class Test$D
java.beans.BeanDescriptor[name=Test$D; beanClass=class Test$D]
--- properties
public java.lang.Integer Test$D.getFoo()
public default void Test$A.setFoo(java.lang.Integer)

beanClass = class Test$DC
java.beans.BeanDescriptor[name=Test$DC; beanClass=class Test$DC]
--- properties
public java.lang.Integer Test$DC.getFoo()
public void Test$AC.setFoo(java.lang.Integer)



btw it will be good to cover this scenario in the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2649798470

From abhishek.cx.kumar at oracle.com  Tue Feb 11 05:49:59 2025
From: abhishek.cx.kumar at oracle.com (Abhishek Kumar)
Date: Tue, 11 Feb 2025 05:49:59 +0000
Subject: [External] : Re: Windows Magnifier does not work with my Swing
 applications
In-Reply-To: <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
 <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
Message-ID: <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>

Hello David,

Yeah, I will evaluate if existing JDK implementation can be extended to work with Windows Magnifier. I didn?t get enough time to look into this issue due to other issues but this is on my to-do list. I will update my findings on JBS after my analysis.

Thank you for your patience.

Regards,
Abhishek

From: David Alayachew <davidalayachew at gmail.com>
Date: Tuesday, 11 February 2025 at 4:39?AM
To: Philip Race <philip.race at oracle.com>
Cc: Abhishek Kumar <abhishek.cx.kumar at oracle.com>, client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: [External] : Re: Windows Magnifier does not work with my Swing applications

Ok, ty vm. Hey Abhishek, any updates?

On Mon, Feb 10, 2025, 5:50?PM Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:
I think I asked Abhishek to take a look.

-phil.
On 2/10/25 2:41 PM, David Alayachew wrote:

Poke.

Any new info?

On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:

Hello Phil,

Did you get any more info about this issue?

On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Thanks Phil.

Yeah, I am A-OK as long as this something that is looked into and the JBS Bug Report is updated with the findings. If this isn't too bad, this would be a solid inclusion. But if it's not worth the effort, I just want the JBS to be updated, and then I can put that as an answer for my StackOverflow post.

Thanks again for taking a look into this.

On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:
Perhaps .. if it is an easy fix but I do not know the specifics and the evaluator of that bug wrote
"the magnifier cannot receive PropertyChangeEvents from Swing. This is a limitation in the Window magnifier.
The Windows magnifier could be modified by Microsoft to receive such events but the work would need to be done by Microsoft."

then went on to add that other magnifiers do work ..

I also don't know how tied in this would be to implementing support for the Windows Accessibility API.

Swing apps today use something called JavaAccessBridge and there are screen readers out there that support it.

It would be good to have another look at this specific issue, but I can't make any promises.

-phil.

On 12/15/24 1:04 PM, David Alayachew wrote:
Hello Client Libs Dev Team,

My eyesite has started to deteriorate significantly, so I have been using the built-in Accessibility tool called Windows (Screen) Magnifier (available since Windows XP at least). It zooms in and out of the screen by pressing the Windows Key and (+) or (-).

This works great because, as I type stuff, the magnifier will follow my text, so that I don't have to keep manually moving the magnifier whenever what I type inevitably ends up off-screen (off-view?).

This feature works great for basically every other application I have, except my Swing apps. I make a lot of Swing apps, and I use a bunch too. And this Magnifier feature that follows text does not work for any of the ones I have tried.

This feature does work on basically every other application I have. To name a few.

* Notepad++
* WordPad
* Firefox
* Git Bash

Here is a Bug Report referring to this problem.

https://bugs.openjdk.org/browse/JDK-5079680

The resolution was listed as "Future Project". Any chance that the future can be now?

I know that Swing is largely in maintenance mode, but if this were to get added, practically ALL Swing apps would receive a significant boost in accessibility. I think that's worth making some significant changes for.

Finally, here is a StackOverflow post I made discussing the same subject.

https://stackoverflow.com/questions/79281778<https://urldefense.com/v3/__https:/stackoverflow.com/questions/79281778__;!!ACWV5N9M2RV99hQ!Ly4-UF3NKnfHKegv0u1A73-bJexJCRENPe2tHIfIZbS-UVOiAyGFuQ5ftsZLZ3nYii9HnobMtSSE1q01jU3NB22v20jnRIk$>

Thank you for your time.
David Alayachew


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250211/06b2f348/attachment-0001.htm>

From serb at openjdk.org  Tue Feb 11 06:18:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 06:18:09 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <q5Bl2cql6c_Qu5pdeDloz-_20vRBkngG-v_GLuB7_iI=.18a3e49f-b333-47a0-a767-e671c04d98ac@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

I also would like to discuss the next small example.


import java.beans.*;
import java.lang.reflect.Method;

interface Parent1<T> {
    T getValue();
}

interface Parent2 {
    Runnable getValue();
}

interface Parent3 extends Parent2, Parent1<Object> {
    Runnable getValue();
}

abstract class Child implements Parent3 {
    public void setValue(Runnable value) {
    }
}

public class BeansMainInt {
    public static void main(String[] args) throws Exception {
        BeanInfo beanInfo = Introspector.getBeanInfo(Child.class);
        for (PropertyDescriptor pd : beanInfo.getPropertyDescriptors()) {
            Method writeMethod = pd.getWriteMethod();
            Method readMethod = pd.getReadMethod();
            System.out.println(pd.getName()+ ":\n ** " + pd.getPropertyType()
                    + "\n >> " + readMethod + "\n << " + writeMethod);
        }
    }
}



Before the JDK-8071693 the output is:
value:
 ** interface java.lang.Runnable
 >> null
 << public void Child.setValue(java.lang.Runnable)


Current output is(this patch did not change it):

value:
 ** class java.lang.Object
 >> public default java.lang.Object Parent3.getValue()
 << public void Child.setValue(java.lang.Runnable)


Is `default Parent3.getValue()` really supposed to be the writer for the "value" property, that looks suspicious?

If you replace interfaces with abstract classes then you will get the old output:



import java.beans.*;
import java.lang.reflect.Method;

abstract class Parent1<T> {
    abstract T getValue();
}

abstract class Parent2 {
    abstract Runnable getValue();
}

abstract class Parent3 extends Parent2 {
    abstract Runnable getValue();
}

abstract class Child extends Parent3 {
    public void setValue(Runnable value) {
    }
}

public class BeansMainInt {
    public static void main(String[] args) throws Exception {
        BeanInfo beanInfo = Introspector.getBeanInfo(Child.class);
        for (PropertyDescriptor pd : beanInfo.getPropertyDescriptors()) {
            Method writeMethod = pd.getWriteMethod();
            Method readMethod = pd.getReadMethod();
            System.out.println(pd.getName()+ ":\n ** " + pd.getPropertyType()
                    + "\n >> " + readMethod + "\n << " + writeMethod);
        }
    }
}

value:
 ** interface java.lang.Runnable
 >> null
 << public void Child.setValue(java.lang.Runnable)

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2649891398

From tr at openjdk.org  Tue Feb 11 07:30:13 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Feb 2025 07:30:13 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v3]
In-Reply-To: <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
 <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
Message-ID: <A5cTFgZoss9kkN-meIs55M6JqQeJkHNqu9eMYuWXYVI=.24d13f58-d38e-4fce-a299-0f272823be2c@github.com>

On Fri, 7 Feb 2025 22:20:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FileDialogIconTest.java has been updated.
>> 
>> Following changes were made.
>> 
>> -  Test instructions updated
>> -  BugID associated with the test is updated to the correct one
>> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
>> -  other minor cleanups
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

test/jdk/java/awt/Dialog/FileDialogIconTest/FileDialogIconTest.java line 43:

> 41:  * @test
> 42:  * @bug 6425126
> 43:  * @summary Test to verify that PIT File Dialog icon not matching with

Do we still need PIT build/PIT file Dailog in summary? The main bug seems to be in solaris.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23523#discussion_r1950354536

From tr at openjdk.org  Tue Feb 11 08:00:15 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 11 Feb 2025 08:00:15 GMT
Subject: RFR: JDK-8348302 : [Test bug] Update FileDialogIconTest.java [v3]
In-Reply-To: <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
References: <UedOumWExQMSQUDfGGYk-MRweA5qeQCLBNXQI5Q8eUc=.02820a01-54ca-46a7-ac8d-82b767dab53e@github.com>
 <eU2GSg4hFfqExsn60PUoWTArbOS4Wg7jd2ggR0HE0YM=.1fe1e75a-f4be-476b-902d-1bdb6f4519b2@github.com>
Message-ID: <xLpQpXppifR6SQcjwqhIoOQQubDOnO4nryQ2attFLU4=.c6eed474-4e71-4669-948e-f8f6d419ace3@github.com>

On Fri, 7 Feb 2025 22:20:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FileDialogIconTest.java has been updated.
>> 
>> Following changes were made.
>> 
>> -  Test instructions updated
>> -  BugID associated with the test is updated to the correct one
>> -  setIconBufferedImagesToFrame and setIconBufferedImagesToDialog btns added to the frame.
>> -  other minor cleanups
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor

As per my testing and understanding (correct me if I'm wrong)
1. `setIconImageToFrame` button set the icon of Frame to Java image.
2. `setIconBufferedImagesToFrame` button sets captured image to icon for both JFrame and also Dialogs. (As you have mentioned in JBS comments and also from [JDK-6425126](https://bugs.openjdk.org/browse/JDK-6425126))
3. Apart from these two buttons I don't see any actions for other buttons (including setting icon image buttons for Dialog). 
Can you please update the test instructions mentioning about the icon matching with both JFrame and JDialog once its set.

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

PR Review: https://git.openjdk.org/jdk/pull/23523#pullrequestreview-2607941452

From jwaters at openjdk.org  Tue Feb 11 08:36:14 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 11 Feb 2025 08:36:14 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
In-Reply-To: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
Message-ID: <5Ou0SpG4cIgTUAx2L22VryWFwm6RYqJ5odO1lFPlvZw=.a56f642d-9265-4b94-91ed-f992d5f6bf60@github.com>

On Mon, 10 Feb 2025 19:07:49 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Filed as a separate issue to keep the #23426 clean.
> 
> Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)

src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h line 16:

> 14: #if !defined(AIX)
> 15: #include <spa/utils/endian.h>
> 16: #endif

The ifdef conditional blocks could be merged if I am not mistaken?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23543#discussion_r1950424978

From davidalayachew at gmail.com  Tue Feb 11 10:52:08 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 11 Feb 2025 05:52:08 -0500
Subject: [External] : Re: Windows Magnifier does not work with my Swing
 applications
In-Reply-To: <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
 <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
 <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_OGuk9UAP2xN5pi+TaZXM55patErtyW38jHX5frWG2NbQ@mail.gmail.com>

And thank you.

On Tue, Feb 11, 2025, 12:50?AM Abhishek Kumar <abhishek.cx.kumar at oracle.com>
wrote:

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

From azvegint at openjdk.org  Tue Feb 11 11:25:05 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 11 Feb 2025 11:25:05 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v2]
In-Reply-To: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
Message-ID: <DtJW_rQULuMZsLeG5zrpNuimPKccCd2Crzl3PCoAahg=.1805b3a1-6886-4a19-98e9-50c6fd89380b@github.com>

> Filed as a separate issue to keep the #23426 clean.
> 
> Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  merge "if defined"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23543/files
  - new: https://git.openjdk.org/jdk/pull/23543/files/91891e66..87227ff8

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

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

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

From azvegint at openjdk.org  Tue Feb 11 11:40:39 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 11 Feb 2025 11:40:39 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v3]
In-Reply-To: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
Message-ID: <5PCD5IdsalKcq3kZ8E_IYPFRcAHK6_lKFOPyI0fqYxU=.c7a694ba-dc51-4412-a3db-3ea91c82a8d3@github.com>

> Filed as a separate issue to keep the #23426 clean.
> 
> Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  move fix to spa/utils/endian.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23543/files
  - new: https://git.openjdk.org/jdk/pull/23543/files/87227ff8..600ddb95

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

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

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

From azvegint at openjdk.org  Tue Feb 11 11:45:11 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 11 Feb 2025 11:45:11 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v3]
In-Reply-To: <5Ou0SpG4cIgTUAx2L22VryWFwm6RYqJ5odO1lFPlvZw=.a56f642d-9265-4b94-91ed-f992d5f6bf60@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
 <5Ou0SpG4cIgTUAx2L22VryWFwm6RYqJ5odO1lFPlvZw=.a56f642d-9265-4b94-91ed-f992d5f6bf60@github.com>
Message-ID: <sySMzPKixDdMTOzWIjZJ5U-CAT1QPWb0fKeBFw30zRg=.3065ad24-0999-4828-82bb-418dd80af8ee@github.com>

On Tue, 11 Feb 2025 08:33:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move fix to spa/utils/endian.h
>
> src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h line 16:
> 
>> 14: #if !defined(AIX)
>> 15: #include <spa/utils/endian.h>
>> 16: #endif
> 
> The ifdef conditional blocks could be merged if I am not mistaken?

Yes, at first I kept it as it was in the original fix.
But after revisiting it, I think that it is belongs in the new `spa/utils/endian.h` file.

@MBaesken could you please recheck if it still works for you?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23543#discussion_r1950694146

From avu at openjdk.org  Tue Feb 11 14:09:17 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 11 Feb 2025 14:09:17 GMT
Subject: RFR: 6562489: Font-Renderer should ignore invisible characters
 \u2062 and \u2063
In-Reply-To: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
References: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
Message-ID: <fi8bg3Wpddoq1hnzEDeo6Ks8SdVzId0ZpSc5p8nN5dM=.acabf2eb-f0c3-4b75-a3e6-9255f747e66b@github.com>

On Tue, 11 Feb 2025 01:40:01 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Expands regression test to cover bug JDK-6562489.
> 
> No additional fix is required after the JDK-8208377 fix (see #22670).

The test update looks good to me.

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23547#pullrequestreview-2608867285

From aivanov at openjdk.org  Tue Feb 11 15:04:21 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Feb 2025 15:04:21 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
In-Reply-To: <nHKrseB4YhnpLc2xLVMXRHFcZwA3WVDgRPA2JRutcoI=.b1a77194-de05-4f6a-88e0-07fa7a231d49@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
 <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>
 <nHKrseB4YhnpLc2xLVMXRHFcZwA3WVDgRPA2JRutcoI=.b1a77194-de05-4f6a-88e0-07fa7a231d49@github.com>
Message-ID: <K8rmJpvvxJA6--UBb5vNd-iQ2CcHmHmxtYbQuSj6y-M=.d1b6e2f9-c08b-4d84-b028-37756d181a8e@github.com>

On Tue, 11 Feb 2025 03:00:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 663:
>> 
>>> 661:         paintIcon(g, lh, lr, holdc);
>>> 662:         if (UIManager.getLookAndFeel().getName().equals("Windows")
>>> 663:             && System.getProperty("os.name").equals("Windows 11")
>> 
>> It's not what I meant.
>> 
>> I suggested painting the menu items *the same way* for Windows 10 and 11. Yet the layout for Windows 11 should be tweaked.
>> 
>> To be clear, the bullet / check-mark is painted at the same location where it would be painted if there were no custom icon for both Windows 10 and 11. The custom icon is painted to the right of the bullet / check-mark, and the menu text moves farther to the right.
>
> This will preserve existing windows 10 behavior and at the same time, it will show Windows 11 File explorer behavior.
> What is the need to show the same way for WIndows 10 and 11 when it will not be same as what native does for windows 10.
> 
> I am sorry but I dont agree to this...

Because, as you say, support for Windows 10 ends in October this year.

For this reason, I'd rather avoid the complexity of supporting different look for Windows 10 and 11.

I won't object to this if you think it's important to support Windows 10 look.

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

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

From aivanov at openjdk.org  Tue Feb 11 15:04:20 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Feb 2025 15:04:20 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <4bdkDW7dmnQj6PYp8owb8Bucp9s-MVsYbWJPKX1JM84=.0a5cfea0-eb01-4694-9ce9-37a7e52dc6e3@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
 <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>
 <NbdvRYDyFGaYKtE2wtBJD_sWFz5dlTuHSv-iSHnpT60=.abb2997d-8c89-485d-90b5-594d914e3541@github.com>
 <4bdkDW7dmnQj6PYp8owb8Bucp9s-MVsYbWJPKX1JM84=.0a5cfea0-eb01-4694-9ce9-37a7e52dc6e3@github.com>
Message-ID: <nQoe_O7wLmnqTvLR6kF5fxLMe_EqnusO8LbA0uXAITA=.9e797e03-fbd5-4512-b4a7-5d68183f2c94@github.com>

On Tue, 11 Feb 2025 03:11:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> I am checking for WIndows L&F so Metal will not be affected.
>> 
>> This is the reason why I don't like this approach: the base class needs to know about Windows L&F and do some customisation based on the current L&F. This code will be included on Linux and macOS where Windows L&F isn't available.
>> 
>> A better solution would be a helper method or a helper class which handles this difference.
>> 
>> As far as I can see, Metal L&F paints both the bullet / check-mark and the custom icon ? this is exactly what you're implementing here. The difference is in margins around these elements.
>> 
>> The layout of the menu is handled by `MenuItemLayoutHelper`. It's customised for Synth L&F in `SynthMenuItemLayoutHelper`. Perhaps, you need to create a customised class for Windows L&F.
>> 
>> Yet there's no hook in `BasicMenuItemUI` to create or pass another `MenuItemLayoutHelper` object which customises the layout. A new method may be added.
>> 
>> ---
>> 
>> I haven't looked deeply into how popup menus are laid out and therefore I can't advice on how to customise menu item layout.
>
> It is just checking for current L&F is Windows or not..I am not even checking for "instanceof WIndowsLookAndFeel" which will not be present in linux and mac so I dont think it will create any problem..
> Helper method will create unnecessary changes in all L&F..I dont think I will like to do that..

It just feels wrong? A superclass doesn't need to know, shouldn't know, about its subclasses.

Yet this solution could be the simplest one? if achieving the same effect different makes the code too complicated.

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

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

From aivanov at openjdk.org  Tue Feb 11 15:18:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Feb 2025 15:18:11 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v2]
In-Reply-To: <yFXftYoFtKgGt5JSZwvzVB6odANQ1gmkOL6uJhaGvrA=.f387fde1-a375-40ce-9fb8-07b4d85ea382@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <yFXftYoFtKgGt5JSZwvzVB6odANQ1gmkOL6uJhaGvrA=.f387fde1-a375-40ce-9fb8-07b4d85ea382@github.com>
Message-ID: <SRSdQvnp7S2nO2NDM7TpV53K_xSHFFd2-rJPMiAZqxQ=.4be5ced4-71ba-4564-b155-475efd05794a@github.com>

On Mon, 10 Feb 2025 21:50:26 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update copyright year.

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp line 2:

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

Suggestion:

 * Copyright (c) 2016, 2025, Oracle and/or its affiliates. All rights reserved.

A comma after 2025 is required.

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2609078478
PR Review Comment: https://git.openjdk.org/jdk/pull/23470#discussion_r1951043779

From rmarchenko at openjdk.org  Tue Feb 11 16:19:15 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 11 Feb 2025 16:19:15 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <y_m13jBR4ae7HLFkkZhNSbTyOjvsLMd-dUPJ4itr-Ts=.88e18813-2990-418f-84c3-645d3fd7ca5d@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <yVk7fclScB_b7XLjEjPVI241HeNqq8dsNiaqWmOAaPg=.bad85dc6-2323-4e39-b274-c22c85e24b63@github.com>
 <y_m13jBR4ae7HLFkkZhNSbTyOjvsLMd-dUPJ4itr-Ts=.88e18813-2990-418f-84c3-645d3fd7ca5d@github.com>
Message-ID: <0V_yYMkPnEGI5ZubqNBqaRgHEjIpQNhc--0XbRcowU8=.ca9ff1c9-cc2c-4718-8581-93043b33e7ce@github.com>

On Tue, 11 Feb 2025 03:25:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I'm concerning why I can't find a check in this PR which builds and tests the change. Should I trigger it somehow, or is it just invisible for me?

Oh, I acidentally switched to "Try the new merge experience" by GitHub. It doesn't show the checks in PRs. I'm able to see them again after I switched back.

@mrserb 

> you can change the code that uses the result of `MethodInfo.get()` in `PropertyInfo.get()` or `PropertyInfo.initialize()` where we created the property to pick the correct default/non-default method.
>...
> Or, most likely, you can skip adding the default method in MethodInfo.get() if non-default methods are already added.

As I commented in JDK-8347826, I think the issue surely can be fixed in different ways. Currently, all methods are put into a list, are sorted, and then methods with the same signature are filtered out in `Introspector.addMethod()` basing on the order. The change I suggested fixes the method order to make `Introspector.addMethod()` working properly. It could be filtered out in `MethodInfo.get()`, however it requires iterating through sub-classes or/and through the entries already added, what doesn't look easy before sorting, and looks redundant as this is already done in `Introspector.addMethod()`. By introducing this kind of processing somewhere else, we duplicate `Introspector.addMethod()` logic. Futhermore, the issue cannot be addressed in `PropertyInfo` because it `Introspector.addMethod()` filters these methods out, so they are already removed from the method list at the time of `PropertyInfo.get()` call.

Additionally, you're focusing on property decriptor list only. The issue occurs for both property descriptor list and method descriptor list. My proposal fixes both.


> the method you updated was added to make the method list stable

>From my point of view, the method list wasn't actually stable (after JDK-8071693), because it didn't take into account if a method is default or not, so `default` is located in the aorted list depending on a name of a returned type, what causes a wrong method list processing in `Introspector.addMethod()`, and exactly what I'm trying to fix here.


> Also please check the next example:
> ...
> Is the next output expected()?
> `public default void Test$A.setFoo(java.lang.Integer)`

It looks OK, it was properly chosen by `PropertyInfo` logic, or am I wrong? If it's OK, I will add it to the test cases.
  

> I also would like to discuss the next small example.
> Is `public default java.lang.Object Parent3.getValue()` really supposed to be the writer for the "value" property, that looks suspicious? 
> Shouldn't the correct output be:
> `>> public ????? java.lang.Runnable Parent3.getValue()`
> or
> `>>null`

As far as I see, `Parent3` actually has 2 methods falling into `com.sun.beans.introspect.MethodInfo.get()`:

 - `java.beans.MethodDescriptor[name=getValue; method=public abstract java.lang.Runnable Parent3.getValueX()] isSynthetic()=false`
 - `java.beans.MethodDescriptor[name=getValue; method=public default java.lang.Object Parent3.getValueX()] isSynthetic()=true`

While processing the `Parent3` class (in case we call `Introspector.getBeanInfo(Parent3.class)`), the default synthetic method is filtered out in `java.beans.Introspector.addMethod()` as synthetic. While processing the derived `Child`, it takes the default method regardless if it's synthetic or not, as JDK-8071693 implemented. However I'm not sure if the synthetic `default java.lang.Object Parent3.getValueX()` method should exist at all in the list. I think this issue is out of scope of this PR, and doesn't relate to the proposed fix, so I'd suggest to process it separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2651305697

From aivanov at openjdk.org  Tue Feb 11 16:22:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Feb 2025 16:22:56 GMT
Subject: RFR: 8294155: Exception thrown before awaitAndCheck hangs
 PassFailJFrame
Message-ID: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>

If a manual test throws an exception during construction of `PassFailJFrame`, the test execution hangs. When the builder pattern is used, no UI appears on the screens, but the Java process does not terminate automatically because there are windows which prevent AWT from shutting down.

**Fix:**

Catch exceptions in `PassFailJFrame.Builder.build()` and dispose of all the windows if an exception occurs.

This ensures all the created windows are disposed of, which lets AWT shut down cleanly.

_Note:_ the above problem doesn't occur when the test is run with `jtreg` because jtreg shuts down the JVM as soon as the main thread exits.

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

Commit messages:
 - 8294155: Exception thrown before awaitAndCheck hangs PassFailJFrame

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

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

From aivanov at openjdk.org  Tue Feb 11 17:19:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Feb 2025 17:19:12 GMT
Subject: RFR: 8347019: Test
 javax/swing/JRadioButton/8033699/bug8033699.java  still fails:  Focus is not
 on Radio Button Single as Expected
In-Reply-To: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
References: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
Message-ID: <Zb6swW60JbDaSo3XSMP6WCmZKQYuzI8nxZK8kULCgx8=.40a9120a-3f8e-4e6e-a2a2-f00c202a3ebc@github.com>

On Tue, 11 Feb 2025 04:15:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in ubuntu 22.04 system..It seems removing setAutoDelay is making the test more stable in such systems.
> Tested in all platforms where it is still ok without auto delay. CI job link in JBS..

Looks good.

I assume the test remains stable other platforms.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23554#pullrequestreview-2609456798

From aivanov at openjdk.org  Tue Feb 11 17:26:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Feb 2025 17:26:58 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v3]
In-Reply-To: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
Message-ID: <dCMxM_K-lLHyDnR4YXFoe-gRoJVDJh-wOaEXtf-8054=.fc348fa3-1ad4-4381-81b9-b45d63338279@github.com>

> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows.
> 
> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely.
> 
> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails.
> 
> The updated test passes in the CI.

Alexey Ivanov 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 four additional commits since the last revision:

 - Merge master
 - Update the test summary
 - Remove the redundant button
 - 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23336/files
  - new: https://git.openjdk.org/jdk/pull/23336/files/0349f37a..a03f66df

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

  Stats: 31639 lines in 929 files changed: 14138 ins; 10937 del; 6564 mod
  Patch: https://git.openjdk.org/jdk/pull/23336.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23336/head:pull/23336

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

From azvegint at openjdk.org  Tue Feb 11 17:34:16 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 11 Feb 2025 17:34:16 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <F_fInN-6KG3tplPYNlDetakDVJM3HVZOoC-dExPUfSA=.2a0edd66-5296-4cfd-9d78-442d68592e40@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
 <F_fInN-6KG3tplPYNlDetakDVJM3HVZOoC-dExPUfSA=.2a0edd66-5296-4cfd-9d78-442d68592e40@github.com>
Message-ID: <fw0kNOr7ImKtRFcrWpWeBNqrTrlT2qfZ-R8pvJNTDVw=.4f283ade-bf17-4c8b-87b5-a4a24ed5ac69@github.com>

On Tue, 11 Feb 2025 01:07:33 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> One thing that I noticed and wanted discuss further: This is when I delete the screencast-tokens.properties file and the permission is granted for the first screen share (new token generated), it asks for permission every time for subsequent screen share and I see multiple screencast tokens in the .properties file instead of one. IIRC the token setup is one time and the subsequent requests are there after allowed or am I missing a step while setting up new token?
> 
> Note: This is not related to the upgrade (happens even without the fix)

I checked on Ubuntu 22.04/24.04/24.10 and could not reproduce it. So please send me more details(config/logs) about this.

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

PR Comment: https://git.openjdk.org/jdk/pull/23426#issuecomment-2651545414

From serb at openjdk.org  Tue Feb 11 17:39:10 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 17:39:10 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <QpmSc-RstY8eolYFmedAS-pzRuV6g_1L6scUkdn6bSY=.f609c472-8582-44f2-b36d-2cf23ada3041@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

> > Or, most likely, you can skip adding the default method in MethodInfo.get() if non-default methods are already added.
> 
> As I commented in JDK-8347826, I think the issue surely can be fixed in different ways. Currently, all methods are put into a list, are sorted, and then methods with the same signature are filtered out in `Introspector.addMethod()` basing on the 

> From my point of view, the method list wasn't actually stable (after JDK-8071693), because it didn't take into account if a method is default or not, so `default` is located in the aorted list depending on a name of a returned type, what causes a wrong method list processing in `Introspector.addMethod()`, and exactly what I'm trying to fix here.

But the current sorting is good enouth to reproduced the bugs similar to the current one.

> > Is the next output expected()?
> > `public default void Test$A.setFoo(java.lang.Integer)`
> 
> It looks OK, it was properly chosen by `PropertyInfo` logic, or am I wrong? If it's OK, I will add it to the test cases.

Then why the property is based on the implemented interface? For classes the method from the current class will be selected.
`public default void Test$A.setFoo(java.lang.Integer)` vs `public void Test$DC.setFoo(java.lang.Number)`

> As far as I see, `Parent3` actually has 2 methods falling into `com.sun.beans.introspect.MethodInfo.get()`:
> 
>     * `java.beans.MethodDescriptor[name=getValue; method=public abstract java.lang.Runnable Parent3.getValueX()] isSynthetic()=false`
> 
>     * `java.beans.MethodDescriptor[name=getValue; method=public default java.lang.Object Parent3.getValueX()] isSynthetic()=true`
> 
> 
> While processing the `Parent3` class (in case we call `Introspector.getBeanInfo(Parent3.class)`), the default synthetic method is filtered out in `java.beans.Introspector.addMethod()` as synthetic. While processing the derived `Child`, it takes the default method regardless if it's synthetic or not, as JDK-8071693 implemented. However I'm not sure if the synthetic `default java.lang.Object Parent3.getValueX()` method should exist at all in the list. I think this issue is out of scope of this PR, and doesn't relate to the proposed fix, so I'd suggest to process it separately.


But it is not filtered out for Child class:

import java.beans.*;
import java.lang.reflect.Method;
import java.util.Arrays;

interface Parent1<T> {
    T getValue();
}

interface Parent2 {
    Runnable getValue();
}

interface Parent3 extends Parent2, Parent1<Object> {
    Runnable getValue();
}

abstract class Child implements Parent3 {
    public void setValue(Runnable value) {
    }
}

public class BeansMainInt {
    public static void main(String[] args) throws Exception {
        BeanInfo beanInfo = Introspector.getBeanInfo(Child.class);
        for (MethodDescriptor methodDescriptor : beanInfo.getMethodDescriptors()) {
            System.out.println("methodDescriptor = " + methodDescriptor);
        }
        for (PropertyDescriptor pd : beanInfo.getPropertyDescriptors()) {
            Method writeMethod = pd.getWriteMethod();
            Method readMethod = pd.getReadMethod();
            System.out.println(pd.getName()+ ":\n ** " + pd.getPropertyType()
                    + "\n >> " + readMethod + "\n << " + writeMethod);
        }
    }
}

There is only one variant of getValue in the output(so both "property descriptor" and "method descriptor" are wrong):
`methodDescriptor = java.beans.MethodDescriptor[name=getValue; method=public default java.lang.Object Parent3.getValue()]
`
Or am I missing something?

It is related to this issue as it is part of 8071693, it seems it is not enouth to just add the list of default methods in the MethodInfo. you also need to "merge" different varants of the same method, select the correct one and filter out others.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2651557788

From aivanov at openjdk.org  Tue Feb 11 17:55:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 11 Feb 2025 17:55:11 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v3]
In-Reply-To: <ICiPA3XCj1Stj6pVeft_Z1mpOQROo2slFyk7x-w4bvY=.6eed32a4-fc4e-46a2-b443-1865d6ebc7ce@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <s6wAL7uQQd4ARvjj6uqKBcq0hZUb1se1CFdq0yUKs_s=.ef99abfb-4fb3-4815-a552-3aaacf90147d@github.com>
 <2Ur6_ymOMG_ItEYncKnpkPPd0TuAM3Cr93dQM9XAmMA=.c04a9ee1-ad2b-45b3-88b0-0ddaee66ea1f@github.com>
 <ICiPA3XCj1Stj6pVeft_Z1mpOQROo2slFyk7x-w4bvY=.6eed32a4-fc4e-46a2-b443-1865d6ebc7ce@github.com>
Message-ID: <tegetP2j3TaS1xIbWi_gpJof0qeer9hI-vEHKAv7NjM=.7454dc32-97d6-4672-95d8-e583fb4c5fcc@github.com>

On Tue, 11 Feb 2025 02:51:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Even for classic windows?

I guess the test is applicable to the classic Windows theme, yet [JDK-4796987](https://bugs.openjdk.org/browse/JDK-4796987) states, <q cite="https://bugs.openjdk.org/browse/JDK-4796987#descriptionmodule-label">This problem does not occur if desktop themes descending from the classic (Windows 2000) look are used.</q>

I'm quite reluctant about adding another case to the test.

Let me know if you think it's necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1951321428

From rmahajan at openjdk.org  Tue Feb 11 18:23:01 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Tue, 11 Feb 2025 18:23:01 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v3]
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <lRrl5t3cygUR_gq9aAC6Bf8g_4pKMMWTRmIyAeEwLw4=.fc971a52-2ccd-4573-abd1-9ed91364b16e@github.com>

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23470/files
  - new: https://git.openjdk.org/jdk/pull/23470/files/66f0a452..9db93f54

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

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

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

From serb at openjdk.org  Tue Feb 11 19:01:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 19:01:21 GMT
Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows
 XP is unavailable [v3]
In-Reply-To: <dCMxM_K-lLHyDnR4YXFoe-gRoJVDJh-wOaEXtf-8054=.fc348fa3-1ad4-4381-81b9-b45d63338279@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
 <dCMxM_K-lLHyDnR4YXFoe-gRoJVDJh-wOaEXtf-8054=.fc348fa3-1ad4-4381-81b9-b45d63338279@github.com>
Message-ID: <b5Zqj8-voighWiky5YtstN4Df_sygF2l6kjylFb7IFw=.fe789a38-61d2-48e7-b4a8-4d385b2c2135@github.com>

On Tue, 11 Feb 2025 17:26:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows.
>> 
>> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely.
>> 
>> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails.
>> 
>> The updated test passes in the CI.
>
> Alexey Ivanov 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 four additional commits since the last revision:
> 
>  - Merge master
>  - Update the test summary
>  - Remove the redundant button
>  - 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23336#pullrequestreview-2609736397

From serb at openjdk.org  Tue Feb 11 19:05:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 11 Feb 2025 19:05:20 GMT
Subject: RFR: 8294155: Exception thrown before awaitAndCheck hangs
 PassFailJFrame
In-Reply-To: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
References: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
Message-ID: <yguhtW3RsfayMxXTUWI77_S3x_lj99kolDEXPULKVhQ=.ee1d56ad-6709-4388-9171-e26ffa0ed0e0@github.com>

On Tue, 11 Feb 2025 16:17:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If a manual test throws an exception during construction of `PassFailJFrame`, the test execution hangs. When the builder pattern is used, no UI appears on the screens, but the Java process does not terminate automatically because there are windows which prevent AWT from shutting down.
> 
> **Fix:**
> 
> Catch exceptions in `PassFailJFrame.Builder.build()` and dispose of all the windows if an exception occurs.
> 
> This ensures all the created windows are disposed of, which lets AWT shut down cleanly.
> 
> _Note:_ the above problem doesn't occur when the test is run with `jtreg` because jtreg shuts down the JVM as soon as the main thread exits.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23564#pullrequestreview-2609757809

From dnguyen at openjdk.org  Tue Feb 11 19:16:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Feb 2025 19:16:36 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v3]
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <wwyUyZFV-5p6OPXpKCw9qhfY_BTQDzIgLXNOXZ_3ztY=.3b427d9a-e577-415d-8d5c-cd296be1a844@github.com>

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - Change fix to use isShowing. Update test to auto.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23451/files
  - new: https://git.openjdk.org/jdk/pull/23451/files/a7856b88..5e4f3124

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

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

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

From dnguyen at openjdk.org  Tue Feb 11 19:16:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Feb 2025 19:16:36 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v3]
In-Reply-To: <oTIP5COO9ALrpDyKjdU48p7izMn_QemI5UXjEKTGumo=.675f15b6-5244-4654-976b-3b445a98329b@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <oTIP5COO9ALrpDyKjdU48p7izMn_QemI5UXjEKTGumo=.675f15b6-5244-4654-976b-3b445a98329b@github.com>
Message-ID: <cjceAWD-4G1pKD6RtJ2EtSoa4oe6N_NFBGcjqi0wB8I=.7fd5aa65-286b-4a35-a216-d5a2af79ddb8@github.com>

On Mon, 10 Feb 2025 21:52:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Change fix to use isShowing. Update test to auto.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1620:
> 
>> 1618:             do {
>> 1619:                 // If application isn't in focus, stop the timer
>> 1620:                 if (focusOwner == null) {
> 
> if (!scrollbar.isShowing()) {
>           ((Timer)e.getSource()).stop();
>           buttonListener.handledEvent = false;
>           scrollbar.setValueIsAdjusting(false);
>           return;
>       }
> 
> 
> I haven't tested this solution well, but you can try to stop the timer when the scrollbar is not showing(before entering the `do` loop)

Tested this solution locally and in CI. Seems to work well. Clientlibs passes and the updated, automatic test also passes on all related platforms. Updated the PR. Thanks for providing the automated test and suggested change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1951447974

From dnguyen at openjdk.org  Tue Feb 11 19:16:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Feb 2025 19:16:36 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v3]
In-Reply-To: <S_ph7vtuEi9JvMue6rsE0NLrIVq9HsAStDXL3X3KODM=.52bca7e3-b1f5-485e-b06c-658ee1180586@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <1fjzUR1RxWAEpbja0uaJmAeSZgln-UQsZ4ESiBUL7Gc=.8e307676-4331-4336-bf37-8968b7db3ed2@github.com>
 <Bl_10if9N9POKQAp0xJ-qHJFSgrV76cUU0G76DV0-XE=.bff59cae-88bf-4fd0-9d52-b6c49ed0b593@github.com>
 <Eu0XxQ_F8x4ZMF7t0Qozg8q8MOZEHrwNbhTFH0zPmvY=.179cd061-bd3f-4552-b1d1-946c24759b37@github.com>
 <ixG11q2tDAjejiEu7xOATivRqRjMujprpTU9zlU9eoQ=.02c08853-6931-4914-8821-31842a28bfad@github.com>
 <S_ph7vtuEi9JvMue6rsE0NLrIVq9HsAStDXL3X3KODM=.52bca7e3-b1f5-485e-b06c-658ee1180586@github.com>
Message-ID: <SGcpmmc8k-2Q_rOsvPkah7hgTJvNNnFsAXSDADpxHpE=.5484a508-010f-4ef9-a34d-efb39cc4293d@github.com>

On Sat, 8 Feb 2025 01:04:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> I was thinking more of `if (!par.isEnabled() !! focusOwner == null)` as the parent is still JFrame.
>> 
>> But, I was trying to run the testcase mentioned in the JBS and this regression test but I am not able to reproduce without the fix..
>> It doesn't keep on scrolling when it regains focus in my windows 11 machine..
>
> @prsadhuk  I wasn't able to replicate the issue first few times. When I changed the no. of combobox items to 1000, the issue was reproducible. 
> 
> I think the issue with 100 combobox items is that the end of combobox is reached quickly while trying to ALT +TAB at the same time and it becomes difficult to replicate the issue unless it is done quickly.
> 
> @DamonGuy Maybe it is good to increase the no. of combobox items to reproduce the issue more consistently.

I did update the test to use 1000 items instead. However, the automated test that Alexander provided seems to work well with 100 as well. I see no issues in testing with 100, so I left it at 100 again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1951450446

From honkar at openjdk.org  Tue Feb 11 20:26:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Feb 2025 20:26:11 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <kwZOkYS-2xkZYVVGhKwwaTOjeG-tROXU3LhikLf1gjI=.33c2d50e-0e17-4cad-8059-786694d58e23@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

SplashScreen tests work as expected on all platforms. No regressions observed.

With optimization=SIZE, libsplashscreen image file sizes are less on linux and macOS.
On the contrary, the .dll files on Windows were slightly bigger with opt=SIZE than with opt=LOW for me (Win 11 x86-64).  Details below.


macOS
--------
408K Feb 10 14:59 libsplashscreen.dylib
96B Feb 10 15:00 libsplashscreen.dylib.dSYM

344K Feb 11 10:38 libsplashscreen.dylib
96B Feb 11 10:39 libsplashscreen.dylib.dSYM

Linux
-----
1.7M Feb 10 16:39 libsplashscreen.debuginfo
364K Feb 10 16:39 libsplashscreen.so

1.4M Feb 11 10:58 libsplashscreen.debuginfo
293K Feb 11 10:58 libsplashscreen.so

Windows
----------
201K Feb  7 15:37 splashscreen.dll
177K Feb  7 15:37 splashscreen.dll.map
1.6M Feb  7 15:37 splashscreen.dll.pdb

547K Feb 11 11:31 splashscreen.dll
281K Feb 11 11:31 splashscreen.dll.map
1.7M Feb 11 11:31 splashscreen.dll.pdb

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

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2609945290

From dnguyen at openjdk.org  Tue Feb 11 20:50:12 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Feb 2025 20:50:12 GMT
Subject: RFR: 8347019: Test
 javax/swing/JRadioButton/8033699/bug8033699.java  still fails:  Focus is not
 on Radio Button Single as Expected
In-Reply-To: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
References: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
Message-ID: <RPf-uac1ODMHoXPiN1DmwKtWegF5SSlXL_QNu574_LE=.068c0915-a124-4f34-9d2e-a7c06f7e68b7@github.com>

On Tue, 11 Feb 2025 04:15:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in ubuntu 22.04 system..It seems removing setAutoDelay is making the test more stable in such systems.
> Tested in all platforms where it is still ok without auto delay. CI job link in JBS..

Tested locally on mac and windows as well. Test still works as expected. Change looks good.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23554#pullrequestreview-2610006892

From kizune at openjdk.org  Tue Feb 11 21:46:16 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 11 Feb 2025 21:46:16 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v2]
In-Reply-To: <k6TZ0TTd-CQnoB-7SvXWh701Hf_hzScujtVnOSKLSZU=.44ec1d04-559a-4112-8aaa-d363e445fad7@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <k6TZ0TTd-CQnoB-7SvXWh701Hf_hzScujtVnOSKLSZU=.44ec1d04-559a-4112-8aaa-d363e445fad7@github.com>
Message-ID: <HIh1yBXCEP78AQ4PI7Q2c3UefZlzJGPOv6vowBSbSXY=.a80b8824-f829-4bb9-bdab-96d3ef50ce1c@github.com>

On Fri, 7 Feb 2025 08:24:54 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
>> 
>> **Reason of the bug**:  
>> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
>> 
>> **Fix description**: 
>> make the size of the execCmd array dependent on the number of options.
>> 
>> **Test**: 
>> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace regexp s+ with space

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 1641:

> 1639:                 execCmd[n++] = "-o job-sheets=standard";
> 1640:             }
> 1641:             if (optionArgs != null) {

I see this block is the same in both branches of the if condition. Can we just move it outside the condition to keep it simpler?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1951651839

From azvegint at openjdk.org  Tue Feb 11 21:48:10 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 11 Feb 2025 21:48:10 GMT
Subject: RFR: 8294155: Exception thrown before awaitAndCheck hangs
 PassFailJFrame
In-Reply-To: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
References: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
Message-ID: <301l_ASB1B52dWrhiFzAQ3CEuIga6Vd5Qoo-cSXrEmg=.bf63d414-96a9-4eac-9978-9ea597662768@github.com>

On Tue, 11 Feb 2025 16:17:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If a manual test throws an exception during construction of `PassFailJFrame`, the test execution hangs. When the builder pattern is used, no UI appears on the screens, but the Java process does not terminate automatically because there are windows which prevent AWT from shutting down.
> 
> **Fix:**
> 
> Catch exceptions in `PassFailJFrame.Builder.build()` and dispose of all the windows if an exception occurs.
> 
> This ensures all the created windows are disposed of, which lets AWT shut down cleanly.
> 
> _Note:_ the above problem doesn't occur when the test is run with `jtreg` because jtreg shuts down the JVM as soon as the main thread exits.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23564#pullrequestreview-2610124795

From honkar at openjdk.org  Tue Feb 11 22:16:16 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 11 Feb 2025 22:16:16 GMT
Subject: RFR: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
Message-ID: <-oNnjEnRe5gm8zhuz4tAY-PpATw5hLkB8fOp0sL3_Qg=.5285921a-b598-4a97-a6b0-f232983a0ce7@github.com>

On Mon, 3 Feb 2025 18:50:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset updates the pipewire headers to the latest available version.
> It contains the minimum set of required header files needed to build the JDK.
> 
> The updated headers are a direct copy from the 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
>  
> Testing looks good.

> I checked on Ubuntu 22.04/24.04/24.10 and could not reproduce it. So please send me more details(config/logs) about this.

Unable to the replicate token issue now. It was probably due to stale token file. 
Other than that the upgrade looks good.

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23426#pullrequestreview-2610173194

From jiangli at openjdk.org  Wed Feb 12 00:07:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 00:07:24 GMT
Subject: RFR: 8349859: Support static JDK in libfontmanager/freetypeScaler.c
Message-ID: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>

Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 

According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.

I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

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

Commit messages:
 - Check if FT_Property_Set can be found from the executable if running on static JDK, before trying to load libfreetype.so.

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

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

From azvegint at openjdk.org  Wed Feb 12 00:38:14 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 12 Feb 2025 00:38:14 GMT
Subject: RFR: 8347019: Test
 javax/swing/JRadioButton/8033699/bug8033699.java  still fails:  Focus is not
 on Radio Button Single as Expected
In-Reply-To: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
References: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
Message-ID: <1LWgqdRnOsWedm7E40gKdQKPtDTTFZ2G8i773TCSkCI=.9e66be34-78d2-41e6-977e-cf45be37d401@github.com>

On Tue, 11 Feb 2025 04:15:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in ubuntu 22.04 system..It seems removing setAutoDelay is making the test more stable in such systems.
> Tested in all platforms where it is still ok without auto delay. CI job link in JBS..

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23554#pullrequestreview-2610477907

From psadhukhan at openjdk.org  Wed Feb 12 03:10:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Feb 2025 03:10:19 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <nQoe_O7wLmnqTvLR6kF5fxLMe_EqnusO8LbA0uXAITA=.9e797e03-fbd5-4512-b4a7-5d68183f2c94@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
 <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>
 <NbdvRYDyFGaYKtE2wtBJD_sWFz5dlTuHSv-iSHnpT60=.abb2997d-8c89-485d-90b5-594d914e3541@github.com>
 <4bdkDW7dmnQj6PYp8owb8Bucp9s-MVsYbWJPKX1JM84=.0a5cfea0-eb01-4694-9ce9-37a7e52dc6e3@github.com>
 <nQoe_O7wLmnqTvLR6kF5fxLMe_EqnusO8LbA0uXAITA=.9e797e03-fbd5-4512-b4a7-5d68183f2c94@github.com>
Message-ID: <8li8njF_3fsUMKO8z6CZV4YlZVxACKioP-zfAid1zxA=.206ab7fa-9d85-432f-adec-868dfb06777d@github.com>

On Tue, 11 Feb 2025 14:59:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It is just checking for current L&F is Windows or not..I am not even checking for "instanceof WIndowsLookAndFeel" which will not be present in linux and mac so I dont think it will create any problem..
>> Helper method will create unnecessary changes in all L&F..I dont think I will like to do that..
>
> It just feels wrong? A superclass doesn't need to know, shouldn't know, about its subclasses.
> 
> Yet this solution could be the simplest one? if achieving the same effect different makes the code too complicated.

Where it is checking for subclasses? It is just checking for if the current lookandfeel is Windows L&F (as I told it is not checking for `instanceof WindowsLookAndFeel` in which case one could have argued that it is trying to know about windows subclass..

Also, having helper method will have effect in only Windows subclass and noop in others and that is unnecessary in my opinion and on top of that, it will need a CSR for that method and that method would be additional maintenance headache and it will prevent backporting this fix if one wants to and considering this is related to JCK issue, people would like it to be backported..

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

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

From psadhukhan at openjdk.org  Wed Feb 12 03:10:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Feb 2025 03:10:19 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
In-Reply-To: <K8rmJpvvxJA6--UBb5vNd-iQ2CcHmHmxtYbQuSj6y-M=.d1b6e2f9-c08b-4d84-b028-37756d181a8e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
 <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>
 <nHKrseB4YhnpLc2xLVMXRHFcZwA3WVDgRPA2JRutcoI=.b1a77194-de05-4f6a-88e0-07fa7a231d49@github.com>
 <K8rmJpvvxJA6--UBb5vNd-iQ2CcHmHmxtYbQuSj6y-M=.d1b6e2f9-c08b-4d84-b028-37756d181a8e@github.com>
Message-ID: <rSRl3GX0RpPVlEgHfWNixHo63UtQrt9Xd4WSZzgXqOY=.9952bb2d-9b81-4a2a-86d8-645b5fe65844@github.com>

On Tue, 11 Feb 2025 14:57:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This will preserve existing windows 10 behavior and at the same time, it will show Windows 11 File explorer behavior.
>> What is the need to show the same way for WIndows 10 and 11 when it will not be same as what native does for windows 10.
>> 
>> I am sorry but I dont agree to this...
>
> Because, as you say, support for Windows 10 ends in October this year.
> 
> For this reason, I'd rather avoid the complexity of supporting different look for Windows 10 and 11.
> 
> I won't object to this if you think it's important to support Windows 10 look.

Ending support shouldn't mean we should make Windows 10 design look like Windows 11, that would be so wrong, in my opinion..because the user would like to get the same look and feel as in native Windows 10 as much as possible..

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

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

From psadhukhan at openjdk.org  Wed Feb 12 03:13:15 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 12 Feb 2025 03:13:15 GMT
Subject: Integrated: 8347019: Test
 javax/swing/JRadioButton/8033699/bug8033699.java  still fails:  Focus is not
 on Radio Button Single as Expected
In-Reply-To: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
References: <nLphRyuqP7zcc6R9PdnQa4FeFwCVSCjwNHyhzivs8n4=.fae0c7bb-bb76-46ae-a0dd-7b9f1e4f6172@github.com>
Message-ID: <PGAyC8CKUiFd_R9cpLG8xx4DAi3zERfD4GlZqAR8foo=.506af910-4cf1-4e69-b060-5dceaf6e1574@github.com>

On Tue, 11 Feb 2025 04:15:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test seems to fail in ubuntu 22.04 system..It seems removing setAutoDelay is making the test more stable in such systems.
> Tested in all platforms where it is still ok without auto delay. CI job link in JBS..

This pull request has now been integrated.

Changeset: 342dec93
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/342dec93f22193309aa8865df95eb19d659b082c
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8347019: Test javax/swing/JRadioButton/8033699/bug8033699.java  still fails:  Focus is not on Radio Button Single as Expected

Reviewed-by: aivanov, dnguyen, azvegint

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

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

From prr at openjdk.org  Wed Feb 12 05:10:10 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Feb 2025 05:10:10 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <3v37P515MhzfAMUB1O0gsP5OPAeVdmy_wKDMj57txFk=.d37c7f07-d0f0-4e16-b255-0e43919a9bb7@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

Marked as reviewed by prr (Reviewer).

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 303:

> 301: #else
> 302: 
> 303:     if (JVM_IsStaticallyLinked()) {

These kinds of checks on behalf of a statically linked build are quite intrusive.
Perhaps there is no alternative, but still.
SFAIK, at this time, no one is under any obligation to test this works, or to know how not to break it.
So I will approve with those caveats.

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

PR Review: https://git.openjdk.org/jdk/pull/23574#pullrequestreview-2610823880
PR Review Comment: https://git.openjdk.org/jdk/pull/23574#discussion_r1951984223

From rmarchenko at openjdk.org  Wed Feb 12 07:20:10 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 12 Feb 2025 07:20:10 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <QpmSc-RstY8eolYFmedAS-pzRuV6g_1L6scUkdn6bSY=.f609c472-8582-44f2-b36d-2cf23ada3041@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <QpmSc-RstY8eolYFmedAS-pzRuV6g_1L6scUkdn6bSY=.f609c472-8582-44f2-b36d-2cf23ada3041@github.com>
Message-ID: <KIaign6T5m5TnM34qXxIHIiUSSA3GMKS-6pRUTOMIyE=.1c1cf51d-36d9-4c4b-b74e-6916df1ffa35@github.com>

On Tue, 11 Feb 2025 17:36:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > Is the next output expected()?
> > > `public default void Test$A.setFoo(java.lang.Integer)`
> > 
> > 
> > It looks OK, it was properly chosen by `PropertyInfo` logic, or am I wrong? If it's OK, I will add it to the test cases.
> 
> Then why the property is based on the implemented interface? For classes the method from the current class will be selected. `public default void Test$A.setFoo(java.lang.Integer)` vs `public void Test$DC.setFoo(java.lang.Number)`

I'd like to clarify this case first.

OK, we have the test:

import java.beans.IntrospectionException;

public class Test {

    public interface A {
        default void setFoo(Integer num) {
            System.out.println(Thread.currentThread().getStackTrace()[1]);
        }
    }

    public class D implements A {
        public void setFoo(Number num) {
            System.out.println(Thread.currentThread().getStackTrace()[1]);
        }
    }

    private void run() {
        var d = new D();
        d.setFoo(null);
    }

    public static void main(String[] args) throws java.beans.IntrospectionException {
        test(D.class);
        System.out.println("--- run");
        (new Test()).run();
    }

    private static void test(Class beanClass) throws IntrospectionException {
        System.out.println("\nbeanClass = " + beanClass);
        var info = java.beans.Introspector.getBeanInfo(beanClass, Object.class);
        System.out.println(info.getBeanDescriptor());
        System.out.println("--- properties");
        for (var desc : info.getPropertyDescriptors()) {
            System.out.println(desc.getReadMethod());
            System.out.println(desc.getWriteMethod());
        }
        System.out.println("--- methods");
        for (var desc : info.getMethodDescriptors()) {
            System.out.println(desc.getMethod());
        }
    }
}

and the output is 

java.beans.BeanDescriptor[name=Test$D; beanClass=class Test$D]
--- properties
null
public default void Test$A.setFoo(java.lang.Integer)
--- methods
public void Test$D.setFoo(java.lang.Number)
public default void Test$A.setFoo(java.lang.Integer)
--- run
Test$A.setFoo(Test.java:7)


`Test$A.setFoo()` was chosen for `d.setFoo(null)` call. And this conforms to what we see in `--- properties` chapter.
Is this a correct behavior?

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2652851052

From rmarchenko at openjdk.org  Wed Feb 12 08:14:11 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 12 Feb 2025 08:14:11 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <QpmSc-RstY8eolYFmedAS-pzRuV6g_1L6scUkdn6bSY=.f609c472-8582-44f2-b36d-2cf23ada3041@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <QpmSc-RstY8eolYFmedAS-pzRuV6g_1L6scUkdn6bSY=.f609c472-8582-44f2-b36d-2cf23ada3041@github.com>
Message-ID: <u1olpl-nJgDr8_YHrEtHldZTzbh8zdlCupFO5riS6mk=.3f612b52-c785-4b0d-8b9c-aec0ac674d2f@github.com>

On Tue, 11 Feb 2025 17:36:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>>   
>>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>
>
>> > Or, most likely, you can skip adding the default method in MethodInfo.get() if non-default methods are already added.
>> 
>> As I commented in JDK-8347826, I think the issue surely can be fixed in different ways. Currently, all methods are put into a list, are sorted, and then methods with the same signature are filtered out in `Introspector.addMethod()` basing on the 
> 
>> From my point of view, the method list wasn't actually stable (after JDK-8071693), because it didn't take into account if a method is default or not, so `default` is located in the aorted list depending on a name of a returned type, what causes a wrong method list processing in `Introspector.addMethod()`, and exactly what I'm trying to fix here.
> 
> But the current sorting is good enouth to reproduced the bugs similar to the current one.
> 
>> > Is the next output expected()?
>> > `public default void Test$A.setFoo(java.lang.Integer)`
>> 
>> It looks OK, it was properly chosen by `PropertyInfo` logic, or am I wrong? If it's OK, I will add it to the test cases.
> 
> Then why the property is based on the implemented interface? For classes the method from the current class will be selected.
> `public default void Test$A.setFoo(java.lang.Integer)` vs `public void Test$DC.setFoo(java.lang.Number)`
> 
>> As far as I see, `Parent3` actually has 2 methods falling into `com.sun.beans.introspect.MethodInfo.get()`:
>> 
>>     * `java.beans.MethodDescriptor[name=getValue; method=public abstract java.lang.Runnable Parent3.getValueX()] isSynthetic()=false`
>> 
>>     * `java.beans.MethodDescriptor[name=getValue; method=public default java.lang.Object Parent3.getValueX()] isSynthetic()=true`
>> 
>> 
>> While processing the `Parent3` class (in case we call `Introspector.getBeanInfo(Parent3.class)`), the default synthetic method is filtered out in `java.beans.Introspector.addMethod()` as synthetic. While processing the derived `Child`, it takes the default method regardless if it's synthetic or not, as JDK-8071693 implemented. However I'm not sure if the synthetic `default java.lang.Object Parent3.getValueX()` method should exist at all in the list. I think this issue is out of scope of this PR, and doesn't relate to the proposed fix, so I'd suggest to process it separately.
> 
> 
> But it is not filtered out for Child class:
> 
> import java.beans.*;
> import java.lang.reflect.Method;
> import java.util.Arrays;
> 
> interface Parent1<T> {
>     T getValue();
> }
> 
> interface Parent2 {
>     Runnable getValue();
> }
> 
> interface Parent3 extends Parent2, Par...

@mrserb  Sorry, I updated my last comment above, so please take a look again, if you already read it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2652943753

From mbaesken at openjdk.org  Wed Feb 12 08:58:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 08:58:11 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <3bZCZUIM5Auo92RuCHxprMpVHHF7CMTo_5xnHpRJryk=.057c47da-d690-478e-9e63-0b0ded583b1d@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <oLbvcLRgiq7vvX2NveHk4V-_1mndE5p3b22lf-TYzwk=.22d277d5-a98f-4723-b092-0c2a828df360@github.com>
 <U3kvFWEo7vCxdgMGPfanApdZ5aVXSCFo2Bbglil2UUY=.fe6a286b-d927-4aaf-9bb6-bfa610faf7f1@github.com>
 <3bZCZUIM5Auo92RuCHxprMpVHHF7CMTo_5xnHpRJryk=.057c47da-d690-478e-9e63-0b0ded583b1d@github.com>
Message-ID: <Hr1Xf9dyrLak-GvqGpT6QKN4Nn-UC_F02tV4v_RowIU=.f0fa3277-f876-4528-8692-4fc72b2e375f@github.com>

On Fri, 7 Feb 2025 22:45:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> What tests have you run?
>> 
>> Had this in our internal test queue with jtreg / JCK  plus some additional SAP internal tests. No issues seen.
>> However I think I have to run some more manual tests on client  like  setups.
>> 
>> Unfortunately my Linux terminal server does not like the awt jtreg tests (with and without my patch) , so I have to find something else.
>
> @MBaesken 
> 
>> However I think I have to run some more manual tests on client like setups.
> 
> SplashScreen clientlib tests are located - test/jdk/java/awt/SplashScreen. Most of them are manual tests invoked by shell script and it is easier to run the whole test folder. I can run the tests on your behalf to check if the tests work fine with the fix. 
> 
> What are we specifically looking for in the tests with this fix?  No degradation in test startup and execution time?

@honkar-jdk do you have the latest/newest jdk head, especially this change is important 
8349214: Improve size optimization flags for MSVC builds
https://github.com/openjdk/jdk/commit/40603a5bf039eef03c157bfc49ac8ea2229a94de

Before the SIZE opt flags for MSVC were bad.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2653033507

From kizune at openjdk.org  Wed Feb 12 09:54:10 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 12 Feb 2025 09:54:10 GMT
Subject: RFR: 8294155: Exception thrown before awaitAndCheck hangs
 PassFailJFrame
In-Reply-To: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
References: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
Message-ID: <DQOegsskCA1BVYvR77tyEHhY3gV2ncvKc646djiXeUk=.86c081ee-783a-4947-969d-21b62f647cff@github.com>

On Tue, 11 Feb 2025 16:17:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If a manual test throws an exception during construction of `PassFailJFrame`, the test execution hangs. When the builder pattern is used, no UI appears on the screens, but the Java process does not terminate automatically because there are windows which prevent AWT from shutting down.
> 
> **Fix:**
> 
> Catch exceptions in `PassFailJFrame.Builder.build()` and dispose of all the windows if an exception occurs.
> 
> This ensures all the created windows are disposed of, which lets AWT shut down cleanly.
> 
> _Note:_ the above problem doesn't occur when the test is run with `jtreg` because jtreg shuts down the JVM as soon as the main thread exits.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23564#pullrequestreview-2611369216

From mbaesken at openjdk.org  Wed Feb 12 10:10:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Feb 2025 10:10:12 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v3]
In-Reply-To: <sySMzPKixDdMTOzWIjZJ5U-CAT1QPWb0fKeBFw30zRg=.3065ad24-0999-4828-82bb-418dd80af8ee@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
 <5Ou0SpG4cIgTUAx2L22VryWFwm6RYqJ5odO1lFPlvZw=.a56f642d-9265-4b94-91ed-f992d5f6bf60@github.com>
 <sySMzPKixDdMTOzWIjZJ5U-CAT1QPWb0fKeBFw30zRg=.3065ad24-0999-4828-82bb-418dd80af8ee@github.com>
Message-ID: <aPiBJAgV787dPm285Pr5z-bRU7JEfg8ep0R1A-lrpDk=.72f9def8-feb5-48fc-8003-116d5e403e51@github.com>

On Tue, 11 Feb 2025 11:42:26 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Yes, at first I kept it as it was in the original fix. But after revisiting it, I think that it is belongs in the new `spa/utils/endian.h` file.
> 
> @MBaesken could you please recheck if it still works for you?

This still works for me on AIX.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23543#discussion_r1952348416

From aivanov at openjdk.org  Wed Feb 12 14:35:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Feb 2025 14:35:15 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
In-Reply-To: <rSRl3GX0RpPVlEgHfWNixHo63UtQrt9Xd4WSZzgXqOY=.9952bb2d-9b81-4a2a-86d8-645b5fe65844@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
 <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>
 <nHKrseB4YhnpLc2xLVMXRHFcZwA3WVDgRPA2JRutcoI=.b1a77194-de05-4f6a-88e0-07fa7a231d49@github.com>
 <K8rmJpvvxJA6--UBb5vNd-iQ2CcHmHmxtYbQuSj6y-M=.d1b6e2f9-c08b-4d84-b028-37756d181a8e@github.com>
 <rSRl3GX0RpPVlEgHfWNixHo63UtQrt9Xd4WSZzgXqOY=.9952bb2d-9b81-4a2a-86d8-645b5fe65844@github.com>
Message-ID: <zD_Q28U7bxKm8HPcBsBDBAoRF9DYWiUW0AVrL08TdpE=.bc4b2966-907d-480a-91a8-da8c62eee1cd@github.com>

On Wed, 12 Feb 2025 03:06:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Ending support shouldn't mean we should make Windows 10 design look like Windows 11, that would be so wrong, in my opinion..because the user would like to get the same look and feel as in native Windows 10 as much as possible..

The thing is neither of us has found any app which displays both radio bullets or check-marks and an icon in its menus.

The problem with `.equals("Windows 11")` is that it'll need updating if and when Microsoft releases a newer version of Windows because Windows 12 will fallback to rendering like in Windows 10 and earlier versions.

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

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

From aivanov at openjdk.org  Wed Feb 12 14:39:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Feb 2025 14:39:14 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <8li8njF_3fsUMKO8z6CZV4YlZVxACKioP-zfAid1zxA=.206ab7fa-9d85-432f-adec-868dfb06777d@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
 <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>
 <NbdvRYDyFGaYKtE2wtBJD_sWFz5dlTuHSv-iSHnpT60=.abb2997d-8c89-485d-90b5-594d914e3541@github.com>
 <4bdkDW7dmnQj6PYp8owb8Bucp9s-MVsYbWJPKX1JM84=.0a5cfea0-eb01-4694-9ce9-37a7e52dc6e3@github.com>
 <nQoe_O7wLmnqTvLR6kF5fxLMe_EqnusO8LbA0uXAITA=.9e797e03-fbd5-4512-b4a7-5d68183f2c94@github.com>
 <8li8njF_3fsUMKO8z6CZV4YlZVxACKioP-zfAid1zxA=.206ab7fa-9d85-432f-adec-868dfb06777d@github.com>
Message-ID: <5J92bI0_QRFYtvZzLcE9diwN1c8IiC0VkEpjDebTLKk=.6cb0fba7-16a3-4dc9-ab66-1abf7cefa739@github.com>

On Wed, 12 Feb 2025 03:07:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It just feels wrong? A superclass doesn't need to know, shouldn't know, about its subclasses.
>> 
>> Yet this solution could be the simplest one? if achieving the same effect different makes the code too complicated.
>
> Where it is checking for subclasses? It is just checking for if the current lookandfeel is Windows L&F (as I told it is not checking for `instanceof WindowsLookAndFeel` in which case one could have argued that it is trying to know about windows subclass..
> 
> Also, having helper method will have effect in only Windows subclass and noop in others and that is unnecessary in my opinion and on top of that, it will need a CSR for that method and that method would be additional maintenance headache and it will prevent backporting this fix if one wants to and considering this is related to JCK issue, people would like it to be backported..

Windows Look-and-Feel is based on Basic L&F implementation???from this point of view, Basic L&F changes its layout to accommodate for customisations that are needed for another L&F that's descends from it.

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

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

From aivanov at openjdk.org  Wed Feb 12 15:52:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Feb 2025 15:52:14 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <skGVSM2e5A0RTsyuVvkYUA0BVGcdY5ycaO7io8_Ceh8=.0fea4521-1408-4721-8715-3da30e1fb32c@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
 <skGVSM2e5A0RTsyuVvkYUA0BVGcdY5ycaO7io8_Ceh8=.0fea4521-1408-4721-8715-3da30e1fb32c@github.com>
Message-ID: <J1VZtJz1sIxgsQKm5dNaXim16SLZHyLQyqsZVt7CQk0=.0baefb26-e3bf-4c0d-8a18-10c51d4bd29f@github.com>

On Fri, 7 Feb 2025 08:14:51 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>>> For consistency, it can be done. I need to check if it impacts on VO announcement.
>> 
>> It shouldn't impact the announcements. One button gets deselected, another one gets selected?
>> 
>> Yet now that I think about it more, we may want to skip announcing deselecting a button in the group when selection moves to another button.
>> 
>> What about the case where currently focused or unfocused selected button gets deselected programmatically? Is there an interactive way to deselect a radio button when it's the only button in its own group?
>> 
>> This *needs more testing*.
>
> @aivanov-jdk I think we should not change RadioButton's implementation as the announcement is not consistent. 
> Do you have any other suggestion ?

@kumarabhi006 Sorry the long delay.

I tested the behaviour of radio buttons and I can't see or hear any difference in announcements when the same condition, namely `!Objects.equals(newValue, oldValue)`, is used before calling `valueChanged(ptr)`.

I added a panel with three radio buttons to your test case. Initially all the buttons aren't selected. VoiceOver announces when I move to the first radio button. It also announces when I move between radio buttons with left and right arrows. Then when I press the <kbd>Space</kbd> key, the current radio button gets selected and this is announced by VoiceOver: selected, <the caption of the button>. When I move to another button with arrow keys, it doesn't get selected right away when VoiceOver is active, and VoiceOver announces that I moved to another button and that it's not selected. Pressing the <kbd>Space</kbd> key selects the currently active button.

What do you hear when testing such a scenario?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1952921829

From jiangli at openjdk.org  Wed Feb 12 16:32:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 16:32:15 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <3v37P515MhzfAMUB1O0gsP5OPAeVdmy_wKDMj57txFk=.d37c7f07-d0f0-4e16-b255-0e43919a9bb7@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <3v37P515MhzfAMUB1O0gsP5OPAeVdmy_wKDMj57txFk=.d37c7f07-d0f0-4e16-b255-0e43919a9bb7@github.com>
Message-ID: <3H_Mfd3MStwDvkvS6pFHUQnNy8iT5Cig_beneRBqdxo=.61c11b41-8b04-4b49-9552-84ee5f5aff71@github.com>

On Wed, 12 Feb 2025 05:07:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
>> 
>> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
>> 
>> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.
>
> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 303:
> 
>> 301: #else
>> 302: 
>> 303:     if (JVM_IsStaticallyLinked()) {
> 
> These kinds of checks on behalf of a statically linked build are quite intrusive.
> Perhaps there is no alternative, but still.
> SFAIK, at this time, no one is under any obligation to test this works, or to know how not to break it.
> So I will approve with those caveats.

Thanks for the review, @prrace!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23574#discussion_r1953012595

From jiangli at openjdk.org  Wed Feb 12 16:32:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 16:32:15 GMT
Subject: Integrated: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <vPBLLepfNl8SWstW0sisWsdyyuoAuc8EqjbWYj2uTgM=.d2d96b7f-f803-4162-8c5d-e7a19259dcf3@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

This pull request has now been integrated.

Changeset: 332d87cc
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd
Stats:     15 lines in 2 files changed: 15 ins; 0 del; 0 mod

8349859: Support static JDK in libfontmanager/freetypeScaler.c

Reviewed-by: prr

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

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

From aivanov at openjdk.org  Wed Feb 12 16:35:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Feb 2025 16:35:16 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <J1VZtJz1sIxgsQKm5dNaXim16SLZHyLQyqsZVt7CQk0=.0baefb26-e3bf-4c0d-8a18-10c51d4bd29f@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
 <skGVSM2e5A0RTsyuVvkYUA0BVGcdY5ycaO7io8_Ceh8=.0fea4521-1408-4721-8715-3da30e1fb32c@github.com>
 <J1VZtJz1sIxgsQKm5dNaXim16SLZHyLQyqsZVt7CQk0=.0baefb26-e3bf-4c0d-8a18-10c51d4bd29f@github.com>
Message-ID: <M3N2eQAUbh3_kxEgIzxYRHuzB8C8v5oNNqVn4dZhFVs=.ba2b1d06-2707-4fdd-88b2-e60f33839b4e@github.com>

On Wed, 12 Feb 2025 15:49:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk I think we should not change RadioButton's implementation as the announcement is not consistent. 
>> Do you have any other suggestion ?
>
> @kumarabhi006 Sorry the long delay.
> 
> I tested the behaviour of radio buttons and I can't see or hear any difference in announcements when the same condition, namely `!Objects.equals(newValue, oldValue)`, is used before calling `valueChanged(ptr)`.
> 
> I added a panel with three radio buttons to your test case. Initially all the buttons aren't selected. VoiceOver announces when I move to the first radio button. It also announces when I move between radio buttons with left and right arrows. Then when I press the <kbd>Space</kbd> key, the current radio button gets selected and this is announced by VoiceOver: selected, <the caption of the button>. When I move to another button with arrow keys, it doesn't get selected right away when VoiceOver is active, and VoiceOver announces that I moved to another button and that it's not selected. Pressing the <kbd>Space</kbd> key selects the currently active button.
> 
> What do you hear when testing such a scenario?

Tested with SwingSet2, and I can hear the difference in announcements.

It looks the difference comes from the focus events: when the old button loses focus, `valueChanged` isn't called currently, but if `Objects.equals` is used, `valueChanged` gets called twice.

Let's keep the current behaviour, it's more reliable even though it looks inconsistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1953019780

From abhiscxk at openjdk.org  Wed Feb 12 17:04:15 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 12 Feb 2025 17:04:15 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <M3N2eQAUbh3_kxEgIzxYRHuzB8C8v5oNNqVn4dZhFVs=.ba2b1d06-2707-4fdd-88b2-e60f33839b4e@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <zrzkuZtwQZyJflGdvUBgOqXBBXIJIBn4_Cr7m_d6jIA=.0562f04b-4933-4839-a9cb-e6e697f6cac4@github.com>
 <4jyJlsnAIDiAZXDyLnv_pYNHahjWnZpAYoSF-uAZIPU=.ad321f3a-57bb-4c3a-92c7-232debf8d050@github.com>
 <OlZYujJtsKUqGw2oXvU8S11TSHeLlPlvcJiZFg0OGwo=.328247ae-8e77-4cdb-8610-caaff2106563@github.com>
 <-JGuhbXVQrOOAiDS6M46ktb67CT9rXhYozkoTi-QdRU=.1cc6dfe2-4d9c-465b-89af-701c37605435@github.com>
 <skGVSM2e5A0RTsyuVvkYUA0BVGcdY5ycaO7io8_Ceh8=.0fea4521-1408-4721-8715-3da30e1fb32c@github.com>
 <J1VZtJz1sIxgsQKm5dNaXim16SLZHyLQyqsZVt7CQk0=.0baefb26-e3bf-4c0d-8a18-10c51d4bd29f@github.com>
 <M3N2eQAUbh3_kxEgIzxYRHuzB8C8v5oNNqVn4dZhFVs=.ba2b1d06-2707-4fdd-88b2-e60f33839b4e@github.com>
Message-ID: <Nl13bnRFZOROi0ERc3viavlx22eA2HPY1YC2n35gdgA=.6c239de2-ae18-4729-9308-d9aed72cca33@github.com>

On Wed, 12 Feb 2025 16:32:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Tested with SwingSet2, and I can hear the difference in announcements.

Yes, I tested with SwingSet2 application and found the inconsistency in announcements. When we move between radio buttons with left / right arrow (one of the radio buttons is selected) then the announcements are not correct. 

> It looks the difference comes from the focus events: when the old button loses focus, valueChanged isn't called currently, but if Objects.equals is used, valueChanged gets called twice.

Yeah, valueChanged gets called twice and that seems the reason for inconsistent behaviour.

Thank you for carrying out the testing and provide your feedback.

> Let's keep the current behaviour, it's more reliable even though it looks inconsistent.

I agree, functional behaviour should not be incorrect for the sake of code consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1953068417

From kvn at openjdk.org  Wed Feb 12 17:27:16 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 17:27:16 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

This broke our builds:

/jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function 'setInterpreterVersion':
/jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9: error: implicit declaration of function 'FT_Property_Set' [-Werror=implicit-function-declaration]
  307 |         FT_Property_Set(library, module, property, (void*)(&version));
      |         ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

I don't see GHA testing enabled for this repo.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654389337
PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654390478

From aivanov at openjdk.org  Wed Feb 12 17:34:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Feb 2025 17:34:14 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <buKqa4XiBlKH0Lhdw0W6ZKl3LQgltuDKVXHBxVwjLkw=.50ea17bf-322c-4d36-9d65-be01c15c9d4e@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <buKqa4XiBlKH0Lhdw0W6ZKl3LQgltuDKVXHBxVwjLkw=.50ea17bf-322c-4d36-9d65-be01c15c9d4e@github.com>
Message-ID: <WZSllGmGjZf4Q_NDmfHb9DMzdLPOtaP-LMjIHP0YZ9g=.d30fa477-0fbf-4beb-b671-f1cdf000b240@github.com>

On Wed, 5 Feb 2025 07:04:21 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Condition evaluation simplified

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2612711918

From aivanov at openjdk.org  Wed Feb 12 17:44:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 12 Feb 2025 17:44:13 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v2]
In-Reply-To: <VNswYI2VrEXJAJsDFuiOKIutMFNPFfbgJkrCbr4BGkU=.1f482016-cf75-4a21-aefb-3b3933e013e0@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <VNswYI2VrEXJAJsDFuiOKIutMFNPFfbgJkrCbr4BGkU=.1f482016-cf75-4a21-aefb-3b3933e013e0@github.com>
Message-ID: <qTyIdBDGRgrG2Eyl_-eVwVirf8INFFhk0dLwTzHZNMI=.972430e5-8bd9-42d5-be30-5d9889c99f8d@github.com>

On Wed, 5 Feb 2025 07:13:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 87:
>> 
>>> 85: 
>>> 86:                 Press Pass if you are able to hear correct VoiceOver announcements and
>>> 87:                 able to see the correct screen magnifier behaviour. """;
>> 
>> These long instructions may benefit from using HTML for formatting instructions.
>
> Are you suggesting to change entire instruction set with HTML formatting ?
> 
> I would appreciate if you add some sample changes. you are referring

Here's the sample that I used:

<details>
<summary>HTML code for instructions</summary>


        String INSTRUCTIONS = """
                <html><body>
                <p><b>Testing with VoiceOver</b></p>

                <ol>
                  <li>Start the VoiceOver application
                      (Press <kbd>Command</kbd> + <kbd>F5</kbd>)
                  <li>Click on the <i>Frame with CheckBox and ToggleButton</i>
                      window to move focus
                  <li>Press <kbd>Spacebar</kbd>
                  <li>VO should announce the checked state
                  <li>Press <kbd>Spacebar</kbd> again
                  <li>VO should announce the unchecked state
                  <li>Press <kbd>Tab</kbd> to move focus to <i>ToggleButton</i>
                  <li>Repeat steps 3 to 6 and listen the announcement
                  <li>If announcements are incorrect, press <b>Fail</b>
                  <li>Stop the VoiceOver application
                      (Press <kbd>Command</kbd> + <kbd>F5</kbd> again)
                </ol>

                <p><b>Testing with Screen Magnifier</b></p>
                <ol style="margin-bottom: 0">
                  <li>Enable Screen magnifier on the Mac:
                   <b>System Settings</b> -> <b>Accessibility</b> ->
                   <b>Hover Text</b> -> <b>Enable Hover Text</b><br>
                   Default Hover Text Activation Modifier is <kbd>Command</kbd> key.
                  <li>Move focus back to test application

                  <ul style="margin-bottom: 0">
                    <li>Test <i>CheckBox</i> states with Screen Magnifier
                      <ol style="list-style-type: lower-alpha; margin-top: 0; margin-bottom: 0">
                        <li>Click on <i>CheckBox</i> to select it
                        <li>Press the <kbd>Command</kbd> key and
                            hover mouse over <i>CheckBox</i>
                        <li>CheckBox ticked state along with its label should be magnified
                        <li>Keep the <kbd>Command</kbd> key pressed and
                            click <i>CheckBox</i> to deselect it
                        <li>CheckBox unticked state along with its label should be magnified
                        <li>Release the <kbd>Command</kbd> key
                        <li>If Screen Magnifier behaviour is incorrect, press <b>Fail</b>
                      </ol>
                    <li>Test <i>ToggleButton</i> states with Screen Magnifier
                      <ol style="list-style-type: lower-alpha; margin-top: 0; margin-bottom: 0">
                        <li>Click on <i>ToggleButton</i> to select it
                        <li>Press the <kbd>Command</kbd> key and
                            hover mouse over <i>ToggleButton</i>
                        <li>Ticked state along with label should be magnified
                        <li>Keep the <kbd>Command</kbd> button pressed and
                            click <i>ToggleButton</i> to deselect it
                        <li>Unticked state along with its label should be magnified
                        <li>Release the <kbd>Command</kbd> key
                        <li>If Screen Magnifier behaviour is incorrect, press <b>Fail</b>
                      </ol>
                  </ul>
                </ol>

                <p>Press <b>Pass</b> if you are able to hear correct VoiceOver announcements and
                able to see the correct screen magnifier behaviour.</p></body></html>""";

</details>

This gives the following look:

<img alt="Screenshot with the instruction text displayed in HTML" src="https://github.com/user-attachments/assets/38146f37-c86c-4e14-bc9f-98ae384c17ac" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1953131477

From jiangli at openjdk.org  Wed Feb 12 17:49:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 17:49:16 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
Message-ID: <1FgaLnyh90Fm6UnoKXOZbqGDjIH6LT8UP9gOGKbtPhY=.25e5ee06-663f-4f9b-b275-1f5123a63364@github.com>

On Wed, 12 Feb 2025 17:24:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I don't see GHA testing enabled for this repo.

GHA testing is enabled: https://github.com/openjdk/jdk/pull/23574/checks. All tests passed in GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654440345

From kvn at openjdk.org  Wed Feb 12 17:53:44 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 17:53:44 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
Message-ID: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>

Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

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

Commit messages:
 - 8349926: [BACKOUT] Support static JDK in libfontmanager/freetypeScaler.c

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

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

From jiangli at openjdk.org  Wed Feb 12 18:03:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:03:10 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <6jUvH-fUYBSpD6WdLyM3R1AWjEBmKAwLZIak54kTvsQ=.2cebe076-2493-4326-82f8-a5d654c134be@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

Looks good. Thanks!

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

Marked as reviewed by jiangli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23591#pullrequestreview-2612791365

From kvn at openjdk.org  Wed Feb 12 18:12:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 18:12:09 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <HBMfzVxfvfqxYq47UElAQxyy-t_tc9PWmvuXvjSFVKk=.41238a27-f571-43fd-8a72-d6682356ed79@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

I will wait GHA builds finish

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

PR Comment: https://git.openjdk.org/jdk/pull/23591#issuecomment-2654490638

From shade at openjdk.org  Wed Feb 12 18:18:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Feb 2025 18:18:21 GMT
Subject: RFR: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <s4fJRmKF_fKbz0vML0bvMcw02WzXq7NFre891nyvY_o=.788ee812-46ae-4778-9531-a302c77869fa@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23591#pullrequestreview-2612827688

From jiangli at openjdk.org  Wed Feb 12 18:20:16 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:20:16 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
Message-ID: <BXX-nLIW4NlscgF094kS3nVQNStV3z4nw8fjA8gXwtI=.e0f4ccab-d8c1-4c6c-bdf3-7099f45a6ede@github.com>

On Wed, 12 Feb 2025 17:24:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> This broke our builds:
> 
> ```
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function 'setInterpreterVersion':
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9: error: implicit declaration of function 'FT_Property_Set' [-Werror=implicit-function-declaration]
>   307 |         FT_Property_Set(library, module, property, (void*)(&version));
>       |         ^~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> ```

Thanks for reporting the issue. Sorry for introducing a breakage (again). 

Does the issue occur with the same build platform run into https://bugs.openjdk.org/browse/JDK-8349752?

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654506966

From kvn at openjdk.org  Wed Feb 12 18:29:16 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 12 Feb 2025 18:29:16 GMT
Subject: Integrated: 8349926: [BACKOUT] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
References: <HNKYUc9JUHLrrHnJQtxAGJ_uTvBNNuFnYKGM3nJbYFk=.eb66cab3-fb68-4f15-876a-f58528e911c9@github.com>
Message-ID: <i-VhoUO90e-tXnGXTazOjpHHP-mvV--WvvUeTEBIYo8=.8a9334b6-d070-4135-a745-273399a2750d@github.com>

On Wed, 12 Feb 2025 17:49:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout change [JDK-8349859](https://git.openjdk.org/jdk/commit/332d87cc7e19d55ddb98a43a6eb3a77f3518ecfd) because it causes build failure.

This pull request has now been integrated.

Changeset: 336d0d85
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/336d0d8592aed734e7b8139e1ecd71d33825c75a
Stats:     15 lines in 2 files changed: 0 ins; 15 del; 0 mod

8349926: [BACKOUT] Support static JDK in libfontmanager/freetypeScaler.c

Reviewed-by: jiangli, shade

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

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

From jiangli at openjdk.org  Wed Feb 12 18:30:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:30:14 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <BXX-nLIW4NlscgF094kS3nVQNStV3z4nw8fjA8gXwtI=.e0f4ccab-d8c1-4c6c-bdf3-7099f45a6ede@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <8EZFl9u-KLlkaQbdSqPetkF4mgUfEGRzPLRUZKeWyYE=.573c543e-eade-4d78-a32c-d2e2d674ca3d@github.com>
 <BXX-nLIW4NlscgF094kS3nVQNStV3z4nw8fjA8gXwtI=.e0f4ccab-d8c1-4c6c-bdf3-7099f45a6ede@github.com>
Message-ID: <Jp9LvQfM0K9xW0Fzeo_fgDZXPtgnXXTm5NBfZVQ_zkA=.25c9999f-6e6f-4324-a4bc-d00c93c70839@github.com>

On Wed, 12 Feb 2025 18:17:16 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This broke our builds:
> 
> ```
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c: In function 'setInterpreterVersion':
> /jdk_git/open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c:307:9: error: implicit declaration of function 'FT_Property_Set' [-Werror=implicit-function-declaration]
>   307 |         FT_Property_Set(library, module, property, (void*)(&version));
>       |         ^~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> ```

Some analysis:

FT_Property_Set is declared in ftmodapi.h (https://github.com/openjdk/jdk/blob/4b463ee70eceb94fdfbffa5c49dd58dcc6a6c890/src/java.desktop/share/native/libfreetype/include/freetype/ftmodapi.h#L413). The header file is properly included by freetypeScaler.c:

https://github.com/openjdk/jdk/blob/4b463ee70eceb94fdfbffa5c49dd58dcc6a6c890/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#L46

#include FT_MODULE_H


I'm puzzled why it cannot find `FT_Property_Set`. @vnkozlov Can you please provide more info about the build platform? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654529482

From henryjen at openjdk.org  Wed Feb 12 18:40:17 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 12 Feb 2025 18:40:17 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <1r1dP7poRcssttRkzdToevDuSu7wgzJGPv_XG6TMFE0=.d3ba890c-b736-47d1-a9ec-8e389abc0dc1@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

based on the comment, perhaps the library version on the failed host is old? I suppose you can invoke the function as dynamic version with the returned pointer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654548863

From mikael at openjdk.org  Wed Feb 12 18:44:14 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 12 Feb 2025 18:44:14 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <-BqCWg6rzve90JPXF37v-Pz1cVE8sKD6Vh7A3QvZvBQ=.5b06fa8a-3f3d-483f-8a26-b68bbef9813b@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

If it helps, the freetype headers/libraries we're using come from the "devkit", and on linux-x64 we're using an Oracle Linux 6.4 sysroot (see https://github.com/openjdk/jdk/blob/master/make/devkit/Tools.gmk#L62).

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654557344

From jiangli at openjdk.org  Wed Feb 12 18:51:15 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 18:51:15 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <1r1dP7poRcssttRkzdToevDuSu7wgzJGPv_XG6TMFE0=.d3ba890c-b736-47d1-a9ec-8e389abc0dc1@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <1r1dP7poRcssttRkzdToevDuSu7wgzJGPv_XG6TMFE0=.d3ba890c-b736-47d1-a9ec-8e389abc0dc1@github.com>
Message-ID: <slYnL1Nem1c-AY_H0_-8nkz4DOuHLPtVjZ5e2aC6J6I=.5008d035-ee44-40bd-a67b-35bc394c1a05@github.com>

On Wed, 12 Feb 2025 18:37:11 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
>> 
>> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
>> 
>> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.
>
> based on the comment, perhaps the library version on the failed host is old? I suppose you can invoke the function as dynamic version with the returned pointer.

Thanks, @slowhog and @vidmik!

I notice the compilation command has `-I/usr/include/freetype2`. I think that makes sense when using system provided libfreetype and not the bundled one. If the library version on the build system is old, it probably can help explain why it cannot find the function.

So looks like we have to also call the function using the address from symbol lookup, for the static case. I was hoping that we don't have to do that, but looks like we cannot avoid.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654571311

From mikael at openjdk.org  Wed Feb 12 18:57:18 2025
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 12 Feb 2025 18:57:18 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <Rd-D29VPhk4-TK7u6dGfpu-jI9g6zD_lU6HFmkFKJXk=.f6821cf8-bc9c-4ce9-bfee-a92d21fb7d71@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

I can confirm that `FT_Property_Set` does not seem to be there at all in the (older?) version of freetype from OL6.4.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654582536

From jiangli at openjdk.org  Wed Feb 12 19:01:13 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 19:01:13 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <Rd-D29VPhk4-TK7u6dGfpu-jI9g6zD_lU6HFmkFKJXk=.f6821cf8-bc9c-4ce9-bfee-a92d21fb7d71@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <Rd-D29VPhk4-TK7u6dGfpu-jI9g6zD_lU6HFmkFKJXk=.f6821cf8-bc9c-4ce9-bfee-a92d21fb7d71@github.com>
Message-ID: <GibAZtFTt9xqwO95cJWeLqZqpUJz4zC9acxd417Tgbg=.315f4b47-8662-4c60-9051-3e867e36d660@github.com>

On Wed, 12 Feb 2025 18:54:17 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> I can confirm that `FT_Property_Set` does not seem to be there at all in the (older?) version of freetype from OL6.4.

Thanks for confirming!

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654591105

From serb at openjdk.org  Wed Feb 12 19:20:18 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 12 Feb 2025 19:20:18 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <3445Z5DkI165Q34QaaUonLTcpBD64hJaQj4ovwTSPE8=.1131d61b-abb0-4502-8bf2-820039481573@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

In that example, the setFoo methods are not overridden but overloaded, so all of them are accessible at runtime. When you pass null, Java tries to select the most specific type, which is Integer. You can change that by casting null to Number.
see https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2.5

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2654635308

From prr at openjdk.org  Wed Feb 12 19:36:18 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Feb 2025 19:36:18 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
Message-ID: <GJ6s52ylXMccR97_dFoj6K27C_GlKyg9jAqPJhc_6GA=.27ecd976-9593-476a-bf79-07a3a51f900e@github.com>

On Wed, 12 Feb 2025 00:02:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the change that looks up `FT_Property_Set` from the current executable first when running on static JDK. If `FT_Property_Set` can be found, don't `dlopen` `libfreetype.so`. If a bundled `libfreetype` is statically linked with the launcher executable (on static JDK), `FT_Property_Set` is provided in the current executable. 
> 
> According to the existing comment in `setInterpreterVersion`, `libfreetype` is always bundled on Windows & Mac. This change only applies to Linux.
> 
> I tested the change by stepping through the code using `test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java`.

Looks like you will have to more fully copy the pattern in the dynamic linking case.

I am surprised that we still have something from OL 6.x .. I thought we were about to obsolete OL 7.x

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654665427

From dgredler at openjdk.org  Wed Feb 12 19:38:48 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 12 Feb 2025 19:38:48 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary PostScript
 commands
Message-ID: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>

Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.

Two methods are impacted:

`PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.

`PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.

The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.

A test case is included.

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

Commit messages:
 - Avoid generation of unnecessary PS commands during printing

Changes: https://git.openjdk.org/jdk/pull/23595/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23595&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349932
  Stats: 312 lines in 2 files changed: 207 ins; 69 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/23595.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23595/head:pull/23595

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

From honkar at openjdk.org  Wed Feb 12 19:44:09 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 12 Feb 2025 19:44:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <dxT9EqX6MU33JeSQR2tTW145SWibmjLKnfMKFeNgC7U=.92a50cb5-1117-42f0-a31f-3bbb1ca69a04@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

> @honkar-jdk do you have the latest/newest jdk head, especially this change is important 8349214: Improve size optimization flags for MSVC builds [40603a5](https://github.com/openjdk/jdk/commit/40603a5bf039eef03c157bfc49ac8ea2229a94de)
> 
> Before the SIZE opt flags for MSVC were bad.

Looks like I didn't have this changeset in my repo. 
With the size opt flag of `-O1` , I see similar .dll file sizes as before. LGTM now.


201K Feb 12 11:29 splashscreen.dll
177K Feb 12 11:30 splashscreen.dll.map
1.6M Feb 12 11:30 splashscreen.dll.pdb

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23493#pullrequestreview-2613025937

From rmarchenko at openjdk.org  Wed Feb 12 19:57:13 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 12 Feb 2025 19:57:13 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <3445Z5DkI165Q34QaaUonLTcpBD64hJaQj4ovwTSPE8=.1131d61b-abb0-4502-8bf2-820039481573@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <3445Z5DkI165Q34QaaUonLTcpBD64hJaQj4ovwTSPE8=.1131d61b-abb0-4502-8bf2-820039481573@github.com>
Message-ID: <qYQ99l8vM5aOLv2uv2FbVj_8ScAw2hlZLG3inM6LFc0=.ec274d8f-4def-44b1-b887-7f90b7197f68@github.com>

On Wed, 12 Feb 2025 19:17:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In that example, the setFoo methods are not overridden but overloaded, so all of them are accessible at runtime. When you pass null, Java tries to select the most specific type, which is Integer. You can change that by casting null to Number. see https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2.5

Yes, I know this. 

The question is why `Test$DC.setFoo(java.lang.Number)`  is set as default setter, while the default call goes to `Test$AC.setFoo()`? Is this documented, or is there specification? I see that no tests exist for this, so it's not clear what is the expected behaviour.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2654710703

From jiangli at openjdk.org  Wed Feb 12 20:24:19 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 20:24:19 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
Message-ID: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>

Please help review this change. The current version calls `FT_Property_Set` using the function address returned from `dlsym` for the static case as well. This is to avoid build issue on build system using older `libfreetype` that does not define `FT_Property_Set`. Thanks for everyone provided info on https://github.com/openjdk/jdk/pull/23574!

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

Commit messages:
 - Redo JDK-8349859 fix. Instead of calling FT_Property_Set directly, call the function using the address returned by lookup.

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

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

From jiangli at openjdk.org  Wed Feb 12 20:25:22 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 20:25:22 GMT
Subject: RFR: 8349859: Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <GJ6s52ylXMccR97_dFoj6K27C_GlKyg9jAqPJhc_6GA=.27ecd976-9593-476a-bf79-07a3a51f900e@github.com>
References: <b4Fxf3nJvQJmiIqolkWV2WhATFimjoz2kuiiFEKU9-k=.c81acf9a-b55e-491c-9e8c-095b7067aa04@github.com>
 <GJ6s52ylXMccR97_dFoj6K27C_GlKyg9jAqPJhc_6GA=.27ecd976-9593-476a-bf79-07a3a51f900e@github.com>
Message-ID: <qWTxT4XLfGzdyPkUncrs9hkIAGPGDm8Is8fdaCIpSuA=.fcdbd7fd-1596-4202-892d-2d13e3b55204@github.com>

On Wed, 12 Feb 2025 19:33:15 GMT, Phil Race <prr at openjdk.org> wrote:

> Looks like you will have to more fully copy the pattern in the dynamic linking case.
 
Yeah, we still have to call it using the function address for the static case. I sent https://github.com/openjdk/jdk/pull/23600.

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

PR Comment: https://git.openjdk.org/jdk/pull/23574#issuecomment-2654762430

From dgredler at openjdk.org  Wed Feb 12 20:28:10 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 12 Feb 2025 20:28:10 GMT
Subject: RFR: 6562489: Font-Renderer should ignore invisible characters
 \u2062 and \u2063
In-Reply-To: <fi8bg3Wpddoq1hnzEDeo6Ks8SdVzId0ZpSc5p8nN5dM=.acabf2eb-f0c3-4b75-a3e6-9255f747e66b@github.com>
References: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
 <fi8bg3Wpddoq1hnzEDeo6Ks8SdVzId0ZpSc5p8nN5dM=.acabf2eb-f0c3-4b75-a3e6-9255f747e66b@github.com>
Message-ID: <W3RVwYXjN1mFINS0uIamqIX4CvIV7XwDCz2QYX5Gf9A=.dfe21cdb-c0b7-4120-9ef1-cb7cad67289f@github.com>

On Tue, 11 Feb 2025 14:06:08 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Expands regression test to cover bug JDK-6562489.
>> 
>> No additional fix is required after the JDK-8208377 fix (see #22670).
>
> The test update looks good to me.

@avu Thanks! Does anyone else have a few free cycles to provide a second review?

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

PR Comment: https://git.openjdk.org/jdk/pull/23547#issuecomment-2654767191

From prr at openjdk.org  Wed Feb 12 20:49:09 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Feb 2025 20:49:09 GMT
Subject: RFR: 6562489: Font-Renderer should ignore invisible characters
 \u2062 and \u2063
In-Reply-To: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
References: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
Message-ID: <VtnHkSahuWk6hmGFkVh-nQ8tTDGHFAPQp_nl-NMzz-Q=.810a30e7-7aa9-41fa-b900-7306c9063f92@github.com>

On Tue, 11 Feb 2025 01:40:01 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Expands regression test to cover bug JDK-6562489.
> 
> No additional fix is required after the JDK-8208377 fix (see #22670).

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23547#pullrequestreview-2613156684

From prr at openjdk.org  Wed Feb 12 21:05:11 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Feb 2025 21:05:11 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
Message-ID: <5lj7gY7GH1Z6MLLS0QQUeyzdmwzzeMvizaJGphBblaE=.22b59d9d-472a-4834-928a-4243e2916bb2@github.com>

On Wed, 12 Feb 2025 20:19:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please help review this change. The current version calls `FT_Property_Set` using the function address returned from `dlsym` for the static case as well. This is to avoid build issue on build system using older `libfreetype` that does not define `FT_Property_Set`. Thanks for everyone provided info on https://github.com/openjdk/jdk/pull/23574!

It might be prudent this time to put this through the Oracle internal build system. Not just GHA.
I'll submit a build shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/23600#issuecomment-2654838060

From jiangli at openjdk.org  Wed Feb 12 21:31:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 21:31:10 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <5lj7gY7GH1Z6MLLS0QQUeyzdmwzzeMvizaJGphBblaE=.22b59d9d-472a-4834-928a-4243e2916bb2@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
 <5lj7gY7GH1Z6MLLS0QQUeyzdmwzzeMvizaJGphBblaE=.22b59d9d-472a-4834-928a-4243e2916bb2@github.com>
Message-ID: <m-KkvF1oSVc_dPPMG-bSPLQcWodcfPoQ8pp3ODNdgvo=.1c5ba069-f369-4852-b84c-e3661e0e3d58@github.com>

On Wed, 12 Feb 2025 21:03:02 GMT, Phil Race <prr at openjdk.org> wrote:

> It might be prudent this time to put this through the Oracle internal build system. Not just GHA. I'll submit a build shortly.

Thank you, @prrace!

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

PR Comment: https://git.openjdk.org/jdk/pull/23600#issuecomment-2654882500

From duke at openjdk.org  Wed Feb 12 21:35:10 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Feb 2025 21:35:10 GMT
Subject: RFR: 6562489: Font-Renderer should ignore invisible characters
 \u2062 and \u2063
In-Reply-To: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
References: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
Message-ID: <fBeye6jkum84DJh9gcP7lDRU9Gk488jupoaUXN4QXtQ=.bdf597f9-d1cf-48bb-a50e-3c02cae1dcdb@github.com>

On Tue, 11 Feb 2025 01:40:01 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Expands regression test to cover bug JDK-6562489.
> 
> No additional fix is required after the JDK-8208377 fix (see #22670).

@gredler 
Your change (at version e1f945066004c656f2bc275b6d8009c548c781ea) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23547#issuecomment-2654888484

From dgredler at openjdk.org  Wed Feb 12 22:20:18 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 12 Feb 2025 22:20:18 GMT
Subject: Integrated: 6562489: Font-Renderer should ignore invisible characters
 \u2062 and \u2063
In-Reply-To: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
References: <68wWhOKu4PnEqCROF7FkIUV6hyM2fDrYNiVD7YYLIZo=.2e1321ef-16cb-46ff-9ba2-4a2c03ae79c3@github.com>
Message-ID: <heps5iriJpEuTVGOuP-q4i9VXS7euEnIkFWu5_faCcA=.d2872f27-76be-4934-a890-676b4a5e1fc7@github.com>

On Tue, 11 Feb 2025 01:40:01 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Expands regression test to cover bug JDK-6562489.
> 
> No additional fix is required after the JDK-8208377 fix (see #22670).

This pull request has now been integrated.

Changeset: b8576eb4
Author:    Daniel Gredler <dgredler at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8576eb48e6aae96f9bad1caeedaeb4b5b675e34
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

6562489: Font-Renderer should ignore invisible characters \u2062 and \u2063

Reviewed-by: avu, prr

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

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

From dgredler at openjdk.org  Wed Feb 12 23:58:45 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 12 Feb 2025 23:58:45 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks with
 zero-width characters
Message-ID: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>

When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.

The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.

I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).

I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.

For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html

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

Commit messages:
 - Fix LineBreakMeasurer when using zero-width chars

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

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

From serb at openjdk.org  Thu Feb 13 00:15:14 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 13 Feb 2025 00:15:14 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <qYQ99l8vM5aOLv2uv2FbVj_8ScAw2hlZLG3inM6LFc0=.ec274d8f-4def-44b1-b887-7f90b7197f68@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <3445Z5DkI165Q34QaaUonLTcpBD64hJaQj4ovwTSPE8=.1131d61b-abb0-4502-8bf2-820039481573@github.com>
 <qYQ99l8vM5aOLv2uv2FbVj_8ScAw2hlZLG3inM6LFc0=.ec274d8f-4def-44b1-b887-7f90b7197f68@github.com>
Message-ID: <lNrAq7W3kapOC0NXn72Q1ZirZbkNJwtb2KqjrPxVqOE=.1412d7cf-1b48-47fd-bb27-24ea5a817ace@github.com>

On Wed, 12 Feb 2025 19:54:37 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> The question is why `Test$DC.setFoo(java.lang.Number)` is set as default setter, while the default call goes to `Test$AC.setFoo()`?

That is not a default call; it is just a method call when null is passed. If an Integer or Number is passed instead, different methods will be selected.

>Is this documented, or is there specification? I see that no tests exist for this, so it's not clear what is the expected behaviour. I mean, regarding property descriptors.

It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
-  java.beans.Introspector.getBeanInfo(DC.class, Object.class);
-  java.beans.Introspector.getBeanInfo(DC.class, AC.class);

Thus, the methods of the current class have some priority over those of the parent class.

But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2655131122

From honkar at openjdk.org  Thu Feb 13 01:13:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 01:13:11 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update of
 Built-In ICC_Profiles
Message-ID: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>

Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().

It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.

With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_

Fix consists of:
* `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
* Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
* `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
* JavaDoc update for setData() (CSR required)

There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.

Applications which need a modified version of the ICC Profile should instead do the following:


byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
newProfile.setData() // to modify and customize the profile


Following existing tests are modified to update a copy of Built-In profile.

- java/awt/color/ICC_Profile/SetHeaderInfo.java
- java/awt/color/ICC_ProfileSetNullDataTest.java
- sun/java2d/cmm/ProfileOp/SetDataTest.java

NOTE : For existing tests only necessary updates are done.

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

Commit messages:
 - updated existing tests
 - BuiltInProfileCheck test added
 - src code fix

Changes: https://git.openjdk.org/jdk/pull/23606/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23606&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346465
  Stats: 157 lines in 5 files changed: 122 ins; 10 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/23606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23606/head:pull/23606

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

From jiangli at openjdk.org  Thu Feb 13 01:33:14 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 01:33:14 GMT
Subject: RFR: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <Tx21SBZAz5q5aRSygne8VQVSPHvfOeki1H1uWyvje64=.cfc49b7d-eef6-4e0a-8ef0-f4d54ba39a48@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
 <Tx21SBZAz5q5aRSygne8VQVSPHvfOeki1H1uWyvje64=.cfc49b7d-eef6-4e0a-8ef0-f4d54ba39a48@github.com>
Message-ID: <OzzK-eOIAWJIadzDx_p8G9bry5uqlbEm7-x6-KYsM8Y=.facbdfd2-c89f-462c-82d0-2556254c61b4@github.com>

On Wed, 12 Feb 2025 21:57:13 GMT, Phil Race <prr at openjdk.org> wrote:

> The build tasks all succeeded (well, there's a not-relevant windows installer one still in progress, so never mind about that).

Thanks again, @prrace! I'll integrate tomorrow early morning.

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

PR Comment: https://git.openjdk.org/jdk/pull/23600#issuecomment-2655226648

From psadhukhan at openjdk.org  Thu Feb 13 03:26:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Feb 2025 03:26:54 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v12]
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: <53Zq0UJ6eM7Bd2OFEgOz3UH7BlCHVbChk1uDf4GUY5s=.966ee31e-fe47-4574-9ace-3066a0dcb537@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:

  Extend to Windows11 and later

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/46a1cb5a..7fac9e0d

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

  Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 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  Thu Feb 13 03:26:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Feb 2025 03:26:54 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
In-Reply-To: <zD_Q28U7bxKm8HPcBsBDBAoRF9DYWiUW0AVrL08TdpE=.bc4b2966-907d-480a-91a8-da8c62eee1cd@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
 <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>
 <nHKrseB4YhnpLc2xLVMXRHFcZwA3WVDgRPA2JRutcoI=.b1a77194-de05-4f6a-88e0-07fa7a231d49@github.com>
 <K8rmJpvvxJA6--UBb5vNd-iQ2CcHmHmxtYbQuSj6y-M=.d1b6e2f9-c08b-4d84-b028-37756d181a8e@github.com>
 <rSRl3GX0RpPVlEgHfWNixHo63UtQrt9Xd4WSZzgXqOY=.9952bb2d-9b81-4a2a-86d8-645b5fe65844@github.com>
 <zD_Q28U7bxKm8HPcBsBDBAoRF9DYWiUW0AVrL08TdpE=.bc4b2966-907d-480a-91a8-da8c62eee1cd@github.com>
Message-ID: <IZQVRrMPC_MxuM3hrTgdfoOqhM_cWrCmQy3Mmv5sKfc=.d9f8472e-c527-4bc4-8b20-3ac9e30ee832@github.com>

On Wed, 12 Feb 2025 14:32:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Ending support shouldn't mean we should make Windows 10 design look like Windows 11, that would be so wrong, in my opinion..because the user would like to get the same look and feel as in native Windows 10 as much as possible..
>
>> Ending support shouldn't mean we should make Windows 10 design look like Windows 11, that would be so wrong, in my opinion..because the user would like to get the same look and feel as in native Windows 10 as much as possible..
> 
> The thing is neither of us has found any app which displays both radio bullets or check-marks and an icon in its menus.
> 
> The problem with `.equals("Windows 11")` is that it'll need updating if and when Microsoft releases a newer version of Windows because Windows 12 will fallback to rendering like in Windows 10 and earlier versions.

Is it mentioned somewhere that Windows 12 will fallback to Windows 10 rendering? Usually, newer version will carry forward previous design i.e Windows 11 or create entire new design
I guess we will cross that bridge when it comes.

For now, I think this is the least-intrusive, no-CSR-required fix that preserves Windows 10 design and honor Windows 11 native layout as much as possible.
You can propose a better solution, if you have, but till then I think we should allow it.

Let's hear from other Reviewers..

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

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

From psadhukhan at openjdk.org  Thu Feb 13 03:33:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 13 Feb 2025 03:33:54 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v13]
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: <jj74jmJrLmDkz_Q0ckMoYSdtdEYh43B9U6aUEAe9yPE=.fb8b0b92-b41f-4b96-87db-b0b30182b544@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:

  comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/7fac9e0d..7cb51be9

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

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 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 mbaesken at openjdk.org  Thu Feb 13 08:17:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Feb 2025 08:17:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <D1T_WjSdi0OTz4RvSV7ouCs8rztBHMvdV4UNldiCEEw=.4ddafb59-21c3-4f4d-8678-107d5876e987@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

Thanks for looking into it !
Seems I need another re review ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-2655824223

From azvegint at openjdk.org  Thu Feb 13 11:45:18 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 13 Feb 2025 11:45:18 GMT
Subject: Integrated: 8348600: Update PipeWire to 1.3.81
In-Reply-To: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
References: <fHG_3yU8zIWFlpzRKdp18JGNdTDcE976dxq5ak05Q54=.50a2d1ed-4ceb-4321-8962-482ddbee0aee@github.com>
Message-ID: <E0oPPomy1jX57xKDBq1c1k9S8G6LvGgy2jPfk6lS704=.a4e45548-d5b0-40ff-ba74-8919d92fb388@github.com>

On Mon, 3 Feb 2025 18:50:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This changeset updates the pipewire headers to the latest available version.
> It contains the minimum set of required header files needed to build the JDK.
> 
> The updated headers are a direct copy from the 
> https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.3.81 (except for the `\t` -> `    ` replacement)
>  
> Testing looks good.

This pull request has now been integrated.

Changeset: add3cd1c
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/add3cd1ca470be8fd5e5e1930d7f789318eb8e6d
Stats:     2369 lines in 72 files changed: 1728 ins; 59 del; 582 mod

8348600: Update PipeWire to 1.3.81

Reviewed-by: psadhukhan, prr, honkar

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

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

From azvegint at openjdk.org  Thu Feb 13 11:55:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 13 Feb 2025 11:55:53 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v4]
In-Reply-To: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
Message-ID: <FH_IfrJvUYeASaENDEa2tdahhsd6VUa9MFgOySIBIac=.d28b27f8-c5fd-406b-b1df-99b170e69ba2@github.com>

> Filed as a separate issue to keep the #23426 clean.
> 
> Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)

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

 - Merge master
 - move fix to spa/utils/endian.h
 - merge "if defined"
 - 8349751: AIX build failure after upgrade pipewire to 1.3.81
 - replace "\t" with "    ", part 2
 - replace "\t" with "    "
 - 8348600: Update PipeWire to 1.3.81

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

Changes: https://git.openjdk.org/jdk/pull/23543/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23543&range=03
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23543/head:pull/23543

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

From aivanov at openjdk.org  Thu Feb 13 12:54:20 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 13 Feb 2025 12:54:20 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v11]
In-Reply-To: <IZQVRrMPC_MxuM3hrTgdfoOqhM_cWrCmQy3Mmv5sKfc=.d9f8472e-c527-4bc4-8b20-3ac9e30ee832@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <e4rYXtGFiyJCFffml9ahBekit7f1xbrRu1-H7bCidGY=.589ee4e4-e6bb-49a2-b186-f06b78743109@github.com>
 <J70pktDspi28ug4Kd9jBPbPVh7WmIzUgQ_SDU8HMKr8=.27344bcc-818c-42f4-99e5-762dee02c2e8@github.com>
 <nHKrseB4YhnpLc2xLVMXRHFcZwA3WVDgRPA2JRutcoI=.b1a77194-de05-4f6a-88e0-07fa7a231d49@github.com>
 <K8rmJpvvxJA6--UBb5vNd-iQ2CcHmHmxtYbQuSj6y-M=.d1b6e2f9-c08b-4d84-b028-37756d181a8e@github.com>
 <rSRl3GX0RpPVlEgHfWNixHo63UtQrt9Xd4WSZzgXqOY=.9952bb2d-9b81-4a2a-86d8-645b5fe65844@github.com>
 <zD_Q28U7bxKm8HPcBsBDBAoRF9DYWiUW0AVrL08TdpE=.bc4b2966-907d-480a-91a8-da8c62eee1cd@github.com>
 <IZQVRrMPC_MxuM3hrTgdfoOqhM_cWrCmQy3Mmv5sKfc=.d9f8472e-c527-4bc4-8b20-3ac9e30ee832@github.com>
Message-ID: <rI_RC6iAz9gRA7UNNS2BBt_5DsOf-3vNtYPchob6z0w=.279d628c-1430-4165-953e-c4238b6ad69e@github.com>

On Thu, 13 Feb 2025 03:23:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Is it mentioned somewhere that Windows 12 will fallback to Windows 10 rendering?

I was mentioned in our, JDK, code.

https://github.com/openjdk/jdk/blob/46a1cb5a4f2eb922e56b221a5420d2ac1204ade5/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java#L663

The condition `System.getProperty("os.name").equals("Windows 11")` would evaluate to `false` in Windows 12, and the rendering would've fell back to Windows 10 way.

You've taken care of this in your latest changeset.

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

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

From duke at openjdk.org  Thu Feb 13 13:47:58 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Thu, 13 Feb 2025 13:47:58 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v3]
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <T4FxWsjbB49BT1QvH0DiRNbo71RySYAd6xBU3oWeyqY=.c5ab8b27-5464-4a69-8326-ac2325381aa9@github.com>

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

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

  remove code duplication

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23457/files
  - new: https://git.openjdk.org/jdk/pull/23457/files/9b35b93a..621bf2e0

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

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

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

From duke at openjdk.org  Thu Feb 13 13:55:11 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Thu, 13 Feb 2025 13:55:11 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v2]
In-Reply-To: <HIh1yBXCEP78AQ4PI7Q2c3UefZlzJGPOv6vowBSbSXY=.a80b8824-f829-4bb9-bdab-96d3ef50ce1c@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
 <k6TZ0TTd-CQnoB-7SvXWh701Hf_hzScujtVnOSKLSZU=.44ec1d04-559a-4112-8aaa-d363e445fad7@github.com>
 <HIh1yBXCEP78AQ4PI7Q2c3UefZlzJGPOv6vowBSbSXY=.a80b8824-f829-4bb9-bdab-96d3ef50ce1c@github.com>
Message-ID: <Lj5oZZXCAbt7GHxc3ZdvAcBhlkl7gr_OYi9MiCN1Vsc=.f47191f0-7151-4f91-ac65-67e822c202ec@github.com>

On Tue, 11 Feb 2025 21:43:53 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace regexp s+ with space
>
> src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 1641:
> 
>> 1639:                 execCmd[n++] = "-o job-sheets=standard";
>> 1640:             }
>> 1641:             if (optionArgs != null) {
> 
> I see this block is the same in both branches of the if condition. Can we just move it outside the condition to keep it simpler?

Yes, these are the same blocks, thanks. I moved options after the if condition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23457#discussion_r1954540443

From rmarchenko at openjdk.org  Thu Feb 13 13:55:13 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 13 Feb 2025 13:55:13 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
Message-ID: <Xhazfift0fhXZ561csieC0_fVRryLwyrqLzjVxZXoZQ=.1ec44e99-c8ad-4b56-84f1-34287ae68acc@github.com>

On Thu, 6 Feb 2025 14:13:50 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also fixed the test, and added the approptiate test case.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/beans/Introspector/DefaultMethodBeanPropertyTest.java
>   
>   Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

> It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
> ...
> Thus, the methods of the current class have some priority over those of the parent class.
> But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.

Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).

I'm still wondering if there's  any specification (tests?) describing this. At the time it looks like the current implementation is the only doc.

If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK. 


Case 1:
    public interface A {
        default public void setParentFoo(Integer num) {
        }
        default public void setFoo(Integer num) {
        }
    }

    public class D implements A {
        public void setFoo(Number num) {
        }
        public void setLocalFoo(Long num) {
        }
        public void setLocalFoo(Float num) {
        }
    }

Expecting:

--- properties
public void Test$D.setFoo(java.lang.Number)
public void Test$D.setLocalFoo(java.lang.Float)
public default void Test$A.setParentFoo(java.lang.Integer)
--- methods
public void Test$D.setFoo(java.lang.Number)
public void Test$D.setLocalFoo(java.lang.Float)
public default void Test$A.setFoo(java.lang.Integer)
public void Test$D.setLocalFoo(java.lang.Long)
public default void Test$A.setParentFoo(java.lang.Integer)


Case 2:
    public class AC {
        public void setParentFoo(Integer num) {
        }
        public void setFoo(Integer num) {
        }
    }

    public class DC extends AC {
        public void setFoo(Number num) {
        }
        public void setLocalFoo(Long num) {
        }
        public void setLocalFoo(Float num) {
        }
    }

Expecting:

--- properties
public void Test$DC.setFoo(java.lang.Number)
public void Test$DC.setLocalFoo(java.lang.Float)
public void Test$AC.setParentFoo(java.lang.Integer)
--- methods
public void Test$DC.setFoo(java.lang.Number)
public void Test$DC.setLocalFoo(java.lang.Float)
public void Test$AC.setFoo(java.lang.Integer)
public void Test$DC.setLocalFoo(java.lang.Long)
public void Test$AC.setParentFoo(java.lang.Integer)


Case 3:
    interface Parent1<T> {
        T getValue();
    }

    interface Parent2 {
        Runnable getValue();
    }

    interface Parent3 extends Parent2, Parent1<Object> {
        Runnable getValue();
    }

    abstract class Child implements Parent3 {
        public void setValue(Runnable value) {
        }
    }

Expecting:

--- properties
public void Test$Child.setValue(java.lang.Runnable)
--- methods
public void Test$Child.setValue(java.lang.Runnable)

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2656664421

From mbaesken at openjdk.org  Thu Feb 13 14:19:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Feb 2025 14:19:15 GMT
Subject: Integrated: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <tHNtniywJCIVeIIWdJPbjrgZ9s2WSkkD9JfztTnRxFg=.273beeb5-307e-44f3-82b4-24acc8edc3e9@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

This pull request has now been integrated.

Changeset: c2fc9478
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2fc94782669ae1645014ee3bfeba957dbff4669
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8349378: Build splashscreen lib with SIZE optimization

Reviewed-by: erikj, prr, honkar

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

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

From mbaesken at openjdk.org  Thu Feb 13 14:28:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Feb 2025 14:28:11 GMT
Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and
 ShapeSINextSpan in libawt java2d from ubsan checks
In-Reply-To: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
References: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
Message-ID: <k0DKt3RZv6khEJyQBvXjXz5mMxm7Tv8nUpDR1Up1rWA=.4f11b95d-75ab-460b-92c7-741533dd55db@github.com>

On Thu, 23 Jan 2025 09:23:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) 
> jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows
> 
> jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int'
>     #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683
>     #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499
>     #2 0x7efe9b8dee7b (<unknown module>)
> 
> java/awt/BasicStroke/DashStrokeTest.java shows
> 
> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int'
>     #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366
>     #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75
>     #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92
>     #3 0x7fba12d07e7b (<unknown module>)
> 
> 
> There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings.

Any more comments on this ? If not I would integrate it soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2656759295

From jiangli at openjdk.org  Thu Feb 13 15:47:35 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 15:47:35 GMT
Subject: Integrated: 8349925: [REDO] Support static JDK in
 libfontmanager/freetypeScaler.c
In-Reply-To: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
References: <cjESHMsvpGi4KV3WzGzOyF-1itQn7lKLQ4oiIOijw-I=.3a170882-b655-4b50-b11e-f8f07908ed22@github.com>
Message-ID: <5kUCUe3yTdNhqIW39aJrNEC3181g1G4i3dzPFsnakP8=.0a49b91d-3ea8-46f2-b38b-ae135386b9a7@github.com>

On Wed, 12 Feb 2025 20:19:08 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please help review this change. The current version calls `FT_Property_Set` using the function address returned from `dlsym` for the static case as well. This is to avoid build issue on build system using older `libfreetype` that does not define `FT_Property_Set`. Thanks for everyone provided info on https://github.com/openjdk/jdk/pull/23574!

This pull request has now been integrated.

Changeset: 18958c62
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18958c6298bf5cc5495375e2940b640b04ec9ccb
Stats:     18 lines in 2 files changed: 17 ins; 0 del; 1 mod

8349925: [REDO] Support static JDK in libfontmanager/freetypeScaler.c

Reviewed-by: prr

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

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

From dnguyen at openjdk.org  Thu Feb 13 17:51:11 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 13 Feb 2025 17:51:11 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
Message-ID: <6btLbLgS62NXUnphb0x8kHvniTWgVRATsXC5vDquFTw=.db5499cf-4c8d-43f9-8e75-5d99341fc78c@github.com>

On Sun, 9 Feb 2025 19:56:48 GMT, anass baya <duke at openjdk.org> wrote:

>> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
>> 
>> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
>> 
>> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
>> 
>> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.
>
> anass baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add proposed enhancments

Ran the test with repeats on all OS's. Seems good to me. I tried playing with the tolerance values a bit, and I think the tolerance here seems fine.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23449#pullrequestreview-2615818132

From honkar at openjdk.org  Thu Feb 13 18:05:12 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 18:05:12 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
Message-ID: <JedcQQevKeN5e9RgwONgWrS2Ziw-A6xaIOPIx0gtUtU=.d453bb4f-8f7a-46bc-8dd4-9fc86dad1a66@github.com>

On Sun, 9 Feb 2025 19:56:48 GMT, anass baya <duke at openjdk.org> wrote:

>> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
>> 
>> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
>> 
>> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
>> 
>> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.
>
> anass baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add proposed enhancments

LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23449#pullrequestreview-2615842001

From honkar at openjdk.org  Thu Feb 13 18:05:13 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 18:05:13 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <DbixoY9a-ZEig4Jmqgp1dfBm0UdDj13ny45ypwNEJeE=.7ef4e073-bdc5-4172-af03-9a7c5dfd9006@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>
 <SxvHNw49f7gWTrpRcYH9q-677-2g5_2SpZULunyFi4s=.b1f1a722-26a4-44cd-96d5-10c066abe3c2@github.com>
 <FLNHZA1V3VsK5JYZJoiEKaOfE4Gw5jSOGqzNRlszCyg=.bb7ccc48-639b-4fce-b6a7-a95ee02b7f36@github.com>
 <MKHDkY0sLjs_lIu1NZs88jLLdtfgpQLUsqdxhqBqzx4=.6987cec3-902b-4c80-85b1-2461484b1a31@github.com>
 <DbixoY9a-ZEig4Jmqgp1dfBm0UdDj13ny45ypwNEJeE=.7ef4e073-bdc5-4172-af03-9a7c5dfd9006@github.com>
Message-ID: <gKO8fonyp4rq3RUoRcAoibxQJX5ICQ8tpO72DVjggrU=.f92bfbdd-22e6-4782-81e5-1b88691c5a11@github.com>

On Sun, 9 Feb 2025 19:51:13 GMT, anass baya <duke at openjdk.org> wrote:

>> Tolerance when comparing colours is different from comparing sizes.
>> 
>> We know that fractional pixels after scaling up and down may be lost, that's where the tolerance comes from.
>
> Tests seem Okay on CI as well as on my local setup

Missed the update. Approved the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1954986149

From honkar at openjdk.org  Thu Feb 13 18:08:15 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 18:08:15 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <MKHDkY0sLjs_lIu1NZs88jLLdtfgpQLUsqdxhqBqzx4=.6987cec3-902b-4c80-85b1-2461484b1a31@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <T6rQbS6ReKUMWGTgfWxrxzg9kwK9LWT8g1QFP19JF4Q=.0fbcbf57-d5a8-4db3-88a2-6170295f48da@github.com>
 <SxvHNw49f7gWTrpRcYH9q-677-2g5_2SpZULunyFi4s=.b1f1a722-26a4-44cd-96d5-10c066abe3c2@github.com>
 <FLNHZA1V3VsK5JYZJoiEKaOfE4Gw5jSOGqzNRlszCyg=.bb7ccc48-639b-4fce-b6a7-a95ee02b7f36@github.com>
 <MKHDkY0sLjs_lIu1NZs88jLLdtfgpQLUsqdxhqBqzx4=.6987cec3-902b-4c80-85b1-2461484b1a31@github.com>
Message-ID: <R32X9htpm1I-TMpZXrq79hfuC6GJ52fuoZvEw3NG4Qw=.8b3d909c-f10f-4e76-b5db-40d55913ce37@github.com>

On Fri, 7 Feb 2025 19:30:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> If it test runs fine on CI then it should be okay. Previously, I came across few tests which required increasing tolerance value (although not in this context but particularly for pixel color case).
>
> Tolerance when comparing colours is different from comparing sizes.
> 
> We know that fractional pixels after scaling up and down may be lost, that's where the tolerance comes from.

@aivanov-jdk 
> We know that fractional pixels after scaling up and down may be lost, that's where the tolerance comes from.

You are right, scaling up and down a fractional pixel can be at most be off by one pixel.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23449#discussion_r1954993246

From serb at openjdk.org  Thu Feb 13 18:28:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 13 Feb 2025 18:28:20 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <Xhazfift0fhXZ561csieC0_fVRryLwyrqLzjVxZXoZQ=.1ec44e99-c8ad-4b56-84f1-34287ae68acc@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <Xhazfift0fhXZ561csieC0_fVRryLwyrqLzjVxZXoZQ=.1ec44e99-c8ad-4b56-84f1-34287ae68acc@github.com>
Message-ID: <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>

On Thu, 13 Feb 2025 13:52:05 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

> > It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
> > ...
> > Thus, the methods of the current class have some priority over those of the parent class.
> > But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
> 
> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).

There is "test/jdk/java/beans/Introspector/TestMethodOrderDependence.java" which was added to prevent accidental change in the implementation, but part of the behavior is undefined/unspecified.

>If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK.

New tests are always welcome, especially for interfaces, as they are a relatively new feature.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2657410227

From prr at openjdk.org  Thu Feb 13 21:07:12 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Feb 2025 21:07:12 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <gJe9XEjgvVERbkblprJyjaISu-FT-CcCWUBXftF90ow=.f9a1ac3a-794d-41ed-bc66-8990706338c2@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

This is a desirable and over-due fix but some small things to handle first.
Whilst this passed testing, I have some comments, one in-line, but testing related ones here
There are 6 images attached, but the test uses only 5.
The images were all attached to the bug, but I don't think that means we automatically have the rights to push them into JDK.
Brian Burkhalter attached at least 3 of them, so I need him to speak up about where they came from. I'd also like @bplb to review this change

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 165:

> 163:                 ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN);
> 164:         if (input.readUnsignedShort() != TIFF_MAGIC) {
> 165:             throw new IllegalArgumentException("Bad magic number");

Where does this exception end up ? I would have supposed that if there's an Exif segment we don't like it would be best to just act like the segment isn't there.

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

PR Review: https://git.openjdk.org/jdk/pull/22898#pullrequestreview-2616189089
PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1955194737

From bpb at openjdk.org  Thu Feb 13 21:18:11 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Feb 2025 21:18:11 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <gJe9XEjgvVERbkblprJyjaISu-FT-CcCWUBXftF90ow=.f9a1ac3a-794d-41ed-bc66-8990706338c2@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <gJe9XEjgvVERbkblprJyjaISu-FT-CcCWUBXftF90ow=.f9a1ac3a-794d-41ed-bc66-8990706338c2@github.com>
Message-ID: <_mlpguaElNkYHxwfVhzTNDPglNNZJtB8pDrj4e4W0fA=.807f29cf-09f7-4f85-8e0d-af71e0b7510e@github.com>

On Thu, 13 Feb 2025 21:04:29 GMT, Phil Race <prr at openjdk.org> wrote:

> Brian Burkhalter attached at least 3 of them, so I need him to speak up about where they came from.

The only one I can attribute at the moment is SV650.jpg, which is a photo of my motorcycle taken by me with my own camera. It's fine with me if it is used for testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2657719272

From prr at openjdk.org  Thu Feb 13 21:18:12 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Feb 2025 21:18:12 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <Z9P6vnSJ0qnMfzTiIb1MzV4eVbA5txaa67dzeFaHmLk=.a3437b5e-2bca-45ec-b9bb-f9b6972d93b1@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

PS .. if even a couple of these images get checked in, then it might be a case for the test to be in its own sub-dir along with the related images, rather than naming them with the bug id ..

PPS .. in fact 3 of the images here aren't from the bug.
@mickleness where are they from ? Do you own them ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2657721887
PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2657726858

From prr at openjdk.org  Thu Feb 13 21:39:16 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Feb 2025 21:39:16 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <l0S0pNyxpKcAQJweq9LD2wR3ATBr5d7NVLvOp64cRNk=.0c9a7186-6722-437b-9ca2-321c7b8f6f0f@github.com>

On Thu, 13 Feb 2025 01:08:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1165:

> 1163:      *         the {@code tagSignature}
> 1164:      * @throws IllegalArgumentException if the profile being updated has
> 1165:      *         {@code isBuiltIn} flag set to true

isBuiltin is a private variable. You can't reference it in public API javadoc.

What this ought to say is
@throw IllegalArgumentException if this is a profile for one of the built-in pre-defined ColorSpaces, i.e those which can be obtained by calling ICC_Profile.getInstance(int cspace) 

There isn't a general way to get that list - but it is short - only 5 colour spaces, and you could put an @see ColorSpace link

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1955247029

From honkar at openjdk.org  Thu Feb 13 21:56:37 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 21:56:37 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v2]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <gij3NwmaGB5Q_Ms7Ht_fcs6JY59ykwpMCdK93yaRITI=.a99401e4-6283-433f-a572-5bb57a28e717@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  javadoc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/0414f60c..11bdc2e3

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

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

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

From honkar at openjdk.org  Thu Feb 13 21:56:37 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 21:56:37 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v2]
In-Reply-To: <l0S0pNyxpKcAQJweq9LD2wR3ATBr5d7NVLvOp64cRNk=.0c9a7186-6722-437b-9ca2-321c7b8f6f0f@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <l0S0pNyxpKcAQJweq9LD2wR3ATBr5d7NVLvOp64cRNk=.0c9a7186-6722-437b-9ca2-321c7b8f6f0f@github.com>
Message-ID: <4KDHym6f7YuAOqqcjxyztZF_uv4Z0ZLuukKyDUygw4o=.b6e3bf20-44a6-47af-9cfe-cce4f9552028@github.com>

On Thu, 13 Feb 2025 21:36:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc update
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1165:
> 
>> 1163:      *         the {@code tagSignature}
>> 1164:      * @throws IllegalArgumentException if the profile being updated has
>> 1165:      *         {@code isBuiltIn} flag set to true
> 
> isBuiltin is a private variable. You can't reference it in public API javadoc.
> 
> What this ought to say is
> @throw IllegalArgumentException if this is a profile for one of the built-in pre-defined ColorSpaces, i.e those which can be obtained by calling ICC_Profile.getInstance(int cspace) 
> 
> There isn't a general way to get that list - but it is short - only 5 colour spaces, and you could put an @see ColorSpace link

Thanks Phil. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1955264291

From honkar at openjdk.org  Thu Feb 13 22:03:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 22:03:11 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v2]
In-Reply-To: <gij3NwmaGB5Q_Ms7Ht_fcs6JY59ykwpMCdK93yaRITI=.a99401e4-6283-433f-a572-5bb57a28e717@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <gij3NwmaGB5Q_Ms7Ht_fcs6JY59ykwpMCdK93yaRITI=.a99401e4-6283-433f-a572-5bb57a28e717@github.com>
Message-ID: <WlE-D6ifPC0Wvs76PVHxENn4fjQ31GHkXMnUPyNa54I=.6c0a8bdf-f17d-4311-93a7-4a824d18f437@github.com>

On Thu, 13 Feb 2025 21:56:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> Fix consists of:
>> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
>> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
>> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
>> * JavaDoc update for setData() (CSR required)
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1154:

> 1152:      * This method is useful for advanced applications which need to access
> 1153:      * profile data directly. Only non-BuiltIn profiles can be updated using
> 1154:      * this method.

@prrace 
I added this additional line here mentioning that only non-BuiltIn profiles can be updated. Does it look okay or do you recommend any changes ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1955271625

From prr at openjdk.org  Thu Feb 13 22:09:10 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Feb 2025 22:09:10 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v2]
In-Reply-To: <gij3NwmaGB5Q_Ms7Ht_fcs6JY59ykwpMCdK93yaRITI=.a99401e4-6283-433f-a572-5bb57a28e717@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <gij3NwmaGB5Q_Ms7Ht_fcs6JY59ykwpMCdK93yaRITI=.a99401e4-6283-433f-a572-5bb57a28e717@github.com>
Message-ID: <IzaEkc5DEMiOzZVb_bY5Vsv2V1_601Tvo8c5UGPE8E0=.d8d3278b-f104-4ce4-a882-b36f38dc8365@github.com>

On Thu, 13 Feb 2025 21:56:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> Fix consists of:
>> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
>> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
>> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
>> * JavaDoc update for setData() (CSR required)
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1166:

> 1164:      * @throws IllegalArgumentException if this is a profile for one of the
> 1165:      *         built-in pre-defined ColorSpaces, i.e. those which can be obtained
> 1166:      *         by calling ICC_Profile.getInstance(int cspace)

you should put that method ref in {@code .. }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1955279012

From honkar at openjdk.org  Thu Feb 13 22:15:28 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 22:15:28 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v3]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <MkIBVmIc6y9jhARi_kNZqSCmSASbZDioOGadslNRgaQ=.4cf89e18-7d71-4d28-b235-0f7345b1713c@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  code annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/11bdc2e3..1da22087

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

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

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

From prr at openjdk.org  Thu Feb 13 22:18:11 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 13 Feb 2025 22:18:11 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <evAenTOjoERTQqzy0mFSRfPw3pkiKTJGAGWWtUXBFnc=.288e0965-3e4b-4b91-946c-351d89c976f5@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
 <evAenTOjoERTQqzy0mFSRfPw3pkiKTJGAGWWtUXBFnc=.288e0965-3e4b-4b91-946c-351d89c976f5@github.com>
Message-ID: <cWLREUTKZi-TdD8Cg3UGHi_T_konPWUlo5no_cGJK9w=.7fbb02b9-6c74-476c-ab57-faee6c6cdb40@github.com>

On Thu, 6 Feb 2025 14:30:30 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
>> 
>> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.
>
> src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java line 245:
> 
>> 243:             throw new EOFException();
>> 244:         }
>> 245:         return (byteOrder == ByteOrder.BIG_ENDIAN)
> 
> This could just be `ByteArray.getShortBO(byteBuff, 0, byteOrder == ByteOrder.BIG_ENDIAN)`. Same for the others.

That would look cleaner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1955287769

From honkar at openjdk.org  Thu Feb 13 23:15:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 13 Feb 2025 23:15:52 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v4]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <P_lYJ11P0HgVIQxy_SnkZe8BSGn9iV4mjIQH97VS7z8=.75e735c5-248c-4553-923f-6c9f525c3cd3@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  removed @link

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/1da22087..52c76c73

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

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

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

From duke at openjdk.org  Thu Feb 13 23:22:13 2025
From: duke at openjdk.org (Jeremy)
Date: Thu, 13 Feb 2025 23:22:13 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <IK0Ehu2Ewo81kAN2Dad8DZuL1I3Bskbo-uarke3NY_I=.3314a7f9-4123-4284-b234-33a6b619ffd3@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

Yes: the new 3 images are images that I own (plastic-wrap, unusual-IFD, bad-timestamp). 

Brian just confirmed we can use SV650.

Sometime (maybe this weekend?) I can scan all the JPEGs on my machine and see if I find one with properties that match other 2 jpeg files we may not have permission to share (exif-rgb-thumbnail, sharpshot-iphone).

(I'll also review PR's other notes.)

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2657909448

From bpb at openjdk.org  Thu Feb 13 23:46:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Feb 2025 23:46:13 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <IK0Ehu2Ewo81kAN2Dad8DZuL1I3Bskbo-uarke3NY_I=.3314a7f9-4123-4284-b234-33a6b619ffd3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <IK0Ehu2Ewo81kAN2Dad8DZuL1I3Bskbo-uarke3NY_I=.3314a7f9-4123-4284-b234-33a6b619ffd3@github.com>
Message-ID: <kONuJM_Uojrnl4qnZ-8FDs_oraYF6OSp1xUmgwSLQZ8=.a245cf82-c216-487b-beac-4f379dfe9f39@github.com>

On Thu, 13 Feb 2025 23:19:35 GMT, Jeremy <duke at openjdk.org> wrote:

> I can scan all the JPEGs on my machine and see if I find one with properties that match other 2 jpeg files we may not have permission to share (exif-rgb-thumbnail, sharpshot-iphone).

At a minimum the test images should cover:

1. compressed (JPEG) main image, compressed (JPEG) thumbnail
2. compressed (JPEG) main image, uncompressed (RGB) thumbnail
3. uncompressed (RGB) main image, uncompressed (RGB) thumbnail

The case of an uncompressed main image with compressed thumbnail is not specified, if memory serves.

There are other cases than the above, e.g., YCbCr, but I would expect the above to cover most cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2657937708

From prr at openjdk.org  Fri Feb 14 00:07:09 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 14 Feb 2025 00:07:09 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters
In-Reply-To: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
Message-ID: <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>

On Wed, 12 Feb 2025 23:53:43 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
> 
> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
> 
> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
> 
> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
> 
> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html

Early days but the test fails on macOS
Exception in thread "main" java.lang.RuntimeException: nextOffset 1 for char 00ad using font Dialog: 2 != 1
	at FormatCharAdvanceTest.assertEqual(FormatCharAdvanceTest.java:289)
	at FormatCharAdvanceTest.testChar(FormatCharAdvanceTest.java:282)
	at FormatCharAdvanceTest.testChars(FormatCharAdvanceTest.java:165)
	at FormatCharAdvanceTest.main(FormatCharAdvanceTest.java:154)

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

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2657960847

From dgredler at openjdk.org  Fri Feb 14 00:13:10 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 14 Feb 2025 00:13:10 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters
In-Reply-To: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
Message-ID: <-1DQ1TSIfQbZzQ87_pj-zV6d-gw-gfdlO8pOFmJHj6w=.9cae1e57-b099-4da8-9c78-34ba0399e99a@github.com>

On Wed, 12 Feb 2025 23:53:43 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
> 
> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
> 
> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
> 
> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
> 
> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html

Interesting, I've been testing on Linux. I'll break out the Mac to see what's going on.

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

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2657968332

From duke at openjdk.org  Fri Feb 14 01:27:23 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Feb 2025 01:27:23 GMT
Subject: Withdrawn: 8346603: Cleanup Metacity.ThemeGetter class
In-Reply-To: <H9RKKX2s8WyNXAXkLTJa8hwdtPFJBI6qbldY7iZrz7A=.10b72385-5d18-4c70-953b-d23641a436c9@github.com>
References: <H9RKKX2s8WyNXAXkLTJa8hwdtPFJBI6qbldY7iZrz7A=.10b72385-5d18-4c70-953b-d23641a436c9@github.com>
Message-ID: <V86c-wqPOZSwQiEUEshSWZhTRwEnJ0MmNYSqNdhBp8I=.abe907b6-ee60-4c4d-ba16-7f644eb1fcb1@github.com>

On Thu, 21 Nov 2024 06:38:26 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is opportunity to remove redundant nested class `Metacity.ThemeGetter`. It was introduced in the SecurityManager era to handle privileged call. Now (after https://github.com/openjdk/jdk/pull/22186/files#diff-5e3ecade1f409333dfba477b64039f86887d1febbff517407835fcac17a77b2a) it's not the case and we can remove it.
> It simplifies and streamlines logic.

This pull request has been closed without being integrated.

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

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

From abhiscxk at openjdk.org  Fri Feb 14 04:32:53 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 14 Feb 2025 04:32:53 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v3]
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <kpTLg9w83l1yz-nuhHjLkZi6wAz4eaT1yq3gnb0X8Ys=.db55fdbc-8bd6-4fa2-aa14-c1954e83947a@github.com>

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

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

  HTML instructions formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23436/files
  - new: https://git.openjdk.org/jdk/pull/23436/files/1bfa6d98..0418694c

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

  Stats: 79 lines in 1 file changed: 42 ins; 26 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23436/head:pull/23436

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

From abhiscxk at openjdk.org  Fri Feb 14 04:32:54 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 14 Feb 2025 04:32:54 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v3]
In-Reply-To: <qTyIdBDGRgrG2Eyl_-eVwVirf8INFFhk0dLwTzHZNMI=.972430e5-8bd9-42d5-be30-5d9889c99f8d@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <j26h80JAE2daYh0OBZjiAl7vO2eYcigotNSRBBYAwPw=.e2fafa48-3a44-421f-bb91-24578aed5443@github.com>
 <VNswYI2VrEXJAJsDFuiOKIutMFNPFfbgJkrCbr4BGkU=.1f482016-cf75-4a21-aefb-3b3933e013e0@github.com>
 <qTyIdBDGRgrG2Eyl_-eVwVirf8INFFhk0dLwTzHZNMI=.972430e5-8bd9-42d5-be30-5d9889c99f8d@github.com>
Message-ID: <nEfWmUSpQRKYOOUGx5aMZli7QGCa_dEj9JEjt5H823Q=.d5d9263a-ebb9-4644-834b-910fc14cd2c2@github.com>

On Wed, 12 Feb 2025 17:41:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Are you suggesting to change entire instruction set with HTML formatting ?
>> 
>> I would appreciate if you add some sample changes. you are referring
>
> Here's the sample that I used:
> 
> <details>
> <summary>HTML code for instructions</summary>
> 
> 
>         String INSTRUCTIONS = """
>                 <html><body>
>                 <p><b>Testing with VoiceOver</b></p>
> 
>                 <ol>
>                   <li>Start the VoiceOver application
>                       (Press <kbd>Command</kbd> + <kbd>F5</kbd>)
>                   <li>Click on the <i>Frame with CheckBox and ToggleButton</i>
>                       window to move focus
>                   <li>Press <kbd>Spacebar</kbd>
>                   <li>VO should announce the checked state
>                   <li>Press <kbd>Spacebar</kbd> again
>                   <li>VO should announce the unchecked state
>                   <li>Press <kbd>Tab</kbd> to move focus to <i>ToggleButton</i>
>                   <li>Repeat steps 3 to 6 and listen the announcement
>                   <li>If announcements are incorrect, press <b>Fail</b>
>                   <li>Stop the VoiceOver application
>                       (Press <kbd>Command</kbd> + <kbd>F5</kbd> again)
>                 </ol>
> 
>                 <p><b>Testing with Screen Magnifier</b></p>
>                 <ol style="margin-bottom: 0">
>                   <li>Enable Screen magnifier on the Mac:
>                    <b>System Settings</b> -> <b>Accessibility</b> ->
>                    <b>Hover Text</b> -> <b>Enable Hover Text</b><br>
>                    Default Hover Text Activation Modifier is <kbd>Command</kbd> key.
>                   <li>Move focus back to test application
> 
>                   <ul style="margin-bottom: 0">
>                     <li>Test <i>CheckBox</i> states with Screen Magnifier
>                       <ol style="list-style-type: lower-alpha; margin-top: 0; margin-bottom: 0">
>                         <li>Click on <i>CheckBox</i> to select it
>                         <li>Press the <kbd>Command</kbd> key and
>                             hover mouse over <i>CheckBox</i>
>                         <li>CheckBox ticked state along with its label should be magnified
>                         <li>Keep the <kbd>Command</kbd> key pressed and
>                             click <i>CheckBox</i> to deselect it
>                         <li>CheckBox unticked state along with its label should be magnified
>                         <li>Release the <kbd>Command</kbd> key
>                         <li>If Screen Magnifier behaviour is incorrect, press <b>Fail</b>
>                       </ol>
>                     <li>Test <i>ToggleButton</i> states with Screen Magnifier
>    ...

Updated test instructions for HTML style formatting. Thanks for the code snippet @aivanov-jdk

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1955540492

From prr at openjdk.org  Fri Feb 14 04:55:12 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 14 Feb 2025 04:55:12 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v4]
In-Reply-To: <FH_IfrJvUYeASaENDEa2tdahhsd6VUa9MFgOySIBIac=.d28b27f8-c5fd-406b-b1df-99b170e69ba2@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
 <FH_IfrJvUYeASaENDEa2tdahhsd6VUa9MFgOySIBIac=.d28b27f8-c5fd-406b-b1df-99b170e69ba2@github.com>
Message-ID: <jhz14jWG0VFeZq6X43kyDDq1fnD9OcIoRF81GDMonOY=.e19d98f7-a7a7-4318-8297-15ef5a31677a@github.com>

On Thu, 13 Feb 2025 11:55:53 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Filed as a separate issue to keep the #23426 clean.
>> 
>> Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)
>
> Alexander Zvegintsev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master
>  - move fix to spa/utils/endian.h
>  - merge "if defined"
>  - 8349751: AIX build failure after upgrade pipewire to 1.3.81
>  - replace "\t" with "    ", part 2
>  - replace "\t" with "    "
>  - 8348600: Update PipeWire to 1.3.81

FWIW
(1) I do not like JDK changes in upstream files we import
(2) This really needs to be done by the port owners.
(3) I do not like JDK changes in upstream files we import
Yes, I'm repeating that. We do have one case of changes which never made it into upstream in some X11 copied code from xwd because xwd is an app and doesn't care about resource leakage (ie there are upstream unfixed bugs). But I don't think we need to expand that precedent.
This change needs to be up-streamed. I do not want the burden of 'remembering' this.
Let's call this the last time we include this into JDK unless it comes from pipewire.

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

PR Review: https://git.openjdk.org/jdk/pull/23543#pullrequestreview-2616757880

From mdoerr at openjdk.org  Fri Feb 14 10:11:15 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 14 Feb 2025 10:11:15 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v4]
In-Reply-To: <FH_IfrJvUYeASaENDEa2tdahhsd6VUa9MFgOySIBIac=.d28b27f8-c5fd-406b-b1df-99b170e69ba2@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
 <FH_IfrJvUYeASaENDEa2tdahhsd6VUa9MFgOySIBIac=.d28b27f8-c5fd-406b-b1df-99b170e69ba2@github.com>
Message-ID: <L-AALXcEMBmtZFbM0_Jle0NFcHtz6Tg7dk7DectyhMo=.cb060b5b-214d-4a42-adc5-d61b79fbd71a@github.com>

On Thu, 13 Feb 2025 11:55:53 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Filed as a separate issue to keep the #23426 clean.
>> 
>> Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)
>
> Alexander Zvegintsev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master
>  - move fix to spa/utils/endian.h
>  - merge "if defined"
>  - 8349751: AIX build failure after upgrade pipewire to 1.3.81
>  - replace "\t" with "    ", part 2
>  - replace "\t" with "    "
>  - 8348600: Update PipeWire to 1.3.81

LGTM. Thanks for fixing it! I agree, we should try to get it into the upstream pipewire. For now, fixing the build is urgent.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23543#pullrequestreview-2617321044

From azvegint at openjdk.org  Fri Feb 14 12:58:19 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 14 Feb 2025 12:58:19 GMT
Subject: Integrated: 8349751: AIX build failure after upgrade pipewire to
 1.3.81
In-Reply-To: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
Message-ID: <I9Tso00ciYPSvSrDLDk61sUKbxBDQJQh88pgSJYraKc=.6173579c-7cf1-4697-a4ca-dfaa8d3629e5@github.com>

On Mon, 10 Feb 2025 19:07:49 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Filed as a separate issue to keep the #23426 clean.
> 
> Fix is the same as in the `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)

This pull request has now been integrated.

Changeset: 19c0ce43
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19c0ce43e258d00d77314d76a361feb2069a5af1
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8349751: AIX build failure after upgrade pipewire to 1.3.81

Reviewed-by: mdoerr

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

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

From duke at openjdk.org  Fri Feb 14 13:57:26 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Feb 2025 13:57:26 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
Message-ID: <CVlS9XD1J6P5InMvqrkoWiiNB2Fu9hxVajReUkg-EoQ=.0bdf7b6f-45fb-41b8-bbbe-bd222e8ef1c0@github.com>

On Sun, 9 Feb 2025 19:56:48 GMT, anass baya <duke at openjdk.org> wrote:

>> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
>> 
>> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
>> 
>> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
>> 
>> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.
>
> anass baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add proposed enhancments

@anass-baya 
Your change (at version 95750a44ec67f2c10c91ba69f3da1556964c5853) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23449#issuecomment-2659397688

From aivanov at openjdk.org  Fri Feb 14 15:18:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 14 Feb 2025 15:18:15 GMT
Subject: RFR: 8349351 : Combine Screen Inset Tests into a Single File [v2]
In-Reply-To: <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
 <cEzTJNk8yawD5ZiguFDW1Ddu7Ox9Tpi_5C56ReSFu7E=.6421d333-ee19-4405-8dd8-9499a8d786b2@github.com>
Message-ID: <bWpF0hkcUawH7U68qQohnc3x8qbAK7UaiVyOLumNP4U=.0d233b17-4eb3-4bca-8ab6-71ba8d9d4d11@github.com>

On Sun, 9 Feb 2025 19:56:48 GMT, anass baya <duke at openjdk.org> wrote:

>> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
>> 
>> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
>> 
>> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
>> 
>> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.
>
> anass baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add proposed enhancments

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23449#pullrequestreview-2618077111

From duke at openjdk.org  Fri Feb 14 15:22:21 2025
From: duke at openjdk.org (anass baya)
Date: Fri, 14 Feb 2025 15:22:21 GMT
Subject: Integrated: 8349351 : Combine Screen Inset Tests into a Single File
In-Reply-To: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
References: <IcuIXABZIwsaXXZAffSo9b5Vd_vSiySDCIzlexWr73E=.200d9c00-388c-4d03-b996-9280ac7537b1@github.com>
Message-ID: <xQ-oIG8McfIfURD7x0XIihX-7OvbyCPsrfEo7flmBAw=.e957dfaf-6cd0-495c-b6cc-30175e587aa3@github.com>

On Tue, 4 Feb 2025 20:26:45 GMT, anass baya <duke at openjdk.org> wrote:

> While working on [JDK-6899304](https://bugs.openjdk.org/browse/JDK-6899304), we discovered that there are two tests meant to perform the same task.
> 
> The first test is located at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java and was originally designed for multi-screen configurations on Linux platforms.
> 
> The second test, located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java, is intended for single-screen configurations but lacks accuracy due to some workarounds to support Windows.
> 
> Now, the test at test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java has been updated to work across all platforms, including Windows, which was previously failing. As a result, it has been agreed to rename this test to ScreenInsetsTest, remove the condition that restricted its execution to multi-screen configurations, and remove the redundant test at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java.

This pull request has now been integrated.

Changeset: 9ea81d90
Author:    anass baya <anass.baya at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9ea81d90175c11460d0efa83f82ceccc4ee2cd3b
Stats:     209 lines in 2 files changed: 16 ins; 143 del; 50 mod

8349351: Combine Screen Inset Tests into a Single File

Reviewed-by: honkar, dnguyen, aivanov

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

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

From mdoerr at openjdk.org  Fri Feb 14 16:28:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 14 Feb 2025 16:28:22 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v4]
In-Reply-To: <jhz14jWG0VFeZq6X43kyDDq1fnD9OcIoRF81GDMonOY=.e19d98f7-a7a7-4318-8297-15ef5a31677a@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
 <FH_IfrJvUYeASaENDEa2tdahhsd6VUa9MFgOySIBIac=.d28b27f8-c5fd-406b-b1df-99b170e69ba2@github.com>
 <jhz14jWG0VFeZq6X43kyDDq1fnD9OcIoRF81GDMonOY=.e19d98f7-a7a7-4318-8297-15ef5a31677a@github.com>
Message-ID: <ps3xN9KnlxF1asIADUKMA4-TMW8mYpqKTdzn7E9rulk=.ca008ba5-0cc4-4fee-819e-220514491571@github.com>

On Fri, 14 Feb 2025 04:52:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master
>>  - move fix to spa/utils/endian.h
>>  - merge "if defined"
>>  - 8349751: AIX build failure after upgrade pipewire to 1.3.81
>>  - replace "\t" with "    ", part 2
>>  - replace "\t" with "    "
>>  - 8348600: Update PipeWire to 1.3.81
>
> FWIW
> (1) I do not like JDK changes in upstream files we import
> (2) This really needs to be done by the port owners.
> (3) I do not like JDK changes in upstream files we import
> Yes, I'm repeating that. We do have one case of changes which never made it into upstream in some X11 copied code from xwd because xwd is an app and doesn't care about resource leakage (ie there are upstream unfixed bugs). But I don't think we need to expand that precedent.
> This change needs to be up-streamed. I do not want the burden of 'remembering' this.
> Let's call this the last time we include this into JDK unless it comes from pipewire.

@prrace: I wonder if pipewire should be build on any platform other than linux. Is there any usage on other UNIX systems (AIX/BSD/...)?

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

PR Comment: https://git.openjdk.org/jdk/pull/23543#issuecomment-2659766360

From bpb at openjdk.org  Fri Feb 14 17:37:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Feb 2025 17:37:14 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <gJe9XEjgvVERbkblprJyjaISu-FT-CcCWUBXftF90ow=.f9a1ac3a-794d-41ed-bc66-8990706338c2@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <gJe9XEjgvVERbkblprJyjaISu-FT-CcCWUBXftF90ow=.f9a1ac3a-794d-41ed-bc66-8990706338c2@github.com>
Message-ID: <StBjShoCDqYHka2087S2L3e5Zv6LKfIHSatMlcXT6XE=.a205db13-cb32-4cdd-a5db-ef61d4c2adfe@github.com>

On Thu, 13 Feb 2025 20:50:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8160327: fixing typo so `thumbnailPos` can be zero
>>   
>>   The `thumbnailLength` cannot be zero, but the position can be.
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 165:
> 
>> 163:                 ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN);
>> 164:         if (input.readUnsignedShort() != TIFF_MAGIC) {
>> 165:             throw new IllegalArgumentException("Bad magic number");
> 
> Where does this exception end up ? I would have supposed that if there's an Exif segment we don't like it would be best to just act like the segment isn't there.

I concur.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1956505245

From bpb at openjdk.org  Fri Feb 14 17:55:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Feb 2025 17:55:12 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <0kZHkkntWQQ-Hpn2oCBvUm3Cvk-Liy44V0hyuSliFlo=.74b6b03e-45a9-4ca3-8883-5f08443aa9c5@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

> In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property [...].

Note that the `DateTime` value extracted by `ExifMarkerSegment.getImageCreationTime` is that of the primary image, not the thumbnail. This is included to support the `ImageCreationTime` element of the Image I/O Standard Metadata Format Specification `javax_imageio_1.0`.

For reference see the [Exif 3.0 specification](https://iptc.org/news/exif-3-0-released-featuring-utf-8-support), although the code from 2016 was based on Exif 2.x. The sections most pertinent to thumbnails are:

- 4.5.8 Basic Structure of Thumbnail Data
- 4.6.9.2 Thumbnail (1st IFD) Support Levels

>From section 4.6.9.2 in particular, there does not appear to be any thumbnail-specific metadata worth extracting.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2659934595
PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2659938631

From bpb at openjdk.org  Fri Feb 14 18:01:24 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Feb 2025 18:01:24 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <LEGQKyhOyLNjeVw59HcFQ-iU4rnM_wY_XrMybQFmCQA=.c1df22ce-f4bc-45f2-ac61-f1c54fbd4435@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

For test image preparation, [exiftool](https://exiftool.org/) might prove useful. For example, to extract a thumbnail from an Exif image:

`exiftool -b -ThumbnailImage image.jpg > thumb.jpg`
 
To embed a thumbnail:

`exiftool "-thumbnailimage<=thumb.jpg" image.jpg`

Unfortunately, it refuses to embed a PNG thumbnail in a file where the primary image is compressed, which would be useful to generate an Exif sample with a compressed primary image but an uncompressed thumbnail.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2659948576

From honkar at openjdk.org  Fri Feb 14 19:34:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 14 Feb 2025 19:34:11 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v3]
In-Reply-To: <wwyUyZFV-5p6OPXpKCw9qhfY_BTQDzIgLXNOXZ_3ztY=.3b427d9a-e577-415d-8d5c-cd296be1a844@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <wwyUyZFV-5p6OPXpKCw9qhfY_BTQDzIgLXNOXZ_3ztY=.3b427d9a-e577-415d-8d5c-cd296be1a844@github.com>
Message-ID: <_Cax12ly2kfEwOf-f8aDLasXJY_EauO08ITSJTj9f5s=.e0614ca7-c601-44c4-a678-1592459aaef0@github.com>

On Tue, 11 Feb 2025 19:16:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>> 
>> CI testing is green on all platforms.
>
> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Change fix to use isShowing. Update test to auto.

Automated test looks good. Tested on Windows and Ubuntu, fix works as expected.

Minor suggestions provided inline.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1616:

> 1614:                 ((Timer)e.getSource()).stop();
> 1615:                 buttonListener.handledEvent = false;
> 1616:                 scrollbar.setValueIsAdjusting(false);

scrollbar.setValueIsAdjusting() is actually used for scroll thumb drag.
Not sure why it is also used on Ln# 1612, but no harm in resetting it to false.

test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 81:

> 79: 
> 80:     static Rectangle getOnScreenBoundsOnEDT(Component component)
> 81:             throws InterruptedException, TimeoutException, ExecutionException {

Suggestion:

            throws Exception {

test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 92:

> 90:     private static int getScrollbarValue()
> 91:             throws InterruptedException, InvocationTargetException,
> 92:             ExecutionException, TimeoutException {

Can be simplified to throw generic exception 
Suggestion:

            throws Exception {

test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 155:

> 153:         }
> 154:     }
> 155: }

EOF new line missing here

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23451#pullrequestreview-2618614251
PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1956621302
PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1956612535
PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1956612263
PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1956610978

From honkar at openjdk.org  Fri Feb 14 19:34:13 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 14 Feb 2025 19:34:13 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v3]
In-Reply-To: <cjceAWD-4G1pKD6RtJ2EtSoa4oe6N_NFBGcjqi0wB8I=.7fd5aa65-286b-4a35-a216-d5a2af79ddb8@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <oTIP5COO9ALrpDyKjdU48p7izMn_QemI5UXjEKTGumo=.675f15b6-5244-4654-976b-3b445a98329b@github.com>
 <cjceAWD-4G1pKD6RtJ2EtSoa4oe6N_NFBGcjqi0wB8I=.7fd5aa65-286b-4a35-a216-d5a2af79ddb8@github.com>
Message-ID: <i5sKiqXIe5yQPZBL05Yy4yZq11coSqL4zj3xMk4yvS0=.0252bb89-0a38-4b6b-8c52-3be69dd559e2@github.com>

On Tue, 11 Feb 2025 19:10:55 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1620:
>> 
>>> 1618:             do {
>>> 1619:                 // If application isn't in focus, stop the timer
>>> 1620:                 if (focusOwner == null) {
>> 
>> if (!scrollbar.isShowing()) {
>>           ((Timer)e.getSource()).stop();
>>           buttonListener.handledEvent = false;
>>           scrollbar.setValueIsAdjusting(false);
>>           return;
>>       }
>> 
>> 
>> I haven't tested this solution well, but you can try to stop the timer when the scrollbar is not showing(before entering the `do` loop)
>
> Tested this solution locally and in CI. Seems to work well. Clientlibs passes and the updated, automatic test also passes on all related platforms. Updated the PR. Thanks for providing the automated test and suggested change.

I agree, `!scrollbar.isShowing()` is a better condition to check for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1956629137

From bpb at openjdk.org  Fri Feb 14 19:40:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Feb 2025 19:40:14 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <s9eaFEw1SsaBNnWWdE0FFt9ExZA5vRf3TUbvyJrR2EM=.02b8dae5-e47a-45f0-aa69-7d6c3ec1a6d5@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 1653:

> 1651:             if (exifMarkerSegment != null
> 1652:                     && exifMarkerSegment.getNumThumbnails() == 1) {
> 1653:                 return 1;

I know that my original code was also like this, but I think the eventual intent was to read both JFIF (APP0) and Exif (APP1) thumbnails if both are present. In such a case, the thumbnail count would be 2, the JFIF thumbnail would be at index 0, and the Exif thumbnail at index 1.

In general I would expect that if both of these thumbnails were present, then they would be identical. If this were not the case, however, then preferring the Exif thumbnail would be a behavioral change. This is not necessarily a blocker for the current PR, but it might need to be addressed later.

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 1758:

> 1756:             }
> 1757: 
> 1758:             // Now we know that there is a jfif segment and that iis is good

I think `iis` should be `it` in this comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1956635292
PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1956634835

From honkar at openjdk.org  Fri Feb 14 19:40:16 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 14 Feb 2025 19:40:16 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v3]
In-Reply-To: <cjceAWD-4G1pKD6RtJ2EtSoa4oe6N_NFBGcjqi0wB8I=.7fd5aa65-286b-4a35-a216-d5a2af79ddb8@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <oTIP5COO9ALrpDyKjdU48p7izMn_QemI5UXjEKTGumo=.675f15b6-5244-4654-976b-3b445a98329b@github.com>
 <cjceAWD-4G1pKD6RtJ2EtSoa4oe6N_NFBGcjqi0wB8I=.7fd5aa65-286b-4a35-a216-d5a2af79ddb8@github.com>
Message-ID: <0petTMcldNyMr7YpBr-j0HY5fzIOZybLTjoJ0OF8IG4=.010542c8-b14c-4bc9-a83c-ded1a95ede09@github.com>

On Tue, 11 Feb 2025 19:10:55 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1620:
>> 
>>> 1618:             do {
>>> 1619:                 // If application isn't in focus, stop the timer
>>> 1620:                 if (focusOwner == null) {
>> 
>> if (!scrollbar.isShowing()) {
>>           ((Timer)e.getSource()).stop();
>>           buttonListener.handledEvent = false;
>>           scrollbar.setValueIsAdjusting(false);
>>           return;
>>       }
>> 
>> 
>> I haven't tested this solution well, but you can try to stop the timer when the scrollbar is not showing(before entering the `do` loop)
>
> Tested this solution locally and in CI. Seems to work well. Clientlibs passes and the updated, automatic test also passes on all related platforms. Updated the PR. Thanks for providing the automated test and suggested change.

@DamonGuy Probably a good idea to add @azvegint as co-author to give credit for the fix and automated test suggestions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1956633741

From dnguyen at openjdk.org  Fri Feb 14 20:20:27 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 14 Feb 2025 20:20:27 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v4]
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <XYqE7VAKi6t8awYH1cRY34LDiAzT4_EOY0DR6kz8G5Y=.f83ff6ce-3aa9-46cc-a7e6-c44df50268b3@github.com>

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23451/files
  - new: https://git.openjdk.org/jdk/pull/23451/files/5e4f3124..3a7bf130

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

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

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

From dnguyen at openjdk.org  Fri Feb 14 20:20:27 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 14 Feb 2025 20:20:27 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v4]
In-Reply-To: <0petTMcldNyMr7YpBr-j0HY5fzIOZybLTjoJ0OF8IG4=.010542c8-b14c-4bc9-a83c-ded1a95ede09@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <oTIP5COO9ALrpDyKjdU48p7izMn_QemI5UXjEKTGumo=.675f15b6-5244-4654-976b-3b445a98329b@github.com>
 <cjceAWD-4G1pKD6RtJ2EtSoa4oe6N_NFBGcjqi0wB8I=.7fd5aa65-286b-4a35-a216-d5a2af79ddb8@github.com>
 <0petTMcldNyMr7YpBr-j0HY5fzIOZybLTjoJ0OF8IG4=.010542c8-b14c-4bc9-a83c-ded1a95ede09@github.com>
Message-ID: <0WurZlk1UQNtdrzX8XlUn84pwA4y24hvvz6_-43A8-U=.f23b188f-8d6b-464c-9d89-a58b55c82e70@github.com>

On Fri, 14 Feb 2025 19:35:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tested this solution locally and in CI. Seems to work well. Clientlibs passes and the updated, automatic test also passes on all related platforms. Updated the PR. Thanks for providing the automated test and suggested change.
>
> @DamonGuy Probably a good idea to add @azvegint as co-author to give credit for the fix and automated test suggestions.

Yep! Good reminder. Was going to do so.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1956671905

From dgredler at openjdk.org  Fri Feb 14 20:33:26 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 14 Feb 2025 20:33:26 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v2]
In-Reply-To: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
Message-ID: <GE04jcZw1ngsKTFuscpTdXo1cJUxEBTl2CwbNd8MBr4=.be5f47db-7611-4698-a736-7fb28d1bcfd3@github.com>

> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
> 
> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
> 
> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
> 
> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
> 
> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html

Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision:

 - Add max width wiggle room for mac
 - When HarfBuzz omits glyphs, assume zero advance (not early line break)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23603/files
  - new: https://git.openjdk.org/jdk/pull/23603/files/99eb1b3b..16143307

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

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

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

From prr at openjdk.org  Fri Feb 14 20:43:09 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 14 Feb 2025 20:43:09 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands
In-Reply-To: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
Message-ID: <XGUCtWzlkT4_1G1AhhQfXLcRcK5c_lN0482w892EgN0=.197869a8-c653-41ad-b138-2df44dc6d05c@github.com>

On Wed, 12 Feb 2025 19:32:31 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
> 
> Two methods are impacted:
> 
> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
> 
> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
> 
> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
> 
> A test case is included.

The new test failed on Windows
java.lang.RuntimeException: Expected 1 path, but found 0 paths
	at PostScriptLeanTest.main(PostScriptLeanTest.java:80)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

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

PR Comment: https://git.openjdk.org/jdk/pull/23595#issuecomment-2660224301

From dgredler at openjdk.org  Fri Feb 14 20:46:10 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 14 Feb 2025 20:46:10 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters
In-Reply-To: <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
Message-ID: <8heY2PXXn-5CCRC6gJ01ItNekmtiVw2zwrXmOLNDSwc=.30a8d9cd-bf77-49d2-97c9-5ff3db25a1f5@github.com>

On Fri, 14 Feb 2025 00:04:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Early days but the test fails on macOS
> Exception in thread "main" java.lang.RuntimeException: nextOffset 1 for char 00ad using font Dialog: 2 != 1
> 	at FormatCharAdvanceTest.assertEqual(FormatCharAdvanceTest.java:289)
> 	at FormatCharAdvanceTest.testChar(FormatCharAdvanceTest.java:282)
> 	at FormatCharAdvanceTest.testChars(FormatCharAdvanceTest.java:165)
> 	at FormatCharAdvanceTest.main(FormatCharAdvanceTest.java:154)

@prrace Two findings here:

First, it looks like macOS needs an extra pixel of wiggle room in the max string width that we measure; I've given it two pixels, just to be extra sure that the test is stable.

Second, the combination of (macOS Dialog font + chars U+200F or U+2067) has HarfBuzz removing the zero-width chars instead of replacing them with the invisible glyph. I think it has something to do with the font tables in that specific macOS font. It looks like in this scenario `ExtendedTextSourceLabel.getLineBreakIndex(int, float)` was communicating an early line break to the caller, rather than assuming that the shaper omitted or combined glyphs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2660227145

From achung at openjdk.org  Fri Feb 14 20:50:57 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 14 Feb 2025 20:50:57 GMT
Subject: RFR: 8348596: Update FreeType to 2.13.3
Message-ID: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>

Upgrading freetype 3rd party tool to newest update

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

Commit messages:
 - freetype upgrade

Changes: https://git.openjdk.org/jdk/pull/23649/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348596
  Stats: 3813 lines in 281 files changed: 1011 ins; 1649 del; 1153 mod
  Patch: https://git.openjdk.org/jdk/pull/23649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23649/head:pull/23649

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

From bpb at openjdk.org  Fri Feb 14 21:11:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Feb 2025 21:11:13 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <4H625H7VLnKi914MoDgvmj9MZYk-BpEBEKOASIGSZmg=.a48e81a7-22f7-4413-8dda-bbd2ab29fc65@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 28:

> 26: package com.sun.imageio.plugins.jpeg;
> 27: 
> 28: import java.io.InputStream;

I suggest putting the imports on lines 28-51 in alphabetical order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1956718373

From honkar at openjdk.org  Fri Feb 14 21:29:16 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 14 Feb 2025 21:29:16 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v4]
In-Reply-To: <XYqE7VAKi6t8awYH1cRY34LDiAzT4_EOY0DR6kz8G5Y=.f83ff6ce-3aa9-46cc-a7e6-c44df50268b3@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <XYqE7VAKi6t8awYH1cRY34LDiAzT4_EOY0DR6kz8G5Y=.f83ff6ce-3aa9-46cc-a7e6-c44df50268b3@github.com>
Message-ID: <mzDAotY0FMdT6onLSpV2Td0IXo4_awSFiSOG-UmDsuc=.2c9255d7-8d03-4fca-8be0-0006ded95500@github.com>

On Fri, 14 Feb 2025 20:20:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>> 
>> CI testing is green on all platforms.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23451#pullrequestreview-2618835140

From prr at openjdk.org  Fri Feb 14 21:45:12 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 14 Feb 2025 21:45:12 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <s9eaFEw1SsaBNnWWdE0FFt9ExZA5vRf3TUbvyJrR2EM=.02b8dae5-e47a-45f0-aa69-7d6c3ec1a6d5@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <s9eaFEw1SsaBNnWWdE0FFt9ExZA5vRf3TUbvyJrR2EM=.02b8dae5-e47a-45f0-aa69-7d6c3ec1a6d5@github.com>
Message-ID: <_yMP6dnmDEc-ZIt0JfHpcCYCAwJz9KhZsdi5URkWHb0=.0528528c-06f1-4a6d-8e8f-45aa15b89043@github.com>

On Fri, 14 Feb 2025 19:37:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8160327: fixing typo so `thumbnailPos` can be zero
>>   
>>   The `thumbnailLength` cannot be zero, but the position can be.
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 1653:
> 
>> 1651:             if (exifMarkerSegment != null
>> 1652:                     && exifMarkerSegment.getNumThumbnails() == 1) {
>> 1653:                 return 1;
> 
> I know that my original code was also like this, but I think the eventual intent was to read both JFIF (APP0) and Exif (APP1) thumbnails if both are present. In such a case, the thumbnail count would be 2, the JFIF thumbnail would be at index 0, and the Exif thumbnail at index 1.
> 
> In general I would expect that if both of these thumbnails were present, then they would be identical. If this were not the case, however, then preferring the Exif thumbnail would be a behavioral change. This is not necessarily a blocker for the current PR, but it might need to be addressed later.

Hmm. I think it better to address it now. Who knows when we'd get back to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1956750727

From bpb at openjdk.org  Fri Feb 14 21:45:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 14 Feb 2025 21:45:13 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <EkUZvOPoqVKWP-DmUk1_77lpGoP6LVPbli6EsgJV-WQ=.174e86f8-5c37-4f13-876c-5b6e7415dd2a@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java line 266:

> 264:                         && (buf[ptr+7] == 0)
> 265:                         && (buf[ptr+8] == 0)) {
> 266:                     newGuy = new ExifMarkerSegment(buffer);

The `IllegalArgumentException` from the `ExifMarkerSegment` constructor should be handled somehow. Perhaps just fall back to setting `newGuy` to a plain `MarkerSegment`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1956751427

From mickleness at gmail.com  Fri Feb 14 21:59:43 2025
From: mickleness at gmail.com (Jeremy Wood)
Date: Fri, 14 Feb 2025 21:59:43 +0000
Subject: Reading Frames from a GIF file
Message-ID: <em657b5604-dfdf-4d4d-b995-4cac0c82c9d5@55b786e1.com>

I have a generic question for the group. I?m trying to implement a 
method resembling:

public BufferedImage seek(File gifFile, int millis)

Ideally I?d like to:
1. Not add a 3rd party jar to our class path
2. Not write a new file
3. Not load the entire gif file into memory as a byte array
4. Use well-tested/stable code to handle gif frame disposal, custom 
color palettes, and any other obscure gif parsing challenges.

ImageIO doesn?t really work without a lot of intervention. It can return 
the individual frames of a GIF, but it becomes the caller?s 
responsibility to handle frame disposal/placement.

So I tried working with ToolkitImages. What I wrote (see below) 
functionally works, but it?s not an acceptable solution because it?s too 
slow. The problem now is sun.awt.image.GifImageDecoder calls 
Thread.sleep(delay). So it acts more like a player than a parser. If my 
gif file contains 10 one-second frames, then this code takes at least 9 
seconds.

This feels way too hard for such a simple ask. Is there a solution / 
toolset I?m missing? All the code I need already exists in the desktop 
module, but I seem unable to leverage it.

Regards,
  - Jeremy

???
import javax.imageio.ImageIO;
import javax.imageio.ImageReader;
import javax.imageio.metadata.IIOMetadataNode;
import java.awt.*;
import java.awt.image.*;
import java.io.*;
import java.util.ArrayList;
import java.util.Hashtable;
import java.util.Objects;
import java.util.List;
import java.util.concurrent.Semaphore;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicReference;

/**
  * This uses a combination of java.awt.Image classes and ImageIO classes
  * to convert a GIF image to a series of frames.
  */
public class GifReader {

public enum FrameConsumerResult {
         CONTINUE, STOP, SKIP
     }

public final static class Info {
public final int width, height, numberOfFrames, duration;
public final boolean isLooping;

public Info(int width, int height, int numberOfFrames, int duration, boolean isLooping) {
this.width = width;
this.height = height;
this.numberOfFrames = numberOfFrames;
this.duration = duration;
this.isLooping = isLooping;
         }
     }

/**
      * Consumes information about the frames of a GIF animation.
      */
public interface GifFrameConsumer {
/**
          * This provides meta information about a GIF image.
          *
          * @return true if the reader should start supplying frame data, or false if this meta information
          * is all the consumer wanted.
          */
boolean startImage(int imageWidth, int imageHeight, int numberOfFrames, int durationMillis, boolean isLooping);

/**
          * @param frameIndex the frame index (starting at 0)
          * @param numberOfFrames the total number of frames in the GIF image.
          * @param startTimeMillis the start time of this frame (relative to the start time of the animation)
          * @param durationMillis the duration of this frame
          * @return if this returns CONTINUE then this consumer expects {@link #consumeFrame(BufferedImage, int, int, int, int, boolean)}
          * to be called next. If this returns STOP then this consumer expects to stop all reading. If this returns SKIP
          * then this consumer is not interested in this frame, but it expects to be asked about `frameIndex + 1`.
          */
default FrameConsumerResult startFrame(int frameIndex, int numberOfFrames, int startTimeMillis, int durationMillis) {
return FrameConsumerResult.CONTINUE;
         }

/**
          * Consume a new frame from a GIF image.
          *
          * @param frame an INT_ARGB image. This BufferedImage reference will be reused with each
          *              call to this method, so if you want to keep these images in memory you
          *              need to clone this image.
          * @param startTimeMillis the start time of this frame (relative to the start time of the animation)
          * @param frameIndex the current frame index (starting at 0).
          * @param numberOfFrames the total number of frames in the GIF image.
          * @param frameDurationMillis the duration of this frame in milliseconds
          * @param isDone if true then this method will not be called again.
          * @return true if the reader should continue reading additional frames, or false if the reader should
          * immediately stop. This return value is ignored if `isDone` is true.
          */
boolean consumeFrame(BufferedImage frame, int startTimeMillis, int frameDurationMillis, int frameIndex, int numberOfFrames, boolean isDone);
     }

/**
      * Read a GIF image.
      *
      * @param gifFile the GIF image file to read.
      * @param waitUntilFinished if true then this method will not return until the GifFrameConsumer
      *                          has received every frame.
      * @param frameConsumer the consumer that will consume the image data.
      */
public void read(final File gifFile, final boolean waitUntilFinished, final GifFrameConsumer frameConsumer) throws IOException {
         Objects.requireNonNull(frameConsumer);
final Semaphore semaphore = new Semaphore(1);
         semaphore.acquireUninterruptibly();

try (FileInputStream gifFileIn = new FileInputStream(gifFile)) {
             List<Integer> frameDurationsMillis = readFrameDurationMillis(gifFileIn);
             Image image = Toolkit.getDefaultToolkit().createImage(gifFile.getPath());
             ImageConsumer consumer = new ImageConsumer() {
private BufferedImage bi;
private boolean isActive = true;
private int frameCtr, imageWidth, imageHeight, currentFrameStartTime;
private boolean ignoreCurrentFrame;

                 @Override
public void setDimensions(int width, int height) {
                     imageWidth = width;
                     imageHeight = height;

// if this gif loops:
                     // the sun.awt.image.GifImageDecoder calls ImageFetcher.startingAnimation, which
                     // changes the name of this thread. We don't know how many times it's supposed
                     // to loop, but in my experience gifs either don't loop at all or they loop forever;
                     // they aren't asked to loop N-many times anymore
boolean isLooping = Thread.currentThread().getName().contains("Image Animator");

try {
int totalDuration = 0;
for (int frameDuration : frameDurationsMillis)
                             totalDuration += frameDuration;

if (!frameConsumer.startImage(width, height, frameDurationsMillis.size(), totalDuration, isLooping))
                             stop(null);
                     } catch(Exception e) {
                         stop(e);
                     }
                 }

                 @Override
public void setProperties(Hashtable<?, ?> props) {}

                 @Override
public void setColorModel(ColorModel model) {}

                 @Override
public void setHints(int hintflags) {
// this is called before every frame starts:
int frameDuration = frameDurationsMillis.get(frameCtr);
                     FrameConsumerResult r = frameConsumer.startFrame(frameCtr, frameDurationsMillis.size(), currentFrameStartTime, frameDuration);
if (r == FrameConsumerResult.STOP) {
                         stop(null);
                     } else {
                         ignoreCurrentFrame = r == FrameConsumerResult.SKIP;
                     }
                 }

private int[] argbRow;
private int[] colorModelRGBs;
private IndexColorModel lastModel;

                 @Override
public void setPixels(final int x, final int y, final int w, final int h,
final ColorModel model, final byte[] pixels, final int off, final int scansize) {
// Even if ignoreCurrentFrame is true we still need to update the image every iteration.
                     // (This is because each frame in a GIF has a "disposal method", and some of them rely
                     // on the previous frame.) In theory we *may* be able to skip this method *sometimes*
                     // depending on the disposal methods in use, but that would take some more research.

try {
// ImageConsumer javadoc says:
                         // Pixel (m,n) is stored in the pixels array at index (n * scansize + m + off)

final int yMax = y + h;
final int xMax = x + w;

if (model instanceof IndexColorModel icm) {
if (icm != lastModel) {
                                 colorModelRGBs = new int[icm.getMapSize()];
                                 icm.getRGBs(colorModelRGBs);
                             }
                             lastModel = icm;
                         } else {
                             colorModelRGBs = null;
                         }

if (bi == null) {
                             bi = new BufferedImage(imageWidth, imageHeight, BufferedImage.TYPE_INT_ARGB);
                             argbRow = new int[imageWidth];
                         }

for (int y_ = y; y_ < yMax; y_++) {
// we're not told to use (off-x), but empirically this is what we get/need:
int i = y_ * scansize + x + (off - x);
for (int x_ = x; x_ < xMax; x_++, i++) {
int pixel = pixels[i] & 0xff;
if (colorModelRGBs != null) {
                                     argbRow[x_ - x] = colorModelRGBs[pixel];
                                 } else {
// I don't think we ever resort to this:
argbRow[x_ - x] = 0xff000000 + (model.getRed(pixel) << 16) + (model.getGreen(pixel) << 8) + (model.getBlue(pixel));
                                 }
                             }
                             bi.getRaster().setDataElements(x, y_, w, 1, argbRow);
                         }
                     } catch(RuntimeException e) {
// we don't expect this to happen, but if something goes wrong nobody else
                         // will print our stacktrace for us:
stop(e);
throw e;
                     }
                 }

                 @Override
public void setPixels(int x, int y, int w, int h, ColorModel model, int[] pixels, int off, int scansize) {
// we never expect this for a GIF image
throw new UnsupportedOperationException();
                 }

                 @Override
public void imageComplete(int status) {
try {
int numberOfFrames = frameDurationsMillis.size();
int frameDuration = frameDurationsMillis.get(frameCtr);
boolean consumeResult;
if (ignoreCurrentFrame) {
                             consumeResult = true;
                         } else {
                             consumeResult = frameConsumer.consumeFrame(bi, currentFrameStartTime, frameDuration,
                                     frameCtr, numberOfFrames, frameCtr + 1 >= numberOfFrames);
                         }
                         frameCtr++;
                         currentFrameStartTime += frameDuration;

// if we don't remove this ImageConsumer the animating thread will loop forever
if (frameCtr == numberOfFrames || !consumeResult)
                             stop(null);
                     } catch(Exception e) {
                         stop(e);
                     }
                 }

private void stop(Exception e) {
synchronized (this) {
if (!isActive)
return;
                         isActive = false;
                     }
if (e != null)
                         e.printStackTrace();
                     image.getSource().removeConsumer(this);
                     image.flush();
if (bi != null)
                         bi.flush();
                     semaphore.release();

                 }
             };
             image.getSource().startProduction(consumer);
         }
if (waitUntilFinished)
             semaphore.acquireUninterruptibly();
     }

/**
      * Return the frame at a given time in an animation.
      */
public BufferedImage seek(File gifFile, int millis) throws IOException {
         AtomicInteger seekTime = new AtomicInteger();
         AtomicReference<BufferedImage> returnValue = new AtomicReference<>();
         read(gifFile, true, new GifFrameConsumer() {
             @Override
public boolean startImage(int imageWidth, int imageHeight, int numberOfFrames, int durationMillis, boolean isLooping) {
                 seekTime.set(millis%durationMillis);
return true;
             }

             @Override
public FrameConsumerResult startFrame(int frameIndex, int numberOfFrames, int startTimeMillis, int durationMillis) {
if (numberOfFrames == 1 ||
                         (startTimeMillis <= seekTime.get() && seekTime.get() < startTimeMillis + durationMillis))
return FrameConsumerResult.CONTINUE;

if (startTimeMillis + durationMillis <= seekTime.get())
return FrameConsumerResult.SKIP;
return FrameConsumerResult.STOP;
             }

             @Override
public boolean consumeFrame(BufferedImage frame, int startTimeMillis, int frameDurationMillis, int frameIndex, int numberOfFrames, boolean isDone) {
                 returnValue.set(frame);
return false;
             }
         });
return returnValue.get();
     }

/**
      * Return basic information about a GIF image/animation.
      */
public Info getInfo(File gifFile) throws IOException {
         AtomicReference<Info> returnValue = new AtomicReference<>();
         read(gifFile, true, new GifFrameConsumer() {
             @Override
public boolean startImage(int imageWidth, int imageHeight, int numberOfFrames, int durationMillis, boolean isLooping) {
                 returnValue.set(new Info(imageWidth, imageHeight, numberOfFrames, durationMillis, isLooping));
return false;
             }

             @Override
public boolean consumeFrame(BufferedImage frame, int startTimeMillis, int frameDurationMillis, int frameIndex, int numberOfFrames, boolean isDone) {
return false;
             }
         });
return returnValue.get();
     }

/**
      * Read the frame durations of a gif. This relies on ImageIO classes.
      */
private List<Integer> readFrameDurationMillis(InputStream stream) throws IOException {
         ImageReader reader = ImageIO.getImageReadersByFormatName("gif").next();
try {
             reader.setInput(ImageIO.createImageInputStream(stream));
int frameCount = reader.getNumImages(true);
             List<Integer> frameDurations = new ArrayList<>(frameCount);
for (int frameIndex = 0; frameIndex < frameCount; frameIndex++) {
                 IIOMetadataNode root = (IIOMetadataNode) reader.getImageMetadata(frameIndex).getAsTree("javax_imageio_gif_image_1.0");
                 IIOMetadataNode gce = (IIOMetadataNode) root.getElementsByTagName("GraphicControlExtension").item(0);
int delay = Integer.parseInt(gce.getAttribute("delayTime"));
                 frameDurations.add( delay * 10 );
             }
return frameDurations;
         } finally {
             reader.dispose();
         }
     }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250214/78ded9e7/attachment-0001.htm>

From davidalayachew at gmail.com  Fri Feb 14 22:57:10 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 14 Feb 2025 17:57:10 -0500
Subject: Reading Frames from a GIF file
In-Reply-To: <em657b5604-dfdf-4d4d-b995-4cac0c82c9d5@55b786e1.com>
References: <em657b5604-dfdf-4d4d-b995-4cac0c82c9d5@55b786e1.com>
Message-ID: <CAA9v-_OONWgYW_Qzz=+CfTvLpWMpH8t23u5QXGBV6NkdzeYQMw@mail.gmail.com>

Hey Jeremy,

Yeah, that's not even close to the performance that Java is capable of.

If you want to see something that is used in Production using only Java
code, look at iCafe. The code is all open source, and I know it can do what
you are trying to do because I did it too. It'll give you an idea of what
is going wrong here.

On Fri, Feb 14, 2025, 5:04?PM Jeremy Wood <mickleness at gmail.com> wrote:

> I have a generic question for the group. I?m trying to implement a method
> resembling:
>
> public BufferedImage seek(File gifFile, int millis)
>
> Ideally I?d like to:
> 1. Not add a 3rd party jar to our class path
> 2. Not write a new file
> 3. Not load the entire gif file into memory as a byte array
> 4. Use well-tested/stable code to handle gif frame disposal, custom color
> palettes, and any other obscure gif parsing challenges.
>
> ImageIO doesn?t really work without a lot of intervention. It can return
> the individual frames of a GIF, but it becomes the caller?s responsibility
> to handle frame disposal/placement.
>
> So I tried working with ToolkitImages. What I wrote (see below)
> functionally works, but it?s not an acceptable solution because it?s too
> slow. The problem now is sun.awt.image.GifImageDecoder calls
> Thread.sleep(delay). So it acts more like a player than a parser. If my gif
> file contains 10 one-second frames, then this code takes at least 9 seconds.
>
> This feels way too hard for such a simple ask. Is there a solution /
> toolset I?m missing? All the code I need already exists in the desktop
> module, but I seem unable to leverage it.
>
> Regards,
>  - Jeremy
>
> ???
>
> import javax.imageio.ImageIO;
> import javax.imageio.ImageReader;
> import javax.imageio.metadata.IIOMetadataNode;
> import java.awt.*;
> import java.awt.image.*;
> import java.io.*;
> import java.util.ArrayList;
> import java.util.Hashtable;
> import java.util.Objects;
> import java.util.List;
> import java.util.concurrent.Semaphore;
> import java.util.concurrent.atomic.AtomicInteger;
> import java.util.concurrent.atomic.AtomicReference;
>
> /**
>  * This uses a combination of java.awt.Image classes and ImageIO classes
>  * to convert a GIF image to a series of frames.
>  */
> public class GifReader {
>
>     public enum FrameConsumerResult {
>         CONTINUE, STOP, SKIP
>     }
>
>     public final static class Info {
>         public final int width, height, numberOfFrames, duration;
>         public final boolean isLooping;
>
>         public Info(int width, int height, int numberOfFrames, int duration, boolean isLooping) {
>             this.width = width;
>             this.height = height;
>             this.numberOfFrames = numberOfFrames;
>             this.duration = duration;
>             this.isLooping = isLooping;
>         }
>     }
>
>     /**
>      * Consumes information about the frames of a GIF animation.
>      */
>     public interface GifFrameConsumer {
>         /**
>          * This provides meta information about a GIF image.
>          *
>          * @return true if the reader should start supplying frame data, or false if this meta information
>          * is all the consumer wanted.
>          */
>         boolean startImage(int imageWidth, int imageHeight, int numberOfFrames, int durationMillis, boolean isLooping);
>
>         /**
>          * @param frameIndex the frame index (starting at 0)
>          * @param numberOfFrames the total number of frames in the GIF image.
>          * @param startTimeMillis the start time of this frame (relative to the start time of the animation)
>          * @param durationMillis the duration of this frame
>          * @return if this returns CONTINUE then this consumer expects {@link #consumeFrame(BufferedImage, int, int, int, int, boolean)}
>          * to be called next. If this returns STOP then this consumer expects to stop all reading. If this returns SKIP
>          * then this consumer is not interested in this frame, but it expects to be asked about `frameIndex + 1`.
>          */
>         default FrameConsumerResult startFrame(int frameIndex, int numberOfFrames, int startTimeMillis, int durationMillis) {
>             return FrameConsumerResult.CONTINUE;
>         }
>
>         /**
>          * Consume a new frame from a GIF image.
>          *
>          * @param frame an INT_ARGB image. This BufferedImage reference will be reused with each
>          *              call to this method, so if you want to keep these images in memory you
>          *              need to clone this image.
>          * @param startTimeMillis the start time of this frame (relative to the start time of the animation)
>          * @param frameIndex the current frame index (starting at 0).
>          * @param numberOfFrames the total number of frames in the GIF image.
>          * @param frameDurationMillis the duration of this frame in milliseconds
>          * @param isDone if true then this method will not be called again.
>          * @return true if the reader should continue reading additional frames, or false if the reader should
>          * immediately stop. This return value is ignored if `isDone` is true.
>          */
>         boolean consumeFrame(BufferedImage frame, int startTimeMillis, int frameDurationMillis, int frameIndex, int numberOfFrames, boolean isDone);
>     }
>
>     /**
>      * Read a GIF image.
>      *
>      * @param gifFile the GIF image file to read.
>      * @param waitUntilFinished if true then this method will not return until the GifFrameConsumer
>      *                          has received every frame.
>      * @param frameConsumer the consumer that will consume the image data.
>      */
>     public void read(final File gifFile, final boolean waitUntilFinished, final GifFrameConsumer frameConsumer) throws IOException {
>         Objects.requireNonNull(frameConsumer);
>         final Semaphore semaphore = new Semaphore(1);
>         semaphore.acquireUninterruptibly();
>
>         try (FileInputStream gifFileIn = new FileInputStream(gifFile)) {
>             List<Integer> frameDurationsMillis = readFrameDurationMillis(gifFileIn);
>             Image image = Toolkit.getDefaultToolkit().createImage(gifFile.getPath());
>             ImageConsumer consumer = new ImageConsumer() {
>                 private BufferedImage bi;
>                 private boolean isActive = true;
>                 private int frameCtr, imageWidth, imageHeight, currentFrameStartTime;
>                 private boolean ignoreCurrentFrame;
>
>                 @Override
>                 public void setDimensions(int width, int height) {
>                     imageWidth = width;
>                     imageHeight = height;
>
>                     // if this gif loops:
>                     // the sun.awt.image.GifImageDecoder calls ImageFetcher.startingAnimation, which
>                     // changes the name of this thread. We don't know how many times it's supposed
>                     // to loop, but in my experience gifs either don't loop at all or they loop forever;
>                     // they aren't asked to loop N-many times anymore
>                     boolean isLooping = Thread.currentThread().getName().contains("Image Animator");
>
>                     try {
>                         int totalDuration = 0;
>                         for (int frameDuration : frameDurationsMillis)
>                             totalDuration += frameDuration;
>
>                         if (!frameConsumer.startImage(width, height, frameDurationsMillis.size(), totalDuration, isLooping))
>                             stop(null);
>                     } catch(Exception e) {
>                         stop(e);
>                     }
>                 }
>
>                 @Override
>                 public void setProperties(Hashtable<?, ?> props) {}
>
>                 @Override
>                 public void setColorModel(ColorModel model) {}
>
>                 @Override
>                 public void setHints(int hintflags) {
>                     // this is called before every frame starts:
>                     int frameDuration = frameDurationsMillis.get(frameCtr);
>                     FrameConsumerResult r = frameConsumer.startFrame(frameCtr, frameDurationsMillis.size(), currentFrameStartTime, frameDuration);
>                     if (r == FrameConsumerResult.STOP) {
>                         stop(null);
>                     } else {
>                         ignoreCurrentFrame = r == FrameConsumerResult.SKIP;
>                     }
>                 }
>
>                 private int[] argbRow;
>                 private int[] colorModelRGBs;
>                 private IndexColorModel lastModel;
>
>                 @Override
>                 public void setPixels(final int x, final int y, final int w, final int h,
>                                       final ColorModel model, final byte[] pixels, final int off, final int scansize) {
>                     // Even if ignoreCurrentFrame is true we still need to update the image every iteration.
>                     // (This is because each frame in a GIF has a "disposal method", and some of them rely
>                     // on the previous frame.) In theory we *may* be able to skip this method *sometimes*
>                     // depending on the disposal methods in use, but that would take some more research.
>
>                     try {
>                         // ImageConsumer javadoc says:
>                         // Pixel (m,n) is stored in the pixels array at index (n * scansize + m + off)
>
>                         final int yMax = y + h;
>                         final int xMax = x + w;
>
>                         if (model instanceof IndexColorModel icm) {
>                             if (icm != lastModel) {
>                                 colorModelRGBs = new int[icm.getMapSize()];
>                                 icm.getRGBs(colorModelRGBs);
>                             }
>                             lastModel = icm;
>                         } else {
>                             colorModelRGBs = null;
>                         }
>
>                         if (bi == null) {
>                             bi = new BufferedImage(imageWidth, imageHeight, BufferedImage.TYPE_INT_ARGB);
>                             argbRow = new int[imageWidth];
>                         }
>
>                         for (int y_ = y; y_ < yMax; y_++) {
>                             // we're not told to use (off-x), but empirically this is what we get/need:
>                             int i = y_ * scansize + x + (off - x);
>                             for (int x_ = x; x_ < xMax; x_++, i++) {
>                                 int pixel = pixels[i] & 0xff;
>                                 if (colorModelRGBs != null) {
>                                     argbRow[x_ - x] = colorModelRGBs[pixel];
>                                 } else {
>                                     // I don't think we ever resort to this:
>                                     argbRow[x_ - x] = 0xff000000 + (model.getRed(pixel) << 16) + (model.getGreen(pixel) << 8) + (model.getBlue(pixel));
>                                 }
>                             }
>                             bi.getRaster().setDataElements(x, y_, w, 1, argbRow);
>                         }
>                     } catch(RuntimeException e) {
>                         // we don't expect this to happen, but if something goes wrong nobody else
>                         // will print our stacktrace for us:
>                         stop(e);
>                         throw e;
>                     }
>                 }
>
>                 @Override
>                 public void setPixels(int x, int y, int w, int h, ColorModel model, int[] pixels, int off, int scansize) {
>                     // we never expect this for a GIF image
>                     throw new UnsupportedOperationException();
>                 }
>
>                 @Override
>                 public void imageComplete(int status) {
>                     try {
>                         int numberOfFrames = frameDurationsMillis.size();
>                         int frameDuration = frameDurationsMillis.get(frameCtr);
>                         boolean consumeResult;
>                         if (ignoreCurrentFrame) {
>                             consumeResult = true;
>                         } else {
>                             consumeResult = frameConsumer.consumeFrame(bi, currentFrameStartTime, frameDuration,
>                                     frameCtr, numberOfFrames, frameCtr + 1 >= numberOfFrames);
>                         }
>                         frameCtr++;
>                         currentFrameStartTime += frameDuration;
>
>                         // if we don't remove this ImageConsumer the animating thread will loop forever
>                         if (frameCtr == numberOfFrames || !consumeResult)
>                             stop(null);
>                     } catch(Exception e) {
>                         stop(e);
>                     }
>                 }
>
>                 private void stop(Exception e) {
>                     synchronized (this) {
>                         if (!isActive)
>                             return;
>                         isActive = false;
>                     }
>                     if (e != null)
>                         e.printStackTrace();
>                     image.getSource().removeConsumer(this);
>                     image.flush();
>                     if (bi != null)
>                         bi.flush();
>                     semaphore.release();
>
>                 }
>             };
>             image.getSource().startProduction(consumer);
>         }
>         if (waitUntilFinished)
>             semaphore.acquireUninterruptibly();
>     }
>
>     /**
>      * Return the frame at a given time in an animation.
>      */
>     public BufferedImage seek(File gifFile, int millis) throws IOException {
>         AtomicInteger seekTime = new AtomicInteger();
>         AtomicReference<BufferedImage> returnValue = new AtomicReference<>();
>         read(gifFile, true, new GifFrameConsumer() {
>             @Override
>             public boolean startImage(int imageWidth, int imageHeight, int numberOfFrames, int durationMillis, boolean isLooping) {
>                 seekTime.set(millis%durationMillis);
>                 return true;
>             }
>
>             @Override
>             public FrameConsumerResult startFrame(int frameIndex, int numberOfFrames, int startTimeMillis, int durationMillis) {
>                 if (numberOfFrames == 1 ||
>                         (startTimeMillis <= seekTime.get() && seekTime.get() < startTimeMillis + durationMillis))
>                     return FrameConsumerResult.CONTINUE;
>
>                 if (startTimeMillis + durationMillis <= seekTime.get())
>                     return FrameConsumerResult.SKIP;
>                 return FrameConsumerResult.STOP;
>             }
>
>             @Override
>             public boolean consumeFrame(BufferedImage frame, int startTimeMillis, int frameDurationMillis, int frameIndex, int numberOfFrames, boolean isDone) {
>                 returnValue.set(frame);
>                 return false;
>             }
>         });
>         return returnValue.get();
>     }
>
>     /**
>      * Return basic information about a GIF image/animation.
>      */
>     public Info getInfo(File gifFile) throws IOException {
>         AtomicReference<Info> returnValue = new AtomicReference<>();
>         read(gifFile, true, new GifFrameConsumer() {
>             @Override
>             public boolean startImage(int imageWidth, int imageHeight, int numberOfFrames, int durationMillis, boolean isLooping) {
>                 returnValue.set(new Info(imageWidth, imageHeight, numberOfFrames, durationMillis, isLooping));
>                 return false;
>             }
>
>             @Override
>             public boolean consumeFrame(BufferedImage frame, int startTimeMillis, int frameDurationMillis, int frameIndex, int numberOfFrames, boolean isDone) {
>                 return false;
>             }
>         });
>         return returnValue.get();
>     }
>
>     /**
>      * Read the frame durations of a gif. This relies on ImageIO classes.
>      */
>     private List<Integer> readFrameDurationMillis(InputStream stream) throws IOException {
>         ImageReader reader = ImageIO.getImageReadersByFormatName("gif").next();
>         try {
>             reader.setInput(ImageIO.createImageInputStream(stream));
>             int frameCount = reader.getNumImages(true);
>             List<Integer> frameDurations = new ArrayList<>(frameCount);
>             for (int frameIndex = 0; frameIndex < frameCount; frameIndex++) {
>                 IIOMetadataNode root = (IIOMetadataNode) reader.getImageMetadata(frameIndex).getAsTree("javax_imageio_gif_image_1.0");
>                 IIOMetadataNode gce = (IIOMetadataNode) root.getElementsByTagName("GraphicControlExtension").item(0);
>                 int delay = Integer.parseInt(gce.getAttribute("delayTime"));
>                 frameDurations.add( delay * 10 );
>             }
>             return frameDurations;
>         } finally {
>             reader.dispose();
>         }
>     }
> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250214/817ae1df/attachment-0001.htm>

From achung at openjdk.org  Fri Feb 14 23:07:29 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 14 Feb 2025 23:07:29 GMT
Subject: RFR: 8348596: Update FreeType to 2.13.3 [v2]
In-Reply-To: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
References: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
Message-ID: <ZB4OHwRMevOzS67gBqh8NxpJb_rGwq1KkJux0beIgHo=.bf3ea650-9ac2-4543-9bc8-0f274846b5b4@github.com>

> Upgrading freetype 3rd party tool to newest update

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

  fix spacing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23649/files
  - new: https://git.openjdk.org/jdk/pull/23649/files/b2b986f6..c7633dbb

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

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

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

From dgredler at openjdk.org  Fri Feb 14 23:51:49 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 14 Feb 2025 23:51:49 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands [v2]
In-Reply-To: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
Message-ID: <7gU4pI25KSO4AuaZShG8nT5OwDOX9HZM0U-N6dnENHk=.2a305b2a-cc93-42ef-bec4-78163f7bf6e8@github.com>

> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
> 
> Two methods are impacted:
> 
> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
> 
> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
> 
> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
> 
> A test case is included.

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Consider OS line separator when inspecting PostScript

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23595/files
  - new: https://git.openjdk.org/jdk/pull/23595/files/78d02b07..0d8009d7

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

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

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

From bpb at openjdk.org  Sat Feb 15 00:01:18 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 15 Feb 2025 00:01:18 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <_yMP6dnmDEc-ZIt0JfHpcCYCAwJz9KhZsdi5URkWHb0=.0528528c-06f1-4a6d-8e8f-45aa15b89043@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <s9eaFEw1SsaBNnWWdE0FFt9ExZA5vRf3TUbvyJrR2EM=.02b8dae5-e47a-45f0-aa69-7d6c3ec1a6d5@github.com>
 <_yMP6dnmDEc-ZIt0JfHpcCYCAwJz9KhZsdi5URkWHb0=.0528528c-06f1-4a6d-8e8f-45aa15b89043@github.com>
Message-ID: <DIDXMrPOXX53wCKhTmhafkLxJu_4wr0-icc8BfIWRdI=.f427025b-de79-4177-b8a8-492db8714913@github.com>

On Fri, 14 Feb 2025 21:41:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 1653:
>> 
>>> 1651:             if (exifMarkerSegment != null
>>> 1652:                     && exifMarkerSegment.getNumThumbnails() == 1) {
>>> 1653:                 return 1;
>> 
>> I know that my original code was also like this, but I think the eventual intent was to read both JFIF (APP0) and Exif (APP1) thumbnails if both are present. In such a case, the thumbnail count would be 2, the JFIF thumbnail would be at index 0, and the Exif thumbnail at index 1.
>> 
>> In general I would expect that if both of these thumbnails were present, then they would be identical. If this were not the case, however, then preferring the Exif thumbnail would be a behavioral change. This is not necessarily a blocker for the current PR, but it might need to be addressed later.
>
> Hmm. I think it better to address it now. Who knows when we'd get back to it.

I have a patch which handles both JFIF and Exif thumbnails if this is not otherwise resolved. To revisit next week ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1956912204

From dgredler at openjdk.org  Sat Feb 15 00:03:09 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Sat, 15 Feb 2025 00:03:09 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands
In-Reply-To: <XGUCtWzlkT4_1G1AhhQfXLcRcK5c_lN0482w892EgN0=.197869a8-c653-41ad-b138-2df44dc6d05c@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
 <XGUCtWzlkT4_1G1AhhQfXLcRcK5c_lN0482w892EgN0=.197869a8-c653-41ad-b138-2df44dc6d05c@github.com>
Message-ID: <6AyJt5Jo5HDJjC7BgknaUQOXE-xTcaVrTKPEwX40rKY=.6b87f97c-2a32-4e60-9241-ebdef712d43f@github.com>

On Fri, 14 Feb 2025 20:41:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
>> 
>> Two methods are impacted:
>> 
>> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
>> 
>> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
>> 
>> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
>> 
>> A test case is included.
>
> The new test failed on Windows
> java.lang.RuntimeException: Expected 1 path, but found 0 paths
> 	at PostScriptLeanTest.main(PostScriptLeanTest.java:80)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1447)

@prrace Thanks, fixed!

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

PR Comment: https://git.openjdk.org/jdk/pull/23595#issuecomment-2660532304

From prr at openjdk.org  Sat Feb 15 20:29:17 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 15 Feb 2025 20:29:17 GMT
Subject: RFR: 8348596: Update FreeType to 2.13.3 [v2]
In-Reply-To: <ZB4OHwRMevOzS67gBqh8NxpJb_rGwq1KkJux0beIgHo=.bf3ea650-9ac2-4543-9bc8-0f274846b5b4@github.com>
References: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
 <ZB4OHwRMevOzS67gBqh8NxpJb_rGwq1KkJux0beIgHo=.bf3ea650-9ac2-4543-9bc8-0f274846b5b4@github.com>
Message-ID: <1jVexO1kBrO1pWHdgU_StOzbkzi_xAjjpFw8QSFwGkQ=.ba154fae-3998-4b1f-8eed-a2c90dfa668f@github.com>

On Fri, 14 Feb 2025 23:07:29 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Upgrading freetype 3rd party tool to newest update
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix spacing

src/java.desktop/share/native/libfreetype/ws.sh line 2:

> 1: shopt -s nullglob
> 2: for f in *.c *.h *.cc *.hh;

I am quite certain you did not mean to include this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23649#discussion_r1957185893

From rmahajan at openjdk.org  Sun Feb 16 03:25:50 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Sun, 16 Feb 2025 03:25:50 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v4]
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  CATCH_BAD_ALLOC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23470/files
  - new: https://git.openjdk.org/jdk/pull/23470/files/9db93f54..5a7cd348

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

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

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

From psadhukhan at openjdk.org  Mon Feb 17 03:01:22 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 17 Feb 2025 03:01:22 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v4]
In-Reply-To: <XYqE7VAKi6t8awYH1cRY34LDiAzT4_EOY0DR6kz8G5Y=.f83ff6ce-3aa9-46cc-a7e6-c44df50268b3@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <XYqE7VAKi6t8awYH1cRY34LDiAzT4_EOY0DR6kz8G5Y=.f83ff6ce-3aa9-46cc-a7e6-c44df50268b3@github.com>
Message-ID: <JvBDa3jvA1SSquQSVb7EWN-mF_kmO2ZPD3DZDtcoDVE=.97e3a743-d440-4265-b93a-0421570910e9@github.com>

On Fri, 14 Feb 2025 20:20:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>> 
>> CI testing is green on all platforms.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1614:

> 1612:             // If scrollbar isn't visible, stop the timer
> 1613:             if (!scrollbar.isShowing()) {
> 1614:                 ((Timer)e.getSource()).stop();

It seems there is duplication of these lines with l1626-1628 which can be placed in a helper method..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1957521044

From jdv at openjdk.org  Mon Feb 17 05:55:10 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 17 Feb 2025 05:55:10 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v4]
In-Reply-To: <P_lYJ11P0HgVIQxy_SnkZe8BSGn9iV4mjIQH97VS7z8=.75e735c5-248c-4553-923f-6c9f525c3cd3@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <P_lYJ11P0HgVIQxy_SnkZe8BSGn9iV4mjIQH97VS7z8=.75e735c5-248c-4553-923f-6c9f525c3cd3@github.com>
Message-ID: <2DWSv8a_tJPDNzKCk884XvU3IRsl0oP3B5O_j9tqh0A=.6f08272a-dbd4-4820-842e-c8dd5562c6fa@github.com>

On Thu, 13 Feb 2025 23:15:52 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> Fix consists of:
>> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
>> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
>> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
>> * JavaDoc update for setData() (CSR required)
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed @link

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2620086806

From jdv at openjdk.org  Mon Feb 17 05:55:11 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 17 Feb 2025 05:55:11 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v2]
In-Reply-To: <WlE-D6ifPC0Wvs76PVHxENn4fjQ31GHkXMnUPyNa54I=.6c0a8bdf-f17d-4311-93a7-4a824d18f437@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <gij3NwmaGB5Q_Ms7Ht_fcs6JY59ykwpMCdK93yaRITI=.a99401e4-6283-433f-a572-5bb57a28e717@github.com>
 <WlE-D6ifPC0Wvs76PVHxENn4fjQ31GHkXMnUPyNa54I=.6c0a8bdf-f17d-4311-93a7-4a824d18f437@github.com>
Message-ID: <CZ_Mcvw7BPnzAWIkG0xSoR2w5aE-p2Rs1I5d15-A_2Q=.bf635c0f-92ff-4208-9ef1-94082e4fc5c4@github.com>

On Thu, 13 Feb 2025 22:00:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc update
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1154:
> 
>> 1152:      * This method is useful for advanced applications which need to access
>> 1153:      * profile data directly. Only non-BuiltIn profiles can be updated using
>> 1154:      * this method.
> 
> @prrace 
> I added this additional line here mentioning that only non-BuiltIn profiles can be updated. Does it look okay or do you recommend any changes ?

I think here also language should be similar to what we use in `@throws IllegalArgumentException`. Using just "non-BuiltIn profiles" doesn't give full picture.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1957652578

From dmarkov at openjdk.org  Mon Feb 17 06:04:13 2025
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Mon, 17 Feb 2025 06:04:13 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v4]
In-Reply-To: <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>
Message-ID: <nn8GvONqkfEWmQtcMwzwLBxy4KaFRF8cxxblijcdg9o=.3c26f53d-a3cc-4045-a5ec-3fe94ccaecf9@github.com>

On Sun, 16 Feb 2025 03:25:50 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CATCH_BAD_ALLOC

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2620097981

From abhiscxk at openjdk.org  Mon Feb 17 07:20:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 17 Feb 2025 07:20:10 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v4]
In-Reply-To: <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>
Message-ID: <twM9SYqJB6e1eNjEErckjY6_XzxpUwof50UnsIs68g8=.c38841a0-b822-46d1-91e9-c3d1ce2c446d@github.com>

On Sun, 16 Feb 2025 03:25:50 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CATCH_BAD_ALLOC

src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp line 134:

> 132:         ::DestroyIcon(icon);
> 133:     }
> 134:     catch (const std::bad_alloc&) {

Please follow java style for catch block too.

Suggestion:

    } catch (const std::bad_alloc&) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23470#discussion_r1957725917

From aivanov at openjdk.org  Mon Feb 17 13:06:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 17 Feb 2025 13:06:11 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v4]
In-Reply-To: <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>
Message-ID: <0NY_FwNy1Tgrai-Ib7DftSIY04IVlxBvQPo24PWIxgU=.a6d9b539-70d8-4bcd-96eb-8ff7919127ef@github.com>

On Sun, 16 Feb 2025 03:25:50 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CATCH_BAD_ALLOC

The suggestion was to use the macros: [`TRY`](https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/alloc.h#L131-L134) and [`CATCH_BAD_ALLOC`](https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/alloc.h#L154-L160).

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2621002791

From aivanov at openjdk.org  Mon Feb 17 13:11:18 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 17 Feb 2025 13:11:18 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v4]
In-Reply-To: <0NY_FwNy1Tgrai-Ib7DftSIY04IVlxBvQPo24PWIxgU=.a6d9b539-70d8-4bcd-96eb-8ff7919127ef@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <m1gTYLtDGC-zO_atnQTEGjVRDhXqiB6cIdXexX5PEQk=.ab6db630-636e-4555-b545-8c031fd09bb6@github.com>
 <0NY_FwNy1Tgrai-Ib7DftSIY04IVlxBvQPo24PWIxgU=.a6d9b539-70d8-4bcd-96eb-8ff7919127ef@github.com>
Message-ID: <WNd08h_JIro8ju1Vj9VSje2_-Tn-7uNiJQwY8cDJtQ0=.c3eb1250-5cfb-49ed-a6b2-df7356ae56b1@github.com>

On Mon, 17 Feb 2025 13:03:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The suggestion was to use the macros: [`TRY`](https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/alloc.h#L131-L134) and [`CATCH_BAD_ALLOC`](https://github.com/openjdk/jdk/blob/ab66c82ce9fdb5ee3fd7690f42b8ad4d78bf5e40/src/java.desktop/windows/native/libawt/windows/alloc.h#L154-L160).

The code would look like this:


JNIEXPORT void JNICALL Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
  (JNIEnv *env, jobject, jlong window, jintArray buf, jint w, jint h)
{
    TRY;

    HICON icon = CreateIconFromRaster(env, buf, w, h);
    m_Taskbar->SetOverlayIcon((HWND)window, icon, NULL);
    ::DestroyIcon(icon);

    CATCH_BAD_ALLOC;
}

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

PR Comment: https://git.openjdk.org/jdk/pull/23470#issuecomment-2663076031

From aivanov at openjdk.org  Mon Feb 17 13:15:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 17 Feb 2025 13:15:19 GMT
Subject: Integrated: 8342524: Use latch in AbstractButton/bug6298940.java
 instead of delay
In-Reply-To: <V2WXHyGBdHdO49Q4L0hYCX4lz3HOTdTNzqJnqv6Dib0=.6421e52b-5548-4555-b9a0-fc70a3bcd24a@github.com>
References: <V2WXHyGBdHdO49Q4L0hYCX4lz3HOTdTNzqJnqv6Dib0=.6421e52b-5548-4555-b9a0-fc70a3bcd24a@github.com>
Message-ID: <k_Kf3hC4obakT4UKvNH7BdNw6DZWtjBLtnRZWuU7CnQ=.e263a11a-c9a3-4b37-97ac-a16bffa2b615@github.com>

On Fri, 24 Jan 2025 16:47:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay.  
> Use `Util.hitMnemonics` instead of custom code to handle macOS.
> 
> I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI.

This pull request has now been integrated.

Changeset: 2bd8f026
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bd8f026dbd449e810dc6ce96cd9235e5cb51a9b
Stats:     93 lines in 1 file changed: 93 ins; 0 del; 0 mod

8342524: Use latch in AbstractButton/bug6298940.java instead of delay

Reviewed-by: azvegint, kizune, dnguyen, achung

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

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

From aivanov at openjdk.org  Mon Feb 17 13:16:20 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 17 Feb 2025 13:16:20 GMT
Subject: Integrated: 8348865: JButton/bug4796987.java never runs because
 Windows XP is unavailable
In-Reply-To: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
References: <Us0uAa9FVyooBWsjAGsdDEpfRx3HmY2UE7-K6Nc0Q1E=.af119fcb-21c9-40e0-bd44-41b4916a5169@github.com>
Message-ID: <f_X2-nHofrBYnaCA_SOlrfW94XuzCsv27zhhfOQFWV0=.6594d2e1-d61f-4781-8453-7784396427bb@github.com>

On Tue, 28 Jan 2025 14:51:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows.
> 
> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely.
> 
> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails.
> 
> The updated test passes in the CI.

This pull request has now been integrated.

Changeset: 650d0d95
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/650d0d954ea8e20e31f17d459993d5edecf08a4c
Stats:     82 lines in 1 file changed: 45 ins; 15 del; 22 mod

8348865: JButton/bug4796987.java never runs because Windows XP is unavailable

Reviewed-by: tr, abhiscxk, serb

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

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

From aivanov at openjdk.org  Mon Feb 17 13:16:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 17 Feb 2025 13:16:19 GMT
Subject: Integrated: 8294155: Exception thrown before awaitAndCheck hangs
 PassFailJFrame
In-Reply-To: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
References: <9lbzMq6w5i1pLC0gGFGq4JM3EwCf6GgCwrR9Rsn-UF4=.42a81929-9533-4b7d-96f9-a6dc0dc5bd13@github.com>
Message-ID: <zdP6mPCWszKxBdQSElPm_RAriPZhVnM0yzGxLxhkN2g=.9a2e344a-6184-4d40-aacd-51b85275d5a2@github.com>

On Tue, 11 Feb 2025 16:17:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If a manual test throws an exception during construction of `PassFailJFrame`, the test execution hangs. When the builder pattern is used, no UI appears on the screens, but the Java process does not terminate automatically because there are windows which prevent AWT from shutting down.
> 
> **Fix:**
> 
> Catch exceptions in `PassFailJFrame.Builder.build()` and dispose of all the windows if an exception occurs.
> 
> This ensures all the created windows are disposed of, which lets AWT shut down cleanly.
> 
> _Note:_ the above problem doesn't occur when the test is run with `jtreg` because jtreg shuts down the JVM as soon as the main thread exits.

This pull request has now been integrated.

Changeset: 906358d3
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/906358d3a14ce755fec771f0a6bb856b3a8f3297
Stats:     14 lines in 1 file changed: 12 ins; 0 del; 2 mod

8294155: Exception thrown before awaitAndCheck hangs PassFailJFrame

Reviewed-by: serb, azvegint, kizune

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

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

From dgredler at openjdk.org  Mon Feb 17 14:13:06 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 17 Feb 2025 14:13:06 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when drawing
 text to a Graphics2D object
Message-ID: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>

On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.

See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.

This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.

The new test class passes on Linux, Windows and macOS.

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

Commit messages:
 - Make Graphics2D.drawString ignore tabs and newlines on macOS
 - Add actual bug ID
 - Add ignored whitespace test

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

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

From alanb at openjdk.org  Mon Feb 17 15:26:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Feb 2025 15:26:14 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules [v2]
In-Reply-To: <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
Message-ID: <F3PCXiegB-EjgfP54T6G4Z_B23Ef5_nN9q-kl9M-V0o=.944af930-79bc-48a6-9041-52b8b7b82844@github.com>

On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
>> 
>> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
>> 
>> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
>> 
>> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @serialData text to CSR-approved version

I think this is oky, the CSR for the change writeExternal has already been reviewed.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2621362315

From hannesw at openjdk.org  Mon Feb 17 15:34:16 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 17 Feb 2025 15:34:16 GMT
Subject: Integrated: 8347123: Add missing @serial tags to other modules
In-Reply-To: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
Message-ID: <bpKNHxlo8g-0-F1SySvfie5_pj0K2tEXiu2cbLyHZ10=.140f9f54-7a24-4633-9901-3bd7ad507871@github.com>

On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
> 
> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
> 
> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
> 
> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.

This pull request has now been integrated.

Changeset: 3f0c1370
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f0c1370269db978072814c2170fc3987efade85
Stats:     104 lines in 39 files changed: 45 ins; 0 del; 59 mod

8347123: Add missing @serial tags to other modules

Reviewed-by: prr, nbenalla, alanb

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

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

From duke at openjdk.org  Mon Feb 17 19:52:21 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Feb 2025 19:52:21 GMT
Subject: Withdrawn: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <y5sbvad1Y5n2bzxGQK97vWP8RTQKIgsvg8EW8xXmJk4=.8629765e-ff9d-4f6b-a609-ff631a30e0d2@github.com>

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
> 
> build.log on release configuration:
> 
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=]
>  3560 |                     static const UINT _VKS_ALT_MASK = 0x04;
>       |                                       ^~~~~~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs]
>  1361 | } SUBTABLE, *PSUBTABLE;
>       |              ^~~~~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)':
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs]
>  1588 | } HEAD, *PHEAD;
>       |          ^~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs]
>  1595 | } ENTRY, *PENTRY;
>       |           ^~~~~~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/...

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Tue Feb 18 07:49:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Feb 2025 07:49:52 GMT
Subject: RFR: 8350224: Deproblemlist
 javax/swing/JComboBox/TestComboBoxComponentRendering.java
Message-ID: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>

Test is failing in ubuntu 23.x and beyond with expected red pixel not being picked up
Increase in fontsize increase the possibility of font red pixel being picked up. 
Test is now passing in ubuntu 24.04 and in CI..

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

Commit messages:
 - Copyright
 - deprob

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

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

From rmarchenko at openjdk.org  Tue Feb 18 08:33:55 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 18 Feb 2025 08:33:55 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v5]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <8pc24J47BZqhH822Ed4q8Q2sNwtwfOmkoEiQrBScXJQ=.18fea0c9-12c8-4d28-abc4-790cf35d7e1e@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also fixed the test, and added the approptiate test case.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  new fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/5782dd7e..a8653e04

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

  Stats: 220 lines in 3 files changed: 195 ins; 6 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

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

From rmarchenko at openjdk.org  Tue Feb 18 09:01:24 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 18 Feb 2025 09:01:24 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <Xhazfift0fhXZ561csieC0_fVRryLwyrqLzjVxZXoZQ=.1ec44e99-c8ad-4b56-84f1-34287ae68acc@github.com>
 <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>
Message-ID: <xNTVl_6IKdaKY_yaJItZck0lg_pIjEWDhk8Tbzh4HQI=.7b60c253-fcd6-4817-abf9-dc129d67478c@github.com>

On Thu, 13 Feb 2025 18:25:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>>> ...
>>> Thus, the methods of the current class have some priority over those of the parent class.
>>> But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
>> 
>> I'm still wondering if there's  any specification (tests?) describing this. At the time it looks like the current implementation is the only doc.
>> 
>> If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK. 
>> 
>> 
>> Case 1:
>>     public interface A {
>>         default public void setParentFoo(Integer num) {
>>         }
>>         default public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class D implements A {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setFoo(java.lang.Integer)
>> public void Test$D.setLocalFoo(java.lang.Long)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> 
>> 
>> Case 2:
>>     public class AC {
>>         public void setParentFoo(Integer num) {
>>         }
>>         public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class DC extends AC {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$DC.setFoo(java.lang.Number)
>> public void Test$DC.setLocalFoo(java.lang.Float)
>> public void Test$AC.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$DC.setFoo(java.lang.N...
>
>> > It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>> > ...
>> > Thus, the methods of the current class have some priority over those of the parent class.
>> > But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
> 
> There is "test/jdk/java/beans/Introspector/TestMethodOrderDependence.java" which was added to prevent accidental change in the implementation, but part of the behavior is undefined/unspecified.
> 
>>If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK.
> 
> New tests are always welcome, especially for interfaces, as they are a relatively new feature.

@mrserb 
I updated PR, could you review?

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2664989438

From psadhukhan at openjdk.org  Tue Feb 18 09:37:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 18 Feb 2025 09:37:10 GMT
Subject: RFR: 8350224: Deproblemlist
 javax/swing/JComboBox/TestComboBoxComponentRendering.java
In-Reply-To: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
References: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
Message-ID: <iUKRD3Vi3zJfBtvUJvu6XWypemjxarDXwNjnyo-6lc0=.1c76ab5c-80bc-4570-87a8-7c16ee26f461@github.com>

On Tue, 18 Feb 2025 07:45:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in ubuntu 23.x and beyond with expected red pixel not being picked up
> Increase in fontsize increase the possibility of font red pixel being picked up. 
> Test is now passing in ubuntu 24.04 and in CI..

ubuntu 22.04 uses [family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12] font
while
ubuntu 24.x uses [family=Noto Sans,name=Noto Sans,style=plain,size=12]
so it makes sense to use uniform font in the test..

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

PR Comment: https://git.openjdk.org/jdk/pull/23670#issuecomment-2665077036

From aivanov at openjdk.org  Tue Feb 18 10:17:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Feb 2025 10:17:22 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v3]
In-Reply-To: <kpTLg9w83l1yz-nuhHjLkZi6wAz4eaT1yq3gnb0X8Ys=.db55fdbc-8bd6-4fa2-aa14-c1954e83947a@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <kpTLg9w83l1yz-nuhHjLkZi6wAz4eaT1yq3gnb0X8Ys=.db55fdbc-8bd6-4fa2-aa14-c1954e83947a@github.com>
Message-ID: <QwUBNRoZG9P9r6TGv6XFDbvCmBrf03-KBocGSDnK0m4=.a7feefbe-4c27-4400-a610-0826366e5946@github.com>

On Fri, 14 Feb 2025 04:32:53 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HTML instructions formatting

Looks good, just a couple of minor tweaks to the instructions.

By the way, I updated the code in `PassFailJFrame` for HTML handling to make the long instructions look better. I'll submit a PR soon.

test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 70:

> 68:                   <li>Enable Screen magnifier on the Mac:
> 69:                    <b>System Settings</b> -> <b>Accessibility</b> ->
> 70:                    <b>Hover Text</b> -> <b>Enable Hover Text</b><br>

Suggestion:

                   <b>Hover Text</b> -> Enable <b>Hover Text</b><br>

Only the UI element should be in bold. (Yes, I know that I provided this snippet, yet I didn't notice it back then.)

test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 71:

> 69:                    <b>System Settings</b> -> <b>Accessibility</b> ->
> 70:                    <b>Hover Text</b> -> <b>Enable Hover Text</b><br>
> 71:                    Default Hover Text Activation Modifier is <kbd>Command</kbd> key.

Suggestion:

                   Default Hover Text Activation Modifier is <kbd>Command</kbd> key

The period at the end of the only sentence looks weird.

test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 72:

> 70:                    <b>Hover Text</b> -> <b>Enable Hover Text</b><br>
> 71:                    Default Hover Text Activation Modifier is <kbd>Command</kbd> key.
> 72:                   <li>Move focus back to test application

Suggestion:

                  <li>Move focus back to the test application and perform the following tests

test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 100:

> 98:                       </ol>
> 99:                   </ul>
> 100:                 </ol>

Suggestion:

                  </ul>
                  <li>Disable <b>Hover Text</b> (optionally) in the Settings
                </ol>

To complete the instructions.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2623029837
PR Comment: https://git.openjdk.org/jdk/pull/23436#issuecomment-2665180871
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1959441483
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1959442820
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1959429037
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1959438566

From aivanov at openjdk.org  Tue Feb 18 11:05:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Feb 2025 11:05:10 GMT
Subject: RFR: 8350224: Deproblemlist
 javax/swing/JComboBox/TestComboBoxComponentRendering.java
In-Reply-To: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
References: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
Message-ID: <LrY6rLv88MYdSedxyspfWg783RmdPSzxR5r0_cY1N38=.8a596fc1-d877-4dd6-be4b-f3de2666fa2a@github.com>

On Tue, 18 Feb 2025 07:45:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in ubuntu 23.x and beyond with expected red pixel not being picked up
> Increase in fontsize increase the possibility of font red pixel being picked up. 
> Test is now passing in ubuntu 24.04 and in CI..

The fix looks good to me.

However, the JBS bug should be more specific: the PR doesn't only remove the `javax/swing/JComboBox/TestComboBoxComponentRendering.java` test from the problem list, it modifies the test so that it can be removed from the problem-list.

Therefore, the subject of the bug has to reflect this additional change. (*?Increase font size in javax/swing/JComboBox/TestComboBoxComponentRendering.java?* isn't a bad candidate in my opinion.)

The current subject would be fine if you only removed the test from PL without modifying it.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23670#pullrequestreview-2623177171

From abhiscxk at openjdk.org  Tue Feb 18 11:15:57 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 18 Feb 2025 11:15:57 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v4]
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <ERbzq-sF_GAKcSjiDl8HrzA_PJWZA5cgumqaOzH3AB8=.38577f89-f5af-4655-9367-975edf1b8ba2@github.com>

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

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

  Minor test instruction formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23436/files
  - new: https://git.openjdk.org/jdk/pull/23436/files/0418694c..acb4ad65

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

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

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

From abhiscxk at openjdk.org  Tue Feb 18 11:15:57 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 18 Feb 2025 11:15:57 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v3]
In-Reply-To: <QwUBNRoZG9P9r6TGv6XFDbvCmBrf03-KBocGSDnK0m4=.a7feefbe-4c27-4400-a610-0826366e5946@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <kpTLg9w83l1yz-nuhHjLkZi6wAz4eaT1yq3gnb0X8Ys=.db55fdbc-8bd6-4fa2-aa14-c1954e83947a@github.com>
 <QwUBNRoZG9P9r6TGv6XFDbvCmBrf03-KBocGSDnK0m4=.a7feefbe-4c27-4400-a610-0826366e5946@github.com>
Message-ID: <J3jalU0pV0LDoI9qvUXq_hJ6zQRbQqPTFp_KiJ9jDjQ=.e061285d-872e-4d12-8bb9-918eeebaa606@github.com>

On Tue, 18 Feb 2025 10:14:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> By the way, I updated the code in `PassFailJFrame` for HTML handling to make the long instructions look better. I'll submit a PR soon.

That's a nice idea. Looking forward for the PR.

> test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java line 70:
> 
>> 68:                   <li>Enable Screen magnifier on the Mac:
>> 69:                    <b>System Settings</b> -> <b>Accessibility</b> ->
>> 70:                    <b>Hover Text</b> -> <b>Enable Hover Text</b><br>
> 
> Suggestion:
> 
>                    <b>Hover Text</b> -> Enable <b>Hover Text</b><br>
> 
> Only the UI element should be in bold. (Yes, I know that I provided this snippet, yet I didn't notice it back then.)

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/23436#issuecomment-2665331351
PR Review Comment: https://git.openjdk.org/jdk/pull/23436#discussion_r1959534243

From aivanov at openjdk.org  Tue Feb 18 11:52:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Feb 2025 11:52:11 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v4]
In-Reply-To: <ERbzq-sF_GAKcSjiDl8HrzA_PJWZA5cgumqaOzH3AB8=.38577f89-f5af-4655-9367-975edf1b8ba2@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <ERbzq-sF_GAKcSjiDl8HrzA_PJWZA5cgumqaOzH3AB8=.38577f89-f5af-4655-9367-975edf1b8ba2@github.com>
Message-ID: <mBYaYRjIAaO2-v6xiq8K_dcS1rCPJTSKkzvfNtjuL_0=.c7f93c79-c1aa-4e8a-af13-9ede71aa93e4@github.com>

On Tue, 18 Feb 2025 11:15:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor test instruction formatting

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2623293534

From aivanov at openjdk.org  Tue Feb 18 11:52:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Feb 2025 11:52:12 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v3]
In-Reply-To: <J3jalU0pV0LDoI9qvUXq_hJ6zQRbQqPTFp_KiJ9jDjQ=.e061285d-872e-4d12-8bb9-918eeebaa606@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <kpTLg9w83l1yz-nuhHjLkZi6wAz4eaT1yq3gnb0X8Ys=.db55fdbc-8bd6-4fa2-aa14-c1954e83947a@github.com>
 <QwUBNRoZG9P9r6TGv6XFDbvCmBrf03-KBocGSDnK0m4=.a7feefbe-4c27-4400-a610-0826366e5946@github.com>
 <J3jalU0pV0LDoI9qvUXq_hJ6zQRbQqPTFp_KiJ9jDjQ=.e061285d-872e-4d12-8bb9-918eeebaa606@github.com>
Message-ID: <fmMVC_w2_fxcmQvRPVCD4Yf0jk-CrvZ1AismK4VXoEY=.9c95b883-8dd3-4000-b328-87dc2762654e@github.com>

On Tue, 18 Feb 2025 11:12:14 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > By the way, I updated the code in `PassFailJFrame` for HTML handling to make the long instructions look better. I'll submit a PR soon.
> 
> That's a nice idea. Looking forward for the PR.

Submitted PR https://github.com/openjdk/jdk/pull/23674.

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

PR Comment: https://git.openjdk.org/jdk/pull/23436#issuecomment-2665442437

From aivanov at openjdk.org  Tue Feb 18 11:52:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Feb 2025 11:52:22 GMT
Subject: RFR: 8350260: Improve HTML instruction formatting in PassFailJFrame
Message-ID: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>

**Problem:**

When instructions are long, the formatting in `PassFailJFrame` looks off:

1. When the instructions are displayed on the screen for the first time, the HTML is scrolled to the bottom, which isn't convenient;
2. Numbers above 10 in the list are clipped on the left;
3. No border around the HTML text.

These problems were found while converting the instructions for `test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java` in https://github.com/openjdk/jdk/pull/23436.

<details>
<summary>Screenshots of the instructions</summary>
The instructions are scrolled to the bottom when the test starts:  
![01-instructions-bottom](https://github.com/user-attachments/assets/66c8d319-83d7-4219-91a5-96c964b9a0fe)

The number 10 in the list is clipped on the left:  
![02-clipped-numbering](https://github.com/user-attachments/assets/8db421ff-7b91-4db8-988c-03828097890e)

The headings _?Testing with??_ are flushed to the left, there's no additional space between the scroll pane border and the text.
</details>

**Fix:**

1. Adjust the list margins to accommodate for longer text;
2. Install the text border to either text instruction component;
3. Scroll the text to the top.

<details>
<summary>Screenshot of the instructions <i>with the fix</i></summary>
The stated issues are resolved:  
![03-top-no-clipping](https://github.com/user-attachments/assets/d14cfae2-733d-468d-93b9-c93d2d00cb3c)
</details>

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

Commit messages:
 - 8350260: Improve HTML instruction formatting in PassFailJFrame

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

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

From kizune at openjdk.org  Tue Feb 18 12:06:14 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Feb 2025 12:06:14 GMT
Subject: RFR: 8350260: Improve HTML instruction formatting in
 PassFailJFrame
In-Reply-To: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
References: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
Message-ID: <kKsGuafCfNDPRfRNz9PDgIbi5uvI4lINs6Mi9T3VLHU=.76c02422-aef0-4c78-9656-3b9530875d6a@github.com>

On Tue, 18 Feb 2025 11:48:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> When instructions are long, the formatting in `PassFailJFrame` looks off:
> 
> 1. When the instructions are displayed on the screen for the first time, the HTML is scrolled to the bottom, which isn't convenient;
> 2. Numbers above 10 in the list are clipped on the left;
> 3. No border around the HTML text.
> 
> These problems were found while converting the instructions for `test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java` in https://github.com/openjdk/jdk/pull/23436.
> 
> <details>
> <summary>Screenshots of the instructions</summary>
> 
> The instructions are scrolled to the bottom when the test starts:  
> ![01-instructions-bottom](https://github.com/user-attachments/assets/66c8d319-83d7-4219-91a5-96c964b9a0fe)
> 
> The number 10 in the list is clipped on the left:  
> ![02-clipped-numbering](https://github.com/user-attachments/assets/8db421ff-7b91-4db8-988c-03828097890e)
> 
> The headings _?Testing with??_ are flushed to the left, there's no additional space between the scroll pane border and the text.
> 
> </details>
> 
> **Fix:**
> 
> 1. Adjust the list margins to accommodate for longer text;
> 2. Install the text border to either text instruction component;
> 3. Scroll the text to the top.
> 
> <details>
> <summary>Screenshot of the instructions <i>with the fix</i></summary>
> 
> The stated issues are resolved:  
> ![03-top-no-clipping](https://github.com/user-attachments/assets/d14cfae2-733d-468d-93b9-c93d2d00cb3c)
> 
> </details>

Looks reasonable. Especially scrolling to the beginning.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23674#pullrequestreview-2623332357

From aivanov at openjdk.org  Tue Feb 18 12:30:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 18 Feb 2025 12:30:10 GMT
Subject: RFR: 8350260: Improve HTML instruction formatting in
 PassFailJFrame
In-Reply-To: <kKsGuafCfNDPRfRNz9PDgIbi5uvI4lINs6Mi9T3VLHU=.76c02422-aef0-4c78-9656-3b9530875d6a@github.com>
References: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
 <kKsGuafCfNDPRfRNz9PDgIbi5uvI4lINs6Mi9T3VLHU=.76c02422-aef0-4c78-9656-3b9530875d6a@github.com>
Message-ID: <jn-bMuV65j_PAI7Qu0DMgHVcQ6V7a3ir31arWt-BqCY=.73f310c5-2ded-45b1-a1a3-5c6a2c688867@github.com>

On Tue, 18 Feb 2025 12:03:43 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Especially scrolling to the beginning.

That was the most disturbing thing. I didn't notice it before, because HTML instructions were never so long to have the vertical scroll bar.

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

PR Comment: https://git.openjdk.org/jdk/pull/23674#issuecomment-2665566653

From azvegint at openjdk.org  Tue Feb 18 18:55:42 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 18 Feb 2025 18:55:42 GMT
Subject: RFR: 8350260: Improve HTML instruction formatting in
 PassFailJFrame
In-Reply-To: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
References: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
Message-ID: <2IO5GxeXxTX4xom1NHI6HWGWPiq-U9MPFdm9zgtiPho=.bd82e2d4-2fd8-4699-b85e-e7f3dde41029@github.com>

On Tue, 18 Feb 2025 11:48:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> When instructions are long, the formatting in `PassFailJFrame` looks off:
> 
> 1. When the instructions are displayed on the screen for the first time, the HTML is scrolled to the bottom, which isn't convenient;
> 2. Numbers above 10 in the list are clipped on the left;
> 3. No border around the HTML text.
> 
> These problems were found while converting the instructions for `test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java` in https://github.com/openjdk/jdk/pull/23436.
> 
> <details>
> <summary>Screenshots of the instructions</summary>
> 
> The instructions are scrolled to the bottom when the test starts:  
> ![01-instructions-bottom](https://github.com/user-attachments/assets/66c8d319-83d7-4219-91a5-96c964b9a0fe)
> 
> The number 10 in the list is clipped on the left:  
> ![02-clipped-numbering](https://github.com/user-attachments/assets/8db421ff-7b91-4db8-988c-03828097890e)
> 
> The headings _?Testing with??_ are flushed to the left, there's no additional space between the scroll pane border and the text.
> 
> </details>
> 
> **Fix:**
> 
> 1. Adjust the list margins to accommodate for longer text;
> 2. Install the text border to either text instruction component;
> 3. Scroll the text to the top.
> 
> <details>
> <summary>Screenshot of the instructions <i>with the fix</i></summary>
> 
> The stated issues are resolved:  
> ![03-top-no-clipping](https://github.com/user-attachments/assets/d14cfae2-733d-468d-93b9-c93d2d00cb3c)
> 
> </details>

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23674#pullrequestreview-2624306723

From bpb at openjdk.org  Tue Feb 18 19:10:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Feb 2025 19:10:13 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <VxInC4X7nPaXDuUNptgsf1upM_a-aaawIem7u7jGSbU=.b8c2cc5a-722d-4a38-bdaa-adfcfcaa1c88@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

Attaching a ZIP of a diff which adds support for reading both JFIF and Exif thumbnails if present. Any JFIF thumbnails are read first and the Exif thumbnail is at index `numThumbails - 1`.

[JPEGImageReader.diff.zip](https://github.com/user-attachments/files/18849539/JPEGImageReader.diff.zip)

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2666324177

From bpb at openjdk.org  Tue Feb 18 19:10:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Feb 2025 19:10:14 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <VxInC4X7nPaXDuUNptgsf1upM_a-aaawIem7u7jGSbU=.b8c2cc5a-722d-4a38-bdaa-adfcfcaa1c88@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <VxInC4X7nPaXDuUNptgsf1upM_a-aaawIem7u7jGSbU=.b8c2cc5a-722d-4a38-bdaa-adfcfcaa1c88@github.com>
Message-ID: <5XDhq_0vxKC_KfZ-zRl1fzGK7K2RlBEqrRQtEHu0rFI=.492c4ee5-0985-405b-9a34-fd0b95dabc5e@github.com>

On Tue, 18 Feb 2025 17:06:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> [...] reading both JFIF and Exif thumbnails [...]

Note that `test/jdk/javax/imageio/plugins/jpeg/jdk_8160327-jfif-jfif-and-exif-thumbnail-sharpshot-iphone.jpg` contains both a JFIF and an Exif thumbnail and they are _different_.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2666589462

From kizune at openjdk.org  Tue Feb 18 19:12:12 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 18 Feb 2025 19:12:12 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v4]
In-Reply-To: <ERbzq-sF_GAKcSjiDl8HrzA_PJWZA5cgumqaOzH3AB8=.38577f89-f5af-4655-9367-975edf1b8ba2@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <ERbzq-sF_GAKcSjiDl8HrzA_PJWZA5cgumqaOzH3AB8=.38577f89-f5af-4655-9367-975edf1b8ba2@github.com>
Message-ID: <PeD9xVbGmFjMJTkLfSINDLfx32SvEj2RddGyNE1D8oE=.5d823039-22f3-4ad7-87ae-4addb9a13ddb@github.com>

On Tue, 18 Feb 2025 11:15:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor test instruction formatting

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2624210901

From azvegint at openjdk.org  Tue Feb 18 19:28:30 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 18 Feb 2025 19:28:30 GMT
Subject: RFR: 8350224: Deproblemlist
 javax/swing/JComboBox/TestComboBoxComponentRendering.java
In-Reply-To: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
References: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
Message-ID: <TP-6hmbRr3PoeAlKzCwd8meVBH6S1ec9iahChZgnh2E=.f515debd-0c8e-4dc5-895c-26590059be07@github.com>

On Tue, 18 Feb 2025 07:45:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in ubuntu 23.x and beyond with expected red pixel not being picked up
> Increase in fontsize increase the possibility of font red pixel being picked up. 
> Test is now passing in ubuntu 24.04 and in CI..

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23670#pullrequestreview-2624323386

From bpb at openjdk.org  Tue Feb 18 21:20:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Feb 2025 21:20:54 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <9uzTu7PPg54HWb1WzqSryJW2oZD1H5sF7KGJAg7IA24=.317e0912-a96c-4f9e-8105-d61eb339b7eb@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

If this change moves forward, the [Thumbnail Images](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/javax/imageio/metadata/doc-files/jpeg_metadata.html#thumbs) section of the JPEG metadata specification should be updated, in which case a CSR will be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2666949882

From duke at openjdk.org  Tue Feb 18 22:23:58 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 18 Feb 2025 22:23:58 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <cx2HoBrX4xui-zkHI_k7EVuTvWiExiFFVNj0jvcXjN4=.8db89caf-7889-49bc-b532-eb11f61af789@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

Thanks; something came up this weekend and didn't get a chance to work on it. I'm excited this ticket suddenly got interest and will definitely look into as time permits.

@bplb when it comes to EXIF vs JFIF: aside from code simplicity, I initially didn't support *both* JFIF and EXIF thumbnails because I read that the two were technically incompatible. (Here's one such explanation: https://superuser.com/questions/1657522/what-makes-two-main-jpeg-file-formats-jfif-and-exif-incompatible ). You sound like the subject matter expert here: it sounds like you're confident there's enough real-world use cases to justify supporting both, right?

I agree it shouldn't be hard to do, but I just wanted to acknowledge the specs in this thread before implementing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2667053496

From bpb at openjdk.org  Tue Feb 18 23:07:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 18 Feb 2025 23:07:59 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
Message-ID: <yHCfjoU8cEIfY5-6-V8thMGaFEXqOmg0vAH0bN_ASkM=.0ac89120-26a5-41f0-8025-0f24b799d4f9@github.com>

On Thu, 2 Jan 2025 06:49:19 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: fixing typo so `thumbnailPos` can be zero
>   
>   The `thumbnailLength` cannot be zero, but the position can be.

> I initially didn't support _both_ JFIF and EXIF thumbnails because I read that the two were technically incompatible.

You are correct, as is the superuser answer (thanks for the link). If the specifications are followed to the letter, then they are incompatible.

> [...] it sounds like you're confident there's enough real-world use cases to justify supporting both, right?

I don't have enough information to justify that. I do know from experience in other formats, however, that one sometimes needs to support cases which are actually non-compliant. Otherwise people will complain with something like "Acme Image Library can read the image but Java cannot." Here I just think we need to do something that makes sense, go with it, and document it.

There is also a minor backward compatibility issue. I think that without this change, the JPEG reader will show one thumbnail for `jfif-jfif-and-exif-thumbnail-sharpshot-iphone.jpg`, which is the JFIF thumbnail, but if the change is applied as is, there will still be just one thumbnail, but now it will be the one from the Exif 1st IFD. As noted above, those two thumbails for this image are not the same, as weird as that is.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2667122865

From dnguyen at openjdk.org  Wed Feb 19 00:08:09 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 19 Feb 2025 00:08:09 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v5]
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <RmMJ9HuqFtlGqcDAPALgj7Pa7OKUEVatFkaK5w1hhl4=.b1970649-ea30-465f-9aad-75902fc00776@github.com>

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add helper method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23451/files
  - new: https://git.openjdk.org/jdk/pull/23451/files/3a7bf130..ce106acd

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

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

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

From dnguyen at openjdk.org  Wed Feb 19 00:38:57 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 19 Feb 2025 00:38:57 GMT
Subject: RFR: 8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS [v4]
In-Reply-To: <ERbzq-sF_GAKcSjiDl8HrzA_PJWZA5cgumqaOzH3AB8=.38577f89-f5af-4655-9367-975edf1b8ba2@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
 <ERbzq-sF_GAKcSjiDl8HrzA_PJWZA5cgumqaOzH3AB8=.38577f89-f5af-4655-9367-975edf1b8ba2@github.com>
Message-ID: <y7dwSyen8-D_LcqPKmUW7dEpP7Eoj60lGGfIfzD8dOg=.0c173168-5857-436c-a741-cc8e2b08189a@github.com>

On Tue, 18 Feb 2025 11:15:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
>> 
>> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
>> 
>> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
>> 
>> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
>> 
>> The proposed change can be verified the manual test in the PR.
>> 
>> CI pipeline testing is `OK`, link posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor test instruction formatting

Tested checking/unchecking checkboxes on TestJCheckBoxToggleAccessibility.java and on SwingSet2 on MacOS 15.3.1 with VoiceOver. Spacebar is correctly working now.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23436#pullrequestreview-2625354449

From psadhukhan at openjdk.org  Wed Feb 19 02:23:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Feb 2025 02:23:11 GMT
Subject: Integrated: 8350224: Test
 javax/swing/JComboBox/TestComboBoxComponentRendering.java fails in ubuntu 23.x
 and later
In-Reply-To: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
References: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
Message-ID: <azVW95Nfp_80ueCLZmgSMAANnqv9zL_TtST3D9LYIdA=.4959d622-1768-42cb-a22a-36fb71082f51@github.com>

On Tue, 18 Feb 2025 07:45:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in ubuntu 23.x and beyond with expected red pixel not being picked up
> Increase in fontsize increase the possibility of font red pixel being picked up. 
> Test is now passing in ubuntu 24.04 and in CI..

This pull request has now been integrated.

Changeset: 4de92a40
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4de92a40d0750a2e6f72eb675d900f1129718d39
Stats:     7 lines in 2 files changed: 2 ins; 4 del; 1 mod

8350224: Test javax/swing/JComboBox/TestComboBoxComponentRendering.java fails in ubuntu 23.x and later

Reviewed-by: aivanov, azvegint

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

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

From psadhukhan at openjdk.org  Wed Feb 19 02:23:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 19 Feb 2025 02:23:11 GMT
Subject: RFR: 8350224: Test
 javax/swing/JComboBox/TestComboBoxComponentRendering.java fails in ubuntu 23.x
 and later
In-Reply-To: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
References: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
Message-ID: <yyicX_6Kl0qNABBX0W82CCloP5Iu8Np6EM5VRlZ6OUU=.214b5611-fba4-4549-a14a-ee7a761f16bb@github.com>

On Tue, 18 Feb 2025 07:45:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is failing in ubuntu 23.x and beyond with expected red pixel not being picked up
> Increase in fontsize increase the possibility of font red pixel being picked up. 
> Test is now passing in ubuntu 24.04 and in CI..

I have changed the bug description to be symptomatic of the issue we are seeing..

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

PR Comment: https://git.openjdk.org/jdk/pull/23670#issuecomment-2667350326

From abhiscxk at openjdk.org  Wed Feb 19 06:11:51 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Feb 2025 06:11:51 GMT
Subject: RFR: 8350260: Improve HTML instruction formatting in
 PassFailJFrame
In-Reply-To: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
References: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
Message-ID: <vkwx_QrKfdzydjLIaugoOXjCAloYp836fmkYIShncl0=.5ecc0a43-924a-4b26-aab2-8204f2f06d20@github.com>

On Tue, 18 Feb 2025 11:48:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> When instructions are long, the formatting in `PassFailJFrame` looks off:
> 
> 1. When the instructions are displayed on the screen for the first time, the HTML is scrolled to the bottom, which isn't convenient;
> 2. Numbers above 10 in the list are clipped on the left;
> 3. No border around the HTML text.
> 
> These problems were found while converting the instructions for `test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java` in https://github.com/openjdk/jdk/pull/23436.
> 
> <details>
> <summary>Screenshots of the instructions</summary>
> 
> The instructions are scrolled to the bottom when the test starts:  
> ![01-instructions-bottom](https://github.com/user-attachments/assets/66c8d319-83d7-4219-91a5-96c964b9a0fe)
> 
> The number 10 in the list is clipped on the left:  
> ![02-clipped-numbering](https://github.com/user-attachments/assets/8db421ff-7b91-4db8-988c-03828097890e)
> 
> The headings _?Testing with??_ are flushed to the left, there's no additional space between the scroll pane border and the text.
> 
> </details>
> 
> **Fix:**
> 
> 1. Adjust the list margins to accommodate for longer text;
> 2. Install the text border to either text instruction component;
> 3. Scroll the text to the top.
> 
> <details>
> <summary>Screenshot of the instructions <i>with the fix</i></summary>
> 
> The stated issues are resolved:  
> ![03-top-no-clipping](https://github.com/user-attachments/assets/d14cfae2-733d-468d-93b9-c93d2d00cb3c)
> 
> </details>

Marked as reviewed by abhiscxk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23674#pullrequestreview-2625716190

From abhiscxk at openjdk.org  Wed Feb 19 06:11:52 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Feb 2025 06:11:52 GMT
Subject: RFR: 8350260: Improve HTML instruction formatting in
 PassFailJFrame
In-Reply-To: <jn-bMuV65j_PAI7Qu0DMgHVcQ6V7a3ir31arWt-BqCY=.73f310c5-2ded-45b1-a1a3-5c6a2c688867@github.com>
References: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
 <kKsGuafCfNDPRfRNz9PDgIbi5uvI4lINs6Mi9T3VLHU=.76c02422-aef0-4c78-9656-3b9530875d6a@github.com>
 <jn-bMuV65j_PAI7Qu0DMgHVcQ6V7a3ir31arWt-BqCY=.73f310c5-2ded-45b1-a1a3-5c6a2c688867@github.com>
Message-ID: <kJEivcacy6z12FukEygXDorgYk7zpO1Yl3USMCgBF5E=.5e8f9e84-7a6b-453d-a3b6-10ab65fae024@github.com>

On Tue, 18 Feb 2025 12:27:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Especially scrolling to the beginning.
> 
> That was the most disturbing thing. I didn't notice it before, because HTML instructions were never so long to have the vertical scroll bar.

I agree to this.
I didn't notice the clipping of number 10 before but With the changes in PFJ, test instructions look better.

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

PR Comment: https://git.openjdk.org/jdk/pull/23674#issuecomment-2667590731

From abhiscxk at openjdk.org  Wed Feb 19 06:37:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 19 Feb 2025 06:37:56 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v5]
In-Reply-To: <RmMJ9HuqFtlGqcDAPALgj7Pa7OKUEVatFkaK5w1hhl4=.b1970649-ea30-465f-9aad-75902fc00776@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <RmMJ9HuqFtlGqcDAPALgj7Pa7OKUEVatFkaK5w1hhl4=.b1970649-ea30-465f-9aad-75902fc00776@github.com>
Message-ID: <NlrFFAii_ujODs_hPsf5CXEH-Tne2CDWu1ef2Isdm-0=.c4973628-76a8-4e71-9283-dea64e06eaff@github.com>

On Wed, 19 Feb 2025 00:08:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>> 
>> CI testing is green on all platforms.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add helper method

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java line 1667:

> 1665: 
> 1666:     private void stopScrollTimer(ActionEvent e) {
> 1667:         ((Timer)e.getSource()).stop();

minor spacing
Suggestion:

        ((Timer) e.getSource()).stop();

test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 44:

> 42:  * @bug 6672644
> 43:  * @library /java/awt/regtesthelpers
> 44:  * @build PassFailJFrame

No longer needed for automated test.

test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 91:

> 89:             JScrollPane scrollPane = (JScrollPane) popup.getAccessibleContext().getAccessibleChild(0);
> 90:             JScrollBar scrollBar = scrollPane.getVerticalScrollBar();
> 91:             return scrollBar.getValue();

Similar code duplication at L113 - L114. Can be pushed to a helper method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1961020404
PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1961020200
PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1961027933

From aivanov at openjdk.org  Wed Feb 19 12:25:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 19 Feb 2025 12:25:55 GMT
Subject: Integrated: 8350260: Improve HTML instruction formatting in
 PassFailJFrame
In-Reply-To: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
References: <rz64YxbPK3x9tVVT-xhXKYh2eFPRBM7SKtfUU8y5fr0=.acea9f00-9705-4320-9df2-885c82660531@github.com>
Message-ID: <38nbAOKUmB3O-dFdjLCahDM2M01LtlgZbf3V_wgiqtI=.22bde6c1-2414-4838-873c-fcc0719c1e56@github.com>

On Tue, 18 Feb 2025 11:48:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> When instructions are long, the formatting in `PassFailJFrame` looks off:
> 
> 1. When the instructions are displayed on the screen for the first time, the HTML is scrolled to the bottom, which isn't convenient;
> 2. Numbers above 10 in the list are clipped on the left;
> 3. No border around the HTML text.
> 
> These problems were found while converting the instructions for `test/jdk/javax/accessibility/TestJCheckBoxToggleAccessibility.java` in https://github.com/openjdk/jdk/pull/23436.
> 
> <details>
> <summary>Screenshots of the instructions</summary>
> 
> The instructions are scrolled to the bottom when the test starts:  
> ![01-instructions-bottom](https://github.com/user-attachments/assets/66c8d319-83d7-4219-91a5-96c964b9a0fe)
> 
> The number 10 in the list is clipped on the left:  
> ![02-clipped-numbering](https://github.com/user-attachments/assets/8db421ff-7b91-4db8-988c-03828097890e)
> 
> The headings _?Testing with??_ are flushed to the left, there's no additional space between the scroll pane border and the text.
> 
> </details>
> 
> **Fix:**
> 
> 1. Adjust the list margins to accommodate for longer text;
> 2. Install the text border to either text instruction component;
> 3. Scroll the text to the top.
> 
> <details>
> <summary>Screenshot of the instructions <i>with the fix</i></summary>
> 
> The stated issues are resolved:  
> ![03-top-no-clipping](https://github.com/user-attachments/assets/d14cfae2-733d-468d-93b9-c93d2d00cb3c)
> 
> </details>

This pull request has now been integrated.

Changeset: 014701a0
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/014701a09b23d21f57edb5b085820532804475bd
Stats:     7 lines in 1 file changed: 2 ins; 1 del; 4 mod

8350260: Improve HTML instruction formatting in PassFailJFrame

Reviewed-by: kizune, azvegint, abhiscxk

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

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

From aivanov at openjdk.org  Wed Feb 19 13:08:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 19 Feb 2025 13:08:58 GMT
Subject: RFR: 8350224: Test
 javax/swing/JComboBox/TestComboBoxComponentRendering.java fails in ubuntu 23.x
 and later
In-Reply-To: <yyicX_6Kl0qNABBX0W82CCloP5Iu8Np6EM5VRlZ6OUU=.214b5611-fba4-4549-a14a-ee7a761f16bb@github.com>
References: <iQZhY9AmUlt2qJqqOKNaqR6krhJODopcmlGfPsnPTlo=.deeac01d-242f-4ac5-934c-7c2832901d3b@github.com>
 <yyicX_6Kl0qNABBX0W82CCloP5Iu8Np6EM5VRlZ6OUU=.214b5611-fba4-4549-a14a-ee7a761f16bb@github.com>
Message-ID: <0Ac5L3whgMfBvXs4H4r48znnjSAhZr4I5pejTmVwrHo=.e4c7c62b-ee75-4847-a38b-616a8de31cde@github.com>

On Wed, 19 Feb 2025 02:18:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I have changed the bug description to be symptomatic of the issue we are seeing..

Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/23670#issuecomment-2668601106

From honkar at openjdk.org  Wed Feb 19 22:54:15 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 19 Feb 2025 22:54:15 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  javadoc change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/52c76c73..8da82c10

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

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

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

From dnguyen at openjdk.org  Wed Feb 19 23:04:39 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 19 Feb 2025 23:04:39 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v6]
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <p8ZXASmJRw0oE13mwM4RAJTP8Do-SVJlDic06DRXc5k=.e2ac0f2d-22c7-4090-8cbf-b4f8086b479a@github.com>

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Add test helper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23451/files
  - new: https://git.openjdk.org/jdk/pull/23451/files/ce106acd..889a6fa7

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

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

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

From dnguyen at openjdk.org  Wed Feb 19 23:04:39 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 19 Feb 2025 23:04:39 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v5]
In-Reply-To: <NlrFFAii_ujODs_hPsf5CXEH-Tne2CDWu1ef2Isdm-0=.c4973628-76a8-4e71-9283-dea64e06eaff@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <RmMJ9HuqFtlGqcDAPALgj7Pa7OKUEVatFkaK5w1hhl4=.b1970649-ea30-465f-9aad-75902fc00776@github.com>
 <NlrFFAii_ujODs_hPsf5CXEH-Tne2CDWu1ef2Isdm-0=.c4973628-76a8-4e71-9283-dea64e06eaff@github.com>
Message-ID: <dM6vGs0Rqd9ZQ5yATiaAwZP2snQwfEJL89MyXN5oKQc=.5a2713f0-b405-4498-9034-cb782b6abf13@github.com>

On Wed, 19 Feb 2025 06:25:21 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add helper method
>
> test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 44:
> 
>> 42:  * @bug 6672644
>> 43:  * @library /java/awt/regtesthelpers
>> 44:  * @build PassFailJFrame
> 
> No longer needed for automated test.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1962489023

From honkar at openjdk.org  Wed Feb 19 23:11:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 19 Feb 2025 23:11:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v2]
In-Reply-To: <CZ_Mcvw7BPnzAWIkG0xSoR2w5aE-p2Rs1I5d15-A_2Q=.bf635c0f-92ff-4208-9ef1-94082e4fc5c4@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <gij3NwmaGB5Q_Ms7Ht_fcs6JY59ykwpMCdK93yaRITI=.a99401e4-6283-433f-a572-5bb57a28e717@github.com>
 <WlE-D6ifPC0Wvs76PVHxENn4fjQ31GHkXMnUPyNa54I=.6c0a8bdf-f17d-4311-93a7-4a824d18f437@github.com>
 <CZ_Mcvw7BPnzAWIkG0xSoR2w5aE-p2Rs1I5d15-A_2Q=.bf635c0f-92ff-4208-9ef1-94082e4fc5c4@github.com>
Message-ID: <aGMo5sipiQG59j3tcGRHRab8R0ncBlYE4shlQsFTlzc=.18186b1f-a727-493a-bb02-e73b54522f29@github.com>

On Mon, 17 Feb 2025 05:51:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1154:
>> 
>>> 1152:      * This method is useful for advanced applications which need to access
>>> 1153:      * profile data directly. Only non-BuiltIn profiles can be updated using
>>> 1154:      * this method.
>> 
>> @prrace 
>> I added this additional line here mentioning that only non-BuiltIn profiles can be updated. Does it look okay or do you recommend any changes ?
>
> I think here also language should be similar to what we use in `@throws IllegalArgumentException`. Using just "non-BuiltIn profiles" doesn't give full picture.

@prrace @jayathirthrao  Thanks! Updated both the PR as per CSR changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1962495024

From achung at openjdk.org  Wed Feb 19 23:29:44 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 19 Feb 2025 23:29:44 GMT
Subject: RFR: 8348596: Update FreeType to 2.13.3 [v3]
In-Reply-To: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
References: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
Message-ID: <dFS4NMHKEep71PGKkpl1yKZLI5u1IkUmKeSBFLmxQGw=.c27741c0-328c-4169-8be0-48ce9e5456a5@github.com>

> Upgrading freetype 3rd party tool to newest update

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

  remove ws tool

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23649/files
  - new: https://git.openjdk.org/jdk/pull/23649/files/c7633dbb..e1dd8fcd

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

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

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

From azvegint at openjdk.org  Thu Feb 20 01:07:57 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 20 Feb 2025 01:07:57 GMT
Subject: RFR: 8348596: Update FreeType to 2.13.3 [v3]
In-Reply-To: <dFS4NMHKEep71PGKkpl1yKZLI5u1IkUmKeSBFLmxQGw=.c27741c0-328c-4169-8be0-48ce9e5456a5@github.com>
References: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
 <dFS4NMHKEep71PGKkpl1yKZLI5u1IkUmKeSBFLmxQGw=.c27741c0-328c-4169-8be0-48ce9e5456a5@github.com>
Message-ID: <UiLB0OJ4FhSU5hBse7q4FRTnptXpUvCh3Xq5Y9O3Pfk=.e698bbc1-dc04-49ab-93c9-9a8ca119292a@github.com>

On Wed, 19 Feb 2025 23:29:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Upgrading freetype 3rd party tool to newest update
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ws tool

I assume testing looks good.

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23649#pullrequestreview-2628338691

From abhiscxk at openjdk.org  Thu Feb 20 09:21:00 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 20 Feb 2025 09:21:00 GMT
Subject: Integrated: 8348936: [Accessibility, macOS,
 VoiceOver] VoiceOver doesn't
 announce untick on toggling the checkbox with "space" key on macOS
In-Reply-To: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
References: <n5lE1zPeVNr8CvIeYweL5nx5voXs8d6btRIcTBvKfPA=.af7347f7-d05e-4652-b9ee-0040364b2475@github.com>
Message-ID: <-qubGjI_mL_03ag3DPxIMJjAiUVQzsQ3PJCW-mhvxrQ=.907c51f9-8dce-41ac-bd32-dddc31b67d4c@github.com>

On Tue, 4 Feb 2025 10:58:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> VoiceOver doesn't announce the _untick state_ when Checkbox is `deselected` using **space** key. When CheckBox is deselected, the state change is not notified to a11y client (VoiceOver) and so the state is not announced by VO. 
> 
> Screen Magnifier is also unable to magnify the unchecked state of JCheckBox due to same reason and is captured as separate bug [JDK-8345728](https://bugs.openjdk.org/browse/JDK-8345728).
> 
> Proposed fix is to send the state change notification to a11y client when checkbox is deselected, this resolves the problem for VoiceOver and Screen Magnifier.
> 
> Similar issue observed for JToggleButton. So, I extended the fix for JToggleButton as well.
> 
> The proposed change can be verified the manual test in the PR.
> 
> CI pipeline testing is `OK`, link posted in JBS.

This pull request has now been integrated.

Changeset: 1e87ff01
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e87ff01994df16df7de331040fc5d7a4a85f630
Stats:     133 lines in 2 files changed: 130 ins; 0 del; 3 mod

8348936: [Accessibility,macOS,VoiceOver] VoiceOver doesn't announce untick on toggling the checkbox with "space" key on macOS
8345728: [Accessibility,macOS,Screen Magnifier]: JCheckbox unchecked state does not magnify but works for checked state

Reviewed-by: aivanov, kizune, dnguyen, asemenov

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

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

From aivanov at openjdk.org  Thu Feb 20 14:46:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 14:46:54 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
Message-ID: <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>

On Wed, 19 Feb 2025 22:54:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> Fix consists of:
>> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
>> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
>> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
>> * JavaDoc update for setData() (CSR required)
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc change

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:

> 114:      * BuiltInProfile.
> 115:      */
> 116:     private boolean isBuiltIn = false;

Can't this field be `final` and be set in constructor of the class?

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1154:

> 1152:      * This method is useful for advanced applications which need to access
> 1153:      * profile data directly. Only non-built-in, application provided profiles
> 1154:      * should be updated using this method.

What you mean is that only non-built-in profiles *can* be updated. The fix makes it impossible to update built-in profiles.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1164:

> 1162:      *         array can not be interpreted as valid tag data, corresponding to
> 1163:      *         the {@code tagSignature}
> 1164:      * @throws IllegalArgumentException if this is a profile for one of the

`IllegalStateException` better describes the reason: the argument to the method can be perfectly valid, but the internal state of the object doesn't allow modifications.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1172:

> 1170:     public void setData(int tagSignature, byte[] tagData) {
> 1171:         if (isBuiltIn) {
> 1172:             throw new IllegalArgumentException("BuiltIn profile"

Suggestion:

            throw new IllegalArgumentException("Built-in profile"

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

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2630072442
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1963699390
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1963690614
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1963694920
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1963695795

From aivanov at openjdk.org  Thu Feb 20 15:16:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 15:16:57 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
Message-ID: <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>

On Thu, 20 Feb 2025 14:43:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc change
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:
> 
>> 114:      * BuiltInProfile.
>> 115:      */
>> 116:     private boolean isBuiltIn = false;
> 
> Can't this field be `final` and be set in constructor of the class?

Indeed, it *can be*, and I prefer this design. This way, the `isBuiltIn` field can't be changed after the object is constructed. I think it's a cleaner design.

To achieve this, you have to add a constructor which accepts a boolean flag: `ICC_Profile(ProfileDeferralInfo pdi, boolean builtIn)`, and `ICC_ProfileRGB` and `ICC_ProfileGray` need to provide an additional constructor as well.

Here's [a diff to your branch which achieves this](https://github.com/honkar-jdk/jdk/compare/BuiltInCheck...aivanov-jdk:jdk:harshitha/8346465-built-inprofiles).

When [you compare the changeset that I propose to `jdk/master`](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:harshitha/8346465-built-inprofiles), there are less differences, and `BuiltInProfile` remains an interface. Yet two more files `ICC_ProfileRGB` and `ICC_ProfileGray` are modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1963761853

From aivanov at openjdk.org  Thu Feb 20 15:16:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 15:16:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
Message-ID: <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>

On Thu, 20 Feb 2025 15:11:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:
>> 
>>> 114:      * BuiltInProfile.
>>> 115:      */
>>> 116:     private boolean isBuiltIn = false;
>> 
>> Can't this field be `final` and be set in constructor of the class?
>
> Indeed, it *can be*, and I prefer this design. This way, the `isBuiltIn` field can't be changed after the object is constructed. I think it's a cleaner design.
> 
> To achieve this, you have to add a constructor which accepts a boolean flag: `ICC_Profile(ProfileDeferralInfo pdi, boolean builtIn)`, and `ICC_ProfileRGB` and `ICC_ProfileGray` need to provide an additional constructor as well.
> 
> Here's [a diff to your branch which achieves this](https://github.com/honkar-jdk/jdk/compare/BuiltInCheck...aivanov-jdk:jdk:harshitha/8346465-built-inprofiles).
> 
> When [you compare the changeset that I propose to `jdk/master`](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:harshitha/8346465-built-inprofiles), there are less differences, and `BuiltInProfile` remains an interface. Yet two more files `ICC_ProfileRGB` and `ICC_ProfileGray` are modified.

After adding a constructor which accepts a boolean parameter, the constructors `ICC_ProfileRGB(ProfileDeferralInfo pdi)` and `ICC_ProfileGray(ProfileDeferralInfo pdi)` ? these two can be removed then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1963768913

From aivanov at openjdk.org  Thu Feb 20 15:21:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 15:21:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
Message-ID: <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>

On Thu, 20 Feb 2025 15:14:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Indeed, it *can be*, and I prefer this design. This way, the `isBuiltIn` field can't be changed after the object is constructed. I think it's a cleaner design.
>> 
>> To achieve this, you have to add a constructor which accepts a boolean flag: `ICC_Profile(ProfileDeferralInfo pdi, boolean builtIn)`, and `ICC_ProfileRGB` and `ICC_ProfileGray` need to provide an additional constructor as well.
>> 
>> Here's [a diff to your branch which achieves this](https://github.com/honkar-jdk/jdk/compare/BuiltInCheck...aivanov-jdk:jdk:harshitha/8346465-built-inprofiles).
>> 
>> When [you compare the changeset that I propose to `jdk/master`](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:harshitha/8346465-built-inprofiles), there are less differences, and `BuiltInProfile` remains an interface. Yet two more files `ICC_ProfileRGB` and `ICC_ProfileGray` are modified.
>
> After adding a constructor which accepts a boolean parameter, the constructors `ICC_ProfileRGB(ProfileDeferralInfo pdi)` and `ICC_ProfileGray(ProfileDeferralInfo pdi)` ? these two can be removed then.

> Can't this field be final and be set in constructor of the class?
> > Indeed, it _can be_, and I prefer this design. This way, the `isBuiltIn` field can't be changed after the object is constructed. I think it's a cleaner design.

A cleaner diff between your latest commit and my commit on top: https://github.com/openjdk/jdk/compare/8da82c10b5be3b92655abef95fd5be0c8b6eaa00..6729625f39c0dc47cd2588906b1793611996ca10

This link shouldn't become invalid after either of us removes the corresponding branches from our forks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1963780521

From mbaesken at openjdk.org  Thu Feb 20 15:30:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Feb 2025 15:30:02 GMT
Subject: RFR: 8349751: AIX build failure after upgrade pipewire to 1.3.81
 [v4]
In-Reply-To: <jhz14jWG0VFeZq6X43kyDDq1fnD9OcIoRF81GDMonOY=.e19d98f7-a7a7-4318-8297-15ef5a31677a@github.com>
References: <iQvq24w33xdyQ23Ly72GPVx3VZi8OwXk9-XBoVaapNc=.852e0e34-3bda-4b89-908f-1b70c9f20c22@github.com>
 <FH_IfrJvUYeASaENDEa2tdahhsd6VUa9MFgOySIBIac=.d28b27f8-c5fd-406b-b1df-99b170e69ba2@github.com>
 <jhz14jWG0VFeZq6X43kyDDq1fnD9OcIoRF81GDMonOY=.e19d98f7-a7a7-4318-8297-15ef5a31677a@github.com>
Message-ID: <J1wBlx5gYmaPhTbIIdvRkgfldfC3-1kBcwadhmMsbpg=.5fb16388-1c03-44eb-b490-d82b2f9f07d7@github.com>

On Fri, 14 Feb 2025 04:52:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master
>>  - move fix to spa/utils/endian.h
>>  - merge "if defined"
>>  - 8349751: AIX build failure after upgrade pipewire to 1.3.81
>>  - replace "\t" with "    ", part 2
>>  - replace "\t" with "    "
>>  - 8348600: Update PipeWire to 1.3.81
>
> FWIW
> (1) I do not like JDK changes in upstream files we import
> (2) This really needs to be done by the port owners.
> (3) I do not like JDK changes in upstream files we import
> Yes, I'm repeating that. We do have one case of changes which never made it into upstream in some X11 copied code from xwd because xwd is an app and doesn't care about resource leakage (ie there are upstream unfixed bugs). But I don't think we need to expand that precedent.
> This change needs to be up-streamed. I do not want the burden of 'remembering' this.
> Let's call this the last time we include this into JDK unless it comes from pipewire.

> @prrace: I wonder if pipewire should be build on any platform other than linux. Is there any usage on other UNIX systems (AIX/BSD/...)?

According to  https://pipewire.org/  pipewire is a project/lib  for Linux . 
In the pipewire coding imported into OpenJDK I also find some BSD related ifdefs so parts of pipewire might also work on BSD
`spa/utils/endian.h:8:#if defined(__FreeBSD__) || defined(__MidnightBSD__)
`

Not sure now much sense this all makes on AIX. As far as I understand , pipewire was imported into OpenJDK for java.awt.Robot support for Wayland,  the change was
8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots
https://github.com/openjdk/jdk/commit/9d7bf5329e5a0393553bca2e3a51ad1125b41b96
Seems we should clarify the Wayland situation on AIX first, I could not find much about this so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/23543#issuecomment-2671840543

From honkar at openjdk.org  Thu Feb 20 18:17:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Feb 2025 18:17:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
Message-ID: <IBiw2JqS48X4okn5Sr3ao3z5smj3X9ckOQERed_-X44=.0ac5ab15-af9a-4bab-9915-fbbf7abac69c@github.com>

On Thu, 20 Feb 2025 14:42:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc change
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1164:
> 
>> 1162:      *         array can not be interpreted as valid tag data, corresponding to
>> 1163:      *         the {@code tagSignature}
>> 1164:      * @throws IllegalArgumentException if this is a profile for one of the
> 
> `IllegalStateException` better describes the reason: the argument to the method can be perfectly valid, but the internal state of the object doesn't allow modifications.

@aivanov-jdk 

_IllegalStateException  - Signals that a method has been invoked at an **illegal or inappropriate time.**_  
Since IllegalStateException is thrown to indicate more of an unstable state of object, it may not be what we want here. The exception is to be thrown when the ICC_Profile object invoking .setData() is JDK Built-in profile and IIlegalArgumentException more closely match this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964122293

From honkar at openjdk.org  Thu Feb 20 18:22:58 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Feb 2025 18:22:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
Message-ID: <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>

On Thu, 20 Feb 2025 14:40:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc change
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1154:
> 
>> 1152:      * This method is useful for advanced applications which need to access
>> 1153:      * profile data directly. Only non-built-in, application provided profiles
>> 1154:      * should be updated using this method.
> 
> What you mean is that only non-built-in profiles *can* be updated. The fix makes it impossible to update built-in profiles.

I'll be inverting this statement to state what is NOT allowed rather than what is allowed by .setData() as below. Does the following sound better?


     * Note: JDK built-in ICC Profiles cannot be updated using this method
     * as it will result in IAE. JDK built-in profiles are those obtained by
     * {@code ICC_Profile.getInstance(int colorSpaceID)} where colorSpaceID
     * is one of the following:
     * {@link ColorSpace#CS_sRGB}, {@link ColorSpace#CS_LINEAR_RGB},
     * {@link ColorSpace#CS_PYCC}, {@link ColorSpace#CS_GRAY} or
     * {@link ColorSpace#CS_CIEXYZ}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964129561

From aivanov at openjdk.org  Thu Feb 20 18:28:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 18:28:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
Message-ID: <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>

On Thu, 20 Feb 2025 18:20:52 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1154:
>> 
>>> 1152:      * This method is useful for advanced applications which need to access
>>> 1153:      * profile data directly. Only non-built-in, application provided profiles
>>> 1154:      * should be updated using this method.
>> 
>> What you mean is that only non-built-in profiles *can* be updated. The fix makes it impossible to update built-in profiles.
>
> I'll be inverting this statement to state what is NOT allowed rather than what is allowed by .setData() as below. Does the following sound better?
> 
> 
>      * Note: JDK built-in ICC Profiles cannot be updated using this method
>      * as it will result in IAE. JDK built-in profiles are those obtained by
>      * {@code ICC_Profile.getInstance(int colorSpaceID)} where colorSpaceID
>      * is one of the following:
>      * {@link ColorSpace#CS_sRGB}, {@link ColorSpace#CS_LINEAR_RGB},
>      * {@link ColorSpace#CS_PYCC}, {@link ColorSpace#CS_GRAY} or
>      * {@link ColorSpace#CS_CIEXYZ}

This is clearer.

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1164:
>> 
>>> 1162:      *         array can not be interpreted as valid tag data, corresponding to
>>> 1163:      *         the {@code tagSignature}
>>> 1164:      * @throws IllegalArgumentException if this is a profile for one of the
>> 
>> `IllegalStateException` better describes the reason: the argument to the method can be perfectly valid, but the internal state of the object doesn't allow modifications.
>
> @aivanov-jdk 
> 
> _IllegalStateException  - Signals that a method has been invoked at an **illegal or inappropriate time.**_  
> Since IllegalStateException is thrown to indicate more of an unstable state of object, it may not be what we want here. The exception is to be thrown when the ICC_Profile object invoking .setData() is JDK Built-in profile and IIlegalArgumentException more closely match this case.

The javadoc for `IllegalArgumentException` says, <q cite="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/IllegalArgumentException.html">Thrown to indicate that a method has been passed <em>an illegal or inappropriate argument</em>.</q> (Emphasis mine.)

Getting an `IllegalArgumentException` for a valid argument would be confusing.

`IllegalStateException`, as you said, ?signals that a method has been invoked at an <em>illegal or inappropriate</em> time?. It's exactly the state of the object: a *built-in* color profile cannot be modified.

Although, there's no time where such a modification will be allowed, I still think `IllegalStateException` better conveys the meaning: changes to built-in profiles are *never* allowed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964136111
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964135080

From honkar at openjdk.org  Thu Feb 20 18:46:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Feb 2025 18:46:52 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
Message-ID: <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>

On Thu, 20 Feb 2025 18:25:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Although, there's no time where such a modification will be allowed

Exactly, it will throw exception every time a built-In profile is passed unlike IllegalStateException which is thrown only during an inappropriate time for instance when you are trying to add an element to the queue when it is already full. Plus setData() already throws IAE for other invalid argument cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964161347

From honkar at openjdk.org  Thu Feb 20 19:40:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 20 Feb 2025 19:40:52 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
Message-ID: <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>

On Thu, 20 Feb 2025 15:19:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> After adding a constructor which accepts a boolean parameter, the constructors `ICC_ProfileRGB(ProfileDeferralInfo pdi)` and `ICC_ProfileGray(ProfileDeferralInfo pdi)` ? these two can be removed then.
>
>> Can't this field be final and be set in constructor of the class?
>> > Indeed, it _can be_, and I prefer this design. This way, the `isBuiltIn` field can't be changed after the object is constructed. I think it's a cleaner design.
> 
> A cleaner diff between your latest commit and my commit on top: https://github.com/openjdk/jdk/compare/8da82c10b5be3b92655abef95fd5be0c8b6eaa00..6729625f39c0dc47cd2588906b1793611996ca10
> 
> This link shouldn't become invalid after either of us removes the corresponding branches from our forks.

Both the approaches - setting isBuiltIn in constructor vs in the static block, were evaluated previously. Setting it via constructor meant that we could mark the profile as Built-In only when it was constructed using ProfileDeferralInfo and modifying all the constructors - ICC_Profile, ICC_ProfileRGB, ICC_ProfileGray whereas setting it in static block meant minimal changes to existing code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964230209

From prr at openjdk.org  Thu Feb 20 20:36:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 20 Feb 2025 20:36:52 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
 <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
Message-ID: <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>

On Thu, 20 Feb 2025 18:44:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The javadoc for `IllegalArgumentException` says, <q cite="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/IllegalArgumentException.html">Thrown to indicate that a method has been passed <em>an illegal or inappropriate argument</em>.</q> (Emphasis mine.)
>> 
>> Getting an `IllegalArgumentException` for a valid argument would be confusing.
>> 
>> `IllegalStateException`, as you said, ?signals that a method has been invoked at an <em>illegal or inappropriate</em> time?. It's exactly the state of the object: a *built-in* color profile cannot be modified.
>> 
>> Although, there's no time where such a modification will be allowed, I still think `IllegalStateException` better conveys the meaning: changes to built-in profiles are *never* allowed.
>
>> Although, there's no time where such a modification will be allowed
> 
> Exactly, it will throw exception every time a built-In profile is passed unlike IllegalStateException which is thrown only during an inappropriate time for instance when you are trying to add an element to the queue when it is already full. Plus setData() already throws IAE for other invalid argument cases.

Although it is not a checked exception, the fact that IllegalArgumentException is already documented on this method is considered to outweigh any benefit of a new Exception type such as IllegalStateException. And IllegalArgumentException is not that far off from existing usage.
Existing usage includes the case that "the specified data is not appropriate to be set in this profile".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964300315

From aivanov at openjdk.org  Thu Feb 20 21:01:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 21:01:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
Message-ID: <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>

On Thu, 20 Feb 2025 19:38:29 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> Can't this field be final and be set in constructor of the class?
>>> > Indeed, it _can be_, and I prefer this design. This way, the `isBuiltIn` field can't be changed after the object is constructed. I think it's a cleaner design.
>> 
>> A cleaner diff between your latest commit and my commit on top: https://github.com/openjdk/jdk/compare/8da82c10b5be3b92655abef95fd5be0c8b6eaa00..6729625f39c0dc47cd2588906b1793611996ca10
>> 
>> This link shouldn't become invalid after either of us removes the corresponding branches from our forks.
>
>> Indeed, it can be, and I prefer this design. This way, the isBuiltIn field can't be changed after the object is constructed. I think it's a cleaner design.
> 
> I agree, the approach you mentioned does have merits. After evaluating both approaches setting in static block was preferred over the constructor for the following reason.
> Setting it via constructor meant that we could mark the profile as Built-In only when it was constructed using ProfileDeferralInfo and modifying all the constructors - ICC_Profile, ICC_ProfileRGB, ICC_ProfileGray whereas setting it in static block meant minimal changes to existing code.

I don't get the reason why it's bad to modify the constructors.

At this time, all the built-in profiles are created with `ProfileDeferralInfo`.

If `ProfileDeferralInfo` is used to create only built-in profiles, then modifying `ICC_Profile(ProfileDeferralInfo pdi)` is enough:


    ICC_Profile(ProfileDeferralInfo pdi) {
        deferralInfo = pdi;
        isBuiltIn = true;
    }


And this is a *minimal* change.

When the `isBuiltIn` is final, it's much easier to find where the value gets set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964330041

From acobbs at openjdk.org  Thu Feb 20 21:05:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 20 Feb 2025 21:05:22 GMT
Subject: RFR: 8261669: Add lint warning for widening primitive conversions that
 lose information
Message-ID: <L3ZCBWN8gnupOXcvzNmHKzAjOUspOTOAiVcs3WPMMR0=.af62fcab-de7c-4c41-80ab-7ff0805881f5@github.com>

This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.

I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!

Currently, we generate this warning, but only for assignment operators, e.g.:

int x = 0;
x += 1.0f;   // warning here


This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:

void method(float f) { }
...
float a = 0x10000001;   // warning here
method(0x10000001);     // warning here


It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:

float f1 = 0x10000000;     // no warning here

The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.

As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:


float a = (float)0x10000001;   // no warning here

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

Commit messages:
 - Warn for more widening primitive conversions that lose information.

Changes: https://git.openjdk.org/jdk/pull/23718/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23718&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8261669
  Stats: 187 lines in 15 files changed: 149 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/23718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23718/head:pull/23718

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

From aivanov at openjdk.org  Thu Feb 20 21:31:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 21:31:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
 <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
 <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>
Message-ID: <dYO5OMO-32FIeqKmQ5Ahm7nukivt8ak9kZV4VfjGAZE=.0da748a6-3354-4701-abe6-12529f86ce83@github.com>

On Thu, 20 Feb 2025 20:34:19 GMT, Phil Race <prr at openjdk.org> wrote:

>>> Although, there's no time where such a modification will be allowed
>> 
>> Exactly, it will throw exception every time a built-In profile is passed unlike IllegalStateException which is thrown only during an inappropriate time for instance when you are trying to add an element to the queue when it is already full. Plus setData() already throws IAE for other invalid argument cases.
>
> Although it is not a checked exception, the fact that IllegalArgumentException is already documented on this method is considered to outweigh any benefit of a new Exception type such as IllegalStateException. And IllegalArgumentException is not that far off from existing usage.
> Existing usage includes the case that "the specified data is not appropriate to be set in this profile".

> > Although, there's no time where such a modification will be allowed
> 
> Exactly, it will throw exception every time a built-In profile is passed unlike IllegalStateException which is thrown only during an inappropriate time for instance when you are trying to add an element to the queue when it is already full. Plus setData() already throws IAE for other invalid argument cases.

I see no contradiction here. Inappropriate time is a vague definition. For built-in object, it is always inappropriate time to call `setData`.

`IllegalArgumentException` implies that the argument is invalid, and if I change the argument, the call will succeed ? but the call will never succeed for a built-in profile *because **the state of the object** doesn't allow it*.

This is why `IllegalStateException` is more appropriate.

> Although it is not a checked exception, the fact that IllegalArgumentException is already documented on this method is considered to outweigh any benefit of a new Exception type such as IllegalStateException.

I do not agree here. The exception type should convey the reason it's thrown, otherwise there wouldn't be so many types of exceptions.

And two `@throws` with the same type aren't allowed in javadoc, which means you have to add the new reason to throw `IllegalArgumentException` into the existing one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964365376

From aivanov at openjdk.org  Thu Feb 20 21:38:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 20 Feb 2025 21:38:52 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <dYO5OMO-32FIeqKmQ5Ahm7nukivt8ak9kZV4VfjGAZE=.0da748a6-3354-4701-abe6-12529f86ce83@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
 <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
 <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>
 <dYO5OMO-32FIeqKmQ5Ahm7nukivt8ak9kZV4VfjGAZE=.0da748a6-3354-4701-abe6-12529f86ce83@github.com>
Message-ID: <jmiM1pQeizXskBh46w-ENQtn8-paYHHeQ8RQZKV7Ozg=.f4436bc1-bcde-422b-8074-269785dfbdf3@github.com>

On Thu, 20 Feb 2025 21:29:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Although it is not a checked exception, the fact that IllegalArgumentException is already documented on this method is considered to outweigh any benefit of a new Exception type such as IllegalStateException. And IllegalArgumentException is not that far off from existing usage.
>> Existing usage includes the case that "the specified data is not appropriate to be set in this profile".
>
>> > Although, there's no time where such a modification will be allowed
>> 
>> Exactly, it will throw exception every time a built-In profile is passed unlike IllegalStateException which is thrown only during an inappropriate time for instance when you are trying to add an element to the queue when it is already full. Plus setData() already throws IAE for other invalid argument cases.
> 
> I see no contradiction here. Inappropriate time is a vague definition. For built-in object, it is always inappropriate time to call `setData`.
> 
> `IllegalArgumentException` implies that the argument is invalid, and if I change the argument, the call will succeed ? but the call will never succeed for a built-in profile *because **the state of the object** doesn't allow it*.
> 
> This is why `IllegalStateException` is more appropriate.
> 
>> Although it is not a checked exception, the fact that IllegalArgumentException is already documented on this method is considered to outweigh any benefit of a new Exception type such as IllegalStateException.
> 
> I do not agree here. The exception type should convey the reason it's thrown, otherwise there wouldn't be so many types of exceptions.
> 
> And two `@throws` with the same type aren't allowed in javadoc, which means you have to add the new reason to throw `IllegalArgumentException` into the existing one.

Let's consider a scenario.

If I call `setData` with `tagSignature` and `tagData` which cannot be interpreted correctly, I get `IllegalArgumentException`, which is reasonable ? I passed invalid arguments.

Then if I call `setData` with valid values for `tagSignature` and `tagData`, the call succeeds even with a built-in color profile. After this fix, this call would fail with `IllegalArgumentException` but I know that the arguments are **valid** because the call succeeded previously. And however I change the arguments, the call will never succeed.

Throwing `IllegalStateException` will convey the updated behaviour in a cleaner way: it is *the state* of the object that makes the call to fail, not the arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964372049

From prr at openjdk.org  Thu Feb 20 21:58:16 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 20 Feb 2025 21:58:16 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <jmiM1pQeizXskBh46w-ENQtn8-paYHHeQ8RQZKV7Ozg=.f4436bc1-bcde-422b-8074-269785dfbdf3@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
 <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
 <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>
 <dYO5OMO-32FIeqKmQ5Ahm7nukivt8ak9kZV4VfjGAZE=.0da748a6-3354-4701-abe6-12529f86ce83@github.com>
 <jmiM1pQeizXskBh46w-ENQtn8-paYHHeQ8RQZKV7Ozg=.f4436bc1-bcde-422b-8074-269785dfbdf3@github.com>
Message-ID: <bZq-yRvuufJ0O8aR6C8uLnMspxcYxWhp4NTEJ8Jwf54=.c00b75d7-8380-4a06-9735-528be2d9c020@github.com>

On Thu, 20 Feb 2025 21:36:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > Although, there's no time where such a modification will be allowed
>>> 
>>> Exactly, it will throw exception every time a built-In profile is passed unlike IllegalStateException which is thrown only during an inappropriate time for instance when you are trying to add an element to the queue when it is already full. Plus setData() already throws IAE for other invalid argument cases.
>> 
>> I see no contradiction here. Inappropriate time is a vague definition. For built-in object, it is always inappropriate time to call `setData`.
>> 
>> `IllegalArgumentException` implies that the argument is invalid, and if I change the argument, the call will succeed ? but the call will never succeed for a built-in profile *because **the state of the object** doesn't allow it*.
>> 
>> This is why `IllegalStateException` is more appropriate.
>> 
>>> Although it is not a checked exception, the fact that IllegalArgumentException is already documented on this method is considered to outweigh any benefit of a new Exception type such as IllegalStateException.
>> 
>> I do not agree here. The exception type should convey the reason it's thrown, otherwise there wouldn't be so many types of exceptions.
>> 
>> And two `@throws` with the same type aren't allowed in javadoc, which means you have to add the new reason to throw `IllegalArgumentException` into the existing one.
>
> Let's consider a scenario.
> 
> If I call `setData` with `tagSignature` and `tagData` which cannot be interpreted correctly, I get `IllegalArgumentException`, which is reasonable ? I passed invalid arguments.
> 
> Then if I call `setData` with valid values for `tagSignature` and `tagData`, the call succeeds even with a built-in color profile. After this fix, this call would fail with `IllegalArgumentException` but I know that the arguments are **valid** because the call succeeded previously. And however I change the arguments, the call will never succeed.
> 
> Throwing `IllegalStateException` will convey the updated behaviour in a cleaner way: it is *the state* of the object that makes the call to fail, not the arguments.

> And two @throws with the same type aren't allowed in javadoc, which means you have to add the new reason to throw IllegalArgumentException into the existing one.

That's demonstrably untrue. This method already has two.

Regarding the scenario above, this apparent and has all been considered already and the IAE is the preferred solution.

And FWIW I don't think ISE is really any better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964393430

From honkar at openjdk.org  Fri Feb 21 00:50:45 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Feb 2025 00:50:45 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  javadoc update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/8da82c10..977f468c

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

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

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

From honkar at openjdk.org  Fri Feb 21 00:56:57 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 21 Feb 2025 00:56:57 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
Message-ID: <ho_Pj0SdJG1a_H0dB_oHR2beH9z1D5Y0AJ4BROMq8I4=.eea33687-ccce-4208-a660-317179ffefff@github.com>

On Thu, 20 Feb 2025 18:26:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'll be inverting this statement to state what is NOT allowed rather than what is allowed by .setData() as below. Does the following sound better?
>> 
>> 
>>      * Note: JDK built-in ICC Profiles cannot be updated using this method
>>      * as it will result in IAE. JDK built-in profiles are those obtained by
>>      * {@code ICC_Profile.getInstance(int colorSpaceID)} where colorSpaceID
>>      * is one of the following:
>>      * {@link ColorSpace#CS_sRGB}, {@link ColorSpace#CS_LINEAR_RGB},
>>      * {@link ColorSpace#CS_PYCC}, {@link ColorSpace#CS_GRAY} or
>>      * {@link ColorSpace#CS_CIEXYZ}
>
> This is clearer.

Looks like my previous commit was not reflected. I have update it now.

@prrace Updated PR and CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1964583365

From duke at openjdk.org  Fri Feb 21 02:31:42 2025
From: duke at openjdk.org (Jeremy)
Date: Fri, 21 Feb 2025 02:31:42 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v3]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <IBhSrtqI0EBx4bZwYKUVB8KPQqIziaIbR5u2B77tuWs=.30c1e8c9-a4ae-4ebd-b8eb-07a1ed66bd3e@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)

Jeremy has updated the pull request incrementally with four additional commits since the last revision:

 - 8160327: alphabetize imports
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/22898#discussion_r1956718373
 - 8160327: fallback to using MarkerSegment if ExifMarkerSegment fails
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/22898#discussion_r1955194737
   
   "I would have supposed that if there's an Exif segment we don't like it would be best to just act like the segment isn't there."
 - 8160327: include support for JFIF *and* EXIF thumbnails together
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/22898#issuecomment-2666324177
   
   As mentioned here ( https://github.com/openjdk/jdk/pull/22898#issuecomment-2666949882 ) we'll need to update some documentation about thumbnails.
 - 8160327: moving test + resources to separate directory
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/22898#issuecomment-2657721887

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/20d44cfb..a67369a6

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

  Stats: 143 lines in 11 files changed: 60 ins; 55 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/22898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898

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

From rmahajan at openjdk.org  Fri Feb 21 16:29:08 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Fri, 21 Feb 2025 16:29:08 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v5]
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:

  use Macros TRY CATCH_BAD_ALLOC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23470/files
  - new: https://git.openjdk.org/jdk/pull/23470/files/5a7cd348..ffc83d76

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

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

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

From achung at openjdk.org  Fri Feb 21 19:42:56 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 21 Feb 2025 19:42:56 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v2]
In-Reply-To: <GE04jcZw1ngsKTFuscpTdXo1cJUxEBTl2CwbNd8MBr4=.be5f47db-7611-4698-a736-7fb28d1bcfd3@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <GE04jcZw1ngsKTFuscpTdXo1cJUxEBTl2CwbNd8MBr4=.be5f47db-7611-4698-a736-7fb28d1bcfd3@github.com>
Message-ID: <ceanIiMvibZ2bDy9NOTxW3kztQsEvk6tJ9xGyqEIhYM=.8ceec4f9-380a-4a28-8c00-f725fedbf8c7@github.com>

On Fri, 14 Feb 2025 20:33:26 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add max width wiggle room for mac
>  - When HarfBuzz omits glyphs, assume zero advance (not early line break)

Also, update copyright years on changed files

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

PR Review: https://git.openjdk.org/jdk/pull/23603#pullrequestreview-2634053798

From bpb at openjdk.org  Fri Feb 21 19:42:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 21 Feb 2025 19:42:58 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v3]
In-Reply-To: <IBhSrtqI0EBx4bZwYKUVB8KPQqIziaIbR5u2B77tuWs=.30c1e8c9-a4ae-4ebd-b8eb-07a1ed66bd3e@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <IBhSrtqI0EBx4bZwYKUVB8KPQqIziaIbR5u2B77tuWs=.30c1e8c9-a4ae-4ebd-b8eb-07a1ed66bd3e@github.com>
Message-ID: <GqLT1rWUBAtlM5rUhZD26HeO-Mo92h0XLIKPVt6V-rM=.95766d47-5950-4617-b6a6-f57b363503f9@github.com>

On Fri, 21 Feb 2025 02:31:42 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - 8160327: alphabetize imports
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#discussion_r1956718373
>  - 8160327: fallback to using MarkerSegment if ExifMarkerSegment fails
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#discussion_r1955194737
>    
>    "I would have supposed that if there's an Exif segment we don't like it would be best to just act like the segment isn't there."
>  - 8160327: include support for JFIF *and* EXIF thumbnails together
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#issuecomment-2666324177
>    
>    As mentioned here ( https://github.com/openjdk/jdk/pull/22898#issuecomment-2666949882 ) we'll need to update some documentation about thumbnails.
>  - 8160327: moving test + resources to separate directory
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#issuecomment-2657721887

The code changes now look good. I've not looked at the test yet but I see that it's been put in its own directory along with the images which is good. I don't think that the images need the `jdk_8160327` prefix however.

Has it been determined which of these images can legitimately be included, aside from SV650?

Also, as I mentioned before, I think that the JPEG metadata specification will need to slightly updated to cover the modified thumbnail behavior. This change will require a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2675396159

From achung at openjdk.org  Fri Feb 21 19:42:57 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 21 Feb 2025 19:42:57 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters
In-Reply-To: <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
Message-ID: <VNMDkT53NXoPp9sgfF6iJqObLrHJEhRsdmOAMjbKhQc=.bbf8c028-78eb-45e3-8079-f942984444fe@github.com>

On Fri, 14 Feb 2025 00:04:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Early days but the test fails on macOS
> Exception in thread "main" java.lang.RuntimeException: nextOffset 1 for char 00ad using font Dialog: 2 != 1
> 	at FormatCharAdvanceTest.assertEqual(FormatCharAdvanceTest.java:289)
> 	at FormatCharAdvanceTest.testChar(FormatCharAdvanceTest.java:282)
> 	at FormatCharAdvanceTest.testChars(FormatCharAdvanceTest.java:165)
> 	at FormatCharAdvanceTest.main(FormatCharAdvanceTest.java:154)

> @prrace Two findings here:
> 
> First, it looks like macOS needs an extra pixel of wiggle room in the max string width that we measure; I've given it two pixels, just to be extra sure that the test is stable.

Should you add only these pixels when running the test on macos? Or do these pixels not matter on other platforms?

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

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2675394575

From dgredler at openjdk.org  Fri Feb 21 21:13:16 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 21 Feb 2025 21:13:16 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
Message-ID: <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>

> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
> 
> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
> 
> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
> 
> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
> 
> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23603/files
  - new: https://git.openjdk.org/jdk/pull/23603/files/16143307..b9b707ae

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

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

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

From dgredler at openjdk.org  Fri Feb 21 21:15:52 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 21 Feb 2025 21:15:52 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters
In-Reply-To: <VNMDkT53NXoPp9sgfF6iJqObLrHJEhRsdmOAMjbKhQc=.bbf8c028-78eb-45e3-8079-f942984444fe@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <LouAFlpPOgoN3T6Ogep1acCbVX_aRUi-II31eDLAh5U=.d5d82a25-fbd6-4aa8-bee7-18c5c7969db3@github.com>
 <VNMDkT53NXoPp9sgfF6iJqObLrHJEhRsdmOAMjbKhQc=.bbf8c028-78eb-45e3-8079-f942984444fe@github.com>
Message-ID: <Qz8HVrxNiPtv191rKsm4nGPK28kJujrBfXKMSOQ0z4s=.b1642467-596b-4965-8dc3-14c3893d2445@github.com>

On Fri, 21 Feb 2025 19:39:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Should you add only these pixels when running the test on macos? Or do these pixels not matter on other platforms?

It doesn't matter on other platforms, since it's just a little bit of extra leniency. I'm relatively new to the codebase, but the other tests I've seen that run similar checks just add the necessary leniency across the board.

> Also, update copyright years on changed files

Done, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23603#issuecomment-2675553179

From kizune at openjdk.org  Fri Feb 21 21:54:00 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 21 Feb 2025 21:54:00 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v11]
In-Reply-To: <2NR4iR7XxODCUtD2RzMbBIhXL9ZG8lbfCZ8Hr6wL1LA=.5256ca35-3fa8-43cd-afff-0bd9ed6da0f6@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com>
 <EQ62MWrzPaEktpIYkRAWHdzEdwsTNHJvrdYjF2U1WIc=.c5d23c6c-1184-41f6-b9b5-88c3b822e3c0@github.com>
 <2NR4iR7XxODCUtD2RzMbBIhXL9ZG8lbfCZ8Hr6wL1LA=.5256ca35-3fa8-43cd-afff-0bd9ed6da0f6@github.com>
Message-ID: <2IbRtCsQ6v5PzUGrVC5ul7U8OZagJzSEuxAXMchlzrM=.fb7949cb-624a-4fe5-a2a2-0158e9af7e84@github.com>

On Tue, 28 Jan 2025 15:56:54 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

> Am I right that you don't mind to accept the behavior change you mentioned

I am okay with the most of it. Now when you mentioned about ignoring scrolling i think i will need to do some additional testing with the textarea in the scrollpane to see how it reacts on the scrolling/replacement of selection that starts or ends outside of the visible view. I will comment on that when i do some testing there. And no, even if i will be satisfied myself with the result of the testing i would not approve pull request with the unanswered technical threads. It is just not a right thing to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2675620897

From duke at openjdk.org  Fri Feb 21 23:30:55 2025
From: duke at openjdk.org (Jeremy)
Date: Fri, 21 Feb 2025 23:30:55 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v3]
In-Reply-To: <IBhSrtqI0EBx4bZwYKUVB8KPQqIziaIbR5u2B77tuWs=.30c1e8c9-a4ae-4ebd-b8eb-07a1ed66bd3e@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <IBhSrtqI0EBx4bZwYKUVB8KPQqIziaIbR5u2B77tuWs=.30c1e8c9-a4ae-4ebd-b8eb-07a1ed66bd3e@github.com>
Message-ID: <myp9tmZdjeRoKzywe7SIze1H4j1bqpuegPt4EV7O6hc=.d16e95c1-0683-4183-88ad-a1bd6588a3df@github.com>

On Fri, 21 Feb 2025 02:31:42 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)
>
> Jeremy has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - 8160327: alphabetize imports
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#discussion_r1956718373
>  - 8160327: fallback to using MarkerSegment if ExifMarkerSegment fails
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#discussion_r1955194737
>    
>    "I would have supposed that if there's an Exif segment we don't like it would be best to just act like the segment isn't there."
>  - 8160327: include support for JFIF *and* EXIF thumbnails together
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#issuecomment-2666324177
>    
>    As mentioned here ( https://github.com/openjdk/jdk/pull/22898#issuecomment-2666949882 ) we'll need to update some documentation about thumbnails.
>  - 8160327: moving test + resources to separate directory
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/22898#issuecomment-2657721887

I don't know how to initiate a CSR. Is that something I can initiate, or does that require a more senior sponsor?

I'm not done with the test files yet. (I'll make a note in this PR when I am.)

Regarding sample files:
I replaced the jpeg file that embeds a JFIF *and* EXIF thumbnail. I still need to:
A. replace the jpeg file "exif-rgb-thumbnail" and
B. review this thread for other interesting test cases

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2675814497

From achung at openjdk.org  Fri Feb 21 23:39:51 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 21 Feb 2025 23:39:51 GMT
Subject: RFR: 8349932: PSPrinterJob sometimes generates unnecessary
 PostScript commands [v2]
In-Reply-To: <7gU4pI25KSO4AuaZShG8nT5OwDOX9HZM0U-N6dnENHk=.2a305b2a-cc93-42ef-bec4-78163f7bf6e8@github.com>
References: <WT4ggVnNFHDF_aOPWwxU3RoziXv8w0YP4ZQIqnL9q-0=.de9cf8f7-6fb5-4da5-9ca5-50c11e33c792@github.com>
 <7gU4pI25KSO4AuaZShG8nT5OwDOX9HZM0U-N6dnENHk=.2a305b2a-cc93-42ef-bec4-78163f7bf6e8@github.com>
Message-ID: <P2sf_ug-f-vWi-GI1MriGqBoSsSRAIPvyUF7rd82840=.4dadcb22-6acf-41e4-b075-06352b9b9cbc@github.com>

On Fri, 14 Feb 2025 23:51:49 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Trying to print text which is ignored (e.g. `\r` or `\n` or `\t`), or trying to print empty shapes generates PostScript graphics context setup commands which are not necessary. This can lead to unnecessarily large PostScript files, and can complicate analysis / comparison of these files.
>> 
>> Two methods are impacted:
>> 
>> `PSPrinterJob.textOut(...)`: The `prepDrawing()` method should only be called once all sanity checks have passed. Otherwise, it will add PS graphics context setup commands that may not be necessary.
>> 
>> `PSPrinterJob.deviceFill(...)`: This method should do nothing if the provided `PathIterator` is empty. Otherwise, it will add PS graphics context setup commands that are not necessary.
>> 
>> The changes in `PSPrinterJob.textOut(...)` eliminated a big `if` statement, therefore include some indentation changes. Checking the diff with whitespace ignored should be helpful here.
>> 
>> A test case is included.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Consider OS line separator when inspecting PostScript

test passing on macos, changes look good

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23595#pullrequestreview-2634478219

From bpb at openjdk.org  Sat Feb 22 00:21:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 22 Feb 2025 00:21:55 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v3]
In-Reply-To: <myp9tmZdjeRoKzywe7SIze1H4j1bqpuegPt4EV7O6hc=.d16e95c1-0683-4183-88ad-a1bd6588a3df@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <IBhSrtqI0EBx4bZwYKUVB8KPQqIziaIbR5u2B77tuWs=.30c1e8c9-a4ae-4ebd-b8eb-07a1ed66bd3e@github.com>
 <myp9tmZdjeRoKzywe7SIze1H4j1bqpuegPt4EV7O6hc=.d16e95c1-0683-4183-88ad-a1bd6588a3df@github.com>
Message-ID: <utSrp5WJhzetf-_2VIjtfstzth6bpKBwY_vmILNls_w=.b6eaa9b4-5f58-4e5c-bc45-4592edfa2877@github.com>

On Fri, 21 Feb 2025 23:28:26 GMT, Jeremy <duke at openjdk.org> wrote:

> I don't know how to initiate a CSR. Is that something I can initiate, or does that require a more senior sponsor?

I can do that, probably next week. We will need to update the JPEG metadata documentation.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2675864162

From azvegint at openjdk.org  Sat Feb 22 01:37:01 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 22 Feb 2025 01:37:01 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v5]
In-Reply-To: <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
Message-ID: <9uoZ7PkDagMXGDUf_0iXNMMudt7PhQloa6aQit1_MIY=.a8df79ae-f316-4b6e-a5c0-fd315b7da750@github.com>

On Fri, 21 Feb 2025 16:29:08 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Macros TRY CATCH_BAD_ALLOC

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2634579956

From azvegint at openjdk.org  Sat Feb 22 02:13:58 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 22 Feb 2025 02:13:58 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v6]
In-Reply-To: <p8ZXASmJRw0oE13mwM4RAJTP8Do-SVJlDic06DRXc5k=.e2ac0f2d-22c7-4090-8cbf-b4f8086b479a@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <p8ZXASmJRw0oE13mwM4RAJTP8Do-SVJlDic06DRXc5k=.e2ac0f2d-22c7-4090-8cbf-b4f8086b479a@github.com>
Message-ID: <SXUqC5q6UEal1b6_vZb4MAK-pUZwcAkZnhynmCmtoV8=.271dc76c-b0e5-47e2-b09f-bb4bf73a4246@github.com>

On Wed, 19 Feb 2025 23:04:39 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>> 
>> CI testing is green on all platforms.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test helper

Marked as reviewed by azvegint (Reviewer).

test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 43:

> 41:  * @key headful
> 42:  * @bug 6672644
> 43:  * @requires os.family != "mac"

Is there a reason to exclude it on mac?

Based on my local testing, the issue doesn't affect mac (test passes before and after the fix), but we can still run the test.

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

PR Review: https://git.openjdk.org/jdk/pull/23451#pullrequestreview-2634609767
PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1966393077

From duke at openjdk.org  Sun Feb 23 19:11:43 2025
From: duke at openjdk.org (Jeremy)
Date: Sun, 23 Feb 2025 19:11:43 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v4]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <Dv3mzDc8e4DC_-hDSeI_O5zW7341hMrFzzwXVntAErI=.0c83f9da-a205-478f-bb2d-60f674ab1e66@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)

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

 - 8160327: fix looping ImageFileDirectory vulnerability
   
   There was a `while` loop that someone could exploit to loop infinitely. Now we read exactly 2 iterations and stop.
 - 8160327: remove bug ID from image file names
   
   Now the bug ID is mentioned in their parent directory name.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/22898#issuecomment-2675396159
 - 8160327: replace image of unknown origin with my own image

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/a67369a6..366a8c37

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

  Stats: 36 lines in 11 files changed: 18 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/22898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898

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

From abhiscxk at openjdk.org  Mon Feb 24 03:11:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 24 Feb 2025 03:11:56 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v5]
In-Reply-To: <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
Message-ID: <rKcHSMU3rrBnVU1Vn7aa4UyUMNMQpkGeyKPsmiZfo8g=.43bb24f3-91f3-408a-ba40-d0291923b777@github.com>

On Fri, 21 Feb 2025 16:29:08 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Macros TRY CATCH_BAD_ALLOC

Marked as reviewed by abhiscxk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2635947369

From duke at openjdk.org  Mon Feb 24 05:48:51 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 24 Feb 2025 05:48:51 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v5]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <OoqYOznTcfDDfhlqaA-deRS94_e56WuZx1V3r5g6A_Q=.68d46fe1-7c6a-43af-9f74-4397b61e6990@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)

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

  8160327: replacing the "sony-d700" image
  
  The origins of that image were unknown, so we weren't sure if we had the rights to store it in the OpenJDK repo.
  
  I couldn't figure out how to create this kind of uncompressed thumbnail from an image editing app, so I spliced this new file together manually in a hex editor using the sony-d700 image as a blueprint.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/366a8c37..24b6feea

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

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

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

From duke at openjdk.org  Mon Feb 24 06:45:57 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 24 Feb 2025 06:45:57 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <StBjShoCDqYHka2087S2L3e5Zv6LKfIHSatMlcXT6XE=.a205db13-cb32-4cdd-a5db-ef61d4c2adfe@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <gJe9XEjgvVERbkblprJyjaISu-FT-CcCWUBXftF90ow=.f9a1ac3a-794d-41ed-bc66-8990706338c2@github.com>
 <StBjShoCDqYHka2087S2L3e5Zv6LKfIHSatMlcXT6XE=.a205db13-cb32-4cdd-a5db-ef61d4c2adfe@github.com>
Message-ID: <THFPsGSKnEy21crD0aLDay-lz30KqYrom2cHtzrHAxQ=.ea638966-e66c-42cf-8add-57e5ff8c4b1c@github.com>

On Fri, 14 Feb 2025 17:34:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 165:
>> 
>>> 163:                 ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN);
>>> 164:         if (input.readUnsignedShort() != TIFF_MAGIC) {
>>> 165:             throw new IllegalArgumentException("Bad magic number");
>> 
>> Where does this exception end up ? I would have supposed that if there's an Exif segment we don't like it would be best to just act like the segment isn't there.
>
> I concur.

When you first asked: this exception would be thrown all the way up to the JPEGImageReader's caller. (That is: calling `myJPEGReader.getNumThumbnails` would throw this IAE.)

As of this writing: now this exception is ignored. It is consumed in this code in JPEGMetaData:

            case JPEG.APP1:
                newGuy = new MarkerSegment(buffer);
                newGuy.loadData(buffer);

                if (newGuy.data.length > 5 &&
                        newGuy.data[0] == 'E' &&
                        newGuy.data[1] == 'x' &&
                        newGuy.data[2] == 'i' &&
                        newGuy.data[3] == 'f' &&
                        newGuy.data[4] == 0) {
                    try {
                        newGuy = new ExifMarkerSegment(newGuy);
                    } catch(Exception e) {
                        // This is intentionally empty.
                        // Now we fallback to keeping the generic MarkerSegment
                    }
                }
                break;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1967100476

From duke at openjdk.org  Mon Feb 24 07:11:55 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 24 Feb 2025 07:11:55 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v5]
In-Reply-To: <OoqYOznTcfDDfhlqaA-deRS94_e56WuZx1V3r5g6A_Q=.68d46fe1-7c6a-43af-9f74-4397b61e6990@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <OoqYOznTcfDDfhlqaA-deRS94_e56WuZx1V3r5g6A_Q=.68d46fe1-7c6a-43af-9f74-4397b61e6990@github.com>
Message-ID: <8a8UN_0ztfKz4bQ565qe0XvhIkTdfOkgXbqxdezgVk0=.06e333e9-fd6d-43c6-a6a3-af35ee648ca8@github.com>

On Mon, 24 Feb 2025 05:48:51 GMT, Jeremy <duke at openjdk.org> wrote:

>> This adds support for parsing thumbnails in an APP1 Exif marker.
>> 
>> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
>> 
>> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
>> 
>> The images used in this test are contributed by Brian and me.
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8160327: replacing the "sony-d700" image
>   
>   The origins of that image were unknown, so we weren't sure if we had the rights to store it in the OpenJDK repo.
>   
>   I couldn't figure out how to create this kind of uncompressed thumbnail from an image editing app, so I spliced this new file together manually in a hex editor using the sony-d700 image as a blueprint.

I think I've finished all the pending edits I had in mind. 

Regarding ownership of images:
One sample image comes from Brian, the rest come from me.

A few questions remain on my end:

1. The PR bot somehow flagged two of the test jpg files as executables (which it describes as "Errors"). Any recommendations on how to placate this error? (Should I just zip the images together?)

@bplb :
2. Do you still think a test case featuring an uncompressed RGB main image with a uncompressed RGB thumbnail is necessary?

I'm not sure off the top of my head how to generate this kind of image. It seems to me like reading any thumbnail is completely insulated from reading the main image, so mixing and matching combinations of main images and thumbnails shouldn't be an issue. (?)

3. Should I add a test that includes an EXIF thumbnail followed by a JFIF thumbnail? You asked about (and the original ticket included) an image that featured a JFIF thumbnail followed by an EXIF thumbnail, and this PR now covers that test case. But I think the JFIF logic is stricter and will probably throw an exception if the EXIF thumbnail appears first.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2677587816

From duke at openjdk.org  Mon Feb 24 07:11:58 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 24 Feb 2025 07:11:58 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <4H625H7VLnKi914MoDgvmj9MZYk-BpEBEKOASIGSZmg=.a48e81a7-22f7-4413-8dda-bbd2ab29fc65@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <4H625H7VLnKi914MoDgvmj9MZYk-BpEBEKOASIGSZmg=.a48e81a7-22f7-4413-8dda-bbd2ab29fc65@github.com>
Message-ID: <v0rzMTC3H8RwvoM-CM-1zRhDGim4CipV3dYzd7EkyMI=.819f539e-0c58-4d3d-bda0-782c541d99af@github.com>

On Fri, 14 Feb 2025 21:08:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8160327: fixing typo so `thumbnailPos` can be zero
>>   
>>   The `thumbnailLength` cannot be zero, but the position can be.
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/ExifMarkerSegment.java line 28:
> 
>> 26: package com.sun.imageio.plugins.jpeg;
>> 27: 
>> 28: import java.io.InputStream;
> 
> I suggest putting the imports on lines 28-51 in alphabetical order.

This is updated

> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 1758:
> 
>> 1756:             }
>> 1757: 
>> 1758:             // Now we know that there is a jfif segment and that iis is good
> 
> I think `iis` should be `it` in this comment.

This comment no longer exists after other revisions

> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java line 266:
> 
>> 264:                         && (buf[ptr+7] == 0)
>> 265:                         && (buf[ptr+8] == 0)) {
>> 266:                     newGuy = new ExifMarkerSegment(buffer);
> 
> The `IllegalArgumentException` from the `ExifMarkerSegment` constructor should be handled somehow. Perhaps just fall back to setting `newGuy` to a plain `MarkerSegment`?

This is updated (see this thread https://github.com/openjdk/jdk/pull/22898#discussion_r1955194737 )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1967118843
PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1967118674
PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1967118950

From duke at openjdk.org  Mon Feb 24 07:11:59 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 24 Feb 2025 07:11:59 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v2]
In-Reply-To: <DIDXMrPOXX53wCKhTmhafkLxJu_4wr0-icc8BfIWRdI=.f427025b-de79-4177-b8a8-492db8714913@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com>
 <s9eaFEw1SsaBNnWWdE0FFt9ExZA5vRf3TUbvyJrR2EM=.02b8dae5-e47a-45f0-aa69-7d6c3ec1a6d5@github.com>
 <_yMP6dnmDEc-ZIt0JfHpcCYCAwJz9KhZsdi5URkWHb0=.0528528c-06f1-4a6d-8e8f-45aa15b89043@github.com>
 <DIDXMrPOXX53wCKhTmhafkLxJu_4wr0-icc8BfIWRdI=.f427025b-de79-4177-b8a8-492db8714913@github.com>
Message-ID: <G198EtO0dHGtAOa0VC0S66ccLNu_BkP4CNngvBr-KHw=.642619a9-3f46-4f3b-91d4-cca13a2db088@github.com>

On Fri, 14 Feb 2025 23:58:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hmm. I think it better to address it now. Who knows when we'd get back to it.
>
> I have a patch which handles both JFIF and Exif thumbnails if this is not otherwise resolved. To revisit next week ...

I integrated Brian's patch ( https://github.com/openjdk/jdk/pull/22898#issuecomment-2666324177 ) into this PR: now we support both thumbnails and the JFIF thumbnail(s) are processed first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22898#discussion_r1967118787

From psadhukhan at openjdk.org  Mon Feb 24 08:21:48 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 24 Feb 2025 08:21:48 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v14]
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: <kBzBRBFvWFEhMG2tkvP678wrF8prIEkr9AFy8YYfpJo=.bd8d3ed7-b801-457d-b5ee-f5e5022c369b@github.com>

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

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

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - comment
 - Extend to Windows11 and later
 - Restore Windows 10 behavior
 - remove test file
 - Move text position w.r.t menuItem icon
 - retain diff of OFFSET between skin background start coord and skin coordinate
 - remove debug
 - Move icon w.r.t bullet skin width
 - Move icon w.r.t bullet skin width
 - ... and 8 more: https://git.openjdk.org/jdk/compare/613d6d1d...7f0849fc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/7cb51be9..7f0849fc

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

  Stats: 227049 lines in 5308 files changed: 112131 ins; 91591 del; 23327 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 duke at openjdk.org  Mon Feb 24 08:41:47 2025
From: duke at openjdk.org (anass baya)
Date: Mon, 24 Feb 2025 08:41:47 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v3]
In-Reply-To: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
Message-ID: <8vpEH1NFfYVvCvWlGRzcNIQxjgKtsMIfaiexbpVgEWw=.e026d686-9c02-453c-bebe-e0c38ea83774@github.com>

> The PR includes two fix : 
> 1 - The first fix targets proper rendering of the transparent image.
> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.

anass baya has updated the pull request incrementally with three additional commits since the last revision:

 - Enhancment step 3
 - Enhancement - step 2
 - enhancement - step 1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23430/files
  - new: https://git.openjdk.org/jdk/pull/23430/files/e65d7344..48ad43b7

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

  Stats: 85 lines in 4 files changed: 21 ins; 53 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/23430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23430/head:pull/23430

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

From duke at openjdk.org  Mon Feb 24 08:41:48 2025
From: duke at openjdk.org (Jeremy)
Date: Mon, 24 Feb 2025 08:41:48 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v3]
In-Reply-To: <Mmmss6KBvzV6xkYFyIjRM6nQXA8kuy20edJ0yZ2EgGg=.8189bbeb-38dd-4f4c-935c-0ec39e5b420e@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
 <UJKPU00GA0SvyPHXNCUoFIiRyTn_NyOKiHEQnrCUWBc=.3bd66306-b4d9-426f-9789-6fb5d5eb6cb8@github.com>
 <Mmmss6KBvzV6xkYFyIjRM6nQXA8kuy20edJ0yZ2EgGg=.8189bbeb-38dd-4f4c-935c-0ec39e5b420e@github.com>
Message-ID: <syHlmH8UfAbAWDBzdV4i-AzHA-6wNbQa_LtyBa63Mrs=.b567ad92-62f5-499a-95f0-fa73361c00cc@github.com>

On Tue, 4 Feb 2025 10:13:57 GMT, anass baya <duke at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 260:
>> 
>>> 258:             }
>>> 259:         };
>>> 260:     }
>> 
>> This may be outside the scope of this ticket, but I'm seeing similar code in Win32GraphicsConfig#createAcceleratedImage(..), X11GraphicsConfig#createAcceleratedImage(..), and GLXGraphicsConfig#createAcceleratedImage(..) .
>> 
>> Should those be looked at, or is there another ticket to explore those? (That is: are they also going to be opaque and the wrong resolution?)
>
> Hello @mickleness,
> The problem is not reproduced on windows !! I can see it only on mac

tldr: Wow / huh. You're right. Thanks for checking.

That code looks so suspicious that I did some digging:

(A. On Windows the TransparentWindowTest *says* it fails because Image.getTransparency() is OPAQUE, but the test is wrong: the window looks fine.)
B. It works because on Windows we end up using the TranslucentWindowPainter. We never invoke `Win32GraphicsConfig#createAcceleratedImage(..)` at all (unless the TransparentWindowTest invokes it directly).

I tested:
A. repainting on a timer (so we'd explicitly go through the RepaintManager), and 
B. an ellipse fill instead of a rectangle fill (to double-check that transparent pixels really were transparent).
C. using Window.setShape(..) instead of changing the window's background color to transparent (to make sure it followed the same path)

(... and I don't have access to any other platforms to make sure Linux is doing the right thing.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1943463224

From duke at openjdk.org  Mon Feb 24 08:41:48 2025
From: duke at openjdk.org (anass baya)
Date: Mon, 24 Feb 2025 08:41:48 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v3]
In-Reply-To: <syHlmH8UfAbAWDBzdV4i-AzHA-6wNbQa_LtyBa63Mrs=.b567ad92-62f5-499a-95f0-fa73361c00cc@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
 <UJKPU00GA0SvyPHXNCUoFIiRyTn_NyOKiHEQnrCUWBc=.3bd66306-b4d9-426f-9789-6fb5d5eb6cb8@github.com>
 <Mmmss6KBvzV6xkYFyIjRM6nQXA8kuy20edJ0yZ2EgGg=.8189bbeb-38dd-4f4c-935c-0ec39e5b420e@github.com>
 <syHlmH8UfAbAWDBzdV4i-AzHA-6wNbQa_LtyBa63Mrs=.b567ad92-62f5-499a-95f0-fa73361c00cc@github.com>
Message-ID: <VFhGre9vGTTA6WTBYu9BEG-nomgPNjkrMSlw-NuWhG0=.8e0cd62f-ca75-4cdf-80a0-1645a90d41e4@github.com>

On Wed, 5 Feb 2025 18:27:20 GMT, Jeremy <duke at openjdk.org> wrote:

>> Hello @mickleness,
>> The problem is not reproduced on windows !! I can see it only on mac
>
> tldr: Wow / huh. You're right. Thanks for checking.
> 
> That code looks so suspicious that I did some digging:
> 
> (A. On Windows the TransparentWindowTest *says* it fails because Image.getTransparency() is OPAQUE, but the test is wrong: the window looks fine.)
> B. It works because on Windows we end up using the TranslucentWindowPainter. We never invoke `Win32GraphicsConfig#createAcceleratedImage(..)` at all (unless the TransparentWindowTest invokes it directly).
> 
> I tested:
> A. repainting on a timer (so we'd explicitly go through the RepaintManager), and 
> B. an ellipse fill instead of a rectangle fill (to double-check that transparent pixels really were transparent).
> C. using Window.setShape(..) instead of changing the window's background color to transparent (to make sure it followed the same path)
> 
> (... and I don't have access to any other platforms to make sure Linux is doing the right thing.)

Hello @mickleness,
Yes, on Windows we use TranslucentWindowPainter.
I moved the PR to draft since I'm trying to simplify the scaling handler logic. I'll come back to you once I'm done with that.
This test is only for macOS. On Windows, it will fail because we don?t explicitly set the Translucent flag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1943473614

From aivanov at openjdk.org  Mon Feb 24 13:20:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 13:20:57 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v5]
In-Reply-To: <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
Message-ID: <mU3IoV0y_DIs9vus3vhJpmDQZhhoKBcZvhSCw5SBxgc=.4a26ad88-607c-4a8e-8ed3-3d64db5abb52@github.com>

On Fri, 21 Feb 2025 16:29:08 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Macros TRY CATCH_BAD_ALLOC

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2637059197

From aivanov at openjdk.org  Mon Feb 24 13:20:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 13:20:58 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
In-Reply-To: <YMVQLdEduxpFdPI1qORMLhSEUhFJZspvsKSjLuBKl0U=.99b47036-454a-4891-9ae0-f8a2fdc4302c@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <YMVQLdEduxpFdPI1qORMLhSEUhFJZspvsKSjLuBKl0U=.99b47036-454a-4891-9ae0-f8a2fdc4302c@github.com>
Message-ID: <KC-LSWUTtovt58leqhmvRtbA9pEwIu3Svl0nI2-s9A8=.a9688c8f-f34f-4c7f-b60c-4db3bad6dfc3@github.com>

On Sat, 8 Feb 2025 04:02:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> It would be good to check what type of exception the methods chain can throw, is it only std::bad_alloc()? if yes, then we can use TRY + CATCH_BAD_ALLOC. If we can get another exception, we should figure out how we can report this error to the user.

@mrserb Could you take another look?

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

PR Comment: https://git.openjdk.org/jdk/pull/23470#issuecomment-2678395367

From aivanov at openjdk.org  Mon Feb 24 16:54:01 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 16:54:01 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
Message-ID: <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>

On Fri, 21 Feb 2025 00:50:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> Fix consists of:
>> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
>> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
>> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
>> * JavaDoc update for setData() (CSR required)
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1163:

> 1161:      * {@link ColorSpace#CS_PYCC}, {@link ColorSpace#CS_GRAY} or
> 1162:      * {@link ColorSpace#CS_CIEXYZ}.
> 1163:      * </p>

Suggestion:

     * <p>
     * Note: JDK built-in ICC Profiles cannot be updated using this method
     * as it will result in {@code IllegalArgumentException}. JDK built-in
     * profiles are those obtained by
     * {@code ICC_Profile.getInstance(int colorSpaceID)}
     * where {@code colorSpaceID} is one of the following:
     * {@link ColorSpace#CS_sRGB}, {@link ColorSpace#CS_LINEAR_RGB},
     * {@link ColorSpace#CS_PYCC}, {@link ColorSpace#CS_GRAY} or
     * {@link ColorSpace#CS_CIEXYZ}.
     * </p>

You should spell `IllegalArgumentException` fully, it explicitly lists the exception thrown. And `colorSpaceID` should also be marked up with `{@code}`.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1170:

> 1168:      * @throws IllegalArgumentException if {@code tagSignature} is not a
> 1169:      *         signature as defined in the ICC specification.
> 1170:      * @throws IllegalArgumentException if a content of the {@code tagData}

This is an existing issue, if it's an issue: should the text say *?**the** content?* instead of *?**a** content?*? @prrace

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1175:

> 1173:      * @throws IllegalArgumentException if this is a profile for one of the
> 1174:      *         built-in pre-defined ColorSpaces, i.e. those which can be obtained
> 1175:      *         by calling {@code ICC_Profile.getInstance(int colorSpaceID)}

Suggestion:

     * @throws IllegalArgumentException if this is a built-in profile for one of the
     *         pre-defined color spaces, i.e. those which can be obtained
     *         by calling {@code ICC_Profile.getInstance(int colorSpaceID)}

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 42:

> 40:         System.out.println("CASE 1: Testing BuiltIn Profile");
> 41:         updateProfile(true);
> 42:         System.out.println("Passed \n");

Suggestion:

        System.out.println("Passed\n");

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 51:

> 49:     private static void updateProfile(boolean isBuiltIn) {
> 50:         ICC_Profile builtInProfile = ICC_Profile.getInstance(ColorSpace.CS_sRGB);
> 51:         //create a copy of the BuiltIn profile

Suggestion:

        // Create a copy of the built-in profile

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 58:

> 56:         byte[] headerData = iccProfile.getData(HEADER_TAG);
> 57:         int index = PROFILE_CLASS_START_INDEX;
> 58:         //set profile class to valid icSigInputClass = 0x73636E72

Suggestion:

        // Set profile class to valid icSigInputClass = 0x73636E72

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 66:

> 64:         if (isBuiltIn) {
> 65:             try {
> 66:                 //try updating a BuiltIn Profile, the following stmt should throw IAE

Suggestion:

                // Try updating a built-in profile, IAE is expected

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 68:

> 66:                 //try updating a BuiltIn Profile, the following stmt should throw IAE
> 67:                 iccProfile.setData(HEADER_TAG, headerData);
> 68:                 throw new RuntimeException("Test Failed ! IAE NOT thrown.");

Suggestion:

                throw new RuntimeException("Test Failed! IAE NOT thrown.");

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 76:

> 74:             }
> 75:         } else {
> 76:             //modifying custom profile should NOT throw IAE

Suggestion:

            // Modifying custom profile should NOT throw IAE

test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 33:

> 31:  */
> 32: public final class ICC_ProfileSetNullDataTest {
> 33:     private static final int[] colorSpace = new int [] {

Suggestion:

    private static final int[] colorSpace = new int[] {

test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 48:

> 46:             } catch (IllegalArgumentException e) {
> 47:                 return;
> 48:             }

The test won't run for **all** the cases if you after the first successful case???use `continue`.

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

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2637741457
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968002547
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968004976
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968009066
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968033857
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968022912
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968028128
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968027136
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968027393
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968028624
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968029468
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968032947

From aivanov at openjdk.org  Mon Feb 24 17:04:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 17:04:54 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <bZq-yRvuufJ0O8aR6C8uLnMspxcYxWhp4NTEJ8Jwf54=.c00b75d7-8380-4a06-9735-528be2d9c020@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
 <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
 <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>
 <dYO5OMO-32FIeqKmQ5Ahm7nukivt8ak9kZV4VfjGAZE=.0da748a6-3354-4701-abe6-12529f86ce83@github.com>
 <jmiM1pQeizXskBh46w-ENQtn8-paYHHeQ8RQZKV7Ozg=.f4436bc1-bcde-422b-8074-269785dfbdf3@github.com>
 <bZq-yRvuufJ0O8aR6C8uLnMspxcYxWhp4NTEJ8Jwf54=.c00b75d7-8380-4a06-9735-528be2d9c020@github.com>
Message-ID: <ENkkdylOSW9qqkzLUthdBXj_r68aERy0V2OK97IE_XE=.4e441653-ac4d-4966-a206-57226d12e781@github.com>

On Thu, 20 Feb 2025 21:55:43 GMT, Phil Race <prr at openjdk.org> wrote:

> > And two @throws with the same type aren't allowed in javadoc, which means you have to add the new reason to throw IllegalArgumentException into the existing one.
> 
> That's demonstrably untrue. This method already has two.

I was wrong here, the specification for [`ICC_Profile.html.setData`](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/color/ICC_Profile.html#setData(int,byte[])) correctly displays the two entries for `IllegalArgumentException`. The generated javadoc for the proposed changeset contains three entries for IAE.

I misremembered it, or it was a limitation in an IDE javadoc parser.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968059734

From aivanov at openjdk.org  Mon Feb 24 17:11:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 17:11:54 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <ENkkdylOSW9qqkzLUthdBXj_r68aERy0V2OK97IE_XE=.4e441653-ac4d-4966-a206-57226d12e781@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
 <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
 <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>
 <dYO5OMO-32FIeqKmQ5Ahm7nukivt8ak9kZV4VfjGAZE=.0da748a6-3354-4701-abe6-12529f86ce83@github.com>
 <jmiM1pQeizXskBh46w-ENQtn8-paYHHeQ8RQZKV7Ozg=.f4436bc1-bcde-422b-8074-269785dfbdf3@github.com>
 <bZq-yRvuufJ0O8aR6C8uLnMspxcYxWhp4NTEJ8Jwf54=.c00b75d7-8380-4a06-9735-528be2d9c020@github.com>
 <ENkkdylOSW9qqkzLUthdBXj_r68aERy0V2O
 K97IE_XE=.4e441653-ac4d-4966-a206-57226d12e781@github.com>
Message-ID: <jdOg1PWgR-FgM83Dw950ptA-1c-XgDOV90jErAmQ730=.a960123b-9c61-4531-aab2-759f90390385@github.com>

On Mon, 24 Feb 2025 17:01:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> And two @throws with the same type aren't allowed in javadoc, which means you have to add the new reason to throw IllegalArgumentException into the existing one.
>> 
>> That's demonstrably untrue. This method already has two.
>> 
>> Regarding the scenario above, this apparent and has all been considered already and the IAE is the preferred solution.
>> 
>> And FWIW I don't think ISE is really any better.
>
>> > And two @throws with the same type aren't allowed in javadoc, which means you have to add the new reason to throw IllegalArgumentException into the existing one.
>> 
>> That's demonstrably untrue. This method already has two.
> 
> I was wrong here, the specification for [`ICC_Profile.html.setData`](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/color/ICC_Profile.html#setData(int,byte[])) correctly displays the two entries for `IllegalArgumentException`. The generated javadoc for the proposed changeset contains three entries for IAE.
> 
> I misremembered it, or it was a limitation in an IDE javadoc parser.

> Regarding the scenario above, this apparent and has all been considered already and the IAE is the preferred solution.
> 
> And FWIW I don't think ISE is really any better.

<code>Illegal<i>Argument</i>Exception</code> implies the *argument* is invalid, but it is now thrown for a *valid* argument if the object *state* doesn't allow modifying the data.

<code>Illegal<i>State</i>Exception</code> conveys the object *state* is inappropriate to call this method.

There's a semantic difference between the two, and I think <code>Illegal<i>State</i>Exception</code> is better in this case.

We can also discuss it with Joe in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968073992

From aivanov at openjdk.org  Mon Feb 24 19:01:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 19:01:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
 <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
Message-ID: <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>

On Thu, 20 Feb 2025 20:59:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> At this time, all the built-in profiles are created with `ProfileDeferralInfo`.
> 
> If `ProfileDeferralInfo` is used to create only built-in profiles, then modifying `ICC_Profile(ProfileDeferralInfo pdi)` is enough.

I've updated my branch with this change: `ICC_Profile(ProfileDeferralInfo pdi)` sets the `isBuiltIn` flag to `true`; `ICC_Profile(Profile p)` sets `isBuiltIn` to `false`.

The diff to ?master?: https://github.com/openjdk/jdk/compare/2a5d1da3355a4df3109ec42646b5b0cf088b4c2a..a34f16860c2f7d393f4a1fb57f46fba1a68a8412

Only `ICC_Profile.java` is modified, which is *minimal*. Only several lines are added.

If there's another way to create a built-in profile in the future, this approach will need to updated to take into account the new way. We'll deal with it at that time in the future.

The diff to your branch: https://github.com/openjdk/jdk/compare/8da82c10b5be3b92655abef95fd5be0c8b6eaa00..a34f16860c2f7d393f4a1fb57f46fba1a68a8412

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968244204

From aivanov at openjdk.org  Mon Feb 24 19:01:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 19:01:59 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
Message-ID: <xbAKIM1hdGaNg-rOyAeAmSM2G-3p_-HbCI-jlkLdr5g=.80fff4bc-a8ef-4c76-91b9-3a11bb711939@github.com>

On Fri, 21 Feb 2025 00:50:45 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> Fix consists of:
>> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
>> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
>> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
>> * JavaDoc update for setData() (CSR required)
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:

> 114:      * BuiltInProfile.
> 115:      */
> 116:     private boolean isBuiltIn = false;

Should the field be named `builtIn` instead? `isBuiltIn` starts with a verb which is used for naming methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968245796

From honkar at openjdk.org  Mon Feb 24 19:09:56 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 24 Feb 2025 19:09:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
 <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
 <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>
Message-ID: <E4Q7glxWdlCxUOsypIZMeC4YGGrUk3NKiOzG8jvd4uM=.11d3b33f-0459-4f04-9837-7e89908ca869@github.com>

On Mon, 24 Feb 2025 18:58:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I don't get the reason why it's bad to modify the constructors.
>> 
>> At this time, all the built-in profiles are created with `ProfileDeferralInfo`.
>> 
>> If `ProfileDeferralInfo` is used to create only built-in profiles, then modifying `ICC_Profile(ProfileDeferralInfo pdi)` is enough:
>> 
>> 
>>     ICC_Profile(ProfileDeferralInfo pdi) {
>>         deferralInfo = pdi;
>>         isBuiltIn = true;
>>     }
>> 
>> 
>> And this is a *minimal* change.
>> 
>> When the `isBuiltIn` is final, it's much easier to find where the value gets set.
>
>> At this time, all the built-in profiles are created with `ProfileDeferralInfo`.
>> 
>> If `ProfileDeferralInfo` is used to create only built-in profiles, then modifying `ICC_Profile(ProfileDeferralInfo pdi)` is enough.
> 
> I've updated my branch with this change: `ICC_Profile(ProfileDeferralInfo pdi)` sets the `isBuiltIn` flag to `true`; `ICC_Profile(Profile p)` sets `isBuiltIn` to `false`.
> 
> The diff to ?master?: https://github.com/openjdk/jdk/compare/2a5d1da3355a4df3109ec42646b5b0cf088b4c2a..a34f16860c2f7d393f4a1fb57f46fba1a68a8412
> 
> Only `ICC_Profile.java` is modified, which is *minimal*. Only several lines are added.
> 
> If there's another way to create a built-in profile in the future, this approach will need to updated to take into account the new way. We'll deal with it at that time in the future.
> 
> The diff to your branch: https://github.com/openjdk/jdk/compare/8da82c10b5be3b92655abef95fd5be0c8b6eaa00..a34f16860c2f7d393f4a1fb57f46fba1a68a8412

There are other way to create a profile - directly loading it form a file (serialization)
`ICC_Profile.getInstance(<path to sRGB.pf or any custom profiles>); `or using the byte array representation of the profile. So the main intention here was not to tie ProfileDeferralInfo with isBuiltIn.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968253349

From honkar at openjdk.org  Mon Feb 24 19:14:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 24 Feb 2025 19:14:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <jdOg1PWgR-FgM83Dw950ptA-1c-XgDOV90jErAmQ730=.a960123b-9c61-4531-aab2-759f90390385@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <NPKRaqMXytmJALNeagKN0G5aVe8eytmksd0fbKTMCqE=.25efcfa1-9036-49c4-b77c-dcdd3a9bf8fc@github.com>
 <d9rbvr2_prfYb6Zvu1x4g9dcEJoWqe_W4gehfLFGnm8=.1c8f66d2-b9d0-4ef8-b3e4-7d1544228363@github.com>
 <yOPdaYhXSJdUzxI666XjgLcUfiRYhsS651Gsi3ISsyc=.b3dd216f-d4a0-4e87-ae84-d9f7506a5575@github.com>
 <WN1x_hVxAk5PxhERzGPQptTFm2yXKEF1HKSEueTpb-k=.4b70b0b2-2800-4026-bcc8-0f22b7d99a5c@github.com>
 <dYO5OMO-32FIeqKmQ5Ahm7nukivt8ak9kZV4VfjGAZE=.0da748a6-3354-4701-abe6-12529f86ce83@github.com>
 <jmiM1pQeizXskBh46w-ENQtn8-paYHHeQ8RQZKV7Ozg=.f4436bc1-bcde-422b-8074-269785dfbdf3@github.com>
 <bZq-yRvuufJ0O8aR6C8uLnMspxcYxWhp4NTEJ8Jwf54=.c00b75d7-8380-4a06-9735-528be2d9c020@github.com>
 <ENkkdylOSW9qqkzLUthdBXj_r68aERy0V2O
 K97IE_XE=.4e441653-ac4d-4966-a206-57226d12e781@github.com>
 <jdOg1PWgR-FgM83Dw950ptA-1c-XgDOV90jErAmQ730=.a960123b-9c61-4531-aab2-759f90390385@github.com>
Message-ID: <epKGPYZJdT1lzm1yS9wnCG5AruuqHD6lRL1itAsgu0w=.e74e22a0-ee95-43a3-9091-8015ff2f5ab0@github.com>

On Mon, 24 Feb 2025 17:09:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > And two @throws with the same type aren't allowed in javadoc, which means you have to add the new reason to throw IllegalArgumentException into the existing one.
>>> 
>>> That's demonstrably untrue. This method already has two.
>> 
>> I was wrong here, the specification for [`ICC_Profile.html.setData`](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/color/ICC_Profile.html#setData(int,byte[])) correctly displays the two entries for `IllegalArgumentException`. The generated javadoc for the proposed changeset contains three entries for IAE.
>> 
>> I misremembered it, or it was a limitation in an IDE javadoc parser.
>
>> Regarding the scenario above, this apparent and has all been considered already and the IAE is the preferred solution.
>> 
>> And FWIW I don't think ISE is really any better.
> 
> <code>Illegal<i>Argument</i>Exception</code> implies the *argument* is invalid, but it is now thrown for a *valid* argument if the object *state* doesn't allow modifying the data.
> 
> <code>Illegal<i>State</i>Exception</code> conveys the object *state* is inappropriate to call this method.
> 
> There's a semantic difference between the two, and I think <code>Illegal<i>State</i>Exception</code> is better in this case.
> 
> We can also discuss it with Joe in the CSR.

@aivanov-jdk  As Phil mentioned earlier the already documented exception IAE for `.setData()` outweighs introducing a new exception. Using an existing exception would mean less disruption to any existing applications using the Java API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968263836

From aivanov at openjdk.org  Mon Feb 24 19:19:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 24 Feb 2025 19:19:56 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <E4Q7glxWdlCxUOsypIZMeC4YGGrUk3NKiOzG8jvd4uM=.11d3b33f-0459-4f04-9837-7e89908ca869@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
 <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
 <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>
 <E4Q7glxWdlCxUOsypIZMeC4YGGrUk3NKiOzG8jvd4uM=.11d3b33f-0459-4f04-9837-7e89908ca869@github.com>
Message-ID: <rm_datMxZJKwEvs4lqfz8g4yrFHNGufSkPA28zZ9wTI=.84c76e85-4fb4-40bc-9b0d-b1c567d68eb3@github.com>

On Mon, 24 Feb 2025 19:05:12 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There are other way to create a profile - directly loading it form a file (serialization) `ICC_Profile.getInstance(<path to sRGB.pf or any custom profiles>); `or using the byte array representation of the profile. So the main intention here was not to tie ProfileDeferralInfo with isBuiltIn.

Yes, there are. Does any other way create a **built-in profile**? No, it doesn't as far as I can see.

Is this flexibility needed? I'd say, it's not needed? unless there's a very high chance there'll soon be introduced a new build-in ICC profile which is created in another way but `ICC_Profile(ProfileDeferralInfo)` constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968271385

From serb at openjdk.org  Mon Feb 24 19:22:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 24 Feb 2025 19:22:58 GMT
Subject: RFR: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon [v5]
In-Reply-To: <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
 <741_AFRexgqFa4RksnSZQvKUj6wHc-0k0-SlWShE8h4=.b6b2d1d0-e47d-4c52-8595-96b1aeb7bacc@github.com>
Message-ID: <zInP2ipiKrYP2edMINkgV-U0nfPbFnggu--lWthIOAU=.803a7873-2c39-4776-b7c0-20208fddff74@github.com>

On Fri, 21 Feb 2025 16:29:08 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> **Issue:**
>> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
>> 
>> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
>> 
>> **Solution:**
>> 
>> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Macros TRY CATCH_BAD_ALLOC

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23470#pullrequestreview-2638212924

From honkar at openjdk.org  Mon Feb 24 19:22:58 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 24 Feb 2025 19:22:58 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <xbAKIM1hdGaNg-rOyAeAmSM2G-3p_-HbCI-jlkLdr5g=.80fff4bc-a8ef-4c76-91b9-3a11bb711939@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
 <xbAKIM1hdGaNg-rOyAeAmSM2G-3p_-HbCI-jlkLdr5g=.80fff4bc-a8ef-4c76-91b9-3a11bb711939@github.com>
Message-ID: <TtkrewJuS27Dlug5t3nOWWvKlmArREbRqJsyRkvcoy4=.a6ee67f6-cb4f-46a2-92c1-d037ecc3b693@github.com>

On Mon, 24 Feb 2025 18:59:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc update
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:
> 
>> 114:      * BuiltInProfile.
>> 115:      */
>> 116:     private boolean isBuiltIn = false;
> 
> Should the field be named `builtIn` instead? `isBuiltIn` starts with a verb which is used for naming methods.

IIRC we usually have `is` or `has` prefixed to boolean vars as per naming convention?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968277681

From honkar at openjdk.org  Mon Feb 24 19:40:55 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 24 Feb 2025 19:40:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <TtkrewJuS27Dlug5t3nOWWvKlmArREbRqJsyRkvcoy4=.a6ee67f6-cb4f-46a2-92c1-d037ecc3b693@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
 <xbAKIM1hdGaNg-rOyAeAmSM2G-3p_-HbCI-jlkLdr5g=.80fff4bc-a8ef-4c76-91b9-3a11bb711939@github.com>
 <TtkrewJuS27Dlug5t3nOWWvKlmArREbRqJsyRkvcoy4=.a6ee67f6-cb4f-46a2-92c1-d037ecc3b693@github.com>
Message-ID: <8e66EWkSX6Eo34mLoOfUMob8crhF2h0_ahUooTPYinw=.7489dcd4-f694-46ec-8ff9-ce5d84ecd46a@github.com>

On Mon, 24 Feb 2025 19:20:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 116:
>> 
>>> 114:      * BuiltInProfile.
>>> 115:      */
>>> 116:     private boolean isBuiltIn = false;
>> 
>> Should the field be named `builtIn` instead? `isBuiltIn` starts with a verb which is used for naming methods.
>
> IIRC we usually have `is` or `has` prefixed to boolean vars as per naming convention?

You are right, probably fields are named without the prefix and methods/local vars are prefixed with 'is'.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968312788

From honkar at openjdk.org  Mon Feb 24 20:07:57 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 24 Feb 2025 20:07:57 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <rm_datMxZJKwEvs4lqfz8g4yrFHNGufSkPA28zZ9wTI=.84c76e85-4fb4-40bc-9b0d-b1c567d68eb3@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
 <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
 <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>
 <E4Q7glxWdlCxUOsypIZMeC4YGGrUk3NKiOzG8jvd4uM=.11d3b33f-0459-4f04-9837-7e89908ca869@github.com>
 <rm_datMxZJKwEvs4lqfz8g4yrFHNGufSkPA
 28zZ9wTI=.84c76e85-4fb4-40bc-9b0d-b1c567d68eb3@github.com>
Message-ID: <pXJAY4trqd22WdLY8VkkXdyWOxPfEi546DwMN0dxBhA=.90e3dad5-7932-4a47-9ff9-8cc21e692c7e@github.com>

On Mon, 24 Feb 2025 19:17:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Yes, there are. Does any other way create a built-in profile? No, it doesn't as far as I can see.

Yes, currently ProfileDeferralInfo  is the only way to create built-in profile.

> Is this flexibility needed? I'd say, it's not needed? unless there's a very high chance there'll soon be introduced a new build-in ICC profile which is created in another way but ICC_Profile(ProfileDeferralInfo) constructor.

As of now we don't need the flexibility but not sure if that is something that we may require or need to consider in future. @prrace Your suggestion ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1968345174

From rmahajan at openjdk.org  Mon Feb 24 20:24:06 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Mon, 24 Feb 2025 20:24:06 GMT
Subject: Integrated: 8348106: Catch C++ exception in
 Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon
In-Reply-To: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
References: <Yuh5-WN8lyFzsxGr6-UfGFAyfJ2JFlZ1DPwkOukmjtk=.d85e40c7-955d-4fe7-a7be-a0e30e510372@github.com>
Message-ID: <MrZGCYG0A8R3pMY1_Tp_jWcKLJCq1UQUUXHxSxCXkRg=.938ab00f-b3f8-480f-a729-699ae7331c11@github.com>

On Wed, 5 Feb 2025 18:40:07 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Issue:**
> The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon `calls `CreateIconFromRaster `that can throw a C++ exception.
> 
> The C++ exception must be caught and must not be allowed to escape the JNI method. The call to `CreateIconFromRaster `has to wrapped into a try-catch block.
> 
> **Solution:**
> 
> Added exception handling to make sure any exception from `CreateIconFromRaster `is handled properly.
> 
> Testing done.

This pull request has now been integrated.

Changeset: 39cb493c
Author:    Rajat Mahajan <rmahajan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39cb493c365778a1e3a6e753b49d8664733a3e26
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8348106: Catch C++ exception in Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon

Reviewed-by: abhiscxk, aivanov, azvegint, serb, dmarkov

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

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

From azvegint at openjdk.org  Mon Feb 24 21:29:17 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 24 Feb 2025 21:29:17 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v15]
In-Reply-To: <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>
Message-ID: <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>

On Thu, 6 Feb 2025 22:03:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - merge
>  - update specifications, replace default values in specifications with links to default var
>  - update glide in test
>  - merge
>  - fix test with removed robot.glide using points
>  - add code tag to specifications in Robot
>  - fix syncdelay in ER
>  - removing lesser used overridden methods
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
>  - update specification to public default fields, add waitforidle exceptions to specifications
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/10791477...30ca6a6b

src/java.desktop/share/classes/java/awt/Robot.java line 130:

> 128: 
> 129:     /**
> 130:      * Default 20 milliseconds delay for mouse {@code click} and

Suggestion:

     * Default delay for mouse {@code click} and


There is no need to specify the exact value in the documentation,  in case of something it will be much easier to change it later on.

src/java.desktop/share/classes/java/awt/Robot.java line 136:

> 134: 
> 135:     /**
> 136:      * Default 2 pixel step length for mouse {@code glide}.

Suggestion:

     * Default pixel step length for mouse {@code glide}.


Same here

src/java.desktop/share/classes/java/awt/Robot.java line 138:

> 136:      * Default 2 pixel step length for mouse {@code glide}.
> 137:      */
> 138:     public static final int DEFAULT_STEP_LENGTH = 2;

Do we want to make the `DEFAULT_DELAY` and `DEFAULT_STEP_LENGTH` configurable?

src/java.desktop/share/classes/java/awt/Robot.java line 792:

> 790:      * and {@code mouseRelease}. Invokes {@code waitForIdle} with a default {@link #DEFAULT_DELAY delay} after
> 791:      * {@code mousePress} and {@code mouseRelease} calls. For specifics on valid inputs please see
> 792:      * {@link java.awt.Robot#mousePress(int)}.

It's discussable, and I may be wrong, but I'm not a fan of documentation that is very specific about its implementation.
I prefer the one that was before in the `ExtendedRobot`.


Clicks mouse button(s) by calling {@link #mousePress(int)} and {@link #mouseRelease(int)} methods

src/java.desktop/share/classes/java/awt/Robot.java line 858:

> 856:      * @since   25
> 857:      */
> 858:     public void glide(int x, int y) {

I don't see the `public void glide(Point dest)` and `public void glide(Point src, Point dest)` added, it may be convenient in some cases.

src/java.desktop/share/classes/java/awt/Robot.java line 924:

> 922:             x += tDx;
> 923:             y += tDy;
> 924:             mouseMove((int)x, (int)y);

`mouseMove` can throw an `IllegalThreadStateException` under certain circumstances.

test/jdk/java/awt/Component/PaintAll/PaintAll.java line 51:

> 49:   @summary Test Component.paintAll() method
> 50:   @author sergey.bylokhov at oracle.com: area=awt.component
> 51:   @library /lib/client/

It's not needed anymore, is it?
Suggestion:

test/jdk/lib/client/ExtendedRobot.java line 182:

> 180:     @Override
> 181:     public synchronized void waitForIdle() {
> 182:         waitForIdle(syncDelay);

This `waitForIdle(500)` is no longer called by tests(as it uses regular `java.awt.Robot#waitForIdle()`, so I assume you have verified that automated testing looks good. (I haven't gone through all the tests yet)

test/jdk/lib/client/ExtendedRobot.java line 368:

> 366:      * @see     java.awt.event.KeyEvent
> 367:      */
> 368:     public void type(char c) {

Those `type(char...` are not migrated also. 

At least one test uses it:

https://github.com/alisenchung/jdk/blob/8150564/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java#L178

With your change, it now calls `type(int)` directly, which has a different implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968352863
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968353101
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968417841
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968386427
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968425006
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968422144
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968431117
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968414517
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r1968435956

From dnguyen at openjdk.org  Mon Feb 24 21:44:12 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 24 Feb 2025 21:44:12 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v7]
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <MwITFruy-5yJSHcARDO8O5WaShYxS3OvGfwcbM_icyY=.efde8dd4-ee12-4efc-ae67-b407c6b0588d@github.com>

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove mac restriction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23451/files
  - new: https://git.openjdk.org/jdk/pull/23451/files/889a6fa7..6d724c83

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

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

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

From dnguyen at openjdk.org  Mon Feb 24 21:44:12 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 24 Feb 2025 21:44:12 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v6]
In-Reply-To: <SXUqC5q6UEal1b6_vZb4MAK-pUZwcAkZnhynmCmtoV8=.271dc76c-b0e5-47e2-b09f-bb4bf73a4246@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <p8ZXASmJRw0oE13mwM4RAJTP8Do-SVJlDic06DRXc5k=.e2ac0f2d-22c7-4090-8cbf-b4f8086b479a@github.com>
 <SXUqC5q6UEal1b6_vZb4MAK-pUZwcAkZnhynmCmtoV8=.271dc76c-b0e5-47e2-b09f-bb4bf73a4246@github.com>
Message-ID: <q53zgVFBlY9lBtQiEMcQF-mn5hO1Kq17-GeenevQsMM=.8d7e8f7d-66ab-4f58-bc14-195d95a130f5@github.com>

On Sat, 22 Feb 2025 02:10:46 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test helper
>
> test/jdk/javax/swing/JComboBox/JComboBoxScrollFocusTest.java line 43:
> 
>> 41:  * @key headful
>> 42:  * @bug 6672644
>> 43:  * @requires os.family != "mac"
> 
> Is there a reason to exclude it on mac?
> 
> Based on my local testing, the issue doesn't affect mac (test passes before and after the fix), but we can still run the test.

I excluded mac because it didn't have an increase/decrease button for the scrollbar. However, I see with the automated test that this doesn't really matter because clicking above or below the slider still increments/decrements the value. Removed the mac exclusion. Thanks again!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23451#discussion_r1968455152

From azvegint at openjdk.org  Mon Feb 24 21:49:55 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 24 Feb 2025 21:49:55 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v7]
In-Reply-To: <MwITFruy-5yJSHcARDO8O5WaShYxS3OvGfwcbM_icyY=.efde8dd4-ee12-4efc-ae67-b407c6b0588d@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <MwITFruy-5yJSHcARDO8O5WaShYxS3OvGfwcbM_icyY=.efde8dd4-ee12-4efc-ae67-b407c6b0588d@github.com>
Message-ID: <Jk_Fs6NwsvA9ouBaub-TvbAen5D_RZnihN2mIZjijiE=.1d8a8a28-1f48-4077-be4c-2d393dd25e75@github.com>

On Mon, 24 Feb 2025 21:44:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>> 
>> CI testing is green on all platforms.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove mac restriction

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23451#pullrequestreview-2638518483

From bpb at openjdk.org  Mon Feb 24 23:54:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 24 Feb 2025 23:54:55 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v3]
In-Reply-To: <utSrp5WJhzetf-_2VIjtfstzth6bpKBwY_vmILNls_w=.b6eaa9b4-5f58-4e5c-bc45-4592edfa2877@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
 <IBhSrtqI0EBx4bZwYKUVB8KPQqIziaIbR5u2B77tuWs=.30c1e8c9-a4ae-4ebd-b8eb-07a1ed66bd3e@github.com>
 <myp9tmZdjeRoKzywe7SIze1H4j1bqpuegPt4EV7O6hc=.d16e95c1-0683-4183-88ad-a1bd6588a3df@github.com>
 <utSrp5WJhzetf-_2VIjtfstzth6bpKBwY_vmILNls_w=.b6eaa9b4-5f58-4e5c-bc45-4592edfa2877@github.com>
Message-ID: <SJ6RVwXhuoSdkYQeZNTptH4wCRV94ElDj3T7XGmN3mw=.b0512af8-25e8-46e5-b7fa-fa18d158530a@github.com>

On Sat, 22 Feb 2025 00:19:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I don't know how to initiate a CSR. Is that something I can initiate, or does that require a more senior sponsor?
>> 
>> I'm not done with the test files yet. (I'll make a note in this PR when I am.)
>> 
>> Regarding sample files:
>> I replaced the jpeg file that embeds a JFIF *and* EXIF thumbnail. I still need to:
>> A. replace the jpeg file "exif-rgb-thumbnail" and
>> B. review this thread for other interesting test cases
>
>> I don't know how to initiate a CSR. Is that something I can initiate, or does that require a more senior sponsor?
> 
> I can do that, probably next week. We will need to update the JPEG metadata documentation.

> @bplb : 2. Do you still think a test case featuring an uncompressed RGB main image with a uncompressed RGB thumbnail is necessary?

I doubt it is necessary. I don't think the case is very common.

>     3. Should I add a test that includes an EXIF thumbnail followed by a JFIF thumbnail?

I do not think it is necessary. The JFIF-before-Exif case is already uncommon and I suspect that Exif-before-JFIF is even more so, if it is even possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/22898#issuecomment-2679966123

From honkar at openjdk.org  Tue Feb 25 01:51:31 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 25 Feb 2025 01:51:31 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v7]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <RFPJ2_fc1mprZaOlFEE0XkjlE-ZucYddGgCfSfCBNuo=.a6523d38-bd4b-47bd-85fe-b5847235734f@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  javadoc and BuiltInProfileCheck test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/977f468c..32c8a13f

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

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

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

From honkar at openjdk.org  Tue Feb 25 02:16:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 25 Feb 2025 02:16:11 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v8]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <1gL0weVb8l4qit443QYXnbR_yNV5CepKZc0oXA_a9qM=.7ce99cc0-35e5-4c3f-ad8a-0c82af8cdf20@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  renamed flag to builtIn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/32c8a13f..93e304f6

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

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

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

From psadhukhan at openjdk.org  Tue Feb 25 02:24:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Feb 2025 02:24:10 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v15]
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: <rGfbC3yxRSH1sPH7cs75_Tg-V0uOyvoFMSIU5p_sPlw=.d2a82820-edf3-49b3-92da-6fb1e53ff02b@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:

  Move windows specific change to windows folder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/7f0849fc..de139e51

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

  Stats: 93 lines in 5 files changed: 78 ins; 8 del; 7 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  Tue Feb 25 02:26:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Feb 2025 02:26:54 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v10]
In-Reply-To: <5J92bI0_QRFYtvZzLcE9diwN1c8IiC0VkEpjDebTLKk=.6cb0fba7-16a3-4dc9-ab66-1abf7cefa739@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <fF-hj2nlAKRU6NXu8lgqLk_B2LWy3xjM5QdWtEJ9wF8=.9ef8eab0-7c2e-4ae4-a228-96643a2864e1@github.com>
 <guVUUIx_7aS7q2KK5EOwKecsrACNUkNwhoCrE6T6Znk=.6e7f2613-d058-4eb1-a379-6ca37f626433@github.com>
 <zLYlbA7bI_JEIaSzq-ZqYf9H8XGizzjkr3Cds2J8WKg=.df8c9094-3614-49a1-ac37-a81400fab0ee@github.com>
 <NbdvRYDyFGaYKtE2wtBJD_sWFz5dlTuHSv-iSHnpT60=.abb2997d-8c89-485d-90b5-594d914e3541@github.com>
 <4bdkDW7dmnQj6PYp8owb8Bucp9s-MVsYbWJPKX1JM84=.0a5cfea0-eb01-4694-9ce9-37a7e52dc6e3@github.com>
 <nQoe_O7wLmnqTvLR6kF5fxLMe_EqnusO8LbA0uXAITA=.9e797e03-fbd5-4512-b4a7-5d68183f2c94@github.com>
 <8li8njF_3fsUMKO8z6CZV4YlZVxACKioP-zfAid1zxA=.206ab7fa-9d85-432f-adec-868dfb06777d@github.com>
 <5J92bI0_QRFYtvZzLcE9diwN1c8IiC0VkEpjDebTLKk=.6cb0fba7-16a3-4dc9-ab66-1abf7cefa739@github.com>
Message-ID: <VFLplOVl9gOXN7zomD4x5OQo4Jpsb3TMU4fUduKdl7g=.392938d2-4968-4534-a66d-7e92c5fe610b@github.com>

On Wed, 12 Feb 2025 14:36:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Where it is checking for subclasses? It is just checking for if the current lookandfeel is Windows L&F (as I told it is not checking for `instanceof WindowsLookAndFeel` in which case one could have argued that it is trying to know about windows subclass..
>> 
>> Also, having helper method will have effect in only Windows subclass and noop in others and that is unnecessary in my opinion and on top of that, it will need a CSR for that method and that method would be additional maintenance headache and it will prevent backporting this fix if one wants to and considering this is related to JCK issue, people would like it to be backported..
>
> Windows Look-and-Feel is based on Basic L&F implementation???from this point of view, Basic L&F changes its layout to accommodate for customisations that are needed for another L&F that's descends from it.

Windows L&F change moved to windows class/folder

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

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

From duke at openjdk.org  Tue Feb 25 04:27:37 2025
From: duke at openjdk.org (Jeremy)
Date: Tue, 25 Feb 2025 04:27:37 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v6]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <13P-4Fh5wk6t7j_zD1qMmQsAc2V46qKiHdDQpvAD-zY=.51e3230b-e89e-4aa8-835e-693c8fcd1451@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
> 
> The images used in this test are contributed by Brian and me.

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

  8160327: trying to placate PR script
  
  Some github script is concluding:
  ```
  Errors
   ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/jfif_and_exif.jpg)
   ?? Executable files are not allowed (file: test/jdk/javax/imageio/plugins/jpeg/JpegExifThumbnail/malicious_looping_IFD.jpg)
  ```
  
  I'm trying to figure what separates these files from the other JPGs. Maybe I need to use hyphens instead of underscores...? Let's check.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/24b6feea..4445d6e9

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

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

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

From duke at openjdk.org  Tue Feb 25 07:54:59 2025
From: duke at openjdk.org (duke)
Date: Tue, 25 Feb 2025 07:54:59 GMT
Subject: Withdrawn: 8336654: [lworld] Tests depending on sun.awt.AppContext can
 fail when run with migrated classes
In-Reply-To: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com>
References: <7_hiO6S4AOb-puw71FWgTLyXgCkz96jP0iQx_uQP7Q4=.1f0741e8-10b2-4216-b7cc-543174ea85a0@github.com>
Message-ID: <ZAbU07gHFmQRYd1xDw0ZVcSWJDSu3v_0Z7U16PdrgCA=.0b69f843-6164-4fe8-b061-e8cf8e29f916@github.com>

On Mon, 23 Dec 2024 17:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

> The problem is that Boolean will be a value type in the future (Project Valhalla)
> and so it can't be the referent of a Reference.
> 
> In this code, the abstract class that creates the Reference accepts a generic type so isn't in control of what it receives.
> 
> The concrete class that extends the generic class has no idea what the super class implementation does,
> so has no way to know that it might do something that is invalid for  a value type.
> 
> That's an interesting observation for Valhalla (that the code that does something inappropriate for a value type
> isn't the source of the value type) but I don't think we need to be concerned
> about that here because we can see reasons to do this anyway.
> 
> The specific classes exist because a nominal singleton for the VM may need to be private to an AppContext.
> This is  a concept from applets but also from webstart where we have a single JVM that may be running code
> from different origins that needs to be partitioned and sand boxed.
> 
> This concept is obsolete now as applets and webstart are no longer supported, and the Security Manager
> is disabled, further undermining any way to support partitioning.
> 
> This specific case of a Boolean created from the value of a Java System Property looks like it never needed
> this partitioning, so the minimal fix is to stop using RecyclableSingleton for it, and just cache the value of that.
> 
> The next  level of fix is to note that since AppContext is obsolete, there is no need for RecyclableSingleton
> to use AppContext specific values, making RecyclableSingleton just a lazy initialization mechanism for the singleton.
> 
> Given that removing the obsolete AppContext is on the TBD list - and some JDK components have already
> removed per-AppContext code - and we'd probably come back to this in JDK 25 anyway it seems best
> to get it over with.
> 
> That does mean that one other place in sun.awt.ImageCache needed to be updated too.
> 
> Also one test that explicitly checked that AppContexts were used for UI instances is obsolete and removed.
> 
> Note that RecyclableSingleton also offers some lazy initialisation benefit, and is widely used in Aqua,
> so going further and removing that probably isn't something we want to do at all, and certainly not here.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Tue Feb 25 08:13:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 25 Feb 2025 08:13:08 GMT
Subject: RFR: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back [v7]
In-Reply-To: <MwITFruy-5yJSHcARDO8O5WaShYxS3OvGfwcbM_icyY=.efde8dd4-ee12-4efc-ae67-b407c6b0588d@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
 <MwITFruy-5yJSHcARDO8O5WaShYxS3OvGfwcbM_icyY=.efde8dd4-ee12-4efc-ae67-b407c6b0588d@github.com>
Message-ID: <PofKhcr8e5-I_ggFaN8XBdfv_xafUNHDDQTQCY7YaLM=.b61addb6-c201-43be-9af4-82fb56864a7d@github.com>

On Mon, 24 Feb 2025 21:44:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
>> 
>> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
>> 
>> CI testing is green on all platforms.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove mac restriction

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23451#pullrequestreview-2640006095

From aivanov at openjdk.org  Tue Feb 25 11:01:06 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 25 Feb 2025 11:01:06 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v8]
In-Reply-To: <1gL0weVb8l4qit443QYXnbR_yNV5CepKZc0oXA_a9qM=.7ce99cc0-35e5-4c3f-ad8a-0c82af8cdf20@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <1gL0weVb8l4qit443QYXnbR_yNV5CepKZc0oXA_a9qM=.7ce99cc0-35e5-4c3f-ad8a-0c82af8cdf20@github.com>
Message-ID: <upPgxvBO_xWbk_WpNscqaYN0Xkz7BtmpK4DkLr7FaYk=.bf8d6e05-2b83-46c9-9126-d9b0111f9d03@github.com>

On Tue, 25 Feb 2025 02:16:11 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
>> 
>> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
>> 
>> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
>> 
>> Fix consists of:
>> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
>> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
>> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
>> * JavaDoc update for setData() (CSR required)
>> 
>> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
>> 
>> Applications which need a modified version of the ICC Profile should instead do the following:
>> 
>> 
>> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
>> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
>> newProfile.setData() // to modify and customize the profile
>> 
>> 
>> Following existing tests are modified to update a copy of Built-In profile.
>> 
>> - java/awt/color/ICC_Profile/SetHeaderInfo.java
>> - java/awt/color/ICC_ProfileSetNullDataTest.java
>> - sun/java2d/cmm/ProfileOp/SetDataTest.java
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed flag to builtIn

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 115:

> 113:      * This check is used in {@link #setData(int, byte[])} to prevent modifying
> 114:      * Built-in profiles.
> 115:      */

/**
     * Set to {@code true} for {@code BuiltInProfile},
     * remains {@code false} otherwise.
     * This flag is used in {@link #setData(int, byte[])} to prevent modifying
     * built-in profiles.
     */

There's no need to capitalise ?Built-in?.

test/jdk/java/awt/color/ICC_Profile/BuiltInProfileCheck.java line 70:

> 68:                 throw new RuntimeException("Test Failed! IAE NOT thrown.");
> 69:             } catch (IllegalArgumentException iae) {
> 70:                 if (!iae.getMessage().equalsIgnoreCase(EXCEPTION_MSG)) {

I think we can compare with regular `equals`. It is unlikely the message will change by letter case only. The test uses exactly the same message as the one that's thrown in `ICC_Profile.setData`, therefore the messages should match.

If the message is changed in the code for whatever reason, the message in the test will need updating, which is expected, isn't it?

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

PR Review: https://git.openjdk.org/jdk/pull/23606#pullrequestreview-2640520613
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1969536537
PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1969481870

From aivanov at openjdk.org  Tue Feb 25 12:09:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 25 Feb 2025 12:09:55 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
 <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>
Message-ID: <ZBI90OnWr7lGjWcWRQKfEj3KhjHmdjlk-Qwgup0-4kA=.ae1f0d7b-970d-4a52-9eb5-bafcf81ed683@github.com>

On Mon, 24 Feb 2025 16:46:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc update
>
> test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 33:
> 
>> 31:  */
>> 32: public final class ICC_ProfileSetNullDataTest {
>> 33:     private static final int[] colorSpace = new int [] {
> 
> Suggestion:
> 
>     private static final int[] colorSpace = new int[] {

In fact, the syntax can be simplified further:

private static final int[] colorSpace = {


There's no need for explicit `new int[]`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1969639009

From azvegint at openjdk.org  Tue Feb 25 12:12:02 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Feb 2025 12:12:02 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after setDisplayMode
 call
Message-ID: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>

Wayland clients are by design not allowed to change the resolution in Wayland.
XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.

Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.

---

There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:

1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 

The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.

---

Testing looks good (manual + automated).

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

Commit messages:
 - 8280991: [XWayland] No displayChanged event after setDisplayMode call

Changes: https://git.openjdk.org/jdk/pull/23774/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8280991
  Stats: 89 lines in 4 files changed: 85 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23774/head:pull/23774

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

From duke at openjdk.org  Tue Feb 25 14:55:41 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Tue, 25 Feb 2025 14:55:41 GMT
Subject: RFR: 8349350: Unable to print using InputSlot and OutputBin print
 attributes at the same time [v4]
In-Reply-To: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
References: <p0Eww2x7bJ_viDo7edWjch7PvFtF3JQy2r2Ztur1vng=.decd2cec-99ce-4eef-90ce-112068b5759a@github.com>
Message-ID: <qugwMqvHOugdo_sGQldgcvi09SK0ZpEXyY_hXKpm9xI=.da5c93dd-878e-4aff-bd4e-2fa861175667@github.com>

> Fix for https://bugs.openjdk.org/browse/JDK-8349350. It's impossible to use more that one print option.
> 
> **Reason of the bug**:  
> execCmd array uses one index per print flag, but 'OPTIONS' flag can use two indexes for the options.
> 
> **Fix description**: 
> make the size of the execCmd array dependent on the number of options.
> 
> **Test**: 
> new test PrintExecCmdOptionTest.java created to check execution with multiple options. (run on MacOS, Windows and linux x86_64)

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

 - Merge branch 'openjdk:master' into print_options_idx_out_of_rng
 - remove code duplication
 - replace regexp s+ with space
 - use array for option args
 - Fix ArrayIndexOutOfBoundsException at PSPrinterJob printExecCmd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23457/files
  - new: https://git.openjdk.org/jdk/pull/23457/files/621bf2e0..291ed330

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

  Stats: 35998 lines in 1329 files changed: 19973 ins; 10576 del; 5449 mod
  Patch: https://git.openjdk.org/jdk/pull/23457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23457/head:pull/23457

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

From vdyakov at openjdk.org  Tue Feb 25 15:55:04 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Tue, 25 Feb 2025 15:55:04 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call
In-Reply-To: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
Message-ID: <lAd4BtftJ94krs5Ky7Q9RgE2C9G0r0vtN6NbC-i4A0g=.0f1468f4-ce9f-487b-8d8b-3bee1bc399f4@github.com>

On Tue, 25 Feb 2025 12:07:11 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Wayland clients are by design not allowed to change the resolution in Wayland.
> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
> 
> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
> 
> ---
> 
> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
> 
> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
> 
> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
> 
> ---
> 
> Testing looks good (manual + automated).

@honkar-jdk @prrace please review

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

PR Comment: https://git.openjdk.org/jdk/pull/23774#issuecomment-2682468250

From duke at openjdk.org  Tue Feb 25 16:02:54 2025
From: duke at openjdk.org (Mikhail Yankelevich)
Date: Tue, 25 Feb 2025 16:02:54 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call
In-Reply-To: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
Message-ID: <7MfEWuILXbADMApvFT20dC9D5chKdaEmQVa9USBJToI=.ea0346dc-e9d3-4902-b5d3-635f42ab960d@github.com>

On Tue, 25 Feb 2025 12:07:11 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Wayland clients are by design not allowed to change the resolution in Wayland.
> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
> 
> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
> 
> ---
> 
> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
> 
> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
> 
> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
> 
> ---
> 
> Testing looks good (manual + automated).

test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 60:

> 58: 
> 59:     public static void main(String[] args) {
> 60:         if (Platform.isOnWayland() && getGnomeShellMajorVersion() < 43) {

Do you think this might be easier to read if the method is changed to `isFixDelivered` or something similar? I think if it would detect the version and compare it inside and just output true or false. This would also remove the version 1000 if there is no gnome-shell installed on the system,  which is a bit confusing imo

test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 256:

> 254:                             .start();
> 255:             try (InputStreamReader isr = new InputStreamReader(process.getInputStream());
> 256:                  BufferedReader reader = new BufferedReader(isr)) {

Wouldn't it be simpler if the reader is retrieved with `process.inputReader()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23774#discussion_r1970074838
PR Review Comment: https://git.openjdk.org/jdk/pull/23774#discussion_r1970074977

From azvegint at openjdk.org  Tue Feb 25 16:40:37 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Feb 2025 16:40:37 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
Message-ID: <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>

> Wayland clients are by design not allowed to change the resolution in Wayland.
> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
> 
> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
> 
> ---
> 
> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
> 
> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
> 
> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
> 
> ---
> 
> Testing looks good (manual + automated).

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  NoResizeEventOnDMChangeTest update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23774/files
  - new: https://git.openjdk.org/jdk/pull/23774/files/73b4968c..f7f022f7

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

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

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

From azvegint at openjdk.org  Tue Feb 25 16:40:37 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 25 Feb 2025 16:40:37 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <7MfEWuILXbADMApvFT20dC9D5chKdaEmQVa9USBJToI=.ea0346dc-e9d3-4902-b5d3-635f42ab960d@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
 <7MfEWuILXbADMApvFT20dC9D5chKdaEmQVa9USBJToI=.ea0346dc-e9d3-4902-b5d3-635f42ab960d@github.com>
Message-ID: <574vT5luciACYtdqOSr-v-tTzEcNypLQANgpwOUnIZI=.1b2d6076-4e0d-48f5-9f54-9fa4a778fda4@github.com>

On Tue, 25 Feb 2025 15:57:38 GMT, Mikhail Yankelevich <duke at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NoResizeEventOnDMChangeTest update
>
> test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java line 60:
> 
>> 58: 
>> 59:     public static void main(String[] args) {
>> 60:         if (Platform.isOnWayland() && getGnomeShellMajorVersion() < 43) {
> 
> Do you think this might be easier to read if the method is changed to `isFixDelivered` or something similar? I think if it would detect the version and compare it inside and just output true or false. This would also remove the version 1000 if there is no gnome-shell installed on the system,  which is a bit confusing imo

Sure, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23774#discussion_r1970150005

From epeter at openjdk.org  Tue Feb 25 17:45:54 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 25 Feb 2025 17:45:54 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <LFxhMM1c0TdQTfXOGwZejzv1ChoF1NITOm3gYk-JbsI=.781ce977-2a85-4a90-a3cd-13284b0ec1e8@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

test/micro/org/openjdk/bench/vm/compiler/MergeStores.java line 175:

> 173:     public byte[] store_B2_con_offs_allocate_bale() {
> 174:         byte[] aB = new byte[RANGE];
> 175:         ByteArray.setShortLE(aB, offset, (short)0x0201);

Did you run this benchmark to see if there is any impact?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23478#discussion_r1970261194

From honkar at openjdk.org  Tue Feb 25 18:53:29 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 25 Feb 2025 18:53:29 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v9]
In-Reply-To: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
Message-ID: <STkIueTKhFy1GK2vcmu42mVkCQP9bTWuTWjHImd1fWg=.38143c42-c5a9-4faf-910f-d0d142620a89@github.com>

> Built-in Profiles are singleton objects and if the user happens to modify this shared profile object via setData() then the modified version of the profile is returned each time the same built-in profile is requested via getInstance().
> 
> It is good to protect Built-in profiles from such direct modification by adding BuiltIn profile check in `setData()` such that **only copies** of Built-In profiles are allowed to be updated.
> 
> With the proposed fix, if Built-In profile is updated using `.setData()` it throws _**IAE - "BuiltIn profile cannot be modified"**_
> 
> Fix consists of:
> * `private boolean isBuiltIn = false` in ICC_Profile which is set to true when BuiltIn profiles are created and false for non-builtIn profile.
> * Converted BuiltInProfile from private interface to private static class (with all the profile instances as static final)
> * `isBuiltIn` flag is set to true when BuiltInProfile are loaded.
> * JavaDoc update for setData() (CSR required)
> 
> There are no restrictions on creating copies of BuiltIn profile and then modifying it, but what is being restricted with this fix is - the direct modification of the shared BuiltIn profile instance.
> 
> Applications which need a modified version of the ICC Profile should instead do the following:
> 
> 
> byte[] profileData = ICC_Profile.getData() // get the byte array represtation of BuiltIn- profile
> ICCProfile newProfile = ICC_Profile.getInstance(profileData) // create a new profile
> newProfile.setData() // to modify and customize the profile
> 
> 
> Following existing tests are modified to update a copy of Built-In profile.
> 
> - java/awt/color/ICC_Profile/SetHeaderInfo.java
> - java/awt/color/ICC_ProfileSetNullDataTest.java
> - sun/java2d/cmm/ProfileOp/SetDataTest.java

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor test updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23606/files
  - new: https://git.openjdk.org/jdk/pull/23606/files/93e304f6..559fb749

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

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

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

From honkar at openjdk.org  Tue Feb 25 18:56:08 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 25 Feb 2025 18:56:08 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
 <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>
Message-ID: <cwp50S9mg7-E9kW3CpOZnd7eIWVV9yQ5UtgRKJ4UEQM=.dc69c033-7861-4b86-baae-64e3bf1232dc@github.com>

On Mon, 24 Feb 2025 16:48:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc update
>
> test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java line 48:
> 
>> 46:             } catch (IllegalArgumentException e) {
>> 47:                 return;
>> 48:             }
> 
> The test won't run for **all** the cases if you exit after the first successful case???use `continue`.

Good catch. Moved ` throw new RuntimeException("IllegalArgumentException expected");`  within try block so continue no longer required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1970356654

From dnguyen at openjdk.org  Tue Feb 25 19:44:06 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 25 Feb 2025 19:44:06 GMT
Subject: Integrated: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if
 switch to another window and return back
In-Reply-To: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
References: <XZYw6SaMigK3rg0d7-XarN608GAp4KNwoZV2UoPMrGk=.bfe453da-e784-4ade-a2f6-dfa2cfa16beb@github.com>
Message-ID: <G44BdoWIVzBKvZjMWoPnJ-D8_eNqs4eYoLOdyBNI-4w=.732bca98-fb55-4089-9a3d-041042b93578@github.com>

On Tue, 4 Feb 2025 23:35:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Redo for JComboBox infinite scrolling issue. The issue is that when a scrollbar is clicked and held, if the user switches focus (ex: ALT+TAB) while scrolling, when focused is returned to the scrolling application, the JComboBox will still be scrolling even though nothing it being clicked.
> 
> Previously, a KeyboardFocusListener was added to determine the focus. However, there was a memory leak on Windows and Ubuntu. This current implementation uses the current FocusManager and is overall a cleaner, simpler approach.
> 
> CI testing is green on all platforms.

This pull request has now been integrated.

Changeset: d4fdc796
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4fdc796aac8ece930c28579d285b21acf8e6ddb
Stats:     164 lines in 2 files changed: 160 ins; 2 del; 2 mod

8344981: [REDO] JDK-6672644 JComboBox still scrolling if switch to another window and return back

Co-authored-by: Alexander Zvegintsev <azvegint at openjdk.org>
Reviewed-by: azvegint, psadhukhan, honkar

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

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

From achung at openjdk.org  Tue Feb 25 20:05:26 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 25 Feb 2025 20:05:26 GMT
Subject: RFR: 8348110: Update LCMS to 2.17
Message-ID: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>

upgrading third party library to newest version

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

Commit messages:
 - lcms upgrade

Changes: https://git.openjdk.org/jdk/pull/23784/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348110
  Stats: 1311 lines in 30 files changed: 294 ins; 860 del; 157 mod
  Patch: https://git.openjdk.org/jdk/pull/23784.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23784/head:pull/23784

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

From achung at openjdk.org  Tue Feb 25 20:22:53 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 25 Feb 2025 20:22:53 GMT
Subject: RFR: 8270265: LineBreakMeasurer calculates incorrect line breaks
 with zero-width characters [v3]
In-Reply-To: <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
References: <zsDaT63BnTnErmCS5KpZS5iVk7MTAc-aMtAMOug_TNw=.abe268c0-03b9-4d8d-8be2-c7514f7aa7be@github.com>
 <3rW-TgFF-cacMTjvzP-CUuHYcgmY0TC-jTxHscvCyXM=.a6eef26d-5495-45c9-8436-2effb6e1e9dc@github.com>
Message-ID: <PS0hDyObaJPyOxCesHpAsPq0jpUKDTcFJ9HFjUsS4ok=.68a00514-1276-42b9-8c39-06d2f8fbc013@github.com>

On Fri, 21 Feb 2025 21:13:16 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When a string contains zero-width characters, `LineBreakMeasurer` calculates line breaks incorrectly.
>> 
>> The root cause appears to be that `LineBreakMeasurer` eventually calls into `StandardGlyphVector.getGlyphInfo()`, which derives the glyph advances from the glyph IDs. However, HarfBuzz's default treatment of zero-width characters is to provide the glyph ID of the space character (`U+0020`) combined with an artificial zero advance (not the font's space glyph advance). Unaware of HarfBuzz's sleight of hand, `StandardGlyphVector.getGlyphInfo()` retrieves the actual advances of the space glyph (since that was the glyph ID returned) and provides these back up the call chain to `LineBreakMeasurer` et al.
>> 
>> I think the correct fix is to use `hb_buffer_set_invisible_glyph` to register `0xFFFF` as the invisible glyph ID with HarfBuzz (matching `CharToGlyphMapper.INVISIBLE_GLYPH_ID`).
>> 
>> I haven't seen any unwanted side effects, but there is a risk, since this is changing the global HarfBuzz configuration.
>> 
>> For more information on HarfBuzz's behavior in this area, see: https://harfbuzz.github.io/setting-buffer-properties.html
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23603#pullrequestreview-2642372234

From vdyakov at openjdk.org  Tue Feb 25 21:29:54 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Tue, 25 Feb 2025 21:29:54 GMT
Subject: RFR: 8348110: Update LCMS to 2.17
In-Reply-To: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
Message-ID: <m3nn7guly0vjP9G1wGgGaDkwDIZN6kYiiME9gKdjtTo=.f892aaae-283b-4ac4-98ad-a21b7fdfb1ff@github.com>

On Tue, 25 Feb 2025 20:00:18 GMT, Alisen Chung <achung at openjdk.org> wrote:

> upgrading third party library to newest version

@honkar-jdk @prrace please review

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

PR Comment: https://git.openjdk.org/jdk/pull/23784#issuecomment-2683334186

From achung at openjdk.org  Wed Feb 26 00:02:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 26 Feb 2025 00:02:40 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
Message-ID: <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>

On Thu, 6 Feb 2025 10:56:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Robot API is just a wrapper around the native API with a basic functionality that works across all platforms. If a native macOS application can move the mouse in a certain way, why should Java be restricted?

The problem is that different platforms have different behaviors. I think since Java behavior should be consistent across platforms, it should be changed to have it's own implementation rather than just be a wrapper around the native API.

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

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2683556413

From honkar at openjdk.org  Wed Feb 26 00:37:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 26 Feb 2025 00:37:53 GMT
Subject: RFR: 8348110: Update LCMS to 2.17
In-Reply-To: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
Message-ID: <QXBNZKhDDMWvYo9TEElkX8XHC2lFOuXwF9oDAs3ts88=.6a9415ca-89df-4c13-aff4-58d4a1f12ec1@github.com>

On Tue, 25 Feb 2025 20:00:18 GMT, Alisen Chung <achung at openjdk.org> wrote:

> upgrading third party library to newest version

Updated files are missing the Oracle copyright.

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

Changes requested by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23784#pullrequestreview-2642758167

From honkar at openjdk.org  Wed Feb 26 00:51:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 26 Feb 2025 00:51:00 GMT
Subject: RFR: 8348110: Update LCMS to 2.17
In-Reply-To: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
Message-ID: <hVN4Ky4h5pr2kVwnTU_XsZXthj-2iu0HBykyvvrSmVM=.a7d99f95-cde1-4e3c-8c17-7503911b7e80@github.com>

On Tue, 25 Feb 2025 20:00:18 GMT, Alisen Chung <achung at openjdk.org> wrote:

> upgrading third party library to newest version

Does CI and relevant tests for LCMS upgrade look good ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23784#issuecomment-2683615867

From serb at openjdk.org  Wed Feb 26 05:22:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Feb 2025 05:22:53 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v5]
In-Reply-To: <8pc24J47BZqhH822Ed4q8Q2sNwtwfOmkoEiQrBScXJQ=.18fea0c9-12c8-4d28-abc4-790cf35d7e1e@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <8pc24J47BZqhH822Ed4q8Q2sNwtwfOmkoEiQrBScXJQ=.18fea0c9-12c8-4d28-abc4-790cf35d7e1e@github.com>
Message-ID: <EOJpL-os4rAKAWnudmpR0Bg4axWEqS_Ipv9uTBW8hdw=.a7b24a24-93e2-45a4-a169-1af294bacfcb@github.com>

On Tue, 18 Feb 2025 08:33:55 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   new fixes

src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java line 94:

> 92:                     this.write = info;
> 93:                     writeType = info.type;
> 94:                 } else if (isParentOfIncoming(this.write, info)) {

Is it possible to update the logic for the read methods above and remove the sorting based on the default property?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r1970924330

From duke at openjdk.org  Wed Feb 26 09:23:47 2025
From: duke at openjdk.org (Jeremy)
Date: Wed, 26 Feb 2025 09:23:47 GMT
Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for
 JPEG [v7]
In-Reply-To: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
References: <aUrd4SA5FqabOnZ9JK52sFp5rw_puF9-bBIqhQT4UoY=.1114d901-219c-4863-bac0-f3185f534ff0@github.com>
Message-ID: <ODYdkkicRh12Hix3tA5ptD_SUeat4R28z_c6zU4beV0=.8ec645b6-01bc-47ba-9ac1-52603928cdca@github.com>

> This adds support for parsing thumbnails in an APP1 Exif marker.
> 
> This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.)
> 
> ~~The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.)~~
> 
> The images used in this test are contributed by Brian and me.

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

  8160327: trying to placate PR script
  
  The github script still classifies two of the sample jpgs as executable files, which it classifies as errors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22898/files
  - new: https://git.openjdk.org/jdk/pull/22898/files/4445d6e9..52cf81f4

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

  Stats: 33 lines in 10 files changed: 21 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/22898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898

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

From mbaesken at openjdk.org  Wed Feb 26 12:51:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Feb 2025 12:51:00 GMT
Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and
 ShapeSINextSpan in libawt java2d from ubsan checks
In-Reply-To: <3jdex5JTctdBekXPeXMDDdAUr0a4L47GAjtNB_4UYbM=.f0ced193-89e7-4503-a9bb-af414d0747ae@github.com>
References: <sCcbJkWswZbxYWeeP0jnUqIM8uv59IkzB8lZbZ0lrtU=.96e5dd9b-5f8f-4a62-b464-303472c457f9@github.com>
 <3jdex5JTctdBekXPeXMDDdAUr0a4L47GAjtNB_4UYbM=.f0ced193-89e7-4503-a9bb-af414d0747ae@github.com>
Message-ID: <KXEPnnAfYgu3ed9fxXRpFe5xVdsIp9pWx-IUzG5Mdus=.ddeadbf2-1103-4902-ba1c-a7520bbd11bc@github.com>

On Fri, 31 Jan 2025 01:02:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) 
>> jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows
>> 
>> jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int'
>>     #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683
>>     #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499
>>     #2 0x7efe9b8dee7b (<unknown module>)
>> 
>> java/awt/BasicStroke/DashStrokeTest.java shows
>> 
>> src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int'
>>     #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366
>>     #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75
>>     #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92
>>     #3 0x7fba12d07e7b (<unknown module>)
>> 
>> 
>> There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings.
>
> how it is possible to repro these warnings?

Hi @mrserb any comments? Are you fine with the change ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2684864114

From rmarchenko at openjdk.org  Wed Feb 26 16:25:08 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Wed, 26 Feb 2025 16:25:08 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <Xhazfift0fhXZ561csieC0_fVRryLwyrqLzjVxZXoZQ=.1ec44e99-c8ad-4b56-84f1-34287ae68acc@github.com>
 <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>
Message-ID: <W_OiWDrW8glv0TqhrX9PxcmgVvtdmvFwsygrqAIiS8I=.c933cbb0-21bc-492b-ba4a-8c0e76d76cd6@github.com>

On Thu, 13 Feb 2025 18:25:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>>> ...
>>> Thus, the methods of the current class have some priority over those of the parent class.
>>> But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
>> 
>> I'm still wondering if there's  any specification (tests?) describing this. At the time it looks like the current implementation is the only doc.
>> 
>> If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK. 
>> 
>> 
>> Case 1:
>>     public interface A {
>>         default public void setParentFoo(Integer num) {
>>         }
>>         default public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class D implements A {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setFoo(java.lang.Integer)
>> public void Test$D.setLocalFoo(java.lang.Long)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> 
>> 
>> Case 2:
>>     public class AC {
>>         public void setParentFoo(Integer num) {
>>         }
>>         public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class DC extends AC {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$DC.setFoo(java.lang.Number)
>> public void Test$DC.setLocalFoo(java.lang.Float)
>> public void Test$AC.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$DC.setFoo(java.lang.N...
>
>> > It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>> > ...
>> > Thus, the methods of the current class have some priority over those of the parent class.
>> > But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
> 
> There is "test/jdk/java/beans/Introspector/TestMethodOrderDependence.java" which was added to prevent accidental change in the implementation, but part of the behavior is undefined/unspecified.
> 
>>If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK.
> 
> New tests are always welcome, especially for interfaces, as they are a relatively new feature.

@mrserb If I reverse sorting order, or remove sorting at all, 2 tests are failed - OverloadedSetter and TestMethodOrderDependence. So it doesn't look an utility wrapper, as 2 tests rely on the sorting order. Or am I mistaken?

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2685557023

From duke at openjdk.org  Wed Feb 26 18:37:56 2025
From: duke at openjdk.org (Jeremy)
Date: Wed, 26 Feb 2025 18:37:56 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v3]
In-Reply-To: <8vpEH1NFfYVvCvWlGRzcNIQxjgKtsMIfaiexbpVgEWw=.e026d686-9c02-453c-bebe-e0c38ea83774@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
 <8vpEH1NFfYVvCvWlGRzcNIQxjgKtsMIfaiexbpVgEWw=.e026d686-9c02-453c-bebe-e0c38ea83774@github.com>
Message-ID: <5Ld_eZtMc8k6o-f2ql-bDZxOwHKWu4r6tVKWGNhyK6A=.fac27063-f1a7-4607-86cb-152df79ec782@github.com>

On Mon, 24 Feb 2025 08:41:47 GMT, anass baya <duke at openjdk.org> wrote:

>> The PR includes two fix : 
>> 1 - The first fix targets proper rendering of the transparent image.
>> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.
>
> anass baya has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Enhancment step 3
>  - Enhancement - step 2
>  - enhancement - step 1

src/java.desktop/macosx/classes/sun/lwawt/LWComponentPeer.java line 983:

> 981:         Image img = getLWGC().createAcceleratedImage(getTarget(), scaledWidth, scaledHeight);
> 982:         if(ScaleX == 1 || ScaleY == 1)
> 983:             return img;

Should this be `&&` instead of `||`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1972142186

From dgredler at openjdk.org  Wed Feb 26 18:46:55 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 26 Feb 2025 18:46:55 GMT
Subject: RFR: 8350203: [macos] Newlines and tabs are not ignored when
 drawing text to a Graphics2D object
In-Reply-To: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
References: <yXqHkZfKpuSVRgoDRTcnIXGCfJMGRIxn_m6jC_kFJZU=.ffbbcc1f-3b12-4f07-9483-c229cc2ed325@github.com>
Message-ID: <PK5Zo_mLn-yJEB8HIh2kcX5ti5K3QHIMe_n6RsZyRfk=.c5625fd2-5b8a-48e2-a766-d1dc8de13ef0@github.com>

On Mon, 17 Feb 2025 14:06:53 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On other platforms like Windows and Linux, the `\n`, `\r` and `\t` characters are ignored when drawing text to a `Graphics2D` object. On macOS this is not currently the case.
> 
> See, for example, `CMap.getControlCodeGlyph(int, boolean)` or `RasterPrinterJob.removeControlChars(String)`.
> 
> This bug was found while running `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` on macOS.
> 
> The new test class passes on Linux, Windows and macOS.

If anyone has a few free cycles, reviews for this PR would be much appreciated. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23665#issuecomment-2685900967

From duke at openjdk.org  Wed Feb 26 18:58:04 2025
From: duke at openjdk.org (Jeremy)
Date: Wed, 26 Feb 2025 18:58:04 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v3]
In-Reply-To: <8vpEH1NFfYVvCvWlGRzcNIQxjgKtsMIfaiexbpVgEWw=.e026d686-9c02-453c-bebe-e0c38ea83774@github.com>
References: <FePx15fSpdt4VxI8PBNKQQGK0rJ5hD535PoCfGjJGE8=.80caf254-b12c-486f-a93d-75023f35f298@github.com>
 <8vpEH1NFfYVvCvWlGRzcNIQxjgKtsMIfaiexbpVgEWw=.e026d686-9c02-453c-bebe-e0c38ea83774@github.com>
Message-ID: <cAo4f9z9a0cqS1bneBW8CJDazljaoZx8BrOBjEs26m8=.a2aced6b-6f55-4442-82fc-0d6499aab499@github.com>

On Mon, 24 Feb 2025 08:41:47 GMT, anass baya <duke at openjdk.org> wrote:

>> The PR includes two fix : 
>> 1 - The first fix targets proper rendering of the transparent image.
>> 2 - The second fix ensures the image is painted at the correct resolution to avoid pixelation.
>
> anass baya has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Enhancment step 3
>  - Enhancement - step 2
>  - enhancement - step 1

Looks good to me (note I'm not an official OpenJDK reviewer). I'm not a fan of the `instanceof Graphics2D` check, but any alternative I propose would be more lines of code so I accept this is good enough.

src/java.desktop/macosx/classes/sun/lwawt/LWComponentPeer.java line 28:

> 26: package sun.lwawt;
> 27: 
> 28: import java.awt.*;

I know in other PRs reviewers have asked to expand wildcard imports. (I haven't studied that topic closely enough to have an informed opinion.)

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

Marked as reviewed by mickleness at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/23430#pullrequestreview-2645537315
PR Review Comment: https://git.openjdk.org/jdk/pull/23430#discussion_r1972182225

From dnguyen at openjdk.org  Wed Feb 26 21:58:03 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 26 Feb 2025 21:58:03 GMT
Subject: RFR: 8348596: Update FreeType to 2.13.3 [v3]
In-Reply-To: <dFS4NMHKEep71PGKkpl1yKZLI5u1IkUmKeSBFLmxQGw=.c27741c0-328c-4169-8be0-48ce9e5456a5@github.com>
References: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
 <dFS4NMHKEep71PGKkpl1yKZLI5u1IkUmKeSBFLmxQGw=.c27741c0-328c-4169-8be0-48ce9e5456a5@github.com>
Message-ID: <xocUCydYtMoruYZIRFP3KeIj-H27n4zsGLjqAGD6fWA=.63e10be9-9a5a-483e-856a-cd730236492a@github.com>

On Wed, 19 Feb 2025 23:29:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Upgrading freetype 3rd party tool to newest update
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ws tool

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/23649#pullrequestreview-2646039263

From kizune at openjdk.org  Wed Feb 26 22:32:30 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 26 Feb 2025 22:32:30 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError
Message-ID: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>

- Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
- Add a test case

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

Commit messages:
 - 8350813: Rendering of bulky sound bank from MIDI sequence can cause OutOfMemoryError

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

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

From honkar at openjdk.org  Thu Feb 27 00:58:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 27 Feb 2025 00:58:53 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
 <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
Message-ID: <YAf1NCvPwsnuaLkj_Ei1N1D6IYjJ4Pi31aaXwZDZZJE=.2b97ce6a-31bf-4e2d-b8f5-3132f954100e@github.com>

On Tue, 25 Feb 2025 16:40:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Wayland clients are by design not allowed to change the resolution in Wayland.
>> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
>> 
>> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
>> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
>> 
>> ---
>> 
>> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
>> 
>> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
>> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
>> 
>> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
>> 
>> ---
>> 
>> Testing looks good (manual + automated).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoResizeEventOnDMChangeTest update

test/jdk/java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java line 58:

> 56:                 DisplayMode displayMode =
> 57:                         getGraphicsConfiguration().getDevice().getDisplayMode();
> 58:                 g.drawString(displayMode.toString(), 100, 100);

@azvegint 
This is on an unchanged line. The finally block in the test sets `gd.setFullScreenWindow(null);`
Is that sufficient or do we need to additionally restore the original display mode in the finally block?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23774#discussion_r1972642256

From azvegint at openjdk.org  Thu Feb 27 01:20:59 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 27 Feb 2025 01:20:59 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <YAf1NCvPwsnuaLkj_Ei1N1D6IYjJ4Pi31aaXwZDZZJE=.2b97ce6a-31bf-4e2d-b8f5-3132f954100e@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
 <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
 <YAf1NCvPwsnuaLkj_Ei1N1D6IYjJ4Pi31aaXwZDZZJE=.2b97ce6a-31bf-4e2d-b8f5-3132f954100e@github.com>
Message-ID: <VWnq_QuDDZiC3CpAW9I4rdI_StcpS7XzgBGm6rZYfbc=.120cd3a0-847b-4bff-a7e1-979b6f37ab00@github.com>

On Thu, 27 Feb 2025 00:56:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   NoResizeEventOnDMChangeTest update
>
> test/jdk/java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java line 58:
> 
>> 56:                 DisplayMode displayMode =
>> 57:                         getGraphicsConfiguration().getDevice().getDisplayMode();
>> 58:                 g.drawString(displayMode.toString(), 100, 100);
> 
> @azvegint 
> This is on an unchanged line. The finally block in the test sets `gd.setFullScreenWindow(null);`
> Is that sufficient or do we need to additionally restore the original display mode in the finally block?

This additional `drawString` was added to make the current display mode more visually distinguishable. It's hard to see just from the window filled with green color.

> The finally block in the test sets gd.setFullScreenWindow(null);
Is that sufficient or do we need to additionally restore the original display mode in the finally block?

Yes, it is sufficient, it is documented here:
https://github.com/openjdk/jdk/blob/78c18cfbcee92ba170810582e238b40b64805e5a/src/java.desktop/share/classes/java/awt/GraphicsDevice.java#L257-L262

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23774#discussion_r1972658030

From azvegint at openjdk.org  Thu Feb 27 01:37:58 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 27 Feb 2025 01:37:58 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError
In-Reply-To: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
Message-ID: <tDV6JSYL6oqG5Lx6MUnrbMQWBo4BXpm51qDHIgnoWco=.497ad9ce-af45-4b9f-8e07-8449a09989a7@github.com>

On Wed, 26 Feb 2025 22:26:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
> - Add a test case

test/jdk/javax/sound/midi/BulkSoundBank/BulkSoundBank.java line 33:

> 31:  * @bug 8350813
> 32:  * @summary Rendering of bulky sound bank from MIDI sequence can cause OutOfMemoryError.
> 33:  * @run main/othervm -Xmx1g BulkSoundBank

The test can still throw OOME with `@run main/othervm -Xmx2g BulkSoundBank` after the fix. (Tested on Ubuntu 22.04)

So it looks like the condition when we throw the `InvalidMidiDataException` should be tuned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1972667485

From serb at openjdk.org  Thu Feb 27 03:31:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Feb 2025 03:31:56 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <Xhazfift0fhXZ561csieC0_fVRryLwyrqLzjVxZXoZQ=.1ec44e99-c8ad-4b56-84f1-34287ae68acc@github.com>
 <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>
Message-ID: <vN-z-wVs61d9z8PPRENhP9P6jsX-QDt7JQNX2uPv5a4=.30b1c217-e0fe-4b10-b4fd-7a77a299dee9@github.com>

On Thu, 13 Feb 2025 18:25:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>>> ...
>>> Thus, the methods of the current class have some priority over those of the parent class.
>>> But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
>> 
>> I'm still wondering if there's  any specification (tests?) describing this. At the time it looks like the current implementation is the only doc.
>> 
>> If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK. 
>> 
>> 
>> Case 1:
>>     public interface A {
>>         default public void setParentFoo(Integer num) {
>>         }
>>         default public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class D implements A {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$D.setFoo(java.lang.Number)
>> public void Test$D.setLocalFoo(java.lang.Float)
>> public default void Test$A.setFoo(java.lang.Integer)
>> public void Test$D.setLocalFoo(java.lang.Long)
>> public default void Test$A.setParentFoo(java.lang.Integer)
>> 
>> 
>> Case 2:
>>     public class AC {
>>         public void setParentFoo(Integer num) {
>>         }
>>         public void setFoo(Integer num) {
>>         }
>>     }
>> 
>>     public class DC extends AC {
>>         public void setFoo(Number num) {
>>         }
>>         public void setLocalFoo(Long num) {
>>         }
>>         public void setLocalFoo(Float num) {
>>         }
>>     }
>> 
>> Expecting:
>> 
>> --- properties
>> public void Test$DC.setFoo(java.lang.Number)
>> public void Test$DC.setLocalFoo(java.lang.Float)
>> public void Test$AC.setParentFoo(java.lang.Integer)
>> --- methods
>> public void Test$DC.setFoo(java.lang.N...
>
>> > It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>> > ...
>> > Thus, the methods of the current class have some priority over those of the parent class.
>> > But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>> 
>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
> 
> There is "test/jdk/java/beans/Introspector/TestMethodOrderDependence.java" which was added to prevent accidental change in the implementation, but part of the behavior is undefined/unspecified.
> 
>>If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK.
> 
> New tests are always welcome, especially for interfaces, as they are a relatively new feature.

> @mrserb If I reverse sorting order, or remove sorting at all, 2 tests are failed - OverloadedSetter and TestMethodOrderDependence. So it doesn't look an utility wrapper, as 2 tests rely on the sorting order. Or am I mistaken?

I meant to delete the next code you added in the [MethodInfo.java](https://github.com/openjdk/jdk/pull/23443/files#diff-2b692928e718b6c457a50aac719ae8b1ace8a2cb2426428fca14c67035e78080):

            if (a.isDefault() != b.isDefault()) {
                return a.isDefault() ? -1 : 1; // default methods go first
            }

and update the logic for read/write in the [PropertyInfo.java#initialize](https://github.com/openjdk/jdk/pull/23443/files#diff-ef0d6cd4a6177670eb9196da7ac4d67d1eddef222aadbfbf49075e74395fe9bbL73) to get the same result.

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

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2686762227

From kizune at openjdk.org  Thu Feb 27 03:51:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 27 Feb 2025 03:51:52 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError
In-Reply-To: <tDV6JSYL6oqG5Lx6MUnrbMQWBo4BXpm51qDHIgnoWco=.497ad9ce-af45-4b9f-8e07-8449a09989a7@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
 <tDV6JSYL6oqG5Lx6MUnrbMQWBo4BXpm51qDHIgnoWco=.497ad9ce-af45-4b9f-8e07-8449a09989a7@github.com>
Message-ID: <9XgB-FZYTHxVi2k6iZx2X8IbkgtkNqSt9yQaPP9lP1w=.5ae8d8a6-7208-4310-8c66-77b7b10bf635@github.com>

On Thu, 27 Feb 2025 01:31:54 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
>> - Add a test case
>
> test/jdk/javax/sound/midi/BulkSoundBank/BulkSoundBank.java line 33:
> 
>> 31:  * @bug 8350813
>> 32:  * @summary Rendering of bulky sound bank from MIDI sequence can cause OutOfMemoryError.
>> 33:  * @run main/othervm -Xmx1g BulkSoundBank
> 
> The test can still throw OOME with `@run main/othervm -Xmx2g BulkSoundBank` after the fix. (Tested on Ubuntu 22.04)
> 
> So it looks like the condition when we throw the `InvalidMidiDataException` should be tuned.

We can not predict OOME reliably - if size of the rendered data is 99% of the remaining heap and the file i/o or background task takes more than 2% of it - the memory will eventually end, there always will be corner cases no matter what treshold we choose. In the end rendering such a huge bank will take minutes and background task might consume more memory at the time. The code here stops OOME when we know for sure we will not have enough resources and lowering the amount might stop the legitimate use case from working.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1972788944

From rmarchenko at openjdk.org  Thu Feb 27 10:35:21 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 27 Feb 2025 10:35:21 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v6]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <X6iITFbDd1ePuvGFYBALdONyK9mSKv2gY7lvE5Z9CFs=.96be107a-cf5a-4e66-9485-02aa5c933f38@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.

Roman Marchenko has updated the pull request incrementally with five additional commits since the last revision:

 - minor fix
 - minor fix
 - removed unnecessary lines
 - copyright year
 - Fixing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/a8653e04..e79589fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=04-05

  Stats: 81 lines in 4 files changed: 9 ins; 64 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From rmarchenko at openjdk.org  Thu Feb 27 10:35:21 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 27 Feb 2025 10:35:21 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v4]
In-Reply-To: <vN-z-wVs61d9z8PPRENhP9P6jsX-QDt7JQNX2uPv5a4=.30b1c217-e0fe-4b10-b4fd-7a77a299dee9@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <uB2t2ebnttSA9eCebaGAX0NLMmqTdWLrUGDANM4N-0k=.d3bb1fd0-50e2-44e2-af21-01b14f4fa06c@github.com>
 <Xhazfift0fhXZ561csieC0_fVRryLwyrqLzjVxZXoZQ=.1ec44e99-c8ad-4b56-84f1-34287ae68acc@github.com>
 <_MvPlhg7ZGfRqKDxMa39e8wo7jcmVy_20p5ZXrZi-Dw=.ae9dae58-9a5d-4233-8c2f-3cd34095c823@github.com>
 <vN-z-wVs61d9z8PPRENhP9P6jsX-QDt7JQNX2uPv5a4=.30b1c217-e0fe-4b10-b4fd-7a77a299dee9@github.com>
Message-ID: <3IijCOiNZLTCs42jNLD6cg77TZ3lwOmKBDvUfdSzqj8=.4eb5764c-4410-4cce-9926-6bbb927c9cdf@github.com>

On Thu, 27 Feb 2025 03:28:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > It was implemented in a way to minimize the difference between different 'stopClasses' for the same object. In the example above, the next call will produce the same properties:
>>> > ...
>>> > Thus, the methods of the current class have some priority over those of the parent class.
>>> > But if the same class has multiple setFoo(xxx) methods, the behavior will be undefined/unspecified.
>>> 
>>> Currently, I see from `PropertyInfo` implementation that methods are just sorted by argument's type name if arguments are not assignable from each other. So, in case `Long` vs `Number`, `Long` will be chosen (`isAssignable()` check works); in case `Float` vs `Integer`, `Float` will be chosen (sorted by type name).
>> 
>> There is "test/jdk/java/beans/Introspector/TestMethodOrderDependence.java" which was added to prevent accidental change in the implementation, but part of the behavior is undefined/unspecified.
>> 
>>>If no docs, could you review the test cases below, please? Is it correct, or redundant, or incomplete? I will add them to the test when OK.
>> 
>> New tests are always welcome, especially for interfaces, as they are a relatively new feature.
>
>> @mrserb If I reverse sorting order, or remove sorting at all, 2 tests are failed - OverloadedSetter and TestMethodOrderDependence. So it doesn't look an utility wrapper, as 2 tests rely on the sorting order. Or am I mistaken?
> 
> I meant to delete the next code you added in the [MethodInfo.java](https://github.com/openjdk/jdk/pull/23443/files#diff-2b692928e718b6c457a50aac719ae8b1ace8a2cb2426428fca14c67035e78080):
> 
>             if (a.isDefault() != b.isDefault()) {
>                 return a.isDefault() ? -1 : 1; // default methods go first
>             }
> 
> and update the logic for read/write in the [PropertyInfo.java#initialize](https://github.com/openjdk/jdk/pull/23443/files#diff-ef0d6cd4a6177670eb9196da7ac4d67d1eddef222aadbfbf49075e74395fe9bbL73) to get the same result.

@mrserb
I updated PR, could you review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2687539682

From rmarchenko at openjdk.org  Thu Feb 27 11:29:36 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 27 Feb 2025 11:29:36 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v7]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <hvvbieIyxzamJ8ao8HCfWsXqP22L6D4fbpBunZ7VvNI=.d16b4b65-88bd-4a83-aba5-9d1418ee0b85@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Symmetric fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/e79589fc..70d0be53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From rmarchenko at openjdk.org  Thu Feb 27 11:32:00 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Thu, 27 Feb 2025 11:32:00 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v7]
In-Reply-To: <hvvbieIyxzamJ8ao8HCfWsXqP22L6D4fbpBunZ7VvNI=.d16b4b65-88bd-4a83-aba5-9d1418ee0b85@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <hvvbieIyxzamJ8ao8HCfWsXqP22L6D4fbpBunZ7VvNI=.d16b4b65-88bd-4a83-aba5-9d1418ee0b85@github.com>
Message-ID: <-_qVtbRoqB9oQ3tGZtmexxgtA3nVI5JampF-c72rBxM=.39fca007-28ea-4aad-bcaf-a9f32a8e5d0f@github.com>

On Thu, 27 Feb 2025 11:29:36 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symmetric fix

src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java line 98:

> 96:                     writeType = info.type;
> 97:                 } else if (writeType.isAssignableFrom(info.type)) {
> 98:                     if ((this.write == null) || (!info.method.isDefault() && this.write.type.isAssignableFrom(info.type))) {

I cannot reproduce this because of the sorting, however it's reproduced without sorting.
Added this to make the fix symmetric between read/write properties.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r1973398822

From kevinw at openjdk.org  Thu Feb 27 16:48:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Feb 2025 16:48:13 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <w7EwNH5soJlrUBiMZGGF7pFQ98SMY_NxP-jlSPf1K-E=.9f33d393-b78b-44e4-b7fa-d47b054638d3@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters 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 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

This change is implicated in the regression JDK-8350820 in the Windows management/cpu usage functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688528615

From jwaters at openjdk.org  Thu Feb 27 16:57:05 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Feb 2025 16:57:05 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <Ew21DejHpQXKCoI4QoT9qZcPpTJbhVJmxyS1-FURJTE=.719d0640-0fa5-4fd0-a7e8-19e9e31f66bf@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters 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 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

That's not good. I cannot view JDK-8350820 however

Is the issue in HotSpot, or another component?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688552358
PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688554610

From kevinw at openjdk.org  Thu Feb 27 17:00:25 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 27 Feb 2025 17:00:25 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <Xfa55gXs5qXMaifp0YRrFKLZzAdldbbUDa4yUeDdtps=.1457e6a0-ef90-408a-bca4-212b91e393df@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters 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 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Issue recently logged, was marked confidential, will update...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2688560132

From honkar at openjdk.org  Thu Feb 27 18:31:58 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 27 Feb 2025 18:31:58 GMT
Subject: RFR: 8280991: [XWayland] No displayChanged event after
 setDisplayMode call [v2]
In-Reply-To: <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
References: <dTQ4gY04quZzhinVtCL_v7pNYy7hrrL1o1ojjc_LclI=.fe857ccd-5f03-4e16-8fec-23a061b7006c@github.com>
 <Rt_gn80msZ8Ufv8pXfnDiY5sAoMsR0XZJ0vwBt0_H-k=.687c8fb0-bcd5-440f-9adf-7178efbb1a25@github.com>
Message-ID: <mVBmHCPqd0trY0aS40wSFyEuIQzlKwOEFen_iWeim6I=.66abeb1e-39db-4201-82d9-4002491bc78a@github.com>

On Tue, 25 Feb 2025 16:40:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Wayland clients are by design not allowed to change the resolution in Wayland.
>> XRandR in Xwayland is just an emulation, it doesn't actually change the desktop resolution. This emulation is per window/x11 client, so different clients can have different emulated resolutions at the same time.
>> 
>> Any request to get the current display mode from the system will always return the original screen resolution, even if we are in emulated resolution.
>> So with this fix, we store the last display mode set so that we can react correctly to the displayChanged event later.
>> 
>> ---
>> 
>> There are two system side fixes related to this issue, which causes missing ConfigureNotify events to be emitted when an emulated resolution change occurs:
>> 
>> 1. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/731 - emits when the resolution changes to an emulated one 
>> 2. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/890 - emits when the resolution changes to a native one 
>> 
>> The second one is only available in GnomeShell 43+ (e.g. Ubuntu 22.10+), so one of the tests is excluded for versions below that.
>> 
>> ---
>> 
>> Testing looks good (manual + automated).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   NoResizeEventOnDMChangeTest update

Tested on Ubuntu. Fix looks good to me.

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23774#pullrequestreview-2648709267

From achung at openjdk.org  Thu Feb 27 19:39:37 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 27 Feb 2025 19:39:37 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v2]
In-Reply-To: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
Message-ID: <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>

> upgrading third party library to newest version

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  readd license header to files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23784/files
  - new: https://git.openjdk.org/jdk/pull/23784/files/88237a55..6531cfaf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23784&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23784&range=00-01

  Stats: 842 lines in 30 files changed: 841 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23784.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23784/head:pull/23784

PR: https://git.openjdk.org/jdk/pull/23784

From liach at openjdk.org  Thu Feb 27 21:26:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 21:26:03 GMT
Subject: RFR: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <SkOkshE90_83MXQqI6i2u8P9di1-_fy5nogdpCFLZKs=.3dd67796-83c0-4d32-8a87-b09a88727e82@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

I think I should withdraw this patch: the multi-byte access is used for 2 purposes: to read actual larger data or just to read multiple bytes for performance, and ByteArray is for the former. We should probably look at vectors for the multiple byte access purpose.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23478#issuecomment-2689141951

From liach at openjdk.org  Thu Feb 27 21:26:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 21:26:03 GMT
Subject: Withdrawn: 8349503: Consolidate multi-byte access into ByteArray
In-Reply-To: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
References: <XyEDaKKIfQq6LdweJxWq_kw7kJ03iUL94IhWQf2tTzs=.06333869-34cb-4f58-bddf-d02ba6ccbd12@github.com>
Message-ID: <u1vcmfWGYtRKa5FXTtCFIR8sShpbFRPRIYUycQEHKto=.28a878a0-8f79-4c43-b649-c4d10612ecd3@github.com>

On Wed, 5 Feb 2025 23:41:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> `MethodHandles.byteArrayViewVarHandle` exposes checked multi-byte access to byte arrays via VarHandle. This larger access speeds up many operations, yet it cannot be used in early bootstrap, and as a result, people tend to use `Unsafe` which can threaten memory safety of the Java Platform.
> 
> To promote the safe use of multi-byte access, I propose to move the checked implementations from VarHandle to ByteArray to allow earlier use and reduce maintenance costs. In addition, ByteArrayLittleEndian is consolidated, and now the access methods are distinguished by BO (byte order) / BE (big endian) / LE (little endian) suffixes to indicate their access features.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23478

From honkar at openjdk.org  Fri Feb 28 00:21:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 28 Feb 2025 00:21:53 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v2]
In-Reply-To: <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>
Message-ID: <nnPIonRyIOkJs_7cNzLVrYRfWq58HvxESBv4neecAtI=.852dc0b3-b754-40eb-a2d6-5d9c3d9e9c06@github.com>

On Thu, 27 Feb 2025 19:39:37 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> upgrading third party library to newest version
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readd license header to files

Upgrade LGTM.

Does CI and other relevant tests for LCMS upgrade look good ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/23784#pullrequestreview-2649378290

From azvegint at openjdk.org  Fri Feb 28 00:21:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Feb 2025 00:21:53 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v2]
In-Reply-To: <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>
Message-ID: <-PHVcKvSj1z3C0d9YYMPHajNaG5wQlneC3V8jMUif9c=.ab91b540-27e1-4828-b8b2-ebc094413c07@github.com>

On Thu, 27 Feb 2025 19:39:37 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> upgrading third party library to newest version
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readd license header to files

src/java.desktop/share/native/liblcms/LCMS.c line 2:

> 1: /*
> 2:  * Copyright (c) 2007, 2025, Oracle and/or its affiliates. All rights reserved.

It looks like there are no changes in this file, and it is not a part of the updated LCMS library. Why is the copyright year updated?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23784#discussion_r1974483517

From psadhukhan at openjdk.org  Fri Feb 28 03:42:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Feb 2025 03:42:47 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v16]
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: <bhR5atlEGuo6wdMrz86AEQjU5XDTg2Q0zX7MINupvH4=.d2580be0-fd0c-40d9-ab32-dc50262d7ba0@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:

  Revert to non-CSR needed fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/de139e51..9a457193

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=14-15

  Stats: 97 lines in 5 files changed: 12 ins; 78 del; 7 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 Feb 28 03:42:48 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Feb 2025 03:42:48 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v15]
In-Reply-To: <rGfbC3yxRSH1sPH7cs75_Tg-V0uOyvoFMSIU5p_sPlw=.d2a82820-edf3-49b3-92da-6fb1e53ff02b@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <rGfbC3yxRSH1sPH7cs75_Tg-V0uOyvoFMSIU5p_sPlw=.d2a82820-edf3-49b3-92da-6fb1e53ff02b@github.com>
Message-ID: <B5boc6NddMspKxKAJ68cZVEze5MuSDGaCHd0LzWkvTg=.6531880e-5cb0-4e7b-aee4-722d8a8ad87f@github.com>

On Tue, 25 Feb 2025 02:24:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move windows specific change to windows folder

@prrace As discussed, reverted to no-CSR needed fix...please review..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2689643096

From psadhukhan at openjdk.org  Fri Feb 28 03:45:29 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Feb 2025 03:45:29 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v17]
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: <rJaQOc-KMZChDjXxcXYDktOnmrhV0u4Z-k2KI2xOyNc=.69c0c464-55f8-47b9-a2cf-34646045f873@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:

  Test rename

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/9a457193..a3475a91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=15-16

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From serb at openjdk.org  Fri Feb 28 03:54:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Feb 2025 03:54:54 GMT
Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when
 trying to move mouse off screen [v11]
In-Reply-To: <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
References: <z8xeCG-w9Qbv3U9IUwz2Kt0ab5qYWuNqGjU0OCltI9o=.86675807-b1dd-4834-b482-f85223352f5a@github.com>
 <YlYYosnKClhhpAGITzPmS6dzYSJ1JoX_YReI-fdNWI4=.04c807f0-a122-4b78-ad7b-301c82f21e30@github.com>
 <741DjI-uVAuf4pjN9MqVaKz2iEI-qr-L9c6KCbP7IlY=.e46c1d54-4b0f-4cc3-b572-043923972212@github.com>
 <mwLvU39Qxbts9_I2MU5oup-aeFVOulBcjRjVvUNKLOI=.4fa7507c-b038-4e87-8dcf-6c6c9f108acc@github.com>
Message-ID: <lI8-Y3StfMzsltCf-vFdP5Oo-S1h5FRG8p21xRMnbfk=.608efc2d-671c-4a37-bfd8-b5827c9bc6cd@github.com>

On Tue, 25 Feb 2025 23:59:22 GMT, Alisen Chung <achung at openjdk.org> wrote:

> > The Robot API is just a wrapper around the native API with a basic functionality that works across all platforms. If a native macOS application can move the mouse in a certain way, why should Java be restricted?
> 
> The problem is that different platforms have different behaviors. I think since Java behavior should be consistent across platforms, it should be changed to have it's own implementation rather than just be a wrapper around the native API.

To some extent, yes, but the Robot class is part of AWT, which is a platform-dependent toolkit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2689654446

From serb at openjdk.org  Fri Feb 28 04:02:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 28 Feb 2025 04:02:59 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v7]
In-Reply-To: <-_qVtbRoqB9oQ3tGZtmexxgtA3nVI5JampF-c72rBxM=.39fca007-28ea-4aad-bcaf-a9f32a8e5d0f@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <hvvbieIyxzamJ8ao8HCfWsXqP22L6D4fbpBunZ7VvNI=.d16b4b65-88bd-4a83-aba5-9d1418ee0b85@github.com>
 <-_qVtbRoqB9oQ3tGZtmexxgtA3nVI5JampF-c72rBxM=.39fca007-28ea-4aad-bcaf-a9f32a8e5d0f@github.com>
Message-ID: <dt8Sq6Nh5wAoEUIdmQ_C55VLCCHA8s5__ALmG36jQws=.5f2218dd-73a6-48cd-a2d5-f3dc326f2ae6@github.com>

On Thu, 27 Feb 2025 11:29:37 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Symmetric fix
>
> src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java line 98:
> 
>> 96:                     writeType = info.type;
>> 97:                 } else if (writeType.isAssignableFrom(info.type)) {
>> 98:                     if ((this.write == null) || (!info.method.isDefault() && this.write.type.isAssignableFrom(info.type))) {
> 
> I cannot reproduce this because of the sorting, however it's reproduced without sorting.
> Added this to make the fix symmetric between read/write properties.

Do we always want to drop default methods here, or should we accept them if the "current method" is also a default method(or null)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r1974728330

From psadhukhan at openjdk.org  Fri Feb 28 08:56:32 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 28 Feb 2025 08:56:32 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
Message-ID: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>

Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
OCI system is ok with the fix.

-------------

Commit messages:
 - 8350924: javax/swing/JMenu/4213634/bug4213634.java fails

Changes: https://git.openjdk.org/jdk/pull/23837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350924
  Stats: 40 lines in 1 file changed: 6 ins; 14 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/23837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23837/head:pull/23837

PR: https://git.openjdk.org/jdk/pull/23837

From rmarchenko at openjdk.org  Fri Feb 28 10:09:30 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 28 Feb 2025 10:09:30 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v8]
In-Reply-To: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
Message-ID: <xl-ayf0DQmEr4jlwlYjqsJDi4hJ83Ep4wFSGPCYhdsc=.c19f4b4c-9e21-4bd0-a545-723bc5a6fc63@github.com>

> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
> 
> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.

Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:

  Fixing review comments 2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23443/files
  - new: https://git.openjdk.org/jdk/pull/23443/files/70d0be53..4f3f9285

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23443&range=06-07

  Stats: 95 lines in 2 files changed: 84 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23443/head:pull/23443

PR: https://git.openjdk.org/jdk/pull/23443

From rmarchenko at openjdk.org  Fri Feb 28 10:09:31 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 28 Feb 2025 10:09:31 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v7]
In-Reply-To: <hvvbieIyxzamJ8ao8HCfWsXqP22L6D4fbpBunZ7VvNI=.d16b4b65-88bd-4a83-aba5-9d1418ee0b85@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <hvvbieIyxzamJ8ao8HCfWsXqP22L6D4fbpBunZ7VvNI=.d16b4b65-88bd-4a83-aba5-9d1418ee0b85@github.com>
Message-ID: <sBBqx1DmogPik8YjpyHefYbUu1l0GxHT7im4O9HHMRs=.7c107051-8b89-45b4-b311-0e18a994fc5c@github.com>

On Thu, 27 Feb 2025 11:29:36 GMT, Roman Marchenko <rmarchenko at openjdk.org> wrote:

>> Fixed `com.sun.beans.introspect.MethodInfo#MethodOrder` to make `Introspector.addMethod()` working properly when filtering methods out.
>> 
>> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java.
>
> Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symmetric fix

I added 2 more test scenarios and re-worked the solution a little.

Now the test successfully passes with and without sorting enabled.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2690240398

From rmarchenko at openjdk.org  Fri Feb 28 10:09:31 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Fri, 28 Feb 2025 10:09:31 GMT
Subject: RFR: 8347826: Introspector shows wrong method list after 8071693
 [v7]
In-Reply-To: <dt8Sq6Nh5wAoEUIdmQ_C55VLCCHA8s5__ALmG36jQws=.5f2218dd-73a6-48cd-a2d5-f3dc326f2ae6@github.com>
References: <OuDnZcA9W2hiJOMtQyoZYhXl0yMDku-GLCcvLrslWD8=.47d265d1-8d87-42aa-9923-e1f7cf4e885b@github.com>
 <hvvbieIyxzamJ8ao8HCfWsXqP22L6D4fbpBunZ7VvNI=.d16b4b65-88bd-4a83-aba5-9d1418ee0b85@github.com>
 <-_qVtbRoqB9oQ3tGZtmexxgtA3nVI5JampF-c72rBxM=.39fca007-28ea-4aad-bcaf-a9f32a8e5d0f@github.com>
 <dt8Sq6Nh5wAoEUIdmQ_C55VLCCHA8s5__ALmG36jQws=.5f2218dd-73a6-48cd-a2d5-f3dc326f2ae6@github.com>
Message-ID: <JqsSDQ-1n2ENN3TQpcemWbu-400iv8fq0QT_JmZXv-k=.32a534ca-6fb7-422c-9a45-7cf21eb92033@github.com>

On Fri, 28 Feb 2025 04:00:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java line 98:
>> 
>>> 96:                     writeType = info.type;
>>> 97:                 } else if (writeType.isAssignableFrom(info.type)) {
>>> 98:                     if ((this.write == null) || (!info.method.isDefault() && this.write.type.isAssignableFrom(info.type))) {
>> 
>> I cannot reproduce this because of the sorting, however it's reproduced without sorting.
>> Added this to make the fix symmetric between read/write properties.
>
> Do we always want to drop default methods here, or should we accept them if the "current method" is also a default method(or null)?

You're right, this is a good question.
Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23443#discussion_r1975148641

From kevinw at openjdk.org  Fri Feb 28 11:18:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 28 Feb 2025 11:18:08 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <i_NSaCTA6BLRKBO6QXgjfBijY8RacgjFXR8U7OtcRLE=.c6b2bda7-afa7-4187-800f-e0cd4184ae36@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters 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 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Quick fix is PR https://github.com/openjdk/jdk/pull/23832 taking care of it in JDK 25, and there should be a backport to JDK 24 first update.  I will come back with a further update in JDK-8350939 to reinstate snprintf.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2690383444

From abhiscxk at openjdk.org  Fri Feb 28 11:27:10 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 28 Feb 2025 11:27:10 GMT
Subject: RFR: 8286204: [Accessibility,macOS,VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
Message-ID: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>

VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.

Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.

CI pipeline testing is ok for the proposed fix.

-------------

Commit messages:
 - Spinner value announcement fix

Changes: https://git.openjdk.org/jdk/pull/23841/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23841&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286204
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23841/head:pull/23841

PR: https://git.openjdk.org/jdk/pull/23841

From abhiscxk at openjdk.org  Fri Feb 28 12:37:35 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 28 Feb 2025 12:37:35 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
Message-ID: <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>

> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
> 
> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
> Manual test case is added to verify the fix.
> 
> CI pipeline testing is ok for the proposed fix.

Abhishek Kumar has updated the pull request incrementally with three additional commits since the last revision:

 - space fix
 - whitespace fix
 - Copyright year update and manual test case added

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23841/files
  - new: https://git.openjdk.org/jdk/pull/23841/files/b58f4db9..dec1c007

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23841&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23841&range=00-01

  Stats: 76 lines in 2 files changed: 75 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23841/head:pull/23841

PR: https://git.openjdk.org/jdk/pull/23841

From azvegint at openjdk.org  Fri Feb 28 14:46:02 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Feb 2025 14:46:02 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly returns
 null
Message-ID: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>

During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:


Method method = CACHE.get(signature);
return (method == null) ? method : CACHE.create(signature);

This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).

----

Before ReflectUtil was removed, it worked by coincidence:


Method method = CACHE.get(signature);
return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);




1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition


https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126

2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true

This is how we previously returned the cached value.

---

So the solution is obvious:


Method method = CACHE.get(signature);
return (method != null) ? method : CACHE.create(signature);


Testing is green.

-------------

Commit messages:
 - 8344892: beans/finder/MethodFinder.findMethod incorrectly returns null

Changes: https://git.openjdk.org/jdk/pull/23845/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23845&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344892
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23845.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23845/head:pull/23845

PR: https://git.openjdk.org/jdk/pull/23845

From azvegint at openjdk.org  Fri Feb 28 14:51:54 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Feb 2025 14:51:54 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
Message-ID: <Vr-ZEE9167mQWaIgOevhLj5xjuMgyVUbNc0wUyuWAEM=.9c8b7657-e32d-40d3-babf-0aeb6c138fb6@github.com>

On Fri, 28 Feb 2025 14:41:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) ? method : CACHE.create(signature);
> 
> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
> 
> ----
> 
> Before ReflectUtil was removed, it worked by coincidence:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
> 
> 
> 
> 
> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
> 
> 
> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
> 
> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
> 
> This is how we previously returned the cached value.
> 
> ---
> 
> So the solution is obvious:
> 
> 
> Method method = CACHE.get(signature);
> return (method != null) ? method : CACHE.create(signature);
> 
> 
> Testing is green.

src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java line 81:

> 79:         try {
> 80:             Method method = CACHE.get(signature);
> 81:             return (method != null) ? method : CACHE.create(signature);

This can be simplified to the `return CACHE.get(signature)`, since we know that the implementation creates the value in the get method:

https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126

However, I am not a fan of this solution as it is implementation dependent and this behavior is not documented.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1975538624

From aivanov at openjdk.org  Fri Feb 28 15:50:06 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 15:50:06 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out in
 Windows 10
Message-ID: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>

**Problem:**

The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)

Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.

**Fix, or Workaround:**

Drag mouse for a short while.

In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.

There have been no failures after the fix in 10 runs with 20 repeats.

-------------

Commit messages:
 - 8224968: javax/swing/JColorChooser/Test6827032.java times out in Windows 10

Changes: https://git.openjdk.org/jdk/pull/23846/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8224968
  Stats: 33 lines in 2 files changed: 13 ins; 11 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23846/head:pull/23846

PR: https://git.openjdk.org/jdk/pull/23846

From aivanov at openjdk.org  Fri Feb 28 15:50:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 15:50:07 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <_wQyMx24UAfravOKR3lyk6RcyAD9W1nhgJBxWANm6Xk=.a4db71b9-dca9-4d06-95c2-ef142f3ec7ab@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

test/jdk/javax/swing/JColorChooser/Test6827032.java line 27:

> 25:  * @test
> 26:  * @key headful
> 27:  * @bug 6827032

[JDK-8197825](https://bugs.openjdk.org/browse/JDK-8197825) was a test stabilisation fix, we don't add such bugs into the `@bug` tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23846#discussion_r1975632755

From aivanov at openjdk.org  Fri Feb 28 16:11:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 16:11:10 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <2nHBYhlM_MDJbJ9YBWsLuVRzLUnVHU-lzJpf-q3ZZb4=.8d80025d-7fe3-4ece-9969-c6b5ad93d801@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
 <2nHBYhlM_MDJbJ9YBWsLuVRzLUnVHU-lzJpf-q3ZZb4=.8d80025d-7fe3-4ece-9969-c6b5ad93d801@github.com>
Message-ID: <mAvfsxq6CP3BPFsMO6DnkWb8hDH4044aeWDWhVJBHGQ=.0c954414-6b24-4e41-bbb4-208f6243d8c6@github.com>

On Fri, 28 Feb 2025 16:06:10 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> > Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [StreamCopier](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See threaddump.log attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> This looks like we should file an issue against jtreg, as I don't see anything wrong with the test either.

Yes. I'd like to start an internal discussion first and then submit a bug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23846#issuecomment-2691029272

From azvegint at openjdk.org  Fri Feb 28 16:11:10 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Feb 2025 16:11:10 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <2nHBYhlM_MDJbJ9YBWsLuVRzLUnVHU-lzJpf-q3ZZb4=.8d80025d-7fe3-4ece-9969-c6b5ad93d801@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [StreamCopier](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See threaddump.log attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.

This looks like we should file an issue against jtreg, as I don't see anything wrong with the test either.

-------------

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23846#pullrequestreview-2651179884

From aivanov at openjdk.org  Fri Feb 28 17:56:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 17:56:57 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <dxj7W3OJqZx_QSU9xQlSuiTOGZigvppx_XjwDwBO1GI=.ec49dcd1-3240-40b7-96d3-615fb779d269@github.com>

On Fri, 28 Feb 2025 08:50:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 65:

> 63: 
> 64:     public static void createAndShowGUI() {
> 65:         frame = new JFrame("TEST");

Could you use a more specific title?

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 88:

> 86:         SwingUtilities.invokeAndWait(() -> {
> 87:             frame.dispose();
> 88:             if (!menu.isSelected()) {

Previously, the condition `!menu.isSelected()` was verified before the frame was disposed of.

I think you should verify whether menu is select before disposing of the frame; once the frame is disposed of, the state of components is not well-defined.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23837#pullrequestreview-2651432599
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1975805598
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1975816414

From aivanov at openjdk.org  Fri Feb 28 18:11:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 18:11:10 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <Vr-ZEE9167mQWaIgOevhLj5xjuMgyVUbNc0wUyuWAEM=.9c8b7657-e32d-40d3-babf-0aeb6c138fb6@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <Vr-ZEE9167mQWaIgOevhLj5xjuMgyVUbNc0wUyuWAEM=.9c8b7657-e32d-40d3-babf-0aeb6c138fb6@github.com>
Message-ID: <_HAbLsDWyXBG68JmdP65CDcuha-P0vi3u83HmyPsKNw=.141ba8d0-4082-45ea-bbd3-ab50768ff90e@github.com>

On Fri, 28 Feb 2025 14:48:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) ? method : CACHE.create(signature);
>> 
>> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
>> 
>> ----
>> 
>> Before ReflectUtil was removed, it worked by coincidence:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
>> 
>> 
>> 
>> 
>> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
>> 
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
>> 
>> This is how we previously returned the cached value.
>> 
>> ---
>> 
>> So the solution is obvious:
>> 
>> 
>> Method method = CACHE.get(signature);
>> return (method != null) ? method : CACHE.create(signature);
>> 
>> 
>> Testing is green.
>
> src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java line 81:
> 
>> 79:         try {
>> 80:             Method method = CACHE.get(signature);
>> 81:             return (method != null) ? method : CACHE.create(signature);
> 
> This can be simplified to the `return CACHE.get(signature)`, since we know that the implementation creates the value in the get method:
> 
> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
> 
> However, I am not a fan of this solution as it is implementation dependent and this behavior is not documented.

I think this is confusing? If `CACHE.get(signature)` always returns a non-null value, there's no need for the condition `method != null` ? it's always true.

The javadoc for the `Cache` class specifies a `null` value can be returned:

https://github.com/openjdk/jdk/blob/e98df71d9c5120fbb73a4c2f49863775fe5db781/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L98-L99

Is it a bug in `Cache` class that it creates the value and adds it to the cache when the value isn't found?

https://github.com/openjdk/jdk/blob/e98df71d9c5120fbb73a4c2f49863775fe5db781/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L126-L127

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1975832067

From duke at openjdk.org  Fri Feb 28 18:11:07 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Fri, 28 Feb 2025 18:11:07 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <H_-teQfl9vZ4S9M6nLtYeJbh91UufezXytxP4IIA4kU=.52416b00-1931-4ecb-badc-68336cf56f3a@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23846#pullrequestreview-2651478703

From duke at openjdk.org  Fri Feb 28 18:18:09 2025
From: duke at openjdk.org (duke)
Date: Fri, 28 Feb 2025 18:18:09 GMT
Subject: Withdrawn: 8346436: Compilation with clang fails
In-Reply-To: <2T1MSOZ5x2Aui8EwMvWvLEXeUGmty5PLl1nuAWSZZ74=.02465712-ad35-48c7-83e9-8e825b92f35a@github.com>
References: <2T1MSOZ5x2Aui8EwMvWvLEXeUGmty5PLl1nuAWSZZ74=.02465712-ad35-48c7-83e9-8e825b92f35a@github.com>
Message-ID: <3CsK5YgwsJOV6BGISamtVGqhU9W4RbrY9C09WS3BflY=.9a3f187f-7c93-4bf2-9931-47b64fe7484b@github.com>

On Tue, 17 Dec 2024 14:57:42 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> clang-18.1.8-1.fc40.x86_64
> Fedora 40 x86_64
> fbd76ca8edd756ff2ebbc9f6477cc1a827df67b0
> 
> 
> src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>   695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 );
>       | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:375:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>   375 | write(splash->controlpipe[1], &code, 1);
>       | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:713:5: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
>   713 | pipe(splash->controlpipe);
>       | ^~~~ ~~~~~~~~~~~~~~~~~~~
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h:45:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined]
>    45 | #define dprintf(s)
>       | ^
> /usr/include/bits/stdio2.h:121:12: note: previous definition is here
>   121 | # define dprintf(fd, ...) \
>       | ^
> src/java.smartcardio/share/native/libj2pcsc/pcsc.c:48:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined]
>    48 | #define dprintf(s)
>       | ^
> /usr/include/bits/stdio2.h:121:12: note: previous definition is here
>   121 | # define dprintf(fd, ...) \
>       | ^

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22794

From prr at openjdk.org  Fri Feb 28 18:24:13 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Feb 2025 18:24:13 GMT
Subject: RFR: 8348596: Update FreeType to 2.13.3 [v3]
In-Reply-To: <dFS4NMHKEep71PGKkpl1yKZLI5u1IkUmKeSBFLmxQGw=.c27741c0-328c-4169-8be0-48ce9e5456a5@github.com>
References: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
 <dFS4NMHKEep71PGKkpl1yKZLI5u1IkUmKeSBFLmxQGw=.c27741c0-328c-4169-8be0-48ce9e5456a5@github.com>
Message-ID: <5op_NRl5HILwrl-4cQOJMabrSwSYHooYyO2OD6HO9nE=.cf9b38e0-b4cf-474b-9e17-3ea2ad86e2ee@github.com>

On Wed, 19 Feb 2025 23:29:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Upgrading freetype 3rd party tool to newest update
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ws tool

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23649#pullrequestreview-2651501605

From honkar at openjdk.org  Fri Feb 28 18:38:57 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 28 Feb 2025 18:38:57 GMT
Subject: RFR: 8286204: [Accessibility, macOS,
 VoiceOver] VoiceOver reads the
 spinner value 10 as 1 when user iterates to 10 for the first time on macOS
 [v2]
In-Reply-To: <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
References: <8z-zsXaX0i3ZFFD4Q-EvHeiYZTiOPRN_NtjoYYMSS9A=.b08d0f23-81a9-422d-9a64-51d7f85b03a3@github.com>
 <mJLWVAvTm5dlGuA6zlHROGAI6TC2WZO1frH-LQazBwo=.38129a5c-9433-406c-97af-a8c80246282e@github.com>
Message-ID: <RvpMJ6hArtFzLTe9SdAU2jKztCCbof_NlxIOITPsgtg=.f1c2808d-5513-4916-b103-b999c330d628@github.com>

On Fri, 28 Feb 2025 12:37:35 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> VoiceOver is unable to announce the correct value for spinner. For JSpinner with maximum value of more than 10, VO announce 10 as 1, 20 as 2 and so on. Probable reason is the "ACCESSIBLE_TEXT_PROPERTY" fired by accessible JTextComponent that leads to wrong range value invoked for accessibility API by VO.
>> Workaround fix is to ensure "ACCESSIBLE_TEXT_PROPOERTY" is not fired in case of JSpinner with numeric values.
>> 
>> Since the fix is in Java Component, verified fix with JAWS on windows. I don't see any side effects in announcement.
>> Manual test case is added to verify the fix.
>> 
>> CI pipeline testing is ok for the proposed fix.
>
> Abhishek Kumar has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - space fix
>  - whitespace fix
>  - Copyright year update and manual test case added

Tested the fix on macOS 15.3.1. The fix works intermittently for me. It announces percentage most of the time and then suddenly just a number.

test/jdk/javax/accessibility/TestJSpinnerAccessibility.java line 50:

> 48:                 Follow these steps to test the behaviour:
> 49: 
> 50:                 1. Start the VoiceOver (Press Commaand + F5) application

Suggestion:

                1. Start the VoiceOver (Press Command + F5) application

-------------

PR Review: https://git.openjdk.org/jdk/pull/23841#pullrequestreview-2651526126
PR Review Comment: https://git.openjdk.org/jdk/pull/23841#discussion_r1975862607

From dnguyen at openjdk.org  Fri Feb 28 18:43:02 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 28 Feb 2025 18:43:02 GMT
Subject: RFR: 8224968: javax/swing/JColorChooser/Test6827032.java times out
 in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <lcHRlOhrqIB5vce3c9sxY7tftOrBcfU-D2_0_l_hgpg=.cbd8eb12-c1e8-4fad-b366-8e0abfc67d36@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

Interesting workaround. Works nicely from what I can tell. Agreed that I don't see anything particularly wrong with the test itself, but this change works. The additional time of dragging barely adds any time to the test too, which is nice.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23846#pullrequestreview-2651533872

From prr at openjdk.org  Fri Feb 28 18:43:03 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Feb 2025 18:43:03 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v2]
In-Reply-To: <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>
Message-ID: <xDGD93XX_MyQSjh6lyNacSRd3MW1Ledq3illJTgOCWs=.d1272531-aa65-4f8b-a6a4-92aac420243a@github.com>

On Thu, 27 Feb 2025 19:39:37 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> upgrading third party library to newest version
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readd license header to files

Please confirm this has been fully tested.

-------------

PR Review: https://git.openjdk.org/jdk/pull/23784#pullrequestreview-2651527765

From prr at openjdk.org  Fri Feb 28 18:43:04 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Feb 2025 18:43:04 GMT
Subject: RFR: 8348110: Update LCMS to 2.17 [v2]
In-Reply-To: <-PHVcKvSj1z3C0d9YYMPHajNaG5wQlneC3V8jMUif9c=.ab91b540-27e1-4828-b8b2-ebc094413c07@github.com>
References: <mOD-ECMfQHt7_P_Bvs7hvoCN-r3z4QU4iGducUYnqrU=.a706b0b5-d4ff-4cc6-9eb5-360c0ac55612@github.com>
 <wMBSxW5o02jTqGl4fNyHsyDosMzQQUtEebsMS74RzMc=.3fe8a6a0-d39a-4445-a463-0c9c0fd19fe3@github.com>
 <-PHVcKvSj1z3C0d9YYMPHajNaG5wQlneC3V8jMUif9c=.ab91b540-27e1-4828-b8b2-ebc094413c07@github.com>
Message-ID: <oqhhD8jLK0x0TMni324R3runG5TTs7g3olTTmPNvTCk=.9c34c313-ac53-4111-9590-cf70f3e43683@github.com>

On Thu, 27 Feb 2025 23:20:34 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   readd license header to files
>
> src/java.desktop/share/native/liblcms/LCMS.c line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2007, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> It looks like there are no changes in this file, and it is not a part of the updated LCMS library. Why is the copyright year updated?

Yes, this needs to be reverted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23784#discussion_r1975862902

From liach at openjdk.org  Fri Feb 28 18:46:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 18:46:55 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <_HAbLsDWyXBG68JmdP65CDcuha-P0vi3u83HmyPsKNw=.141ba8d0-4082-45ea-bbd3-ab50768ff90e@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <Vr-ZEE9167mQWaIgOevhLj5xjuMgyVUbNc0wUyuWAEM=.9c8b7657-e32d-40d3-babf-0aeb6c138fb6@github.com>
 <_HAbLsDWyXBG68JmdP65CDcuha-P0vi3u83HmyPsKNw=.141ba8d0-4082-45ea-bbd3-ab50768ff90e@github.com>
Message-ID: <eL-exxZ4t3XdI6om8WUcahoKp-TBlEcrySh3wKEFLu0=.2edce9f0-f75f-4543-a1bd-8a54f7443ea4@github.com>

On Fri, 28 Feb 2025 18:06:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/beans/finder/MethodFinder.java line 81:
>> 
>>> 79:         try {
>>> 80:             Method method = CACHE.get(signature);
>>> 81:             return (method != null) ? method : CACHE.create(signature);
>> 
>> This can be simplified to the `return CACHE.get(signature)`, since we know that the implementation creates the value in the get method:
>> 
>> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
>> 
>> However, I am not a fan of this solution as it is implementation dependent and this behavior is not documented.
>
> I think this is confusing? If `CACHE.get(signature)` always returns a non-null value, there's no need for the condition `method != null` ? it's always true.
> 
> The javadoc for the `Cache` class specifies a `null` value can be returned:
> 
> https://github.com/openjdk/jdk/blob/e98df71d9c5120fbb73a4c2f49863775fe5db781/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L98-L99
> 
> Is it a bug in `Cache` class that it creates the value and adds it to the cache when the value isn't found?
> 
> https://github.com/openjdk/jdk/blob/e98df71d9c5120fbb73a4c2f49863775fe5db781/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L126-L127

Sorry for my last premature comment.

I have looked at `Cache`, and believe `create` should be made protected to indicate it is not intended to be called, but only overridden.

The preexisting code called `create` to reuse the creation mechanism without going through the cache - such usage is dubious. Per my experience, similar conditional caches are better implemented by enclosing the logic into the cache structure and use a common endpoint to access, so we have one universal site to determine the conditionality of caching. In this case, such a condition is better included in the `Cache` class itself, and the `create` method should not be publicly exposed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1975870725

From honkar at openjdk.org  Fri Feb 28 18:50:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 28 Feb 2025 18:50:00 GMT
Subject: RFR: 8350813: Rendering of bulky sound bank from MIDI sequence can
 cause OutOfMemoryError
In-Reply-To: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
References: <l1NX_0LHvTNwaWtpe34oq5fzVrUcYWjhp-t3IWdvxSI=.46da0d0b-aac0-4506-a165-be967b78201b@github.com>
Message-ID: <N3Bx0i53mmqxmRj7PnbfuEJZusjk765jJCZ684VoLhc=.d8a0d513-1daa-4d3d-b292-0f268073937e@github.com>

On Wed, 26 Feb 2025 22:26:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> - Check that the calculated audio data size does not exceed available heap memory before committing to the rendering
> - Add a test case

test/jdk/javax/sound/midi/BulkSoundBank/BulkSoundBank.java line 52:

> 50:         }
> 51:         throw new RuntimeException("Test should throw InvalidMidiDataException but it did not.");
> 52:     }

ByteArrayInputStream can be initialized within try-with resources block.

Suggestion:

        try (ByteArrayInputStream bis = new ByteArrayInputStream(midi)) {
            MidiSystem.getSoundbank(bis);
            throw new RuntimeException("Test should throw InvalidMidiDataException" 
                                       + " but it did not.");
        } catch (InvalidMidiDataException imda) {
            System.out.println("Caught InvalidMidiDataException as expected");
        }
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23814#discussion_r1975873774

From aivanov at openjdk.org  Fri Feb 28 18:52:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 18:52:52 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <eL-exxZ4t3XdI6om8WUcahoKp-TBlEcrySh3wKEFLu0=.2edce9f0-f75f-4543-a1bd-8a54f7443ea4@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <Vr-ZEE9167mQWaIgOevhLj5xjuMgyVUbNc0wUyuWAEM=.9c8b7657-e32d-40d3-babf-0aeb6c138fb6@github.com>
 <_HAbLsDWyXBG68JmdP65CDcuha-P0vi3u83HmyPsKNw=.141ba8d0-4082-45ea-bbd3-ab50768ff90e@github.com>
 <eL-exxZ4t3XdI6om8WUcahoKp-TBlEcrySh3wKEFLu0=.2edce9f0-f75f-4543-a1bd-8a54f7443ea4@github.com>
Message-ID: <V65o9P-Vwogy5EjgsJhMIRUtBb3dfpheq9Ditlp2nLQ=.f430a3f5-65e9-478b-9215-134de58decac@github.com>

On Fri, 28 Feb 2025 18:44:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I think this is confusing? If `CACHE.get(signature)` always returns a non-null value, there's no need for the condition `method != null` ? it's always true.
>> 
>> The javadoc for the `Cache` class specifies a `null` value can be returned:
>> 
>> https://github.com/openjdk/jdk/blob/e98df71d9c5120fbb73a4c2f49863775fe5db781/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L98-L99
>> 
>> Is it a bug in `Cache` class that it creates the value and adds it to the cache when the value isn't found?
>> 
>> https://github.com/openjdk/jdk/blob/e98df71d9c5120fbb73a4c2f49863775fe5db781/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L126-L127
>
> Sorry for my last premature comment.
> 
> I have looked at `Cache`, and believe `create` should be made protected to indicate it is not intended to be called, but only overridden.
> 
> The preexisting code called `create` to reuse the creation mechanism without going through the cache - such usage is dubious. Per my experience, similar conditional caches are better implemented by enclosing the logic into the cache structure and use a common endpoint to access, so we have one universal site to determine the conditionality of caching. In this case, such a condition is better included in the `Cache` class itself, and the `create` method should not be publicly exposed.

Yes, I'd prefer `CACHE.get(signature)`.

At the same time, I've got doubts that Alexander has?

Although, strictly speaking, it is not ?implementation dependent? because the `Cache` class is part of OpenJDK, and I think it's reasonable to depend on its implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23845#discussion_r1975876473

From aivanov at openjdk.org  Fri Feb 28 19:02:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 19:02:53 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
Message-ID: <EYX01O5Ti0A1QYlMGnyHrCJ5x2xcEO-JqTXDQhnaxmE=.e9c0f2e3-e4db-4652-b481-2ecc13d9b5b1@github.com>

On Fri, 28 Feb 2025 14:41:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) ? method : CACHE.create(signature);
> 
> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
> 
> ----
> 
> Before ReflectUtil was removed, it worked by coincidence:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
> 
> 
> 
> 
> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
> 
> 
> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
> 
> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
> 
> This is how we previously returned the cached value.
> 
> ---
> 
> So the solution is obvious:
> 
> 
> Method method = CACHE.get(signature);
> return (method != null) ? method : CACHE.create(signature);
> 
> 
> Testing is green.

It's somewhat off-topic, yet I find it *worrying*.

The `Cache.get` method starts with *unsynchronised access first*.

https://github.com/openjdk/jdk/blob/e98df71d9c5120fbb73a4c2f49863775fe5db781/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L112-L114

It doesn't make sense? First of all, if the method can be accessed concurrently, which seems to be implied, the `table` field could be in an inconsistent state. This could result in hard-to-reproduce bugs.

Secondly, the `Cache.get` invokes `removeStaleEntries` which has a `synchronized` block. That is the `get` method still requires explicit synchronisation. Having this in mind, *the unsynchronised access to the data structures doesn't gain anything*.

Performance-wise, it would be better to wrap the call to `removeStaleEntries` and the required logic into `synchronized (this.queue)`. 

Thirdly, there's another call to `removeStaleEntries` in the `get` method, this time it's inside the `synchronized (this.queue)` block.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23845#issuecomment-2691348842

From honkar at openjdk.org  Fri Feb 28 19:05:52 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 28 Feb 2025 19:05:52 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <QJ3zaRbNR_99xQD-kCe8Lf3UdNde36cyZkR30vc-UcQ=.0dca51cf-9111-4371-be75-b3c3adb0346e@github.com>

On Fri, 28 Feb 2025 08:50:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 42:

> 40:  * @key headful
> 41:  * @bug 4213634 8017187
> 42:  * @library ../../regtesthelpers

Suggestion:

 * @library /java/awt/regtesthelpers

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 80:

> 78:     }
> 79: 
> 80:     private static void test() throws AWTException, InterruptedException, InvocationTargetException {

Suggestion:

    private static void test() throws Exception {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1975885981
PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1975886766

From honkar at openjdk.org  Fri Feb 28 19:05:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 28 Feb 2025 19:05:53 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
In-Reply-To: <dxj7W3OJqZx_QSU9xQlSuiTOGZigvppx_XjwDwBO1GI=.ec49dcd1-3240-40b7-96d3-615fb779d269@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
 <dxj7W3OJqZx_QSU9xQlSuiTOGZigvppx_XjwDwBO1GI=.ec49dcd1-3240-40b7-96d3-615fb779d269@github.com>
Message-ID: <gqMLWVtbsUHdhlmCEaeCSOLXcR5Gn1eLI6140XDY8fc=.db396911-566c-43ba-9e90-75dae7318e8c@github.com>

On Fri, 28 Feb 2025 17:53:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
>> OCI system is ok with the fix.
>
> test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 88:
> 
>> 86:         SwingUtilities.invokeAndWait(() -> {
>> 87:             frame.dispose();
>> 88:             if (!menu.isSelected()) {
> 
> Previously, the condition `!menu.isSelected()` was verified before the frame was disposed of.
> 
> I think you should verify whether menu is select before disposing of the frame; once the frame is disposed of, the state of components is not well-defined.

I agree, frame.dispose() can be added within finally block instead of here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1975889962

From liach at openjdk.org  Fri Feb 28 19:22:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 19:22:52 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <EYX01O5Ti0A1QYlMGnyHrCJ5x2xcEO-JqTXDQhnaxmE=.e9c0f2e3-e4db-4652-b481-2ecc13d9b5b1@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
 <EYX01O5Ti0A1QYlMGnyHrCJ5x2xcEO-JqTXDQhnaxmE=.e9c0f2e3-e4db-4652-b481-2ecc13d9b5b1@github.com>
Message-ID: <5CVWmLFCt5v6j6s77IqrIVWRkZuSaSFUxiAA-VqvPIM=.73df3a3a-7550-4b68-bc83-22e7577badf3@github.com>

On Fri, 28 Feb 2025 18:59:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> *the unsynchronised access to the data structures doesn't gain anything*

The existing optimistic fast path can avoid the lock, with the assumption that garbage collection of the cache values are rare. It is fine. However these plain access do require that the cached values to be thread safe and support safe publication.

Given the huge complexity of this cache and confusions around it, I recommend checking out `jdk.internal.util.ReferencedKeyMap`, which is already exported to `java.desktop` module.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23845#issuecomment-2691383449

From aivanov at openjdk.org  Fri Feb 28 19:34:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 19:34:52 GMT
Subject: RFR: 8344892: beans/finder/MethodFinder.findMethod incorrectly
 returns null
In-Reply-To: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
References: <AdU9LBoER9U76VqBdULRKOgf2mekMOnSf6EpcdWXYy4=.964d92c3-b630-4c3c-a82e-4384f581aa3c@github.com>
Message-ID: <V55VpIhctRZPZG5JtRz953W6F0nLUu-SsIp19X9-AEo=.b0f3f608-7709-46c2-9d1b-889475b5d9fd@github.com>

On Fri, 28 Feb 2025 14:41:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> During the [JDK-8344891 Remove uses of sun.misc.ReflectUtil in java.desktop](https://bugs.openjdk.org/browse/JDK-8344891) it was discovered that `beans/finder/MethodFinder.findMethod' incorrectly returned null if a signature was not in the cache and added it to the cache if it was already there:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) ? method : CACHE.create(signature);
> 
> This resulted in a [significant drop in performance](https://bugs.openjdk.org/browse/JDK-8350573).
> 
> ----
> 
> Before ReflectUtil was removed, it worked by coincidence:
> 
> 
> Method method = CACHE.get(signature);
> return (method == null) || isPackageAccessible(method.getDeclaringClass()) ? method : CACHE.create(signature);
> 
> 
> 
> 
> 1. `Cache#get` non-obviously creates a value in Cache, this in turn allowed us to avoid the NPE in the `(method == null) || isPackageAccessible(method.getDeclaringClass())` condition
> 
> 
> https://github.com/openjdk/jdk/blob/d6c4be672f6348f8ed985416ed90d0447f5d5bb3/src/java.desktop/share/classes/com/sun/beans/util/Cache.java#L120-L126
> 
> 2. `isPackageAccessible(method.getDeclaringClass())` was evaluated as true
> 
> This is how we previously returned the cached value.
> 
> ---
> 
> So the solution is obvious:
> 
> 
> Method method = CACHE.get(signature);
> return (method != null) ? method : CACHE.create(signature);
> 
> 
> Testing is green.

> > _the unsynchronised access to the data structures doesn't gain anything_
> 
> The existing optimistic fast path can avoid the lock, with the assumption that garbage collection of the cache values are rare. It is fine. However these plain access do require that the cached values to be thread safe and support safe publication.

You're right, the lock in `removeStaleEntries` is acquired if there's a reference to remove.

Accessing the `table` field isn't safe without synchronisation. When the table is re-allocated, it may go awry.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23845#issuecomment-2691403946

From aivanov at openjdk.org  Fri Feb 28 19:56:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 28 Feb 2025 19:56:52 GMT
Subject: RFR: 8350924: javax/swing/JMenu/4213634/bug4213634.java fails
In-Reply-To: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
References: <h4s1lVBLsNOF-o7MeQQU9AgRBN3LX31cKuE1Ely2XMw=.1900766b-a689-4378-847b-46ed03112fb8@github.com>
Message-ID: <bDwR7oV-taRWRp_k-wNHvbG29W7BcenPVxJHv9g-VsU=.f3a3268e-4456-4d72-9d32-1d92c8fd616d@github.com>

On Fri, 28 Feb 2025 08:50:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in ubuntu OCI system..Made it more robust my adding waitForIdle/delay before commencing test..
> OCI system is ok with the fix.

test/jdk/javax/swing/JMenu/4213634/bug4213634.java line 71:

> 69:         frame.setJMenuBar(mb);
> 70:         JTextArea ta = new JTextArea("This test dedicated to Nancy and Kathleen, testers and bowlers extraordinaire\n\n\nNo exception means pass.");
> 71:         frame.getContentPane().add("Center", ta);

The text area seems redundant, especially the text inside which looks like an [Easter egg](https://en.wikipedia.org/wiki/Easter_egg_(media)).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23837#discussion_r1975942628

From achung at openjdk.org  Fri Feb 28 21:25:01 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 28 Feb 2025 21:25:01 GMT
Subject: Integrated: 8348596: Update FreeType to 2.13.3
In-Reply-To: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
References: <hoxqZqnYCNX32XpxhFSt3b4gHJL5MExWO-Sw1UA9Pcs=.db0840c7-03c4-4a8e-b727-8b4cf13881c1@github.com>
Message-ID: <7HM6GahBSSOV5Hn5AgIeBAQn5JswajwLB-bxwZwRMVE=.e43070eb-85ed-4620-8820-3614b2222f06@github.com>

On Fri, 14 Feb 2025 20:45:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Upgrading freetype 3rd party tool to newest update

This pull request has now been integrated.

Changeset: 6b719eee
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b719eeebc346fd4655fc718d7d033b3ebf54d9e
Stats:     3796 lines in 280 files changed: 996 ins; 1647 del; 1153 mod

8348596: Update FreeType to 2.13.3

Reviewed-by: azvegint, dnguyen, prr

-------------

PR: https://git.openjdk.org/jdk/pull/23649

From prr at openjdk.org  Fri Feb 28 23:47:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Feb 2025 23:47:54 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v6]
In-Reply-To: <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <grWRA6u6XUAT570_leNQmhE6-DVe3c9MAJk-KBtpOIU=.6b1859d4-8deb-44f1-9f1b-6f166c747d28@github.com>
 <2tZ5ZlWFeRoBPvUpyUsadwdzVUM_-Hp0Nk7iLogdzqY=.74644b95-1c05-4544-86aa-1ba3e6c0654c@github.com>
Message-ID: <1wfT2PtTYMvOaP0wr4oAPo_gDneqo4fGch1zapRcYdw=.39f099a1-7ade-4318-ac28-38bfe1ca4ea1@github.com>

On Mon, 24 Feb 2025 16:31:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc update
>
> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1170:
> 
>> 1168:      * @throws IllegalArgumentException if {@code tagSignature} is not a
>> 1169:      *         signature as defined in the ICC specification.
>> 1170:      * @throws IllegalArgumentException if a content of the {@code tagData}
> 
> This is an existing issue, if it's an issue: should the text say *?**the** content?* instead of *?**a** content?*? @prrace

Yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1976123856

From prr at openjdk.org  Fri Feb 28 23:47:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 28 Feb 2025 23:47:53 GMT
Subject: RFR: JDK-8346465 : Add a check in setData() to restrict the update
 of Built-In ICC_Profiles [v5]
In-Reply-To: <pXJAY4trqd22WdLY8VkkXdyWOxPfEi546DwMN0dxBhA=.90e3dad5-7932-4a47-9ff9-8cc21e692c7e@github.com>
References: <wzIMIddx6AnkKEY0REHx5zKUVndvTn7IbYWguj7jEwk=.f2a8aa6f-e4b4-40d2-90a0-6b441f7c7a94@github.com>
 <nN0564w_elvZ75rOYp6Y6wDvRoCpVHyDoZChbrEoX2A=.4b1cdad3-a303-4b1d-a227-a370680cfeda@github.com>
 <3_4w7ORolKKOG1ylCMn6yuDKlAaVeFvku0zETs2lwLk=.d455fa8e-9a22-4ecd-aefb-c454a36c5e10@github.com>
 <PRqQ3aF6vlDbc_YXYPXqe5W102xdlJ2cOd4h-tomXZs=.055a6c99-f051-4033-a6bc-87c37f49d340@github.com>
 <bYpyUBFmTYg0csvj0UktP9qZd3GkLsYEoOFMVBG9uk0=.37347544-b64b-4ffd-ad54-10834b30a11f@github.com>
 <fbzDZUYcIXfRKkfqob8bqcn6dd7hWgyWyPcssBz8L-M=.596f720b-b7da-4c2e-825b-5d74d9471474@github.com>
 <G-PRPycRYcqWvvdpxaJEjEhqNi3uZHBDXBixvK5Z_j4=.c3455078-94d1-4dd1-a88c-317da3765f29@github.com>
 <qKLPNJNlvvabD7l9RFGYNImduYcnq-T853ci9RJUqT4=.0972d0c6-392f-4436-991e-04ca94bf45c1@github.com>
 <w8M8yoJ524jLkPV7E7snC16XPinIuZQhSASClCAOIHk=.654812e8-4c2d-4693-abb6-3c930072c973@github.com>
 <E4Q7glxWdlCxUOsypIZMeC4YGGrUk3NKiOzG8jvd4uM=.11d3b33f-0459-4f04-9837-7e89908ca869@github.com>
 <rm_datMxZJKwEvs4lqfz8g4yrFHNGufSkPA
 28zZ9wTI=.84c76e85-4fb4-40bc-9b0d-b1c567d68eb3@github.com>
 <pXJAY4trqd22WdLY8VkkXdyWOxPfEi546DwMN0dxBhA=.90e3dad5-7932-4a47-9ff9-8cc21e692c7e@github.com>
Message-ID: <nWAFGMzONh6Lfnaad0xecXvVqxmLiGPLXguX7WkyEXE=.adadf8bb-6fd2-47aa-90d7-aa7152a69dcd@github.com>

On Mon, 24 Feb 2025 20:04:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> There are other way to create a profile - directly loading it form a file (serialization) `ICC_Profile.getInstance(<path to sRGB.pf or any custom profiles>); `or using the byte array representation of the profile. So the main intention here was not to tie ProfileDeferralInfo with isBuiltIn.
>> 
>> Yes, there are. Does any other way create a **built-in profile**? No, it doesn't as far as I can see.
>> 
>> Is this flexibility needed? I'd say, it's not needed? unless there's a very high chance there'll soon be introduced a new build-in ICC profile which is created in another way but `ICC_Profile(ProfileDeferralInfo)` constructor.
>
>> Yes, there are. Does any other way create a built-in profile? No, it doesn't as far as I can see.
> 
> Yes, currently ProfileDeferralInfo  is the only way to create built-in profile.
> 
>> Is this flexibility needed? I'd say, it's not needed? unless there's a very high chance there'll soon be introduced a new build-in ICC profile which is created in another way but ICC_Profile(ProfileDeferralInfo) constructor.
> 
> As of now we don't need the flexibility but not sure if that is something that we may require or need to consider in future. @prrace Your suggestion ?

So in fact Harshitha had prototyped the constructor mechanism - but it was passing a parameter so wasn't as small a diff as the most recent alternate, because I think it rippled into changing the sub-class constructors as well, which made it less desirable.
Another particular concern was that it was equating ProfileDeferralInfo to meaning isBuiltIn == true, which is the case today, but it is not a fundamental truth.
And the proposal here is more direct and you don't have to go follow the bread crumbs to see exactly which profiles have this set to true.  So that is why the PR is as it is.
Neither is "wrong" - they are just different choices based on different perceptions.

But if we can do this with changes to *just this class*, then may be .. and since I see the sub-class constructors (for RGB and Gray) call the same signature super-class constructors, then I think this should work, and it will be OK.
I tried it on a local repo, and came up with the same changes as suggested and it least builds .. 
So we can do it that way too, but there should be a comment somewhere that ProfileDeferralInfo is only for built-in profiles - and that in fact all built-in profiles should use it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1976123437