From serb at openjdk.org  Wed Oct  1 00:18:06 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 1 Oct 2025 00:18:06 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26
In-Reply-To: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
Message-ID: <lgaiw2CABaQ_OwvYujWxKU1mg6EkPgzo9wIg7YaKf1w=.b4313c43-766d-40cb-aa55-6ba9925d8726@github.com>

On Tue, 30 Sep 2025 23:46:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This test fails on macOS 26 due to slight color mismatch at background frame edges. A offset of 4 pixels is added as fix.
> 
> CI testing passes on other platforms.

test/jdk/java/awt/Frame/DisposeTest.java line 42:

> 40:  * @summary Tests that disposing of a Frame with MenuBar removes all traces
> 41:  *          of the Frame from the screen.
> 42:  * @run main/othervm -Dsun.java2d.uiScale=1 DisposeTest

Why do you need to set scale factor=1, does the default break something?

test/jdk/java/awt/Frame/DisposeTest.java line 80:

> 78: 
> 79:         for (int x = PIXEL_OFFSET; x < bi.getWidth() - PIXEL_OFFSET; x++) {
> 80:             for (int y = PIXEL_OFFSET; y < bi.getHeight() - PIXEL_OFFSET; y++) {

It might be better to increase the size of the background frame so that its edge does not appear under the tested frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27585#discussion_r2393110080
PR Review Comment: https://git.openjdk.org/jdk/pull/27585#discussion_r2393111551

From honkar at openjdk.org  Wed Oct  1 00:43:56 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 1 Oct 2025 00:43:56 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26
In-Reply-To: <lgaiw2CABaQ_OwvYujWxKU1mg6EkPgzo9wIg7YaKf1w=.b4313c43-766d-40cb-aa55-6ba9925d8726@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
 <lgaiw2CABaQ_OwvYujWxKU1mg6EkPgzo9wIg7YaKf1w=.b4313c43-766d-40cb-aa55-6ba9925d8726@github.com>
Message-ID: <NkmEywfmQko2qYTbM-7akRbaS1JH2MOFJ3P_Qj8tzz0=.e006262d-b24e-4a82-8055-411c87440a43@github.com>

On Wed, 1 Oct 2025 00:13:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This test fails on macOS 26 due to slight color mismatch at background frame edges. A offset of 4 pixels is added as fix.
>> 
>> CI testing passes on other platforms.
>
> test/jdk/java/awt/Frame/DisposeTest.java line 42:
> 
>> 40:  * @summary Tests that disposing of a Frame with MenuBar removes all traces
>> 41:  *          of the Frame from the screen.
>> 42:  * @run main/othervm -Dsun.java2d.uiScale=1 DisposeTest
> 
> Why do you need to set scale factor=1, does the default break something?

It doesn't break as such but based on my observation a couple of previous test on windows fail when there is fractional scaling + color comparison at edges. Set the uiScale to 1 to make the test robust.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27585#discussion_r2393153313

From honkar at openjdk.org  Wed Oct  1 00:48:38 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 1 Oct 2025 00:48:38 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26
In-Reply-To: <lgaiw2CABaQ_OwvYujWxKU1mg6EkPgzo9wIg7YaKf1w=.b4313c43-766d-40cb-aa55-6ba9925d8726@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
 <lgaiw2CABaQ_OwvYujWxKU1mg6EkPgzo9wIg7YaKf1w=.b4313c43-766d-40cb-aa55-6ba9925d8726@github.com>
Message-ID: <wf6uPTC-7nfpfPDvvO5qbtc0PcFNEGSU7glqyI_gAcw=.9b08e5cd-93ce-48d3-9c35-5496ab58e460@github.com>

On Wed, 1 Oct 2025 00:15:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This test fails on macOS 26 due to slight color mismatch at background frame edges. A offset of 4 pixels is added as fix.
>> 
>> CI testing passes on other platforms.
>
> test/jdk/java/awt/Frame/DisposeTest.java line 80:
> 
>> 78: 
>> 79:         for (int x = PIXEL_OFFSET; x < bi.getWidth() - PIXEL_OFFSET; x++) {
>> 80:             for (int y = PIXEL_OFFSET; y < bi.getHeight() - PIXEL_OFFSET; y++) {
> 
> It might be better to increase the size of the background frame so that its edge does not appear under the tested frame.

Currently the backroundFrame is 200x200 and testFrame is 100x100. The difference of 100 seems sufficient for this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27585#discussion_r2393161972

From aivanov at openjdk.org  Wed Oct  1 09:45:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 1 Oct 2025 09:45:14 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state
In-Reply-To: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
Message-ID: <Om1JWS2hw2ok9HfuXCsKZTK_TVpg3Vwe6qmNzTtAOAU=.9ff82f29-2449-4e95-9f63-280c55ff6a8b@github.com>

On Tue, 23 Sep 2025 07:10:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
> 
> 100 iterations of the test passed in all platforms.

Looks fine.

However, I'd like to reduce the delay of 2 seconds to smaller value?

test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java line 92:

> 90:             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
> 91:             robot.waitForIdle();
> 92:             robot.delay(2000);

I wonder if syncing with `mousePressed` event handler on the button and adding a little delay after `mousePressed` is triggered would allow for smaller delay. Anyway, using an event handler will *guarantee*, the same handler is called in `ButtonUI`. We will still need a delay to allow the button UI delegate to handle the event and to repaint the button, yet that delay less than 2 seconds would be enough.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27444#pullrequestreview-3288320215
PR Review Comment: https://git.openjdk.org/jdk/pull/27444#discussion_r2394006008

From duke at openjdk.org  Wed Oct  1 10:08:22 2025
From: duke at openjdk.org (duke)
Date: Wed, 1 Oct 2025 10:08:22 GMT
Subject: Withdrawn: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features
In-Reply-To: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
Message-ID: <Wb9NdXAomelFWJWZja85IpUxj6E7CTAA8p1YyBQqQ8o=.bc20a0e4-ca33-478b-b729-15552d55944a@github.com>

On Sun, 6 Jul 2025 16:29:51 GMT, Valery Semenchuk <duke at openjdk.org> wrote:

> Introducing to API constants, and implementation for controlling Figure Styles
> 
> Target font: *Inter*
> 
> Example screenshot 
> 
> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)

This pull request has been closed without being integrated.

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

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

From hampus.ram at gmail.com  Wed Oct  1 12:23:00 2025
From: hampus.ram at gmail.com (Hampus Ram)
Date: Wed, 1 Oct 2025 14:23:00 +0200
Subject: Comments on the JDatePicker UI Component draft JEP
Message-ID: <CAJO5KZj5upB-9xcmGAdyNQ0hp-Xe3R=3cTaQfDDv6eeXS0svPw@mail.gmail.com>

Hello,

Saw the draft JEP for the JDatePicker UI Component  (and the accompanying
issue JDK-8368874) and thought I'd chime in with some observations (that
may have very well already been considered) but that I think would be
necessary for me to use such a control in an application.

A feature that I have found lacking in other date picker components in the
past, and that isn't fully clear if it is intended to be supported in this
JEP is using WeekFields.getFirstDayOfWeek() or similar. The examples all
start on a sunday, but in many places around the world the week starts on a
monday. The calendar should be able to reflect that and maybe that should
be clarified somewhere?

Another feature often missing or neglected that I'm fairly certain isn't at
all in the JEP is the ability to show week numbers. At least here in Sweden
many organizations (and most schools) use week numbers for recurring things
such as vacation and school holidays. Of course this is also something that
works differently in different locales and would need to be handled
correctly. However I don't think it needs to be anything other than a
visual component, you do not need to be able to select a week by clicking
it or supporting any other interaction.

Just my two cents :)

Regards,
Hampus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251001/f8c0ffa1/attachment.htm>

From azvegint at openjdk.org  Wed Oct  1 18:24:00 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 1 Oct 2025 18:24:00 GMT
Subject: RFR: 8298823: [macos]
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with
 "No MouseReleased event on label!" [v4]
In-Reply-To: <9vvWHaii3QGKfYXmWcua3BoW9YDffTy6UcDG23-srME=.dad86d7d-483b-4565-a680-375bc8f61f93@github.com>
References: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
 <9vvWHaii3QGKfYXmWcua3BoW9YDffTy6UcDG23-srME=.dad86d7d-483b-4565-a680-375bc8f61f93@github.com>
Message-ID: <81LQXFCOQt9UQIfbULtaVxiZ4lQeZ3-9zUV1WHrKu1M=.1fc4f265-ced1-4a55-bdb5-4915fb501b71@github.com>

On Fri, 26 Sep 2025 16:44:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Test is currently problem-listed due to the test failing on both macOS arm and x64 machines. Updated the test to use `SwingUtilities.invokeAndWait` and use the EDT to dispose of the frame. Also needed to modify the delay for stability. Initially, I removed `setAutoDelay` since this has caused issues previously, but this caused a failure in linux (when previously linux has never failed). However, keeping the auto delay and adding additional small delays seems to be stable with all of the other changes to the test. The test passes in CI with multiple runs of 100 on all OS's with the proposed changes.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move listener. Add count reset.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27478#pullrequestreview-3290453552

From serb at openjdk.org  Wed Oct  1 18:43:41 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 1 Oct 2025 18:43:41 GMT
Subject: RFR: 8167268: StandardGlyphVector.getGlyphMetrics creates metrics
 with erroneous bounds for characters with no outline (e.g.,
 the space character ' ') [v2]
In-Reply-To: <F-jqJP_5yHCVLBb585i8VuAUC8cwZMo-8ziG9hwCF8Y=.9e95ec9b-98d5-44a0-a3af-76a6bed6e738@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
 <slQnmRm2eXxz8rIUUFmaJoYvxfZchHvTRGbCyzBjPJE=.a881a5d5-aa19-4d6c-870a-073737482f1d@github.com>
 <F-jqJP_5yHCVLBb585i8VuAUC8cwZMo-8ziG9hwCF8Y=.9e95ec9b-98d5-44a0-a3af-76a6bed6e738@github.com>
Message-ID: <uf6Ii4gISYZ2FGS7RebsknbOQO0wQLSJ1UI_ExjNIB4=.36a12b25-e86b-4184-b0c9-cc0a3e8c02f8@github.com>

On Tue, 30 Sep 2025 20:08:37 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/font/StandardGlyphVector.java line 611:
>> 
>>> 609: 
>>> 610:         Rectangle2D vb = getGlyphVisualBounds(ix).getBounds2D();
>>> 611:         if (!vb.isEmpty()) {
>> 
>> Just to double check: do we want to skip glyphs only when the bounds are empty, or we also want to skip them when the bounds are flipped (negative width/height)?
>
> Do you know when that might happen? This code gets its values (after a few layers of abstraction) from `StandardGlyphVector$GlyphStrike.getGlyphOutlineBounds(int, float, float)`, which has a similar `isEmpty` check.

I am not sure if it is possible, but I would like to make sure we did not introduce any issues, since isEmpty() will skip ?flipped? bounds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27580#discussion_r2395509254

From serb at openjdk.org  Wed Oct  1 18:44:35 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 1 Oct 2025 18:44:35 GMT
Subject: RFR: 8368892: Make JEditorPane/TestBrowserBGColor.java headless
In-Reply-To: <oeou7wBPkbuu2ZFw-JXFzSVaoxOadKl33OJvi-DenU4=.21ff4a96-b6b2-49c5-b073-8657f05099bd@github.com>
References: <oeou7wBPkbuu2ZFw-JXFzSVaoxOadKl33OJvi-DenU4=.21ff4a96-b6b2-49c5-b073-8657f05099bd@github.com>
Message-ID: <FXaVjfJ9lYdnPGekIhpPBNlP6jqEjJx6Y8U2lkevnbU=.375369e8-489b-474b-8f76-3eb995d30192@github.com>

On Mon, 29 Sep 2025 20:16:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is to update `javax/swing/JEditorPane/TestBrowserBGColor.java` and to let it run headless.
> 
> Currently, the test creates a frame with `JEditorPane` with an HTML document the background color of which is set with three hex digits, `background: #FFF`. Then the test uses `Robot.getPixelColor` to verify the color of the pixel on the screen.
> 
> Now, the editor pane is rendered into a buffered image, this is needed to ensure text is laid out. The test then searches for a view that represents the `<body>` element and verifies that its background color is set to the expected *white* color. If it isn't so, the test saves the image for reference and throws an exception to indicate failure.
> 
> The updated test fails with JDK 11 because [JDK-8213781](https://bugs.openjdk.org/browse/JDK-8213781) isn't backported yet; the test passes with later versions including mainline. I ran the updated test on the CI, and it passes.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27556#pullrequestreview-3290535398

From serb at openjdk.org  Wed Oct  1 19:03:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 1 Oct 2025 19:03:37 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
In-Reply-To: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
Message-ID: <2KLzlUDFuAWk84q5Gm1zSKw_q0XZO90QpmIURSF8gMQ=.b0ac6502-6f5b-4a95-b998-2061cbd03e43@github.com>

On Mon, 29 Sep 2025 16:15:45 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> There is a reproducible bug in symbol rendering on Windows machines with [particular](https://github.com/openjdk/jdk/blob/9d71af108ea2cc3682607527246d60a19fd820ba/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L244) default locales. This changeset fixes the deferred font initialisation request, which now skips the last font in the list. 
> 
> The test (attached to the jira) was performed on a Windows 11 machine with the Japanese locale set as the default.  Without the fix, it fails with an NPE. With the fix it displays a window showing glyphs drawn by all the fonts accessible from the Java application.

src/java.desktop/share/classes/sun/font/CompositeFont.java line 117:

> 115:             deferredInitialisation = new boolean[numSlots];
> 116:             if (defer) {
> 117:                 for (int i=0; i<numSlots-1; i++) {

Do we have any jtreg tests that can reproduce the bug in the JP locale? If not, it would be good to create one based on the test described in the bug report.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2395571658

From mbaesken at openjdk.org  Thu Oct  2 07:18:02 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Oct 2025 07:18:02 GMT
Subject: RFR: 8368775: Remove outdated comment in OutlineTextRenderer
In-Reply-To: <UTyNMpFcRsQEPZqKtPbnWNfkItriVltY4O-tyKCiNxo=.4c2dbcdc-79af-42d2-beaf-9badd647217a@github.com>
References: <EzGv0TKs6RQUYSfcjHUQXNDYOtPoevyKI8JzYCSM804=.b99ffdcb-f05d-4c9e-89b5-3de6171b24a1@github.com>
 <N6GcrqkfLuIFvf3OwtNTgBiGyQw3dvIB1gnvp9ak8LE=.dbc5c163-1f10-47d8-ac51-fc81099caf14@github.com>
 <UTyNMpFcRsQEPZqKtPbnWNfkItriVltY4O-tyKCiNxo=.4c2dbcdc-79af-42d2-beaf-9badd647217a@github.com>
Message-ID: <-XgXxzHrCOcOh-zyQuMXWmM5Y3xDH76vejh66k4YNyc=.c4fb58f5-57f8-420e-8c64-a74cc9f10309@github.com>

On Fri, 26 Sep 2025 18:54:03 GMT, Phil Race <prr at openjdk.org> wrote:

> > You can use str.isEmpty() here.
> 
> I was actually going for consistency with all of the other optimizations of this type, which all use a length check. I can change it to `isEmpty` if you feel strongly about it, though.
> 

Hi, you replaced this strange `''".equals`  check ; is this because it looks not nice compared to length or isEmpty or for other reasons ? I ask because there are quite a few of those checks in the codebase (below are only some of them) .



src/java.base/share/classes/java/lang/runtime/ObjectMethods.java:416:                List<String> nameList = "".equals(names) ? List.of() : List.of(names.split(";"));
src/java.base/share/classes/java/net/NetworkInterface.java:230:        return "".equals(displayName) ? null : displayName;
src/java.base/share/classes/java/net/SocketPermission.java:885:        if (this.wildcard && "".equals(this.cname))
src/java.base/share/classes/java/security/CodeSource.java:466:            if (("".equals(thisHost) || "localhost".equals(thisHost)) &&
src/java.base/share/classes/java/security/CodeSource.java:467:                ("".equals(thatHost) || "localhost".equals(thatHost))) {
src/java.base/share/classes/java/text/CompactNumberFormat.java:2546:            !"".equals(compactPatterns[index])) { // ignore empty pattern
src/java.base/share/classes/sun/security/tools/keytool/Main.java:931:            if ("".equals(dest)) {
src/java.base/share/classes/sun/security/tools/keytool/Main.java:939:            if ("".equals(alias)) {
src/java.base/share/classes/sun/security/tools/keytool/Main.java:2510:                    if ("".equals(newAlias)) {
src/java.base/share/classes/sun/security/util/SecurityProperties.java:155:        if ("".equals(rawPropVal)) {
src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java:604:        } else if ("".equals(pattern)) {
src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java:246:        if (!text.hasFocus() && "".equals(text.getText())) {
src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java:290:        button.setVisible(!"".equals(text.getText()));
src/java.desktop/share/classes/com/sun/media/sound/JDK13Services.java:175:        if ("".equals(value)) {
src/java.desktop/share/classes/java/awt/FileDialog.java:153:                    fileDialog.file = ("".equals(file)) ? null : file;
src/java.desktop/share/classes/java/awt/FileDialog.java:156:                    fileDialog.dir = ("".equals(directory)) ? null : directory;
src/java.desktop/share/classes/java/beans/PropertyDescriptor.java:101:        if ("".equals(readMethodName) || "".equals(writeMethodName)) {
src/java.desktop/share/classes/javax/swing/JTable.java:5567:                if ("".equals(s)) {
src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java:1450:                            (!(value instanceof String) || !"".equals(value))) {
src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java:551:                if ("".equals(text)) {
src/java.desktop/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java:276:        if (useCheckAndArrow() && (!"".equals(getAccText()))) {
src/java.desktop/share/classes/javax/swing/text/html/CSS.java:1064:        if (borderValue == HTML.NULL_ATTRIBUTE_VALUE || "".equals(borderValue)) {
src/java.desktop/share/classes/javax/swing/undo/AbstractUndoableEdit.java:230:        if (!"".equals(name)) {
src/java.desktop/share/classes/javax/swing/undo/AbstractUndoableEdit.java:257:        if (!"".equals(name)) {
src/java.desktop/share/classes/sun/font/TrueTypeFont.java:696:        if ("".equals(encoding)) {
src/java.desktop/share/classes/sun/font/TrueTypeFont.java:1493:        while (!"".equals(key)) {
src/java.desktop/share/classes/sun/java2d/pipe/OutlineTextRenderer.java:76:        if ("".equals(str)) {
src/java.naming/share/classes/com/sun/jndi/url/ldap/ldapURLContext.java:76:        if (!"".equals(dn)) {
src/java.naming/share/classes/com/sun/jndi/url/ldap/ldapURLContextFactory.java:65:        if (!"".equals(dn)) {
src/java.net.http/share/classes/jdk/internal/net/http/HeaderParser.java:232:            if (val != null && "".equals (val)) {
src/java.net.http/share/classes/jdk/internal/net/http/ResponseBodyHandlers.java:215:            if ("".equals(src))

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

PR Comment: https://git.openjdk.org/jdk/pull/27523#issuecomment-3359526026

From serb at openjdk.org  Thu Oct  2 08:46:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Oct 2025 08:46:56 GMT
Subject: RFR: 8368892: Make JEditorPane/TestBrowserBGColor.java headless
In-Reply-To: <ohnKDbof7EOG5Tf7xqobxUo5VWDAKyMaTbP95M_UDkM=.df61bea1-213d-42be-a6b4-87a616fde014@github.com>
References: <oeou7wBPkbuu2ZFw-JXFzSVaoxOadKl33OJvi-DenU4=.21ff4a96-b6b2-49c5-b073-8657f05099bd@github.com>
 <ohnKDbof7EOG5Tf7xqobxUo5VWDAKyMaTbP95M_UDkM=.df61bea1-213d-42be-a6b4-87a616fde014@github.com>
Message-ID: <NaYXfPKjEpKpGYpS3Gi7kbe0iJg76Qs4aq0Y4VauCw4=.9b88ff9b-bb20-4384-846e-ecbbc737ce65@github.com>

On Mon, 29 Sep 2025 20:44:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> What do others think about changing `background: #FFF` to `background: #CCC`?
> 
> The white background is the default for text components. If parsing the color fails, the background color will remain white. With `#CCC`, the test will fail if the color remains white, the default color; it will also fail if `#CCC` is decoded as `0x000CCC` as was the case before [JDK-8213781](https://bugs.openjdk.org/browse/JDK-8213781) was fixed.

Up to you, both are fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/27556#issuecomment-3359914107

From dgredler at openjdk.org  Thu Oct  2 10:00:56 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 2 Oct 2025 10:00:56 GMT
Subject: RFR: 8368775: Remove outdated comment in OutlineTextRenderer
In-Reply-To: <-XgXxzHrCOcOh-zyQuMXWmM5Y3xDH76vejh66k4YNyc=.c4fb58f5-57f8-420e-8c64-a74cc9f10309@github.com>
References: <EzGv0TKs6RQUYSfcjHUQXNDYOtPoevyKI8JzYCSM804=.b99ffdcb-f05d-4c9e-89b5-3de6171b24a1@github.com>
 <N6GcrqkfLuIFvf3OwtNTgBiGyQw3dvIB1gnvp9ak8LE=.dbc5c163-1f10-47d8-ac51-fc81099caf14@github.com>
 <UTyNMpFcRsQEPZqKtPbnWNfkItriVltY4O-tyKCiNxo=.4c2dbcdc-79af-42d2-beaf-9badd647217a@github.com>
 <-XgXxzHrCOcOh-zyQuMXWmM5Y3xDH76vejh66k4YNyc=.c4fb58f5-57f8-420e-8c64-a74cc9f10309@github.com>
Message-ID: <gJdJ-Re_aU1BTae96mR8GP1b8b-lRfS6X_AxcbV8XLg=.cc9bdd68-cc2c-4a63-83de-2a9b01719188@github.com>

On Thu, 2 Oct 2025 07:14:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> > You can use str.isEmpty() here.
>>> 
>>> I was actually going for consistency with all of the other optimizations of this type, which all use a length check. I can change it to `isEmpty` if you feel strongly about it, though.
>> 
>> I think a lot of cases were written before isEmpty() existed so would have used length().
>> isEmpty() might perform a 'tiny' bit better. But that's all.
>> 
>>> 
>>> > Do we actually call this method with an empty string?
>>> 
>>> I do think it's possible, e.g. from `SunGraphics2D.drawString(String, int, int)` and `SunGraphics2D.drawString(String, float, float)` when the font doesn't have layout attributes, or a few other places when `OutlineTextRenderer.drawChars(...)` delegates to `OutlineTextRenderer.drawString(...)`.
>> 
>> I agree.
>> Even if we added some checks there, it would require work to prove that there's no way to get here with an empty string.
>> I see no harm in the check here, especially if we aren't 100% confident.
>
>> > You can use str.isEmpty() here.
>> 
>> I was actually going for consistency with all of the other optimizations of this type, which all use a length check. I can change it to `isEmpty` if you feel strongly about it, though.
>> 
> 
> Hi, you replaced this strange `''".equals`  check ; is this because it looks not nice compared to length or isEmpty or for other reasons ? I ask because there are quite a few of those checks in the codebase (below are only some of them) .
> 
> 
> 
> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java:416:                List<String> nameList = "".equals(names) ? List.of() : List.of(names.split(";"));
> src/java.base/share/classes/java/net/NetworkInterface.java:230:        return "".equals(displayName) ? null : displayName;
> src/java.base/share/classes/java/net/SocketPermission.java:885:        if (this.wildcard && "".equals(this.cname))
> src/java.base/share/classes/java/security/CodeSource.java:466:            if (("".equals(thisHost) || "localhost".equals(thisHost)) &&
> src/java.base/share/classes/java/security/CodeSource.java:467:                ("".equals(thatHost) || "localhost".equals(thatHost))) {
> src/java.base/share/classes/java/text/CompactNumberFormat.java:2546:            !"".equals(compactPatterns[index])) { // ignore empty pattern
> src/java.base/share/classes/sun/security/tools/keytool/Main.java:931:            if ("".equals(dest)) {
> src/java.base/share/classes/sun/security/tools/keytool/Main.java:939:            if ("".equals(alias)) {
> src/java.base/share/classes/sun/security/tools/keytool/Main.java:2510:                    if ("".equals(newAlias)) {
> src/java.base/share/classes/sun/security/util/SecurityProperties.java:155:        if ("".equals(rawPropVal)) {
> src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java:604:        } else if ("".equals(pattern)) {
> src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java:246:        if (!text.hasFocus() && "".equals(text.getText())) {
> src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java:290:        button.setVisible(!"".equals(text.getText()));
> src/java.desktop/share/classes/com/sun/media/sound/JDK13Services.java:175:        if ("".equals(value)) {
> src/java.desktop/share/classes/java/awt/FileDialog.java:153:                    fileDialog.file = ("".equals(file)) ? null : file;
> src/java.desktop/share/classes/java/awt/FileDialog.java:156:                    fileDialog.dir = ("".equals(directory)) ? null : directory;
> src/java.des...

@MBaesken We decided to keep the check as a pure optimization (not just a safety check required to avoid an exception) after seeing that there are other similar checks (as optimizations) in the code base, and used this specific formulation simply for consistency with all of the other existing equivalent checks (see list here: https://github.com/openjdk/jdk/pull/26947#issuecomment-3329884998).

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

PR Comment: https://git.openjdk.org/jdk/pull/27523#issuecomment-3360249841

From asemenov at openjdk.org  Thu Oct  2 10:07:49 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 2 Oct 2025 10:07:49 GMT
Subject: RFR: 8365609: Fix several potential NULL native pointer
 dereferences in the desktop module
In-Reply-To: <DWDzmPz9NuO_zs57aeufdU2mfPg2XMAi_sgxja4GBFM=.0a08a649-3cda-41f3-9c3d-a043b1c8da58@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <DWDzmPz9NuO_zs57aeufdU2mfPg2XMAi_sgxja4GBFM=.0a08a649-3cda-41f3-9c3d-a043b1c8da58@github.com>
Message-ID: <Lc8RZ43wxqeBXzeyFiIA-NJ0kbzV8dTvO0FTlILRtu0=.83edce33-cb81-4d08-b97e-22ed494a35fd@github.com>

On Fri, 15 Aug 2025 17:05:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function OGLBlitToSurfaceViaTexture() located in the file src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null.
>> 
>> In the same file, line 551 calls OGLBlitToSurfaceViaTexture() from line 263, where NULL is passed in place of pf.
>> All other calls are fine.
>> 
>> Also, another function with a similar issue from the same file, OGLBlitSwToTexture() from line 396.
>> 
>> In src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c gtk3_load()
>> The pointer fp_glib_check_version can be null, but it is dereferenced without any check. Although in the same file, for example, line 280 contains a check, this check does not lead to termination of execution.
>> 
>> 
>> In src/java.desktop/share/native/libsplashscreen/splashscreen_gif.c SplashDecodeGif()
>> The pointer colorMap is dereferenced after it has been checked against nullptr in lines 151 and 206. Moreover, between these checks and the mentioned location (line 282), the pointer is not modified in any way.
>> 
>> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.
>
>>The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> It is better first to confirm whether this pointer can actually be NULL. If it cannot then remove the unnecessary earlier NULL check.

@mrserb Do you agree with this option?

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

PR Comment: https://git.openjdk.org/jdk/pull/26799#issuecomment-3360279247

From azvegint at openjdk.org  Thu Oct  2 13:04:48 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 2 Oct 2025 13:04:48 GMT
Subject: RFR: 8368892: Make JEditorPane/TestBrowserBGColor.java headless
In-Reply-To: <oeou7wBPkbuu2ZFw-JXFzSVaoxOadKl33OJvi-DenU4=.21ff4a96-b6b2-49c5-b073-8657f05099bd@github.com>
References: <oeou7wBPkbuu2ZFw-JXFzSVaoxOadKl33OJvi-DenU4=.21ff4a96-b6b2-49c5-b073-8657f05099bd@github.com>
Message-ID: <2Z14pC5iRmE7OhDaWduwTYrKaIu1cGZiqWl9W3cRPmA=.071de87f-7939-4efa-ad88-831f994670ca@github.com>

On Mon, 29 Sep 2025 20:16:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is to update `javax/swing/JEditorPane/TestBrowserBGColor.java` and to let it run headless.
> 
> Currently, the test creates a frame with `JEditorPane` with an HTML document the background color of which is set with three hex digits, `background: #FFF`. Then the test uses `Robot.getPixelColor` to verify the color of the pixel on the screen.
> 
> Now, the editor pane is rendered into a buffered image, this is needed to ensure text is laid out. The test then searches for a view that represents the `<body>` element and verifies that its background color is set to the expected *white* color. If it isn't so, the test saves the image for reference and throws an exception to indicate failure.
> 
> The updated test fails with JDK 11 because [JDK-8213781](https://bugs.openjdk.org/browse/JDK-8213781) isn't backported yet; the test passes with later versions including mainline. I ran the updated test on the CI, and it passes.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27556#pullrequestreview-3294521657

From snazarki at openjdk.org  Thu Oct  2 13:13:27 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Thu, 2 Oct 2025 13:13:27 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
In-Reply-To: <2KLzlUDFuAWk84q5Gm1zSKw_q0XZO90QpmIURSF8gMQ=.b0ac6502-6f5b-4a95-b998-2061cbd03e43@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <2KLzlUDFuAWk84q5Gm1zSKw_q0XZO90QpmIURSF8gMQ=.b0ac6502-6f5b-4a95-b998-2061cbd03e43@github.com>
Message-ID: <F4O2BYAAeKlIeF5CssLZWIFRYPZv30Qw_v7VeqI138c=.a7b5f54f-6c1c-4b14-89de-e2d35765c013@github.com>

On Wed, 1 Oct 2025 19:00:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There is a reproducible bug in symbol rendering on Windows machines with [particular](https://github.com/openjdk/jdk/blob/9d71af108ea2cc3682607527246d60a19fd820ba/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L244) default locales. This changeset fixes the deferred font initialisation request, which now skips the last font in the list. 
>> 
>> The test (attached to the jira) was performed on a Windows 11 machine with the Japanese locale set as the default.  Without the fix, it fails with an NPE. With the fix it displays a window showing glyphs drawn by all the fonts accessible from the Java application.
>
> src/java.desktop/share/classes/sun/font/CompositeFont.java line 117:
> 
>> 115:             deferredInitialisation = new boolean[numSlots];
>> 116:             if (defer) {
>> 117:                 for (int i=0; i<numSlots-1; i++) {
> 
> Do we have any jtreg tests that can reproduce the bug in the JP locale? If not, it would be good to create one based on the test described in the bug report.

The fallback font may have legal issues and installing eudc.ttf on the test machine may be challenging.   I'll try to reproduce the issue using the EN_US locale and an open-source font.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2398794300

From aivanov at openjdk.org  Thu Oct  2 18:59:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Oct 2025 18:59:55 GMT
Subject: RFR: 8298823: [macos]
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with
 "No MouseReleased event on label!" [v4]
In-Reply-To: <9vvWHaii3QGKfYXmWcua3BoW9YDffTy6UcDG23-srME=.dad86d7d-483b-4565-a680-375bc8f61f93@github.com>
References: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
 <9vvWHaii3QGKfYXmWcua3BoW9YDffTy6UcDG23-srME=.dad86d7d-483b-4565-a680-375bc8f61f93@github.com>
Message-ID: <YdXbu6LYE_fV96V6Q743ZA99Y5pHGf9ddnLuy_mlbTk=.fe36cf78-29ea-40a4-88a9-cf4d94664c3a@github.com>

On Fri, 26 Sep 2025 16:44:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Test is currently problem-listed due to the test failing on both macOS arm and x64 machines. Updated the test to use `SwingUtilities.invokeAndWait` and use the EDT to dispose of the frame. Also needed to modify the delay for stability. Initially, I removed `setAutoDelay` since this has caused issues previously, but this caused a failure in linux (when previously linux has never failed). However, keeping the auto delay and adding additional small delays seems to be stable with all of the other changes to the test. The test passes in CI with multiple runs of 100 on all OS's with the proposed changes.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move listener. Add count reset.

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 59:

> 57:     private static JLabel label;
> 58:     private static JButton button;
> 59:     private static JFrame frame;

Let's add some air into the declarations of the fields:


    private static volatile int dragWindowMouseEnteredCount = 0;
    private static volatile int buttonMouseEnteredCount = 0;
    private static volatile int labelMouseReleasedCount = 0;

    private static volatile Point pointToClick;
    private static volatile Point pointToDrag;

    private static MyDragWindow dragWindow;
    private static JLabel label;
    private static JButton button;
    private static JFrame frame;

Is it easier to skim quickly instead a wall of declarations?

test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 81:

> 79:             robot.delay(250);
> 80: 
> 81:             if (dragWindowMouseEnteredCount != 1) {

Would it still work the mouse cursor happened to be located over the label? I think it should? Anyway, nothing's changed here, so it's unimportant.

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

PR Review: https://git.openjdk.org/jdk/pull/27478#pullrequestreview-3295606421
PR Review Comment: https://git.openjdk.org/jdk/pull/27478#discussion_r2399780102
PR Review Comment: https://git.openjdk.org/jdk/pull/27478#discussion_r2399512173

From dnguyen at openjdk.org  Thu Oct  2 19:18:21 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 2 Oct 2025 19:18:21 GMT
Subject: RFR: 8298823: [macos]
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with
 "No MouseReleased event on label!" [v5]
In-Reply-To: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
References: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
Message-ID: <1rPbKVXsR-e9Scgqk2PQ5UJLn5c4CmjQl_D23jlvXCI=.5a61bb39-6617-4bb9-b902-c5a378fe2340@github.com>

> Test is currently problem-listed due to the test failing on both macOS arm and x64 machines. Updated the test to use `SwingUtilities.invokeAndWait` and use the EDT to dispose of the frame. Also needed to modify the delay for stability. Initially, I removed `setAutoDelay` since this has caused issues previously, but this caused a failure in linux (when previously linux has never failed). However, keeping the auto delay and adding additional small delays seems to be stable with all of the other changes to the test. The test passes in CI with multiple runs of 100 on all OS's with the proposed changes.

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

  Add spacing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27478/files
  - new: https://git.openjdk.org/jdk/pull/27478/files/5e393187..0c48ae22

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

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

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

From dnguyen at openjdk.org  Thu Oct  2 19:18:24 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 2 Oct 2025 19:18:24 GMT
Subject: RFR: 8298823: [macos]
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with
 "No MouseReleased event on label!" [v4]
In-Reply-To: <YdXbu6LYE_fV96V6Q743ZA99Y5pHGf9ddnLuy_mlbTk=.fe36cf78-29ea-40a4-88a9-cf4d94664c3a@github.com>
References: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
 <9vvWHaii3QGKfYXmWcua3BoW9YDffTy6UcDG23-srME=.dad86d7d-483b-4565-a680-375bc8f61f93@github.com>
 <YdXbu6LYE_fV96V6Q743ZA99Y5pHGf9ddnLuy_mlbTk=.fe36cf78-29ea-40a4-88a9-cf4d94664c3a@github.com>
Message-ID: <AnBfJQZ2X0SLy_--cZKUDKsleP3XT8Pl_4-A-GrBMYk=.c7761d1a-d535-4dc1-9e06-c913d37ce42e@github.com>

On Thu, 2 Oct 2025 18:53:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move listener. Add count reset.
>
> test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 59:
> 
>> 57:     private static JLabel label;
>> 58:     private static JButton button;
>> 59:     private static JFrame frame;
> 
> Let's add some air into the declarations of the fields:
> 
> 
>     private static volatile int dragWindowMouseEnteredCount = 0;
>     private static volatile int buttonMouseEnteredCount = 0;
>     private static volatile int labelMouseReleasedCount = 0;
> 
>     private static volatile Point pointToClick;
>     private static volatile Point pointToDrag;
> 
>     private static MyDragWindow dragWindow;
>     private static JLabel label;
>     private static JButton button;
>     private static JFrame frame;
> 
> Is it easier to skim quickly instead a wall of declarations?

Agreed. Updated!

> test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java line 81:
> 
>> 79:             robot.delay(250);
>> 80: 
>> 81:             if (dragWindowMouseEnteredCount != 1) {
> 
> Would it still work the mouse cursor happened to be located over the label? I think it should? Anyway, nothing's changed here, so it's unimportant.

I think it should too, but I see the test passing locally on my various devices as well as on CI on all OS's, so this seems consistent as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27478#discussion_r2399832852
PR Review Comment: https://git.openjdk.org/jdk/pull/27478#discussion_r2399835100

From aivanov at openjdk.org  Thu Oct  2 19:28:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Oct 2025 19:28:55 GMT
Subject: RFR: 8298823: [macos]
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with
 "No MouseReleased event on label!" [v5]
In-Reply-To: <1rPbKVXsR-e9Scgqk2PQ5UJLn5c4CmjQl_D23jlvXCI=.5a61bb39-6617-4bb9-b902-c5a378fe2340@github.com>
References: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
 <1rPbKVXsR-e9Scgqk2PQ5UJLn5c4CmjQl_D23jlvXCI=.5a61bb39-6617-4bb9-b902-c5a378fe2340@github.com>
Message-ID: <CAQX_tLi_a9AOQhiqEdZ8dJnXqtkHHSpj47E0b8khZk=.815d0fc1-f829-4a8a-990e-9ff41c6e9700@github.com>

On Thu, 2 Oct 2025 19:18:21 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Test is currently problem-listed due to the test failing on both macOS arm and x64 machines. Updated the test to use `SwingUtilities.invokeAndWait` and use the EDT to dispose of the frame. Also needed to modify the delay for stability. Initially, I removed `setAutoDelay` since this has caused issues previously, but this caused a failure in linux (when previously linux has never failed). However, keeping the auto delay and adding additional small delays seems to be stable with all of the other changes to the test. The test passes in CI with multiple runs of 100 on all OS's with the proposed changes.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add spacing

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27478#pullrequestreview-3296102701

From honkar at openjdk.org  Thu Oct  2 20:51:02 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 2 Oct 2025 20:51:02 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26 [v2]
In-Reply-To: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
Message-ID: <D958ocDG-mo7nXD4Ii7H-eGv3JI_Mx3AENufiAXBhg8=.b953a379-aaa9-4c9b-8a73-ab0786c16334@github.com>

> This test fails on macOS 26 due to slight color mismatch at background frame edges. A offset of 4 pixels is added as fix.
> 
> CI testing passes on other platforms.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  uiScale removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27585/files
  - new: https://git.openjdk.org/jdk/pull/27585/files/eef99913..a148663e

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

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

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

From honkar at openjdk.org  Thu Oct  2 20:51:04 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 2 Oct 2025 20:51:04 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26 [v2]
In-Reply-To: <NkmEywfmQko2qYTbM-7akRbaS1JH2MOFJ3P_Qj8tzz0=.e006262d-b24e-4a82-8055-411c87440a43@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
 <lgaiw2CABaQ_OwvYujWxKU1mg6EkPgzo9wIg7YaKf1w=.b4313c43-766d-40cb-aa55-6ba9925d8726@github.com>
 <NkmEywfmQko2qYTbM-7akRbaS1JH2MOFJ3P_Qj8tzz0=.e006262d-b24e-4a82-8055-411c87440a43@github.com>
Message-ID: <qhWDJ5d5ZoT8EiUup4FHz0us833YfMDXY7hOgmuOx_I=.c1a21db6-1159-4a3f-93b6-70e286111f08@github.com>

On Wed, 1 Oct 2025 00:41:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/Frame/DisposeTest.java line 42:
>> 
>>> 40:  * @summary Tests that disposing of a Frame with MenuBar removes all traces
>>> 41:  *          of the Frame from the screen.
>>> 42:  * @run main/othervm -Dsun.java2d.uiScale=1 DisposeTest
>> 
>> Why do you need to set scale factor=1, does the default break something?
>
> It doesn't break as such but based on my observation a couple of previous tests on windows fail when there is fractional scaling + color comparison at edges. Set the uiScale to 1 to make the test robust.

I had added uiScale=1 as a defensive fix but since the test doesn't fail without it, I have gone ahead and removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27585#discussion_r2400023083

From honkar at openjdk.org  Thu Oct  2 21:31:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 2 Oct 2025 21:31:51 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v2]
In-Reply-To: <OjvBzjxPo81xNylYy3biNjB1jj4HE-2OfJHBq6Kflps=.53e04905-36fa-497f-b01d-47457f878e45@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
 <PY0HrglNfb2h03tpbM-pCkv-iYu3xuzGH92yPziRvQk=.3596b887-fd86-43f9-9671-6741575bc041@github.com>
 <Uu2MBAkiCtcgb_cJowAYJQWOIMQNUswkp6j47SiG6SI=.b47ad5c5-c39e-4196-b566-6bbe854102f2@github.com>
 <OjvBzjxPo81xNylYy3biNjB1jj4HE-2OfJHBq6Kflps=.53e04905-36fa-497f-b01d-47457f878e45@github.com>
Message-ID: <KlpQjti5UmlmeWSnLLnWL-8eUnyBlJ-LBaoxW1_4CHE=.ca4f4d85-793b-4522-9e11-2ef9ad8665fb@github.com>

On Fri, 26 Sep 2025 21:13:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Marked as reviewed by psadhukhan (Reviewer).
>
> @prsadhuk Could you take another look at this?

@DamonGuy 
> When looking into this, it looks like macOS does not support mnemonics. It would therefore make sense to exclude macOS from this test

When I tested menu mnemonics on macOS ScreenMenuBar it works as expected.

May be try @mrserb  suggestion by using `System.setProperty("apple.laf.useScreenMenuBar", "false");` and verify if mnemonics work for embedded frame menu and not for JTabbedPane. If it works for embedded frame menu then should the test be de-problemlisted as it could indicate a product bug or feature not implement yet?

> Have you tried disabling the global menu on macOS and testing the mnemonics when the menu is embedded into the frame? Does it work?

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

PR Comment: https://git.openjdk.org/jdk/pull/27371#issuecomment-3363170436

From honkar at openjdk.org  Thu Oct  2 21:56:47 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 2 Oct 2025 21:56:47 GMT
Subject: RFR: 8367384: The ICC_Profile class may throw exceptions during
 serialization [v3]
In-Reply-To: <WxKFQt8HdRsyX22Up_HHgrZaMk-rqTnZ6ynDvqHK2YE=.c1d8785d-2b0a-45b5-b12c-d04e42adb717@github.com>
References: <miPV_0JUGuDHqNJjKJ_JgDQCO9U6BVewYWbj8IAS4TA=.43738169-0a30-4b59-9c5f-27f5bed9af72@github.com>
 <WxKFQt8HdRsyX22Up_HHgrZaMk-rqTnZ6ynDvqHK2YE=.c1d8785d-2b0a-45b5-b12c-d04e42adb717@github.com>
Message-ID: <OVdx2xApCfapQSCcP-7SlUf84kB4QdyiZwaockqPeO8=.c53f66fd-c10c-494c-ac70-c04029eb0dd0@github.com>

On Thu, 25 Sep 2025 03:12:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Additional checks were recently added to ICC_Profile (see [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)). As a result, objects previously stored as valid profiles may now throw an IllegalArgumentException during serialization. Discussion about serialization was started in https://github.com/openjdk/jdk/pull/23044 but it seems at the end non-serialization related check was [verified](https://github.com/openjdk/jdk/pull/23044/commits/a5201b5f353e8957a1274261372496768edbc7a2). =(
>> 
>> The patch itself is simple, but I found that we do not have good test coverage in this area. So I added two tests to cover all possible variants specified by the serialization spec.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8367384
>  - Add naming conventions used in test file names
>  - sort catch
>  - Update ValidateICCHeaderData.java
>  - 8367384: The ICC_Profile class may throw exceptions during serialization

Changes LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27326#pullrequestreview-3296561323

From dnguyen at openjdk.org  Thu Oct  2 22:11:56 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 2 Oct 2025 22:11:56 GMT
Subject: Integrated: 8298823: [macos]
 java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with
 "No MouseReleased event on label!"
In-Reply-To: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
References: <44RFezWY4Z6kUYQPcOrVHayc_LLeW2Zj_z6_ShuyCtQ=.9709d2aa-3cb4-41d6-9090-0d645aa5cb84@github.com>
Message-ID: <syOmrg39UaYo7rh9B3pGUkippxwW2asr_HmZhRNWwD0=.ef7a4fb2-1fab-42b2-a99e-70aee57c9b95@github.com>

On Wed, 24 Sep 2025 22:48:17 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Test is currently problem-listed due to the test failing on both macOS arm and x64 machines. Updated the test to use `SwingUtilities.invokeAndWait` and use the EDT to dispose of the frame. Also needed to modify the delay for stability. Initially, I removed `setAutoDelay` since this has caused issues previously, but this caused a failure in linux (when previously linux has never failed). However, keeping the auto delay and adding additional small delays seems to be stable with all of the other changes to the test. The test passes in CI with multiple runs of 100 on all OS's with the proposed changes.

This pull request has now been integrated.

Changeset: fa6e8841
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa6e884105ac247b3b83a5a2329f9c18888bd7d0
Stats:     96 lines in 2 files changed: 27 ins; 51 del; 18 mod

8298823: [macos] java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with "No MouseReleased event on label!"

Reviewed-by: aivanov, azvegint

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

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

From prr at openjdk.org  Thu Oct  2 22:51:49 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Oct 2025 22:51:49 GMT
Subject: RFR: 8367384: The ICC_Profile class may throw exceptions during
 serialization [v3]
In-Reply-To: <WxKFQt8HdRsyX22Up_HHgrZaMk-rqTnZ6ynDvqHK2YE=.c1d8785d-2b0a-45b5-b12c-d04e42adb717@github.com>
References: <miPV_0JUGuDHqNJjKJ_JgDQCO9U6BVewYWbj8IAS4TA=.43738169-0a30-4b59-9c5f-27f5bed9af72@github.com>
 <WxKFQt8HdRsyX22Up_HHgrZaMk-rqTnZ6ynDvqHK2YE=.c1d8785d-2b0a-45b5-b12c-d04e42adb717@github.com>
Message-ID: <uEvXICEEdXS5yum4_hUaD5H8BhjSBYTQGkCfnF-BoBg=.8d7ba2b2-7ffa-4c1f-b5cc-de3aad6a6148@github.com>

On Thu, 25 Sep 2025 03:12:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Additional checks were recently added to ICC_Profile (see [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)). As a result, objects previously stored as valid profiles may now throw an IllegalArgumentException during serialization. Discussion about serialization was started in https://github.com/openjdk/jdk/pull/23044 but it seems at the end non-serialization related check was [verified](https://github.com/openjdk/jdk/pull/23044/commits/a5201b5f353e8957a1274261372496768edbc7a2). =(
>> 
>> The patch itself is simple, but I found that we do not have good test coverage in this area. So I added two tests to cover all possible variants specified by the serialization spec.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8367384
>  - Add naming conventions used in test file names
>  - sort catch
>  - Update ValidateICCHeaderData.java
>  - 8367384: The ICC_Profile class may throw exceptions during serialization

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27326#pullrequestreview-3296737780

From serb at openjdk.org  Fri Oct  3 02:01:45 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 3 Oct 2025 02:01:45 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26 [v2]
In-Reply-To: <D958ocDG-mo7nXD4Ii7H-eGv3JI_Mx3AENufiAXBhg8=.b953a379-aaa9-4c9b-8a73-ab0786c16334@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
 <D958ocDG-mo7nXD4Ii7H-eGv3JI_Mx3AENufiAXBhg8=.b953a379-aaa9-4c9b-8a73-ab0786c16334@github.com>
Message-ID: <1vPiknj84Bynoz3pXg06zdBNwwp57koE43YNQ4ouFAg=.0b59afae-0032-4afb-9b5e-e6b5f83fc6b5@github.com>

On Thu, 2 Oct 2025 20:51:02 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This test fails on macOS 26 due to slight color mismatch at background frame edges. A offset of 4 pixels is added as fix.
>> 
>> CI testing passes on other platforms.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uiScale removed

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27585#pullrequestreview-3297063019

From serb at openjdk.org  Fri Oct  3 02:01:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 3 Oct 2025 02:01:47 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26 [v2]
In-Reply-To: <NkmEywfmQko2qYTbM-7akRbaS1JH2MOFJ3P_Qj8tzz0=.e006262d-b24e-4a82-8055-411c87440a43@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
 <lgaiw2CABaQ_OwvYujWxKU1mg6EkPgzo9wIg7YaKf1w=.b4313c43-766d-40cb-aa55-6ba9925d8726@github.com>
 <NkmEywfmQko2qYTbM-7akRbaS1JH2MOFJ3P_Qj8tzz0=.e006262d-b24e-4a82-8055-411c87440a43@github.com>
Message-ID: <8tkzhgEscm_fwsPNqKOf1uYtIaXvvWhRS58o5LBlhns=.e601c706-407c-41ba-8ae2-91cc799fe88e@github.com>

On Wed, 1 Oct 2025 00:41:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/Frame/DisposeTest.java line 42:
>> 
>>> 40:  * @summary Tests that disposing of a Frame with MenuBar removes all traces
>>> 41:  *          of the Frame from the screen.
>>> 42:  * @run main/othervm -Dsun.java2d.uiScale=1 DisposeTest
>> 
>> Why do you need to set scale factor=1, does the default break something?
>
> It doesn't break as such but based on my observation a couple of previous tests on windows fail when there is fractional scaling + color comparison at edges. Set the uiScale to 1 to make the test robust.

We should also have some tests that cover the default scale. For this test it might be better to increase the offset change while using the default scale.

>> test/jdk/java/awt/Frame/DisposeTest.java line 80:
>> 
>>> 78: 
>>> 79:         for (int x = PIXEL_OFFSET; x < bi.getWidth() - PIXEL_OFFSET; x++) {
>>> 80:             for (int y = PIXEL_OFFSET; y < bi.getHeight() - PIXEL_OFFSET; y++) {
>> 
>> It might be better to increase the size of the background frame so that its edge does not appear under the tested frame.
>
> Currently the backroundFrame is 200x200 and testFrame is 100x100. A difference of 100 pixels seems sufficient for this case.

ok , then this change looks fine

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27585#discussion_r2393389879
PR Review Comment: https://git.openjdk.org/jdk/pull/27585#discussion_r2393388396

From azvegint at openjdk.org  Fri Oct  3 02:42:47 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 3 Oct 2025 02:42:47 GMT
Subject: RFR: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java fails
 on macOS 26 [v2]
In-Reply-To: <D958ocDG-mo7nXD4Ii7H-eGv3JI_Mx3AENufiAXBhg8=.b953a379-aaa9-4c9b-8a73-ab0786c16334@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
 <D958ocDG-mo7nXD4Ii7H-eGv3JI_Mx3AENufiAXBhg8=.b953a379-aaa9-4c9b-8a73-ab0786c16334@github.com>
Message-ID: <x2adKu4xihM7YBTUVHno0q8rAS5q3doFAHPSqRcVvL4=.862451dc-bdc2-4669-901a-77f3da41ec53@github.com>

On Thu, 2 Oct 2025 20:51:02 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This test fails on macOS 26 due to slight color mismatch at background frame edges. A offset of 4 pixels is added as fix.
>> 
>> CI testing passes on other platforms.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uiScale removed

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27585#pullrequestreview-3297147645

From psadhukhan at openjdk.org  Fri Oct  3 06:07:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Oct 2025 06:07:47 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state
In-Reply-To: <dUZ0kiLSb1sXVLs5Nt-uEYixFCHB0Pwrwigh7UpY1Q4=.cb053284-6672-4c5e-8627-90049c9d6ff8@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <dUZ0kiLSb1sXVLs5Nt-uEYixFCHB0Pwrwigh7UpY1Q4=.cb053284-6672-4c5e-8627-90049c9d6ff8@github.com>
Message-ID: <hPEErTt1E8clrAcOg60yYZ8LxhgZlNEnh9w8AkfgMak=.7bf2adba-30f7-4482-9abd-807995cc8f01@github.com>

On Fri, 26 Sep 2025 13:54:08 GMT, Tejesh R <tr at openjdk.org> wrote:

> Test is not passing in my local machine - macos aarch64 machine. Failing with this error:
> 
> ```
> Button center point: java.awt.Point[x=298,y=219]
> Red: 181; Green: 182; Blue: 186
> Exception in thread "main" java.lang.RuntimeException: Synth ButtonUI does not handle PRESSED & MOUSE_OVER state
> 	at bug6276188.main(bug6276188.java:104)
> ```
> 
> This is observed when test is run from IDE. When it is run from jtreg the test passes. Seems strange behavior, do you know the reason?

Not sure..I ran from commandline and it works locally too..it needs to access the xml file, probably from IDE it is not able to access that file..

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

PR Comment: https://git.openjdk.org/jdk/pull/27444#issuecomment-3364384538

From psadhukhan at openjdk.org  Fri Oct  3 06:11:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Oct 2025 06:11:46 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state
In-Reply-To: <Om1JWS2hw2ok9HfuXCsKZTK_TVpg3Vwe6qmNzTtAOAU=.9ff82f29-2449-4e95-9f63-280c55ff6a8b@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <Om1JWS2hw2ok9HfuXCsKZTK_TVpg3Vwe6qmNzTtAOAU=.9ff82f29-2449-4e95-9f63-280c55ff6a8b@github.com>
Message-ID: <I76fdv1CcMdqjaJU5TMuvAnxTE0PxTGkT__VsEdVs_Y=.22413df9-d261-460b-9296-fa3909cc995a@github.com>

On Wed, 1 Oct 2025 09:41:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
>> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
>> 
>> 100 iterations of the test passed in all platforms.
>
> test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java line 92:
> 
>> 90:             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
>> 91:             robot.waitForIdle();
>> 92:             robot.delay(2000);
> 
> I wonder if syncing with `mousePressed` event handler on the button and adding a little delay after `mousePressed` is triggered would allow for smaller delay. Anyway, using an event handler will *guarantee*, the same handler is called in `ButtonUI`. We will still need a delay to allow the button UI delegate to handle the event and to repaint the button, yet that delay less than 2 seconds would be enough.

Since the color change to Red will happen on MOUSE_PRESSED and MOUSE_OVER state, I wanted to give it more time to be in red color state so that robot can pick the color..
The failure was that it was picking up Green color even though the CI failure artifact shows background is Red

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27444#discussion_r2400905436

From psadhukhan at openjdk.org  Fri Oct  3 06:36:48 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Oct 2025 06:36:48 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v5]
In-Reply-To: <xLL6a07LgtazNVpGz9AG7McoTyHAWH9iMryhF6NUbu4=.8d534a66-97ce-4697-8a2d-f832ba4d98b5@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <_xto3Lxl6h6UBw1qg3VLqgB_lK5LQPQm0o1sY-2MB_w=.7a87ac4d-5c03-413a-9c17-ca60dea14552@github.com>
 <xLL6a07LgtazNVpGz9AG7McoTyHAWH9iMryhF6NUbu4=.8d534a66-97ce-4697-8a2d-f832ba4d98b5@github.com>
Message-ID: <XdEP8Fu7ejn9MU3pXNPnzzB3naPcQy_v0ga-rYRHO4A=.e3b7306c-1185-42a4-9a31-45ff57ef7dd7@github.com>

On Wed, 24 Sep 2025 19:50:33 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PL updation
>
> test/jdk/ProblemList.txt line 259:
> 
>> 257: 
>> 258: sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh 7184899,8221451 linux-all,macosx-aarch64
>> 259: java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 8169469 windows-all,macosx-aarch64
> 
> So does this test really still fail on macos ARM ?
> The only remaining bug ID is entirely about windows.
> Seems you should remove the arm entry and re-test and it if does fail, then maybe a new bug is needed.

@prrace Any more comments on this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27365#discussion_r2400943167

From aivanov at openjdk.org  Fri Oct  3 09:38:46 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Oct 2025 09:38:46 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state
In-Reply-To: <I76fdv1CcMdqjaJU5TMuvAnxTE0PxTGkT__VsEdVs_Y=.22413df9-d261-460b-9296-fa3909cc995a@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <Om1JWS2hw2ok9HfuXCsKZTK_TVpg3Vwe6qmNzTtAOAU=.9ff82f29-2449-4e95-9f63-280c55ff6a8b@github.com>
 <I76fdv1CcMdqjaJU5TMuvAnxTE0PxTGkT__VsEdVs_Y=.22413df9-d261-460b-9296-fa3909cc995a@github.com>
Message-ID: <dNrMY7vWZ-rurJDJS0NDvlmNwXrGVVQZxPYVHpAIuxY=.4e8b42c7-a076-47b2-a36b-639d791fb2b6@github.com>

On Fri, 3 Oct 2025 06:08:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java line 92:
>> 
>>> 90:             robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
>>> 91:             robot.waitForIdle();
>>> 92:             robot.delay(2000);
>> 
>> I wonder if syncing with `mousePressed` event handler on the button and adding a little delay after `mousePressed` is triggered would allow for smaller delay. Anyway, using an event handler will *guarantee*, the same handler is called in `ButtonUI`. We will still need a delay to allow the button UI delegate to handle the event and to repaint the button, yet that delay less than 2 seconds would be enough.
>
> Since the color change to Red will happen on MOUSE_PRESSED and MOUSE_OVER state, I wanted to give it more time to be in red color state so that robot can pick the color..
> The failure was that it was picking up Green color even though the CI failure artifact shows background is Red

Yes, I got this? A delay of 2 seconds on each run means the test will *always* wait for 2 seconds even if the update occurred in 0.1 seconds.

It's fine as it is, yet I'd rather use a better synchronisation to allow the test to complete quicker, at the very least I'd investigate whether it's possible and whether the more complicated logic in the test gives a time bonus as the result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27444#discussion_r2401369318

From duke at openjdk.org  Fri Oct  3 09:56:51 2025
From: duke at openjdk.org (Ravi-Patel8)
Date: Fri, 3 Oct 2025 09:56:51 GMT
Subject: RFR: 8368606: Printer lookup returns empty on AIX platform due to
 uninitialized results list [v2]
In-Reply-To: <yb1PFIdKWoo-93897oexds1fjig1zylX5kGqxcGa5dg=.6bff193d-b484-484f-b163-67e1f7f33f4b@github.com>
References: <Gl2qsEx-CSwy_K5r9OQY4ACN451eE_iobOW7l2qnS1Y=.3fc4fb33-0485-4e0f-b5fd-2be1ac467977@github.com>
 <fGd2zoWrleSgeYmrWiySfj2Il_Utg8qRkIUpVpHRoBE=.f064a323-4279-4d36-be22-c19a867c2d26@github.com>
 <yb1PFIdKWoo-93897oexds1fjig1zylX5kGqxcGa5dg=.6bff193d-b484-484f-b163-67e1f7f33f4b@github.com>
Message-ID: <3DJpRH2D8WCnfMA1LkEXbQGeeGcqjNs0ZZzIWwWbWtQ=.41a69133-a51c-466e-a2cb-26f0359f37c9@github.com>

On Fri, 26 Sep 2025 02:02:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ravi-Patel8 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated Comments
>>    
>>    Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>
>>  - Add catch block to log exception details for troubleshooting printer
>>    command
>>    
>>    Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>
>
> Marked as reviewed by serb (Reviewer).

Thank you, @mrserb, for reviewing and approving. @prsadhuk  / @prrace , I've updated the changes based on your feedback. Could you please take a look?

Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/27482#issuecomment-3365084511

From psadhukhan at openjdk.org  Fri Oct  3 11:05:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Oct 2025 11:05:06 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v2]
In-Reply-To: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
Message-ID: <IPyLW_hbXpLH5YnU5s4Ks00LofWCZDQFH5AH2XEqn3k=.67c0355f-cb8b-4b02-8707-49da663e0790@github.com>

> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
> 
> 100 iterations of the test passed in all platforms.

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

  Use latch sync

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27444/files
  - new: https://git.openjdk.org/jdk/pull/27444/files/047054c2..b8ed9879

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

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

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

From psadhukhan at openjdk.org  Fri Oct  3 11:05:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Oct 2025 11:05:08 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v2]
In-Reply-To: <dNrMY7vWZ-rurJDJS0NDvlmNwXrGVVQZxPYVHpAIuxY=.4e8b42c7-a076-47b2-a36b-639d791fb2b6@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <Om1JWS2hw2ok9HfuXCsKZTK_TVpg3Vwe6qmNzTtAOAU=.9ff82f29-2449-4e95-9f63-280c55ff6a8b@github.com>
 <I76fdv1CcMdqjaJU5TMuvAnxTE0PxTGkT__VsEdVs_Y=.22413df9-d261-460b-9296-fa3909cc995a@github.com>
 <dNrMY7vWZ-rurJDJS0NDvlmNwXrGVVQZxPYVHpAIuxY=.4e8b42c7-a076-47b2-a36b-639d791fb2b6@github.com>
Message-ID: <UUPff4yTAzAYn6UbNlvKmkcBSvB2Amtl0B-1V8pomFU=.b6beb6f2-3232-4b69-a2c1-73daa3b2eaf9@github.com>

On Fri, 3 Oct 2025 09:36:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Since the color change to Red will happen on MOUSE_PRESSED and MOUSE_OVER state, I wanted to give it more time to be in red color state so that robot can pick the color..
>> The failure was that it was picking up Green color even though the CI failure artifact shows background is Red
>
> Yes, I got this? A delay of 2 seconds on each run means the test will *always* wait for 2 seconds even if the update occurred in 0.1 seconds.
> 
> It's fine as it is, yet I'd rather use a better synchronisation to allow the test to complete quicker, at the very least I'd investigate whether it's possible and whether the more complicated logic in the test gives a time bonus as the result.

Used CountDownLatch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27444#discussion_r2401534524

From aivanov at openjdk.org  Fri Oct  3 14:33:09 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Oct 2025 14:33:09 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v2]
In-Reply-To: <IPyLW_hbXpLH5YnU5s4Ks00LofWCZDQFH5AH2XEqn3k=.67c0355f-cb8b-4b02-8707-49da663e0790@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <IPyLW_hbXpLH5YnU5s4Ks00LofWCZDQFH5AH2XEqn3k=.67c0355f-cb8b-4b02-8707-49da663e0790@github.com>
Message-ID: <aI63ef2To5BsOj5NEUOBzkNwdpTQqfQIoN1bZDfY50k=.0e5a94a8-6b8b-4869-81cd-1ed3a6725de0@github.com>

On Fri, 3 Oct 2025 11:05:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
>> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
>> 
>> 100 iterations of the test passed in all platforms.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use latch sync

test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java line 103:

> 101:             robot.waitForIdle();
> 102:             latch.await();
> 103:             robot.delay(1000);

Can this delay be reduced to 500 or less? Anyway, 1 second delay is better than 2 seconds.

`waitForIdle` should go after `await` to ensure all the pending events after `mousePressed` are processed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27444#discussion_r2402168046

From azvegint at openjdk.org  Fri Oct  3 16:00:00 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 3 Oct 2025 16:00:00 GMT
Subject: RFR: 8358058: sun/java2d/OpenGL/DrawImageBg.java Test fails
 intermittently [v2]
In-Reply-To: <RnIlLug9im53Kc3RPTRp2MI43vRsIHfSDRSrrRZA8ws=.3b55c7bd-10f5-4016-b5f6-55fb23998380@github.com>
References: <ZcyNtV0gCE7EFOrFpmOLrwIP_LDSKoAPjWLoiG-z5GU=.551a1210-ed25-46f5-8350-3ddd2519e2be@github.com>
 <RnIlLug9im53Kc3RPTRp2MI43vRsIHfSDRSrrRZA8ws=.3b55c7bd-10f5-4016-b5f6-55fb23998380@github.com>
Message-ID: <3dSE9TIsvuAggj5Z9ViyDGlZSVlDHie11-HEVAeoFcs=.0e9435ce-1119-4354-9871-17f425bf5c76@github.com>

On Fri, 26 Sep 2025 23:35:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Moving to open a number of graphics related tests, originally written to test the OpenGL pipeline.
>> These versions are "better behaved" than the versions that were in closed - mostly meaning they now
>> do things on the right thread and paint properly on demand.
>> As a result they now pass - at least on systems with correct drivers etc.
>> There are a few bugs to add to the issue list which I'll do right after submitting this.
>> 
>> I also extended these tests so as to run with the default pipeline on every system, not just OpenGL.
>> This mostly went OK except that I found one of the tests fails on macOS with metal.
>> I've had to add a new problem listing for that.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8040230

Marked as reviewed by azvegint (Reviewer).

test/jdk/sun/java2d/OpenGL/DrawBitmaskImage.java line 28:

> 26:  * @bug 6248561 6264014
> 27:  * @key headful
> 28:  * @requires (os.family != "mac")

It looks like we only need one `@test` statement because they are now identical (besides `@requires`) after removing uiScale. Same for others.

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

PR Review: https://git.openjdk.org/jdk/pull/27399#pullrequestreview-3299557905
PR Review Comment: https://git.openjdk.org/jdk/pull/27399#discussion_r2402356532

From honkar at openjdk.org  Fri Oct  3 17:30:50 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 3 Oct 2025 17:30:50 GMT
Subject: RFR: 8367384: The ICC_Profile class may throw exceptions during
 serialization [v3]
In-Reply-To: <WxKFQt8HdRsyX22Up_HHgrZaMk-rqTnZ6ynDvqHK2YE=.c1d8785d-2b0a-45b5-b12c-d04e42adb717@github.com>
References: <miPV_0JUGuDHqNJjKJ_JgDQCO9U6BVewYWbj8IAS4TA=.43738169-0a30-4b59-9c5f-27f5bed9af72@github.com>
 <WxKFQt8HdRsyX22Up_HHgrZaMk-rqTnZ6ynDvqHK2YE=.c1d8785d-2b0a-45b5-b12c-d04e42adb717@github.com>
Message-ID: <8R9GItbUs3ul1sZLsqfG10GA1xOCZkKP8BlxRsboVGY=.aa1b3e40-77d7-4418-bdc9-f4551fc21c0c@github.com>

On Thu, 25 Sep 2025 03:12:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Additional checks were recently added to ICC_Profile (see [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)). As a result, objects previously stored as valid profiles may now throw an IllegalArgumentException during serialization. Discussion about serialization was started in https://github.com/openjdk/jdk/pull/23044 but it seems at the end non-serialization related check was [verified](https://github.com/openjdk/jdk/pull/23044/commits/a5201b5f353e8957a1274261372496768edbc7a2). =(
>> 
>> The patch itself is simple, but I found that we do not have good test coverage in this area. So I added two tests to cover all possible variants specified by the serialization spec.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8367384
>  - Add naming conventions used in test file names
>  - sort catch
>  - Update ValidateICCHeaderData.java
>  - 8367384: The ICC_Profile class may throw exceptions during serialization

CI Testing for open PR + closed test changes looks good. I'll be integrating both PR soon.

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

PR Review: https://git.openjdk.org/jdk/pull/27326#pullrequestreview-3300091995

From honkar at openjdk.org  Fri Oct  3 17:36:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 3 Oct 2025 17:36:00 GMT
Subject: Integrated: JDK-8365424 : [macos26] java/awt/Frame/DisposeTest.java
 fails on macOS 26
In-Reply-To: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
References: <DZKNVqhOGzotgzd6Ifxf6DgjiwSVyoUc2oh5meRVcNQ=.78914714-9cf9-45a6-8045-f38410d9d8ee@github.com>
Message-ID: <qlMPV0qalbdf6R0isfWY62w0VYeMHZUkrEbx0HlQXNU=.b2a8dfb8-aac9-4ff5-bc94-c4be91a26c14@github.com>

On Tue, 30 Sep 2025 23:46:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> This test fails on macOS 26 due to slight color mismatch at background frame edges. A offset of 4 pixels is added as fix.
> 
> CI testing passes on other platforms.

This pull request has now been integrated.

Changeset: aee73d35
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aee73d3568fbcb2fe7293f92154e6677c080d20c
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8365424: [macos26] java/awt/Frame/DisposeTest.java fails on macOS 26

Reviewed-by: serb, azvegint

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

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

From honkar at openjdk.org  Fri Oct  3 17:41:51 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 3 Oct 2025 17:41:51 GMT
Subject: RFR: 8368606: Printer lookup returns empty on AIX platform due to
 uninitialized results list [v2]
In-Reply-To: <5VU_J3c_CpOHpRWaKsUAoGzvE84IayQN_ae8Tb6ug34=.a8dc5dee-0133-4eeb-bb99-0ac433e120a9@github.com>
References: <Gl2qsEx-CSwy_K5r9OQY4ACN451eE_iobOW7l2qnS1Y=.3fc4fb33-0485-4e0f-b5fd-2be1ac467977@github.com>
 <fGd2zoWrleSgeYmrWiySfj2Il_Utg8qRkIUpVpHRoBE=.f064a323-4279-4d36-be22-c19a867c2d26@github.com>
 <5VU_J3c_CpOHpRWaKsUAoGzvE84IayQN_ae8Tb6ug34=.a8dc5dee-0133-4eeb-bb99-0ac433e120a9@github.com>
Message-ID: <xmiYy3eZazI4Fr7PnezRZQRtA8AI0HmQ7tpFUVXjHA8=.a1445309-77da-4cbb-8f43-f3c6fea46d97@github.com>

On Fri, 26 Sep 2025 20:46:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> Ravi-Patel8 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated Comments
>>    
>>    Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>
>>  - Add catch block to log exception details for troubleshooting printer
>>    command
>>    
>>    Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>
>
> src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java line 879:
> 
>> 877:                     bufferedReader = new BufferedReader(reader);
>> 878:                     String line;
>> 879:                     results = new ArrayList<>();
> 
> I'm surprised there's no NPE propagated.
> 
> It looks like this line was in the middle of a huge re-indented block so it wasn't easy to spot it was removed, which can only have been an editing accident.
> 
> Looks OK to me but @honkar-jdk please take a look too..

Looks like I missed looking at this PR earlier. I'll look into it today.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27482#discussion_r2402778720

From serb at openjdk.org  Fri Oct  3 17:52:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 3 Oct 2025 17:52:57 GMT
Subject: Integrated: 8367384: The ICC_Profile class may throw exceptions during
 serialization
In-Reply-To: <miPV_0JUGuDHqNJjKJ_JgDQCO9U6BVewYWbj8IAS4TA=.43738169-0a30-4b59-9c5f-27f5bed9af72@github.com>
References: <miPV_0JUGuDHqNJjKJ_JgDQCO9U6BVewYWbj8IAS4TA=.43738169-0a30-4b59-9c5f-27f5bed9af72@github.com>
Message-ID: <WU0kd7x2ZUmi08P7GC0J9AAxj3WiYF_SsrFET8og4mI=.57b0b55b-749c-4edd-ad35-7af86877e452@github.com>

On Tue, 16 Sep 2025 23:51:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Additional checks were recently added to ICC_Profile (see [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377)). As a result, objects previously stored as valid profiles may now throw an IllegalArgumentException during serialization. Discussion about serialization was started in https://github.com/openjdk/jdk/pull/23044 but it seems at the end non-serialization related check was [verified](https://github.com/openjdk/jdk/pull/23044/commits/a5201b5f353e8957a1274261372496768edbc7a2). =(
> 
> The patch itself is simple, but I found that we do not have good test coverage in this area. So I added two tests to cover all possible variants specified by the serialization spec.

This pull request has now been integrated.

Changeset: 0e98ec36
Author:    Sergey Bylokhov <serb at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e98ec36623d5d83172209058574a97bab1d6038
Stats:     205 lines in 25 files changed: 173 ins; 14 del; 18 mod

8367384: The ICC_Profile class may throw exceptions during serialization

Reviewed-by: honkar, prr

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

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

From prr at openjdk.org  Fri Oct  3 18:58:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Oct 2025 18:58:57 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification clean
 up.
Message-ID: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>

Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API.

Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update

createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might.

createBandedRaster(..) to address 
- a not explicitly specified or tested case that WxH must not overflow
- a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown.
There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent.

The existing CreateRasterExceptionTest.java is updated to verify all these assertions.
In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front.

There are only 2 sub-tests which would fail on JDK 25
The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes
- One for the  createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change.
- One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen.

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

Commit messages:
 - 8369129

Changes: https://git.openjdk.org/jdk/pull/27627/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27627&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369129
  Stats: 601 lines in 2 files changed: 556 ins; 17 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/27627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27627/head:pull/27627

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

From prr at openjdk.org  Fri Oct  3 19:05:06 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Oct 2025 19:05:06 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v2]
In-Reply-To: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
Message-ID: <iN5OOffOG-8zakPa-Rfip6oGknsatmmEW9A3p9JC4jA=.3039398a-e649-4326-95fc-1fcb58a28ecd@github.com>

> Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API.
> 
> Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update
> 
> createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might.
> 
> createBandedRaster(..) to address 
> - a not explicitly specified or tested case that WxH must not overflow
> - a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown.
> There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent.
> 
> The existing CreateRasterExceptionTest.java is updated to verify all these assertions.
> In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front.
> 
> There are only 2 sub-tests which would fail on JDK 25
> The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes
> - One for the  createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change.
> - One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen.

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

  8369129

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27627/files
  - new: https://git.openjdk.org/jdk/pull/27627/files/3408acfa..7ba88492

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

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

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

From sherman at openjdk.org  Fri Oct  3 19:10:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:10:20 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
Message-ID: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>

### Summary

Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.

Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:

**String.equalsIgnoreCase(String)**

- Unicode-aware, locale-independent.
- Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
- Limited: does not support 1:M mapping defined in Unicode case folding.

**Character.toLowerCase(int) / Character.toUpperCase(int)**

- Locale-independent, single code point only.
- No support for 1:M mappings.

**String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**

- Based on Unicode SpecialCasing.txt, supports 1:M mappings.
- Intended primarily for presentation/display, not structural case-insensitive matching.
- Requires full string conversion before comparison, which is less efficient and not intended for structural matching.

**1:M mapping example, U+00DF (?)**

- String.toUpperCase(Locale.ROOT, "?") ? "SS"
- Case folding produces "ss", matching Unicode caseless comparison rules.


jshell> "\u00df".equalsIgnoreCase("ss")
$22 ==> false

jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
$24 ==> true


### Motivation & Direction

Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

- Unicode-compliant **full** case folding.
- Simpler, stable and more efficient case-less matching without workarounds.
- Brings Java's string comparison handling in line with other programming languages/libraries.

This PR proposes to introduce the following comparison methods in `String` class

- boolean equalsFoldCase(String anotherString)
- int compareToFoldCase(String anotherString)
- Comparator<String> UNICODE_CASEFOLD_ORDER

These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.

*Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.

### The New API


   /**
     * Compares this {@code String} to another {@code String} for equality,
     * using <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")}
     * returns {@code true}, since the character {@code U+00DF} (sharp s) folds
     * to {@code "ss"}.
     * <p>
     * Case folding is locale-independent and language-neutral, unlike
     * locale-sensitive transformations such as {@link #toLowerCase()} or
     * {@link #toUpperCase()}. It is intended for caseless matching,
     * searching, and indexing.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #equalsIgnoreCase(String)}. It implements full case folding as
     * defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code equalsIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @param  anotherString
     *         The {@code String} to compare this {@code String} against
     *
     * @return  {@code true} if the given object is not {@code null} and represents
     *          the same sequence of characters as this string under Unicode case
     *          folding; {@code false} otherwise.
     *
     * @see     #compareToFoldCase(String)
     * @see     #equalsIgnoreCase(String)
     * @since   26
     */
    public boolean equalsFoldCase(String anotherString)

    /**
     * Compares two strings lexicographically using <em>Unicode case folding</em>.
     * This method returns an integer whose sign is that of calling {@code compareTo}
     * on the Unicode case folded version of the strings. Unicode Case folding
     * eliminates differences in case according to the Unicode Standard, using the
     * mappings defined in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * Case folding is a locale-independent, language-neutral form of case mapping,
     * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)},
     * which applies a simpler locale-insensitive uppercase mapping. This method
     * follows the Unicode <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> take locale into account, and may
     * produce results that differ from locale-sensitive ordering. Use
     * {@link java.text.Collator} for locale-sensitive comparison.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #compareToIgnoreCase(String)}. It implements the <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @param   str   the {@code String} to be compared.
     * @return  a negative integer, zero, or a positive integer as the specified
     *          String is greater than, equal to, or less than this String,
     *          ignoring case considerations by case folding.
     * @see     #equalsFoldCase(String)
     * @see     #compareToIgnoreCase(String)
     * @see     java.text.Collator
     * @since   26
     */
    public int compareToFoldCase(String str) 

    /**
     * A Comparator that orders {@code String} objects as by
     * {@link #compareToFoldCase(String) compareToFoldCase()}.
     *
     * @see     #compareToFoldCase(String)
     * @since   26
     */
    public static final Comparator<String> UNICODE_CASEFOLD_ORDER;



### Usage Examples

Sharp s (U+00DF) case-folds to "ss"


    "stra?e".equalsIgnoreCase("strasse");             // false
    "stra?e".compareToIgnoreCase("strasse");          // != 0
    "stra?e".equalsFoldCase("strasse");               // true



### Performance

The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing  compareToIgnoreCase().


Benchmark                                         Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.asciiGreekLower         avgt   15  20.195 ? 0.300  ns/op
StringCompareToIgnoreCase.asciiGreekLowerCF       avgt   15  11.051 ? 0.254  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLower    avgt   15   6.035 ? 0.047  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLowerCF  avgt   15  14.786 ? 0.382  ns/op
StringCompareToIgnoreCase.asciiLower              avgt   15  17.688 ? 1.396  ns/op
StringCompareToIgnoreCase.asciiLowerCF            avgt   15  44.552 ? 0.155  ns/op
StringCompareToIgnoreCase.asciiUpperLower         avgt   15  13.069 ? 0.487  ns/op
StringCompareToIgnoreCase.asciiUpperLowerCF       avgt   15  58.684 ? 0.274  ns/op
StringCompareToIgnoreCase.greekLower              avgt   15  20.642 ? 0.082  ns/op
StringCompareToIgnoreCase.greekLowerCF            avgt   15   7.255 ? 0.271  ns/op
StringCompareToIgnoreCase.greekUpperLower         avgt   15   5.737 ? 0.013  ns/op
StringCompareToIgnoreCase.greekUpperLowerCF       avgt   15  11.100 ? 1.147  ns/op
StringCompareToIgnoreCase.lower                   avgt   15  20.192 ? 0.044  ns/op
StringCompareToIgnoreCase.lowerrCF                avgt   15  11.257 ? 0.259  ns/op
StringCompareToIgnoreCase.supLower                avgt   15  54.801 ? 0.415  ns/op
StringCompareToIgnoreCase.supLowerCF              avgt   15  15.207 ? 0.418  ns/op
StringCompareToIgnoreCase.supUpperLower           avgt   15  14.431 ? 0.188  ns/op
StringCompareToIgnoreCase.supUpperLowerCF         avgt   15  19.149 ? 0.985  ns/op
StringCompareToIgnoreCase.upperLower              avgt   15   5.650 ? 0.051  ns/op
StringCompareToIgnoreCase.upperLowerCF            avgt   15  14.338 ? 0.352  ns/op
StringCompareToIgnoreCase.utf16SubLower           avgt   15  14.774 ? 0.200  ns/op
StringCompareToIgnoreCase.utf16SubLowerCF         avgt   15   2.669 ? 0.041  ns/op
StringCompareToIgnoreCase.utf16SupUpperLower      avgt   15  16.250 ? 0.099  ns/op
StringCompareToIgnoreCase.utf16SupUpperLowerCF    avgt   15  11.524 ? 0.327  ns/op



### Refs

[Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790)
[Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping)
[Unicode Technical Standard #18:  Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches)
[Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt)
[Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt)

### Other Languages

**Python string.casefold()**

The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons.

**Perl?s fc()**

Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings.
Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case.
Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. 

**ICU4J UCharacter.foldCase (Java)** 

Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF).
Method Signature (String based): public static String foldCase(String str, int options)
Method Signature (CharSequence & Appendable based): public static <A extends Appendable> A foldCase(CharSequence src, A dest, int options, Edits edits)
Key Features:
Case Folding: Converts a string to its case-folded equivalent.
Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings.
Context Insensitive: The mapping of a character is not affected by surrounding characters.
Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text.
Result Length: The resulting string can be longer or shorter than the original.
Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes.

**u_strFoldCase (C/C++)**

A lower-level C API function for case folding a string.
Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior.
Availability: Found in the ustring.h and unistr.h headers in the ICU4C library.

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

Commit messages:
 - 8365675: Add String Unicode Case-Folding Support

Changes: https://git.openjdk.org/jdk/pull/26892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365675
  Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892

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

From prr at openjdk.org  Fri Oct  3 19:32:05 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Oct 2025 19:32:05 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v3]
In-Reply-To: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
Message-ID: <5-V-9shFfS8xgAE27cvqa2StKF2IFSZBEqkWQwMsnQE=.fea25d6f-90bb-4fc8-8272-bc2b5d997ad1@github.com>

> Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API.
> 
> Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update
> 
> createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might.
> 
> createBandedRaster(..) to address 
> - a not explicitly specified or tested case that WxH must not overflow
> - a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown.
> There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent.
> 
> The existing CreateRasterExceptionTest.java is updated to verify all these assertions.
> In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front.
> 
> There are only 2 sub-tests which would fail on JDK 25
> The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes
> - One for the  createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change.
> - One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen.

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

  8369129

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27627/files
  - new: https://git.openjdk.org/jdk/pull/27627/files/7ba88492..f00d5bc6

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

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

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

From prr at openjdk.org  Fri Oct  3 19:35:21 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Oct 2025 19:35:21 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v4]
In-Reply-To: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
Message-ID: <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>

> Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API.
> 
> Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update
> 
> createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might.
> 
> createBandedRaster(..) to address 
> - a not explicitly specified or tested case that WxH must not overflow
> - a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown.
> There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent.
> 
> The existing CreateRasterExceptionTest.java is updated to verify all these assertions.
> In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front.
> 
> There are only 2 sub-tests which would fail on JDK 25
> The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes
> - One for the  createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change.
> - One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen.

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

  8369129

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27627/files
  - new: https://git.openjdk.org/jdk/pull/27627/files/f00d5bc6..b95c4ad0

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

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

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

From kizune at openjdk.org  Fri Oct  3 20:21:51 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 3 Oct 2025 20:21:51 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed [v3]
In-Reply-To: <N-6iF7Nb3cqtWXFTr6s1olEECUvABGg9sFDoBedC9SM=.a579f3d6-a458-43f9-8dd9-2ef4903d4e92@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
 <N-6iF7Nb3cqtWXFTr6s1olEECUvABGg9sFDoBedC9SM=.a579f3d6-a458-43f9-8dd9-2ef4903d4e92@github.com>
Message-ID: <VKuSagBg91fRBBu-tSsjNUvHe7ooR8iBcJY3w6AF1ts=.9a04b29e-fdf9-4c7e-b876-1187ebb3b642@github.com>

On Tue, 26 Aug 2025 07:11:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.
>> 
>> This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
>> which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
>> At start `leftComponent = Red, rightComponent = Green`
>> 
>> before `super.addImpl` is called in `JSplitPane.addImpl` the 
>> 
>> `leftComponent = Green, rightComponent = Green`
>> 
>> After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
>> leftComponent = null.
>> 
>> so we have
>> leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
>> so we have now
>> leftComponent = null, rightComponent = null
>> 
>> so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.
>> 
>> So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fire property change notification instead

After carefully reading the conversation i see the point of the fix now. I am ok with the way it is done because "Proper" fix with adding a separate property and separate propertychangeevent would require a change in specification that will make it way harder to backport. I did ran all the relevant regression tests on this fix and i see nothing broken. I would double check with the manual JCK tests for the JSplitPane but if nothing is failing i will approve it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26893#issuecomment-3367098531

From serb at openjdk.org  Sat Oct  4 02:43:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 4 Oct 2025 02:43:21 GMT
Subject: RFR: 8369032: Add test to ensure serialized ICC_Profile stores only
 necessary optional data
Message-ID: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>

Added a small test to check the size of ICC profile data after serialization.
For standard profiles, the size should stay small (under 200 bytes) because the real data is not stored.
For custom profiles, the size depends on the real data plus a small overhead.

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

Commit messages:
 - 8369032: Add test to ensure serialized ICC_Profile stores only necessary optional data

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

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

From dgredler at openjdk.org  Sat Oct  4 14:00:53 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Sat, 4 Oct 2025 14:00:53 GMT
Subject: RFR: 8167268: StandardGlyphVector.getGlyphMetrics creates metrics
 with erroneous bounds for characters with no outline (e.g.,
 the space character ' ') [v2]
In-Reply-To: <uf6Ii4gISYZ2FGS7RebsknbOQO0wQLSJ1UI_ExjNIB4=.36a12b25-e86b-4184-b0c9-cc0a3e8c02f8@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
 <slQnmRm2eXxz8rIUUFmaJoYvxfZchHvTRGbCyzBjPJE=.a881a5d5-aa19-4d6c-870a-073737482f1d@github.com>
 <F-jqJP_5yHCVLBb585i8VuAUC8cwZMo-8ziG9hwCF8Y=.9e95ec9b-98d5-44a0-a3af-76a6bed6e738@github.com>
 <uf6Ii4gISYZ2FGS7RebsknbOQO0wQLSJ1UI_ExjNIB4=.36a12b25-e86b-4184-b0c9-cc0a3e8c02f8@github.com>
Message-ID: <yYEMERwY4Joxbq-a0CXiRaMBJxCNCWY0m0wDBx6z7d8=.93575b5f-db50-459c-bffe-db0e3c4bce52@github.com>

On Wed, 1 Oct 2025 18:41:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Do you know when that might happen? This code gets its values (after a few layers of abstraction) from `StandardGlyphVector$GlyphStrike.getGlyphOutlineBounds(int, float, float)`, which has a similar `isEmpty` check.
>
> I am not sure if it is possible, but I would like to make sure we did not introduce any issues, since isEmpty() will skip ?flipped? bounds.

I think the main thing is that the condition which adds the "aggregate" position to the glyph bounds is the same condition which later undoes this and converts the position back to the "single glyph" position. The code which adds the total advance the glyph position uses `isEmpty`, so I think the code which undoes it (the code being added in this PR) needs to use it as well:

https://github.com/openjdk/jdk/blob/76dba201fa1a525780677e4d3dee8e9ffafd1cd7/src/java.desktop/share/classes/sun/font/StandardGlyphVector.java#L1798

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27580#discussion_r2403986158

From psadhukhan at openjdk.org  Sun Oct  5 05:32:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 5 Oct 2025 05:32:19 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v3]
In-Reply-To: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
Message-ID: <OP3Oa4ZsUHdy8rfbLftaYfVzuA4_iVi4nMHGtpVP0T0=.744ce3c3-594c-46ae-9244-d01fb39c5f61@github.com>

> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
> 
> 100 iterations of the test passed in all platforms.

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

  Remove waitForIdle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27444/files
  - new: https://git.openjdk.org/jdk/pull/27444/files/b8ed9879..5955ad0a

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

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

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

From psadhukhan at openjdk.org  Sun Oct  5 05:44:37 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 5 Oct 2025 05:44:37 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined foreground
 color on Ubuntu 24.04
Message-ID: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>

Test fails to pick red color from JLabel in ubuntu24.04 even though it passes is ubuntu 22.04.
Seems like the red pixel from the font is not being picked up despite the fact that label foreground color actually is rendered in red.

It is seen in ubuntu 22.04 the font used for JLabel is "family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12"
while in ubuntu 24.04 the font used for JLabel is "family=Noto Sans,name=Noto Sans,style=plain,size=12"

I have made it consistent across version using same font and made it larger and bold and using such text for easier pickup of redpixel.
It passes in all platforms including ubuntu24.04

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

Commit messages:
 - 8335646: Nimbus : JLabel not painted with LAF defined foreground color on Ubuntu 24.04

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

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

From psadhukhan at openjdk.org  Sun Oct  5 05:52:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 5 Oct 2025 05:52:45 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v2]
In-Reply-To: <aI63ef2To5BsOj5NEUOBzkNwdpTQqfQIoN1bZDfY50k=.0e5a94a8-6b8b-4869-81cd-1ed3a6725de0@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <IPyLW_hbXpLH5YnU5s4Ks00LofWCZDQFH5AH2XEqn3k=.67c0355f-cb8b-4b02-8707-49da663e0790@github.com>
 <aI63ef2To5BsOj5NEUOBzkNwdpTQqfQIoN1bZDfY50k=.0e5a94a8-6b8b-4869-81cd-1ed3a6725de0@github.com>
Message-ID: <f_MAptGe1jdeTgHlSJBjIBB-6qM2HnLf_NmB7EgENzA=.562efd0f-31e4-4710-8b38-48b76e4e11fa@github.com>

On Fri, 3 Oct 2025 14:30:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use latch sync
>
> test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java line 103:
> 
>> 101:             robot.waitForIdle();
>> 102:             latch.await();
>> 103:             robot.delay(1000);
> 
> Can this delay be reduced to 500 or less? Anyway, 1 second delay is better than 2 seconds.
> 
> `waitForIdle` should go after `await` to ensure all the pending events after `mousePressed` are processed.

Reducing delay further causes failure in CI so I will keep it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27444#discussion_r2404299085

From serb at openjdk.org  Sun Oct  5 06:09:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 5 Oct 2025 06:09:46 GMT
Subject: RFR: 8358058: sun/java2d/OpenGL/DrawImageBg.java Test fails
 intermittently [v2]
In-Reply-To: <RnIlLug9im53Kc3RPTRp2MI43vRsIHfSDRSrrRZA8ws=.3b55c7bd-10f5-4016-b5f6-55fb23998380@github.com>
References: <ZcyNtV0gCE7EFOrFpmOLrwIP_LDSKoAPjWLoiG-z5GU=.551a1210-ed25-46f5-8350-3ddd2519e2be@github.com>
 <RnIlLug9im53Kc3RPTRp2MI43vRsIHfSDRSrrRZA8ws=.3b55c7bd-10f5-4016-b5f6-55fb23998380@github.com>
Message-ID: <3R-nscGni2s4jgOE7Rrpzy1w2tJWmcjC3AeaOcKxPMU=.4a377bca-d997-4e56-bd42-e04079d8faf0@github.com>

On Fri, 26 Sep 2025 23:35:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Moving to open a number of graphics related tests, originally written to test the OpenGL pipeline.
>> These versions are "better behaved" than the versions that were in closed - mostly meaning they now
>> do things on the right thread and paint properly on demand.
>> As a result they now pass - at least on systems with correct drivers etc.
>> There are a few bugs to add to the issue list which I'll do right after submitting this.
>> 
>> I also extended these tests so as to run with the default pipeline on every system, not just OpenGL.
>> This mostly went OK except that I found one of the tests fails on macOS with metal.
>> I've had to add a new problem listing for that.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8040230

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27399#pullrequestreview-3302222212

From prr at openjdk.org  Sun Oct  5 20:39:21 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 5 Oct 2025 20:39:21 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
Message-ID: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>

Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue.

The behaviour for image types and sizes <= 0 is unchanged by this PR.
Also in many cases the behaviour for sizes that are too large is also unchanged.
In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException.

In no case is anything changed that would affect the possibility to construct a BufferedImage.

A test is provided to ensure the behaviour.

A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155

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

Commit messages:
 - 4617681

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

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

From lbourges at openjdk.org  Sun Oct  5 22:22:21 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 5 Oct 2025 22:22:21 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
Message-ID: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>

- Fix cubic offsetting artefacts (sort cubic roots + fixed numerical accuracy problem in ROC^2-w^2 = 0 solver + fixed EliminateInf)
- Restored lower precision using ulp(float) in point, line or flat bezier curve checks

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

Commit messages:
 - JDK-8341381 Random lines appear in graphic causing by the fix of JDK-8297230

Changes: https://git.openjdk.org/jdk/pull/27641/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341381
  Stats: 657 lines in 5 files changed: 620 ins; 1 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/27641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27641/head:pull/27641

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

From tr at openjdk.org  Mon Oct  6 05:30:52 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 6 Oct 2025 05:30:52 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v3]
In-Reply-To: <hPEErTt1E8clrAcOg60yYZ8LxhgZlNEnh9w8AkfgMak=.7bf2adba-30f7-4482-9abd-807995cc8f01@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <dUZ0kiLSb1sXVLs5Nt-uEYixFCHB0Pwrwigh7UpY1Q4=.cb053284-6672-4c5e-8627-90049c9d6ff8@github.com>
 <hPEErTt1E8clrAcOg60yYZ8LxhgZlNEnh9w8AkfgMak=.7bf2adba-30f7-4482-9abd-807995cc8f01@github.com>
Message-ID: <hPAHMbG3huUpvwuv4kc02RhxyCWWgCsRzzhzg5E3yA0=.3af35c31-3d1f-47be-b7aa-60f347cb0eec@github.com>

On Fri, 3 Oct 2025 06:05:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test is not passing in my local machine - macos aarch64 machine. Failing with this error:
> 
> ```
> Button center point: java.awt.Point[x=298,y=219]
> Red: 181; Green: 182; Blue: 186
> Exception in thread "main" java.lang.RuntimeException: Synth ButtonUI does not handle PRESSED & MOUSE_OVER state
> 	at bug6276188.main(bug6276188.java:104)
> ```
> 
> This is observed when test is run from IDE. When it is run from jtreg the test passes. Seems strange behavior, do you know the reason?

Looks like something to do with IDE settings or system though because it works fine with jtreg and other macos too.

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

PR Comment: https://git.openjdk.org/jdk/pull/27444#issuecomment-3369977073

From tr at openjdk.org  Mon Oct  6 05:30:51 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 6 Oct 2025 05:30:51 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v3]
In-Reply-To: <OP3Oa4ZsUHdy8rfbLftaYfVzuA4_iVi4nMHGtpVP0T0=.744ce3c3-594c-46ae-9244-d01fb39c5f61@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <OP3Oa4ZsUHdy8rfbLftaYfVzuA4_iVi4nMHGtpVP0T0=.744ce3c3-594c-46ae-9244-d01fb39c5f61@github.com>
Message-ID: <nJizaZRbg9OJEOYppmZAIB9CkwkhL-XFAXgoBe861N8=.c04bcef4-de84-4154-b2f3-6bbbf2a75de4@github.com>

On Sun, 5 Oct 2025 05:32:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
>> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
>> 
>> 100 iterations of the test passed in all platforms.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove waitForIdle

LGTM.

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27444#pullrequestreview-3302877615

From psadhukhan at openjdk.org  Mon Oct  6 06:39:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Oct 2025 06:39:10 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v5]
In-Reply-To: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
Message-ID: <cfecvvipGeuH3nSiDoytFZCFzEFLGG3KsEqIi2JWIU8=.3ec95f7f-a606-4c7c-9b71-e5d1f7decd68@github.com>

> It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0.

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

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26500/files
  - new: https://git.openjdk.org/jdk/pull/26500/files/ba88e12e..5e2e413e

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

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

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

From psadhukhan at openjdk.org  Mon Oct  6 06:39:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Oct 2025 06:39:10 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v3]
In-Reply-To: <yNhKRWQKTU3weOtQaHH90CThC5zgLrMAKj63xgsPUas=.315e099d-4d09-49bb-bed0-fc144553f748@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <0MDTPquVuMulH9tEnu_VEaKM7e6SPCpHh_19RhGWXMw=.56db997b-8a7e-48ea-bd07-e9721c5eea28@github.com>
 <f3RdJbjdKALPP0cjZakg3wajvw8-yCiUF0J2qopPc6U=.2594f37b-f625-43ca-98d0-a0009a038135@github.com>
 <yNhKRWQKTU3weOtQaHH90CThC5zgLrMAKj63xgsPUas=.315e099d-4d09-49bb-bed0-fc144553f748@github.com>
Message-ID: <IP47xhx5FnnbhMcv5RLU_b7mEUhzvLOv4iqqrwx8cTU=.965fd87f-e9eb-4e1b-8c5b-2c207325da15@github.com>

On Fri, 5 Sep 2025 08:16:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> And if the rectangle you pass in has a y that is = the height of the list, then scrolling in a positive direction also returns 0.
> If it is GREATER than the height, then I get back a negative increment !

I tried


Rectangle cell = list.getCellBounds(1, data.length);
            cell.y = list.getHeight() + 10;
            int unit = list.getScrollableUnitIncrement(
                    cell,
                    SwingConstants.VERTICAL,
                    -1);
            System.out.println("Scrollable unit increment: " + unit);

and I get 117 in upward (-1) direction and -99 in downward (1) direction..
so it seems `getScrollableUnitIncrement` finds from `locationToIndex` that it's last row so `r.y` points to TOP of last cell (90) but `visibleRect.y` points to height past the last cell(207) so it has to backtrack -99 pixels [last cell height=18 - (207-90) = 18-117] logically but I guess we need to restrict it to 0 since there is no incremental scrolling that can be done


> > And if the rectangle you pass in has a y that is = the height of the list, then scrolling in a positive direction also returns 0.
> > If it is GREATER than the height, then I get back a negative increment !
> 
> I tried
> 
> ```
> Rectangle cell = list.getCellBounds(1, data.length);
>             cell.y = list.getHeight() + 10;
>             int unit = list.getScrollableUnitIncrement(
>                     cell,
>                     SwingConstants.VERTICAL,
>                     -1);
>             System.out.println("Scrollable unit increment: " + unit);
> ```
> 
> and I get 117 in upward (-1) direction and -99 in downward (1) direction.. so it seems `getScrollableUnitIncrement` finds from `locationToIndex` that it's last row so `r.y` points to TOP of last cell (90) but `visibleRect.y` points to height past the last cell(207) so it has to backtrack -99 pixels [last cell height=18 - (207-90) = 18-117] logically but I guess we need to restrict it to 0 since there is no incremental scrolling that can be done

Test added

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

PR Comment: https://git.openjdk.org/jdk/pull/26500#issuecomment-3370104712

From tejesh.r at oracle.com  Mon Oct  6 06:54:09 2025
From: tejesh.r at oracle.com (Tejesh R)
Date: Mon, 6 Oct 2025 06:54:09 +0000
Subject: Comments on the JDatePicker UI Component draft JEP
In-Reply-To: <CAJO5KZj5upB-9xcmGAdyNQ0hp-Xe3R=3cTaQfDDv6eeXS0svPw@mail.gmail.com>
References: <CAJO5KZj5upB-9xcmGAdyNQ0hp-Xe3R=3cTaQfDDv6eeXS0svPw@mail.gmail.com>
Message-ID: <75F1B4F0-41F1-49E9-8E16-F0DB4292EB7F@oracle.com>

Hello Hampus,

                Firstly, thank you so much for going through the draft JEP and providing with the feedback.

  1.  Support for FirstDayOfWeek : This has been taken care in the current JEP. Default FirstDayOfWeek will be fetched from set Locale, and it can be overridden using setter method.
  2.  Support for showing week numbers : Currently we haven?t included this feature, might have to re-think on this. Thanks for the heads-up on this feature.

Regards,
Tejesh R



Confidential ? Oracle Internal
From: client-libs-dev <client-libs-dev-retn at openjdk.org> on behalf of Hampus Ram <hampus.ram at gmail.com>
Date: Wednesday, 1 October 2025 at 5:53?PM
To: "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
Subject: Comments on the JDatePicker UI Component draft JEP

Hello,

Saw the draft JEP for the JDatePicker UI Component  (and the accompanying issue JDK-8368874) and thought I'd chime in with some observations (that may have very well already been considered) but that I think would be necessary for me to use such a control in an application.

A feature that I have found lacking in other date picker components in the past, and that isn't fully clear if it is intended to be supported in this JEP is using WeekFields.getFirstDayOfWeek() or similar. The examples all start on a sunday, but in many places around the world the week starts on a monday. The calendar should be able to reflect that and maybe that should be clarified somewhere?

Another feature often missing or neglected that I'm fairly certain isn't at all in the JEP is the ability to show week numbers. At least here in Sweden many organizations (and most schools) use week numbers for recurring things such as vacation and school holidays. Of course this is also something that works differently in different locales and would need to be handled correctly. However I don't think it needs to be anything other than a visual component, you do not need to be able to select a week by clicking it or supporting any other interaction.

Just my two cents :)
Regards,
Hampus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251006/1f961c16/attachment.htm>

From tr at openjdk.org  Mon Oct  6 06:59:50 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 6 Oct 2025 06:59:50 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed [v3]
In-Reply-To: <N-6iF7Nb3cqtWXFTr6s1olEECUvABGg9sFDoBedC9SM=.a579f3d6-a458-43f9-8dd9-2ef4903d4e92@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
 <N-6iF7Nb3cqtWXFTr6s1olEECUvABGg9sFDoBedC9SM=.a579f3d6-a458-43f9-8dd9-2ef4903d4e92@github.com>
Message-ID: <eSzr8XC-6H_fTLnXJKqBRYn6XMXXvj7gbUyQO3e9SC8=.28e19c02-733d-45f7-8851-403db3fb0957@github.com>

On Tue, 26 Aug 2025 07:11:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.
>> 
>> This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
>> which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
>> At start `leftComponent = Red, rightComponent = Green`
>> 
>> before `super.addImpl` is called in `JSplitPane.addImpl` the 
>> 
>> `leftComponent = Green, rightComponent = Green`
>> 
>> After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
>> leftComponent = null.
>> 
>> so we have
>> leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
>> so we have now
>> leftComponent = null, rightComponent = null
>> 
>> so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.
>> 
>> So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fire property change notification instead

test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java line 23:

> 21:  * questions.
> 22:  */
> 23: 

Please update copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26893#discussion_r2404967503

From psadhukhan at openjdk.org  Mon Oct  6 09:26:50 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Oct 2025 09:26:50 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed [v4]
In-Reply-To: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
Message-ID: <_C7RQ6idsZ_i2MNm2VkVaY-_f_kytvmckizl7q7T1yU=.a461756d-ab6d-493c-be82-0516863ba5ae@github.com>

> When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.
> 
> This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
> which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
> At start `leftComponent = Red, rightComponent = Green`
> 
> before `super.addImpl` is called in `JSplitPane.addImpl` the 
> 
> `leftComponent = Green, rightComponent = Green`
> 
> After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
> leftComponent = null.
> 
> so we have
> leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
> so we have now
> leftComponent = null, rightComponent = null
> 
> so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.
> 
> So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components

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

  copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26893/files
  - new: https://git.openjdk.org/jdk/pull/26893/files/4b25b546..8ee77d97

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

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

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

From psadhukhan at openjdk.org  Mon Oct  6 09:26:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Oct 2025 09:26:51 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed [v3]
In-Reply-To: <VKuSagBg91fRBBu-tSsjNUvHe7ooR8iBcJY3w6AF1ts=.9a04b29e-fdf9-4c7e-b876-1187ebb3b642@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
 <N-6iF7Nb3cqtWXFTr6s1olEECUvABGg9sFDoBedC9SM=.a579f3d6-a458-43f9-8dd9-2ef4903d4e92@github.com>
 <VKuSagBg91fRBBu-tSsjNUvHe7ooR8iBcJY3w6AF1ts=.9a04b29e-fdf9-4c7e-b876-1187ebb3b642@github.com>
Message-ID: <qzJXvN2Fg40mmTM6zQ93oyXXEecTzsP5EEo5N0kIvCA=.1a740220-832c-49ed-9a02-2b8cb4fe084c@github.com>

On Fri, 3 Oct 2025 20:19:29 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> After carefully reading the conversation i see the point of the fix now. I am ok with the way it is done because "Proper" fix with adding a separate property and separate propertychangeevent would require a change in specification that will make it way harder to backport. I did ran all the relevant regression tests on this fix and i see nothing broken. I would double check with the manual JCK tests for the JSplitPane but if nothing is failing i will approve it.

BTW, I have run the relevant manual JCK tests which passed but you can verify it if you want to ....

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

PR Comment: https://git.openjdk.org/jdk/pull/26893#issuecomment-3370677678

From psadhukhan at openjdk.org  Mon Oct  6 09:26:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Oct 2025 09:26:55 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed [v3]
In-Reply-To: <eSzr8XC-6H_fTLnXJKqBRYn6XMXXvj7gbUyQO3e9SC8=.28e19c02-733d-45f7-8851-403db3fb0957@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
 <N-6iF7Nb3cqtWXFTr6s1olEECUvABGg9sFDoBedC9SM=.a579f3d6-a458-43f9-8dd9-2ef4903d4e92@github.com>
 <eSzr8XC-6H_fTLnXJKqBRYn6XMXXvj7gbUyQO3e9SC8=.28e19c02-733d-45f7-8851-403db3fb0957@github.com>
Message-ID: <vgonsEN1OLRpWmosHM9GQ0CXLa_XEqUGl3jBhhEzWm4=.f4d3b3f3-2cb7-444e-93dc-f13275f2c3a6@github.com>

On Mon, 6 Oct 2025 05:31:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fire property change notification instead
>
> test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java line 23:
> 
>> 21:  * questions.
>> 22:  */
>> 23: 
> 
> Please update copyright year.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26893#discussion_r2405466995

From tr at openjdk.org  Mon Oct  6 09:32:49 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 6 Oct 2025 09:32:49 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed [v4]
In-Reply-To: <_C7RQ6idsZ_i2MNm2VkVaY-_f_kytvmckizl7q7T1yU=.a461756d-ab6d-493c-be82-0516863ba5ae@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
 <_C7RQ6idsZ_i2MNm2VkVaY-_f_kytvmckizl7q7T1yU=.a461756d-ab6d-493c-be82-0516863ba5ae@github.com>
Message-ID: <FjIshrKG-lhrUbkTIxsXiWBKgdBrCnU40-PsYCcF-28=.6cbc64bd-7e70-43e9-bc8a-4cdb6b9bb996@github.com>

On Mon, 6 Oct 2025 09:26:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.
>> 
>> This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
>> which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
>> At start `leftComponent = Red, rightComponent = Green`
>> 
>> before `super.addImpl` is called in `JSplitPane.addImpl` the 
>> 
>> `leftComponent = Green, rightComponent = Green`
>> 
>> After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
>> leftComponent = null.
>> 
>> so we have
>> leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
>> so we have now
>> leftComponent = null, rightComponent = null
>> 
>> so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.
>> 
>> So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26893#pullrequestreview-3303573942

From cushon at google.com  Mon Oct  6 11:57:14 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 6 Oct 2025 13:57:14 +0200
Subject: HDR image support
Message-ID: <CAL4QsgsN8QqpwFVkaN+XOkNCsP05z_oFDXXR8Ha6Nyzs4Yt2BA@mail.gmail.com>

Hi,

Are there any plans around HDR image support in the JDK?

My colleague Alec Mouri provides the following background:

Advancements in display and imaging technology have enabled HDR (High
Dynamic Range) content, which allows for displaying content at a greater
luminance than SDR (Standard Dynamic Range) content. Google
<https://android-developers.googleblog.com/2025/08/what-is-hdr.html> and
Adobe <https://blog.adobe.com/en/publish/2023/10/10/hdr-explained> have
informative blog posts explaining this new technology.

HDR images are part of intentional standards ISO 22028-5
<https://www.iso.org/standard/81863.html> and ISO 21496-1
<https://www.iso.org/standard/86775.html>. ISO 21496-1 in particular is
heavily used by the mobile ecosystem to generate high-quality images. See
the UltraHDR <https://developer.android.com/media/platform/hdr-image-format>
image format as an example.

Every major operating system now has support for rendering HDR GUIs. See:
Android?s ExtendedRangeBrightness
<https://developer.android.com/reference/android/view/SurfaceControl.Transaction#setExtendedRangeBrightness(android.view.SurfaceControl,%20float,%20float)>
and COLOR_MODE_HDR
<https://developer.android.com/reference/android/content/pm/ActivityInfo#COLOR_MODE_HDR>,
Apple?s EDR
<https://developer.apple.com/documentation/metal/displaying-hdr-content-in-a-metal-layer>,
and Wayland?s HDR Protocol
<https://www.phoronix.com/news/Wayland-CM-HDR-Merged>, and Window?s Advanced
Color
<https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range>
.

Platforms built on top of these OSs are accordingly adding support for HDR.
See: QT <https://doc.qt.io/qt-6/qrhiswapchainhdrinfo.html> and CSS
<https://www.w3.org/TR/css-color-hdr-1/>.

Support in the JDK would involve decoding and display support.

Decoding support could be added to Image I/O. For ISO 22028-5, this means
that ICC_ColorSpace
<https://docs.oracle.com/javase/8/docs/api/java/awt/color/ICC_ColorSpace.html>
could support CICPs as described in ITU-T H.273
<https://www.itu.int/rec/T-REC-H.273> to represent HLG and PQ encodings.
For ISO 21496-1, this means that BufferedImage
<https://docs.oracle.com/javase/8/docs/api/java/awt/image/BufferedImage.html>
could be decorated with a gainmap representation.

Display support could be added to Swing and JavaFX. This would involve
interacting with each major OS?s capabilities to color manage and draw HDR
images through ImageIcon or JComponent. Note that SDR content should not be
colorimetrically affected when there is no HDR on screen. I.e., the rest of
the UI should not ?flicker?.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251006/1b7765e8/attachment.htm>

From mullan at openjdk.org  Mon Oct  6 14:53:50 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 6 Oct 2025 14:53:50 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v10]
In-Reply-To: <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
Message-ID: <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>

On Fri, 26 Sep 2025 22:59:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Allow password hiding even if there is no `System.console`. A manual test is included.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update bug list in test

src/java.base/share/classes/sun/security/util/Password.java line 62:

> 60:                     consoleEntered = ConsoleHolder.readPassword();
> 61:                     // readPassword returns "" if you just press ENTER with the built-in Console,
> 62:                     // to be compatible with old Password class, change to null

This is an odd comment - what is the "old Password class"? Maybe you just want to remove the "to be compatible with old Password class" part from this comment.

test/jdk/sun/security/tools/keytool/EchoPassword.java line 1:

> 1: /*

In this test, where are you verifying that a warning is shown when the input is echoed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406585327
PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406794334

From weijun at openjdk.org  Mon Oct  6 15:07:19 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:07:19 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v11]
In-Reply-To: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
Message-ID: <P6QvxP6d92txbI9uquJqqjxflJylQKH3Ri2ry-vDxA0=.fb52a205-c489-4660-a55e-a3c2b7a67514@github.com>

> Allow password hiding even if there is no `System.console`. A manual test is included.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup; simpler reallocation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27196/files
  - new: https://git.openjdk.org/jdk/pull/27196/files/15e76512..befc698a

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

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

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

From weijun at openjdk.org  Mon Oct  6 15:16:54 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:16:54 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v10]
In-Reply-To: <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
 <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
Message-ID: <6VesvUNEDQ5ml401NDz3AIPxSDjjmF2YAoysdiB69Y4=.a3e17f7e-6920-487d-9f47-1f0218e835ee@github.com>

On Mon, 6 Oct 2025 14:14:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update bug list in test
>
> src/java.base/share/classes/sun/security/util/Password.java line 62:
> 
>> 60:                     consoleEntered = ConsoleHolder.readPassword();
>> 61:                     // readPassword returns "" if you just press ENTER with the built-in Console,
>> 62:                     // to be compatible with old Password class, change to null
> 
> This is an odd comment - what is the "old Password class"? Maybe you just want to remove the "to be compatible with old Password class" part from this comment.

I meant to be consistent with the parse-from-inputstream behavior, but I just realized the more important check here is for null since that is a possible return value. For an empty input, even if we don't stop here, `consoleBytes` and `in` will be empty and the first `in.read()` would return -1 and `offset` stays 0 and a null will be returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406926705

From weijun at openjdk.org  Mon Oct  6 15:27:32 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:27:32 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v10]
In-Reply-To: <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <m9EfrVX42Nmjr7wx03iRw7ETXbfx1GcQQk6QKyfg6FU=.e038bba8-b432-42fe-b51e-9dcb574ed86d@github.com>
 <ky7jGPWlG4479Z6Jq3TzUVt_AWhs2pYwYi6NWbPpEmQ=.09e340d5-8afd-46c3-8ab1-f70ab5340f8d@github.com>
Message-ID: <OCP59TT9G3uPXzKco7vWoxGFJqE0r7MhesBHGvUwOAI=.275f753a-c566-4c6e-9691-4160b21813c3@github.com>

On Mon, 6 Oct 2025 14:51:13 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update bug list in test
>
> test/jdk/sun/security/tools/keytool/EchoPassword.java line 1:
> 
>> 1: /*
> 
> In this test, where are you verifying that a warning is shown when the input is echoed?

As I mentioned in the comment, an IDE Run Window or in JShell is the only case I know now that the input is echoed on screen. This test will not cover those cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2406995465

From weijun at openjdk.org  Mon Oct  6 15:31:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 6 Oct 2025 15:31:27 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v12]
In-Reply-To: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
Message-ID: <b1PT909B5J0Hl4Gplp8y42CiNVEjt2Oc8MK8F_DRTWY=.7b6d883d-2318-4a28-85c7-7483ede93e8b@github.com>

> Allow password hiding even if there is no `System.console`. A manual test is included.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more null check; one less empty check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27196/files
  - new: https://git.openjdk.org/jdk/pull/27196/files/befc698a..93220920

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

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

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

From serb at openjdk.org  Mon Oct  6 19:10:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 6 Oct 2025 19:10:49 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
Message-ID: <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>

On Sun, 5 Oct 2025 20:33:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue.
> 
> The behaviour for image types and sizes <= 0 is unchanged by this PR.
> Also in many cases the behaviour for sizes that are too large is also unchanged.
> In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException.
> 
> In no case is anything changed that would affect the possibility to construct a BufferedImage.
> 
> A test is provided to ensure the behaviour.
> 
> A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155

src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 314:

> 312:      * @throws IllegalArgumentException if the multiplication product of
> 313:      *          {@code width}, {@code height}, and the number of samples per pixel
> 314:      *          for the specified format exceeds the maximum length of a Java array.

This check seems too strict. It is possible to implement a BufferedImage that splits its internal data into multiple surfaces/arrays. It might be better to phrase this as optional:
?for the specified format exceeds the maximum supported length?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2408048654

From aivanov at openjdk.org  Mon Oct  6 21:01:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Oct 2025 21:01:47 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v3]
In-Reply-To: <OP3Oa4ZsUHdy8rfbLftaYfVzuA4_iVi4nMHGtpVP0T0=.744ce3c3-594c-46ae-9244-d01fb39c5f61@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <OP3Oa4ZsUHdy8rfbLftaYfVzuA4_iVi4nMHGtpVP0T0=.744ce3c3-594c-46ae-9244-d01fb39c5f61@github.com>
Message-ID: <2gkm-taxrIwGSHIPqAEmklRoDEcvlmLzrN5xcoj0xaQ=.c1499642-f760-4579-8fa0-81ddd4b3fe50@github.com>

On Sun, 5 Oct 2025 05:32:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
>> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
>> 
>> 100 iterations of the test passed in all platforms.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove waitForIdle

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27444#pullrequestreview-3307342138

From aivanov at openjdk.org  Mon Oct  6 21:01:49 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Oct 2025 21:01:49 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v2]
In-Reply-To: <f_MAptGe1jdeTgHlSJBjIBB-6qM2HnLf_NmB7EgENzA=.562efd0f-31e4-4710-8b38-48b76e4e11fa@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <IPyLW_hbXpLH5YnU5s4Ks00LofWCZDQFH5AH2XEqn3k=.67c0355f-cb8b-4b02-8707-49da663e0790@github.com>
 <aI63ef2To5BsOj5NEUOBzkNwdpTQqfQIoN1bZDfY50k=.0e5a94a8-6b8b-4869-81cd-1ed3a6725de0@github.com>
 <f_MAptGe1jdeTgHlSJBjIBB-6qM2HnLf_NmB7EgENzA=.562efd0f-31e4-4710-8b38-48b76e4e11fa@github.com>
Message-ID: <bhmfFtRzgl__gWgDHeY-5y6j9hkZpmzs1lXrU51JRRQ=.be7ec03a-f8d6-4c92-8b0f-8cb04029fdab@github.com>

On Sun, 5 Oct 2025 05:50:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java line 103:
>> 
>>> 101:             robot.waitForIdle();
>>> 102:             latch.await();
>>> 103:             robot.delay(1000);
>> 
>> Can this delay be reduced to 500 or less? Anyway, 1 second delay is better than 2 seconds.
>> 
>> `waitForIdle` should go after `await` to ensure all the pending events after `mousePressed` are processed.
>
> Reducing delay further causes failure in CI so I will keep it

I see.

I expected to have `waitForIdle` after `await` to ensure all other pending events including `paint` is handled.


            robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
            latch.await();
            robot.waitForIdle();
            robot.delay(1000);


In this case, it could be possible to reduce the delay? or maybe not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27444#discussion_r2408545621

From aivanov at openjdk.org  Mon Oct  6 21:07:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Oct 2025 21:07:45 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v3]
In-Reply-To: <hPAHMbG3huUpvwuv4kc02RhxyCWWgCsRzzhzg5E3yA0=.3af35c31-3d1f-47be-b7aa-60f347cb0eec@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <dUZ0kiLSb1sXVLs5Nt-uEYixFCHB0Pwrwigh7UpY1Q4=.cb053284-6672-4c5e-8627-90049c9d6ff8@github.com>
 <hPEErTt1E8clrAcOg60yYZ8LxhgZlNEnh9w8AkfgMak=.7bf2adba-30f7-4482-9abd-807995cc8f01@github.com>
 <hPAHMbG3huUpvwuv4kc02RhxyCWWgCsRzzhzg5E3yA0=.3af35c31-3d1f-47be-b7aa-60f347cb0eec@github.com>
Message-ID: <R8TV85HIAngozrztCW10KOwp_R7nZltnf4p1IE1JBmc=.164f56f1-e421-49e6-8189-6cffbceb827f@github.com>

On Mon, 6 Oct 2025 05:28:26 GMT, Tejesh R <tr at openjdk.org> wrote:

> > This is observed when test is run from IDE. When it is run from jtreg the test passes. Seems strange behavior, do you know the reason?
> 
> Looks like something to do with IDE settings or system though because it works fine with jtreg and other macos too.

I guess loading the XML for synth


lookAndFeel.load(bug6276188.class.getResourceAsStream("bug6276188.xml"), bug6276188.class);


doesn't work when you run the test from IDE, as [Prasanta said](https://github.com/openjdk/jdk/pull/27444#issuecomment-3364384538). I haven't tried myself.

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

PR Comment: https://git.openjdk.org/jdk/pull/27444#issuecomment-3374128436

From honkar at openjdk.org  Mon Oct  6 23:58:47 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 6 Oct 2025 23:58:47 GMT
Subject: RFR: 8368606: Printer lookup returns empty on AIX platform due to
 uninitialized results list [v3]
In-Reply-To: <HqP2zQoZ4IzcHAEW0YrnNFxmiG7-SfgguGJ7m7yssvU=.a841c61a-9b26-42df-b39e-396b5f4931e1@github.com>
References: <Gl2qsEx-CSwy_K5r9OQY4ACN451eE_iobOW7l2qnS1Y=.3fc4fb33-0485-4e0f-b5fd-2be1ac467977@github.com>
 <HqP2zQoZ4IzcHAEW0YrnNFxmiG7-SfgguGJ7m7yssvU=.a841c61a-9b26-42df-b39e-396b5f4931e1@github.com>
Message-ID: <B1VwHOZSZgCfWW-tnF8dBYe1S98DlQKYnHgIO2u7T6Y=.17e9d583-0418-4d14-84fd-32b745a67183@github.com>

On Mon, 29 Sep 2025 04:17:34 GMT, Ravi-Patel8 <duke at openjdk.org> wrote:

>> Bug Ref: https://bugs.openjdk.org/browse/JDK-8368606
>> 
>> As part of [JDK-8344057](https://bugs.openjdk.org/browse/JDK-8344057) ("Remove doPrivileged calls from unix platform sources in the java.desktop module"), changes were made to execCmd() in
>>  `src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java`.
>> In the updated implementation, execCmd(...) code is missing to initialize the results variable. It declares it as null and then tries to results.add(line), which prevents the results list from being populated with printer names.
>> 
>> Initializing the results variable will resolve the issue.
>> 
>> 
>> Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>
>
> Ravi-Patel8 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add debug_println instead of System.err.println
>   
>   Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

Changes LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27482#pullrequestreview-3307877138

From dnguyen at openjdk.org  Tue Oct  7 01:29:46 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 7 Oct 2025 01:29:46 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v9]
In-Reply-To: <i7VhKRjSOzLQuhWA31Dq03OpFM9i4KCcVVJvMV9nipU=.7dce1618-ca17-4a92-a10b-abf5b5b4c534@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <i7VhKRjSOzLQuhWA31Dq03OpFM9i4KCcVVJvMV9nipU=.7dce1618-ca17-4a92-a10b-abf5b5b4c534@github.com>
Message-ID: <zDhn0Od5usZkazHXLj7vSwv0STxN5-KFLjMYpQ9Bn8o=.b3bcbead-1afd-4b1e-8b30-3dd9bec7366f@github.com>

On Thu, 25 Sep 2025 00:25:25 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove synchronized keyword

@liach @mrserb When there is time, could I get a re-review on this after the changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3374839138

From serb at openjdk.org  Tue Oct  7 02:46:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Oct 2025 02:46:55 GMT
Subject: RFR: 8367017: Remove legacy checks from WrappedToolkitTest and
 convert from bash
In-Reply-To: <Nq6qhw--naqXhYjs1SpoJhxoqzeeSn14yA2V9fwp2-k=.ce350fbc-7082-4b6e-92ea-4b80f3f214f4@github.com>
References: <L92tilq-abjz3We8DG7eZXDu-kt-sOUqy322ytg5bak=.614c8417-242e-48cc-95f1-cc1a7b7df1ae@github.com>
 <Nq6qhw--naqXhYjs1SpoJhxoqzeeSn14yA2V9fwp2-k=.ce350fbc-7082-4b6e-92ea-4b80f3f214f4@github.com>
Message-ID: <NJ0nLRLzGq9k40U9s71ihm8I09-1ipgigpgrkWwuU98=.d9c5074b-286d-4129-a225-af1df2473ebd@github.com>

On Mon, 15 Sep 2025 18:49:50 GMT, Phil Race <prr at openjdk.org> wrote:

>I am not sure how valuable this test is these days. There's only one headful toolkit per-platform. Having said that, some day we expect to have WLToolkit too .. of course the test would need to be updated then. Hopefully without going back to a shell wrapper.

@prrace Will that toolkit reuse the lwawt? or it will be created from scratch?

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

PR Comment: https://git.openjdk.org/jdk/pull/27127#issuecomment-3374950724

From psadhukhan at openjdk.org  Tue Oct  7 04:11:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 7 Oct 2025 04:11:59 GMT
Subject: Integrated: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state
In-Reply-To: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
Message-ID: <HBe8PThR7wqeGNbTW6nidahz1o2fmzL7P_ITroeHpA8=.1ef45623-50d9-42b9-bcf4-46149ba595a0@github.com>

On Tue, 23 Sep 2025 07:10:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
> 
> 100 iterations of the test passed in all platforms.

This pull request has now been integrated.

Changeset: e783c524
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e783c524c17e1d1a3fff4b6370e222134e66edc8
Stats:     42 lines in 1 file changed: 27 ins; 6 del; 9 mod

8368185: Test javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth ButtonUI does not handle PRESSED & MOUSE_OVER state

Reviewed-by: tr, aivanov

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

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

From tr at openjdk.org  Tue Oct  7 04:30:46 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Oct 2025 04:30:46 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v3]
In-Reply-To: <VW_nxoOGjR7kjlzAHWRYMm5X97to5lyOERF2Ojz5K34=.5a2b638b-2ae6-4109-8ef9-e269f6b3e0f3@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
 <VW_nxoOGjR7kjlzAHWRYMm5X97to5lyOERF2Ojz5K34=.5a2b638b-2ae6-4109-8ef9-e269f6b3e0f3@github.com>
Message-ID: <t1p7XKthP7I5auY_LHCxEBFmb48lOxKw26DJfDfpcBs=.a10e5b80-d547-4166-a747-85f775549f56@github.com>

On Tue, 30 Sep 2025 05:12:28 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The test passed on CI machines with multiple test runs. Few stabilization fix has been made to make the test more robust.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

> I'm not convinced `invokeAndWait` is needed.
> 
> Capturing screenshot is appreciated.
> 
> As @DamonGuy mentioned, a better way to deal with [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) could be closing it as _Cannot reproduce_ and submitting a new bug to update `FrameLocation.java` and remove `SizeMinimizedTest.java` from the problem list.

Probably I'll capture screenshot on failure and deproblemlist it. If I close the bug as _Cannot reproduce_  then it remains in problem listing, so better way is to de-problemlist it and add screen capture.

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

PR Comment: https://git.openjdk.org/jdk/pull/27366#issuecomment-3375150363

From duke at openjdk.org  Tue Oct  7 05:35:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 7 Oct 2025 05:35:47 GMT
Subject: RFR: 8368606: Printer lookup returns empty on AIX platform due to
 uninitialized results list [v3]
In-Reply-To: <HqP2zQoZ4IzcHAEW0YrnNFxmiG7-SfgguGJ7m7yssvU=.a841c61a-9b26-42df-b39e-396b5f4931e1@github.com>
References: <Gl2qsEx-CSwy_K5r9OQY4ACN451eE_iobOW7l2qnS1Y=.3fc4fb33-0485-4e0f-b5fd-2be1ac467977@github.com>
 <HqP2zQoZ4IzcHAEW0YrnNFxmiG7-SfgguGJ7m7yssvU=.a841c61a-9b26-42df-b39e-396b5f4931e1@github.com>
Message-ID: <AVPx2pAmkcaZzFeYqYEo2lkOd8YzpaA6vMzdXBNITJQ=.969c29e9-f345-45c0-bf5a-a28316740ee3@github.com>

On Mon, 29 Sep 2025 04:17:34 GMT, Ravi-Patel8 <duke at openjdk.org> wrote:

>> Bug Ref: https://bugs.openjdk.org/browse/JDK-8368606
>> 
>> As part of [JDK-8344057](https://bugs.openjdk.org/browse/JDK-8344057) ("Remove doPrivileged calls from unix platform sources in the java.desktop module"), changes were made to execCmd() in
>>  `src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java`.
>> In the updated implementation, execCmd(...) code is missing to initialize the results variable. It declares it as null and then tries to results.add(line), which prevents the results list from being populated with printer names.
>> 
>> Initializing the results variable will resolve the issue.
>> 
>> 
>> Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>
>
> Ravi-Patel8 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add debug_println instead of System.err.println
>   
>   Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

@Ravi-Patel8 
Your change (at version 432f398ad136e978fe2154aa86d3c05a88972c84) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27482#issuecomment-3375270487

From tr at openjdk.org  Tue Oct  7 06:27:32 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Oct 2025 06:27:32 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v4]
In-Reply-To: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
Message-ID: <92GXarnpyt0EWzkbe5g5mNzvaXoSXGVmoxmm1ZTY5Ns=.6a176661-1fcc-48e6-b769-7a604c964eec@github.com>

> The test passed on CI machines with multiple test runs. Few stabilization fix has been made to make the test more robust.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Revert EDT and add screen capture

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27366/files
  - new: https://git.openjdk.org/jdk/pull/27366/files/274fb3ba..60e5276f

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

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

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

From psadhukhan at openjdk.org  Tue Oct  7 07:24:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 7 Oct 2025 07:24:56 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v6]
In-Reply-To: <VfkYxVzz-zDjxiittV7tVJY1e5bsTasi-wDtfWF_WRw=.18ec5ad5-6927-4f4a-acfb-f0f327aa1758@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <VfkYxVzz-zDjxiittV7tVJY1e5bsTasi-wDtfWF_WRw=.18ec5ad5-6927-4f4a-acfb-f0f327aa1758@github.com>
Message-ID: <47CrFrW4wnR-o-T00QYFzwmLXagjv8kpnd_-FBg3p1A=.55c70c09-41b2-483f-9c05-c15809b8ab22@github.com>

On Sat, 27 Sep 2025 04:40:03 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> Previously:
>> 
>> If DesktopProperty#updateAllUIs threw an exception, we would never reset the update-pending property to false. This means any subsequent call to `updateUI()` would not attempt to call `updateAllUIs()`
>> 
>> With this change:
>> Subsequent calls to DesktopProperty#updateUI() can still trigger at least one call to updateAllUIs().
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - 8367376: test all installed L&F's
>    
>    This is in response to:
>    https://git.openjdk.org/jdk/pull/27205#discussion_r2382574446
>  - Merge branch 'master' into JDK-8367376
>  - 8367376: use same try/finally pattern for SynthL&F
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2357719216
>  - 8367376: use same try/finally pattern for MetalL&F
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2357716063
>  - 8367376: remove setLookAndFeel
>    
>    This was probably left over from an earlier draft; this test uses the TestDesktopProperty class so it doesn't rely on/test any particular L&F.
>  - 8367376: rename test file
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2356674752
>  - 8367376: add new line to end of file
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2356666306
>  - 8367376: changing field names
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2356664929
>  - Update test/jdk/com/sun/java/swing/plaf/Test8367376.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/com/sun/java/swing/plaf/Test8367376.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/86c2a13e...1b669f8d

test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java line 92:

> 90:         Toolkit.getDefaultToolkit().getSystemEventQueue().push(newEventQueue);
> 91: 
> 92:         for (UIManager.LookAndFeelInfo info :

UIManager import is missing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27205#discussion_r2409647336

From tejesh.r at oracle.com  Tue Oct  7 09:18:49 2025
From: tejesh.r at oracle.com (Tejesh R)
Date: Tue, 7 Oct 2025 09:18:49 +0000
Subject: [External] : Re: FYI: Draft JEP: JDK-8368874 JEP: Add a
 JDatePicker UI Component to the Swing UI Toolkit (Preview)
In-Reply-To: <CAA9v-_OeE6Gu6V5rq=Ow4qAwSswBuLERaZgnwZBKDnknOW5Qjw@mail.gmail.com>
References: <B7E3DEFB-4889-4AE6-A77B-D33E00D00AF3@oracle.com>
 <CAA9v-_OeE6Gu6V5rq=Ow4qAwSswBuLERaZgnwZBKDnknOW5Qjw@mail.gmail.com>
Message-ID: <18307693-C6B1-49CF-979C-0DF6FB09E4CE@oracle.com>

Hello David,

                Thank you for the feedback. We currently have 3 options to select year (drop down is not an option though).

  1.  Set the year through TextField in JDatepicker for selection.
  2.  Select using navigation buttons next to Year Label which increment/decrement by 1 count.
  3.  Select using a separate Year panel which has a default Year scroll limit/range for easier navigation through mouse/key press. (The limit can be modified through api).

Regards,
Tejesh R



Confidential ? Oracle Internal
From: David Alayachew <davidalayachew at gmail.com>
Date: Tuesday, 30 September 2025 at 3:53?PM
To: Tejesh R <tejesh.r at oracle.com>
Cc: "client-libs-dev at openjdk.java.net" <client-libs-dev at openjdk.java.net>
Subject: [External] : Re: FYI: Draft JEP: JDK-8368874 JEP: Add a JDatePicker UI Component to the Swing UI Toolkit (Preview)

Looks great Tejesh R.

Only feedback is that, don't have a whole drop down for year. Since you are using LocalDate, then year could feasibly be 3000, and I don't think that having a scrollable list for that benefits anyone.

Just have the year selection be a text field, with some arrows for increment and decrement, and then maybe some keyboard controls for that same increment and decrement.

On Tue, Sep 30, 2025, 12:32?AM Tejesh R <tejesh.r at oracle.com<mailto:tejesh.r at oracle.com>> wrote:
Hello Swing Community,

                I just submitted - in draft state - https://bugs.openjdk.org/browse/JDK-8368874 which proposes to Add a JDatePicker UI Component to the Swing UI Toolkit.

Regards,
Tejesh R



Confidential ? Oracle Internal
From: Tejesh R <tejesh.r at oracle.com<mailto:tejesh.r at oracle.com>>
Date: Wednesday, 23 October 2024 at 11:20?AM
To: "client-libs-dev at openjdk.java.net<mailto:client-libs-dev at openjdk.java.net>" <client-libs-dev at openjdk.java.net<mailto:client-libs-dev at openjdk.java.net>>
Subject: RE: Seeking feedback on a possible JDatePicker Swing component

Hello Swing Community,

Thank you all for your valuable feedback on a possible JDatePicker Swing Component. [1]
The respondents all welcomed the proposal, so we plan to move forward with it.
We are digesting the details of the feedback and will draw upon it to create a draft JEP,
which we will publish as soon as it is ready.
Regards,
Tejesh R
JDK client team

[1] https://mail.openjdk.org/pipermail/client-libs-dev/2024-August/021805.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251007/735ba4c6/attachment-0001.htm>

From aivanov at openjdk.org  Tue Oct  7 09:24:27 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 09:24:27 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04
In-Reply-To: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
Message-ID: <gC2cUrAkWwYuLsJGMDzfmgBqcfdEUoTMQ7rQQX31PVs=.bc7b1b50-399a-4a7c-89ea-6104da99f4cf@github.com>

On Sun, 5 Oct 2025 05:37:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails to pick red color from JLabel in ubuntu24.04 even though it passes is ubuntu 22.04.
> Seems like the red pixel from the font is not being picked up despite the fact that label foreground color actually is rendered in red.
> 
> It is seen in ubuntu 22.04 the font used for JLabel is "family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12"
> while in ubuntu 24.04 the font used for JLabel is "family=Noto Sans,name=Noto Sans,style=plain,size=12"
> 
> I have made it consistent across version using same font and made it larger and bold and using such text for easier pickup of redpixel.
> It passes in all platforms including ubuntu24.04

test/jdk/javax/swing/plaf/basic/BasicHTML/bug4248210.java line 74:

> 72:         }
> 73: 
> 74:         JLabel label = new JLabel("<html><body>WWWWWWWWWMMMMMMM?</body></html>");

Full block character, `\u2588`, to ensure the entire label is filled with red color?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27635#discussion_r2409967825

From tr at openjdk.org  Tue Oct  7 09:26:39 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Oct 2025 09:26:39 GMT
Subject: RFR: 8368185: Test
 javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth
 ButtonUI does not handle PRESSED & MOUSE_OVER state [v3]
In-Reply-To: <OP3Oa4ZsUHdy8rfbLftaYfVzuA4_iVi4nMHGtpVP0T0=.744ce3c3-594c-46ae-9244-d01fb39c5f61@github.com>
References: <CiiB_dFjnQGP8ExdxmuV_B87B-VnGixrLKDYnaYcmsw=.8a7c256e-93b1-465d-bc7b-2b0b5dda137d@github.com>
 <OP3Oa4ZsUHdy8rfbLftaYfVzuA4_iVi4nMHGtpVP0T0=.744ce3c3-594c-46ae-9244-d01fb39c5f61@github.com>
Message-ID: <a0lcb_bf9AhMuMdOVEjSAd4fy9hbQcnaLoVv-GfdTPM=.762c40de-5e84-4e29-9aea-627c74f2b607@github.com>

On Sun, 5 Oct 2025 05:32:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test frame is changed to Red for Mouse PRESSED and MOUSE_OVER state but it seem time is too less before it is moved to Green when mouse press is released so it retrieves Green instead of Red.
>> Also, the pixel color retrieval point is conflicting with mouse cursor position, which gets picked up during `robot.createSceenCapture` execution so retrieval point is moved slightly up instead of down.
>> 
>> 100 iterations of the test passed in all platforms.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove waitForIdle

> > > This is observed when test is run from IDE. When it is run from jtreg the test passes. Seems strange behavior, do you know the reason?
> > 
> > 
> > Looks like something to do with IDE settings or system though because it works fine with jtreg and other macos too.
> 
> I guess loading the XML for synth
> 
> ```java
> lookAndFeel.load(bug6276188.class.getResourceAsStream("bug6276188.xml"), bug6276188.class);
> ```
> 
> doesn't work when you run the test from IDE, as [Prasanta said](https://github.com/openjdk/jdk/pull/27444#issuecomment-3364384538). I haven't tried myself.

This anyhow doesn't work in IDE, I modified accordingly while testing. Not related to this I guess.

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

PR Comment: https://git.openjdk.org/jdk/pull/27444#issuecomment-3375966527

From aivanov at openjdk.org  Tue Oct  7 10:25:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 10:25:00 GMT
Subject: Integrated: 8368892: Make JEditorPane/TestBrowserBGColor.java headless
In-Reply-To: <oeou7wBPkbuu2ZFw-JXFzSVaoxOadKl33OJvi-DenU4=.21ff4a96-b6b2-49c5-b073-8657f05099bd@github.com>
References: <oeou7wBPkbuu2ZFw-JXFzSVaoxOadKl33OJvi-DenU4=.21ff4a96-b6b2-49c5-b073-8657f05099bd@github.com>
Message-ID: <ZmOyk_1k0fArIsgLXQRsDO8gbrRh2MxoHPbnv6t_Eas=.ae945a82-57d9-412f-8d47-3fb3c4661a3a@github.com>

On Mon, 29 Sep 2025 20:16:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is to update `javax/swing/JEditorPane/TestBrowserBGColor.java` and to let it run headless.
> 
> Currently, the test creates a frame with `JEditorPane` with an HTML document the background color of which is set with three hex digits, `background: #FFF`. Then the test uses `Robot.getPixelColor` to verify the color of the pixel on the screen.
> 
> Now, the editor pane is rendered into a buffered image, this is needed to ensure text is laid out. The test then searches for a view that represents the `<body>` element and verifies that its background color is set to the expected *white* color. If it isn't so, the test saves the image for reference and throws an exception to indicate failure.
> 
> The updated test fails with JDK 11 because [JDK-8213781](https://bugs.openjdk.org/browse/JDK-8213781) isn't backported yet; the test passes with later versions including mainline. I ran the updated test on the CI, and it passes.

This pull request has now been integrated.

Changeset: 6bec42ad
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bec42adcc1d99e16ddd5148bb4012c74a0c3090
Stats:     88 lines in 1 file changed: 16 ins; 31 del; 41 mod

8368892: Make JEditorPane/TestBrowserBGColor.java headless

Reviewed-by: serb, azvegint

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

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

From aivanov at openjdk.org  Tue Oct  7 10:42:49 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 10:42:49 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v4]
In-Reply-To: <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
 <Yu2SK_bIjCuvYmhUQSA_53VJbuvN4UuYZq5tMefP2kw=.73adc4dc-f1ad-4039-950f-bfc02afad084@github.com>
 <jgt0eI7_exqJSEBAiyAQdNA0dnBgOKHqRldAduOkfdo=.8334283d-b3c1-4149-9d02-fe230a3480f7@github.com>
 <KzMF8D1GKgU-Z2ZxwETs9Zi4iFjLWj2OwIoUvx91TQ0=.ca590e78-64a5-4d5a-adfd-a94dfdb7bfdf@github.com>
 <51_8LtLfYKn8StwbKOTw3_AKyI9c3qCDwvHrbie9VZE=.2c46040e-6439-455a-81f4-437d25669282@github.com>
 <Irql74RktBY-6S7rvjBgsihs5z5DmBy1hkK_zrbWRKA=.937db58d-7177-4175-acf7-ac5c6b6366f5@github.com>
 <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
Message-ID: <FrbMmTQ4IVhYQHYgaKOlBriCV8wzpOWZm2H5MyFL46g=.559af11c-1d7d-4893-8fba-a9c199a9c897@github.com>

On Fri, 26 Sep 2025 21:33:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>>> > > Error
>>> > > ?? 8305915 is used in problem lists: [test/jdk/ProblemList.txt]
>>> > 
>>> > 
>>> > However, the problem list only contains another test under the 8305915 bug ID.
>>> > > java/awt/Frame/SizeMinimizedTest.java 8305915 linux-x64
>>> > 
>>> > 
>>> > And that is what we should pay attention to.
>>> 
>>> We should resolve this problem.
>>> 
>>> Tejesh problem-listed `SizeMinimizedTest.java` in #18448. The PR description states:
>>> 
>>> > Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>>> 
>>> If `SizeMinimizedTest.java` still fails, it's time to file a new bug for it. A sub-task of the new bug should be used to fix up the bugid in the problem list.
>> 
>> I tested `SizeMinimizedTest.java` running in CI and no failure is observed. It's true that I had added the test for different bug ID long time which is wrong. Should we just move it to another JBS and PL it while removing 8305915 PL ? I guess we should handle both the issue separately with different BugID ?
>
>> I tested SizeMinimizedTest.java running in CI and no failure is observed. It's true that I had added the test for different bug ID long time which is wrong. Should we just move it to another JBS and PL it while removing 8305915 PL ? I guess we should handle both the issue separately with different BugID ?
> 
> At the very least, this info should be added to the current JBS issue. Maybe update the title and the summary of the issue to also include the removal of `SizeMinimizedTest.java` from the PL.

> > As @DamonGuy mentioned, a better way to deal with [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) could be closing it as _Cannot reproduce_ and submitting a new bug to update `FrameLocation.java` and remove `SizeMinimizedTest.java` from the problem list.
> 
> Probably I'll capture screenshot on failure and deproblemlist it. If I close the bug as _Cannot reproduce_ then it remains in problem listing, so better way is to de-problemlist it and add screen capture.

That's the point?you cannot reproduce the failure of `FrameLocation.java`, can you?

Thus, the correct resolution is *Cannot Reproduce*.

Adding a screenshot is not fixing the failure reported in [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915), it's an improvement for the test to have the more information to analyse the failure if it occurs again. This is why it's a new issue.

8305915 has to be removed from the PL, submit a new bug, or rather create a subtask of JDK-8305915, to remove both `FrameLocation.java` and `SizeMinimizedTest.java` from the problem list.

I strongly believe this approach creates a clearer bug history in JBS and clearer changelog in the JDK. This also makes backporting easier as well as dealing with test failures in older releases.

Yes, submitting two new bugs creates more work but we're not in a rush here, and I think *it's worth the time*.

I can submit the bugs for you if you prefer so.

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

PR Comment: https://git.openjdk.org/jdk/pull/27366#issuecomment-3376307327

From psadhukhan at openjdk.org  Tue Oct  7 10:53:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 7 Oct 2025 10:53:13 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04 [v2]
In-Reply-To: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
Message-ID: <tuhM2ATYiClMieut8KYX01Orr6QJLTapyDFlv8DpF54=.7c0a317f-72f2-4cb3-bbce-9dad47c9688c@github.com>

> Test fails to pick red color from JLabel in ubuntu24.04 even though it passes is ubuntu 22.04.
> Seems like the red pixel from the font is not being picked up despite the fact that label foreground color actually is rendered in red.
> 
> It is seen in ubuntu 22.04 the font used for JLabel is "family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12"
> while in ubuntu 24.04 the font used for JLabel is "family=Noto Sans,name=Noto Sans,style=plain,size=12"
> 
> I have made it consistent across version using same font and made it larger and bold and using such text for easier pickup of redpixel.
> It passes in all platforms including ubuntu24.04

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

  Use full block red char

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27635/files
  - new: https://git.openjdk.org/jdk/pull/27635/files/537d53d3..a656dd07

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

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

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

From psadhukhan at openjdk.org  Tue Oct  7 10:53:14 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 7 Oct 2025 10:53:14 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04 [v2]
In-Reply-To: <gC2cUrAkWwYuLsJGMDzfmgBqcfdEUoTMQ7rQQX31PVs=.bc7b1b50-399a-4a7c-89ea-6104da99f4cf@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
 <gC2cUrAkWwYuLsJGMDzfmgBqcfdEUoTMQ7rQQX31PVs=.bc7b1b50-399a-4a7c-89ea-6104da99f4cf@github.com>
Message-ID: <IEFng-DvmnFs8XhPVo_KtuQjOy-B6_GShu__SxHBkos=.2db0bda9-85b6-4ff5-ba93-e68bb56561b4@github.com>

On Tue, 7 Oct 2025 09:18:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use full block red char
>
> test/jdk/javax/swing/plaf/basic/BasicHTML/bug4248210.java line 74:
> 
>> 72:         }
>> 73: 
>> 74:         JLabel label = new JLabel("<html><body>WWWWWWWWWMMMMMMM?</body></html>");
> 
> Full block character, `\u2588`, to ensure the entire label is filled with red color?

Yes, that can be used..Modified...We have used for another JRadioButton synth test if I am not wrong

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27635#discussion_r2410214369

From tr at openjdk.org  Tue Oct  7 11:15:47 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Oct 2025 11:15:47 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v4]
In-Reply-To: <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
 <Yu2SK_bIjCuvYmhUQSA_53VJbuvN4UuYZq5tMefP2kw=.73adc4dc-f1ad-4039-950f-bfc02afad084@github.com>
 <jgt0eI7_exqJSEBAiyAQdNA0dnBgOKHqRldAduOkfdo=.8334283d-b3c1-4149-9d02-fe230a3480f7@github.com>
 <KzMF8D1GKgU-Z2ZxwETs9Zi4iFjLWj2OwIoUvx91TQ0=.ca590e78-64a5-4d5a-adfd-a94dfdb7bfdf@github.com>
 <51_8LtLfYKn8StwbKOTw3_AKyI9c3qCDwvHrbie9VZE=.2c46040e-6439-455a-81f4-437d25669282@github.com>
 <Irql74RktBY-6S7rvjBgsihs5z5DmBy1hkK_zrbWRKA=.937db58d-7177-4175-acf7-ac5c6b6366f5@github.com>
 <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
Message-ID: <5e6LcbU8spmmm_T19K6WyCenf17d4g0Ys_Um5Y9Zk-k=.387bfe7d-0de5-4889-8455-e1d31ef91245@github.com>

On Fri, 26 Sep 2025 21:33:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>>> > > Error
>>> > > ?? 8305915 is used in problem lists: [test/jdk/ProblemList.txt]
>>> > 
>>> > 
>>> > However, the problem list only contains another test under the 8305915 bug ID.
>>> > > java/awt/Frame/SizeMinimizedTest.java 8305915 linux-x64
>>> > 
>>> > 
>>> > And that is what we should pay attention to.
>>> 
>>> We should resolve this problem.
>>> 
>>> Tejesh problem-listed `SizeMinimizedTest.java` in #18448. The PR description states:
>>> 
>>> > Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>>> 
>>> If `SizeMinimizedTest.java` still fails, it's time to file a new bug for it. A sub-task of the new bug should be used to fix up the bugid in the problem list.
>> 
>> I tested `SizeMinimizedTest.java` running in CI and no failure is observed. It's true that I had added the test for different bug ID long time which is wrong. Should we just move it to another JBS and PL it while removing 8305915 PL ? I guess we should handle both the issue separately with different BugID ?
>
>> I tested SizeMinimizedTest.java running in CI and no failure is observed. It's true that I had added the test for different bug ID long time which is wrong. Should we just move it to another JBS and PL it while removing 8305915 PL ? I guess we should handle both the issue separately with different BugID ?
> 
> At the very least, this info should be added to the current JBS issue. Maybe update the title and the summary of the issue to also include the removal of `SizeMinimizedTest.java` from the PL.

> > > As @DamonGuy mentioned, a better way to deal with [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) could be closing it as _Cannot reproduce_ and submitting a new bug to update `FrameLocation.java` and remove `SizeMinimizedTest.java` from the problem list.
> > 
> > 
> > Probably I'll capture screenshot on failure and deproblemlist it. If I close the bug as _Cannot reproduce_ then it remains in problem listing, so better way is to de-problemlist it and add screen capture.
> 
> That's the point?you cannot reproduce the failure of `FrameLocation.java`, can you?
> 
> Thus, the correct resolution is _Cannot Reproduce_.
> 
> Adding a screenshot is not fixing the failure reported in [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915), it's an improvement for the test to have the more information to analyse the failure if it occurs again. This is why it's a new issue.
> 
> 8305915 has to be removed from the PL, submit a new bug, or rather create a subtask of JDK-8305915, to remove both `FrameLocation.java` and `SizeMinimizedTest.java` from the problem list.
> 
> I strongly believe this approach creates a clearer bug history in JBS and clearer changelog in the JDK. This also makes backporting easier as well as dealing with test failures in older releases.
> 
> Yes, submitting two new bugs creates more work but we're not in a rush here, and I think _it's worth the time_.
> 
> I can submit the bugs for you if you prefer so.

Sure then, sub tasking would be better idea, I'll do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/27366#issuecomment-3376425131

From davidalayachew at gmail.com  Tue Oct  7 11:22:51 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 7 Oct 2025 07:22:51 -0400
Subject: [External] : Re: FYI: Draft JEP: JDK-8368874 JEP: Add a
 JDatePicker UI Component to the Swing UI Toolkit (Preview)
In-Reply-To: <18307693-C6B1-49CF-979C-0DF6FB09E4CE@oracle.com>
References: <B7E3DEFB-4889-4AE6-A77B-D33E00D00AF3@oracle.com>
 <CAA9v-_OeE6Gu6V5rq=Ow4qAwSswBuLERaZgnwZBKDnknOW5Qjw@mail.gmail.com>
 <18307693-C6B1-49CF-979C-0DF6FB09E4CE@oracle.com>
Message-ID: <CAA9v-_OiAhHsSPoy-NPe050vMZLPUVrFJNXHGG0-FrfsTv4s4Q@mail.gmail.com>

Ok, cool. If the limit is set via the API, then I am good with it. Ty vm.

On Tue, Oct 7, 2025, 5:18?AM Tejesh R <tejesh.r at oracle.com> wrote:

> Hello David,
>
>
>
>                 Thank you for the feedback. We currently have 3 options to
> select year (drop down is not an option though).
>
>    1. Set the year through TextField in JDatepicker for selection.
>    2. Select using navigation buttons next to Year Label which
>    increment/decrement by 1 count.
>    3. Select using a separate Year panel which has a default Year scroll
>    limit/range for easier navigation through mouse/key press. (The limit can
>    be modified through api).
>
>
>
> Regards,
>
> Tejesh R
>
>
>
> Confidential ? Oracle Internal
>
> *From: *David Alayachew <davidalayachew at gmail.com>
> *Date: *Tuesday, 30 September 2025 at 3:53?PM
> *To: *Tejesh R <tejesh.r at oracle.com>
> *Cc: *"client-libs-dev at openjdk.java.net" <client-libs-dev at openjdk.java.net
> >
> *Subject: *[External] : Re: FYI: Draft JEP: JDK-8368874 JEP: Add a
> JDatePicker UI Component to the Swing UI Toolkit (Preview)
>
>
>
> Looks great Tejesh R.
>
>
>
> Only feedback is that, don't have a whole drop down for year. Since you
> are using LocalDate, then year could feasibly be 3000, and I don't think
> that having a scrollable list for that benefits anyone.
>
>
>
> Just have the year selection be a text field, with some arrows for
> increment and decrement, and then maybe some keyboard controls for that
> same increment and decrement.
>
>
>
> On Tue, Sep 30, 2025, 12:32?AM Tejesh R <tejesh.r at oracle.com> wrote:
>
> Hello Swing Community,
>
>
>
>                 I just submitted - in draft state -
> https://bugs.openjdk.org/browse/JDK-8368874 which proposes to Add a
> JDatePicker UI Component to the Swing UI Toolkit.
>
>
>
> Regards,
>
> Tejesh R
>
>
>
>
>
> Confidential ? Oracle Internal
>
> *From: *Tejesh R <tejesh.r at oracle.com>
> *Date: *Wednesday, 23 October 2024 at 11:20?AM
> *To: *"client-libs-dev at openjdk.java.net" <client-libs-dev at openjdk.java.net
> >
> *Subject: *RE: Seeking feedback on a possible JDatePicker Swing component
>
>
>
> Hello Swing Community,
>
> Thank you all for your valuable feedback on a possible JDatePicker Swing
> Component. [1]
> The respondents all welcomed the proposal, so we plan to move forward with
> it.
> We are digesting the details of the feedback and will draw upon it to
> create a draft JEP,
> which we will publish as soon as it is ready.
>
> Regards,
> Tejesh R
>
> JDK client team
>
>
> [1]
> https://mail.openjdk.org/pipermail/client-libs-dev/2024-August/021805.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251007/60f3e360/attachment.htm>

From mullan at openjdk.org  Tue Oct  7 13:22:37 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 7 Oct 2025 13:22:37 GMT
Subject: RFR: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep [v12]
In-Reply-To: <b1PT909B5J0Hl4Gplp8y42CiNVEjt2Oc8MK8F_DRTWY=.7b6d883d-2318-4a28-85c7-7483ede93e8b@github.com>
References: <XAcizF6aMn09rsUXJamHojBg_fInClY-RRLAf75t0L0=.fc664a86-9255-4c6f-a376-a6177e9be324@github.com>
 <b1PT909B5J0Hl4Gplp8y42CiNVEjt2Oc8MK8F_DRTWY=.7b6d883d-2318-4a28-85c7-7483ede93e8b@github.com>
Message-ID: <xymmCHquz50KFh9YIuAsbWo2V0KrxV8JBUzG2MulUY8=.2c7293ea-16ea-4705-9c37-878bcfe01ed9@github.com>

On Mon, 6 Oct 2025 15:31:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Allow password hiding even if there is no `System.console`. A manual test is included.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more null check; one less empty check

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3310089768

From tr at openjdk.org  Tue Oct  7 16:41:20 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Oct 2025 16:41:20 GMT
Subject: Withdrawn: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!"
In-Reply-To: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
Message-ID: <qN3Z3si7-o9jqKwVjZnuio8_rpcXv8FpercZHo3i_zs=.fe27aae9-37c8-40cb-bada-054cb737ae21@github.com>

On Thu, 18 Sep 2025 14:51:46 GMT, Tejesh R <tr at openjdk.org> wrote:

> The test passed on CI machines with multiple test runs. Few stabilization fix has been made to make the test more robust.

This pull request has been closed without being integrated.

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

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

From tr at openjdk.org  Tue Oct  7 16:47:51 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Oct 2025 16:47:51 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v4]
In-Reply-To: <FrbMmTQ4IVhYQHYgaKOlBriCV8wzpOWZm2H5MyFL46g=.559af11c-1d7d-4893-8fba-a9c199a9c897@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
 <Yu2SK_bIjCuvYmhUQSA_53VJbuvN4UuYZq5tMefP2kw=.73adc4dc-f1ad-4039-950f-bfc02afad084@github.com>
 <jgt0eI7_exqJSEBAiyAQdNA0dnBgOKHqRldAduOkfdo=.8334283d-b3c1-4149-9d02-fe230a3480f7@github.com>
 <KzMF8D1GKgU-Z2ZxwETs9Zi4iFjLWj2OwIoUvx91TQ0=.ca590e78-64a5-4d5a-adfd-a94dfdb7bfdf@github.com>
 <51_8LtLfYKn8StwbKOTw3_AKyI9c3qCDwvHrbie9VZE=.2c46040e-6439-455a-81f4-437d25669282@github.com>
 <Irql74RktBY-6S7rvjBgsihs5z5DmBy1hkK_zrbWRKA=.937db58d-7177-4175-acf7-ac5c6b6366f5@github.com>
 <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
 <FrbMmTQ4IVhYQHYgaKOlBriCV8wzpOWZm2H5MyFL46g=.559af11c-1d7d-4893-8fba-a9c199a9c897@github.com>
Message-ID: <L6DJ06ay7s6Rp9HXbQ1FbAOUYDC9s1TgBzTmYWYvGzE=.847236f4-88fa-40a4-8694-ea5e22a1506a@github.com>

On Tue, 7 Oct 2025 10:40:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> I tested SizeMinimizedTest.java running in CI and no failure is observed. It's true that I had added the test for different bug ID long time which is wrong. Should we just move it to another JBS and PL it while removing 8305915 PL ? I guess we should handle both the issue separately with different BugID ?
>> 
>> At the very least, this info should be added to the current JBS issue. Maybe update the title and the summary of the issue to also include the removal of `SizeMinimizedTest.java` from the PL.
>
>> > As @DamonGuy mentioned, a better way to deal with [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) could be closing it as _Cannot reproduce_ and submitting a new bug to update `FrameLocation.java` and remove `SizeMinimizedTest.java` from the problem list.
>> 
>> Probably I'll capture screenshot on failure and deproblemlist it. If I close the bug as _Cannot reproduce_ then it remains in problem listing, so better way is to de-problemlist it and add screen capture.
> 
> That's the point?you cannot reproduce the failure of `FrameLocation.java`, can you?
> 
> Thus, the correct resolution is *Cannot Reproduce*.
> 
> Adding a screenshot is not fixing the failure reported in [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915), it's an improvement for the test to have the more information to analyse the failure if it occurs again. This is why it's a new issue.
> 
> 8305915 has to be removed from the PL, submit a new bug, or rather create a subtask of JDK-8305915, to remove both `FrameLocation.java` and `SizeMinimizedTest.java` from the problem list.
> 
> I strongly believe this approach creates a clearer bug history in JBS and clearer changelog in the JDK. This also makes backporting easier as well as dealing with test failures in older releases.
> 
> Yes, submitting two new bugs creates more work but we're not in a rush here, and I think *it's worth the time*.
> 
> I can submit the bugs for you if you prefer so.

@aivanov-jdk @DamonGuy I've raised https://github.com/openjdk/jdk/pull/27678 PR for de-problemlisting the main bug. Once this is integrated, I'll close the main bug as "Not-Reproducible".

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

PR Comment: https://git.openjdk.org/jdk/pull/27366#issuecomment-3377713390

From prr at openjdk.org  Tue Oct  7 16:51:17 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Oct 2025 16:51:17 GMT
Subject: Integrated: 8358058: sun/java2d/OpenGL/DrawImageBg.java Test fails
 intermittently
In-Reply-To: <ZcyNtV0gCE7EFOrFpmOLrwIP_LDSKoAPjWLoiG-z5GU=.551a1210-ed25-46f5-8350-3ddd2519e2be@github.com>
References: <ZcyNtV0gCE7EFOrFpmOLrwIP_LDSKoAPjWLoiG-z5GU=.551a1210-ed25-46f5-8350-3ddd2519e2be@github.com>
Message-ID: <rHyubWn-bNMShZG8xTDWa6tWITCKVncsVfUsVCJfML0=.1f0e6d34-daf2-42a9-9973-610a05f44a68@github.com>

On Fri, 19 Sep 2025 21:53:30 GMT, Phil Race <prr at openjdk.org> wrote:

> Moving to open a number of graphics related tests, originally written to test the OpenGL pipeline.
> These versions are "better behaved" than the versions that were in closed - mostly meaning they now
> do things on the right thread and paint properly on demand.
> As a result they now pass - at least on systems with correct drivers etc.
> There are a few bugs to add to the issue list which I'll do right after submitting this.
> 
> I also extended these tests so as to run with the default pipeline on every system, not just OpenGL.
> This mostly went OK except that I found one of the tests fails on macOS with metal.
> I've had to add a new problem listing for that.

This pull request has now been integrated.

Changeset: ebeb77ba
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ebeb77baaeb6d9098d7462f5ddf61d8583b1e493
Stats:     1989 lines in 11 files changed: 1989 ins; 0 del; 0 mod

8358058: sun/java2d/OpenGL/DrawImageBg.java Test fails intermittently

Reviewed-by: azvegint, serb, psadhukhan

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

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

From aivanov at openjdk.org  Tue Oct  7 17:19:28 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 17:19:28 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v4]
In-Reply-To: <L6DJ06ay7s6Rp9HXbQ1FbAOUYDC9s1TgBzTmYWYvGzE=.847236f4-88fa-40a4-8694-ea5e22a1506a@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
 <Yu2SK_bIjCuvYmhUQSA_53VJbuvN4UuYZq5tMefP2kw=.73adc4dc-f1ad-4039-950f-bfc02afad084@github.com>
 <jgt0eI7_exqJSEBAiyAQdNA0dnBgOKHqRldAduOkfdo=.8334283d-b3c1-4149-9d02-fe230a3480f7@github.com>
 <KzMF8D1GKgU-Z2ZxwETs9Zi4iFjLWj2OwIoUvx91TQ0=.ca590e78-64a5-4d5a-adfd-a94dfdb7bfdf@github.com>
 <51_8LtLfYKn8StwbKOTw3_AKyI9c3qCDwvHrbie9VZE=.2c46040e-6439-455a-81f4-437d25669282@github.com>
 <Irql74RktBY-6S7rvjBgsihs5z5DmBy1hkK_zrbWRKA=.937db58d-7177-4175-acf7-ac5c6b6366f5@github.com>
 <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
 <FrbMmTQ4IVhYQHYgaKOlBriCV8wzpOWZm2H5MyFL46g=.559af11c-1d7d-4893-8fba-a9c199a9c897@github.com>
 <L6DJ06ay7s6Rp9HXbQ1FbAOUYDC9s1TgBzTmYWYvGzE=.847236f4-88fa-40a4-8694-ea5e22a1506a@github.com>
Message-ID: <CP6WX9pCxPoZDdzOl8vcRGZAfNC0y649UpYgbCDrGJM=.bba44a38-beb0-4f28-b30a-b74ca0124d7d@github.com>

On Tue, 7 Oct 2025 16:44:39 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> > As @DamonGuy mentioned, a better way to deal with [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) could be closing it as _Cannot reproduce_ and submitting a new bug to update `FrameLocation.java` and remove `SizeMinimizedTest.java` from the problem list.
>>> 
>>> Probably I'll capture screenshot on failure and deproblemlist it. If I close the bug as _Cannot reproduce_ then it remains in problem listing, so better way is to de-problemlist it and add screen capture.
>> 
>> That's the point?you cannot reproduce the failure of `FrameLocation.java`, can you?
>> 
>> Thus, the correct resolution is *Cannot Reproduce*.
>> 
>> Adding a screenshot is not fixing the failure reported in [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915), it's an improvement for the test to have the more information to analyse the failure if it occurs again. This is why it's a new issue.
>> 
>> 8305915 has to be removed from the PL, submit a new bug, or rather create a subtask of JDK-8305915, to remove both `FrameLocation.java` and `SizeMinimizedTest.java` from the problem list.
>> 
>> I strongly believe this approach creates a clearer bug history in JBS and clearer changelog in the JDK. This also makes backporting easier as well as dealing with test failures in older releases.
>> 
>> Yes, submitting two new bugs creates more work but we're not in a rush here, and I think *it's worth the time*.
>> 
>> I can submit the bugs for you if you prefer so.
>
> @aivanov-jdk @DamonGuy I've raised https://github.com/openjdk/jdk/pull/27678 PR for de-problemlisting the main bug. Once this is integrated, I'll close the main bug as "Not-Reproducible".

@TejeshR13 You can still use this PR to implement adding screenshots, just change the subject of the PR to associate it with the new bugid.

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

PR Comment: https://git.openjdk.org/jdk/pull/27366#issuecomment-3377812472

From tr at openjdk.org  Tue Oct  7 17:25:17 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Oct 2025 17:25:17 GMT
Subject: RFR: 8369311: De-problemlist 8305915 since the issue is not
 reproducible
Message-ID: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com>

[JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) is not reproducible with multiple CI checks. The main test java/awt/Frame/FrameLocation/FrameLocation.java which was failing is been missed in the Problem-List file, rather java/awt/Frame/SizeMinimizedTest.java is been added which still doesn't fail. So de-problemlisting with a sub-task and closing the main bug as "Not-reproducible".

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

Commit messages:
 - de-porblemlist

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

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

From aivanov at openjdk.org  Tue Oct  7 17:25:17 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 17:25:17 GMT
Subject: RFR: 8369311: De-problemlist 8305915 since the issue is not
 reproducible
In-Reply-To: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com>
References: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com>
Message-ID: <v-0jMpY5fLVbP1kH5VAD6ZeKH171jcDgvnvuybQw44I=.4e0dd581-29f9-4e6f-930b-2e09a7a3ec20@github.com>

On Tue, 7 Oct 2025 16:43:08 GMT, Tejesh R <tr at openjdk.org> wrote:

> [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) is not reproducible with multiple CI checks. The main test java/awt/Frame/FrameLocation/FrameLocation.java which was failing is been missed in the Problem-List file, rather java/awt/Frame/SizeMinimizedTest.java is been added which still doesn't fail. So de-problemlisting with a sub-task and closing the main bug as "Not-reproducible".

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27678#pullrequestreview-3311111497

From aivanov at openjdk.org  Tue Oct  7 17:27:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 17:27:02 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04 [v2]
In-Reply-To: <tuhM2ATYiClMieut8KYX01Orr6QJLTapyDFlv8DpF54=.7c0a317f-72f2-4cb3-bbce-9dad47c9688c@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
 <tuhM2ATYiClMieut8KYX01Orr6QJLTapyDFlv8DpF54=.7c0a317f-72f2-4cb3-bbce-9dad47c9688c@github.com>
Message-ID: <y1KwJRDoFuETRPStQvW1pj4GMrELY-jDGumtSG2LXCA=.53b5f1d0-8bb3-42f8-a5b5-1c38f6af8fcb@github.com>

On Tue, 7 Oct 2025 10:53:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails to pick red color from JLabel in ubuntu24.04 even though it passes is ubuntu 22.04.
>> Seems like the red pixel from the font is not being picked up despite the fact that label foreground color actually is rendered in red.
>> 
>> It is seen in ubuntu 22.04 the font used for JLabel is "family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12"
>> while in ubuntu 24.04 the font used for JLabel is "family=Noto Sans,name=Noto Sans,style=plain,size=12"
>> 
>> I have made it consistent across version using same font and made it larger and bold and using such text for easier pickup of redpixel.
>> It passes in all platforms including ubuntu24.04
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use full block red char

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/plaf/basic/BasicHTML/bug4248210.java line 74:

> 72:         }
> 73: 
> 74:         JLabel label = new JLabel("<html><body>\u2588 \u2588 \u2588 \u2588</body></html>");

Suggestion:

        JLabel label = new JLabel("<html><body>\u2588\u2588\u2588\u2588</body></html>");

No one sees the text, spaces aren't necessary.

A comment will clarify what the Unicode character is used and why. Otherwise, it looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/27635#pullrequestreview-3311132957
PR Review Comment: https://git.openjdk.org/jdk/pull/27635#discussion_r2411354488

From aivanov at openjdk.org  Tue Oct  7 17:27:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 17:27:04 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04 [v2]
In-Reply-To: <IEFng-DvmnFs8XhPVo_KtuQjOy-B6_GShu__SxHBkos=.2db0bda9-85b6-4ff5-ba93-e68bb56561b4@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
 <gC2cUrAkWwYuLsJGMDzfmgBqcfdEUoTMQ7rQQX31PVs=.bc7b1b50-399a-4a7c-89ea-6104da99f4cf@github.com>
 <IEFng-DvmnFs8XhPVo_KtuQjOy-B6_GShu__SxHBkos=.2db0bda9-85b6-4ff5-ba93-e68bb56561b4@github.com>
Message-ID: <cUrpcX91FfxzFyA8ZcJU7dSCWSfy1cNnX8XpRDbWHNw=.d325fe09-645c-4da9-a6d9-0f6bd7d1f766@github.com>

On Tue, 7 Oct 2025 10:49:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/plaf/basic/BasicHTML/bug4248210.java line 74:
>> 
>>> 72:         }
>>> 73: 
>>> 74:         JLabel label = new JLabel("<html><body>WWWWWWWWWMMMMMMM?</body></html>");
>> 
>> Full block character, `\u2588`, to ensure the entire label is filled with red color?
>
> Yes, that can be used..Modified...We have used for another JRadioButton synth test if I am not wrong

Yep!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27635#discussion_r2411349311

From jwood at openjdk.org  Tue Oct  7 17:30:30 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Tue, 7 Oct 2025 17:30:30 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v7]
In-Reply-To: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
Message-ID: <z4eEfPLTNQRtad_FRdjXi0SAQHlGJhyrYiibtJV79hw=.fb5fe128-f8b7-41b2-a917-0dfb49f4b81f@github.com>

> Previously:
> 
> If DesktopProperty#updateAllUIs threw an exception, we would never reset the update-pending property to false. This means any subsequent call to `updateUI()` would not attempt to call `updateAllUIs()`
> 
> With this change:
> Subsequent calls to DesktopProperty#updateUI() can still trigger at least one call to updateAllUIs().

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8367376: adding missing UIManager import
  
  This is in response to:
  https://git.openjdk.org/jdk/pull/27205#discussion_r2409647336

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27205/files
  - new: https://git.openjdk.org/jdk/pull/27205/files/1b669f8d..d93815c9

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

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

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

From jwood at openjdk.org  Tue Oct  7 17:30:35 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Tue, 7 Oct 2025 17:30:35 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v6]
In-Reply-To: <47CrFrW4wnR-o-T00QYFzwmLXagjv8kpnd_-FBg3p1A=.55c70c09-41b2-483f-9c05-c15809b8ab22@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <VfkYxVzz-zDjxiittV7tVJY1e5bsTasi-wDtfWF_WRw=.18ec5ad5-6927-4f4a-acfb-f0f327aa1758@github.com>
 <47CrFrW4wnR-o-T00QYFzwmLXagjv8kpnd_-FBg3p1A=.55c70c09-41b2-483f-9c05-c15809b8ab22@github.com>
Message-ID: <ujp81Aas3uUiBSkPnVzAnQjrrFtklVfLTgfGR-U9Bgk=.7727dbf1-ac77-4ca2-8624-e8d0deb57889@github.com>

On Tue, 7 Oct 2025 07:22:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - 8367376: test all installed L&F's
>>    
>>    This is in response to:
>>    https://git.openjdk.org/jdk/pull/27205#discussion_r2382574446
>>  - Merge branch 'master' into JDK-8367376
>>  - 8367376: use same try/finally pattern for SynthL&F
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/27205#discussion_r2357719216
>>  - 8367376: use same try/finally pattern for MetalL&F
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/27205#discussion_r2357716063
>>  - 8367376: remove setLookAndFeel
>>    
>>    This was probably left over from an earlier draft; this test uses the TestDesktopProperty class so it doesn't rely on/test any particular L&F.
>>  - 8367376: rename test file
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/27205#discussion_r2356674752
>>  - 8367376: add new line to end of file
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/27205#discussion_r2356666306
>>  - 8367376: changing field names
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/27205#discussion_r2356664929
>>  - Update test/jdk/com/sun/java/swing/plaf/Test8367376.java
>>    
>>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>>  - Update test/jdk/com/sun/java/swing/plaf/Test8367376.java
>>    
>>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/db7079dd...1b669f8d
>
> test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java line 92:
> 
>> 90:         Toolkit.getDefaultToolkit().getSystemEventQueue().push(newEventQueue);
>> 91: 
>> 92:         for (UIManager.LookAndFeelInfo info :
> 
> UIManager import is missing

Thanks; this is updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27205#discussion_r2411359670

From azvegint at openjdk.org  Tue Oct  7 17:32:16 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 7 Oct 2025 17:32:16 GMT
Subject: RFR: 8369311: De-problemlist 8305915 since the issue is not
 reproducible
In-Reply-To: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com>
References: <4LAh1FXUeqdb0B1nNWCmB7TDzBJp1wwH6h6X8FaddFw=.c1f92044-9389-4541-88b7-a7356e82abef@github.com>
Message-ID: <AHq9sRNNQ0El_cEHeGFIP-9SrKMKVqaQROiDCrSO3Ns=.95f99125-ef9b-407a-9db0-3be5ae52233d@github.com>

On Tue, 7 Oct 2025 16:43:08 GMT, Tejesh R <tr at openjdk.org> wrote:

> [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) is not reproducible with multiple CI checks. The main test java/awt/Frame/FrameLocation/FrameLocation.java which was failing is been missed in the Problem-List file, rather java/awt/Frame/SizeMinimizedTest.java is been added which still doesn't fail. So de-problemlisting with a sub-task and closing the main bug as "Not-reproducible".

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27678#pullrequestreview-3311162582

From serb at openjdk.org  Tue Oct  7 18:01:28 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Oct 2025 18:01:28 GMT
Subject: RFR: 8369032: Add test to ensure serialized ICC_Profile stores
 only necessary optional data [v2]
In-Reply-To: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
References: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
Message-ID: <xwtaVvzBXNnVQgx7gOREXl_jrh13pNuGPEgdRgDcGsw=.2bf54781-d27a-46e6-b1a0-ff30b9f60c37@github.com>

> Added a small test to check the size of ICC profile data after serialization.
> For standard profiles, the size should stay small (under 200 bytes) because the real data is not stored.
> For custom profiles, the size depends on the real data plus a small overhead.

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

 - Merge branch 'openjdk:master' into JDK-8369032
 - Update SerializedFormSize.java
 - 8369032: Add test to ensure serialized ICC_Profile stores only necessary optional data

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27616/files
  - new: https://git.openjdk.org/jdk/pull/27616/files/3f91eca3..6ad4a82c

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

  Stats: 10622 lines in 430 files changed: 6792 ins; 2017 del; 1813 mod
  Patch: https://git.openjdk.org/jdk/pull/27616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27616/head:pull/27616

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

From prr at openjdk.org  Tue Oct  7 19:07:16 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Oct 2025 19:07:16 GMT
Subject: RFR: 8366002: Beans.instantiate needs to describe the lookup
 procedure [v3]
In-Reply-To: <-BkuInssj6CJiOj8d_W2ppxhIfbUfK2LZWZJiiKQJ_k=.3a4a0cc6-8836-40a3-be05-d6c6b13f378e@github.com>
References: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
 <FwhOPaW_26h4BbjzjWZ9nu_5J9YJ_Ct57_eb-Yo3oA8=.fe3952d9-37bb-4d14-9749-34a5608493c9@github.com>
 <-BkuInssj6CJiOj8d_W2ppxhIfbUfK2LZWZJiiKQJ_k=.3a4a0cc6-8836-40a3-be05-d6c6b13f378e@github.com>
Message-ID: <NZXtcQTp-XHBXyQ4I0qBVaBna9pB5zXz2-XRbLYhIys=.3999c883-132d-469b-8862-53611712c16c@github.com>

On Mon, 29 Sep 2025 14:24:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366002
>
> src/java.desktop/share/classes/java/beans/Beans.java line 81:
> 
>> 79:      * try to read a serialized object from the resource "x/y.ser" and if
>> 80:      * that failed it would try to load the class "x.y" and create an
>> 81:      * instance of that class.
> 
> Suggestion:
> 
>      * For example, given a {@code beanName} of {@code "x.y"}, {@code Beans.instantiate} would first
>      * try to read a serialized object from the resource {@code "x/y.ser"} and if
>      * that failed it would try to load the class {@code "x.y"} and create an
>      * instance of that class.
> 
> I think the example names of the classes and files should be marked up with `{@code}`. This also applies to `".ser"` in the paragraph above.

I'm not sure that is necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26905#discussion_r2411618029

From prr at openjdk.org  Tue Oct  7 19:11:06 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Oct 2025 19:11:06 GMT
Subject: Integrated: 8366002: Beans.instantiate needs to describe the lookup
 procedure
In-Reply-To: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
References: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
Message-ID: <YYk8RLtc92e4xacCFbPLpKBwgJ05E0NXMtnbo86vgg0=.21d58d2f-cf30-48a5-bc55-1bf36c855004@github.com>

On Fri, 22 Aug 2025 17:39:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Some text describing the Beans.instantiate lookup process existed only on the method that used the now removed AppletInitializer.
> Since there are two other Beans.instantiate methods, we need to move that text to the remaining methods.
> 
> Note that one of the methods is also deprecated for removal, so it seems prudent to add it to both so that when the next to be removed method is gone, this problem doesn't recur.
> 
> This is a doc. only change. The CSR is ready for review.

This pull request has now been integrated.

Changeset: 6bfd018b
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6bfd018beaf187940ebafc71885045b4aabca673
Stats:     32 lines in 1 file changed: 32 ins; 0 del; 0 mod

8366002: Beans.instantiate needs to describe the lookup procedure

Reviewed-by: serb, aivanov

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

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

From prr at openjdk.org  Tue Oct  7 19:17:30 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Oct 2025 19:17:30 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
Message-ID: <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>

On Mon, 6 Oct 2025 19:08:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Specifying the behaviour of BufferedImage constructors for invalid dimensions is long overdue.
>> 
>> The behaviour for image types and sizes <= 0 is unchanged by this PR.
>> Also in many cases the behaviour for sizes that are too large is also unchanged.
>> In some cases, the behaviour is changed from "accidental" NegativeArraySizeException to a consistent IllegalArgumentException.
>> 
>> In no case is anything changed that would affect the possibility to construct a BufferedImage.
>> 
>> A test is provided to ensure the behaviour.
>> 
>> A CSR is provided too : https://bugs.openjdk.org/browse/JDK-8369155
>
> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 314:
> 
>> 312:      * @throws IllegalArgumentException if the multiplication product of
>> 313:      *          {@code width}, {@code height}, and the number of samples per pixel
>> 314:      *          for the specified format exceeds the maximum length of a Java array.
> 
> This check seems too strict. It is possible to implement a BufferedImage that splits its internal data into multiple surfaces/arrays. It might be better to phrase this as optional:
> ?for the specified format exceeds the maximum supported length?

I had looked at using a BandedRaster but there were a decent number of places that relied on the current format, even inside the JDK.
The work and compatibility concerns to address these are out of all proportion to simply documenting what has been true since the very beginning - 27 years plus - without a compelling reason.

The specification has the word "may" so it is not disallowed, but I think it would be risky.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2411640132

From serb at openjdk.org  Tue Oct  7 19:52:27 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Oct 2025 19:52:27 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
 <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
Message-ID: <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>

On Tue, 7 Oct 2025 19:14:59 GMT, Phil Race <prr at openjdk.org> wrote:

>The work and compatibility concerns to address these are out of all proportion to simply documenting what has been true since the very beginning - 27 years plus - without a compelling reason.

What compatibility impact? It has been throwing exceptions all this time, but currently it is allowed to work if we change that in the future,  unlike the current proposal, which describes all implementation details as part of the specification, making it much harder to change later.

Instead we can mention "maximum supported length" in the spec and in the "impl section" mention that currently it is the size of the array/maxint,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2411728510

From acobbs at openjdk.org  Tue Oct  7 20:03:25 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 7 Oct 2025 20:03:25 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v3]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <q_qI6DzbAbTICLbaW4FZkcey6WViuN-VizouO5n9oV0=.fb9b55bf-7717-4f77-b4de-de0473829edd@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 132 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Add clarifying comment.
 - Merge branch 'master' into JDK-8344159
 - Change inner class name to avoid shadowing superclass name.
 - Add a couple of code clarification comments.
 - Refactor test to avoid requiring changes to TestRunner.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - Add OPTIONS, PATH, and SUPPRESSION to the regression test.
 - ... and 122 more: https://git.openjdk.org/jdk/compare/910bb68e...3542625c

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=02
  Stats: 1659 lines in 34 files changed: 1486 ins; 49 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

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

From aivanov at openjdk.org  Tue Oct  7 20:16:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Oct 2025 20:16:45 GMT
Subject: RFR: 8365625: Can't change accelerator colors in Windows L&F [v3]
In-Reply-To: <X-K8Y3YsCUgVU5-ya3eLcj4G0CGUoMqP3LQwYedZCvE=.30e68acc-6a72-4038-a8ca-30b3e052b181@github.com>
References: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
 <X-K8Y3YsCUgVU5-ya3eLcj4G0CGUoMqP3LQwYedZCvE=.30e68acc-6a72-4038-a8ca-30b3e052b181@github.com>
Message-ID: <COrJugYIZS7qshxX9AItkino_-0JQe2mY5g6ZPZK6Sk=.6514e93c-25eb-483c-81ac-d7dc05cb317d@github.com>

On Tue, 16 Sep 2025 15:33:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> **Problem:**
>> 
>> The colors for the accelerators are cached in static fields: `disabledForeground`, `acceleratorSelectionForeground` and `acceleratorForeground`. As soon as this field is set to a non-`UIResource` value, the value cannot change.
>> 
>> **Fix:**
>> 
>> Remove the static fields for accelerator from `WindowsMenuItemUI` and use the fields inherited from `BasicMenuItemUI`, pass these fields as parameters to static methods.
>> 
>> Additionally, I formatted the calls to `WindowsMenuItemUI.paintMenuItem` in one consistent way.
>> 
>> I removed the redundant javadoc from `paintMenuItem` and added the missing `@Override` annotation.
>> 
>> I provided a regression test. The test also reproduces [JDK-8365375](https://bugs.openjdk.org/browse/JDK-8365375) that was resolved in #26743.
>
> Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update instructions to include the set of disabled menu items
>  - Add disabled menu items to verify for MenuItem.disabledForeground
>  - Merge master
>  - Merge master
>  - Align parameter list in WindowsMenuUI.paintMenuItem.
>  - Merge master
>    
>    Accepted the versions of
>     * WindowsCheckBoxMenuItemUI.java
>     * WindowsMenuItemUI.java
>     * WindowsMenuUI.java
>     * WindowsRadioButtonMenuItemUI.java
>    that existed in my branch.
>  - 8365625: Can't change accelerator colors in Windows L&F
>  - 8365389
>  - 8365389

Still no one?

Bump up with a new request for volunteers to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26826#issuecomment-3376272873

From prr at openjdk.org  Tue Oct  7 22:45:54 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Oct 2025 22:45:54 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
 <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
 <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>
Message-ID: <wMpTpnaJHLjU0uGkpJVezk7RzyOpHw00jEw4sjNuAwk=.b781b494-f0dd-47fc-963c-7d0ae8986b9e@github.com>

On Tue, 7 Oct 2025 19:49:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The work and compatibility concerns to address these are out of all proportion to simply documenting what has been true since the very beginning - 27 years plus - without a compelling reason.
> 
> What compatibility impact? 

That is in reponse to your suggestion to change the internal raster type. Not to a spec working change.

It has been throwing exceptions all this time, but currently it is allowed to work if we change that in the future, unlike the current proposal, which describes all implementation details as part of the specification, making it much harder to change later.

(1) No it allows leeway
(2) Even if it didn't we can relax it if there's ever a compelling enough reason - which I doubt we'll find.

> Instead we can mention "maximum supported length" in the spec and in the "impl section" mention that currently it is the size of the array/maxint,

I don't see how that is better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2412096298

From dnguyen at openjdk.org  Tue Oct  7 23:16:33 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 7 Oct 2025 23:16:33 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04 [v2]
In-Reply-To: <tuhM2ATYiClMieut8KYX01Orr6QJLTapyDFlv8DpF54=.7c0a317f-72f2-4cb3-bbce-9dad47c9688c@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
 <tuhM2ATYiClMieut8KYX01Orr6QJLTapyDFlv8DpF54=.7c0a317f-72f2-4cb3-bbce-9dad47c9688c@github.com>
Message-ID: <7hIExmSuJF8j-OXs0Sa8PtixUk_Y2bKCc-1UhSdnWeU=.8ac10826-4ad9-4b55-b048-996eebcf8063@github.com>

On Tue, 7 Oct 2025 10:53:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails to pick red color from JLabel in ubuntu24.04 even though it passes is ubuntu 22.04.
>> Seems like the red pixel from the font is not being picked up despite the fact that label foreground color actually is rendered in red.
>> 
>> It is seen in ubuntu 22.04 the font used for JLabel is "family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12"
>> while in ubuntu 24.04 the font used for JLabel is "family=Noto Sans,name=Noto Sans,style=plain,size=12"
>> 
>> I have made it consistent across version using same font and made it larger and bold and using such text for easier pickup of redpixel.
>> It passes in all platforms including ubuntu24.04
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use full block red char

Tested on both my 22.04 and 24.04 and it seems to be consistent to me now. LGTM.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27635#pullrequestreview-3312200732

From serb at openjdk.org  Tue Oct  7 23:19:08 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Oct 2025 23:19:08 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <wMpTpnaJHLjU0uGkpJVezk7RzyOpHw00jEw4sjNuAwk=.b781b494-f0dd-47fc-963c-7d0ae8986b9e@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
 <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
 <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>
 <wMpTpnaJHLjU0uGkpJVezk7RzyOpHw00jEw4sjNuAwk=.b781b494-f0dd-47fc-963c-7d0ae8986b9e@github.com>
Message-ID: <NePpLGkb2s4dS5QduAB1YxuN_r-aw7aXtj4R_cLdLa0=.a4acabec-c823-4133-a004-7b3312ba94f2@github.com>

On Tue, 7 Oct 2025 22:43:33 GMT, Phil Race <prr at openjdk.org> wrote:

>I don't see how that is better.

The specification will include a note about certain limitations, and under @implNote, we will describe the actual implementation-specific limitation. I believe that tag is appropriate in this context:

>"@implNote" ? Implementation Notes. This section contains informative notes about the implementation, such as advice for implementors or performance characteristics specific to this class in this version of the JDK. The information in this **section may change from release to release**. These characteristics may also vary across platforms, vendors, and JDK versions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2412138582

From serb at openjdk.org  Tue Oct  7 23:21:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Oct 2025 23:21:39 GMT
Subject: RFR: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04 [v2]
In-Reply-To: <tuhM2ATYiClMieut8KYX01Orr6QJLTapyDFlv8DpF54=.7c0a317f-72f2-4cb3-bbce-9dad47c9688c@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
 <tuhM2ATYiClMieut8KYX01Orr6QJLTapyDFlv8DpF54=.7c0a317f-72f2-4cb3-bbce-9dad47c9688c@github.com>
Message-ID: <d1go-mB6_zkyw7l-Mj3u5BtIF_CZixjnMlr8HtzffNo=.75f4a487-2bad-4569-952c-98dc968176d6@github.com>

On Tue, 7 Oct 2025 10:53:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails to pick red color from JLabel in ubuntu24.04 even though it passes is ubuntu 22.04.
>> Seems like the red pixel from the font is not being picked up despite the fact that label foreground color actually is rendered in red.
>> 
>> It is seen in ubuntu 22.04 the font used for JLabel is "family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12"
>> while in ubuntu 24.04 the font used for JLabel is "family=Noto Sans,name=Noto Sans,style=plain,size=12"
>> 
>> I have made it consistent across version using same font and made it larger and bold and using such text for easier pickup of redpixel.
>> It passes in all platforms including ubuntu24.04
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use full block red char

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27635#pullrequestreview-3312209735

From serb at openjdk.org  Tue Oct  7 23:23:24 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Oct 2025 23:23:24 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v4]
In-Reply-To: <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
 <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>
Message-ID: <zhjIDNXUpsomJv8akt37e1GlRoDly4hmtWJfNnPRVIk=.571ec1b5-2fe1-4080-a6a9-b60f64d0e773@github.com>

On Fri, 3 Oct 2025 19:35:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Updates the specification of Raster.createPackedRaster(..) methods and also the implementation of these to explicitly check the specified conditions rather than relying on them being passed up from some other API.
>> 
>> Also one each of the createInterleavedRaster(..) and createBandedRaster(..) methods have an update
>> 
>> createInterleavedRaster(...) to address that even if WxH does not exceed Integer.MAX_VALUE, the storage needed still might.
>> 
>> createBandedRaster(..) to address 
>> - a not explicitly specified or tested case that WxH must not overflow
>> - a not explicitly tested NPE case if bandMasks is null. This was relying on a de-reference and the actual check for it being null would have thrown the wrong exception type (AIOBE) - meaning not the one NPE actually specified and thrown.
>> There's an unfortunate oddity with this that of bankIndices is null it specifies and throws AIOBE, but I didn't think it worth changing either of these to make them consistent.
>> 
>> The existing CreateRasterExceptionTest.java is updated to verify all these assertions.
>> In almost all cases the behaviour is unchanged, it is just now properly specified and verified up front.
>> 
>> There are only 2 sub-tests which would fail on JDK 25
>> The test can also be run (and pass) there without this fix because it explicitly handles those 2 cases which are reasonable behavioral changes
>> - One for the  createInterleavedRaster() update where the unchecked case could end up causing a NegativeArraySizeException. This seems like a merited change.
>> - One for an unlikely case where if an app specified 0 app to createPackedRaster, divide by zero would happen.
>> 
>> The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8369131
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8369129

src/java.desktop/share/classes/java/awt/image/Raster.java line 271:

> 269:      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
> 270:      * @throws IllegalArgumentException if {@code w * pixelStride} is greater
> 271:      *         than {@code scanlineStride}

Is it still a valid point even for a single-line image, where scanlineStride would not be used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2412143515

From serb at openjdk.org  Tue Oct  7 23:26:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Oct 2025 23:26:39 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v9]
In-Reply-To: <zDhn0Od5usZkazHXLj7vSwv0STxN5-KFLjMYpQ9Bn8o=.b3bcbead-1afd-4b1e-8b30-3dd9bec7366f@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <i7VhKRjSOzLQuhWA31Dq03OpFM9i4KCcVVJvMV9nipU=.7dce1618-ca17-4a92-a10b-abf5b5b4c534@github.com>
 <zDhn0Od5usZkazHXLj7vSwv0STxN5-KFLjMYpQ9Bn8o=.b3bcbead-1afd-4b1e-8b30-3dd9bec7366f@github.com>
Message-ID: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com>

On Tue, 7 Oct 2025 01:27:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> @liach @mrserb When there is time, could I get a re-review on this after the changes?

Did you compare the behavior of the current implementation with the behavior in [Jemmy](https://github.com/openjdk/jdk/pull/26969#issuecomment-3300887917)

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

PR Comment: https://git.openjdk.org/jdk/pull/26969#issuecomment-3379020144

From liach at openjdk.org  Tue Oct  7 23:30:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 Oct 2025 23:30:51 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v9]
In-Reply-To: <i7VhKRjSOzLQuhWA31Dq03OpFM9i4KCcVVJvMV9nipU=.7dce1618-ca17-4a92-a10b-abf5b5b4c534@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <i7VhKRjSOzLQuhWA31Dq03OpFM9i4KCcVVJvMV9nipU=.7dce1618-ca17-4a92-a10b-abf5b5b4c534@github.com>
Message-ID: <pkEVHJzNKkDLhkAkgo9lrz-wIzyK5dgPE5EEttCKVoY=.93cb5ced-c97e-4be4-a6b5-51ffc3e43d7b@github.com>

On Thu, 25 Sep 2025 00:25:25 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove synchronized keyword

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

> 131:      * {@link #glide(int, int, int, int) glide},
> 132:      * {@link #type(int) type}, and
> 133:      * {@link #click(int) click}

Suggestion:

     * {@link #click(int) click}.

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

> 798:      * @throws  IllegalArgumentException if the {@code buttons} mask contains the mask for
> 799:      *          extra mouse button and support for extended mouse buttons is
> 800:      *          {@link Toolkit#areExtraMouseButtonsEnabled() disabled} by Java

Suggestion:

     *          {@linkplain Toolkit#areExtraMouseButtonsEnabled() disabled} by Java

`{@link}` renders in `{@code}` font.

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

> 801:      * @throws  IllegalArgumentException if the {@code buttons} mask contains the mask for
> 802:      *          extra mouse button that does not exist on the mouse and support for extended
> 803:      *          mouse buttons is {@link Toolkit#areExtraMouseButtonsEnabled() enabled}

Suggestion:

     *          mouse buttons is {@linkplain Toolkit#areExtraMouseButtonsEnabled() enabled}

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

> 986:      * A convenience method that simulates typing a char by calling {@code keyPress}
> 987:      * and {@code keyRelease}. Gets the ExtendedKeyCode for the char and calls
> 988:      * type(int keycode).

Suggestion:

     * {@link #type(int) type(int keycode)}.

Or
Suggestion:

     * {@code type(int keycode)}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2410968044
PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2410969799
PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2410970561
PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2412161667

From dnguyen at openjdk.org  Tue Oct  7 23:47:07 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 7 Oct 2025 23:47:07 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v2]
In-Reply-To: <IG6TH1wyrtaOn6I4PKSt1iMrcEpcU2_bc4EPf_H8TGM=.fd9962b2-f8d1-4c1e-9668-0ee12008c212@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
 <PY0HrglNfb2h03tpbM-pCkv-iYu3xuzGH92yPziRvQk=.3596b887-fd86-43f9-9671-6741575bc041@github.com>
 <IG6TH1wyrtaOn6I4PKSt1iMrcEpcU2_bc4EPf_H8TGM=.fd9962b2-f8d1-4c1e-9668-0ee12008c212@github.com>
Message-ID: <VqXMRZKBnw8uTaFepugSn3x0JFr6fhFPIjTB3XneluI=.36777d66-f6a3-4c09-83a9-c55842ae8f8c@github.com>

On Wed, 24 Sep 2025 22:53:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverse release order
>
> Have you tried disabling the global menu on macOS and testing the mnemonics when the menu is embedded into the frame? Does it work?

> May be try @mrserb suggestion by using System.setProperty("apple.laf.useScreenMenuBar", "false"); and verify if mnemonics work for embedded frame menu and not for JTabbedPane.

It does not seem to make a difference in my testing. The test still fails the same way. Did you add any other changes in your testing when it passed for you?

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

PR Comment: https://git.openjdk.org/jdk/pull/27371#issuecomment-3379050701

From prr at openjdk.org  Wed Oct  8 00:03:29 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Oct 2025 00:03:29 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v4]
In-Reply-To: <zhjIDNXUpsomJv8akt37e1GlRoDly4hmtWJfNnPRVIk=.571ec1b5-2fe1-4080-a6a9-b60f64d0e773@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
 <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>
 <zhjIDNXUpsomJv8akt37e1GlRoDly4hmtWJfNnPRVIk=.571ec1b5-2fe1-4080-a6a9-b60f64d0e773@github.com>
Message-ID: <H8DE31yab8IeJ3Ht6dEhpRKI07anTvvttZzE8U6HYUo=.6ccf15dc-c5fc-4697-9545-f453e4db66a4@github.com>

On Tue, 7 Oct 2025 23:20:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8369129
>
> src/java.desktop/share/classes/java/awt/image/Raster.java line 271:
> 
>> 269:      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
>> 270:      * @throws IllegalArgumentException if {@code w * pixelStride} is greater
>> 271:      *         than {@code scanlineStride}
> 
> Is it still a valid point even for a single-line image, where scanlineStride would not be used?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2412196875

From prr at openjdk.org  Wed Oct  8 00:02:35 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Oct 2025 00:02:35 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <NePpLGkb2s4dS5QduAB1YxuN_r-aw7aXtj4R_cLdLa0=.a4acabec-c823-4133-a004-7b3312ba94f2@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
 <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
 <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>
 <wMpTpnaJHLjU0uGkpJVezk7RzyOpHw00jEw4sjNuAwk=.b781b494-f0dd-47fc-963c-7d0ae8986b9e@github.com>
 <NePpLGkb2s4dS5QduAB1YxuN_r-aw7aXtj4R_cLdLa0=.a4acabec-c823-4133-a004-7b3312ba94f2@github.com>
Message-ID: <USEIFtwOrc2HFrPENJlA_IjHYNG5i_y6R2-nU6mu8VU=.782491fc-69e6-4759-87c7-4933e6299add@github.com>

On Tue, 7 Oct 2025 23:16:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > The work and compatibility concerns to address these are out of all proportion to simply documenting what has been true since the very beginning - 27 years plus - without a compelling reason.
>>> 
>>> What compatibility impact? 
>> 
>> That is in reponse to your suggestion to change the internal raster type. Not to a spec working change.
>> 
>> It has been throwing exceptions all this time, but currently it is allowed to work if we change that in the future, unlike the current proposal, which describes all implementation details as part of the specification, making it much harder to change later.
>> 
>> (1) No it allows leeway
>> (2) Even if it didn't we can relax it if there's ever a compelling enough reason - which I doubt we'll find.
>> 
>>> Instead we can mention "maximum supported length" in the spec and in the "impl section" mention that currently it is the size of the array/maxint,
>> 
>> I don't see how that is better.
>
>>I don't see how that is better.
> 
> The specification will include a note about certain limitations, and under @implNote, we will describe the actual implementation-specific limitation. I believe that tag is appropriate in this context:
> 
>>"@implNote" ? Implementation Notes. This section contains informative notes about the implementation, such as advice for implementors or performance characteristics specific to this class in this version of the JDK. The information in this **section may change from release to release**. These characteristics may also vary across platforms, vendors, and JDK versions.

It is a statement of fact. Not an implNote.
If someone used different storage the clause would still be accurate even if there were no actual examples of it left.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2412196131

From honkar at openjdk.org  Wed Oct  8 00:35:02 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 8 Oct 2025 00:35:02 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v2]
In-Reply-To: <VqXMRZKBnw8uTaFepugSn3x0JFr6fhFPIjTB3XneluI=.36777d66-f6a3-4c09-83a9-c55842ae8f8c@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
 <PY0HrglNfb2h03tpbM-pCkv-iYu3xuzGH92yPziRvQk=.3596b887-fd86-43f9-9671-6741575bc041@github.com>
 <IG6TH1wyrtaOn6I4PKSt1iMrcEpcU2_bc4EPf_H8TGM=.fd9962b2-f8d1-4c1e-9668-0ee12008c212@github.com>
 <VqXMRZKBnw8uTaFepugSn3x0JFr6fhFPIjTB3XneluI=.36777d66-f6a3-4c09-83a9-c55842ae8f8c@github.com>
Message-ID: <4tTWkP9T1EU0cXnCTXwSQskg7e5ivn9_j4Vv1UKGaZE=.64aeb027-d77b-4611-9b19-f2da3bc28f7d@github.com>

On Tue, 7 Oct 2025 23:44:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> It does not seem to make a difference in my testing. The test still fails the same way. Did you add any other changes in your testing when it passed for you?

I tested the Apple screen bar mnemonics on Finder and IntelliJ IDE application. They worked fine. 
What Sergey and I suggested to verify is adding menu bar to the Frame and then test it by setting the "apple.laf.useScreenMenuBar" to true and false to see if the mnemonics works in both cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/27371#issuecomment-3379146340

From serb at openjdk.org  Wed Oct  8 00:58:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Oct 2025 00:58:02 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <USEIFtwOrc2HFrPENJlA_IjHYNG5i_y6R2-nU6mu8VU=.782491fc-69e6-4759-87c7-4933e6299add@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
 <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
 <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>
 <wMpTpnaJHLjU0uGkpJVezk7RzyOpHw00jEw4sjNuAwk=.b781b494-f0dd-47fc-963c-7d0ae8986b9e@github.com>
 <NePpLGkb2s4dS5QduAB1YxuN_r-aw7aXtj4R_cLdLa0=.a4acabec-c823-4133-a004-7b3312ba94f2@github.com>
 <USEIFtwOrc2HFrPENJlA_IjHYNG5i_y6R2-nU6mu8VU=.782491fc-69e6-4759-87c7-4933e6299add@github.com>
Message-ID: <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@github.com>

On Wed, 8 Oct 2025 00:00:26 GMT, Phil Race <prr at openjdk.org> wrote:

>If someone used different storage the clause would still be accurate even if there were no actual examples of it left.

I still would like to clarify, how the next statement could be correct if another storage is in use?

> IllegalArgumentException if the multiplication product of
     *          {@code width}, {@code height}, and the number of samples per pixel
     *          for the specified format exceeds the maximum length of a Java array.

It is strictly required to throw this exception here and there, even if we will split the data across two arrays.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2412261516

From psadhukhan at openjdk.org  Wed Oct  8 03:03:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Oct 2025 03:03:39 GMT
Subject: Integrated: 8335646: Nimbus : JLabel not painted with LAF defined
 foreground color on Ubuntu 24.04
In-Reply-To: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
References: <oMTdIoRvEUnmTs8v9Vr9sqg7AsG567MS2fwzSLwpcMc=.c534b278-5d24-4c77-a499-0ba20c67c604@github.com>
Message-ID: <EsiUKZJhhDCHyAfvv7fTdoswSJy5DP0rYJ2vrbcG_dg=.07a09cc0-3470-4368-90ff-9953fca195b9@github.com>

On Sun, 5 Oct 2025 05:37:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails to pick red color from JLabel in ubuntu24.04 even though it passes is ubuntu 22.04.
> Seems like the red pixel from the font is not being picked up despite the fact that label foreground color actually is rendered in red.
> 
> It is seen in ubuntu 22.04 the font used for JLabel is "family=DejaVu Sans,name=DejaVu Sans,style=plain,size=12"
> while in ubuntu 24.04 the font used for JLabel is "family=Noto Sans,name=Noto Sans,style=plain,size=12"
> 
> I have made it consistent across version using same font and made it larger and bold and using such text for easier pickup of redpixel.
> It passes in all platforms including ubuntu24.04

This pull request has now been integrated.

Changeset: 650fd35b
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/650fd35b3b30bf16e8caad968bd335d423c87b7d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8335646: Nimbus : JLabel not painted with LAF defined foreground color on Ubuntu 24.04

Reviewed-by: aivanov, dnguyen, serb

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

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

From tr at openjdk.org  Wed Oct  8 03:25:16 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Oct 2025 03:25:16 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v4]
In-Reply-To: <L6DJ06ay7s6Rp9HXbQ1FbAOUYDC9s1TgBzTmYWYvGzE=.847236f4-88fa-40a4-8694-ea5e22a1506a@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
 <Yu2SK_bIjCuvYmhUQSA_53VJbuvN4UuYZq5tMefP2kw=.73adc4dc-f1ad-4039-950f-bfc02afad084@github.com>
 <jgt0eI7_exqJSEBAiyAQdNA0dnBgOKHqRldAduOkfdo=.8334283d-b3c1-4149-9d02-fe230a3480f7@github.com>
 <KzMF8D1GKgU-Z2ZxwETs9Zi4iFjLWj2OwIoUvx91TQ0=.ca590e78-64a5-4d5a-adfd-a94dfdb7bfdf@github.com>
 <51_8LtLfYKn8StwbKOTw3_AKyI9c3qCDwvHrbie9VZE=.2c46040e-6439-455a-81f4-437d25669282@github.com>
 <Irql74RktBY-6S7rvjBgsihs5z5DmBy1hkK_zrbWRKA=.937db58d-7177-4175-acf7-ac5c6b6366f5@github.com>
 <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
 <FrbMmTQ4IVhYQHYgaKOlBriCV8wzpOWZm2H5MyFL46g=.559af11c-1d7d-4893-8fba-a9c199a9c897@github.com>
 <L6DJ06ay7s6Rp9HXbQ1FbAOUYDC9s1TgBzTmYWYvGzE=.847236f4-88fa-40a4-8694-ea5e22a1506a@github.com>
Message-ID: <wlX_FfWWZZ8fYdn4qFGXbFsAkfNd69LLDU59Yb0MTKk=.40c1baa4-76ed-4710-bd70-bf43da71e9c2@github.com>

On Tue, 7 Oct 2025 16:44:39 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> > As @DamonGuy mentioned, a better way to deal with [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) could be closing it as _Cannot reproduce_ and submitting a new bug to update `FrameLocation.java` and remove `SizeMinimizedTest.java` from the problem list.
>>> 
>>> Probably I'll capture screenshot on failure and deproblemlist it. If I close the bug as _Cannot reproduce_ then it remains in problem listing, so better way is to de-problemlist it and add screen capture.
>> 
>> That's the point?you cannot reproduce the failure of `FrameLocation.java`, can you?
>> 
>> Thus, the correct resolution is *Cannot Reproduce*.
>> 
>> Adding a screenshot is not fixing the failure reported in [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915), it's an improvement for the test to have the more information to analyse the failure if it occurs again. This is why it's a new issue.
>> 
>> 8305915 has to be removed from the PL, submit a new bug, or rather create a subtask of JDK-8305915, to remove both `FrameLocation.java` and `SizeMinimizedTest.java` from the problem list.
>> 
>> I strongly believe this approach creates a clearer bug history in JBS and clearer changelog in the JDK. This also makes backporting easier as well as dealing with test failures in older releases.
>> 
>> Yes, submitting two new bugs creates more work but we're not in a rush here, and I think *it's worth the time*.
>> 
>> I can submit the bugs for you if you prefer so.
>
> @aivanov-jdk @DamonGuy I've raised https://github.com/openjdk/jdk/pull/27678 PR for de-problemlisting the main bug. Once this is integrated, I'll close the main bug as "Not-Reproducible".

> @TejeshR13 You can still use this PR to implement adding screenshots, just change the subject of the PR to associate it with the new bugid.

New bugid ? You want me to raise another JBS to handle adding screenshots ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27366#issuecomment-3379430004

From duke at openjdk.org  Wed Oct  8 03:48:18 2025
From: duke at openjdk.org (duke)
Date: Wed, 8 Oct 2025 03:48:18 GMT
Subject: Withdrawn: 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: <c5opBwdHoerPBjnL5DCsRJoZ3wDhY_CHIGAWE99hghY=.9652e0cc-0b02-4d81-afdb-2dd80f3f1d8c@github.com>

On Tue, 4 Feb 2025 00:07:48 GMT, Anass Baya <abaya 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.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Wed Oct  8 05:35:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Oct 2025 05:35:03 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v6]
In-Reply-To: <ujp81Aas3uUiBSkPnVzAnQjrrFtklVfLTgfGR-U9Bgk=.7727dbf1-ac77-4ca2-8624-e8d0deb57889@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <VfkYxVzz-zDjxiittV7tVJY1e5bsTasi-wDtfWF_WRw=.18ec5ad5-6927-4f4a-acfb-f0f327aa1758@github.com>
 <47CrFrW4wnR-o-T00QYFzwmLXagjv8kpnd_-FBg3p1A=.55c70c09-41b2-483f-9c05-c15809b8ab22@github.com>
 <ujp81Aas3uUiBSkPnVzAnQjrrFtklVfLTgfGR-U9Bgk=.7727dbf1-ac77-4ca2-8624-e8d0deb57889@github.com>
Message-ID: <3-q1CxszMw0vIuXjRUi_dXBcBQhTa6q-EAU4w52aANw=.70fcfd3d-34c6-4c55-ac1e-d86fc3de61b8@github.com>

On Tue, 7 Oct 2025 17:25:14 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java line 92:
>> 
>>> 90:         Toolkit.getDefaultToolkit().getSystemEventQueue().push(newEventQueue);
>>> 91: 
>>> 92:         for (UIManager.LookAndFeelInfo info :
>> 
>> UIManager import is missing
>
> Thanks; this is updated.

you can also dispose of the frame in try-finally block to be safe and consistent with headful regression tests
and you need to add @key headful to the jtreg tag

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27205#discussion_r2412548662

From psadhukhan at openjdk.org  Wed Oct  8 05:39:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Oct 2025 05:39:07 GMT
Subject: RFR: 8365625: Can't change accelerator colors in Windows L&F [v3]
In-Reply-To: <X-K8Y3YsCUgVU5-ya3eLcj4G0CGUoMqP3LQwYedZCvE=.30e68acc-6a72-4038-a8ca-30b3e052b181@github.com>
References: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
 <X-K8Y3YsCUgVU5-ya3eLcj4G0CGUoMqP3LQwYedZCvE=.30e68acc-6a72-4038-a8ca-30b3e052b181@github.com>
Message-ID: <b8B8ZYFUcJPaIYR_lW5xFrixWVbiMZdHPCftjj66k3Q=.cdbf5687-5c0c-4ca2-8689-31009bd5e4ce@github.com>

On Tue, 16 Sep 2025 15:33:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> **Problem:**
>> 
>> The colors for the accelerators are cached in static fields: `disabledForeground`, `acceleratorSelectionForeground` and `acceleratorForeground`. As soon as this field is set to a non-`UIResource` value, the value cannot change.
>> 
>> **Fix:**
>> 
>> Remove the static fields for accelerator from `WindowsMenuItemUI` and use the fields inherited from `BasicMenuItemUI`, pass these fields as parameters to static methods.
>> 
>> Additionally, I formatted the calls to `WindowsMenuItemUI.paintMenuItem` in one consistent way.
>> 
>> I removed the redundant javadoc from `paintMenuItem` and added the missing `@Override` annotation.
>> 
>> I provided a regression test. The test also reproduces [JDK-8365375](https://bugs.openjdk.org/browse/JDK-8365375) that was resolved in #26743.
>
> Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Update instructions to include the set of disabled menu items
>  - Add disabled menu items to verify for MenuItem.disabledForeground
>  - Merge master
>  - Merge master
>  - Align parameter list in WindowsMenuUI.paintMenuItem.
>  - Merge master
>    
>    Accepted the versions of
>     * WindowsCheckBoxMenuItemUI.java
>     * WindowsMenuItemUI.java
>     * WindowsMenuUI.java
>     * WindowsRadioButtonMenuItemUI.java
>    that existed in my branch.
>  - 8365625: Can't change accelerator colors in Windows L&F
>  - 8365389
>  - 8365389

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26826#pullrequestreview-3312905697

From jwood at openjdk.org  Wed Oct  8 05:47:33 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Wed, 8 Oct 2025 05:47:33 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v8]
In-Reply-To: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
Message-ID: <r7L6NPZlxDvSFRcLOA60J2tznFxkgG8UULvvcIjmJKE=.2bd01a4b-273e-4abd-bf5e-93673f739230@github.com>

> Previously:
> 
> If DesktopProperty#updateAllUIs threw an exception, we would never reset the update-pending property to false. This means any subsequent call to `updateUI()` would not attempt to call `updateAllUIs()`
> 
> With this change:
> Subsequent calls to DesktopProperty#updateUI() can still trigger at least one call to updateAllUIs().

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8367376: adding @key headful
   
   This is in response to the second point here:
   https://github.com/openjdk/jdk/pull/27205#discussion_r2412548662
 - 8367376: adding Frame.dispose() in try/finally
   
   This is in response to the first point here:
   https://github.com/openjdk/jdk/pull/27205#discussion_r2412548662

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27205/files
  - new: https://git.openjdk.org/jdk/pull/27205/files/d93815c9..39d4ad96

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

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

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

From jwood at openjdk.org  Wed Oct  8 05:47:34 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Wed, 8 Oct 2025 05:47:34 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v6]
In-Reply-To: <3-q1CxszMw0vIuXjRUi_dXBcBQhTa6q-EAU4w52aANw=.70fcfd3d-34c6-4c55-ac1e-d86fc3de61b8@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <VfkYxVzz-zDjxiittV7tVJY1e5bsTasi-wDtfWF_WRw=.18ec5ad5-6927-4f4a-acfb-f0f327aa1758@github.com>
 <47CrFrW4wnR-o-T00QYFzwmLXagjv8kpnd_-FBg3p1A=.55c70c09-41b2-483f-9c05-c15809b8ab22@github.com>
 <ujp81Aas3uUiBSkPnVzAnQjrrFtklVfLTgfGR-U9Bgk=.7727dbf1-ac77-4ca2-8624-e8d0deb57889@github.com>
 <3-q1CxszMw0vIuXjRUi_dXBcBQhTa6q-EAU4w52aANw=.70fcfd3d-34c6-4c55-ac1e-d86fc3de61b8@github.com>
Message-ID: <t4Vq09561eEiBrpCoRC-TzTDazQg1tZGjZ0BkMwAarg=.c98eb38a-c6fe-4a13-b668-fefaefa788f3@github.com>

On Wed, 8 Oct 2025 05:32:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Thanks; this is updated.
>
> you can also dispose of the frame in try-finally block to be safe and consistent with headful regression tests
> and you need to add @key headful to the jtreg tag

OK, this is updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27205#discussion_r2412566945

From psadhukhan at openjdk.org  Wed Oct  8 06:55:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Oct 2025 06:55:06 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v8]
In-Reply-To: <r7L6NPZlxDvSFRcLOA60J2tznFxkgG8UULvvcIjmJKE=.2bd01a4b-273e-4abd-bf5e-93673f739230@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <r7L6NPZlxDvSFRcLOA60J2tznFxkgG8UULvvcIjmJKE=.2bd01a4b-273e-4abd-bf5e-93673f739230@github.com>
Message-ID: <OzZJINPjKEDK6Wx49Lf-de3CD01037ewcTlnTHH96bc=.69c76ebb-767b-4314-b441-8b7da32df8f2@github.com>

On Wed, 8 Oct 2025 05:47:33 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> Previously:
>> 
>> If DesktopProperty#updateAllUIs threw an exception, we would never reset the update-pending property to false. This means any subsequent call to `updateUI()` would not attempt to call `updateAllUIs()`
>> 
>> With this change:
>> Subsequent calls to DesktopProperty#updateUI() can still trigger at least one call to updateAllUIs().
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8367376: adding @key headful
>    
>    This is in response to the second point here:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2412548662
>  - 8367376: adding Frame.dispose() in try/finally
>    
>    This is in response to the first point here:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2412548662

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27205#pullrequestreview-3313248731

From aivanov at openjdk.org  Wed Oct  8 10:40:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Oct 2025 10:40:19 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v8]
In-Reply-To: <r7L6NPZlxDvSFRcLOA60J2tznFxkgG8UULvvcIjmJKE=.2bd01a4b-273e-4abd-bf5e-93673f739230@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <r7L6NPZlxDvSFRcLOA60J2tznFxkgG8UULvvcIjmJKE=.2bd01a4b-273e-4abd-bf5e-93673f739230@github.com>
Message-ID: <ar0kseaGqwK_HGHMpvRceec6Rv-9rjTdFA2dplMzjug=.82aff3be-2084-4926-8000-e801d33e3485@github.com>

On Wed, 8 Oct 2025 05:47:33 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> Previously:
>> 
>> If DesktopProperty#updateAllUIs threw an exception, we would never reset the update-pending property to false. This means any subsequent call to `updateUI()` would not attempt to call `updateAllUIs()`
>> 
>> With this change:
>> Subsequent calls to DesktopProperty#updateUI() can still trigger at least one call to updateAllUIs().
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8367376: adding @key headful
>    
>    This is in response to the second point here:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2412548662
>  - 8367376: adding Frame.dispose() in try/finally
>    
>    This is in response to the first point here:
>    https://github.com/openjdk/jdk/pull/27205#discussion_r2412548662

Marked as reviewed by aivanov (Reviewer).

test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java line 31:

> 29:  * @run main DesktopPropertyResetPendingFlagTest
> 30:  * @key headful
> 31:  */

Suggestion:

/*
 * @test
 * @bug 8367376
 * @key headful
 * @summary DesktopProperty never reset pending status to process new updates
 * @modules java.desktop/sun.swing.plaf
 * @run main DesktopPropertyResetPendingFlagTest
 */

It doesn't really matter, yet usually `@key` comes after the `@bug` tag.

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

PR Review: https://git.openjdk.org/jdk/pull/27205#pullrequestreview-3314186501
PR Review Comment: https://git.openjdk.org/jdk/pull/27205#discussion_r2413408274

From aivanov at openjdk.org  Wed Oct  8 11:10:20 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Oct 2025 11:10:20 GMT
Subject: RFR: 8305915: java/awt/Frame/FrameLocation/FrameLocation.java
 fails with "The frame location is wrong!" [v4]
In-Reply-To: <wlX_FfWWZZ8fYdn4qFGXbFsAkfNd69LLDU59Yb0MTKk=.40c1baa4-76ed-4710-bd70-bf43da71e9c2@github.com>
References: <crdTgZR8efg6Cc2smoLgBYWT6ptDdmI7wYykWELn9WA=.7553cbfe-c573-4aed-a238-f18a9f552a8a@github.com>
 <Yu2SK_bIjCuvYmhUQSA_53VJbuvN4UuYZq5tMefP2kw=.73adc4dc-f1ad-4039-950f-bfc02afad084@github.com>
 <jgt0eI7_exqJSEBAiyAQdNA0dnBgOKHqRldAduOkfdo=.8334283d-b3c1-4149-9d02-fe230a3480f7@github.com>
 <KzMF8D1GKgU-Z2ZxwETs9Zi4iFjLWj2OwIoUvx91TQ0=.ca590e78-64a5-4d5a-adfd-a94dfdb7bfdf@github.com>
 <51_8LtLfYKn8StwbKOTw3_AKyI9c3qCDwvHrbie9VZE=.2c46040e-6439-455a-81f4-437d25669282@github.com>
 <Irql74RktBY-6S7rvjBgsihs5z5DmBy1hkK_zrbWRKA=.937db58d-7177-4175-acf7-ac5c6b6366f5@github.com>
 <nOXCPnxWPvDW-Mv2aeKLYhPwauRKen0T8aG6aLT8f6M=.f78d7d41-3d92-4d1f-9971-d7a41511e02f@github.com>
 <FrbMmTQ4IVhYQHYgaKOlBriCV8wzpOWZm2H5MyFL46g=.559af11c-1d7d-4893-8fba-a9c199a9c897@github.com>
 <L6DJ06ay7s6Rp9HXbQ1FbAOUYDC9s1TgBzTmYWYvGzE=.847236f4-88fa-40a4-8694-ea5e22a1506a@github.com>
 <wlX_FfWWZZ8fYdn4qFGXbFsAkfNd69LLDU59Yb0MTKk=.40c1baa4-76ed-4710-bd70-bf43da71e9c2@github.com>
Message-ID: <tReysQRU_avNRPcJkJs2NEqIpVDgpS9hrlmeDfAAJQU=.36dcc18b-5edd-45a7-890a-9e377ca7ecaf@github.com>

On Wed, 8 Oct 2025 03:22:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> > @TejeshR13 You can still use this PR to implement adding screenshots, just change the subject of the PR to associate it with the new bugid.
> 
> New bugid ? You want me to raise another JBS to handle adding screenshots ?

@TejeshR13 Yes, that's what I said.

> Adding a screenshot is not fixing the failure reported in [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915), it's an improvement for the test to have the more information to analyse the failure if it occurs again. **This is why it's a new issue.**

You'll close as *Cannot Reproduce* because no one can reproduce the failure any more. (I did run these two tests both off master and with reverted [JDK-8305825](https://bugs.openjdk.org/browse/JDK-8305825 "getBounds API returns wrong value resulting in multiple Regression Test Failures on Ubuntu 23.04") as @azvegint suggested; these two tests ? `FrameLocation.java` and `SizeMinimizedTest.java` ? passed in both jobs.)

Then you'll create a new bug to improve `FrameLocation.java` with adding a screenshot before disposing of the frame which will provide us with more date if the test fails again. Once the new bug id is available, you'll update the subject of this PR, and we'll be able to integrate the updated `FrameLocation.java` that takes a screenshot when it fails.

I'm not sure if `SizeMinimizedTest.java` will benefit from a screenshot, it may? I quickly looked at the test, and `iterationCnt` in `SizeMinimizedTest.java` is accessed and modified in a non-thread-safe way, which could also lead to test failures. I think this problem needs addressing, too? under a separate bugid.

If you like, I can submit both new bugs for you.

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

PR Comment: https://git.openjdk.org/jdk/pull/27366#issuecomment-3381004931