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

From kizune at openjdk.org  Wed Oct  8 15:35:36 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Oct 2025 15:35:36 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: <MorW_tIFAWPiYNf3QmQd2gs8uCKEKslLmkCBRN9ZieA=.dab85e1f-d5a8-473a-a606-0b852613bc85@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 kizune (Reviewer).

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

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

From jwood at openjdk.org  Wed Oct  8 16:34:28 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Wed, 8 Oct 2025 16:34:28 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v9]
In-Reply-To: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
Message-ID: <n1qXfKqwSf-vE11O6aD-gYKYgyY8lJDXRz9sLybb31E=.0f6f0b4f-0521-4a8c-bd50-2f248dfc92e7@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:

  Update test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27205/files
  - new: https://git.openjdk.org/jdk/pull/27205/files/39d4ad96..aa565ef3

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

  Stats: 2 lines in 1 file changed: 1 ins; 1 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 aivanov at openjdk.org  Wed Oct  8 16:46:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Oct 2025 16:46:54 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v9]
In-Reply-To: <n1qXfKqwSf-vE11O6aD-gYKYgyY8lJDXRz9sLybb31E=.0f6f0b4f-0521-4a8c-bd50-2f248dfc92e7@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <n1qXfKqwSf-vE11O6aD-gYKYgyY8lJDXRz9sLybb31E=.0f6f0b4f-0521-4a8c-bd50-2f248dfc92e7@github.com>
Message-ID: <W5CzONtVJu49zh0FA-Vz_aHf7Br2KKp0zvtKMvqMEX4=.0e4a9954-20d4-4383-8b09-3e87bf28470f@github.com>

On Wed, 8 Oct 2025 16:34:28 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 one additional commit since the last revision:
> 
>   Update test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27205#pullrequestreview-3315695970

From duke at openjdk.org  Wed Oct  8 16:56:32 2025
From: duke at openjdk.org (duke)
Date: Wed, 8 Oct 2025 16:56:32 GMT
Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating
 when system changes desktop properties [v9]
In-Reply-To: <n1qXfKqwSf-vE11O6aD-gYKYgyY8lJDXRz9sLybb31E=.0f6f0b4f-0521-4a8c-bd50-2f248dfc92e7@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
 <n1qXfKqwSf-vE11O6aD-gYKYgyY8lJDXRz9sLybb31E=.0f6f0b4f-0521-4a8c-bd50-2f248dfc92e7@github.com>
Message-ID: <P6iBK-06JogCXipsi2r3QzOcyateObn6CfFkl05aER4=.1fa2671e-2e4b-45fc-8ebc-aa9dd156d1cd@github.com>

On Wed, 8 Oct 2025 16:34:28 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 one additional commit since the last revision:
> 
>   Update test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27205#issuecomment-3382442158

From prr at openjdk.org  Wed Oct  8 22:11:16 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Oct 2025 22:11:16 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp with
 shear
Message-ID: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>

This fix does a couple of things

1) AffineTransformOp.createCompatibleDestImage() and AffineTransformOp.createCompatibleDestRaster() now specify that they will throw RasterFormatException if the transformed size is too large. They were already getting an exception.
Note that inside the JDK only the imaging API implementation itself uses these APIs and I suspect they are rarely used by applications.

2) AffineTransformOp.filter(src, null) will not throw an exception if it cannot create a destination image or raster of the required size and instead will use the source image size. This means applications which simply filter() will not need to carefully examine the transform. Sophisticated applications which want to do this can use the above "create*" methods to explicitly create the destination to find this out. 

So some inconsistency but I think it is a user-friendly trade-off.

A CSR will be needed but I want to get past initial review first.

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

Commit messages:
 - 4690476

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

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

From fandreuzzi at openjdk.org  Thu Oct  9 09:07:52 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 9 Oct 2025 09:07:52 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
Message-ID: <3djP8YakkpJzgFO-KqN4TaQIRbxCVdB-w88tVGQcuD4=.23de0a81-78dc-46cb-ab14-7cf57c534f13@github.com>

On Wed, 8 Oct 2025 22:05:05 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix does a couple of things
> 
> 1) AffineTransformOp.createCompatibleDestImage() and AffineTransformOp.createCompatibleDestRaster() now specify that they will throw RasterFormatException if the transformed size is too large. They were already getting an exception.
> Note that inside the JDK only the imaging API implementation itself uses these APIs and I suspect they are rarely used by applications.
> 
> 2) AffineTransformOp.filter(src, null) will not throw an exception if it cannot create a destination image or raster of the required size and instead will use the source image size. This means applications which simply filter() will not need to carefully examine the transform. Sophisticated applications which want to do this can use the above "create*" methods to explicitly create the destination to find this out. 
> 
> So some inconsistency but I think it is a user-friendly trade-off.
> 
> A CSR will be needed but I want to get past initial review first.

src/java.desktop/share/classes/java/awt/image/AffineTransformOp.java line 455:

> 453:             return createCompatibleDestImage(src, destCM, r);
> 454:         } catch (Exception e) {
> 455:              if (e instanceof RasterFormatException) {

How about two `catch` blocks? One catching `RasterFormatException` and a fallback to `Exception`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27707#discussion_r2416078369

From psadhukhan at openjdk.org  Thu Oct  9 09:45:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 9 Oct 2025 09:45:55 GMT
Subject: Integrated: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed
In-Reply-To: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
Message-ID: <ojznanhhI7Nse08uPyqjvovjRdAdDAGd47GjwLubTyY=.d304c2be-c75b-4d2d-b056-61f7aedbe273@github.com>

On Fri, 22 Aug 2025 03:53:13 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

This pull request has now been integrated.

Changeset: 285d16a3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/285d16a3a3b29b175670a042165780859a7dbc81
Stats:     43 lines in 2 files changed: 35 ins; 0 del; 8 mod

8365886: JSplitPane loses track of the left component when the component orientation is changed

Reviewed-by: tr, kizune

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

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

From aivanov at openjdk.org  Thu Oct  9 16:20:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Oct 2025 16:20:29 GMT
Subject: RFR: 8367772: Refactor createUI in PassFailJFrame
In-Reply-To: <ZEr5AH8lOD7rYEXcx_NTo8gqh-9djDXzr_rPI3m9UQc=.23d568e8-1a7b-4d40-b0af-7ab1ef3a4ed8@github.com>
References: <C3ofoSbW7YViR-H23YkuHMy0INN7Ue0zd_vwhaGzDWg=.59c3bd92-1c6b-4d5c-a6ce-68ae2b504623@github.com>
 <ZEr5AH8lOD7rYEXcx_NTo8gqh-9djDXzr_rPI3m9UQc=.23d568e8-1a7b-4d40-b0af-7ab1ef3a4ed8@github.com>
Message-ID: <nZqQdpUPmvqaZhJjjYBCnIoShrLx23F5YBovrW9W6ho=.af5c2c98-aa72-40ed-9110-849b96e2d252@github.com>

On Tue, 30 Sep 2025 21:04:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Code review https://git.openjdk.org/jdk/pull/27197 for [JDK-8367348](https://bugs.openjdk.org/browse/JDK-8367348) made me think how to avoid adding more parameters to methods, in particular `createInstructionUIPanel`. The `Builder` object captures all the required configuration data, it is the `Builder` object that should be used to pass the configuration.
>> 
>> This changeset refactors UI creation in `PassFailJFrame`.
>> 
>> * The remaining constructor that accepts positional parameters now creates a builder to pass the configuration data.
>> * The `createInstructionUIPanel` method now accepts `Builder` instead of a set of parameters from it.
>> * The `createUI` method with positional parameters has become redundant and is removed. Code duplication between two versions of `createUI` is now eliminated.
>> 
>> There are no functional differences. I verified it by launching a few tests which use `PassFailJFrame` constructors and builder.
>
> Marked as reviewed by dnguyen (Committer).

Thank you @DamonGuy.

I still need a *reviewer*.

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

PR Comment: https://git.openjdk.org/jdk/pull/27321#issuecomment-3386561747

From jwood at openjdk.org  Thu Oct  9 16:04:43 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Thu, 9 Oct 2025 16:04:43 GMT
Subject: Integrated: 8367376: Bad ButtonUI prevents other components from
 updating when system changes desktop properties
In-Reply-To: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
References: <eCl5de3vyDSmPOv4BrYJwq2PreLIPlbFfoN_HmuPW2Q=.0ce971d1-119c-4e98-a7df-70b25275c474@github.com>
Message-ID: <Q2adNDGj_wcUM3-HJ1-GWVulAotpXndRszjjrbA-AvE=.eb1ed5ff-5ed6-434e-af32-5f71907157e5@github.com>

On Wed, 10 Sep 2025 22:28:54 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().

This pull request has now been integrated.

Changeset: 7c75cb31
Author:    Jeremy Wood <jwood at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c75cb312c0f9c645a140e10df212e364b99ee42
Stats:     186 lines in 4 files changed: 177 ins; 0 del; 9 mod

8367376: Bad ButtonUI prevents other components from updating when system changes desktop properties

Reviewed-by: aivanov, prr, psadhukhan

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

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

From serb at openjdk.org  Thu Oct  9 18:32:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 9 Oct 2025 18:32:50 GMT
Subject: RFR: 8369327: On macOS List may loses selection when added to Frame
Message-ID: <T_H9WBYA5re1BrGDTvLnllaJd2Gh3u-q6uJ-3d1OKo8=.42fd43c2-e944-4ddb-85ca-b2eee42fab64@github.com>

The bug happens when List.select(int) is used in multiple selection mode. It only appears when the List is added to a Frame, because in that case, the selection is handled by the platform peer, and the internal logic in the List class is skipped.

To fix this, the code now uses [addSelectionInterval](https://github.com/openjdk/jdk/blob/910bb68e5191f830ff6f3dff5753e4e5f6214a7b/src/java.desktop/share/classes/javax/swing/ListSelectionModel.java#L93) instead of setSelectedIndex. This method works correctly for multiple selection mode when using JList as the delegate on macOS.

I added DeselectionUnitTest and SelectionUnitTest tests for some selection and deselection cases. At first, it was one big test, but I split it because it got too large.

**Notes on invalid index handling**
According to the java.awt.List [spec](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/java/awt/List.java#L573), using invalid indexes is undefined behavior. For now, I have decided not to validate these cases fully in this patch, but I did add a check in the `LWListPeer.select()` to handle them more safely.

The previously used setSelectedIndex method [ignored](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/javax/swing/JList.java#L2229) indexes greater than the list size, unlike addSelectionInterval. So I added an explicit check to skip all indexes larger than the list size.

Later, I discovered that passing a negative index not only causes an exception (which is acceptable, since it's undefined behavior), but also leaves the peer in an inconsistent state. This happens because setSkipStateChangedEvent(false) at the end of LWListPeer.select() is not called if an exception is thrown.

To prevent this, I added a check to skip all negative values as well. As a result, the peer now cleanly ignores all out-of-range indexes.

**Description of how invalid indexes are handled on other platforms:**
 - The shared code in java.awt.List stores elements and selection separately, so it accepts invalid indexes. This can cause exceptions if the selection and data become out of sync.
 - On Windows, all invalid indexes are ignored, except for the special value -1, which is used to select or deselect all elements. This happens because the indexes are passed to the win api without validation.
 - XAWT uses the same logic as the shared code, so it can throw the same exceptions if the data and selection are out of sync. (I have filed [JDK-8369455](https://bugs.openjdk.org/browse/JDK-8369455) to track this.)

There are other code paths that can trigger exceptions due to this undefined behavior. I can address those later. The main issue I am fixing in this patch is the broken multiple selection mode.

@prrace @aivanov-jdk please take a look

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

Commit messages:
 - Update ProblemList.txt
 - Update SelectInvalid.java
 - Validate "index >= 0 && index < model.getSize()"
 - Create SelectInvalid.java
 - 8369327: On macOS List may loses selection when added to Frame

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

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

From serb at openjdk.org  Thu Oct  9 18:32:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 9 Oct 2025 18:32:51 GMT
Subject: RFR: 8369327: On macOS List may loses selection when added to
 Frame
In-Reply-To: <T_H9WBYA5re1BrGDTvLnllaJd2Gh3u-q6uJ-3d1OKo8=.42fd43c2-e944-4ddb-85ca-b2eee42fab64@github.com>
References: <T_H9WBYA5re1BrGDTvLnllaJd2Gh3u-q6uJ-3d1OKo8=.42fd43c2-e944-4ddb-85ca-b2eee42fab64@github.com>
Message-ID: <gRFVzfAVMZDB-q6ExOgW4ecYmuzXyhvoH9fl_zHOBkg=.ddcebe53-1191-4fbc-b8c4-e4d67b9c91e4@github.com>

On Wed, 8 Oct 2025 01:20:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The bug happens when List.select(int) is used in multiple selection mode. It only appears when the List is added to a Frame, because in that case, the selection is handled by the platform peer, and the internal logic in the List class is skipped.
> 
> To fix this, the code now uses [addSelectionInterval](https://github.com/openjdk/jdk/blob/910bb68e5191f830ff6f3dff5753e4e5f6214a7b/src/java.desktop/share/classes/javax/swing/ListSelectionModel.java#L93) instead of setSelectedIndex. This method works correctly for multiple selection mode when using JList as the delegate on macOS.
> 
> I added DeselectionUnitTest and SelectionUnitTest tests for some selection and deselection cases. At first, it was one big test, but I split it because it got too large.
> 
> **Notes on invalid index handling**
> According to the java.awt.List [spec](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/java/awt/List.java#L573), using invalid indexes is undefined behavior. For now, I have decided not to validate these cases fully in this patch, but I did add a check in the `LWListPeer.select()` to handle them more safely.
> 
> The previously used setSelectedIndex method [ignored](https://github.com/openjdk/jdk/blob/0e5655e6680762a99b5aecb58369b880ea913565/src/java.desktop/share/classes/javax/swing/JList.java#L2229) indexes greater than the list size, unlike addSelectionInterval. So I added an explicit check to skip all indexes larger than the list size.
> 
> Later, I discovered that passing a negative index not only causes an exception (which is acceptable, since it's undefined behavior), but also leaves the peer in an inconsistent state. This happens because setSkipStateChangedEvent(false) at the end of LWListPeer.select() is not called if an exception is thrown.
> 
> To prevent this, I added a check to skip all negative values as well. As a result, the peer now cleanly ignores all out-of-range indexes.
> 
> **Description of how invalid indexes are handled on other platforms:**
>  - The shared code in java.awt.List stores elements and selection separately, so it accepts invalid indexes. This can cause exceptions if the selection and data become out of sync.
>  - On Windows, all invalid indexes are ignored, except for the special value -1, which is used to select or deselect all elements. This happens because the indexes are passed to the win api without validation.
>  - XAWT uses the same logic as the shared code, so it can throw the same exceptions if the data...

src/java.desktop/macosx/classes/sun/lwawt/LWListPeer.java line 150:

> 148:         }
> 149:     }
> 150: 

Note:
`getDelegate().getView().addSelectionInterval(index, index);`
`getDelegate().getView().removeSelectionInterval(index, index);`
just shortcuts for:
`getDelegate().getView().getSelectionModel().addSelectionInterval(index, index);`
`getDelegate().getView().getSelectionModel().removeSelectionInterval(index, index);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27682#discussion_r2412303830

From prr at openjdk.org  Thu Oct  9 18:51:44 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 9 Oct 2025 18:51:44 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <3djP8YakkpJzgFO-KqN4TaQIRbxCVdB-w88tVGQcuD4=.23de0a81-78dc-46cb-ab14-7cf57c534f13@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <3djP8YakkpJzgFO-KqN4TaQIRbxCVdB-w88tVGQcuD4=.23de0a81-78dc-46cb-ab14-7cf57c534f13@github.com>
Message-ID: <M3rMVvSvQYQ5WANhGyb9OI7DwSHHt1EIyg8mKTU5hsE=.f96c026b-1196-43bc-b4a6-d5bb7274e801@github.com>

On Thu, 9 Oct 2025 09:04:44 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> This fix does a couple of things
>> 
>> 1) AffineTransformOp.createCompatibleDestImage() and AffineTransformOp.createCompatibleDestRaster() now specify that they will throw RasterFormatException if the transformed size is too large. They were already getting an exception.
>> Note that inside the JDK only the imaging API implementation itself uses these APIs and I suspect they are rarely used by applications.
>> 
>> 2) AffineTransformOp.filter(src, null) will not throw an exception if it cannot create a destination image or raster of the required size and instead will use the source image size. This means applications which simply filter() will not need to carefully examine the transform. Sophisticated applications which want to do this can use the above "create*" methods to explicitly create the destination to find this out. 
>> 
>> So some inconsistency but I think it is a user-friendly trade-off.
>> 
>> A CSR will be needed but I want to get past initial review first.
>
> src/java.desktop/share/classes/java/awt/image/AffineTransformOp.java line 455:
> 
>> 453:             return createCompatibleDestImage(src, destCM, r);
>> 454:         } catch (Exception e) {
>> 455:              if (e instanceof RasterFormatException) {
> 
> How about two `catch` blocks? One catching `RasterFormatException` and a fallback to `Exception`.

That would be another way to code it, but the outcome is the same and I suspect this is marginally more efficient. And an exception should be extremely rare.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27707#discussion_r2417683585

From prr at openjdk.org  Thu Oct  9 18:52:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 9 Oct 2025 18:52:01 GMT
Subject: RFR: 8369516: Delete duplicate imaging test
Message-ID: <ZwWcb610M8q3WEKCBBighgLi0FaojzB880bSHvJ9lcY=.bf3d99d5-fecb-458e-8ec0-a84758d35be4@github.com>

Delete a duplicate test.

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

Commit messages:
 - 8369516

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

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

From honkar at openjdk.org  Fri Oct 10 00:23:11 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 10 Oct 2025 00:23:11 GMT
Subject: RFR: 8367772: Refactor createUI in PassFailJFrame
In-Reply-To: <nZqQdpUPmvqaZhJjjYBCnIoShrLx23F5YBovrW9W6ho=.af5c2c98-aa72-40ed-9110-849b96e2d252@github.com>
References: <C3ofoSbW7YViR-H23YkuHMy0INN7Ue0zd_vwhaGzDWg=.59c3bd92-1c6b-4d5c-a6ce-68ae2b504623@github.com>
 <ZEr5AH8lOD7rYEXcx_NTo8gqh-9djDXzr_rPI3m9UQc=.23d568e8-1a7b-4d40-b0af-7ab1ef3a4ed8@github.com>
 <nZqQdpUPmvqaZhJjjYBCnIoShrLx23F5YBovrW9W6ho=.af5c2c98-aa72-40ed-9110-849b96e2d252@github.com>
Message-ID: <QngAgceYftyEsyep4GGFk6NEIRFK9avyk9dTszIKm8Y=.54167795-687b-4402-b763-454d27841a96@github.com>

On Thu, 9 Oct 2025 16:18:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Marked as reviewed by dnguyen (Committer).
>
> Thank you @DamonGuy.
> 
> I still need a *reviewer*.

@aivanov-jdk Did I understand it correctly - this changeset prevents multiple parameters being sent to createInstructionUIPanel() by using the builder object but there are no changes to how PassFailJFrame is called in the tests ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27321#issuecomment-3387854124

From serb at openjdk.org  Fri Oct 10 03:20:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Oct 2025 03:20:03 GMT
Subject: RFR: 8369516: Delete duplicate imaging test
In-Reply-To: <ZwWcb610M8q3WEKCBBighgLi0FaojzB880bSHvJ9lcY=.bf3d99d5-fecb-458e-8ec0-a84758d35be4@github.com>
References: <ZwWcb610M8q3WEKCBBighgLi0FaojzB880bSHvJ9lcY=.bf3d99d5-fecb-458e-8ec0-a84758d35be4@github.com>
Message-ID: <Y9klJkSFQwUav3WbXSgt-nnqm_gWOrydPkdDZ9piatE=.c704d1c9-001d-48c9-87de-2e1ada60a740@github.com>

On Thu, 9 Oct 2025 18:44:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Delete a duplicate test.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27736#pullrequestreview-3321215776

From prr at openjdk.org  Fri Oct 10 04:33:11 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 10 Oct 2025 04:33:11 GMT
Subject: Integrated: 8369516: Delete duplicate imaging test
In-Reply-To: <ZwWcb610M8q3WEKCBBighgLi0FaojzB880bSHvJ9lcY=.bf3d99d5-fecb-458e-8ec0-a84758d35be4@github.com>
References: <ZwWcb610M8q3WEKCBBighgLi0FaojzB880bSHvJ9lcY=.bf3d99d5-fecb-458e-8ec0-a84758d35be4@github.com>
Message-ID: <tBlzrC0NP2aVxixUGM8-NWTCUWt3NJkqs79C7CUrkTc=.37740cf2-c0c2-4b8d-ac8b-b7e2b2b787bb@github.com>

On Thu, 9 Oct 2025 18:44:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Delete a duplicate test.

This pull request has now been integrated.

Changeset: 5a32966d
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a32966d4255131cf0ac1273b603d994829596e2
Stats:     484 lines in 1 file changed: 0 ins; 484 del; 0 mod

8369516: Delete duplicate imaging test

Reviewed-by: serb

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

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

From serb at openjdk.org  Fri Oct 10 05:24:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Oct 2025 05:24:03 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: <IT6uqJTsemyfNahSEAwq_BeBEkF0d_3yCeNoilzt7no=.096747a0-a132-400e-9067-63035b31dfc3@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 310:

> 308:             throw new IllegalArgumentException("size too large to store image");
> 309:         }
> 310:         int size = (int)lsz;

Isn't it strange that in this method we reject "empty" images by requiring w and h to be greater than 0, but at the same time accept 0 as scanlineStride and pixelStride? This may result in empty image as well (size == 0), I think it will be rejected later but still should we check it here as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2418526427

From aivanov at openjdk.org  Fri Oct 10 13:04:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Oct 2025 13:04:31 GMT
Subject: RFR: 8367772: Refactor createUI in PassFailJFrame
In-Reply-To: <nZqQdpUPmvqaZhJjjYBCnIoShrLx23F5YBovrW9W6ho=.af5c2c98-aa72-40ed-9110-849b96e2d252@github.com>
References: <C3ofoSbW7YViR-H23YkuHMy0INN7Ue0zd_vwhaGzDWg=.59c3bd92-1c6b-4d5c-a6ce-68ae2b504623@github.com>
 <ZEr5AH8lOD7rYEXcx_NTo8gqh-9djDXzr_rPI3m9UQc=.23d568e8-1a7b-4d40-b0af-7ab1ef3a4ed8@github.com>
 <nZqQdpUPmvqaZhJjjYBCnIoShrLx23F5YBovrW9W6ho=.af5c2c98-aa72-40ed-9110-849b96e2d252@github.com>
Message-ID: <7I7UD3BHc68o9PVNmcE7x-DSHJPIarDrQ8zpC31U7cY=.a399ef9b-f7e0-4d17-b917-ab481eacc743@github.com>

On Thu, 9 Oct 2025 16:18:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Marked as reviewed by dnguyen (Committer).
>
> Thank you @DamonGuy.
> 
> I still need a *reviewer*.

> @aivanov-jdk Did I understand it correctly - this changeset prevents multiple parameters being sent to createInstructionUIPanel() by using the builder object but there are no changes to how PassFailJFrame is called in the tests (even when using extra chaining such as .addHyperlinkListener()) ?

@honkar-jdk Exactly.

I stated in the description:

> There are no functional differences.

This changeset refactors and unifies the way parameters are passed *internally*.

If more parameters are added that are needed in `createUI` or `createInstructionUIPanel` to configure the presentation of instructions, there will be no need to add more positional parameters to `createUI` ? you will use the same `Builder` instance that has all the configuration parameters. Thus, all new options will be added to the `Builder` class only.

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

PR Comment: https://git.openjdk.org/jdk/pull/27321#issuecomment-3389956382

From honkar at openjdk.org  Fri Oct 10 16:50:44 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 10 Oct 2025 16:50:44 GMT
Subject: RFR: 8367772: Refactor createUI in PassFailJFrame
In-Reply-To: <C3ofoSbW7YViR-H23YkuHMy0INN7Ue0zd_vwhaGzDWg=.59c3bd92-1c6b-4d5c-a6ce-68ae2b504623@github.com>
References: <C3ofoSbW7YViR-H23YkuHMy0INN7Ue0zd_vwhaGzDWg=.59c3bd92-1c6b-4d5c-a6ce-68ae2b504623@github.com>
Message-ID: <ZvulZcNNsxxfJ-lf3geGL8rFwaw77No6q0Q6nRRzHmI=.efec9121-d93c-4883-95df-2f6900237043@github.com>

On Tue, 16 Sep 2025 19:23:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Code review https://git.openjdk.org/jdk/pull/27197 for [JDK-8367348](https://bugs.openjdk.org/browse/JDK-8367348) made me think how to avoid adding more parameters to methods, in particular `createInstructionUIPanel`. The `Builder` object captures all the required configuration data, it is the `Builder` object that should be used to pass the configuration.
> 
> This changeset refactors UI creation in `PassFailJFrame`.
> 
> * The remaining constructor that accepts positional parameters now creates a builder to pass the configuration data.
> * The `createInstructionUIPanel` method now accepts `Builder` instead of a set of parameters from it.
> * The `createUI` method with positional parameters has become redundant and is removed. Code duplication between two versions of `createUI` is now eliminated.
> 
> There are no functional differences. I verified it by launching a few tests which use `PassFailJFrame` constructors and builder.

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27321#pullrequestreview-3324755902

From philip.race at oracle.com  Fri Oct 10 19:04:08 2025
From: philip.race at oracle.com (Phil Race)
Date: Fri, 10 Oct 2025 12:04:08 -0700
Subject: HDR image support
In-Reply-To: <CAL4QsgsN8QqpwFVkaN+XOkNCsP05z_oFDXXR8Ha6Nyzs4Yt2BA@mail.gmail.com>
References: <CAL4QsgsN8QqpwFVkaN+XOkNCsP05z_oFDXXR8Ha6Nyzs4Yt2BA@mail.gmail.com>
Message-ID: <f8e0c31a-0f40-4876-a73b-5dd4d21b2b1b@oracle.com>

It is something we are aware of, but isn't something we are resourced to 
do, not even to look into it.

-phil.

On 10/6/2025 4:57, Liam Miller-Cushon wrote:
>
> 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/20251010/e3fe68b8/attachment.htm>

From prr at openjdk.org  Fri Oct 10 22:36:34 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 10 Oct 2025 22:36:34 GMT
Subject: RFR: 6185110: Undefined behaviour of SampleModel for width, height < 0
Message-ID: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>

The only significant change here is to ensure that all SampleModel types throw a specified exception if a client
calls any of the following methods with a negative width or height.
getPixels(..)
setPixels(..)
getSamples(..)
setSamples(..)

The rest is fixing the javadoc to properly describe what happens and some minor cleanup.
I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them.
I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method.
There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions
are not inherited. You need to explicitly re-add them.

I added a test which verifies the behaviour for illegal arguments.

There will be a CSR.

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

Commit messages:
 - 6185110

Changes: https://git.openjdk.org/jdk/pull/27754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6185110
  Stats: 815 lines in 6 files changed: 365 ins; 206 del; 244 mod
  Patch: https://git.openjdk.org/jdk/pull/27754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27754/head:pull/27754

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

From prr at openjdk.org  Sat Oct 11 05:23:46 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 11 Oct 2025 05:23:46 GMT
Subject: RFR: 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse Exception:
 Invalid or unrecognized bugid: 50510568367702
Message-ID: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>

I must have spaced out.

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

Commit messages:
 - 8369146

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

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

From syan at openjdk.org  Sat Oct 11 06:00:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 11 Oct 2025 06:00:03 GMT
Subject: RFR: 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse
 Exception: Invalid or unrecognized bugid: 50510568367702
In-Reply-To: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
References: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
Message-ID: <1qUKuVI5CLXEK7R_i7c37Cg5eCHGKy3YLPzKg4MuzvU=.ed2604c4-10ff-4343-b19a-09f49d8817ae@github.com>

On Sat, 11 Oct 2025 05:16:45 GMT, Phil Race <prr at openjdk.org> wrote:

> I must have spaced out.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27756#pullrequestreview-3326698974

From prr at openjdk.org  Sun Oct 12 04:18:06 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 12 Oct 2025 04:18:06 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@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>
 <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@github.com>
Message-ID: <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com>

On Wed, 8 Oct 2025 00:55:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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.
>
>>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.

Do you have a  conformant sample implementation that we could consider ?

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

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

From psadhukhan at openjdk.org  Sun Oct 12 13:36:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 12 Oct 2025 13:36:35 GMT
Subject: RFR: 8369251: Opensource few tests
Message-ID: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>

Opensourcing few tests

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

Commit messages:
 - 8369251: Opensource few tests
 - 8369251: Opensource few tests

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

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

From prr at openjdk.org  Sun Oct 12 18:29:32 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 12 Oct 2025 18:29:32 GMT
Subject: RFR: 8369335: Two  sun/java2d/OpenGL tests fail on Windows after
 JDK-8358058
Message-ID: <K2Bf4R6cB2OKlMpG1pXUkDzwVMHk_FUquiamO_6UtAk=.c2664215-b3c4-4494-a4c1-6677df255f10@github.com>

Update two tests which fail on Windows hi-dpi fractional scaling, when using OpenGL with some accelerated graphics.
Details in the JBS issue

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

Commit messages:
 - 8369335

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

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

From jdv at openjdk.org  Mon Oct 13 05:25:02 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 13 Oct 2025 05:25:02 GMT
Subject: RFR: 8369335: Two sun/java2d/OpenGL tests fail on Windows after
 JDK-8358058
In-Reply-To: <K2Bf4R6cB2OKlMpG1pXUkDzwVMHk_FUquiamO_6UtAk=.c2664215-b3c4-4494-a4c1-6677df255f10@github.com>
References: <K2Bf4R6cB2OKlMpG1pXUkDzwVMHk_FUquiamO_6UtAk=.c2664215-b3c4-4494-a4c1-6677df255f10@github.com>
Message-ID: <uOMvlNsNyH-uuA-Mg4v_UncU8mkwu9SJbfYYh3VDqXM=.4509cf2e-00f4-465a-9621-b84a5c3f85a1@github.com>

On Sun, 12 Oct 2025 18:23:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Update two tests which fail on Windows hi-dpi fractional scaling, when using OpenGL with some accelerated graphics.
> Details in the JBS issue

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27761#pullrequestreview-3329996475

From fandreuzzi at openjdk.org  Mon Oct 13 09:38:18 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 13 Oct 2025 09:38:18 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <M3rMVvSvQYQ5WANhGyb9OI7DwSHHt1EIyg8mKTU5hsE=.f96c026b-1196-43bc-b4a6-d5bb7274e801@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <3djP8YakkpJzgFO-KqN4TaQIRbxCVdB-w88tVGQcuD4=.23de0a81-78dc-46cb-ab14-7cf57c534f13@github.com>
 <M3rMVvSvQYQ5WANhGyb9OI7DwSHHt1EIyg8mKTU5hsE=.f96c026b-1196-43bc-b4a6-d5bb7274e801@github.com>
Message-ID: <WfSu2OoYwgXmfnUM3mAFR_IuFDphpqvh_qu-LUHxCT8=.659a6fbd-485e-4f75-b8fd-02f1778c74d7@github.com>

On Thu, 9 Oct 2025 18:48:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/image/AffineTransformOp.java line 455:
>> 
>>> 453:             return createCompatibleDestImage(src, destCM, r);
>>> 454:         } catch (Exception e) {
>>> 455:              if (e instanceof RasterFormatException) {
>> 
>> How about two `catch` blocks? One catching `RasterFormatException` and a fallback to `Exception`.
>
> That would be another way to code it, but the outcome is the same and I suspect this is marginally more efficient. And an exception should be extremely rare.

My comment was more about code style than performance, but thanks for checking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27707#discussion_r2425713976

From aivanov at openjdk.org  Mon Oct 13 12:13:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 13 Oct 2025 12:13:32 GMT
Subject: Integrated: 8367772: Refactor createUI in PassFailJFrame
In-Reply-To: <C3ofoSbW7YViR-H23YkuHMy0INN7Ue0zd_vwhaGzDWg=.59c3bd92-1c6b-4d5c-a6ce-68ae2b504623@github.com>
References: <C3ofoSbW7YViR-H23YkuHMy0INN7Ue0zd_vwhaGzDWg=.59c3bd92-1c6b-4d5c-a6ce-68ae2b504623@github.com>
Message-ID: <AoZQnUFZjHp4L2p5E9a73xfG5KrjRVVTYoMuTz82BjE=.f74c0580-9905-4590-93f8-654043d0604a@github.com>

On Tue, 16 Sep 2025 19:23:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Code review https://git.openjdk.org/jdk/pull/27197 for [JDK-8367348](https://bugs.openjdk.org/browse/JDK-8367348) made me think how to avoid adding more parameters to methods, in particular `createInstructionUIPanel`. The `Builder` object captures all the required configuration data, it is the `Builder` object that should be used to pass the configuration.
> 
> This changeset refactors UI creation in `PassFailJFrame`.
> 
> * The remaining constructor that accepts positional parameters now creates a builder to pass the configuration data.
> * The `createInstructionUIPanel` method now accepts `Builder` instead of a set of parameters from it.
> * The `createUI` method with positional parameters has become redundant and is removed. Code duplication between two versions of `createUI` is now eliminated.
> 
> There are no functional differences. I verified it by launching a few tests which use `PassFailJFrame` constructors and builder.

This pull request has now been integrated.

Changeset: d278043d
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d278043ddba0cd9ec3ddf8b490366965f5831a22
Stats:     55 lines in 1 file changed: 8 ins; 33 del; 14 mod

8367772: Refactor createUI in PassFailJFrame

Reviewed-by: dnguyen, honkar

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

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

From cushon at google.com  Mon Oct 13 12:19:35 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 13 Oct 2025 14:19:35 +0200
Subject: HDR image support
In-Reply-To: <f8e0c31a-0f40-4876-a73b-5dd4d21b2b1b@oracle.com>
References: <CAL4QsgsN8QqpwFVkaN+XOkNCsP05z_oFDXXR8Ha6Nyzs4Yt2BA@mail.gmail.com>
 <f8e0c31a-0f40-4876-a73b-5dd4d21b2b1b@oracle.com>
Message-ID: <CAL4Qsgsiao1zr9RCU9WW85yxHuoRMmhPvTuHYKnd2SnZH1vpHg@mail.gmail.com>

Understood, thanks for the response.

On Fri, Oct 10, 2025 at 9:05?PM Phil Race <philip.race at oracle.com> wrote:

> It is something we are aware of, but isn't something we are resourced to
> do, not even to look into it.
>
> -phil.
> On 10/6/2025 4:57, Liam Miller-Cushon wrote:
>
> 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/20251013/725cb167/attachment.htm>

From snazarki at openjdk.org  Mon Oct 13 15:09:20 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Mon, 13 Oct 2025 15:09:20 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v2]
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: <xkAYHiKR5lIkvl6y7Sm_fQcJ9v1Qj4mpUmsCSa7vi4s=.4ddcf801-21c5-4b68-a44b-f7b0107e8341@github.com>

> 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.

Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27551/files
  - new: https://git.openjdk.org/jdk/pull/27551/files/4d7042a3..7afddf8c

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

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

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

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

On Thu, 2 Oct 2025 13:10:21 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> 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.

A simplified test has been created; however, it still requires some environment setup and would not fail on non-US (and non-JP, KO, ZH) locales.

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

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

From snazarki at openjdk.org  Mon Oct 13 15:27:37 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Mon, 13 Oct 2025 15:27:37 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v2]
In-Reply-To: <xkAYHiKR5lIkvl6y7Sm_fQcJ9v1Qj4mpUmsCSa7vi4s=.4ddcf801-21c5-4b68-a44b-f7b0107e8341@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <xkAYHiKR5lIkvl6y7Sm_fQcJ9v1Qj4mpUmsCSa7vi4s=.4ddcf801-21c5-4b68-a44b-f7b0107e8341@github.com>
Message-ID: <Ataehrx1tH8u4WR3ocQd8-HiRRhOfXE0jzdxXRdapn8=.a85b8aba-1be2-4bb5-b98b-37a1325950d1@github.com>

On Mon, 13 Oct 2025 15:09:20 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

`eudc.reg` is UTF-16 encoded text file

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\EUDC\1252]
"SystemDefaultEUDCFont"="EUDC.TTE"


`EUDC.TTE` is just random generated file, created by `eudcedit.exe`

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3397979809

From duke at openjdk.org  Mon Oct 13 16:10:03 2025
From: duke at openjdk.org (Ravi-Patel8)
Date: Mon, 13 Oct 2025 16:10:03 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: <pJFpEXJdFI6WvxqyvJiVVxbNwEt-jdKXmKscMHdRZuA=.3f5580bf-1fa0-4bd1-b057-df60a0ebddae@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).

Hi @mrserb  / @honkar-jdk ,

The requested changes have been completed, and the PR has been approved. When you get a chance, could you please sponsor it?

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

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

From duke at openjdk.org  Mon Oct 13 16:14:33 2025
From: duke at openjdk.org (Ravi-Patel8)
Date: Mon, 13 Oct 2025 16:14:33 GMT
Subject: Integrated: 8368606: Printer lookup returns empty on AIX platform due
 to uninitialized results list
In-Reply-To: <Gl2qsEx-CSwy_K5r9OQY4ACN451eE_iobOW7l2qnS1Y=.3fc4fb33-0485-4e0f-b5fd-2be1ac467977@github.com>
References: <Gl2qsEx-CSwy_K5r9OQY4ACN451eE_iobOW7l2qnS1Y=.3fc4fb33-0485-4e0f-b5fd-2be1ac467977@github.com>
Message-ID: <nhz0J-W7djH0yUmeAtx_tTXgxqPmYU2pR_jUzfpO_Ko=.6cabcaae-a1e7-4974-b5fa-0b5c5da17a6c@github.com>

On Thu, 25 Sep 2025 07:09:37 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>

This pull request has now been integrated.

Changeset: 9b1633de
Author:    Ravi.Patel8 <Ravi.Patel8 at ibm.com>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b1633ded0e1d952ef13c054b6c507149d22f8cd
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8368606: Printer lookup returns empty on AIX platform due to uninitialized results list

Reviewed-by: honkar, serb

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

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

From lbourges at openjdk.org  Mon Oct 13 16:53:38 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 13 Oct 2025 16:53:38 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
Message-ID: <aGNPMDyGteIeABvJ96_ZWU5aRX8nMzRSqbWjcqDqiig=.d2441a9a-4123-4e46-8f2d-baaac9eb7b69@github.com>

On Sun, 5 Oct 2025 22:16:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - 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

Please review this fix...

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3398277799

From prr at openjdk.org  Mon Oct 13 18:01:17 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 13 Oct 2025 18:01:17 GMT
Subject: RFR: 8365077: java.awt.font.NumericShaper violates equals/hashCode
 contract
Message-ID: <qU_CK51GAimmcyZpFLtmkMZDlB24zUFZ84kNSNDuvbw=.1316d201-081a-449b-9b2d-d829bbc198a4@github.com>

The problem here is that NumericShaper can be constructed either using Range enum members
or a bitmask.
And the bitmask can represent the same (equal) NumericShaper as one constructed using
the equivalent Range enum members and "boolean equals(Object)" handles this and there
is support in the Range enum for a Set<Range> for this which is used by equals.

However the hashCode() does not have similar support and is quite different.
The fix adds support for this.
If the instance has a Set<Range> then use this new support, which will return
the same hash as if it was constructed using a mask. In cases where this is not
possible because Range instances  have no mask equivalent there is no issue
because these cannot be equal either.


EASTERN_ARABIC over-rides ARABIC and there was an inconsistency in that
when constructed with Ranges this ARABIC is removed but this isn't the case
for when constructed with masks. 
I had to fix that so that the hashes would be the same.

I also made one variable final that should have been final all along.
 
A test is provided.

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

Commit messages:
 - 8365077

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

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

From serb at openjdk.org  Mon Oct 13 19:18:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 13 Oct 2025 19:18:59 GMT
Subject: RFR: 8369618: Remove outdated reference to JDK 1.1 in the spec of
 BufferedImage.TYPE_INT_ARGB
Message-ID: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>

The reference to "JDK 1.1 and earlier releases" was removed from the BufferedImage.TYPE_INT_ARGB spec.

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

Commit messages:
 - 8369618: Remove outdated reference to JDK 1.1 in the spec of BufferedImage.TYPE_INT_ARGB

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

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

From aivanov at openjdk.org  Mon Oct 13 20:42:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 13 Oct 2025 20:42:04 GMT
Subject: RFR: 8225131: Test DragSourceMotionListenerTest.java fails on
 Windows [v3]
In-Reply-To: <71he7hvNoEec69wpPw6VnincSEcdcOcW-C322MByhE0=.54a0578e-041f-4caa-9b5a-4f3c149b101f@github.com>
References: <wnR56KVe_exCFKdIp7z59xLu0Ds3waCLLCNe4i-W3Xc=.077706f2-a790-4999-8875-5c6d38c408ed@github.com>
 <71he7hvNoEec69wpPw6VnincSEcdcOcW-C322MByhE0=.54a0578e-041f-4caa-9b5a-4f3c149b101f@github.com>
Message-ID: <45Tg5zXEAOXioVvw5sOAnIAjMwqFC03YN0-2TzXdDZE=.40a52f57-6814-4f0e-bd24-91139586ab95@github.com>

On Mon, 22 Sep 2025 04:02:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Test is failing frequently on mach5 machines. I have fixed it with stabilizations and moved the frame to center of the screen. After the fix several runs were made on mach5 and no failures were seen.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove blank space
>  - Revert indentations

What do we know about the test failure? Not much.

According to the bug report, the test fails with the message ?Failed first test.? This message means that the test didn't receive `dragMouseMoved` event that lies outside of the frame bounds.

https://github.com/openjdk/jdk/blob/1d6cafdc5244960ddec2fd82b8454c6c3cafe022/test/jdk/java/awt/dnd/DragSourceMotionListenerTest.java#L90-L94

I added traces to different parts of the test, and this is what I found out. The test stops receiving mouse events via `dragMouseMoved`:

<details><summary><b>Log of the <code>DragSourceMotionListenerTest.java</code> failure</b></summary>


-------
 srcPoint : java.awt.Point[x=107,y=130]
testPoint1: java.awt.Point[x=621,y=118]
testPoint2: java.awt.Point[x=307,y=130]
-------
Start dragging to java.awt.Point[x=621,y=118]
    107, 130
    108, 129
    109, 128
gestureListener -> startDrag
    110, 127
java.awt.Point[x=111,y=126]
    111, 126
    112, 125
        dragMouseMoved: 113, 124
    113, 124
        dragMouseMoved: 114, 123
...
    227, 118
        dragMouseMoved: 228, 118
    228, 118
    229, 118
...
    620, 118
Drag started? true
Move down
    621, 119
...
    621, 128
To drop target: java.awt.Point[x=307,y=130]
    621, 128
    620, 129
    619, 130
...
    309, 130
    308, 130
Release mouse
dragDropEnd: 228, 118


</details>

Thus, the last time the `dragMouseMoved` method was called with coordinates of (228, 118). It's the mouse coordinates that are reported by `dragDropEnd`.

Indeed, adding `robot.waitForIdle()` after dragging the mouse to `dstOutsidePoint` helps resolve the missing mouse events. Why aren't mouse drag events delivered?

This looks to me like a product bug rather than a test bug. Watching the test running, robot doesn't move the mouse too quickly, a user is capable of moving mouse quicker. Will the drag operation fail if the user moves the mouse pointer too quickly?

Additionally, I was able to make the test fail with this additional `robot.waitForIdle()`. In this case, the mouse events get delivered so that `passedTest1` is set to `true`. Yet while the mouse is dragged to `dstInsidePoint`, the `dragMouseMoved` stops being called.

<details><summary><b>Log of the <code>DragSourceMotionListenerTest.java</code> failure with only one <code>waitForIdle</code></b></summary>

...
    622, 119
passed1: 623 ~ 624
         dragMouseMoved: 623, 119
    623, 119
Drag started? true
<-- waitForIdle
...
To drop target: java.awt.Point[x=308,y=131]
passed1: 624 ~ 624
         dragMouseMoved: 624, 129
    624, 129
...
    354, 131
         dragMouseMoved: 353, 131
    353, 131
    352, 131
    351, 131
...
    310, 131
    309, 131
Release mouse
dragDropEnd: 353, 131
----------System.err:(11/653)----------
java.lang.RuntimeException: Failed second test.


</details>

Again, the mouse coordinates in `dragDropEnd` are exactly the ones in the latest call to `dragMouseMoved`: (353, 131).

Adding another `robot.waitForIdle()` after drag is complete but before release the mouse button makes the test stable; at least it has never failed for me in this configuration.

But why are so many `waitForIdle`s needed?

The should be stable as it is written now. The robot simulates the user's behaviour: press <kbd>Ctrl</kbd>, press the left mouse button and start dragging? outside of the app window and return back to the app window, then finally release the mouse button and <kbd>Ctrl</kbd>. Since this test fails, a real app may fail to register the drop at the correct coordinates.

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

PR Comment: https://git.openjdk.org/jdk/pull/27283#issuecomment-3398999965

From serb at openjdk.org  Mon Oct 13 21:41:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 13 Oct 2025 21:41:01 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@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>
 <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@github.com>
 <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com>
Message-ID: <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com>

On Sun, 12 Oct 2025 04:14:54 GMT, Phil Race <prr at openjdk.org> wrote:

> Do you have a conformant sample implementation that we could consider ?

We already have an implementation of BandedSampleModel and buffers that store color components in separate bands (different arrays). Similarly, we can implement a new subclass of ComponentSampleModel that stores "x lines of the image per bank". 
And it should be possible to reuse an existed api of buffers like: https://github.com/openjdk/jdk/blob/4ca4485e9af10a49ca95710c4e26aa3895835d47/src/java.desktop/share/classes/java/awt/image/DataBufferInt.java#L254

Initially these images will the slowest loops, but we can add some new here and there.

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

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

From honkar at openjdk.org  Mon Oct 13 22:01:35 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 13 Oct 2025 22:01:35 GMT
Subject: RFR: JDK-8365423 : [macos26] java/awt/MenuBar/8007006/bug8007006.java
 fails on macOS 26
Message-ID: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>

Test fails on the macOS 26 because test uses hardcoded location of menu item to click, but on macOS 26 the menu bar is taller and robot misses the menu item by couple of pixels. 

Fix : Screen insets is used to get the y location of menu item Instead of using hardcoded value. 

Additionally test has been cleaned up and frames moved to the center of screen to avoid menubar interactions.

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

Commit messages:
 - macOS26 test fix

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

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

From prr at openjdk.org  Mon Oct 13 22:22:00 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 13 Oct 2025 22:22:00 GMT
Subject: RFR: JDK-8365423 :  [macos26]
 java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26
In-Reply-To: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
References: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
Message-ID: <xL7_Vii7usAWBo92eJ-IkV_hDHMnOeAnxMU-Azk0Skk=.ed1e2d07-0464-4c1e-886d-cd3f980b8114@github.com>

On Mon, 13 Oct 2025 21:54:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Test fails on the macOS 26 because test uses hardcoded location of menu item to click, but on macOS 26 the menu bar is taller and robot misses the menu item by couple of pixels. 
> 
> Fix : Screen insets is used to get the y location of menu item Instead of using hardcoded value. 
> 
> Additionally test has been cleaned up and frames moved to the center of screen to avoid menubar interactions.

And this passes on older macOS versions ? And on retina as well as an external monitor?

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

PR Comment: https://git.openjdk.org/jdk/pull/27776#issuecomment-3399229199

From honkar at openjdk.org  Tue Oct 14 00:36:05 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 14 Oct 2025 00:36:05 GMT
Subject: RFR: JDK-8365423 :  [macos26]
 java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26
In-Reply-To: <xL7_Vii7usAWBo92eJ-IkV_hDHMnOeAnxMU-Azk0Skk=.ed1e2d07-0464-4c1e-886d-cd3f980b8114@github.com>
References: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
 <xL7_Vii7usAWBo92eJ-IkV_hDHMnOeAnxMU-Azk0Skk=.ed1e2d07-0464-4c1e-886d-cd3f980b8114@github.com>
Message-ID: <XOei0BSZzKfdmAC3B8hstZZQDfm7AjCuHQRf-RltrOQ=.9e3520f5-f898-4a7d-b9b0-4ce5eba7e685@github.com>

On Mon, 13 Oct 2025 22:19:28 GMT, Phil Race <prr at openjdk.org> wrote:

> And this passes on older macOS versions ? And on retina as well as an external monitor?

CI Testing looks good on different macOS version (link added to JBS).
Testing on my local (macOS 15.7.1) both on retina and external monitor looks good as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/27776#issuecomment-3399528889

From kizune at openjdk.org  Tue Oct 14 00:59:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 14 Oct 2025 00:59:11 GMT
Subject: RFR: JDK-8365423 :  [macos26]
 java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26
In-Reply-To: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
References: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
Message-ID: <SUSgkhFlPGeHxM9IjpaI7Z3RWtksFz4nkw_QUJUsOzo=.bdd9b363-a0a8-4116-82be-d968f3691957@github.com>

On Mon, 13 Oct 2025 21:54:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Test fails on the macOS 26 because test uses hardcoded location of menu item to click, but on macOS 26 the menu bar is taller and robot misses the menu item by couple of pixels. 
> 
> Fix : Screen insets is used to get the y location of menu item Instead of using hardcoded value. 
> 
> Additionally test has been cleaned up and frames moved to the center of screen to avoid menubar interactions.

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27776#pullrequestreview-3333531452

From prr at openjdk.org  Tue Oct 14 03:35:39 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 03:35:39 GMT
Subject: RFR: 4954405: Data buffers created with an offset are unusable
Message-ID: <VKT61MUnXijF380GXqIIWlZb_XBEELsMI95TGmgu-C4=.7a803f2a-6f47-44b1-b23e-e91c08a3f027@github.com>

ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements
The super-class sets it in the constructor which runs very much like this subclass except it omits this.
The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset
to adjust dataOffsets values used in all calculations.

Instead ByteInterleavedRaster  does something a bit different than other classes where it includes it in some instance vars
that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements.

It looks to me as if this is what ByteInterleavedRaster should also do instead.
All existing tests pass, and this resolves the specific complaint in the bug report.

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

Commit messages:
 - 4954405

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

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

From prr at openjdk.org  Tue Oct 14 03:36:15 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 03:36:15 GMT
Subject: Integrated: 8369335: Two  sun/java2d/OpenGL tests fail on Windows
 after JDK-8358058
In-Reply-To: <K2Bf4R6cB2OKlMpG1pXUkDzwVMHk_FUquiamO_6UtAk=.c2664215-b3c4-4494-a4c1-6677df255f10@github.com>
References: <K2Bf4R6cB2OKlMpG1pXUkDzwVMHk_FUquiamO_6UtAk=.c2664215-b3c4-4494-a4c1-6677df255f10@github.com>
Message-ID: <YILAYf2iO31Q8yT5HpKLXLe9S08MysiTgFXjTzrv8No=.8ad347a9-fa70-4fc0-a70c-5ddf9e04a827@github.com>

On Sun, 12 Oct 2025 18:23:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Update two tests which fail on Windows hi-dpi fractional scaling, when using OpenGL with some accelerated graphics.
> Details in the JBS issue

This pull request has now been integrated.

Changeset: d6ca382f
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6ca382f4ee5793dfa191bba694a7fef88c591fc
Stats:     38 lines in 2 files changed: 18 ins; 0 del; 20 mod

8369335: Two  sun/java2d/OpenGL tests fail on Windows after JDK-8358058

Reviewed-by: jdv

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

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

From prr at openjdk.org  Tue Oct 14 03:39:01 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 03:39:01 GMT
Subject: RFR: JDK-8365423 :  [macos26]
 java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26
In-Reply-To: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
References: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
Message-ID: <IW7j5Wki0962m1ykaQnrW428uEMVTyuQy404MjrJe3E=.16082fc8-ce3e-4f95-bde3-e8299a911861@github.com>

On Mon, 13 Oct 2025 21:54:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Test fails on the macOS 26 because test uses hardcoded location of menu item to click, but on macOS 26 the menu bar is taller and robot misses the menu item by couple of pixels. 
> 
> Fix : Screen insets is used to get the y location of menu item Instead of using hardcoded value. 
> 
> Additionally test has been cleaned up and frames moved to the center of screen to avoid menubar interactions.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27776#pullrequestreview-3333777891

From prr at openjdk.org  Tue Oct 14 04:33:44 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 04:33:44 GMT
Subject: RFR: 8364673: Remove duplicate font mapping for itcavantgarde in
 psfontj2d.properties
Message-ID: <MXlxEylx7cLHssTKpVIt23Uacgwb8JoEMV-gagNTN5E=.fa258c8c-2285-43a7-a241-9e0d6c98bc5d@github.com>

I've spent some time trying to think if one of these was supposed to be something else, but it looks like a dup.

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

Commit messages:
 - 8364673

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

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

From prr at openjdk.org  Tue Oct 14 05:32:18 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 05:32:18 GMT
Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB
 conversion
Message-ID: <uGPIYHkjIbxRmh5RmDbz2x9-tU9CVRoQ7f9o3-l7jrc=.c40b12ce-297a-4198-b966-041866ad4cbf@github.com>

color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short.
More details in JBS.

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

Commit messages:
 - 8364583

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

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

From snazarki at openjdk.org  Tue Oct 14 08:58:24 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Tue, 14 Oct 2025 08:58:24 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v3]
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: <2-0rVj4i6A0ndg96LExAn8UD6Wn_EXfYeIbDW45o55A=.2e6316e1-7398-4808-95ee-9579079faf8f@github.com>

> 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.

Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:

  Add EUDC.tte restoration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27551/files
  - new: https://git.openjdk.org/jdk/pull/27551/files/7afddf8c..08e62316

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

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

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

From abaya at openjdk.org  Tue Oct 14 14:02:43 2025
From: abaya at openjdk.org (Anass Baya)
Date: Tue, 14 Oct 2025 14:02:43 GMT
Subject: RFR: 8357390 : java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java
 Test failing on Ubuntu 24.04 SBR Hosts
Message-ID: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>

**Issue:**
The bottom inset is different from the expected value by 2 pixels.

**Analysis:**
In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 

But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.

When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:

> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 

However, it should be:
 
> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 

Wich is the output of the command when the issue doest not occur.

after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 

**Proposed Fix:**
Increase the allowed margin to 2 pixels.

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

Commit messages:
 - add bug ID
 - Increase margin tolerance to 3 pixel

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

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

From honkar at openjdk.org  Tue Oct 14 14:02:43 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 14 Oct 2025 14:02:43 GMT
Subject: RFR: 8357390 :
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 SBR Hosts
In-Reply-To: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
Message-ID: <9s1KDh3FVnS36lccH_GAdotAO5vFhs6zfdZqMYP9TJU=.9b639ffe-f91b-4006-a1a1-c9d041f51e11@github.com>

On Thu, 29 May 2025 14:53:51 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Issue:**
> The bottom inset is different from the expected value by 2 pixels.
> 
> **Analysis:**
> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
> 
> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
> 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
> 
> However, it should be:
>  
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
> 
> Wich is the output of the command when the issue doest not occur.
> 
> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
> 
> **Proposed Fix:**
> Increase the allowed margin to 2 pixels.

@anass-baya Couple of things regarding this PR:

- There is a title mismatch please remove the prefix "Draft:" so that jcheck passes and rfr label is added to PR.

- I wasn't able to get it to fail on Ubuntu 24.04, is fractional scaling setting enabled on SBR nodes ? Although even with fractional scale enabled I wasn't able to replicate the issue with different uiScales (1, 1.25, 1.5, 2)

- Can you please add test logs from the node it is failing on?

- Headsup: RDP1 for jdk25 is on 5th June, 2025. In case you are planning to add this fix to 25 then it requires to be approved and integrated before the fork.

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

PR Review: https://git.openjdk.org/jdk/pull/25521#pullrequestreview-2893594494

From abaya at openjdk.org  Tue Oct 14 14:02:44 2025
From: abaya at openjdk.org (Anass Baya)
Date: Tue, 14 Oct 2025 14:02:44 GMT
Subject: RFR: 8357390 :
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 SBR Hosts
In-Reply-To: <9s1KDh3FVnS36lccH_GAdotAO5vFhs6zfdZqMYP9TJU=.9b639ffe-f91b-4006-a1a1-c9d041f51e11@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <9s1KDh3FVnS36lccH_GAdotAO5vFhs6zfdZqMYP9TJU=.9b639ffe-f91b-4006-a1a1-c9d041f51e11@github.com>
Message-ID: <h0T3_sSCEh5mY8_AlfAZied3Gvb14NrUk18j21rEFig=.1aeaf4ad-4a92-48c4-b855-59929fdfd418@github.com>

On Tue, 3 Jun 2025 18:17:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> **Issue:**
>> The bottom inset is different from the expected value by 2 pixels.
>> 
>> **Analysis:**
>> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
>> 
>> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
>> 
>> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
>> 
>>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
>> 
>> However, it should be:
>>  
>>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
>> 
>> Wich is the output of the command when the issue doest not occur.
>> 
>> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
>> 
>> **Proposed Fix:**
>> Increase the allowed margin to 2 pixels.
>
> @anass-baya Couple of things regarding this PR:
> 
> - There is a title mismatch please remove the prefix "Draft:" so that jcheck passes and rfr label is added to PR.
> 
> - I wasn't able to get it to fail on Ubuntu 24.04, is fractional scaling setting enabled on SBR nodes ? Although even with fractional scale enabled I wasn't able to replicate the issue with different uiScales (1, 1.25, 1.5, 2)
> 
> - Can you please add test logs from the node it is failing on?
> 
> - Headsup: RDP1 for jdk25 is on 5th June, 2025. In case you are planning to add this fix to 25 then it requires to be approved and integrated before the fork.

Hello @honkar-jdk,

> There is a title mismatch please remove the prefix "Draft:" so that jcheck passes and rfr label is added to PR.

I?ve converted it to a draft to investigate further, as Alexey suggested.

> I wasn't able to get it to fail on Ubuntu 24.04, is fractional scaling setting enabled on SBR nodes ? Although even with fractional scale enabled I wasn't able to replicate the issue with different uiScales (1, 1.25, 1.5, 2)

The failure only occurs on Ubuntu SBR nodes, so I'm trying to take a screenshot to see what's going on there. 
Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-2936650908

From prr at openjdk.org  Tue Oct 14 16:04:08 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 16:04:08 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 SBR Hosts
In-Reply-To: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
Message-ID: <mZBc4eFx-tvjSd8VyoercLrEPMP4fI92M89_jfwDSF0=.1ea82bc2-6d98-487e-89db-b98c90ceb9e7@github.com>

On Thu, 29 May 2025 14:53:51 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Issue:**
> The bottom inset is different from the expected value by 2 pixels.
> 
> **Analysis:**
> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
> 
> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
> 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
> 
> However, it should be:
>  
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
> 
> Wich is the output of the command when the issue doest not occur.
> 
> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
> 
> **Proposed Fix:**
> Increase the allowed margin to 2 pixels.

"The failure only occurs on Ubuntu SBR nodes"

That's a bit of a cryptic internal term to be using in a github PR.
It might be better explained as "on a Linux VM used by Oracle's internal CI system"

I don't think any of these are likely to be configured with "fractional scaling" and it is unlikely to be related.
Also we don't support fractional scaling on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3402604980

From prr at openjdk.org  Tue Oct 14 16:20:46 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 16:20:46 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@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>
 <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@github.com>
 <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com>
 <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com>
Message-ID: <N3Nmz5i24w3sym5e-1U_uISBNFG3RPfjq7QtITrc7mM=.0d2f3a96-5636-4262-9379-7ede1f578ac9@github.com>

On Mon, 13 Oct 2025 21:38:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Do you have a  conformant sample implementation that we could consider ?
>
>> Do you have a conformant sample implementation that we could consider ?
> 
> We already have an implementation of BandedSampleModel and buffers that store color components in separate bands (different arrays). Similarly, we can implement a new subclass of ComponentSampleModel that stores "x lines of the image per bank". 
> And it should be possible to reuse an existed api of buffers like: https://github.com/openjdk/jdk/blob/4ca4485e9af10a49ca95710c4e26aa3895835d47/src/java.desktop/share/classes/java/awt/image/DataBufferInt.java#L254
> 
> Initially these images will the slowest loops, but we can add some new here and there.

BandedSampleModel is not precluded by the current proposed wording, in fact it is explicitly accommodated.

The spec. for BandedSampleModel has this as its first sentence :
This class represents image data which is stored in a band interleaved fashion and for which each sample of a pixel occupies one data element of the DataBuffer

I had actually thought already about the way you suggest with splitting an image so that different parts of it
are in different data buffers. But that seems nearly impossible. There's too many things in the spec. and
implementation that would need revisision. I see no value in diluting the wording to allow an impossibility.
If we ever did that (unlikely) then revising these few words in the spec. would be an insignificant part of it.

Essentially the proposed spec is saying is "array length imposes a hard limit".

So I do not see any problem with the spec as proposed.

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

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

From honkar at openjdk.org  Tue Oct 14 16:34:56 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 14 Oct 2025 16:34:56 GMT
Subject: Integrated: JDK-8365423 :  [macos26]
 java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26
In-Reply-To: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
References: <FS7jXwbfYi5HzMyTAklmqbhrP-jEW4sGLU5xczN2dw0=.a3945354-b1b9-4d83-87f8-2fcc4a9634d1@github.com>
Message-ID: <dyA-DChddhM2mh534ssepKvl4wHqfwA4dXj6vDi_flg=.fc30fb09-c702-435c-b0ad-4459fa562864@github.com>

On Mon, 13 Oct 2025 21:54:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Test fails on the macOS 26 because test uses hardcoded location of menu item to click, but on macOS 26 the menu bar is taller and robot misses the menu item by couple of pixels. 
> 
> Fix : Screen insets is used to get the y location of menu item Instead of using hardcoded value. 
> 
> Additionally test has been cleaned up and frames moved to the center of screen to avoid menubar interactions.

This pull request has now been integrated.

Changeset: bbbb9c5f
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbbb9c5f1557cb1e80d72a820c034c71308cb3a2
Stats:     100 lines in 1 file changed: 37 ins; 27 del; 36 mod

8365423: [macos26] java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26

Reviewed-by: kizune, prr

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

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

From prr at openjdk.org  Tue Oct 14 17:27:06 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 17:27:06 GMT
Subject: RFR: 8344918: Unused private variables in SwingUtilities.java
Message-ID: <Ghd5rQNsTJA41L1H6JW8McpVaSZKDsaIVmeuC8c9wNM=.480109d1-76d7-47a0-a9ab-eb29b3f0ebc5@github.com>

Clean up of vars that are un-used.

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

Commit messages:
 - 8344918

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

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

From azvegint at openjdk.org  Tue Oct 14 17:31:37 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 14 Oct 2025 17:31:37 GMT
Subject: RFR: 8344918: Unused private variables in SwingUtilities.java
In-Reply-To: <Ghd5rQNsTJA41L1H6JW8McpVaSZKDsaIVmeuC8c9wNM=.480109d1-76d7-47a0-a9ab-eb29b3f0ebc5@github.com>
References: <Ghd5rQNsTJA41L1H6JW8McpVaSZKDsaIVmeuC8c9wNM=.480109d1-76d7-47a0-a9ab-eb29b3f0ebc5@github.com>
Message-ID: <XU0rAUmBtngS6EOIobwfpUvAoQOekKDtha8vfINFp8c=.1dc44b7c-e5e9-49c8-94c9-f8130e293469@github.com>

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

> Clean up of vars that are un-used.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27804#pullrequestreview-3336764272

From prr at openjdk.org  Tue Oct 14 17:40:01 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 17:40:01 GMT
Subject: Integrated: 8344918: Unused private variables in SwingUtilities.java
In-Reply-To: <Ghd5rQNsTJA41L1H6JW8McpVaSZKDsaIVmeuC8c9wNM=.480109d1-76d7-47a0-a9ab-eb29b3f0ebc5@github.com>
References: <Ghd5rQNsTJA41L1H6JW8McpVaSZKDsaIVmeuC8c9wNM=.480109d1-76d7-47a0-a9ab-eb29b3f0ebc5@github.com>
Message-ID: <wN4mQYSADnONwtBFTCzde2Xvdo7TVkH7FixT7f2dkNE=.ac362a76-665d-4163-94ba-5121c021c6ec@github.com>

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

> Clean up of vars that are un-used.

This pull request has now been integrated.

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

8344918: Unused private variables in SwingUtilities.java

Reviewed-by: azvegint

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

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

From prr at openjdk.org  Tue Oct 14 17:48:10 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 17:48:10 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v4]
In-Reply-To: <IT6uqJTsemyfNahSEAwq_BeBEkF0d_3yCeNoilzt7no=.096747a0-a132-400e-9067-63035b31dfc3@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
 <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>
 <IT6uqJTsemyfNahSEAwq_BeBEkF0d_3yCeNoilzt7no=.096747a0-a132-400e-9067-63035b31dfc3@github.com>
Message-ID: <RKfnQi1Oxp-9oEr5WUPs7TXoZhiptgN31_iiwvCScDs=.9f0109e4-4eb9-4640-a588-ecb583d0bb79@github.com>

On Fri, 10 Oct 2025 05:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8369129
>
> src/java.desktop/share/classes/java/awt/image/Raster.java line 310:
> 
>> 308:             throw new IllegalArgumentException("size too large to store image");
>> 309:         }
>> 310:         int size = (int)lsz;
> 
> Isn't it strange that in this method we reject "empty" images by requiring w and h to be greater than 0, but at the same time accept 0 as scanlineStride and pixelStride? This may result in empty image as well (size == 0), I think it will be rejected later but still should we check it here as well?

We seem to have a number of APIs that allow the strides to be zero.
I find them odd, but I don't see how they can cause an empty image and they need careful consideration before changing. It seems very deliberate.
Here's a sampling of other cases (there are likely more, I searched very briefly and crudely)


     * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
    public BandedSampleModel(int dataType,
                             int w, int h,
                             int scanlineStride,
                             int[] bankIndices,
                             int[] bandOffsets) 

=====

     * @throws IllegalArgumentException if {@code pixelStride} is less than 0
     * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
  public ComponentSampleModel(int dataType,
                                int w, int h,
                                int pixelStride,
                                int scanlineStride,
                                int[] bandOffsets) {

=====
     * @throws IllegalArgumentException if {@code pixelStride} is less than 0
     * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
   public ComponentSampleModel(int dataType,
                                int w, int h,
                                int pixelStride,
                                int scanlineStride,
                                int[] bankIndices,
                                int[] bandOffsets) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2429979263

From prr at openjdk.org  Tue Oct 14 17:48:10 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 17:48:10 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v4]
In-Reply-To: <RKfnQi1Oxp-9oEr5WUPs7TXoZhiptgN31_iiwvCScDs=.9f0109e4-4eb9-4640-a588-ecb583d0bb79@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
 <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>
 <IT6uqJTsemyfNahSEAwq_BeBEkF0d_3yCeNoilzt7no=.096747a0-a132-400e-9067-63035b31dfc3@github.com>
 <RKfnQi1Oxp-9oEr5WUPs7TXoZhiptgN31_iiwvCScDs=.9f0109e4-4eb9-4640-a588-ecb583d0bb79@github.com>
Message-ID: <wKjNjLJfDi3xnnb-QgDagZQUrCMGvt5j5ihbVEic2Bw=.fbe631e4-25af-475f-80d6-1cc4c280fd4c@github.com>

On Tue, 14 Oct 2025 17:43:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/image/Raster.java line 310:
>> 
>>> 308:             throw new IllegalArgumentException("size too large to store image");
>>> 309:         }
>>> 310:         int size = (int)lsz;
>> 
>> Isn't it strange that in this method we reject "empty" images by requiring w and h to be greater than 0, but at the same time accept 0 as scanlineStride and pixelStride? This may result in empty image as well (size == 0), I think it will be rejected later but still should we check it here as well?
>
> We seem to have a number of APIs that allow the strides to be zero.
> I find them odd, but I don't see how they can cause an empty image and they need careful consideration before changing. It seems very deliberate.
> Here's a sampling of other cases (there are likely more, I searched very briefly and crudely)
> 
> 
>      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>     public BandedSampleModel(int dataType,
>                              int w, int h,
>                              int scanlineStride,
>                              int[] bankIndices,
>                              int[] bandOffsets) 
> 
> =====
> 
>      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
>      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>   public ComponentSampleModel(int dataType,
>                                 int w, int h,
>                                 int pixelStride,
>                                 int scanlineStride,
>                                 int[] bandOffsets) {
> 
> =====
>      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
>      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>    public ComponentSampleModel(int dataType,
>                                 int w, int h,
>                                 int pixelStride,
>                                 int scanlineStride,
>                                 int[] bankIndices,
>                                 int[] bandOffsets) {

PS, also negative strides are something that we've been asked to support too - in the distant past.
But I don't have any plans to do it now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2429982980

From prr at openjdk.org  Tue Oct 14 19:33:20 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Oct 2025 19:33:20 GMT
Subject: RFR: 6453640: BandedSampleModel.createCompatibleSampleModel() API docs
 are wrong
Message-ID: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>

This corrects some omissions / errors in BandedSampleModel docs and adds a test to verify them.

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

Commit messages:
 - 6453640

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

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

From honkar at openjdk.org  Wed Oct 15 00:17:03 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 15 Oct 2025 00:17:03 GMT
Subject: RFR: 8369251: Opensource few tests
In-Reply-To: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
Message-ID: <C2yzsQ9r5tMCfz-NBMdA7HaNdVBtG2vD-WEr6CK2dTg=.8ee91530-eb66-4b37-853d-2cf132e26eec@github.com>

On Sun, 12 Oct 2025 13:29:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Opensourcing few tests

test/jdk/java/awt/Choice/PaintArtefacts.java line 48:

> 46:     static boolean removeItems = true;
> 47:     private static final String INSTRUCTIONS = """
> 48:         The problem is seen on XToolkit only.

Since it says XToolkit only and the original bug was observed on solaris, can we restrict this test to linux platforms?

test/jdk/java/awt/Choice/SelectBetweenPressRelease.java line 28:

> 26:  * @bug 6318746
> 27:  * @key headful
> 28:  * @summary REG: File Selection is failing for every second selection made in the FileDlg drop-down, XToolkit

Same as above , can this test be restricted to linux only?

test/jdk/java/awt/Choice/SelectBetweenPressRelease.java line 61:

> 59: 
> 60:     private static void init() {
> 61:         frame = new Frame();

Frame title missing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2430785638
PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2430787581
PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2430786881

From psadhukhan at openjdk.org  Wed Oct 15 01:33:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Oct 2025 01:33:11 GMT
Subject: RFR: 8369251: Opensource few tests [v2]
In-Reply-To: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
Message-ID: <pgkHkHE9Eiu00pJZTboBjrBjeYeJcwcMXg31SiSzj0g=.667614a8-daac-4186-9830-e5247d894579@github.com>

> Opensourcing few tests

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

  Frame title

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27760/files
  - new: https://git.openjdk.org/jdk/pull/27760/files/c5261fa6..3c9a9ca3

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

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

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

From psadhukhan at openjdk.org  Wed Oct 15 01:33:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Oct 2025 01:33:17 GMT
Subject: RFR: 8369251: Opensource few tests [v2]
In-Reply-To: <C2yzsQ9r5tMCfz-NBMdA7HaNdVBtG2vD-WEr6CK2dTg=.8ee91530-eb66-4b37-853d-2cf132e26eec@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
 <C2yzsQ9r5tMCfz-NBMdA7HaNdVBtG2vD-WEr6CK2dTg=.8ee91530-eb66-4b37-853d-2cf132e26eec@github.com>
Message-ID: <DHQKASN-GWr2ch1jPa6W_7tO02nmaLaNE4QU4e69Vn4=.148d0c30-78e2-4372-a4dd-4910f7086eaf@github.com>

On Wed, 15 Oct 2025 00:02:40 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Frame title
>
> test/jdk/java/awt/Choice/PaintArtefacts.java line 48:
> 
>> 46:     static boolean removeItems = true;
>> 47:     private static final String INSTRUCTIONS = """
>> 48:         The problem is seen on XToolkit only.
> 
> Since it says XToolkit only and the original bug was observed on solaris, can we restrict this test to linux platforms?

same as below..

> test/jdk/java/awt/Choice/SelectBetweenPressRelease.java line 28:
> 
>> 26:  * @bug 6318746
>> 27:  * @key headful
>> 28:  * @summary REG: File Selection is failing for every second selection made in the FileDlg drop-down, XToolkit
> 
> Same as above , can this test be restricted to linux only?

Yes the bug was in XToolkit but that does not restrict us to test on other platforms to ensure there is no regressions in this area in other platforms too

> test/jdk/java/awt/Choice/SelectBetweenPressRelease.java line 61:
> 
>> 59: 
>> 60:     private static void init() {
>> 61:         frame = new Frame();
> 
> Frame title missing

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2430889370
PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2430888961
PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2430889127

From psadhukhan at openjdk.org  Wed Oct 15 07:55:28 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Oct 2025 07:55:28 GMT
Subject: RFR: 8342401: [TESTBUG]
 javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu
 22.04 on SBR Hosts
Message-ID: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>

Test probably was failing due to lack of delay between UI creation and test execution..Delay is added along with rendering frame at screen centre..Also added listener closer to UI creation within EDT
CI run for 100 iterations are ok on all platforms..

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

Commit messages:
 - 8342401: [TESTBUG] javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu 22.04 on SBR Hosts

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

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

From aturbanov at openjdk.org  Wed Oct 15 08:39:16 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 08:39:16 GMT
Subject: RFR: 4954405: Data buffers created with an offset are unusable
In-Reply-To: <VKT61MUnXijF380GXqIIWlZb_XBEELsMI95TGmgu-C4=.7a803f2a-6f47-44b1-b23e-e91c08a3f027@github.com>
References: <VKT61MUnXijF380GXqIIWlZb_XBEELsMI95TGmgu-C4=.7a803f2a-6f47-44b1-b23e-e91c08a3f027@github.com>
Message-ID: <aMAxc4dYww-LO72Xrg8AeWxl6bnzsVXtKSYoucDUmxE=.256d6b2e-908b-4f2b-b978-227582574a6b@github.com>

On Tue, 14 Oct 2025 03:29:00 GMT, Phil Race <prr at openjdk.org> wrote:

> ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements
> The super-class sets it in the constructor which runs very much like this subclass except it omits this.
> The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset
> to adjust dataOffsets values used in all calculations.
> 
> Instead ByteInterleavedRaster  does something a bit different than other classes where it includes it in some instance vars
> that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements.
> 
> It looks to me as if this is what ByteInterleavedRaster should also do instead.
> All existing tests pass, and this resolves the specific complaint in the bug report.

test/jdk/java/awt/image/ByteInterleavedRasterOffsetsTest.java line 48:

> 46:             Raster.createInterleavedRaster(databuf, 1, 1, 3, 3, bandOffsets, null);
> 47:         int[] pixels = raster.getPixels(0, 0, 1, 1, (int[])null);
> 48:         byte[] elements = (byte[])raster.getDataElements(0, 0,null);

Suggestion:

        byte[] elements = (byte[])raster.getDataElements(0, 0, null);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27782#discussion_r2431635679

From aturbanov at openjdk.org  Wed Oct 15 08:46:24 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 08:46:24 GMT
Subject: RFR: 8369251: Opensource few tests [v2]
In-Reply-To: <pgkHkHE9Eiu00pJZTboBjrBjeYeJcwcMXg31SiSzj0g=.667614a8-daac-4186-9830-e5247d894579@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
 <pgkHkHE9Eiu00pJZTboBjrBjeYeJcwcMXg31SiSzj0g=.667614a8-daac-4186-9830-e5247d894579@github.com>
Message-ID: <op4ap3B7q0FOmIOVHW2ECA1l8rGpfOO_0TBKsprA3f0=.ebfcbc94-bc80-43ac-9d37-2c14d4332b8f@github.com>

On Wed, 15 Oct 2025 01:33:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Opensourcing few tests
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Frame title

test/jdk/java/awt/Choice/SelectBetweenPressRelease.java line 70:

> 68: 
> 69:         addListener();
> 70:         frame.setSize (200,200);

Suggestion:

        frame.setSize(200, 200);

test/jdk/java/awt/Choice/SelectBetweenPressRelease.java line 102:

> 100: 
> 101:         // try to hit the first item
> 102:         if(System.getProperty("os.name").startsWith("Mac")) {

Suggestion:

        if (System.getProperty("os.name").startsWith("Mac")) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2431653421
PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2431653908

From psadhukhan at openjdk.org  Wed Oct 15 08:53:14 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Oct 2025 08:53:14 GMT
Subject: RFR: 8369251: Opensource few tests [v3]
In-Reply-To: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
Message-ID: <NFyxcLp80-E1nbihRXq9V0sysTi2q9PFpx6qWq40Mc4=.5b0069d5-fbd0-4544-af17-8350091010ec@github.com>

> Opensourcing few tests

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

  formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27760/files
  - new: https://git.openjdk.org/jdk/pull/27760/files/3c9a9ca3..52b91652

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

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

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

From aturbanov at openjdk.org  Wed Oct 15 08:53:16 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 08:53:16 GMT
Subject: RFR: 8369251: Opensource few tests [v2]
In-Reply-To: <pgkHkHE9Eiu00pJZTboBjrBjeYeJcwcMXg31SiSzj0g=.667614a8-daac-4186-9830-e5247d894579@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
 <pgkHkHE9Eiu00pJZTboBjrBjeYeJcwcMXg31SiSzj0g=.667614a8-daac-4186-9830-e5247d894579@github.com>
Message-ID: <dsMxW18pIRpv0LPrfyfPqOcbzOoUVFIUDU_ygL6Gttg=.4e3b8300-97d1-4b22-8a18-4286f9e10552@github.com>

On Wed, 15 Oct 2025 01:33:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Opensourcing few tests
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Frame title

test/jdk/javax/swing/text/JTextComponent/bug4532590.java line 50:

> 48:     static final Color TEXT_BG        = Color.WHITE;
> 49:     static final Color SELECTION_FG   = Color.RED;
> 50:     static final Color SELECTION_BG   = Color.YELLOW;

Suggestion:

    static final int SELECTION_START = 5;
    static final int SELECTION_END   = 10;
    static final String TEXT         = "Typein the missing word.";

    static final Color TEXT_FG       = Color.BLACK;
    static final Color TEXT_BG       = Color.WHITE;
    static final Color SELECTION_FG  = Color.RED;
    static final Color SELECTION_BG  = Color.YELLOW;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27760#discussion_r2431679609

From aturbanov at openjdk.org  Wed Oct 15 08:56:56 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 08:56:56 GMT
Subject: RFR: 6185110: Undefined behaviour of SampleModel for width,
 height < 0
In-Reply-To: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
References: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
Message-ID: <OB0hD-FHfbfhnDgXpkYy5cDYEzLu7aOW5b6Ni9hr5NI=.415a5093-a224-4301-b1b0-05c561c0d003@github.com>

On Fri, 10 Oct 2025 22:30:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The only significant change here is to ensure that all SampleModel types throw a specified exception if a client
> calls any of the following methods with a negative width or height.
> getPixels(..)
> setPixels(..)
> getSamples(..)
> setSamples(..)
> 
> The rest is fixing the javadoc to properly describe what happens and some minor cleanup.
> I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them.
> I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method.
> There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions
> are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in  foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited.
> 
> I added a test which verifies the behaviour for illegal arguments.
> 
> CSR is here https://bugs.openjdk.org/browse/JDK-8369623

src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 450:

> 448: 
> 449:         if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width ||
> 450:             y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 >  height)

Suggestion:

            y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height)

src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 703:

> 701: 
> 702:         if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width ||
> 703:             y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 >  height)

Suggestion:

            y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height)

src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 747:

> 745: 
> 746:         if (x < 0 || (w < 0) || x >= width || w > width || x1 < 0 || x1 > width ||
> 747:             y < 0 || (h < 0) || y >= height || y > height || y1 < 0 || y1 >  height)

Suggestion:

            y < 0 || (h < 0) || y >= height || y > height || y1 < 0 || y1 > height)

src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 1002:

> 1000: 
> 1001:         if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width ||
> 1002:             y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 >  height)

Suggestion:

            y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height)

src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java line 460:

> 458: 
> 459:         if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width ||
> 460:             y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 >  height)

Suggestion:

            y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height)

src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java line 640:

> 638: 
> 639:         if (x < 0 || w < 0 || x >= width || w > width || x1 < 0 || x1 > width ||
> 640:             y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 >  height)

Suggestion:

            y < 0 || h < 0 || y >= height || h > height || y1 < 0 || y1 > height)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2431696072
PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2431696556
PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2431695064
PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2431695539
PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2431693595
PR Review Comment: https://git.openjdk.org/jdk/pull/27754#discussion_r2431694243

From psadhukhan at openjdk.org  Wed Oct 15 08:59:34 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Oct 2025 08:59:34 GMT
Subject: RFR: 8369251: Opensource few tests [v4]
In-Reply-To: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
Message-ID: <5pge14VJFwM3UwWqKMuYKgs04xMBxmpR4tbvqSuOrcs=.1e7b6a0d-9707-4713-a923-4d74f6ff9223@github.com>

> Opensourcing few tests

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

  Formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27760/files
  - new: https://git.openjdk.org/jdk/pull/27760/files/52b91652..6739a4ed

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

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

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

From honkar at openjdk.org  Wed Oct 15 18:13:53 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 15 Oct 2025 18:13:53 GMT
Subject: RFR: 8369251: Opensource few tests [v4]
In-Reply-To: <5pge14VJFwM3UwWqKMuYKgs04xMBxmpR4tbvqSuOrcs=.1e7b6a0d-9707-4713-a923-4d74f6ff9223@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
 <5pge14VJFwM3UwWqKMuYKgs04xMBxmpR4tbvqSuOrcs=.1e7b6a0d-9707-4713-a923-4d74f6ff9223@github.com>
Message-ID: <dpbqTQ0WeoYLL_IOnSLJkPH8zj-YyTWNcBt2UdXIYO8=.4a27ec77-09f1-4618-8c47-b539e16a982a@github.com>

On Wed, 15 Oct 2025 08:59:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Opensourcing few tests
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27760#pullrequestreview-3341696504

From weijun at openjdk.org  Wed Oct 15 20:50:59 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 15 Oct 2025 20:50:59 GMT
Subject: Integrated: 8354469: Keytool exposes the password in plain text when
 command is piped using | grep
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: <VINVigPpAuUHumUpsTv57oe-EVKi4n_CDGw68alyluw=.319759d8-19fe-427f-9046-2206c3855453@github.com>

On Wed, 10 Sep 2025 15:43:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: a7a3a660
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7a3a660e33fabc025ebe887f5605741be9ca8c3
Stats:     335 lines in 6 files changed: 287 ins; 12 del; 36 mod

8354469: Keytool exposes the password in plain text when command is piped using | grep

Reviewed-by: mullan, smarks, naoto, hchao

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

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

From asemenov at openjdk.org  Wed Oct 15 23:53:05 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 15 Oct 2025 23:53:05 GMT
Subject: RFR: 8365609: Fix several potential NULL native pointer
 dereferences in the desktop module [v5]
In-Reply-To: <iPq0-TE9FfK_S1UFSBCgcBVQ_uorVkP5_WPmHBbXLoA=.68906c90-0a28-40cb-9456-a8dbc22f1d03@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <iPq0-TE9FfK_S1UFSBCgcBVQ_uorVkP5_WPmHBbXLoA=.68906c90-0a28-40cb-9456-a8dbc22f1d03@github.com>
Message-ID: <igfVVkhgQfO_vZcBuFPrZSbfvVN7wbHTND6V6BbY678=.d953636d-ad0a-49d4-8a09-0ee68625165b@github.com>

On Mon, 1 Sep 2025 10:24:58 GMT, Artem Semenov <asemenov 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.
>
> Artem Semenov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "The same issue is present in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitSwToTexture()"
>    
>    This reverts commit c4b87121234bb1427f5e611adf5726ac5b3d15e3.
>  - Revert "8365609 Null pointer dereference in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitToSurfaceViaTexture()"
>    
>    This reverts commit ff9825cd7d8838c90daa804e794576282be7bb81.
>  - Revert "Fixed indentation"
>    
>    This reverts commit c96d09acd95d0ccf2fef50b8ccfeb5e2a0aa0968.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Artem Semenov <savoptik at altlinux.org>.

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

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

From serb at openjdk.org  Wed Oct 15 23:53:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 15 Oct 2025 23:53:05 GMT
Subject: RFR: 8365609: Fix several potential NULL native pointer
 dereferences in the desktop module [v5]
In-Reply-To: <iPq0-TE9FfK_S1UFSBCgcBVQ_uorVkP5_WPmHBbXLoA=.68906c90-0a28-40cb-9456-a8dbc22f1d03@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <iPq0-TE9FfK_S1UFSBCgcBVQ_uorVkP5_WPmHBbXLoA=.68906c90-0a28-40cb-9456-a8dbc22f1d03@github.com>
Message-ID: <dB27tAymlgP3zoBCeg0b_BJkmMymIJDtARemNTA9iK4=.191565cd-8053-4d47-9d38-07e6b83e0ed6@github.com>

On Mon, 1 Sep 2025 10:24:58 GMT, Artem Semenov <asemenov 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.
>
> Artem Semenov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "The same issue is present in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitSwToTexture()"
>    
>    This reverts commit c4b87121234bb1427f5e611adf5726ac5b3d15e3.
>  - Revert "8365609 Null pointer dereference in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitToSurfaceViaTexture()"
>    
>    This reverts commit ff9825cd7d8838c90daa804e794576282be7bb81.
>  - Revert "Fixed indentation"
>    
>    This reverts commit c96d09acd95d0ccf2fef50b8ccfeb5e2a0aa0968.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26799#pullrequestreview-3342665165

From honkar at openjdk.org  Thu Oct 16 00:27:04 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 16 Oct 2025 00:27:04 GMT
Subject: RFR: 8342401: [TESTBUG]
 javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu
 22.04 on SBR Hosts
In-Reply-To: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
References: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
Message-ID: <KIlwsV2uhXWC8fUQRXpsr1fApkZJRmEzwDF6KTOXWq4=.05278826-27df-492c-afd1-9d15fa04a304@github.com>

On Wed, 15 Oct 2025 07:41:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test probably was failing due to lack of delay between UI creation and test execution..Delay is added along with rendering frame at screen centre..Also added listener closer to UI creation within EDT
> CI run for 100 iterations are ok on all platforms..

test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java line 66:

> 64: 
> 65:                 SwingUtilities.invokeAndWait(() -> {
> 66:                     frame = new JFrame(")JSpinnerButtonFocusTest");

Extra bracket in title

test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java line 96:

> 94: 
> 95:                     frame.setAlwaysOnTop(true);
> 96:                     frame.pack();

Frame size can be made a little bigger instead of frame.pack().

test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java line 102:

> 100:                 robot.waitForIdle();
> 101:                 robot.delay(1000);
> 102: 

This is on unedited line: Ln#107, 15 minutes of await time looks really long. I think 1 or 2 mins would be more than sufficient ?


 if (!latch1.await(15, TimeUnit.MINUTES)) {
                    throw new RuntimeException(LF.getClassName() +
                            ": Timeout waiting for editor1 to gain focus.");
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27815#discussion_r2434256032
PR Review Comment: https://git.openjdk.org/jdk/pull/27815#discussion_r2434261247
PR Review Comment: https://git.openjdk.org/jdk/pull/27815#discussion_r2434258588

From honkar at openjdk.org  Thu Oct 16 00:52:14 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 16 Oct 2025 00:52:14 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <h0T3_sSCEh5mY8_AlfAZied3Gvb14NrUk18j21rEFig=.1aeaf4ad-4a92-48c4-b855-59929fdfd418@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <9s1KDh3FVnS36lccH_GAdotAO5vFhs6zfdZqMYP9TJU=.9b639ffe-f91b-4006-a1a1-c9d041f51e11@github.com>
 <h0T3_sSCEh5mY8_AlfAZied3Gvb14NrUk18j21rEFig=.1aeaf4ad-4a92-48c4-b855-59929fdfd418@github.com>
Message-ID: <AqvPwqaSP_4qfwknNhqonUoibTAfM9BoGAigohwruNA=.7c9a859b-6685-4bec-bc8e-47988b33164c@github.com>

On Tue, 3 Jun 2025 18:29:03 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> @anass-baya Couple of things regarding this PR:
>> 
>> - There is a title mismatch please remove the prefix "Draft:" so that jcheck passes and rfr label is added to PR.
>> 
>> - I wasn't able to get it to fail on Ubuntu 24.04, is fractional scaling setting enabled on SBR nodes ? Although even with fractional scale enabled I wasn't able to replicate the issue with different uiScales (1, 1.25, 1.5, 2)
>> 
>> - Can you please add test logs from the node it is failing on?
>> 
>> - Headsup: RDP1 for jdk25 is on 5th June, 2025. In case you are planning to add this fix to 25 then it requires to be approved and integrated before the fork.
>
> Hello @honkar-jdk,
> 
>> There is a title mismatch please remove the prefix "Draft:" so that jcheck passes and rfr label is added to PR.
> 
> I?ve converted it to a draft to investigate further, as Alexey suggested.
> 
>> I wasn't able to get it to fail on Ubuntu 24.04, is fractional scaling setting enabled on SBR nodes ? Although even with fractional scale enabled I wasn't able to replicate the issue with different uiScales (1, 1.25, 1.5, 2)
> 
> The failure only occurs on Ubuntu SBR nodes, so I'm trying to take a screenshot to see what's going on there. 
> Thanks

@anass-baya 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>     _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 1020
> 
> However, it should be:
> 
>     _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 1018
> 
> Wich is the output of the command when the issue doest not occur.

Can you please check which property or API are we querying in native x11 side to get screen insets ? If  _NET_WORKAREA returns the correct values then may be it warrants a src code fix rather than test?

What about Wayland does it return similar values?

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3408753345

From honkar at openjdk.org  Thu Oct 16 01:21:08 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 16 Oct 2025 01:21:08 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
Message-ID: <pinhFHmL7dV2JPraIoBXyvgOvPFhXpzSAoi5_gBcvaw=.ce398282-d271-4f3f-b1b7-c7452d8fe1b3@github.com>

On Thu, 29 May 2025 14:53:51 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Issue:**
> The bottom inset is different from the expected value by 2 pixels.
> 
> **Analysis:**
> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
> 
> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
> 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
> 
> However, it should be:
>  
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
> 
> Wich is the output of the command when the issue doest not occur.
> 
> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
> 
> **Proposed Fix:**
> Increase the allowed margin to 2 pixels.

I see that we are using `_NET_WORKAREA` in Xtoolkit.java to fetch screen insets. You may want to check getScreenInsetsImpl() method to check why different values are returned in the 2 cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3408803189

From psadhukhan at openjdk.org  Thu Oct 16 02:02:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Oct 2025 02:02:56 GMT
Subject: RFR: 8342401: [TESTBUG]
 javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu
 22.04 on SBR Hosts [v2]
In-Reply-To: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
References: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
Message-ID: <VOqMsltbQLXPrG5frR2XxrMkoJipDLoX2k3RNy_Klxg=.175d6424-32a9-4034-ac53-603a7cdeba77@github.com>

> Test probably was failing due to lack of delay between UI creation and test execution..Delay is added along with rendering frame at screen centre..Also added listener closer to UI creation within EDT
> CI run for 100 iterations are ok on all platforms..

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

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27815/files
  - new: https://git.openjdk.org/jdk/pull/27815/files/4482c22a..f808f507

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

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

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

From psadhukhan at openjdk.org  Thu Oct 16 02:03:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Oct 2025 02:03:01 GMT
Subject: RFR: 8342401: [TESTBUG]
 javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu
 22.04 on SBR Hosts [v2]
In-Reply-To: <KIlwsV2uhXWC8fUQRXpsr1fApkZJRmEzwDF6KTOXWq4=.05278826-27df-492c-afd1-9d15fa04a304@github.com>
References: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
 <KIlwsV2uhXWC8fUQRXpsr1fApkZJRmEzwDF6KTOXWq4=.05278826-27df-492c-afd1-9d15fa04a304@github.com>
Message-ID: <CUwS4i11YEh0AH3umy6xP7Nou-BWjw9CJjbNHbFJgaw=.f13132a2-3273-4bed-af2c-0f70e5ef061c@github.com>

On Thu, 16 Oct 2025 00:17:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java line 66:
> 
>> 64: 
>> 65:                 SwingUtilities.invokeAndWait(() -> {
>> 66:                     frame = new JFrame(")JSpinnerButtonFocusTest");
> 
> Extra bracket in title

rectified

> test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java line 96:
> 
>> 94: 
>> 95:                     frame.setAlwaysOnTop(true);
>> 96:                     frame.pack();
> 
> Frame size can be made a little bigger instead of frame.pack().

ok

> test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java line 102:
> 
>> 100:                 robot.waitForIdle();
>> 101:                 robot.delay(1000);
>> 102: 
> 
> This is on unedited line: Ln#107, 15 minutes of await time looks really long. I think 1 or 2 mins would be more than sufficient ?
> 
> 
>  if (!latch1.await(15, TimeUnit.MINUTES)) {
>                     throw new RuntimeException(LF.getClassName() +
>                             ": Timeout waiting for editor1 to gain focus.");
> }

ok..i noticed it but did not change it as it was not contributing to the failure

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27815#discussion_r2434358520
PR Review Comment: https://git.openjdk.org/jdk/pull/27815#discussion_r2434359485
PR Review Comment: https://git.openjdk.org/jdk/pull/27815#discussion_r2434359308

From psadhukhan at openjdk.org  Thu Oct 16 02:05:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Oct 2025 02:05:25 GMT
Subject: Integrated: 8369251: Opensource few tests
In-Reply-To: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
References: <smKIG-q0ePEiSsx5Etae6BBwrTYBh0lwGaNrdnwGars=.44dbc4cb-7f78-4c80-b0b9-be5d41cb7397@github.com>
Message-ID: <XrfsFppE-ozB222p23vFGSmuqFeyXsSG4intnDj7z8Q=.de12809a-8d7d-42c1-b480-c62f0e173f28@github.com>

On Sun, 12 Oct 2025 13:29:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Opensourcing few tests

This pull request has now been integrated.

Changeset: 4ed36403
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ed364033daef96f6141a3ad2d217fa1ec5eca3e
Stats:     1102 lines in 8 files changed: 1102 ins; 0 del; 0 mod

8369251: Opensource few tests

Reviewed-by: honkar

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

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

From tr at openjdk.org  Thu Oct 16 04:30:14 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 16 Oct 2025 04:30:14 GMT
Subject: RFR: 8225131: Test DragSourceMotionListenerTest.java fails on
 Windows [v3]
In-Reply-To: <71he7hvNoEec69wpPw6VnincSEcdcOcW-C322MByhE0=.54a0578e-041f-4caa-9b5a-4f3c149b101f@github.com>
References: <wnR56KVe_exCFKdIp7z59xLu0Ds3waCLLCNe4i-W3Xc=.077706f2-a790-4999-8875-5c6d38c408ed@github.com>
 <71he7hvNoEec69wpPw6VnincSEcdcOcW-C322MByhE0=.54a0578e-041f-4caa-9b5a-4f3c149b101f@github.com>
Message-ID: <VnAXQsMia7eNpdDDrLBAgyN0wBDzWOD0nQkiyThpXL4=.b640c35d-07a0-4ec4-a4ac-a63a101ba2e7@github.com>

On Mon, 22 Sep 2025 04:02:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Test is failing frequently on mach5 machines. I have fixed it with stabilizations and moved the frame to center of the screen. After the fix several runs were made on mach5 and no failures were seen.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove blank space
>  - Revert indentations

> What do we know about the test failure? Not much.
> 
> According to the bug report, the test fails with the message ?Failed first test.? This message means that the test didn't receive `dragMouseMoved` event that lies outside of the frame bounds.
> 
> https://github.com/openjdk/jdk/blob/1d6cafdc5244960ddec2fd82b8454c6c3cafe022/test/jdk/java/awt/dnd/DragSourceMotionListenerTest.java#L90-L94
> 
> I added traces to different parts of the test, and this is what I found out. The test stops receiving mouse events via `dragMouseMoved`:
> 
> Log of the `DragSourceMotionListenerTest.java` failure
> ```
> -------
>  srcPoint : java.awt.Point[x=107,y=130]
> testPoint1: java.awt.Point[x=621,y=118]
> testPoint2: java.awt.Point[x=307,y=130]
> -------
> Start dragging to java.awt.Point[x=621,y=118]
>     107, 130
>     108, 129
>     109, 128
> gestureListener -> startDrag
>     110, 127
> java.awt.Point[x=111,y=126]
>     111, 126
>     112, 125
>         dragMouseMoved: 113, 124
>     113, 124
>         dragMouseMoved: 114, 123
> ...
>     227, 118
>         dragMouseMoved: 228, 118
>     228, 118
>     229, 118
> ...
>     620, 118
> Drag started? true
> Move down
>     621, 119
> ...
>     621, 128
> To drop target: java.awt.Point[x=307,y=130]
>     621, 128
>     620, 129
>     619, 130
> ...
>     309, 130
>     308, 130
> Release mouse
> dragDropEnd: 228, 118
> ```
> 
> Thus, the last time the `dragMouseMoved` method was called with coordinates of (228, 118). It's the mouse coordinates that are reported by `dragDropEnd`.
> 
> Indeed, adding `robot.waitForIdle()` after dragging the mouse to `dstOutsidePoint` helps resolve the missing mouse events. Why aren't mouse drag events delivered?
> 
> This looks to me like a product bug rather than a test bug. Watching the test running, robot doesn't move the mouse too quickly, a user is capable of moving mouse quicker. Will the drag operation fail if the user moves the mouse pointer too quickly?
> 
> Additionally, I was able to make the test fail with this additional `robot.waitForIdle()`. In this case, the mouse events get delivered so that `passedTest1` is set to `true`. Yet while the mouse is dragged to `dstInsidePoint`, the `dragMouseMoved` stops being called.
> 
> Log of the `DragSourceMotionListenerTest.java` failure with only one `waitForIdle`
> ```text ... 622, 119 passed1: 623 ~ 624 dragMouseMoved: 623, 119 623, 119 Drag started? true <-- waitForIdle ... To drop target: java.awt.Point[x=308,y=131] passed1: 624 ~ 624 dragMouseMoved: 624, 129 624, 129 ... 354, 131 dragMouseMoved: 353, 131 353, 131 352, 131 351, 131 ... 310, 131 309, 131 Release mouse dragDropEnd: 353, 131 ----------System.err:(11/653)---------- java.lang.RuntimeException: Failed second test. ```
> Again, the mouse coordinates in `dragDropEnd` are exactly the ones in the latest call to `dragMouseMoved`: (353, 131).
> 
> Adding another `robot.waitForIdle()` after drag is complete but before release the mouse button makes the test stable; at least it has never failed for me in this configuration.
> 
> But why are so many `waitForIdle`s needed?
> 
> The should be stable as it is written now. The robot simulates the user's behaviour: press Ctrl, press the left mouse button and start dragging? outside of the app window and return back to the app window, then finally release the mouse button and Ctrl. Since this test fails, a real app may fail to register the drop at the correct coordinates.

Sounds right to me. Thanks for the investigation though. I did some stabilization to fix the failure, never tried to look into product issue for this one. Thought it might be another case of making the test stable. Then I'll drop this PR since this one might be a product issue too, needs further investigation.

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

PR Comment: https://git.openjdk.org/jdk/pull/27283#issuecomment-3409130503

From tr at openjdk.org  Thu Oct 16 04:30:15 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 16 Oct 2025 04:30:15 GMT
Subject: Withdrawn: 8225131: Test DragSourceMotionListenerTest.java fails on
 Windows
In-Reply-To: <wnR56KVe_exCFKdIp7z59xLu0Ds3waCLLCNe4i-W3Xc=.077706f2-a790-4999-8875-5c6d38c408ed@github.com>
References: <wnR56KVe_exCFKdIp7z59xLu0Ds3waCLLCNe4i-W3Xc=.077706f2-a790-4999-8875-5c6d38c408ed@github.com>
Message-ID: <l95e5ZED-7YHsKd1vw3ffFMFg2dgEBiJT0vBoZcxy94=.c5f00c76-fe8c-42fc-bdb8-19a2414e503e@github.com>

On Mon, 15 Sep 2025 06:24:15 GMT, Tejesh R <tr at openjdk.org> wrote:

> Test is failing frequently on mach5 machines. I have fixed it with stabilizations and moved the frame to center of the screen. After the fix several runs were made on mach5 and no failures were seen.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Thu Oct 16 05:00:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Oct 2025 05:00:13 GMT
Subject: RFR: 8068310: [TEST_BUG] Test
 javax/swing/JColorChooser/Test4234761.java fails with GTKL&F
Message-ID: <LsrWtHnCJfea_oQZ-3kTiwNlsqV6MPWcP9DClQJcfQw=.07cd7157-ced2-48de-bae5-a9f89067c76c@github.com>

Test fails in GTK L&F as test attempts to cast JColorChooser component to JTabbedPane but colorChooser UI is different in GTK L&F without tabbedpane as seen below so restricted it for GTK run

<img width="579" height="404" alt="image" src="https://github.com/user-attachments/assets/79c23377-5ab3-48a5-a02f-c93b8885e4bd" />

unlike Metal

<img width="622" height="381" alt="image" src="https://github.com/user-attachments/assets/ee9a8433-6766-403e-b3c0-dfe441200f96" />

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

Commit messages:
 - 8068310: [TEST_BUG] Test javax/swing/JColorChooser/Test4234761.java fails with GTKL&F
 - 8068310: [TEST_BUG] Test javax/swing/JColorChooser/Test4234761.java fails with GTKL&F

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

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

From asemenov at openjdk.org  Thu Oct 16 07:31:18 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 16 Oct 2025 07:31:18 GMT
Subject: Integrated: 8365609: Fix several potential NULL native pointer
 dereferences in the desktop module
In-Reply-To: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
Message-ID: <Uem6SqoOnAMmpzim-Y6Qhq_eDj-N4qTMctr8haIon3g=.31b5f7c3-4780-4daa-b146-5a040d26c74d@github.com>

On Fri, 15 Aug 2025 13:04:35 GMT, Artem Semenov <asemenov 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.

This pull request has now been integrated.

Changeset: aed42a16
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aed42a16bacb24753a536d07fedd736d64cde3be
Stats:     7 lines in 2 files changed: 2 ins; 3 del; 2 mod

8365609: Fix several potential NULL native pointer dereferences in the desktop module

Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Artem Semenov Artem Semenov <savoptik at altlinux.org>

Reviewed-by: azvegint, prr, serb

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

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

From psadhukhan at openjdk.org  Thu Oct 16 07:40:26 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Oct 2025 07:40:26 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v3]
In-Reply-To: <yiazDqgIY1S4bZ5tT2FQer3uIdix59pGaTkVRUnxNVA=.b33b6a31-d178-4de2-9994-5ae893e900f0@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f9PSjXuCRbIv9MmRAMww3Lr6tKHEKgLIXQ0Nk8f2aV0=.e3295676-168c-480d-b89a-caccdeeb4d39@github.com>
 <AG_nNYcM_ZF06Kla9v93LhPPB3kSJuFoKpIdXC-NOeo=.a762fc9e-ad90-4408-8676-9e7c314391bb@github.com>
 <jcQunL4UBLi2TYXa_d7BusNqCDgBwIjwlrRda9fbcTc=.ba87c749-d19b-4f46-a7cb-aa03e01b378b@github.com>
 <Sr9Waor7MPhu8WkEddohMKwyaSkRO3bc8jTVTtddf1g=.770dff08-0bf1-4465-8775-3684d1cd5625@github.com>
 <L5vGJYo_jLYqxoN7FNY3mHzfrbk5_PJ5OKQFv835KeU=.d2f27745-8e3f-411b-86fa-5b076951a037@github.com>
 <yiazDqgIY1S4bZ5tT2FQer3uIdix59pGaTkVRUnxNVA=.b33b6a31-d178-4de2-9994-5ae893e900f0@github.com>
Message-ID: <ysIiX3VFpzWpH6HBe33EFZuRYeGau6wdenog1uSRDLc=.04b733a8-ae0f-4479-8c3a-873c98bf98ab@github.com>

On Thu, 25 Sep 2025 18:45:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Why it should not call sleep on EDT? It is not forbidden and if it hangs it will be a bug in product.
> 
> It is not necessary to update the test that catches two bugs the initial issue and the macOS bug without a reason, only adjust the timeout if needed.

I guess it is strongly discouraged to have sleep in EDT to ensure UI does not become unresponsive.
Also, it's not the same test but same bugid was being erroneously used in two different tests as both are failing in macos ARM..The other test is decoupled from this and will be investigated as per different bugid..Current PR for this test stands as it is..

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

PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3409579772

From psadhukhan at openjdk.org  Thu Oct 16 09:39:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Oct 2025 09:39:39 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
Message-ID: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>

Test fails in GTKLookAndFeel with NPE

java.lang.NullPointerException
at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 

because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
`UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there

Fix is made to not use these color to create BevelBorder if these colors are not present..

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

Commit messages:
 - 8068293: [TEST_BUG] Test closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java fails with GTKLookAndFeel

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

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

From abaya at openjdk.org  Thu Oct 16 13:51:29 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 16 Oct 2025 13:51:29 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <pinhFHmL7dV2JPraIoBXyvgOvPFhXpzSAoi5_gBcvaw=.ce398282-d271-4f3f-b1b7-c7452d8fe1b3@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <pinhFHmL7dV2JPraIoBXyvgOvPFhXpzSAoi5_gBcvaw=.ce398282-d271-4f3f-b1b7-c7452d8fe1b3@github.com>
Message-ID: <tr3_UnZBasRmgFcenm7wdByC_dKty1EG0OJzWCgkvss=.cd03d3fa-af20-4140-baa9-421547cf0ab4@github.com>

On Thu, 16 Oct 2025 01:18:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> **Issue:**
>> The bottom inset is different from the expected value by 2 pixels.
>> 
>> **Analysis:**
>> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
>> 
>> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
>> 
>> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
>> 
>>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
>> 
>> However, it should be:
>>  
>>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
>> 
>> Wich is the output of the command when the issue doest not occur.
>> 
>> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
>> 
>> **Proposed Fix:**
>> Increase the allowed margin to 2 pixels.
>
> I see that we are using `_NET_WORKAREA` in Xtoolkit.java to fetch screen insets. You may want to check getScreenInsetsImpl() method to check why different values are returned in the 2 cases.

Hello @honkar-jdk,
Thank you for your follow-up.
Both our source code and the command use the same property, _NET_WORKAREA. When I noticed the issue, I thought that maybe we are misusing the _NET_WORKAREA in getScreenInsetsImpl(). However, as you can see in the traces in [JDK-8357390](https://bugs.openjdk.org/browse/JDK-8357390) , it returns the same values as the xprop command does.

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3410981990

From azvegint at openjdk.org  Thu Oct 16 16:11:49 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 16 Oct 2025 16:11:49 GMT
Subject: RFR: 8364673: Remove duplicate font mapping for itcavantgarde in
 psfontj2d.properties
In-Reply-To: <MXlxEylx7cLHssTKpVIt23Uacgwb8JoEMV-gagNTN5E=.fa258c8c-2285-43a7-a241-9e0d6c98bc5d@github.com>
References: <MXlxEylx7cLHssTKpVIt23Uacgwb8JoEMV-gagNTN5E=.fa258c8c-2285-43a7-a241-9e0d6c98bc5d@github.com>
Message-ID: <hR80sPchqGhQCpFU6tequs5WiuNXUioNTa9rHuPCgGc=.d65bea48-ac12-46b7-ab9c-611a7368cf97@github.com>

On Tue, 14 Oct 2025 04:27:53 GMT, Phil Race <prr at openjdk.org> wrote:

> I've spent some time trying to think if one of these was supposed to be something else, but it looks like a dup.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27784#pullrequestreview-3345747484

From kizune at openjdk.org  Thu Oct 16 16:11:51 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 16 Oct 2025 16:11:51 GMT
Subject: RFR: 8364673: Remove duplicate font mapping for itcavantgarde in
 psfontj2d.properties
In-Reply-To: <MXlxEylx7cLHssTKpVIt23Uacgwb8JoEMV-gagNTN5E=.fa258c8c-2285-43a7-a241-9e0d6c98bc5d@github.com>
References: <MXlxEylx7cLHssTKpVIt23Uacgwb8JoEMV-gagNTN5E=.fa258c8c-2285-43a7-a241-9e0d6c98bc5d@github.com>
Message-ID: <MCJbMuleSQYlSQIFIfaoa_4zdaBYrsj83VDHrC2ZbE8=.355fbeb3-69e3-4379-be35-96effbe5e8c1@github.com>

On Tue, 14 Oct 2025 04:27:53 GMT, Phil Race <prr at openjdk.org> wrote:

> I've spent some time trying to think if one of these was supposed to be something else, but it looks like a dup.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27784#pullrequestreview-3345747901

From azvegint at openjdk.org  Thu Oct 16 16:15:10 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 16 Oct 2025 16:15:10 GMT
Subject: RFR: 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse
 Exception: Invalid or unrecognized bugid: 50510568367702
In-Reply-To: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
References: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
Message-ID: <1dSJW9_ALGoABgAUtWlrEgV4ltx0jfkQB7I9F1NDp2U=.37222872-7973-48f6-b06f-dd8f5a02b952@github.com>

On Sat, 11 Oct 2025 05:16:45 GMT, Phil Race <prr at openjdk.org> wrote:

> I must have spaced out.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27756#pullrequestreview-3345758109

From jdv at openjdk.org  Thu Oct 16 16:15:12 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 16 Oct 2025 16:15:12 GMT
Subject: RFR: 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse
 Exception: Invalid or unrecognized bugid: 50510568367702
In-Reply-To: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
References: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
Message-ID: <m-0IT1vHBFOOCqx-e_TpKK3MMICpSzMFlfLk5BNQ7Ek=.b4f84212-5a75-42cc-9247-00df7d1ebdc3@github.com>

On Sat, 11 Oct 2025 05:16:45 GMT, Phil Race <prr at openjdk.org> wrote:

> I must have spaced out.

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27756#pullrequestreview-3345763456

From kizune at openjdk.org  Thu Oct 16 16:15:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 16 Oct 2025 16:15:11 GMT
Subject: RFR: 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse
 Exception: Invalid or unrecognized bugid: 50510568367702
In-Reply-To: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
References: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
Message-ID: <tce91FPymoMElSyZpBvArVpvmca8CBkv-P0J1j5mAmU=.dd59e686-44a0-4db1-b26b-509e04d6687a@github.com>

On Sat, 11 Oct 2025 05:16:45 GMT, Phil Race <prr at openjdk.org> wrote:

> I must have spaced out.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27756#pullrequestreview-3345758538

From honkar at openjdk.org  Thu Oct 16 16:45:13 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 16 Oct 2025 16:45:13 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <tr3_UnZBasRmgFcenm7wdByC_dKty1EG0OJzWCgkvss=.cd03d3fa-af20-4140-baa9-421547cf0ab4@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <pinhFHmL7dV2JPraIoBXyvgOvPFhXpzSAoi5_gBcvaw=.ce398282-d271-4f3f-b1b7-c7452d8fe1b3@github.com>
 <tr3_UnZBasRmgFcenm7wdByC_dKty1EG0OJzWCgkvss=.cd03d3fa-af20-4140-baa9-421547cf0ab4@github.com>
Message-ID: <ZVAVbndK552rdql1OvfcufUDZ5Vchswpgz47wzDSp6g=.172b4840-4662-403b-9ca7-fc8088048292@github.com>

On Thu, 16 Oct 2025 13:48:42 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> I see that we are using `_NET_WORKAREA` in Xtoolkit.java to fetch screen insets. You may want to check getScreenInsetsImpl() method to check why different values are returned in the 2 cases.
>
> Hello @honkar-jdk,
> Thank you for your follow-up.
> Both our source code and the command use the same property, _NET_WORKAREA. When I noticed the issue, I thought that maybe we are misusing the _NET_WORKAREA in getScreenInsetsImpl(). However, as you can see in the traces in [JDK-8357390](https://bugs.openjdk.org/browse/JDK-8357390) , it returns the same values as the xprop command does.

@anass-baya You mentioned previously that the difference might be related to window manager. Which window manager is used in the 2 cases (the one where the test passes vs fails) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3411737248

From prr at openjdk.org  Thu Oct 16 17:02:20 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Oct 2025 17:02:20 GMT
Subject: Integrated: 8364673: Remove duplicate font mapping for itcavantgarde
 in psfontj2d.properties
In-Reply-To: <MXlxEylx7cLHssTKpVIt23Uacgwb8JoEMV-gagNTN5E=.fa258c8c-2285-43a7-a241-9e0d6c98bc5d@github.com>
References: <MXlxEylx7cLHssTKpVIt23Uacgwb8JoEMV-gagNTN5E=.fa258c8c-2285-43a7-a241-9e0d6c98bc5d@github.com>
Message-ID: <rVGA7bgvLZeBkH-0ctgY5IULDBdJrQdx7lCt-WNdPk0=.4ecec73b-5f08-4432-ac00-61d1ccf05bff@github.com>

On Tue, 14 Oct 2025 04:27:53 GMT, Phil Race <prr at openjdk.org> wrote:

> I've spent some time trying to think if one of these was supposed to be something else, but it looks like a dup.

This pull request has now been integrated.

Changeset: d7b525ab
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7b525ab9980743cf0cab3e3daaa4ccb725bfea8
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8364673: Remove duplicate font mapping for itcavantgarde in psfontj2d.properties

Reviewed-by: azvegint, kizune

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

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

From prr at openjdk.org  Thu Oct 16 17:04:30 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Oct 2025 17:04:30 GMT
Subject: Integrated: 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse
 Exception: Invalid or unrecognized bugid: 50510568367702
In-Reply-To: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
References: <d0zvLrb4q6qSmpYBd_HoArTzuat9L5ntss1cBs5WZ3Y=.70729959-a235-4ad0-9c57-ec2bb6524eb0@github.com>
Message-ID: <AbfLAlRwum8rk96bOuYATN3fekPDsfDRewV32iffE4A=.e25454c1-de3c-4727-8af9-0e2cc7871143@github.com>

On Sat, 11 Oct 2025 05:16:45 GMT, Phil Race <prr at openjdk.org> wrote:

> I must have spaced out.

This pull request has now been integrated.

Changeset: 844118a9
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/844118a9d854459778f88d299b148c2288131344
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse Exception: Invalid or unrecognized bugid: 50510568367702

Reviewed-by: syan, azvegint, kizune, jdv

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

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

From honkar at openjdk.org  Thu Oct 16 17:27:40 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 16 Oct 2025 17:27:40 GMT
Subject: RFR: 8342401: [TESTBUG]
 javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu
 22.04 on SBR Hosts [v2]
In-Reply-To: <VOqMsltbQLXPrG5frR2XxrMkoJipDLoX2k3RNy_Klxg=.175d6424-32a9-4034-ac53-603a7cdeba77@github.com>
References: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
 <VOqMsltbQLXPrG5frR2XxrMkoJipDLoX2k3RNy_Klxg=.175d6424-32a9-4034-ac53-603a7cdeba77@github.com>
Message-ID: <hVi98x5hOPXiNn_fp0u4jSgrxIghmmpgaAbdMjBtaF0=.37dd7b5f-9c01-4044-85db-81cd57da1b54@github.com>

On Thu, 16 Oct 2025 02:02:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test probably was failing due to lack of delay between UI creation and test execution..Delay is added along with rendering frame at screen centre..Also added listener closer to UI creation within EDT
>> CI run for 100 iterations are ok on all platforms..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

LGTM apart from the minor inline suggestion.

test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java line 96:

> 94: 
> 95:                     frame.setAlwaysOnTop(true);
> 96:                     frame.setSize(100, 100);

Minor: I would recommend increasing the width to 300 so that the title of the frame is visible. (In past there have been cases of stray windows during CI, having a visible frame title makes it easier to identify problematic tests)

Suggestion:

                    frame.setSize(300, 100);

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27815#pullrequestreview-3346061853
PR Review Comment: https://git.openjdk.org/jdk/pull/27815#discussion_r2436814853

From serb at openjdk.org  Thu Oct 16 17:35:31 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 17:35:31 GMT
Subject: RFR: 8342401: [TESTBUG]
 javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu
 22.04 on SBR Hosts [v2]
In-Reply-To: <VOqMsltbQLXPrG5frR2XxrMkoJipDLoX2k3RNy_Klxg=.175d6424-32a9-4034-ac53-603a7cdeba77@github.com>
References: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
 <VOqMsltbQLXPrG5frR2XxrMkoJipDLoX2k3RNy_Klxg=.175d6424-32a9-4034-ac53-603a7cdeba77@github.com>
Message-ID: <aZ_ka06oa5JUo0I23A6HDCH_kAhgICSSDZ724PGY8mE=.b03f4971-dbeb-4ddc-aa9c-a8c7cf159c42@github.com>

On Thu, 16 Oct 2025 02:02:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test probably was failing due to lack of delay between UI creation and test execution..Delay is added along with rendering frame at screen centre..Also added listener closer to UI creation within EDT
>> CI run for 100 iterations are ok on all platforms..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27815#pullrequestreview-3346116264

From azvegint at openjdk.org  Thu Oct 16 17:35:32 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 16 Oct 2025 17:35:32 GMT
Subject: RFR: 6453640: BandedSampleModel.createCompatibleSampleModel() API
 docs are wrong
In-Reply-To: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
References: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
Message-ID: <b9zaKbws3Mx0w5qEvsuFw6Hp_emoNHCS-_jLjJQVcKE=.67eb9267-91cd-4542-93f2-6b710f332840@github.com>

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

> This corrects some omissions / errors in BandedSampleModel docs and adds a test to verify them.
> 
> CSR here https://bugs.openjdk.org/browse/JDK-8369849

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27806#pullrequestreview-3346118881

From serb at openjdk.org  Thu Oct 16 17:39:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 17:39:33 GMT
Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB
 conversion
In-Reply-To: <uGPIYHkjIbxRmh5RmDbz2x9-tU9CVRoQ7f9o3-l7jrc=.c40b12ce-297a-4198-b966-041866ad4cbf@github.com>
References: <uGPIYHkjIbxRmh5RmDbz2x9-tU9CVRoQ7f9o3-l7jrc=.c40b12ce-297a-4198-b966-041866ad4cbf@github.com>
Message-ID: <bQIpDjCxJPBR6rwkmvU6N9kaUW_8U_DxKgwnfLgNeF0=.ab357a2d-16b0-4684-9c8e-6fe51dda1b10@github.com>

On Tue, 14 Oct 2025 05:25:44 GMT, Phil Race <prr at openjdk.org> wrote:

> color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short.
> More details in JBS.

src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java line 811:

> 809:                 for (int x = 0; x < w; x++) {
> 810:                     pixel = srcRas.getDataElements(x, y, pixel);
> 811:                     color = srcCM.getNormalizedComponents(pixel, null, 0);

Since this is executed for each pixel, it will generate garbage equal to the image size. Maybe we can cleanly split the usage of the two vars here? Note that the bug only occurs when the source image does not use an ICC profile, but this change would increase garbage for both ICC and non-ICC profiles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2436869668

From serb at openjdk.org  Thu Oct 16 18:26:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 18:26:51 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v3]
In-Reply-To: <ysIiX3VFpzWpH6HBe33EFZuRYeGau6wdenog1uSRDLc=.04b733a8-ae0f-4479-8c3a-873c98bf98ab@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f9PSjXuCRbIv9MmRAMww3Lr6tKHEKgLIXQ0Nk8f2aV0=.e3295676-168c-480d-b89a-caccdeeb4d39@github.com>
 <AG_nNYcM_ZF06Kla9v93LhPPB3kSJuFoKpIdXC-NOeo=.a762fc9e-ad90-4408-8676-9e7c314391bb@github.com>
 <jcQunL4UBLi2TYXa_d7BusNqCDgBwIjwlrRda9fbcTc=.ba87c749-d19b-4f46-a7cb-aa03e01b378b@github.com>
 <Sr9Waor7MPhu8WkEddohMKwyaSkRO3bc8jTVTtddf1g=.770dff08-0bf1-4465-8775-3684d1cd5625@github.com>
 <L5vGJYo_jLYqxoN7FNY3mHzfrbk5_PJ5OKQFv835KeU=.d2f27745-8e3f-411b-86fa-5b076951a037@github.com>
 <yiazDqgIY1S4bZ5tT2FQer3uIdix59pGaTkVRUnxNVA=.b33b6a31-d178-4de2-9994-5ae893e900f0@github.com>
 <ysIiX3VFpzWpH6HBe33EFZuRYeGau6wdenog1uSRDLc=.04b733a8-ae0f-4479-8c3a-873c98bf98ab@github.com>
Message-ID: <xnElbTyi02galjk8630FhHt5UP0uNdH27WEFemzbPOs=.123100d3-bd83-4fcc-86f8-a5ba3463c369@github.com>

On Thu, 16 Oct 2025 07:37:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess it is strongly discouraged to have sleep in EDT to ensure UI does not become unresponsive.

It is not forbidden and should work. It is fine to have such code in the test, it may trigger some suspicious behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3412250276

From serb at openjdk.org  Thu Oct 16 18:28:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 18:28:47 GMT
Subject: RFR: 6185110: Undefined behaviour of SampleModel for width,
 height < 0
In-Reply-To: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
References: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
Message-ID: <DNn5LtgCHlzTbjNA_EEYxhdxkMmeqsF2nIL6F6T-Njw=.e98ccfd1-0127-493b-ba6d-6b20c6b93b6f@github.com>

On Fri, 10 Oct 2025 22:30:53 GMT, Phil Race <prr at openjdk.org> wrote:

>This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited.

May be it is better to add them to the "@throws" list instead of duplicating the spec?

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

PR Comment: https://git.openjdk.org/jdk/pull/27754#issuecomment-3412260773

From serb at openjdk.org  Thu Oct 16 18:33:44 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 18:33:44 GMT
Subject: RFR: 8068310: [TEST_BUG] Test
 javax/swing/JColorChooser/Test4234761.java fails with GTKL&F
In-Reply-To: <LsrWtHnCJfea_oQZ-3kTiwNlsqV6MPWcP9DClQJcfQw=.07cd7157-ced2-48de-bae5-a9f89067c76c@github.com>
References: <LsrWtHnCJfea_oQZ-3kTiwNlsqV6MPWcP9DClQJcfQw=.07cd7157-ced2-48de-bae5-a9f89067c76c@github.com>
Message-ID: <jOCI_Sh7gYpqpblnunPpT4H9Dl1EZOHQHwQ8zB1lu0U=.db75d5eb-85f0-44ab-99f5-b8d4a0352986@github.com>

On Thu, 16 Oct 2025 04:53:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in GTK L&F as test attempts to cast JColorChooser component to JTabbedPane but colorChooser UI is different in GTK L&F without tabbedpane as seen below so restricted it for GTK run
> 
> <img width="579" height="404" alt="image" src="https://github.com/user-attachments/assets/79c23377-5ab3-48a5-a02f-c93b8885e4bd" />
> 
> unlike Metal
> 
> <img width="622" height="381" alt="image" src="https://github.com/user-attachments/assets/ee9a8433-6766-403e-b3c0-dfe441200f96" />

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27836#pullrequestreview-3346418456

From serb at openjdk.org  Thu Oct 16 19:01:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 19:01:32 GMT
Subject: RFR: 6453640: BandedSampleModel.createCompatibleSampleModel() API
 docs are wrong
In-Reply-To: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
References: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
Message-ID: <RawHF4DFiCrwDExBkhi4Upv5ngajjjR_gBc-VWzuFwU=.7ec491f6-17f1-476b-bc0a-833695040cfc@github.com>

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

> This corrects some omissions / errors in BandedSampleModel docs and adds a test to verify them.
> 
> CSR here https://bugs.openjdk.org/browse/JDK-8369849

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27806#pullrequestreview-3346549565

From serb at openjdk.org  Thu Oct 16 19:08:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 19:08:07 GMT
Subject: RFR: 6453640: BandedSampleModel.createCompatibleSampleModel() API
 docs are wrong
In-Reply-To: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
References: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
Message-ID: <0Q0kk5inlBQOWFFWNsrmPN9VIbehW0nUqpvosV0Qe2Q=.4e5ba0e1-545b-4f35-80e9-4adcfbe1347e@github.com>

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

> This corrects some omissions / errors in BandedSampleModel docs and adds a test to verify them.
> 
> CSR here https://bugs.openjdk.org/browse/JDK-8369849

src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java line 146:

> 144:      * @throws IllegalArgumentException if the product of {@code w}
> 145:      *         and {@code h} is greater than {@code Integer.MAX_VALUE}
> 146:      *         or {@code w} or {@code h} is not greater than 0.

Note that it does not mention limitation related to the maximum size of the array, so if we will reuse this in BI we may store a little bit more data than max_int.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27806#discussion_r2437166140

From prr at openjdk.org  Thu Oct 16 19:22:42 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Oct 2025 19:22:42 GMT
Subject: RFR: 6185110: Undefined behaviour of SampleModel for width,
 height < 0
In-Reply-To: <DNn5LtgCHlzTbjNA_EEYxhdxkMmeqsF2nIL6F6T-Njw=.e98ccfd1-0127-493b-ba6d-6b20c6b93b6f@github.com>
References: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
 <DNn5LtgCHlzTbjNA_EEYxhdxkMmeqsF2nIL6F6T-Njw=.e98ccfd1-0127-493b-ba6d-6b20c6b93b6f@github.com>
Message-ID: <I_NOWCl0A-jhP7oUzZL2B2EhPOpkW48tM_r1cZELA2E=.0d3d3e26-20ec-419c-aadd-8f71a6c0b9fa@github.com>

On Thu, 16 Oct 2025 18:26:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > This because if it isn't an exception in the method signature (as in foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited.
> 
> May be it is better to add them to the "@throws" list instead of duplicating the spec?

That would not help. In fact it makes it harder.
RuntimeExceptions aren't inherited in the method signature so I'd need to add them there in the subclass anyway in addition to what I am already doing with the @throws.

Then I'd feel obliged to change lots of similar things to be consistent and this is already big enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/27754#issuecomment-3412518256

From prr at openjdk.org  Thu Oct 16 20:10:48 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Oct 2025 20:10:48 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v7]
In-Reply-To: <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
Message-ID: <tNO49qVatmoP86iem_XZvQzy4hu5-EaSPlnEFkpjIdo=.111a92b2-13b3-408d-bc53-0a7ceb1c6dd6@github.com>

On Fri, 26 Sep 2025 07:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test used to timeout even though it seems the test passed..Increased the timeout to a safe value as sometimes it shows elapsed time to timeout > 300secs in macOS in CI and also ensured the wait-time for child process to execute the test is not been waiting endlessly.
>> Also ensured the original display mode is resetted after the test to prevent affecting following tests.
>> 
>> Tried 100 iterations of the fix on all platforms which is ok
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - PL updation
>  - Merge master
>  - Added mac ARM JBS
>  - PL updation
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273617
>  - Remove displayMode reset
>  - EDT fix, timeout reduced
>  - 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12

Something is still not right and I don't think it is just a test problem.

Both the old and new version of UninitializedDisplayModeChangeTest hang for me.
And they also hang If I run DisplayModeChanger directly.
In all cases it looks like it a call to setNativeDisplayMode isn't returning,
This corresponds to test code line
            EventQueue.invokeAndWait(() -> gd.setFullScreenWindow(null));

I'm on an M4 Mac Pro running 15.7.1, but I'm using my external display.


Display Changer stdout output >    java.lang.Thread.State: RUNNABLE
Display Changer stdout output > 	at sun.awt.CGraphicsDevice.nativeSetDisplayMode(java.desktop at 25/Native Method)
Display Changer stdout output > 	at sun.awt.CGraphicsDevice.setDisplayMode(java.desktop at 25/CGraphicsDevice.java:314)
Display Changer stdout output > 	at sun.awt.CGraphicsDevice.setFullScreenWindow(java.desktop at 25/CGraphicsDevice.java:238)
Display Changer stdout output > 	- locked <0x000000043f886168> (a sun.awt.CGraphicsDevice)
Display Changer stdout output > 	at DisplayModeChanger.lambda$main$1(DisplayModeChanger.java:63)
Display Changer stdout output > 	at DisplayModeChanger$$Lambda/0x0000078001040438.run(Unknown Source)
Display Changer stdout output > 	at java.awt.event.InvocationEvent.dispatch(java.desktop at 25/InvocationEvent.java:313)
Display Changer stdout output > 	at java.awt.EventQueue.dispatchEventImpl(java.desktop at 25/EventQueue.java:723)
Display Changer stdout output > 	at java.awt.EventQueue.dispatchEvent(java.desktop at 25/EventQueue.java:702)
Display Changer stdout output > 	at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop at 25/EventDispatchThread.java:203)
Display Changer stdout output > 	at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop at 25/EventDispatchThread.java:124)
Display Changer stdout output > 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(java.desktop at 25/EventDispatchThread.java:113)
Display Changer stdout output > 	at java.awt.EventDispatchThread.pumpEvents(java.desktop at 25/EventDispatchThread.java:109)
Display Changer stdout output > 	at java.awt.EventDispatchThread.pumpEvents(java.desktop at 25/EventDispatchThread.java:101)
Display Changer stdout output > 	at java.awt.EventDispatchThread.run(java.desktop at 25/EventDispatchThread.java:90)
Display Changer stdout output >

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

PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3412659441

From dgredler at openjdk.org  Thu Oct 16 21:16:09 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 16 Oct 2025 21:16:09 GMT
Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses
 font transform
In-Reply-To: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
References: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
Message-ID: <pQsYIV0hs9jXheolOMjsR2LXYeCeqSgxNZWgrbojzSY=.d08cac38-4bd0-4953-af78-c558df926c88@github.com>

On Mon, 29 Sep 2025 11:46:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> When printing text on macOS, if the text uses a composite font (a logical font composed of more than one physical font) with a custom affine transform, the transform can be lost, and the text printed without the transform applied.
> 
> This is one of a few issues affecting the problem listed manual test `java/awt/print/PrinterJob/PrintTextTest.java` on macOS, and can be observed on page 10, on the last line ("TextLayout 2"). Without the fix, the text on this line is not stretched across the x-axis, resulting in large gaps of white space between runs of different script types.

This one is waiting for reviews, if anyone has a few spare cycles. I think once this PR is incorporated, macOS will only have issues with one page (page 8) of the `java/awt/print/PrinterJob/PrintTextTest.java` test case.

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

PR Comment: https://git.openjdk.org/jdk/pull/27544#issuecomment-3412872862

From dgredler at openjdk.org  Thu Oct 16 21:17:05 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 16 Oct 2025 21:17:05 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: <dtvTt6VvCpc19dWTj5VGvMfw028m7DoFMjPTIWsSSZo=.0c364710-7bff-453e-a6f2-9de37f938176@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.

@mrserb Does the explanation above make sense, in that the condition to "undo" something should match the condition used to decide to do it initially?

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

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

From prr at openjdk.org  Thu Oct 16 22:06:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Oct 2025 22:06:01 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
Message-ID: <GGA7hznqTZyauVPWCVk90hn-pHv0F1AfC1GX7DYEVss=.7ef1df3f-da23-4193-b4d3-cbfe9a09f2d5@github.com>

On Sun, 5 Oct 2025 22:16:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - 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

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27641#pullrequestreview-3347153766

From serb at openjdk.org  Thu Oct 16 23:35:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Oct 2025 23:35:02 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: <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
 <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
Message-ID: <pEOrpBu_-gUkwbi0JDitbBBUmXK1EBCV_IH4ujDt0-4=.32feb658-58bd-4ff7-a72a-8a132893cff6@github.com>

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

>> `GlyphMetrics` objects returned by `StandardGlyphVector.getGlyphMetrics(int)` contain bounds that are calculated by taking the glyph?s visual bounds and normalizing them by subtracting the glyph?s position.
>> 
>> However, some glyphs (e.g., the glyph for the space character) do not have visual bounds. Their outline is an empty shape. In such a case the bounds in the metrics should not be normalized by the glyph?s position. The code erroneously ignores this special case, thus producing bounds with inconsistent negative x-positions.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split long line

looks fine

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

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27580#pullrequestreview-3347350700

From honkar at openjdk.org  Fri Oct 17 00:08:05 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 17 Oct 2025 00:08:05 GMT
Subject: RFR: 8369032: Add test to ensure serialized ICC_Profile stores
 only necessary optional data [v2]
In-Reply-To: <xwtaVvzBXNnVQgx7gOREXl_jrh13pNuGPEgdRgDcGsw=.2bf54781-d27a-46e6-b1a0-ff30b9f60c37@github.com>
References: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
 <xwtaVvzBXNnVQgx7gOREXl_jrh13pNuGPEgdRgDcGsw=.2bf54781-d27a-46e6-b1a0-ff30b9f60c37@github.com>
Message-ID: <ctsWoG_x2GV5_QdcjnfYiFQnHhfh44vOAKBnexCiU2U=.47cdb5e9-954d-4d81-935e-fed30413dc25@github.com>

On Tue, 7 Oct 2025 18:01:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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

LGTM

test/jdk/java/awt/color/ICC_Profile/SerializedFormSize.java line 50:

> 48:             int dataSize = data.length;
> 49:             int min = 3; // At least version, name and data fields
> 50:             int max = 200; // Small enough to confirm no data saved

max = 200, does it account for header data (128 bytes) and some padding ?

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27616#pullrequestreview-3347462406
PR Review Comment: https://git.openjdk.org/jdk/pull/27616#discussion_r2437825938

From serb at openjdk.org  Fri Oct 17 00:47:10 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Oct 2025 00:47:10 GMT
Subject: RFR: 8369032: Add test to ensure serialized ICC_Profile stores
 only necessary optional data [v2]
In-Reply-To: <ctsWoG_x2GV5_QdcjnfYiFQnHhfh44vOAKBnexCiU2U=.47cdb5e9-954d-4d81-935e-fed30413dc25@github.com>
References: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
 <xwtaVvzBXNnVQgx7gOREXl_jrh13pNuGPEgdRgDcGsw=.2bf54781-d27a-46e6-b1a0-ff30b9f60c37@github.com>
 <ctsWoG_x2GV5_QdcjnfYiFQnHhfh44vOAKBnexCiU2U=.47cdb5e9-954d-4d81-935e-fed30413dc25@github.com>
Message-ID: <AjI-sUa1IVFty_0L_cVNysEFXiF1fgr22MKcP6BOgl0=.1c321bba-3244-4775-99a0-c56cf2530f9f@github.com>

On Fri, 17 Oct 2025 00:02:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 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
>
> test/jdk/java/awt/color/ICC_Profile/SerializedFormSize.java line 50:
> 
>> 48:             int dataSize = data.length;
>> 49:             int min = 3; // At least version, name and data fields
>> 50:             int max = 200; // Small enough to confirm no data saved
> 
> max = 200, does it account for header data (128 bytes) and some padding ?

200 does not include the actual profile data / the header, only a few strings and references.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27616#discussion_r2437924449

From psadhukhan at openjdk.org  Fri Oct 17 01:34:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 01:34:17 GMT
Subject: Integrated: 8342401: [TESTBUG]
 javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu
 22.04 on SBR Hosts
In-Reply-To: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
References: <v6Ef7MG3pHMt1uZvAZQSjigauEx6NNd5Eu7n5TYVKZg=.d133b455-4f12-4afc-af6a-9508a5bedbb3@github.com>
Message-ID: <1WcX72hA8d1_jklF63avhZaNGKTmAQ6c5aOTATRCBAQ=.ca9aaa31-dbfb-4047-a44f-160c0946aadc@github.com>

On Wed, 15 Oct 2025 07:41:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test probably was failing due to lack of delay between UI creation and test execution..Delay is added along with rendering frame at screen centre..Also added listener closer to UI creation within EDT
> CI run for 100 iterations are ok on all platforms..

This pull request has now been integrated.

Changeset: 55787fe5
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55787fe5f52544ea902cac35f1f552e26d954167
Stats:     24 lines in 1 file changed: 10 ins; 9 del; 5 mod

8342401: [TESTBUG] javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu 22.04 on SBR Hosts

Reviewed-by: honkar, serb

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

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

From psadhukhan at openjdk.org  Fri Oct 17 01:40:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 01:40:03 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v7]
In-Reply-To: <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
Message-ID: <OuWWSPqxroyynHgzTFoYG83eBw4x8DERnGsErjCkM6s=.3e9925de-6e8a-4d1a-8f60-40d6a977c1e6@github.com>

On Fri, 26 Sep 2025 07:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test used to timeout even though it seems the test passed..Increased the timeout to a safe value as sometimes it shows elapsed time to timeout > 300secs in macOS in CI and also ensured the wait-time for child process to execute the test is not been waiting endlessly.
>> Also ensured the original display mode is resetted after the test to prevent affecting following tests.
>> 
>> Tried 100 iterations of the fix on all platforms which is ok
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - PL updation
>  - Merge master
>  - Added mac ARM JBS
>  - PL updation
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273617
>  - Remove displayMode reset
>  - EDT fix, timeout reduced
>  - 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12

That is strange..It is working for me but on retina display but I believe CI osx systems all use external displays and it does not hang there it seems..

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

PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3413462175

From psadhukhan at openjdk.org  Fri Oct 17 01:36:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 01:36:13 GMT
Subject: Integrated: 8068310: [TEST_BUG] Test
 javax/swing/JColorChooser/Test4234761.java fails with GTKL&F
In-Reply-To: <LsrWtHnCJfea_oQZ-3kTiwNlsqV6MPWcP9DClQJcfQw=.07cd7157-ced2-48de-bae5-a9f89067c76c@github.com>
References: <LsrWtHnCJfea_oQZ-3kTiwNlsqV6MPWcP9DClQJcfQw=.07cd7157-ced2-48de-bae5-a9f89067c76c@github.com>
Message-ID: <F_eGf8M03bouLPc-D9nX_cz2lch3wHE3YB6hm26C-0U=.36ee8e2e-38c4-4245-bc25-85bfce07f04f@github.com>

On Thu, 16 Oct 2025 04:53:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in GTK L&F as test attempts to cast JColorChooser component to JTabbedPane but colorChooser UI is different in GTK L&F without tabbedpane as seen below so restricted it for GTK run
> 
> <img width="579" height="404" alt="image" src="https://github.com/user-attachments/assets/79c23377-5ab3-48a5-a02f-c93b8885e4bd" />
> 
> unlike Metal
> 
> <img width="622" height="381" alt="image" src="https://github.com/user-attachments/assets/ee9a8433-6766-403e-b3c0-dfe441200f96" />

This pull request has now been integrated.

Changeset: 31beb7d3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/31beb7d3b34c3516c326c9d29a267f6becb38805
Stats:     12 lines in 1 file changed: 9 ins; 1 del; 2 mod

8068310: [TEST_BUG] Test javax/swing/JColorChooser/Test4234761.java fails with GTKL&F

Reviewed-by: serb

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

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

From psadhukhan at openjdk.org  Fri Oct 17 03:42:30 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 03:42:30 GMT
Subject: RFR: 8026776: Broken API names in API doc
Message-ID: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>

Some of the name typos are corrected

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

Commit messages:
 - 8026776: Broken API names in API doc

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

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

From lbourges at openjdk.org  Fri Oct 17 05:46:13 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 17 Oct 2025 05:46:13 GMT
Subject: Integrated: 8341381: Random lines appear in graphic causing by the fix
 of JDK-8297230
In-Reply-To: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
Message-ID: <4nMpcLgI3U-PCPnXl_FcRa_JuhH0kaPtzT7uepO6LSg=.29e72533-ffca-46ab-9054-5ea096b82236@github.com>

On Sun, 5 Oct 2025 22:16:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - 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

This pull request has now been integrated.

Changeset: 46c23bb1
Author:    Laurent Bourg?s <lbourges at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9
Stats:     657 lines in 5 files changed: 620 ins; 1 del; 36 mod

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

Reviewed-by: prr

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

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

From kizune at openjdk.org  Fri Oct 17 06:49:04 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 17 Oct 2025 06:49:04 GMT
Subject: RFR: 8365077: java.awt.font.NumericShaper violates equals/hashCode
 contract
In-Reply-To: <qU_CK51GAimmcyZpFLtmkMZDlB24zUFZ84kNSNDuvbw=.1316d201-081a-449b-9b2d-d829bbc198a4@github.com>
References: <qU_CK51GAimmcyZpFLtmkMZDlB24zUFZ84kNSNDuvbw=.1316d201-081a-449b-9b2d-d829bbc198a4@github.com>
Message-ID: <trJxunOLpb8rOXgPaBtpoqI5O9hQecxMSF0WGr1H4Gc=.fa31f70d-3bf5-4ba4-9ed7-6a0f1b328ccb@github.com>

On Mon, 13 Oct 2025 17:53:44 GMT, Phil Race <prr at openjdk.org> wrote:

> The problem here is that NumericShaper can be constructed either using Range enum members
> or a bitmask.
> And the bitmask can represent the same (equal) NumericShaper as one constructed using
> the equivalent Range enum members and "boolean equals(Object)" handles this and there
> is support in the Range enum for a Set<Range> for this which is used by equals.
> 
> However the hashCode() does not have similar support and is quite different.
> The fix adds support for this.
> If the instance has a Set<Range> then use this new support, which will return
> the same hash as if it was constructed using a mask. In cases where this is not
> possible because Range instances  have no mask equivalent there is no issue
> because these cannot be equal either.
> 
> 
> EASTERN_ARABIC over-rides ARABIC and there was an inconsistency in that
> when constructed with Ranges this ARABIC is removed but this isn't the case
> for when constructed with masks. 
> I had to fix that so that the hashes would be the same.
> 
> I also made one variable final that should have been final all along.
>  
> A test is provided.

Looks reasonable and test works as expected.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27774#pullrequestreview-3348538055

From kizune at openjdk.org  Fri Oct 17 06:49:07 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 17 Oct 2025 06:49: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: <03b70vsEWoe6Ca_8j0PgtLxCaSSsx0UldaNKs8cCsNA=.e319422d-58df-49c8-915c-1d76532f1862@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

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26826#pullrequestreview-3348540132

From tr at openjdk.org  Fri Oct 17 07:10:02 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 17 Oct 2025 07:10:02 GMT
Subject: RFR: 8026776: Broken API names in API doc
In-Reply-To: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
Message-ID: <a6G-kweGutou2PBW7zvEpcHGI13iGRMaMTA7Rq6TWwg=.91b41e9d-e0a5-4d20-81f8-e832ad9e54e7@github.com>

On Fri, 17 Oct 2025 03:36:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Some of the name typos are corrected

I see another place where "RenderedImageOp" is used, can we correct that too ? - https://github.com/openjdk/jdk/blob/46c23bb1a252916096876c2ae3a72f4a525dd6f9/src/java.desktop/share/classes/java/awt/image/renderable/ContextualRenderedImageFactory.java#L44

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

PR Review: https://git.openjdk.org/jdk/pull/27860#pullrequestreview-3348598031

From tr at openjdk.org  Fri Oct 17 07:14:06 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 17 Oct 2025 07:14:06 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
Message-ID: <aJP2gIePb-KO3VxCJRSae_x04j5pbqXv_iC90vfMlbw=.81ccf7e2-bab1-47da-88f9-1eec169ce5c1@github.com>

On Thu, 16 Oct 2025 09:25:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in GTKLookAndFeel with NPE
> 
> java.lang.NullPointerException
> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
> 
> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
> 
> Fix is made to not use these color to create BevelBorder if these colors are not present..

src/java.desktop/share/classes/javax/swing/BorderFactory.java line 156:

> 154:      */
> 155:     public static Border createBevelBorder(int type, Color highlight, Color shadow) {
> 156:         if (highlight != null && shadow != null) {

Should we update the doc about `null` case too ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27839#discussion_r2438628809

From psadhukhan at openjdk.org  Fri Oct 17 07:19:36 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 07:19:36 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
Message-ID: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>

> Some of the name typos are corrected

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

  Typo fix in another class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27860/files
  - new: https://git.openjdk.org/jdk/pull/27860/files/b196e4b4..8c6dd749

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

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

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

From psadhukhan at openjdk.org  Fri Oct 17 07:19:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 07:19:38 GMT
Subject: RFR: 8026776: Broken API names in API doc
In-Reply-To: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
Message-ID: <ybOpiVZvznTHSoe2JnWz0peJIADd40r__jjJG1rQN08=.491bc323-8d16-4c79-884d-dec9c742a9dd@github.com>

On Fri, 17 Oct 2025 03:36:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Some of the name typos are corrected

corrected

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3414179434

From psadhukhan at openjdk.org  Fri Oct 17 07:22:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 07:22:05 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <aJP2gIePb-KO3VxCJRSae_x04j5pbqXv_iC90vfMlbw=.81ccf7e2-bab1-47da-88f9-1eec169ce5c1@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <aJP2gIePb-KO3VxCJRSae_x04j5pbqXv_iC90vfMlbw=.81ccf7e2-bab1-47da-88f9-1eec169ce5c1@github.com>
Message-ID: <-26zBbyL8zGVFSfvziCIEtiaTsuJ6Qndf97Fl9YInRw=.fcfce828-44fa-4f08-8dee-99bea4c812e3@github.com>

On Fri, 17 Oct 2025 07:11:26 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Test fails in GTKLookAndFeel with NPE
>> 
>> java.lang.NullPointerException
>> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
>> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
>> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
>> 
>> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
>> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
>> 
>> Fix is made to not use these color to create BevelBorder if these colors are not present..
>
> src/java.desktop/share/classes/javax/swing/BorderFactory.java line 156:
> 
>> 154:      */
>> 155:     public static Border createBevelBorder(int type, Color highlight, Color shadow) {
>> 156:         if (highlight != null && shadow != null) {
> 
> Should we update the doc about `null` case too ?

Dont think its required..We are still returning a bevel border

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27839#discussion_r2438647986

From tr at openjdk.org  Fri Oct 17 07:22:09 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 17 Oct 2025 07:22:09 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <Q8wsMiqwZjalJtCHqULGDwM3czeXurdtkbRWBt1_2hU=.7326840d-7d04-4e08-afe0-7fdb87a17df4@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

src/java.desktop/share/classes/java/awt/image/renderable/ContextualRenderedImageFactory.java line 44:

> 42:  * functionality that may differ between instances of
> 43:  * RenderableImageOp.  Thus different operations on RenderableImages
> 44:  * may be performed by a single class such as RenderableImageOp through

Suggestion:

 * may be performed by a single class such as {@code RenderableImageOp} through

Should we add inline tag ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2438647160

From psadhukhan at openjdk.org  Fri Oct 17 07:24:02 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 07:24:02 GMT
Subject: RFR: 8365077: java.awt.font.NumericShaper violates equals/hashCode
 contract
In-Reply-To: <qU_CK51GAimmcyZpFLtmkMZDlB24zUFZ84kNSNDuvbw=.1316d201-081a-449b-9b2d-d829bbc198a4@github.com>
References: <qU_CK51GAimmcyZpFLtmkMZDlB24zUFZ84kNSNDuvbw=.1316d201-081a-449b-9b2d-d829bbc198a4@github.com>
Message-ID: <zCnUOlvctM7i4Ty1ifj44J2VuTgcrBJGNrmuaLHNKt4=.eb6056e6-faea-4687-9845-6d3803043dd3@github.com>

On Mon, 13 Oct 2025 17:53:44 GMT, Phil Race <prr at openjdk.org> wrote:

> The problem here is that NumericShaper can be constructed either using Range enum members
> or a bitmask.
> And the bitmask can represent the same (equal) NumericShaper as one constructed using
> the equivalent Range enum members and "boolean equals(Object)" handles this and there
> is support in the Range enum for a Set<Range> for this which is used by equals.
> 
> However the hashCode() does not have similar support and is quite different.
> The fix adds support for this.
> If the instance has a Set<Range> then use this new support, which will return
> the same hash as if it was constructed using a mask. In cases where this is not
> possible because Range instances  have no mask equivalent there is no issue
> because these cannot be equal either.
> 
> 
> EASTERN_ARABIC over-rides ARABIC and there was an inconsistency in that
> when constructed with Ranges this ARABIC is removed but this isn't the case
> for when constructed with masks. 
> I had to fix that so that the hashes would be the same.
> 
> I also made one variable final that should have been final all along.
>  
> A test is provided.

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27774#pullrequestreview-3348638179

From tr at openjdk.org  Fri Oct 17 07:30:03 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 17 Oct 2025 07:30:03 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <E4FxUbmuBGuhNpkU3wqvp5CqoiofYgL7TMQPR1b0s2A=.b71f177e-7b4c-4e2a-91d6-d8cb9bbcabf6@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27860#pullrequestreview-3348654496

From aghaisas at openjdk.org  Fri Oct 17 07:30:04 2025
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 17 Oct 2025 07:30:04 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <5XiLSmZpfXB2882TFkqq9HvgZ3umPOqka_8-NDaUvfc=.ea77f921-6692-489a-b17e-863f164282c7@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

This JBS lists a lot of broken API names. Is this list still valid?
I see that you have chosen to fix only a few.

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3414207997

From psadhukhan at openjdk.org  Fri Oct 17 07:30:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 07:30:05 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <LJLgu8b0PbYGoCRpM91LsDp9TfHtAXS2yH_3yYtVErU=.1f8a535e-6774-414c-ab1c-cbfab37396ba@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

Other awt/swing things are fixed already

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3414211373

From psadhukhan at openjdk.org  Fri Oct 17 07:30:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 07:30:07 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <Q8wsMiqwZjalJtCHqULGDwM3czeXurdtkbRWBt1_2hU=.7326840d-7d04-4e08-afe0-7fdb87a17df4@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
 <Q8wsMiqwZjalJtCHqULGDwM3czeXurdtkbRWBt1_2hU=.7326840d-7d04-4e08-afe0-7fdb87a17df4@github.com>
Message-ID: <5WOU9O5q9Hqegz68TdhZopW-owONhonu5sc_Yxsk2Yo=.2c003eaf-f085-49d1-83af-81cffe6b5bf3@github.com>

On Fri, 17 Oct 2025 07:19:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo fix in another class
>
> src/java.desktop/share/classes/java/awt/image/renderable/ContextualRenderedImageFactory.java line 44:
> 
>> 42:  * functionality that may differ between instances of
>> 43:  * RenderableImageOp.  Thus different operations on RenderableImages
>> 44:  * may be performed by a single class such as RenderableImageOp through
> 
> Suggestion:
> 
>  * may be performed by a single class such as {@code RenderableImageOp} through
> 
> Should we add inline tag ?

it is not used in this paragraph for any other class so is not required only for this..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2438657285

From psadhukhan at openjdk.org  Fri Oct 17 08:15:02 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 08:15:02 GMT
Subject: RFR: 6185110: Undefined behaviour of SampleModel for width,
 height < 0
In-Reply-To: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
References: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
Message-ID: <OMK1ZQ-T3hly23eI_5oSt4Oi_L48MwQyQD7RnWoIIhs=.629cafdc-9aab-4dd0-907f-afe727e7226a@github.com>

On Fri, 10 Oct 2025 22:30:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The only significant change here is to ensure that all SampleModel types throw a specified exception if a client
> calls any of the following methods with a negative width or height.
> getPixels(..)
> setPixels(..)
> getSamples(..)
> setSamples(..)
> 
> The rest is fixing the javadoc to properly describe what happens and some minor cleanup.
> I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them.
> I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method.
> There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions
> are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in  foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited.
> 
> I added a test which verifies the behaviour for illegal arguments.
> 
> CSR is here https://bugs.openjdk.org/browse/JDK-8369623

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27754#pullrequestreview-3348807187

From jdv at openjdk.org  Fri Oct 17 08:20:07 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 17 Oct 2025 08:20:07 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: <IkEd4UOXg5OdUF6Elhl2nzSv17q-4ShbEQVURNxB8Yo=.df20d3c0-824f-4462-b7ce-2eb76b5aaf50@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

I have gone through most of the code paths and its good that now the API clearly states  exceptions that can be thrown by lower level code.

Since we have difference in expected exception at some places, please make sure there are no JCK/jtreg failures with this update.

test/jdk/java/awt/image/Raster/CreateRasterExceptionTest.java line 56:

> 54:     /**
> 55:       * If running on a JDK of the targetVersion or later, throw
> 56:       * a RuntimeException becuase the exception argument

"because"

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27627#pullrequestreview-3348809355
PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2438790445

From psadhukhan at openjdk.org  Fri Oct 17 08:24:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 08:24:08 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v3]
In-Reply-To: <2-0rVj4i6A0ndg96LExAn8UD6Wn_EXfYeIbDW45o55A=.2e6316e1-7398-4808-95ee-9579079faf8f@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <2-0rVj4i6A0ndg96LExAn8UD6Wn_EXfYeIbDW45o55A=.2e6316e1-7398-4808-95ee-9579079faf8f@github.com>
Message-ID: <-ovD4w-N1RHMlZ0ImzN8guVkEcSUn48oa1UyR0c6cHk=.ec23e81c-dbdf-496d-bb94-027cf026bd9e@github.com>

On Tue, 14 Oct 2025 08:58:24 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add EUDC.tte restoration

test/jdk/java/awt/8368882/FallbackFontNPE.sh line 56:

> 54:    Reg DELETE "${reg_eudc_1252}" /va /f
> 55: fi
> 56: Reg import eudc.reg

Dont think we are allowed to push binary files..Cant we check using 
`-Duser.language `or 
`new Locale(ja, JP)`

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

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

From ayang at openjdk.org  Fri Oct 17 09:07:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:07:13 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <Gz6ncclFSmvp8OhrUx2U5RJhbemzMxwxpguthwTc49o=.080b8577-4bbc-4056-b4b0-f36c03613fd9@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27860#pullrequestreview-3349011234

From snazarki at openjdk.org  Fri Oct 17 09:50:18 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 17 Oct 2025 09:50:18 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v3]
In-Reply-To: <-ovD4w-N1RHMlZ0ImzN8guVkEcSUn48oa1UyR0c6cHk=.ec23e81c-dbdf-496d-bb94-027cf026bd9e@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <2-0rVj4i6A0ndg96LExAn8UD6Wn_EXfYeIbDW45o55A=.2e6316e1-7398-4808-95ee-9579079faf8f@github.com>
 <-ovD4w-N1RHMlZ0ImzN8guVkEcSUn48oa1UyR0c6cHk=.ec23e81c-dbdf-496d-bb94-027cf026bd9e@github.com>
Message-ID: <tDl-RQrjkMle651He6bUMpYpzJlXfn1FhVm7aodC5ac=.458cdff5-d8c2-464f-a61e-a02c989da7c3@github.com>

On Fri, 17 Oct 2025 08:21:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add EUDC.tte restoration
>
> test/jdk/java/awt/8368882/FallbackFontNPE.sh line 56:
> 
>> 54:    Reg DELETE "${reg_eudc_1252}" /va /f
>> 55: fi
>> 56: Reg import eudc.reg
> 
> Dont think we are allowed to push binary files..Cant we check using 
> `-Duser.language `or 
> `new Locale(ja, JP)`

The test doesn't change locale, and CLI settings doesn't help since native AWT library uses system [GetSystemDefaultLangID](https://github.com/openjdk/jdk/blob/0a97bef840f8799313a1a55a65d9334e09cc1cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L238) call.

And unfortunately without this file whole test is useless.

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

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

From tr at openjdk.org  Fri Oct 17 09:50:18 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 17 Oct 2025 09:50:18 GMT
Subject: RFR: 8368576: PrintJob.getGraphics() does not specify behavior
 after PrintJob.end()
In-Reply-To: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
References: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
Message-ID: <1Mf8zYiTJ9rFLv0oTNFWETcdE6qGiY3H1IukTL_rkMY=.605dcdd4-b65d-46ac-852b-85a50eea8b59@github.com>

On Wed, 24 Sep 2025 16:43:13 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the spec. of java.awt.PrintJob.getGraphics() to document long standing behaviour after PrintJob.end() has been called.
> 
> A CSR has been created https://bugs.openjdk.org/browse/JDK-8368577

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27474#pullrequestreview-3349159261

From tr at openjdk.org  Fri Oct 17 09:56:09 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 17 Oct 2025 09:56:09 GMT
Subject: RFR: 8299304: Test "java/awt/print/PrinterJob/PageDialogTest.java"
 fails on macOS 13 x64 because the Page Dialog blocks the Toolkit
In-Reply-To: <QFHd5fl33BWtFusrpHqoViPZwpEH7-xEYTH0VxcUgJ4=.007d5c24-2aba-47f1-8b86-9d2a7bba3960@github.com>
References: <QFHd5fl33BWtFusrpHqoViPZwpEH7-xEYTH0VxcUgJ4=.007d5c24-2aba-47f1-8b86-9d2a7bba3960@github.com>
Message-ID: <VF8SnJoXONIWANsYduP2IA-BaLN3gxne0bbsro4OZGA=.b2b51116-5c42-4bc2-8372-9362e7e3bfa5@github.com>

On Fri, 12 Sep 2025 05:44:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> mac printer dialog blocks underlying window even on native platform so this is not applicable to the test so restricting to run on osx

Please update the copyright.

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

PR Review: https://git.openjdk.org/jdk/pull/27243#pullrequestreview-3349177570

From psadhukhan at openjdk.org  Fri Oct 17 10:14:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Oct 2025 10:14:55 GMT
Subject: RFR: 8299304: Test "java/awt/print/PrinterJob/PageDialogTest.java"
 fails on macOS 13 x64 because the Page Dialog blocks the Toolkit
In-Reply-To: <VF8SnJoXONIWANsYduP2IA-BaLN3gxne0bbsro4OZGA=.b2b51116-5c42-4bc2-8372-9362e7e3bfa5@github.com>
References: <QFHd5fl33BWtFusrpHqoViPZwpEH7-xEYTH0VxcUgJ4=.007d5c24-2aba-47f1-8b86-9d2a7bba3960@github.com>
 <VF8SnJoXONIWANsYduP2IA-BaLN3gxne0bbsro4OZGA=.b2b51116-5c42-4bc2-8372-9362e7e3bfa5@github.com>
Message-ID: <IsFiVmGVYIYelowFCN_-EcoI2NnfTMPODf8j3CFAOus=.95ecc599-248a-419d-995a-ac3da9910340@github.com>

On Fri, 17 Oct 2025 09:52:59 GMT, Tejesh R <tr at openjdk.org> wrote:

> Please update the copyright.

It is not mandatory and shouldn't stop the approval unless youhave anything else technical..

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

PR Comment: https://git.openjdk.org/jdk/pull/27243#issuecomment-3414789702

From snazarki at openjdk.org  Fri Oct 17 10:20:49 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 17 Oct 2025 10:20:49 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v4]
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: <aIQzomqZimFp9qkFyYN-KysEIcr-A5OO08JxuEP3ntg=.c4862d80-cd01-4888-8732-7b5ffdcf1c7e@github.com>

> 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.

Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:

  Get rid of binary file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27551/files
  - new: https://git.openjdk.org/jdk/pull/27551/files/08e62316..386b0206

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

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

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

From snazarki at openjdk.org  Fri Oct 17 10:20:53 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 17 Oct 2025 10:20:53 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v3]
In-Reply-To: <tDl-RQrjkMle651He6bUMpYpzJlXfn1FhVm7aodC5ac=.458cdff5-d8c2-464f-a61e-a02c989da7c3@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <2-0rVj4i6A0ndg96LExAn8UD6Wn_EXfYeIbDW45o55A=.2e6316e1-7398-4808-95ee-9579079faf8f@github.com>
 <-ovD4w-N1RHMlZ0ImzN8guVkEcSUn48oa1UyR0c6cHk=.ec23e81c-dbdf-496d-bb94-027cf026bd9e@github.com>
 <tDl-RQrjkMle651He6bUMpYpzJlXfn1FhVm7aodC5ac=.458cdff5-d8c2-464f-a61e-a02c989da7c3@github.com>
Message-ID: <659tPhmXi2dT4XmsZgV0vXgopSX4qEDoXH87k9pc2jA=.7b89e498-61b1-4b08-963d-c286f0c432eb@github.com>

On Fri, 17 Oct 2025 09:47:36 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> test/jdk/java/awt/8368882/FallbackFontNPE.sh line 56:
>> 
>>> 54:    Reg DELETE "${reg_eudc_1252}" /va /f
>>> 55: fi
>>> 56: Reg import eudc.reg
>> 
>> Dont think we are allowed to push binary files..Cant we check using 
>> `-Duser.language `or 
>> `new Locale(ja, JP)`
>
> The test doesn't change locale, and CLI settings doesn't help since native AWT library uses system [GetSystemDefaultLangID](https://github.com/openjdk/jdk/blob/0a97bef840f8799313a1a55a65d9334e09cc1cf4/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsEnv.cpp#L238) call.
> 
> And unfortunately without this file whole test is useless.

I had another conversation with my rubber duck, and it came to light that the test can use any system default TTF font as EUDC.tte. Updated the test

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

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

From duke at openjdk.org  Fri Oct 17 10:26:40 2025
From: duke at openjdk.org (eduardsdv)
Date: Fri, 17 Oct 2025 10:26:40 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <rYvezc_aKEVDCPFLmr4UarIndwwE65Ch_GmCqvXhNbM=.52faca0b-1d1d-4c16-8bdd-8de79265cb53@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
 <rYvezc_aKEVDCPFLmr4UarIndwwE65Ch_GmCqvXhNbM=.52faca0b-1d1d-4c16-8bdd-8de79265cb53@github.com>
Message-ID: <AMa1qDtIGoxCSnW8xfOHvCYHQGq67IgHEktnxOS-KjA=.e9f0877b-b069-426b-8a13-a79ae1d9d328@github.com>

On Wed, 3 Sep 2025 01:41:44 GMT, Phil Race <prr at openjdk.org> wrote:

> So what I think happens is we are setting a range within a range.

I agree with @prrace's assumption.

I temporary changed the CPrinterJob.m and PrinterView.m files to use fix values.
The PrinterView.knowsPageRanges() method returned the range with location=2 and length=4.
The CPrinterJob.javaPrinterJobToNSPrintInfo() method used the fromPage and toPage values from the table below.
I tested it with a Java program (see the code block below), which always returned 5 when calling Pageable.getNumberOfPages().

Pageable.getNumberOfPages() |knowsPageRanges()| javaPrinterJobToNSPrintInfo() | printed pages |
|--|---|-----------------|-----------------------------|
|numberOfPages=5|location=2, length=4|fromPage=1, toPage=1| 2|
|numberOfPages=5|location=2, length=4|fromPage=1, toPage=5|2, 3, 4, 5|
|numberOfPages=5|location=2, length=4|fromPage=5, toPage=5| nothing |
|numberOfPages=5|location=2, length=4|fromPage=3, toPage=6| 4, 5 |

In my opinion, the fix is correct, and we still need the `knowsPageRanges()` method, which returns the range of available pages with location=1 and length=Pageable.getNumberOfPages(). Then, the `javaPrinterJobToNSPrintInfo()` method can process the page range that will actually be printed.



public class PageRanges {

    public static final int PAGES_COUNT = 5;

    public static void main(String args[]) throws Exception {
        PrinterJob job = PrinterJob.getPrinterJob();
        if (job.getPrintService() == null) {
            System.out.println("No printers. Test cannot continue.");
            return;
        }

        Printable printable = (g, pf, pi) -> {
            if (pi >= PAGES_COUNT) {
                return Printable.NO_SUCH_PAGE;
            }
            g.drawString("Page : " + (pi+1), 200, 200);
            return Printable.PAGE_EXISTS;
        };


        job.setPageable(new Pageable() {
            @Override
            public int getNumberOfPages() {
                return PAGES_COUNT;
            }

            @Override
            public PageFormat getPageFormat(int pageIndex) throws IndexOutOfBoundsException {
                return new PageFormat();
            }

            @Override
            public Printable getPrintable(int pageIndex) throws IndexOutOfBoundsException {
                return printable;
            }
        });

        PrintRequestAttributeSet attributes = new HashPrintRequestAttributeSet();
        attributes.add(DialogTypeSelection.NATIVE);
        if (!job.printDialog(attributes)) {
            return;
        }
        job.print(attributes);
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3414847846

From lbourges at openjdk.org  Fri Oct 17 10:38:05 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 17 Oct 2025 10:38:05 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box
In-Reply-To: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
Message-ID: <CTgvLFxXdCAOcFLY7ZbleJ2mSSPGmUbRoRxOBBrouVc=.790e0b2b-1019-47bc-84db-cfb52f2eb592@github.com>

On Sun, 10 Aug 2025 04:35:43 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> 4197755 is marked as a duplicate of [JDK-8176501](https://bugs.openjdk.org/browse/JDK-8176501) , but I think that is a mistake. The complaint in that ticket still reproduces, and it is resolved in this PR.
> 
> The complaint is: Arc2D.getBounds() is too large. If an Arc2D represents a small slice of an ellipse, then Arc2D.getBounds() always returns the size of the total ellipse. Arc2D.getBounds2D(), by contrast, has been "high-precision" for decades.
> 
> This PR makes Arc2D.getBounds() resemble the same implementation already used in Area, CubicCurve2D, Line2D, Path2D, and QuadCurve2D:
> 
>     public Rectangle getBounds() {
>         return getBounds2D().getBounds();
>     }
> 
> 
> This modifies (simplifies) the javadoc for Arc2D.getBounds2D(). If we generally like this PR I assume we'll need a CSR to approve the javadoc change.

Please review, LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3414896684

From jdv at openjdk.org  Fri Oct 17 11:44:17 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 17 Oct 2025 11:44:17 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
Message-ID: <J9ndK9qQG7h3jVa_wnX5t8fKhsVUV9eo--M3iuuPJ2s=.8680163b-3e8f-4089-aeb9-2ad6c86ff63d@github.com>

On Wed, 8 Oct 2025 22:05:05 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix does a couple of things
> 
> 1) AffineTransformOp.createCompatibleDestImage() and AffineTransformOp.createCompatibleDestRaster() now specify that they will throw RasterFormatException if the transformed size is too large. They were already getting an exception.
> Note that inside the JDK only the imaging API implementation itself uses these APIs and I suspect they are rarely used by applications.
> 
> 2) AffineTransformOp.filter(src, null) will not throw an exception if it cannot create a destination image or raster of the required size and instead will use the source image size. This means applications which simply filter() will not need to carefully examine the transform. Sophisticated applications which want to do this can use the above "create*" methods to explicitly create the destination to find this out. 
> 
> So some inconsistency but I think it is a user-friendly trade-off.
> 
> A CSR will be needed but I want to get past initial review first.

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27707#pullrequestreview-3349760369

From kcr at openjdk.org  Fri Oct 17 12:25:38 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Oct 2025 12:25:38 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <aGNPMDyGteIeABvJ96_ZWU5aRX8nMzRSqbWjcqDqiig=.d2441a9a-4123-4e46-8f2d-baaac9eb7b69@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
 <aGNPMDyGteIeABvJ96_ZWU5aRX8nMzRSqbWjcqDqiig=.d2441a9a-4123-4e46-8f2d-baaac9eb7b69@github.com>
Message-ID: <A7bitpeFPR762TuN2bmiiZdU26mtk9fTCSPAf5hdcpI=.8cfd7a9a-e62f-4f8f-b61c-da8ceb454f0b@github.com>

On Mon, 13 Oct 2025 16:51:04 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> - 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
>
> Please review this fix...

@bourgesl PRs in client-libs require two reviewers. In the future, please wait for a second reviewer before integrating any PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3415345954

From lbourges at openjdk.org  Fri Oct 17 12:31:32 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 17 Oct 2025 12:31:32 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
Message-ID: <CfXG-MLSYOch-83h7yS-Oh3_VqtbtxxaW85NGJWZpJk=.d5624d06-48b8-44d0-887c-f5879794abdb@github.com>

On Sun, 5 Oct 2025 22:16:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - 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

So sorry. 
Would it be possible to let skara  respect this rule?

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3415370104

From duke at openjdk.org  Fri Oct 17 14:05:34 2025
From: duke at openjdk.org (Christian Heilmann)
Date: Fri, 17 Oct 2025 14:05:34 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
Message-ID: <C8N_wyX6Qs6xs6ww_PV7tyhwHyseiv7sQdk_B0QnwLk=.40968533-1c7b-4570-931d-452ab5919df1@github.com>

On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann <duke at openjdk.org> wrote:

>> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
>> 
>> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.
>
> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
>  - Merge branch 'master' into pr/11266
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS

Test precondition providing 5 pages.
I tested **successfully** the following with native print dialog and swing (common) print dialog:

**Test with native (DialogTypeSelection.NATIVE) print dialog**
|Pageable.getNumberOfPages|PrintRequestAttributeSet|manual enter range in print dialog|printed pages|
|---|---|---|---|
|5|-|all pages|1 - 5|
|5|-|1 - 5|1 - 5|
|5|-|1 - 1|1|
|5|-|5 - 5|5|
|5|-|2 - 4|2 - 4|
|5|PageRanges(3, 5)|-|3 - 5|
|5|PageRanges(3, 5)|all pages|1 - 5|
|5|PageRanges(3, 5)|1 - 5|1 - 5|
|5|PageRanges(5, 5)|-|5|
|UNKNOWN_NUMBER_OF_PAGES|-|all pages|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|-|1 - 5|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|PageRanges(3, 5)|all pages|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|PageRanges(3, 5)|1 - 5|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|PageRanges(3, 5)|2 - 2|2|

**Test with Swing (DialogTypeSelection.COMMON) print dialog**
|Pageable.getNumberOfPages|PrintRequestAttributeSet|manual enter range in print dialog|printed pages|
|---|---|---|---|
|5|-|all pages|1 - 5|
|5|-|1 - 5|1 - 5|
|5|-|1 - 1|1|
|5|-|5 - 5|5|
|5|-|2 - 4|2 - 4|
|5|PageRanges(3, 5)|-|3 - 5|
|5|PageRanges(3, 5)|all pages|1 - 5|
|5|PageRanges(3, 5)|1 - 5|1 - 5|
|5|PageRanges(5, 5)|-|5|
|UNKNOWN_NUMBER_OF_PAGES|-|all pages|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|-|1 - 5|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|PageRanges(3, 5)|all pages|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|PageRanges(3, 5)|1 - 5|1 - 5|
|UNKNOWN_NUMBER_OF_PAGES|PageRanges(3, 5)|2 - 2|2|

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

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3415745572

From abaya at openjdk.org  Fri Oct 17 14:21:01 2025
From: abaya at openjdk.org (Anass Baya)
Date: Fri, 17 Oct 2025 14:21:01 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <ZVAVbndK552rdql1OvfcufUDZ5Vchswpgz47wzDSp6g=.172b4840-4662-403b-9ca7-fc8088048292@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <pinhFHmL7dV2JPraIoBXyvgOvPFhXpzSAoi5_gBcvaw=.ce398282-d271-4f3f-b1b7-c7452d8fe1b3@github.com>
 <tr3_UnZBasRmgFcenm7wdByC_dKty1EG0OJzWCgkvss=.cd03d3fa-af20-4140-baa9-421547cf0ab4@github.com>
 <ZVAVbndK552rdql1OvfcufUDZ5Vchswpgz47wzDSp6g=.172b4840-4662-403b-9ca7-fc8088048292@github.com>
Message-ID: <Ldil2LRhbp_mSIlQqpprOZD4Qx5N4Q31Ge6cglo3Guc=.219f6d6b-60fa-499d-9c4a-2c97689d2e05@github.com>

On Thu, 16 Oct 2025 16:41:43 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Hello @honkar-jdk,
>> Thank you for your follow-up.
>> Both our source code and the command use the same property, _NET_WORKAREA. When I noticed the issue, I thought that maybe we are misusing the _NET_WORKAREA in getScreenInsetsImpl(). However, as you can see in the traces in [JDK-8357390](https://bugs.openjdk.org/browse/JDK-8357390) , it returns the same values as the xprop command does.
>
> @anass-baya You mentioned previously that the difference might be related to window manager. Which window manager is used in the 2 cases (the one where the test passes vs fails) ?

Hello @honkar-jdk ,
> @anass-baya You mentioned previously that the difference might be related to window manager. Which window manager is used in the 2 cases (the one where the test passes vs fails) ?

We are not changeing the config. we are using GNOME with X11

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3415802260

From cushon at google.com  Fri Oct 17 15:23:43 2025
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 17 Oct 2025 17:23:43 +0200
Subject: HDR image support
In-Reply-To: <CAL4Qsgsiao1zr9RCU9WW85yxHuoRMmhPvTuHYKnd2SnZH1vpHg@mail.gmail.com>
References: <CAL4QsgsN8QqpwFVkaN+XOkNCsP05z_oFDXXR8Ha6Nyzs4Yt2BA@mail.gmail.com>
 <f8e0c31a-0f40-4876-a73b-5dd4d21b2b1b@oracle.com>
 <CAL4Qsgsiao1zr9RCU9WW85yxHuoRMmhPvTuHYKnd2SnZH1vpHg@mail.gmail.com>
Message-ID: <CAL4Qsgs7se7Se3-OUhXvshYZwvpSeXvR1HrEh9b_c71QtknrhQ@mail.gmail.com>

Also, I can't promise anything, but would there be any interest in
accepting contributions in this area? Or would they be unlikely to be
reviewed and accepted given current resourcing?

On Mon, Oct 13, 2025 at 2:19?PM Liam Miller-Cushon <cushon at google.com>
wrote:

> Understood, thanks for the response.
>
> On Fri, Oct 10, 2025 at 9:05?PM Phil Race <philip.race at oracle.com> wrote:
>
>> It is something we are aware of, but isn't something we are resourced to
>> do, not even to look into it.
>>
>> -phil.
>> On 10/6/2025 4:57, Liam Miller-Cushon wrote:
>>
>> 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/20251017/724af0b9/attachment.htm>

From philip.race at oracle.com  Fri Oct 17 17:54:44 2025
From: philip.race at oracle.com (Philip Race)
Date: Fri, 17 Oct 2025 10:54:44 -0700
Subject: HDR image support
In-Reply-To: <CAL4Qsgs7se7Se3-OUhXvshYZwvpSeXvR1HrEh9b_c71QtknrhQ@mail.gmail.com>
References: <CAL4QsgsN8QqpwFVkaN+XOkNCsP05z_oFDXXR8Ha6Nyzs4Yt2BA@mail.gmail.com>
 <f8e0c31a-0f40-4876-a73b-5dd4d21b2b1b@oracle.com>
 <CAL4Qsgsiao1zr9RCU9WW85yxHuoRMmhPvTuHYKnd2SnZH1vpHg@mail.gmail.com>
 <CAL4Qsgs7se7Se3-OUhXvshYZwvpSeXvR1HrEh9b_c71QtknrhQ@mail.gmail.com>
Message-ID: <c6d44b8d-355c-49cc-88ac-8b36ed5e8a1a@oracle.com>


We would definitely accept contributions which people are able to stand 
behind.
We always recommend that people float ideas here before appearing with a PR.
This exchange is a start on that but should also be done for the 
specific ideas.

Thanks,

-phil

On 10/17/25 8:23 AM, Liam Miller-Cushon wrote:
> Also, I can't promise anything, but would there be any interest in 
> accepting contributions in this area? Or would they be unlikely to be 
> reviewed and accepted given current resourcing?
>
> On Mon, Oct 13, 2025 at 2:19?PM Liam Miller-Cushon <cushon at google.com> 
> wrote:
>
>     Understood, thanks?for the response.
>
>     On Fri, Oct 10, 2025 at 9:05?PM Phil Race <philip.race at oracle.com>
>     wrote:
>
>         It is something we are aware of, but isn't something we are
>         resourced to do, not even to look into it.
>
>         -phil.
>
>         On 10/6/2025 4:57, Liam Miller-Cushon wrote:
>>
>>         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/20251017/041a3cbe/attachment-0001.htm>

From prr at openjdk.org  Fri Oct 17 18:00:15 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Oct 2025 18:00:15 GMT
Subject: Integrated: 8365077: java.awt.font.NumericShaper violates
 equals/hashCode contract
In-Reply-To: <qU_CK51GAimmcyZpFLtmkMZDlB24zUFZ84kNSNDuvbw=.1316d201-081a-449b-9b2d-d829bbc198a4@github.com>
References: <qU_CK51GAimmcyZpFLtmkMZDlB24zUFZ84kNSNDuvbw=.1316d201-081a-449b-9b2d-d829bbc198a4@github.com>
Message-ID: <C_GQohWU9H8DivLp61Ky4fPad5zkGCTGyCJfQynKiXQ=.48525ddf-b198-4360-b467-81400ce92d21@github.com>

On Mon, 13 Oct 2025 17:53:44 GMT, Phil Race <prr at openjdk.org> wrote:

> The problem here is that NumericShaper can be constructed either using Range enum members
> or a bitmask.
> And the bitmask can represent the same (equal) NumericShaper as one constructed using
> the equivalent Range enum members and "boolean equals(Object)" handles this and there
> is support in the Range enum for a Set<Range> for this which is used by equals.
> 
> However the hashCode() does not have similar support and is quite different.
> The fix adds support for this.
> If the instance has a Set<Range> then use this new support, which will return
> the same hash as if it was constructed using a mask. In cases where this is not
> possible because Range instances  have no mask equivalent there is no issue
> because these cannot be equal either.
> 
> 
> EASTERN_ARABIC over-rides ARABIC and there was an inconsistency in that
> when constructed with Ranges this ARABIC is removed but this isn't the case
> for when constructed with masks. 
> I had to fix that so that the hashes would be the same.
> 
> I also made one variable final that should have been final all along.
>  
> A test is provided.

This pull request has now been integrated.

Changeset: 0103f216
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0103f21635f00d7b4ece0d667cc5c276613d41ff
Stats:     110 lines in 2 files changed: 100 ins; 8 del; 2 mod

8365077: java.awt.font.NumericShaper violates equals/hashCode contract

Reviewed-by: kizune, psadhukhan

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

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

From prr at openjdk.org  Fri Oct 17 18:04:05 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Oct 2025 18:04:05 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <4Yod2_UwZ837XGMro-l8is8Myt-r9T2pksAcGgYQQhY=.d0b15a20-8d5e-469f-a5d8-6f326dfc61d2@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

Marked as reviewed by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/ScrollPaneLayout.java line 42:

> 40: /**
> 41:  * The layout manager used by <code>JScrollPane</code>.
> 42:  * <code>JScrollPaneLayout</code> is

I'd have probably changed this to {@code ..} since you are touching it but it isn't a big deal.

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

PR Review: https://git.openjdk.org/jdk/pull/27860#pullrequestreview-3351354544
PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2440768813

From kcr at openjdk.org  Fri Oct 17 22:10:11 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Oct 2025 22:10:11 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <CfXG-MLSYOch-83h7yS-Oh3_VqtbtxxaW85NGJWZpJk=.d5624d06-48b8-44d0-887c-f5879794abdb@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
 <CfXG-MLSYOch-83h7yS-Oh3_VqtbtxxaW85NGJWZpJk=.d5624d06-48b8-44d0-887c-f5879794abdb@github.com>
Message-ID: <SZPFmkvrKJKYUvjwQ7Yb4OJh92zAGme97AeMZoylG0U=.fc9a4c26-bc9b-49cd-8a5d-e46415ac2953@github.com>

On Fri, 17 Oct 2025 12:28:24 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> Would it be possible to let skara respect this rule?

The minimum number of reviewers is set globally for the repo, which is 1 for the jdk (and we don't want to change that for the whole repo). There has been some discussion from time-to-time about the possibility of having Skara effectively default to `/reviewers 2` for certain areas of the code (hotspot, client, etc). It would need to be done in such a way that a "Reviewer" can lower it back to 1 (for backouts, critical build failures, problem listing, re-reviews for trivial changes, etc). I might file an RFE for this, but I don't know how likely it will be to get implemented.

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3417385913

From honkar at openjdk.org  Fri Oct 17 23:32:04 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 17 Oct 2025 23:32:04 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
Message-ID: <F7n0BoPTMQpO2Onccc9AWraJOOq6IWGaYK0aWZMX5Nc=.050f554b-24d4-48ac-81bf-81d14e866d7b@github.com>

On Thu, 29 May 2025 14:53:51 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Issue:**
> The bottom inset is different from the expected value by 2 pixels.
> 
> **Analysis:**
> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
> 
> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
> 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
> 
> However, it should be:
>  
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
> 
> Wich is the output of the command when the issue doest not occur.
> 
> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
> 
> **Proposed Fix:**
> Increase the allowed margin to 2 pixels.

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25521#pullrequestreview-3352374834

From serb at openjdk.org  Fri Oct 17 23:51:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Oct 2025 23:51:03 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <f8KCixAR2sfNqHbJ9vM7JTxBp926mV_fxUajNun-89I=.f45957af-9d13-49dd-9fc7-528b9037550a@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

Does it cover all the issues mentioned in the JBS? It seems it have a long list, but it may already be outdated.

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3417527425

From honkar at openjdk.org  Fri Oct 17 23:58:01 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 17 Oct 2025 23:58:01 GMT
Subject: RFR: 8369032: Add test to ensure serialized ICC_Profile stores
 only necessary optional data [v2]
In-Reply-To: <xwtaVvzBXNnVQgx7gOREXl_jrh13pNuGPEgdRgDcGsw=.2bf54781-d27a-46e6-b1a0-ff30b9f60c37@github.com>
References: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
 <xwtaVvzBXNnVQgx7gOREXl_jrh13pNuGPEgdRgDcGsw=.2bf54781-d27a-46e6-b1a0-ff30b9f60c37@github.com>
Message-ID: <Jj_81F1_olXqjzPsA_hLpxogvHzFQG4UqFztVSEOZzk=.2d9e834d-a7b0-43af-8521-b9d3e65dcffd@github.com>

On Tue, 7 Oct 2025 18:01:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27616#pullrequestreview-3352398159

From serb at openjdk.org  Sat Oct 18 01:14:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 01:14:38 GMT
Subject: RFR: 8298432: Investigate the benefits of usage of
 GetPrimitiveArrayCritical in the cmm code
Message-ID: <sXoEjAJD42R2Jx2oTfHdFTA4Unz1cyMq5e19KdIgV4w=.a3b9d003-353a-4a89-a0e0-a0d433ba6c56@github.com>

The LCMS JNI code currently uses GetByteArrayElements, GetShortArrayElements, GetIntArrayElements, and GetDoubleArrayElements. These can be replaced by GetPrimitiveArrayCritical, which avoids unnecessary copying of array data and provides measurable performance improvements.

This optimization was postponed earlier due to several reasons:

 - At that time, G1 did not support pinning, so critical sections could interfere with GC (see [JEP 423](https://openjdk.org/jeps/423)). Also note that this API is already used safely in many parts of java2d/awt.
 - There was a plan to migrate to panama, but cold-startup issues ([JDK-8313344](https://bugs.openjdk.org/browse/JDK-8313344)) remain unresolved.
 - GetPrimitiveArrayCritical forbids many JNI operations inside the critical region, including allocations and java callbacks, which could be unsafe for LCMS error handlers. However, LCMS color conversions do not trigger such callbacks (see [LittleCMS #516](https://github.com/mm2/Little-CMS/issues/516)).

Performance data of various [combinations](https://bugs.openjdk.org/secure/attachment/114273/OnePixelConvert-1.java) for ColorSpace.toXX/fromXX in single-threaded and multi-threaded (64 threads) modes:
https://jmh.morethan.io/?gists=b1440355577dc48f2b19b976b67f1120,d31c6a585330c9167b462e377445ad2f
Example:
<img width="1448" height="158" alt="image" src="https://github.com/user-attachments/assets/57c98739-8007-43cc-8d87-b50a8bf2aec1" />

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8298432-v3
 - 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code

Changes: https://git.openjdk.org/jdk/pull/27841/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27841&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298432
  Stats: 79 lines in 4 files changed: 4 ins; 60 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27841.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27841/head:pull/27841

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

From nikita.provotorov at jetbrains.com  Sat Oct 18 01:37:25 2025
From: nikita.provotorov at jetbrains.com (Nikita Provotorov)
Date: Sat, 18 Oct 2025 03:37:25 +0200
Subject: [Windows] How are AWT/Swing applications supposed to deal with the
 system shutdown/logout to prevent EDT deadlock?
Message-ID: <CAMTdVeq1kUF9zTS6CykK+KGFyunS6O866hqgpzEgT1-cJ9xrFg@mail.gmail.com>

Hello! In this topic, I'd like to discuss the following scenario with an
AWT/Swing application:
1. The system is shutting down, or the user is logging out.
2. The application's background thread posts a UI-related task onto the EDT
(via *invokeLater*).
3. As a consequence of p.1, the WToolkit's runtime shutdown hook gets
launched (the thread called "*ToolkitShutdown*"), which signals the
WToolkit's event loop to exit.
4. As a consequence of p.3, the WToolkit's event loop exits, and then
*AwtToolkit::Dispose()* gets called.
5. EDT starts performing the task posted in p.2. The task happens to
(indirectly) call some AWT native API, e.g.
*WComponentPeer.getLocationOnScreen*.
6. All such API natively starts with *hang_if_shutdown()*, causing EDT to
hang forever.
7. The hanging non-daemon thread causes the system to pause and then cancel
by timeout the shutting down/logging out routine.

I understand that this AWT behavior is kind of supposed, but *it turns out
that the application somehow has to understand that the WToolkit's shutdown
hook is about to launch and manage to finish all its EDT activities before
the hook gets actually** launched. What is the intended way to do so?* As
far as I understand, registering your own hook is not an option because:
1. The order of their execution is not specified/guaranteed
2. It's still not possible to immediately shut down the EDT (because the
hook is still another thread and you'll still need *invokeLater*).

Thank you in advance for help!

Best regards,
Nikita Provotorov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251018/e3f03616/attachment-0001.htm>

From serb at openjdk.org  Sat Oct 18 03:14:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 03:14:04 GMT
Subject: RFR: 8368576: PrintJob.getGraphics() does not specify behavior
 after PrintJob.end()
In-Reply-To: <NDIMbkAQAN84PvD1UIDpCCW66GLgyakdN7KB1bRjbVQ=.d646596b-6c60-48ff-8ced-3c12e06d61f2@github.com>
References: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
 <kUSWniHzpinTab1ljiUeTYkgXPFWC4ySX96mcSiw6Bw=.4e07c8a4-e085-4bc2-b9ce-753ece741dc1@github.com>
 <2FvOz_LmRyFvCgHNdaijn61I9T7HpHgDAX-6FoV9Iu4=.f12032d3-65ee-435e-8d80-729a6a49956b@github.com>
 <0OvAY-ty0-62EzKs0PsakNwHQaTxX2sQXdQLXLbSwSA=.13432e56-ffd4-4a43-8394-310171174093@github.com>
 <nE9OWiH0KERXkYcXPs0MEalnfQnHZ_-_0Y1wfcfTwLk=.8804d4cc-13dc-4980-956e-65fdcdf8d0ab@github.com>
 <NDIMbkAQAN84PvD1UIDpCCW66GLgyakdN7KB1bRjbVQ=.d646596b-6c60-48ff-8ced-3c12e06d61f2@github.com>
Message-ID: <UEeGNJOwMOCnyjNckxOTsUJtztHU3vJa-RguUFS5OOk=.80d5d339-735e-4b5f-b549-05683eb1ab0c@github.com>

On Thu, 25 Sep 2025 19:08:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It might be useful to mention that, as far as I understand, calling methods on a Graphics object after its target has been disposed is undefined behavior. I hope it does not cause a crash or something.

still think it is better to specify and test......https://bugs.openjdk.org/browse/JDK-8367702

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

PR Comment: https://git.openjdk.org/jdk/pull/27474#issuecomment-3417749186

From prr at openjdk.org  Sat Oct 18 04:50:00 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 18 Oct 2025 04:50:00 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <f8KCixAR2sfNqHbJ9vM7JTxBp926mV_fxUajNun-89I=.f45957af-9d13-49dd-9fc7-528b9037550a@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
 <f8KCixAR2sfNqHbJ9vM7JTxBp926mV_fxUajNun-89I=.f45957af-9d13-49dd-9fc7-528b9037550a@github.com>
Message-ID: <Mj4cWwMqQXOAgS0tale2Vl5v8fG47iR_BrdNaVdhq3s=.7c5f4fde-5b50-4a22-9b02-a3efdd538981@github.com>

On Fri, 17 Oct 2025 23:48:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Does it cover all the issues mentioned in the JBS? It seems it have a long list, but it may already be outdated.

There was a conversation above :
Reviewer >> This JBS lists a lot of broken API names. Is this list still valid?
Reviewer >> I see that you have chosen to fix only a few.

Fixer > Other awt/swing things are fixed already

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3417803265

From prr at openjdk.org  Sat Oct 18 05:12:32 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 18 Oct 2025 05:12:32 GMT
Subject: RFR: 8370160: NumericShaper allows illegal ranges
Message-ID: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>

This is a follow-on to 8365077: java.awt.font.NumericShaper violates equals/hashCode contract

The factory method to construct a contextual shaper from a bitmask will happily store illegal, unspecified bits.
So there are still ways to create instances which violate the contract.

This isn't possible with the enum approach. We should align these two. And we should document it.

Additionally the behaviour of eliminating an value which is of lesser precedence is also something we should specify.

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

Commit messages:
 - 8370160

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

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

From serb at openjdk.org  Sat Oct 18 06:02:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 06:02:01 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <Mj4cWwMqQXOAgS0tale2Vl5v8fG47iR_BrdNaVdhq3s=.7c5f4fde-5b50-4a22-9b02-a3efdd538981@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
 <f8KCixAR2sfNqHbJ9vM7JTxBp926mV_fxUajNun-89I=.f45957af-9d13-49dd-9fc7-528b9037550a@github.com>
 <Mj4cWwMqQXOAgS0tale2Vl5v8fG47iR_BrdNaVdhq3s=.7c5f4fde-5b50-4a22-9b02-a3efdd538981@github.com>
Message-ID: <tEKlvZL8nngPG0tbW_anpFRtMGdoCxqIQY2uAUg92yE=.b674ed0b-c59a-4f5c-8ef0-bae3625cb122@github.com>

On Sat, 18 Oct 2025 04:46:53 GMT, Phil Race <prr at openjdk.org> wrote:

> There was a conversation above :
> Reviewer >> This JBS lists a lot of broken API names. Is this list still valid?
> Reviewer >> I see that you have chosen to fix only a few.
> Fixer > Other awt/swing things are fixed already

The bug is not only about awt/swing, like the next one(still exists?):

>10.http://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslServer.html
  ldap.in = new SecureInputStream(ss, ldap.in);
      ldap.out = new SecureOutputStream(ss, ldap.out);-> Where are SecureInputStream and SecureOutputStream?

The ticket also mentioned references to non-public APIs from the specification, such as:

>1. http://docs.oracle.com/javase/7/docs/api/index.html?java/awt/Component.html
For paint events, the new event is coalesced into a complex RepaintArea in the peer. > RepaintArea is deleted in 7.0. 

Same for various peers, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3417841824

From serb at openjdk.org  Sat Oct 18 06:08:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 06:08:01 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v4]
In-Reply-To: <wKjNjLJfDi3xnnb-QgDagZQUrCMGvt5j5ihbVEic2Bw=.fbe631e4-25af-475f-80d6-1cc4c280fd4c@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
 <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>
 <IT6uqJTsemyfNahSEAwq_BeBEkF0d_3yCeNoilzt7no=.096747a0-a132-400e-9067-63035b31dfc3@github.com>
 <RKfnQi1Oxp-9oEr5WUPs7TXoZhiptgN31_iiwvCScDs=.9f0109e4-4eb9-4640-a588-ecb583d0bb79@github.com>
 <wKjNjLJfDi3xnnb-QgDagZQUrCMGvt5j5ihbVEic2Bw=.fbe631e4-25af-475f-80d6-1cc4c280fd4c@github.com>
Message-ID: <eid0SQ1DmLz1tw6LiJDjaZE0-qs336VKfjk0mtAxM1o=.7011bb5f-4d25-44a4-bf88-a7a57483d8a2@github.com>

On Tue, 14 Oct 2025 17:45:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> We seem to have a number of APIs that allow the strides to be zero.
>> I find them odd, but I don't see how they can cause an empty image and they need careful consideration before changing. It seems very deliberate.
>> Here's a sampling of other cases (there are likely more, I searched very briefly and crudely)
>> 
>> 
>>      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>>     public BandedSampleModel(int dataType,
>>                              int w, int h,
>>                              int scanlineStride,
>>                              int[] bankIndices,
>>                              int[] bandOffsets) 
>> 
>> =====
>> 
>>      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
>>      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>>   public ComponentSampleModel(int dataType,
>>                                 int w, int h,
>>                                 int pixelStride,
>>                                 int scanlineStride,
>>                                 int[] bandOffsets) {
>> 
>> =====
>>      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
>>      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>>    public ComponentSampleModel(int dataType,
>>                                 int w, int h,
>>                                 int pixelStride,
>>                                 int scanlineStride,
>>                                 int[] bankIndices,
>>                                 int[] bandOffsets) {
>
> PS, also negative strides are something that we've been asked to support too - in the distant past.
> But I don't have any plans to do it now.

>We seem to have a number of APIs that allow the strides to be zero.
>I find them odd, but I don't see how they can cause an empty image 

If the  scanlineStride and pixelStride are zero then the size below will be set to zero as well, even if we try to prevent that by checking the w and h to be > 0 before.

lsz = (long)scanlineStride * (long)(h - 1) + // first (h - 1) scans
      (long)pixelStride * (long)w; // last scan
int size = (int)lsz;
.....
d = new DataBufferByte(size);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2441597488

From serb at openjdk.org  Sat Oct 18 06:51:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 06:51:59 GMT
Subject: RFR: 8370160: NumericShaper allows illegal ranges
In-Reply-To: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
References: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
Message-ID: <bQT3VZlkwbt92MBahZrwR1Y9nMYZiggOco49T9i_qDI=.b9d8cb56-cbe3-408b-be09-2e09bfebf87b@github.com>

On Sat, 18 Oct 2025 05:05:48 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a follow-on to 8365077: java.awt.font.NumericShaper violates equals/hashCode contract
> 
> The factory method to construct a contextual shaper from a bitmask will happily store illegal, unspecified bits.
> So there are still ways to create instances which violate the contract.
> 
> This isn't possible with the enum approach. We should align these two. And we should document it.
> 
> Additionally the behaviour of eliminating an value which is of lesser precedence is also something we should specify.
> 
> CSR : https://bugs.openjdk.org/browse/JDK-8370161

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27884#pullrequestreview-3352685659

From serb at openjdk.org  Sat Oct 18 06:56:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 06:56:01 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
Message-ID: <XXywQrWB8dmw1q8AapaECJigEHXvRPzS91Sj15cSDVM=.b102af32-a6f2-4e6a-92a6-2bc789ed6c48@github.com>

On Thu, 16 Oct 2025 09:25:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in GTKLookAndFeel with NPE
> 
> java.lang.NullPointerException
> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
> 
> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
> 
> Fix is made to not use these color to create BevelBorder if these colors are not present..

I don?t have a strong opinion on whether this is a test bug: using the Motif L&F UI classes while GTK is active, a bug in the Motif UI class that assumes these variables are always set, or a bug in BorderFactory.java as addressed by this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27839#issuecomment-3417915497

From duke at openjdk.org  Sat Oct 18 16:24:04 2025
From: duke at openjdk.org (duke)
Date: Sat, 18 Oct 2025 16:24:04 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
Message-ID: <mJW17dtpPcmwfGxGF1dFkriSy4wxQya0V4LvZ8KlO2M=.b41281b7-a0aa-4a78-9eb4-14e0a2368a68@github.com>

On Thu, 29 May 2025 14:53:51 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Issue:**
> The bottom inset is different from the expected value by 2 pixels.
> 
> **Analysis:**
> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
> 
> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
> 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
> 
> However, it should be:
>  
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
> 
> Wich is the output of the command when the issue doest not occur.
> 
> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
> 
> **Proposed Fix:**
> Increase the allowed margin to 2 pixels.

@anass-baya 
Your change (at version 5a1030466ae50c95fd4393c5da11cb42c59aa66c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3418627320

From serb at openjdk.org  Sat Oct 18 21:27:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 21:27:07 GMT
Subject: RFR: 8370160: NumericShaper allows illegal ranges
In-Reply-To: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
References: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
Message-ID: <ztZzWP4PsEFpbadjd1uOjOX8SHrCzsRoQDBwnZsFLq4=.ee95c402-e5a0-4f4b-894c-82af22efa957@github.com>

On Sat, 18 Oct 2025 05:05:48 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a follow-on to 8365077: java.awt.font.NumericShaper violates equals/hashCode contract
> 
> The factory method to construct a contextual shaper from a bitmask will happily store illegal, unspecified bits.
> So there are still ways to create instances which violate the contract.
> 
> This isn't possible with the enum approach. We should align these two. And we should document it.
> 
> Additionally the behaviour of eliminating an value which is of lesser precedence is also something we should specify.
> 
> CSR : https://bugs.openjdk.org/browse/JDK-8370161

src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 1534:

> 1532:     private NumericShaper(int key, int mask) {
> 1533:         this.key = key;
> 1534:         this.mask = mask & (CONTEXTUAL_MASK | ALL_RANGES);

Note that this will accept the CONTEXTUAL_MASK even if it was provided by the app. It is unclear whether we should discard it in that case or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27884#discussion_r2442606464

From serb at openjdk.org  Sat Oct 18 21:29:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Oct 2025 21:29:03 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
Message-ID: <vsns4VdZF1e0Q226aqMdLTF_VtHr-IT4VUiu_K5b2K8=.7e9b047d-2337-49f5-a869-e447741e9eb5@github.com>

On Thu, 29 May 2025 14:53:51 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Issue:**
> The bottom inset is different from the expected value by 2 pixels.
> 
> **Analysis:**
> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
> 
> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
> 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
> 
> However, it should be:
>  
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
> 
> Wich is the output of the command when the issue doest not occur.
> 
> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
> 
> **Proposed Fix:**
> Increase the allowed margin to 2 pixels.

Marked as reviewed by serb (Reviewer).

>after discution with @aivanov-jdk a 2 pixels margin error is acceptibe

It would be good to file a bug against Ubuntu for this issue. Is it a regression?

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

PR Review: https://git.openjdk.org/jdk/pull/25521#pullrequestreview-3353781175
PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3418828983

From abaya at openjdk.org  Sun Oct 19 11:51:14 2025
From: abaya at openjdk.org (Anass Baya)
Date: Sun, 19 Oct 2025 11:51:14 GMT
Subject: Integrated: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
Message-ID: <p4PW-ztTgjBCNv3bkBw0yGQ1x2TDP9WFx0zUMv83tFA=.186da9bb-d09c-408c-9b7c-532a93a4cdc9@github.com>

On Thu, 29 May 2025 14:53:51 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Issue:**
> The bottom inset is different from the expected value by 2 pixels.
> 
> **Analysis:**
> In [JDK-8349351](https://bugs.openjdk.org/browse/JDK-8349351), we agreed that a small difference between the expected and actual inset values could happen due to scaling. So, we accepted a small margin of error. Harshita suggested allowing a margin of 2 or 3 pixels. However, we decided to accept only a 1-pixel margin since it was enough for scaling loss and the test was passing consistently on CI. 
> 
> But here we have a different origin of the error. On our OCI Ubuntu 24.04 hosts with X11, the _NET_WORKAREA most of the time returns a value that is 2px greater than the actual working area. We have verified that the source of the issue is not from our code. It seems to be related to the window manager.
> 
> When the issue occurs, running xprop -root | grep _NET_WORKAREA returns a value that is 2px larger than expected. In a system with a bottom inset of 30px, a top inset of 32px, and a screen resolution of 1920x1080, when the issue occurs, the _NET_WORKAREA value is as follows:
> 
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**20** 
> 
> However, it should be:
>  
>> _NET_WORKAREA(CARDINAL) = 0, 32, 1920, 1020, 0, 32, 1920, 10**18** 
> 
> Wich is the output of the command when the issue doest not occur.
> 
> after discution with @aivanov-jdk a 2 pixels margin error is acceptibe 
> 
> **Proposed Fix:**
> Increase the allowed margin to 2 pixels.

This pull request has now been integrated.

Changeset: c2fde517
Author:    Anass Baya <abaya at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2fde517b44e2315385a5ffe17fcf9ab57e12786
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8357390: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu 24.04 Vm Hosts used by Oracle's internal CI system

Reviewed-by: honkar, serb

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

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

From prr at openjdk.org  Sun Oct 19 15:19:01 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 19 Oct 2025 15:19:01 GMT
Subject: RFR: 8370160: NumericShaper allows illegal ranges
In-Reply-To: <ztZzWP4PsEFpbadjd1uOjOX8SHrCzsRoQDBwnZsFLq4=.ee95c402-e5a0-4f4b-894c-82af22efa957@github.com>
References: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
 <ztZzWP4PsEFpbadjd1uOjOX8SHrCzsRoQDBwnZsFLq4=.ee95c402-e5a0-4f4b-894c-82af22efa957@github.com>
Message-ID: <QwKyl7Nyp1ltH_8gNBhpzmAADaThzYiaPdv_EK_yH1o=.3804b439-5395-4198-bb49-480e65993cbf@github.com>

On Sat, 18 Oct 2025 21:23:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is a follow-on to 8365077: java.awt.font.NumericShaper violates equals/hashCode contract
>> 
>> The factory method to construct a contextual shaper from a bitmask will happily store illegal, unspecified bits.
>> So there are still ways to create instances which violate the contract.
>> 
>> This isn't possible with the enum approach. We should align these two. And we should document it.
>> 
>> Additionally the behaviour of eliminating an value which is of lesser precedence is also something we should specify.
>> 
>> CSR : https://bugs.openjdk.org/browse/JDK-8370161
>
> src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 1534:
> 
>> 1532:     private NumericShaper(int key, int mask) {
>> 1533:         this.key = key;
>> 1534:         this.mask = mask & (CONTEXTUAL_MASK | ALL_RANGES);
> 
> Note that this will accept the CONTEXTUAL_MASK even if it was provided by the app. It is unclear whether we should discard it in that case or not.

This is always added by the implementation when constructing a contextual shaper.
So when we get here it is always part of the mask argument.
The only path that gets here without a contextual shaper bit set is the single range case.
But it the app has set that there an IAE is thrown, so it can't happen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27884#discussion_r2443358823

From serb at openjdk.org  Mon Oct 20 02:45:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Oct 2025 02:45:37 GMT
Subject: RFR: 8370197: Add missing @Override annotations in com.sun.beans
 package
Message-ID: <4SAucq5DFcGowDQlLKy2Nop5y5uP80wVQ3h4iCnqjmc=.552d7576-4853-4c31-a164-c4c9a35d3f84@github.com>

This patch adds missing `@Override` annotations to methods in the `com.sun.beans` package that override superclass or interface methods.
Only source annotations are added; there are no behavioral changes.

Unlike the previous patches, I have skipped adding the `final` to classes, since it should be done carefully when applied to shared code. So I do not want to mix it with other changes.

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

Commit messages:
 - 8370197: Add missing @Override annotations in com.sun.beans package

Changes: https://git.openjdk.org/jdk/pull/27887/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27887&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370197
  Stats: 97 lines in 17 files changed: 80 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27887/head:pull/27887

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

From snazarki at openjdk.org  Mon Oct 20 05:58:27 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Mon, 20 Oct 2025 05:58:27 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v4]
In-Reply-To: <aIQzomqZimFp9qkFyYN-KysEIcr-A5OO08JxuEP3ntg=.c4862d80-cd01-4888-8732-7b5ffdcf1c7e@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <aIQzomqZimFp9qkFyYN-KysEIcr-A5OO08JxuEP3ntg=.c4862d80-cd01-4888-8732-7b5ffdcf1c7e@github.com>
Message-ID: <pRA4U86xmuJUD5F-lgN1bADjp6949F2tVIl3hTXn8W0=.377ff99a-1a43-43b2-a40a-e1c1dc95fffd@github.com>

On Fri, 17 Oct 2025 10:20:49 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of binary file

Removed all binary files

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3420671756

From snazarki at openjdk.org  Mon Oct 20 05:58:25 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Mon, 20 Oct 2025 05:58:25 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
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: <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>

> 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.

Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:

  Get rid of eudc.reg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27551/files
  - new: https://git.openjdk.org/jdk/pull/27551/files/386b0206..5fceb547

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

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

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

From aivanov at openjdk.org  Mon Oct 20 14:21:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Oct 2025 14:21:22 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <vsns4VdZF1e0Q226aqMdLTF_VtHr-IT4VUiu_K5b2K8=.7e9b047d-2337-49f5-a869-e447741e9eb5@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <vsns4VdZF1e0Q226aqMdLTF_VtHr-IT4VUiu_K5b2K8=.7e9b047d-2337-49f5-a869-e447741e9eb5@github.com>
Message-ID: <1LXiIjbrRM5m1XDWKkvb-O5DSrkksPPpMcjIQL4W3Rw=.964824fb-8680-4ae8-bd23-50807c4786cd@github.com>

On Sat, 18 Oct 2025 21:26:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > after discution with @aivanov-jdk a 2 pixels margin error is acceptibe
> 
> It would be good to file a bug against Ubuntu for this issue. Is it a regression?

This problem reproduced only on Ubuntu 25.10. It may be worth checking with XWayland developers or whoever is responsible for providing `_NET_WORKAREA`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3422287132

From azvegint at openjdk.org  Mon Oct 20 17:04:36 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 20 Oct 2025 17:04:36 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <1LXiIjbrRM5m1XDWKkvb-O5DSrkksPPpMcjIQL4W3Rw=.964824fb-8680-4ae8-bd23-50807c4786cd@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <vsns4VdZF1e0Q226aqMdLTF_VtHr-IT4VUiu_K5b2K8=.7e9b047d-2337-49f5-a869-e447741e9eb5@github.com>
 <1LXiIjbrRM5m1XDWKkvb-O5DSrkksPPpMcjIQL4W3Rw=.964824fb-8680-4ae8-bd23-50807c4786cd@github.com>
Message-ID: <IE1tCbP3aYoW_B0b04eKHDARa5m6SQv9lT0rjTprbus=.cc7c81b1-24d5-4468-8783-ffc191828fef@github.com>

On Mon, 20 Oct 2025 14:18:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This problem reproduced only on Ubuntu 25.10. It may be worth checking with XWayland developers or whoever is responsible for providing `_NET_WORKAREA`.

The title of the JBS bug contains "Test failing on Ubuntu 24.04 Vm hosts", so it does not seem to be limited to Ubuntu 25.10.

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3422983902

From aivanov at openjdk.org  Mon Oct 20 17:12:17 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Oct 2025 17:12:17 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <IE1tCbP3aYoW_B0b04eKHDARa5m6SQv9lT0rjTprbus=.cc7c81b1-24d5-4468-8783-ffc191828fef@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <vsns4VdZF1e0Q226aqMdLTF_VtHr-IT4VUiu_K5b2K8=.7e9b047d-2337-49f5-a869-e447741e9eb5@github.com>
 <1LXiIjbrRM5m1XDWKkvb-O5DSrkksPPpMcjIQL4W3Rw=.964824fb-8680-4ae8-bd23-50807c4786cd@github.com>
 <IE1tCbP3aYoW_B0b04eKHDARa5m6SQv9lT0rjTprbus=.cc7c81b1-24d5-4468-8783-ffc191828fef@github.com>
Message-ID: <JQjOzlDbUfx7SpzWr_JFwSfiBQbBdju6Y58sXvtn54c=.d1e65a72-fa46-415f-8f64-bd3d677fa74f@github.com>

On Mon, 20 Oct 2025 17:01:10 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> > This problem reproduced only on Ubuntu 25.10. It may be worth checking with XWayland developers or whoever is responsible for providing `_NET_WORKAREA`.
> 
> The title of the JBS bug contains "Test failing on Ubuntu 24.04 Vm hosts", so it does not seem to be limited to Ubuntu 25.10.

I may have confused it with something else. Let's wait for Anass' to reply, he has more details. @anass-baya

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3423009156

From abaya at openjdk.org  Mon Oct 20 17:29:15 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 20 Oct 2025 17:29:15 GMT
Subject: RFR: 8357390:
 java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java Test failing on Ubuntu
 24.04 Vm Hosts used by Oracle's internal CI system
In-Reply-To: <JQjOzlDbUfx7SpzWr_JFwSfiBQbBdju6Y58sXvtn54c=.d1e65a72-fa46-415f-8f64-bd3d677fa74f@github.com>
References: <zN61X9pV6tejqx9xZBRSJEvkPRR2Aj4EB3xE9oAJzeg=.51159905-20c3-474c-9ed8-c86f7204d1c9@github.com>
 <vsns4VdZF1e0Q226aqMdLTF_VtHr-IT4VUiu_K5b2K8=.7e9b047d-2337-49f5-a869-e447741e9eb5@github.com>
 <1LXiIjbrRM5m1XDWKkvb-O5DSrkksPPpMcjIQL4W3Rw=.964824fb-8680-4ae8-bd23-50807c4786cd@github.com>
 <IE1tCbP3aYoW_B0b04eKHDARa5m6SQv9lT0rjTprbus=.cc7c81b1-24d5-4468-8783-ffc191828fef@github.com>
 <JQjOzlDbUfx7SpzWr_JFwSfiBQbBdju6Y58sXvtn54c=.d1e65a72-fa46-415f-8f64-bd3d677fa74f@github.com>
Message-ID: <z1sajEA2HdD-j7xozK1KJbBLhT8UnAIGIIJkKcn-Hc0=.5de895eb-f698-419c-9e07-1e59f34c2674@github.com>

On Mon, 20 Oct 2025 17:09:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > This problem reproduced only on Ubuntu 25.10. It may be worth checking with XWayland developers or whoever is responsible for providing `_NET_WORKAREA`.
> > 
> > 
> > The title of the JBS bug contains "Test failing on Ubuntu 24.04 Vm hosts", so it does not seem to be limited to Ubuntu 25.10.
> 
> I may have confused it with something else. Let's wait for Anass' to reply, he has more details. @anass-baya

We see the problem on the Ubuntu 24.04. I will file a bug report against Ubuntu for this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25521#issuecomment-3423062589

From aivanov at openjdk.org  Mon Oct 20 18:20:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Oct 2025 18:20:16 GMT
Subject: Integrated: 8365625: Can't change accelerator colors in Windows L&F
In-Reply-To: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
References: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
Message-ID: <CH_hKeTBISzzLZEmTaBL5IztP1d70-3UWQkZrPVgCuo=.f220f173-bbfc-4414-b969-8b2be4da03ed@github.com>

On Mon, 18 Aug 2025 16:31:00 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.

This pull request has now been integrated.

Changeset: a1302e5f
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a1302e5fbc1e1b41bc0b334c2502e487fa42209f
Stats:     268 lines in 5 files changed: 211 ins; 32 del; 25 mod

8365625: Can't change accelerator colors in Windows L&F

Reviewed-by: psadhukhan, kizune

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

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

From prr at openjdk.org  Mon Oct 20 20:44:07 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Oct 2025 20:44:07 GMT
Subject: RFR: 8368576: PrintJob.getGraphics() does not specify behavior
 after PrintJob.end()
In-Reply-To: <UEeGNJOwMOCnyjNckxOTsUJtztHU3vJa-RguUFS5OOk=.80d5d339-735e-4b5f-b549-05683eb1ab0c@github.com>
References: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
 <kUSWniHzpinTab1ljiUeTYkgXPFWC4ySX96mcSiw6Bw=.4e07c8a4-e085-4bc2-b9ce-753ece741dc1@github.com>
 <2FvOz_LmRyFvCgHNdaijn61I9T7HpHgDAX-6FoV9Iu4=.f12032d3-65ee-435e-8d80-729a6a49956b@github.com>
 <0OvAY-ty0-62EzKs0PsakNwHQaTxX2sQXdQLXLbSwSA=.13432e56-ffd4-4a43-8394-310171174093@github.com>
 <nE9OWiH0KERXkYcXPs0MEalnfQnHZ_-_0Y1wfcfTwLk=.8804d4cc-13dc-4980-956e-65fdcdf8d0ab@github.com>
 <NDIMbkAQAN84PvD1UIDpCCW66GLgyakdN7KB1bRjbVQ=.d646596b-6c60-48ff-8ced-3c12e06d61f2@github.com>
 <UEeGNJOwMOCnyjNckxOTsUJtztHU3vJa-RguUFS5OOk=.80d5d339-735e-4b5f-b549-05683eb1ab0c@github.com>
Message-ID: <et6X2AEMOjIfeNmdM6pnUaf36TACyKM1dPvHR0TsMW4=.9d225109-086b-4de3-a083-8a630b7c0006@github.com>

On Sat, 18 Oct 2025 03:11:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > It might be useful to mention that, as far as I understand, calling methods on a Graphics object after its target has been disposed is undefined behavior. I hope it does not cause a crash or something.
> 
> still think it is better to specify and test......https://bugs.openjdk.org/browse/JDK-8367702

As you note that other fix (PR here https://github.com/openjdk/jdk/pull/27458/files) already added the test for null.

I don't think we need to specify anything here about use after dispose().
It is the case from the very beginning for all instances of java.awt.Graphics and its sub-classes. 
https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/java/awt/Graphics.html#dispose()

The other part about not causing a crash. I agree. But that's not related to specification and should be handled separately.
I played around and I did actually get a crash on macOS. I will submit a PR for that very shortly

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

PR Comment: https://git.openjdk.org/jdk/pull/27474#issuecomment-3423650229

From aivanov at openjdk.org  Mon Oct 20 20:48:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Oct 2025 20:48:14 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
Message-ID: <g2Rhy1UQ_Y7IBqU2U2O-F5R1h07IzYj3Z91UHNyH5GA=.7c0820c2-517c-40e6-8f8d-39bcf22c461f@github.com>

On Fri, 17 Oct 2025 07:19:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo fix in another class

Update the copyright year in the other files. You've updated it in one files and left three others untouched.

Either all or none.

src/java.desktop/share/classes/java/awt/GridBagConstraints.java line 1:

> 1: /*

Update the copyright year.

src/java.desktop/share/classes/java/awt/image/renderable/RenderableImageOp.java line 1:

> 1: /*

The copyright year in this file needs updating.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27860#pullrequestreview-3357867956
PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2446077491
PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2446076658

From prr at openjdk.org  Mon Oct 20 21:02:56 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Oct 2025 21:02:56 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used.
Message-ID: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>

macOS printing uses a Quartz surface. It is the SurfaceData for a CPrinterGraphics.
That Surface is not disconnected from the graphics unless Graphics.dispose() is called.
If the application uses Graphics.create() then the implementation will not Graphics.dispose() it.
If it is used after printing is complete and the CGContext is no longer valid a crash will occur.
We need to invalidate the surface as soon as printing to a page is done.
Note: this is Graphics.dispose(), and is unrelated to disposal of an object when it becomes unreachable.

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

Commit messages:
 - 8370141
 - 8370141

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

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

From prr at openjdk.org  Mon Oct 20 21:10:05 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Oct 2025 21:10:05 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v4]
In-Reply-To: <eid0SQ1DmLz1tw6LiJDjaZE0-qs336VKfjk0mtAxM1o=.7011bb5f-4d25-44a4-bf88-a7a57483d8a2@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
 <agorqmZoPA2_QMhgKdHp4ZZg22MwrnaFI-6ZwnEVYe4=.f98eafbf-534b-4165-bb31-1f8f02522682@github.com>
 <IT6uqJTsemyfNahSEAwq_BeBEkF0d_3yCeNoilzt7no=.096747a0-a132-400e-9067-63035b31dfc3@github.com>
 <RKfnQi1Oxp-9oEr5WUPs7TXoZhiptgN31_iiwvCScDs=.9f0109e4-4eb9-4640-a588-ecb583d0bb79@github.com>
 <wKjNjLJfDi3xnnb-QgDagZQUrCMGvt5j5ihbVEic2Bw=.fbe631e4-25af-475f-80d6-1cc4c280fd4c@github.com>
 <eid0SQ1DmLz1tw6LiJDjaZE0-qs336VKfjk0mtAxM1o=.7011bb5f-4d25-44a4-bf88-a7a57483d8a2@github.com>
Message-ID: <fGRNTksa2n7tvVqcbOPQRW2EeDLlkjegaa9Zy6y3zqo=.012caeed-3519-409c-9a2d-e0d12c391b46@github.com>

On Sat, 18 Oct 2025 06:05:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> PS, also negative strides are something that we've been asked to support too - in the distant past.
>> But I don't have any plans to do it now.
>
>>We seem to have a number of APIs that allow the strides to be zero.
>>I find them odd, but I don't see how they can cause an empty image 
> 
> If the  scanlineStride and pixelStride are zero then the size below will be set to zero as well, even if we try to prevent that by checking the w and h to be > 0 before.
> 
> lsz = (long)scanlineStride * (long)(h - 1) + // first (h - 1) scans
>       (long)pixelStride * (long)w; // last scan
> int size = (int)lsz;
> .....
> d = new DataBufferByte(size);

I've played around a bit.
Commenting specifically about the one createInterleavedRaster factory method which accepts, width, height and the strides, I don't think such cases of zero pixel stride have ever been useful.
I've written a small test (which I'll paste below) and as far as I've found so far, a zero pixel or scan line stride always results in an exception
from somewhere. And the exceptions are the same for each case. I've tried JDK 8, JDK 24 and a build of the current proposed fix.

So I think we could explicitly disallow 0 for these strides on this method although rather than a mix
of  RasterFormatException and IllegalArgumentException, they'd all become IllegalArgumentException

For the  other public factory method createInterleavedRaster that accepts a DataBuffer,  even if the app makes it large enough,
there's still an exception in most cases. The sole "working" case I've found is if bandoffsets are also all zero.

 Raster.createInterleavedRaster(new DataBufferByte(100), 1, 1, 0, 0, new int[] { 0 });

To continue to allow that we'd need to still allow zero strides on that method and use words about the bandoffsets.

The words about the bandOffsets should in fact go on both methods. They apply more broadly than a zero stride.

I'll proceed accordingly unless you spot an issue. Also I'll need to run all our tests which I've not done yet.

I don't intend to look at the allowability of zero in other APIs as part of this change.

BTW negative strides was asked for here : https://bugs.openjdk.org/browse/JDK-4296691
 
I don't think we'll ever do that.

test program :
import static java.awt.image.DataBuffer.TYPE_BYTE ;
import java.awt.image.Raster;

public class ZeroStride {
    public static void main(String[] args) {
        //   w  h  ss ps           bandoffsets
        test(1, 1, 0, 0, new int[] { 0, 0, 0});
        test(1, 1, 0, 0, new int[] { 0, 1, 2});
        test(1, 1, 0, 1, new int[] { 0, 0, 0});
        test(1, 1, 3, 0, new int[] { 0, 0, 0});
        test(1, 1, 3, 0, new int[] { 0, 1, 2});
    }

    static void test(int w, int h, int scanlineStride, int pixelStride, int[] offsets) {
        try {
             System.err.println("w="+w+" h=" + h + " scanlineStride=" + scanlineStride +
                                " pixelStride = " + pixelStride +
                                ((offsets[1] == 0) ? " bands={0,0,0}" : " bands={0,1,2}"));
             Raster.createInterleavedRaster(TYPE_BYTE, w, h, scanlineStride, pixelStride, offsets, null);
             System.err.println("No exception");
        } catch (Exception e) {
             e.printStackTrace();
        }
        System.err.println();
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27627#discussion_r2446128878

From prr at openjdk.org  Mon Oct 20 21:30:05 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Oct 2025 21:30:05 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v7]
In-Reply-To: <OuWWSPqxroyynHgzTFoYG83eBw4x8DERnGsErjCkM6s=.3e9925de-6e8a-4d1a-8f60-40d6a977c1e6@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
 <OuWWSPqxroyynHgzTFoYG83eBw4x8DERnGsErjCkM6s=.3e9925de-6e8a-4d1a-8f60-40d6a977c1e6@github.com>
Message-ID: <WIw5ww2DcTINZdf2y9oo-zfT6lo0YbSHBLk2JtmI9vo=.4702adb3-75d5-4490-b5ea-01943505c5ba@github.com>

On Fri, 17 Oct 2025 01:37:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> That is strange..It is working for me but on retina display but I believe CI osx systems all use external displays and it does not hang there it seems..

It works for me too on retina. Have you tried an external display on your system ? It is a 100 % consistent hang for me.

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

PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3423787774

From prr at openjdk.org  Mon Oct 20 21:41:08 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Oct 2025 21:41:08 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
Message-ID: <8Ogw77PdPH_unngwOZrTY3C_8vu1p6hy6TxPkxxwk8U=.b6dfa72a-06ca-4d79-a570-2372b6135b36@github.com>

On Mon, 20 Oct 2025 05:58:25 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of eudc.reg

>From the JBS issue 
This issue cannot be reproduced on a clean machine and requires several prerequisites.
1. JP should be the default local on the Windows machine.
2. The EUDC font should be installed (created with eudcedit.exe).
3. The fallback font is present at <jdk>/lib/fonts.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

How did the fall back font get there ?
It is no longer (since JDK 9) supported to touch that directory
https://bugs.openjdk.org/browse/JDK-8368882

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3423819017

From serb at openjdk.org  Mon Oct 20 22:04:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Oct 2025 22:04:01 GMT
Subject: RFR: 8368576: PrintJob.getGraphics() does not specify behavior
 after PrintJob.end()
In-Reply-To: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
References: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
Message-ID: <cP4oB1B39DUEinhV1_BVWHn2ek0gJyWqyIwam4-9ENY=.0e475b7f-7c5c-4371-9aaa-0241480e3c33@github.com>

On Wed, 24 Sep 2025 16:43:13 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the spec. of java.awt.PrintJob.getGraphics() to document long standing behaviour after PrintJob.end() has been called.
> 
> A CSR has been created https://bugs.openjdk.org/browse/JDK-8368577

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27474#pullrequestreview-3358070220

From serb at openjdk.org  Mon Oct 20 22:04:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Oct 2025 22:04:02 GMT
Subject: RFR: 8368576: PrintJob.getGraphics() does not specify behavior
 after PrintJob.end()
In-Reply-To: <et6X2AEMOjIfeNmdM6pnUaf36TACyKM1dPvHR0TsMW4=.9d225109-086b-4de3-a083-8a630b7c0006@github.com>
References: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
 <kUSWniHzpinTab1ljiUeTYkgXPFWC4ySX96mcSiw6Bw=.4e07c8a4-e085-4bc2-b9ce-753ece741dc1@github.com>
 <2FvOz_LmRyFvCgHNdaijn61I9T7HpHgDAX-6FoV9Iu4=.f12032d3-65ee-435e-8d80-729a6a49956b@github.com>
 <0OvAY-ty0-62EzKs0PsakNwHQaTxX2sQXdQLXLbSwSA=.13432e56-ffd4-4a43-8394-310171174093@github.com>
 <nE9OWiH0KERXkYcXPs0MEalnfQnHZ_-_0Y1wfcfTwLk=.8804d4cc-13dc-4980-956e-65fdcdf8d0ab@github.com>
 <NDIMbkAQAN84PvD1UIDpCCW66GLgyakdN7KB1bRjbVQ=.d646596b-6c60-48ff-8ced-3c12e06d61f2@github.com>
 <UEeGNJOwMOCnyjNckxOTsUJtztHU3vJa-RguUFS5OOk=.80d5d339-735e-4b5f-b549-05683eb1ab0c@github.com>
 <et6X2AEMOjIfeNmdM6pnUaf36TACyKM1dPvHR0TsMW4=.9d225109-086b-4de3-a083-8a630b7c0006@github.com>
Message-ID: <3INNkRUWBRyeJZSkd93Ydvl1oP4IpsatZA505Jselfk=.40fff677-222c-49bb-8092-1003dc949547@github.com>

On Mon, 20 Oct 2025 20:41:14 GMT, Phil Race <prr at openjdk.org> wrote:

>The other part about not causing a crash. I agree. But that's not related to specification and should be handled separately.
>I played around and I did actually get a crash on macOS. I will submit a PR for that very shortly

It sounds good, but leaving this unspecified could still be improved, even as a general concept of using graphics after disposal. Otherwise, for example, TCK cannot create tests for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27474#issuecomment-3423884376

From serb at openjdk.org  Mon Oct 20 22:39:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Oct 2025 22:39:00 GMT
Subject: RFR: 8368576: PrintJob.getGraphics() does not specify behavior
 after PrintJob.end()
In-Reply-To: <3INNkRUWBRyeJZSkd93Ydvl1oP4IpsatZA505Jselfk=.40fff677-222c-49bb-8092-1003dc949547@github.com>
References: <LhlDTQkRqAxNYKs-2CpDvMjqohq9a89EVXDRAxjwtKg=.86b5caca-04ee-427e-88bc-09c6feff2599@github.com>
 <kUSWniHzpinTab1ljiUeTYkgXPFWC4ySX96mcSiw6Bw=.4e07c8a4-e085-4bc2-b9ce-753ece741dc1@github.com>
 <2FvOz_LmRyFvCgHNdaijn61I9T7HpHgDAX-6FoV9Iu4=.f12032d3-65ee-435e-8d80-729a6a49956b@github.com>
 <0OvAY-ty0-62EzKs0PsakNwHQaTxX2sQXdQLXLbSwSA=.13432e56-ffd4-4a43-8394-310171174093@github.com>
 <nE9OWiH0KERXkYcXPs0MEalnfQnHZ_-_0Y1wfcfTwLk=.8804d4cc-13dc-4980-956e-65fdcdf8d0ab@github.com>
 <NDIMbkAQAN84PvD1UIDpCCW66GLgyakdN7KB1bRjbVQ=.d646596b-6c60-48ff-8ced-3c12e06d61f2@github.com>
 <UEeGNJOwMOCnyjNckxOTsUJtztHU3vJa-RguUFS5OOk=.80d5d339-735e-4b5f-b549-05683eb1ab0c@github.com>
 <et6X2AEMOjIfeNmdM6pnUaf36TACyKM1dPvHR0TsMW4=.9d225109-086b-4de3-a083-8a630b7c0006@github.com>
 <3INNkRUWBRyeJZSkd93Ydvl1oP4IpsatZA505Jselfk=.40fff677-222c-49bb-8092-1003dc949547@github.com>
Message-ID: <0HgSVIjqpycVnuYv80bCleB0PECTOaUk2Fwza9O_syM=.35468ca4-550f-45cd-a5d8-b622503fa616@github.com>

On Mon, 20 Oct 2025 22:01:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>I played around and I did actually get a crash on macOS.

O_o nice

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

PR Comment: https://git.openjdk.org/jdk/pull/27474#issuecomment-3423982266

From serb at openjdk.org  Tue Oct 21 05:17:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Oct 2025 05:17:01 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v7]
In-Reply-To: <WIw5ww2DcTINZdf2y9oo-zfT6lo0YbSHBLk2JtmI9vo=.4702adb3-75d5-4490-b5ea-01943505c5ba@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
 <OuWWSPqxroyynHgzTFoYG83eBw4x8DERnGsErjCkM6s=.3e9925de-6e8a-4d1a-8f60-40d6a977c1e6@github.com>
 <WIw5ww2DcTINZdf2y9oo-zfT6lo0YbSHBLk2JtmI9vo=.4702adb3-75d5-4490-b5ea-01943505c5ba@github.com>
Message-ID: <9U5mDvlTADEGeBkGtUiwancl2AnoKQzH1t9FH3Du39k=.4ccb81cc-cec7-485f-9b6e-e3f6cc92043a@github.com>

On Mon, 20 Oct 2025 21:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

>It works for me too on retina. Have you tried an external display on your system ? It is a 100 % consistent hang for me.

is it possible to reproduce this just by the native example? opportunity to report it to Apple?

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

PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3424702400

From snazarki at openjdk.org  Tue Oct 21 14:25:15 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Tue, 21 Oct 2025 14:25:15 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <8Ogw77PdPH_unngwOZrTY3C_8vu1p6hy6TxPkxxwk8U=.b6dfa72a-06ca-4d79-a570-2372b6135b36@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <8Ogw77PdPH_unngwOZrTY3C_8vu1p6hy6TxPkxxwk8U=.b6dfa72a-06ca-4d79-a570-2372b6135b36@github.com>
Message-ID: <kLuRWt-J7pT0fxwJ9RgaKDnBVdIjjjBFzIjaI8uYp5U=.8fb5fefb-037f-4edd-a103-bbf09cfc5c7a@github.com>

On Mon, 20 Oct 2025 21:38:19 GMT, Phil Race <prr at openjdk.org> wrote:

> How did the fall back font get there ? It is no longer (since JDK 9) supported to touch that directory https://bugs.openjdk.org/browse/JDK-8368882
This issue was reported by one of our customers.  They use JDK 17, but I think the code migrates with JDK upgrades.

I was unaware that the <JDK_PATH>/lib/font directory is deprecated. At least, this part of the JDK has not been touched for a very long time. Do you remember the JBS record for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3426948282

From abaya at openjdk.org  Tue Oct 21 15:30:33 2025
From: abaya at openjdk.org (Anass Baya)
Date: Tue, 21 Oct 2025 15:30:33 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
Message-ID: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>

The tests : 
  test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
  test/jdk/java/awt/print/PrinterJob/PageRanges.java      
  
  were failing because the Arguments yesno to manual option is invalid 
the fix is as follow : 
- Removed yesno
- Used PassFailJFrame manual test framework 
- add the missing keyboard  'test' to PolylinePrintingTest.java

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

Commit messages:
 - Update copyright
 - Update copyright
 - Add bug ID
 - add bug ID
 - Remove extra line
 - Convert test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java to use PassFailJFrame
 - Convert :

Changes: https://git.openjdk.org/jdk/pull/27916/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320677
  Stats: 181 lines in 2 files changed: 23 ins; 132 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/27916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27916/head:pull/27916

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

From prr at openjdk.org  Tue Oct 21 16:46:32 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Oct 2025 16:46:32 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <kLuRWt-J7pT0fxwJ9RgaKDnBVdIjjjBFzIjaI8uYp5U=.8fb5fefb-037f-4edd-a103-bbf09cfc5c7a@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <8Ogw77PdPH_unngwOZrTY3C_8vu1p6hy6TxPkxxwk8U=.b6dfa72a-06ca-4d79-a570-2372b6135b36@github.com>
 <kLuRWt-J7pT0fxwJ9RgaKDnBVdIjjjBFzIjaI8uYp5U=.8fb5fefb-037f-4edd-a103-bbf09cfc5c7a@github.com>
Message-ID: <04-TH9hNOlOmVP3Ah72IoCN0fdHl9KzErQ50hGJD6po=.60a5e3a6-d51b-4763-8747-29c7f27585e2@github.com>

On Tue, 21 Oct 2025 14:22:55 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> > How did the fall back font get there ? It is no longer (since JDK 9) supported to touch that directory https://bugs.openjdk.org/browse/JDK-8368882
> > This issue was reported by one of our customers.  They use JDK 17, but I think the code migrates with JDK upgrades.
> 
> I was unaware that the <JDK_PATH>/lib/font directory is deprecated. At least, this part of the JDK has not been touched for a very long time. Do you remember the JBS record for this?

I tried to paste it but somehow I pasted this bug id (!) It is https://bugs.openjdk.org/browse/JDK-8039273

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3427643058

From prr at openjdk.org  Tue Oct 21 16:55:41 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Oct 2025 16:55:41 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
Message-ID: <VuKhPaBnr8WzUSjKzfLLO2WXUQpTl1JHVF5Kh5t0Y8A=.92b29d19-66d1-49ad-939a-c8055ddda7e0@github.com>

On Mon, 20 Oct 2025 05:58:25 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of eudc.reg

PS as referenced in that bug the updated INTL guide https://docs.oracle.com/en/java/javase/25/intl/font-configuration-files.html#GUID-F8ABF748-F3C3-4781-97B2-66C7E1E10EE9 says

The JDK places any files that it provides in $JDKHOME/lib.
Do not modify that location.
Instead, put any updates or custom versions of the configuration files in $JDKHOME/conf/fonts.
On platforms that support font configuration files, the runtime will look first in $JDKHOME/conf/fonts.

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3427721018

From dnguyen at openjdk.org  Tue Oct 21 17:29:17 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Oct 2025 17:29:17 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v2]
In-Reply-To: <4tTWkP9T1EU0cXnCTXwSQskg7e5ivn9_j4Vv1UKGaZE=.64aeb027-d77b-4611-9b19-f2da3bc28f7d@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>
 <4tTWkP9T1EU0cXnCTXwSQskg7e5ivn9_j4Vv1UKGaZE=.64aeb027-d77b-4611-9b19-f2da3bc28f7d@github.com>
Message-ID: <h58g92kc6nATVNyaT8lGDfg4gY22FWZrymvCuDxthBc=.0aa320e8-048e-4952-b8c4-ccbd16a2aa69@github.com>

On Wed, 8 Oct 2025 00:31:20 GMT, Harshitha Onkar <honkar 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. (I tested the native behavior and suggested to double-check the mnemonics behavior for Frame menu)
> 
> The suggestion was to verify 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.

I have manually added a JMenuBar to the frame in `bug4624207.java` and ran the test with both "apple.laf.useScreenMenuBar" set to true/false. In both cases, the test still fails.

I have looked further into whether macOS officially supports mnemonics, and there are a few occurrences (as you've given examples of some) where mnemonics work, but there seems to be no official documentation that I can find that confirms that this is supported. As such, I believe this change can continue as-is for now.

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

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

From serb at openjdk.org  Tue Oct 21 17:32:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Oct 2025 17:32:09 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used.
In-Reply-To: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
Message-ID: <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>

On Mon, 20 Oct 2025 20:45:47 GMT, Phil Race <prr at openjdk.org> wrote:

> macOS printing uses a Quartz surface. It is the SurfaceData for a CPrinterGraphics.
> That Surface is not disconnected from the graphics unless Graphics.dispose() is called.
> If the application uses Graphics.create() then the implementation will not Graphics.dispose() it.
> If it is used after printing is complete and the CGContext is no longer valid a crash will occur.
> We need to invalidate the surface as soon as printing to a page is done.
> Note: this is Graphics.dispose(), and is unrelated to disposal of an object when it becomes unreachable.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 833:

> 831:                 }
> 832:                 painter.print(pathGraphics, FlipPageFormat.getOriginal(page), pageIndex);
> 833:                 delegate.surfaceData.invalidate();

how this code synchronized? is it always executed on EDT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2449145630

From aivanov at openjdk.org  Tue Oct 21 17:33:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Oct 2025 17:33:16 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
In-Reply-To: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
Message-ID: <DW2PkkZHidYagtEBCp8VEh0SKk3YZJK_3KCSLta_xYk=.cfc83d60-2394-46b4-b303-ea1dddb93db2@github.com>

On Tue, 21 Oct 2025 14:14:46 GMT, Anass Baya <abaya at openjdk.org> wrote:

> The tests : 
>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>   
>   were failing because the Argument yesno to 'manual' option is invalid 
> the fix is as follow : 
> - Removed yesno
> - Used PassFailJFrame manual test framework 
> - add the missing keyboard  'test' to PolylinePrintingTest.java

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 24:

> 22:  */
> 23: 
> 24: /**

Suggestion:

/*

Avoid using javadoc syntax for jtreg tags.

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @bug 6575331 8320677

Bug id that don't modify the product code (JDK) aren't added to the list.

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 51:

> 49:     public static void main(String args[]) throws Exception {
> 50:         PassFailJFrame passFailJFrame = new PassFailJFrame(INSTRUCTIONS);
> 51:         passFailJFrame.positionTestWindow(null, PassFailJFrame.Position.HORIZONTAL);

Use `PassFailJFrame.builder()` to configure and create an instance of `PassFailJFrame`.

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 57:

> 55:             System.out.println("No printer available");
> 56:             PassFailJFrame.forcePass();
> 57:         }

This is an anti-pattern, although it was used previously.

The test has `@key printer`, you can expect a printer is available. It's appropriate to fail the test in this case.

Alternatively, throw `jtreg.SkippedException` if printer is not available. Do it before you start creating `PassFailJFrame`.

test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java line 24:

> 22:  */
> 23: 
> 24: /**

Suggestion:

/*

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

PR Review: https://git.openjdk.org/jdk/pull/27916#pullrequestreview-3361888951
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2449143980
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2449130033
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2449132706
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2449139704
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2449144363

From abaya at openjdk.org  Tue Oct 21 17:48:54 2025
From: abaya at openjdk.org (Anass Baya)
Date: Tue, 21 Oct 2025 17:48:54 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
In-Reply-To: <DW2PkkZHidYagtEBCp8VEh0SKk3YZJK_3KCSLta_xYk=.cfc83d60-2394-46b4-b303-ea1dddb93db2@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
 <DW2PkkZHidYagtEBCp8VEh0SKk3YZJK_3KCSLta_xYk=.cfc83d60-2394-46b4-b303-ea1dddb93db2@github.com>
Message-ID: <Mq1ycnQUVGgXTqhRAPn-jXKZj6I9PVDwKbp4kkRjsWQ=.46ca3d86-e9e4-4f18-a32a-e43dcdd47edc@github.com>

On Tue, 21 Oct 2025 17:24:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The tests : 
>>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>>   
>>   were failing because the Argument yesno to 'manual' option is invalid 
>> the fix is as follow : 
>> - Removed yesno
>> - Used PassFailJFrame manual test framework 
>> - add the missing keyboard  'test' to PolylinePrintingTest.java
>
> test/jdk/java/awt/print/PrinterJob/PageRanges.java line 51:
> 
>> 49:     public static void main(String args[]) throws Exception {
>> 50:         PassFailJFrame passFailJFrame = new PassFailJFrame(INSTRUCTIONS);
>> 51:         passFailJFrame.positionTestWindow(null, PassFailJFrame.Position.HORIZONTAL);
> 
> Use `PassFailJFrame.builder()` to configure and create an instance of `PassFailJFrame`.

Hello @aivanov-jdk,
Thank you for your review.
I used this approach to position the instruction window on the left side of the screen so that it won?t be hidden by the print dialog.
Is it possible to do something similar with the PassFailJFrame.builder()?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2449192883

From prr at openjdk.org  Tue Oct 21 18:17:07 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Oct 2025 18:17:07 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
Message-ID: <JVK28TG8GANFlXlo9FFYS3DvfxXFF7P_ArjX51g-N3U=.82238fe8-dc73-40ad-991a-7b46e9a171f8@github.com>

On Mon, 20 Oct 2025 05:58:25 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of eudc.reg

Please update that one word in the comment - last -> first

BTW the above doesn't invalidate this fix.

I think its is clear that the intent was to skip deferring the already initialized eudcFont but it got the slot wrong.
I see what happened. The eudc font was moved in this fix

https://bugs.openjdk.java.net/browse/JDK-8170913

but the slot that was assumed to be already initialized wasn't changed.

And I notice that this comment on the method.
         * If so add it as the final fallback component of the composite.
Should be revised to
         * If so add it as the first fallback component of the composite.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27551#pullrequestreview-3362097972
PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3428544888

From prr at openjdk.org  Tue Oct 21 18:22:18 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Oct 2025 18:22:18 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used.
In-Reply-To: <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
Message-ID: <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>

On Tue, 21 Oct 2025 17:29:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> macOS printing uses a Quartz surface. It is the SurfaceData for a CPrinterGraphics.
>> That Surface is not disconnected from the graphics unless Graphics.dispose() is called.
>> If the application uses Graphics.create() then the implementation will not Graphics.dispose() it.
>> If it is used after printing is complete and the CGContext is no longer valid a crash will occur.
>> We need to invalidate the surface as soon as printing to a page is done.
>> Note: this is Graphics.dispose(), and is unrelated to disposal of an object when it becomes unreachable.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 833:
> 
>> 831:                 }
>> 832:                 painter.print(pathGraphics, FlipPageFormat.getOriginal(page), pageIndex);
>> 833:                 delegate.surfaceData.invalidate();
> 
> how this code synchronized? is it always executed on EDT?

I don't know where you are headed. All it does is set a boolean variable and there's no reason to be on the EDT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2449292645

From serb at openjdk.org  Tue Oct 21 20:33:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Oct 2025 20:33:48 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used.
In-Reply-To: <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
 <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>
Message-ID: <uLFOyknrOKtfnNnF6gGSrl35pg0225eU9Uhe2f5uwBA=.f7adacbb-0368-4367-b004-de5f6da0ca7b@github.com>

On Tue, 21 Oct 2025 18:19:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 833:
>> 
>>> 831:                 }
>>> 832:                 painter.print(pathGraphics, FlipPageFormat.getOriginal(page), pageIndex);
>>> 833:                 delegate.surfaceData.invalidate();
>> 
>> how this code synchronized? is it always executed on EDT?
>
> I don't know where you are headed. All it does is set a boolean variable and there's no reason to be on the EDT.

I meant, is it possible to get this surfaceData before invalidation on one thread, start rendering to it, and then call delegate.dispose() on another thread? Don't we need some kind of synchronization or is it already somehow implemented?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2449626316

From prr at openjdk.org  Tue Oct 21 20:52:31 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Oct 2025 20:52:31 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used.
In-Reply-To: <uLFOyknrOKtfnNnF6gGSrl35pg0225eU9Uhe2f5uwBA=.f7adacbb-0368-4367-b004-de5f6da0ca7b@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
 <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>
 <uLFOyknrOKtfnNnF6gGSrl35pg0225eU9Uhe2f5uwBA=.f7adacbb-0368-4367-b004-de5f6da0ca7b@github.com>
Message-ID: <2u9x88zYKdfGaA78yMwaHWfc8xMO_3miDt-KK1HLSg8=.a6551d99-10ff-4732-b195-a3c714bd9fa4@github.com>

On Tue, 21 Oct 2025 20:31:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I don't know where you are headed. All it does is set a boolean variable and there's no reason to be on the EDT.
>
> I meant, is it possible to get this surfaceData before invalidation on one thread, start rendering to it, and then call delegate.dispose() on another thread? Don't we need some kind of synchronization or is it already somehow implemented?

delegate.dispose just replaces the reference in the graphics with a NullSurfaceData.
There's no synchronization needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2449667401

From serb at openjdk.org  Tue Oct 21 21:42:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Oct 2025 21:42:02 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used.
In-Reply-To: <2u9x88zYKdfGaA78yMwaHWfc8xMO_3miDt-KK1HLSg8=.a6551d99-10ff-4732-b195-a3c714bd9fa4@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
 <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>
 <uLFOyknrOKtfnNnF6gGSrl35pg0225eU9Uhe2f5uwBA=.f7adacbb-0368-4367-b004-de5f6da0ca7b@github.com>
 <2u9x88zYKdfGaA78yMwaHWfc8xMO_3miDt-KK1HLSg8=.a6551d99-10ff-4732-b195-a3c714bd9fa4@github.com>
Message-ID: <t0uhs0Vi3JNhZcR1fQXL-BIBeB5XDrlj15YuHkOuAHg=.e348c4a6-238a-4efc-9bf1-a56dd30d2b4b@github.com>

On Tue, 21 Oct 2025 20:50:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> I meant, is it possible to get this surfaceData before invalidation on one thread, start rendering to it, and then call delegate.dispose() on another thread? Don't we need some kind of synchronization or is it already somehow implemented?
>
> delegate.dispose just replaces the reference in the graphics with a NullSurfaceData.
> There's no synchronization needed.

multi-threaded version of the `PrintJobAfterEndTest` always crashed for me even with a patch:


import java.awt.Frame;
import java.awt.Graphics;
import java.awt.JobAttributes;
import java.awt.JobAttributes.DialogType;
import java.awt.PageAttributes;
import java.awt.PrintJob;
import java.awt.Toolkit;
import java.util.concurrent.CountDownLatch;

public final class MTPrintJobAfterEndTest {

    public static void main(String[] args) throws InterruptedException {

        JobAttributes jobAttributes = new JobAttributes();
        jobAttributes.setDialog(DialogType.NONE);
        PageAttributes pageAttributes = new PageAttributes();
        Frame f = new Frame();
        Toolkit toolkit = f.getToolkit();

        for (int i = 0; i < 1000; i++) {
            PrintJob job = toolkit.getPrintJob(f, "Crash Test",jobAttributes,
                                               pageAttributes);
            if (job != null) {
                Graphics g = job.getGraphics();
                CountDownLatch latch = new CountDownLatch(1);
                
                Thread endThread = new Thread(() -> {
                    try {
                        latch.await();
                        job.end();
                    } catch (Throwable ignore) {}
                });
                
                Thread drawThread = new Thread(() -> {
                    try {
                        latch.await();
                        g.drawLine(0, 100, 200, 100);
                    } catch (Throwable ignore) {}
                });
                
                endThread.start();
                drawThread.start();
                latch.countDown();
                
                endThread.join();
                drawThread.join();
            }
        }
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2449772224

From serb at openjdk.org  Tue Oct 21 21:55:14 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Oct 2025 21:55:14 GMT
Subject: RFR: 8369032: Add test to ensure serialized ICC_Profile stores
 only necessary optional data [v3]
In-Reply-To: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
References: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
Message-ID: <XGpLEacz3BS3X7itSsLbd2h5VcqD4llNNjruzcQ2090=.e761747b-c68a-4d3b-a476-ecb3a0c5ff41@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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8369032
 - 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/6ad4a82c..71c26aaf

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

  Stats: 33728 lines in 860 files changed: 20081 ins; 9499 del; 4148 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 serb at openjdk.org  Tue Oct 21 22:12:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Oct 2025 22:12:57 GMT
Subject: Integrated: 8369032: Add test to ensure serialized ICC_Profile stores
 only necessary optional data
In-Reply-To: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
References: <XJ_6vsuKwieqNTUdFBDmZRZlBc9Ig09xdCPhb1TdXts=.bb90723b-4ed9-4aeb-af34-1f339f04e17d@github.com>
Message-ID: <hkC82UIxf4WA_bF_go0eIXY-Ex5rGDkutMrZFy-JSDk=.9a3603a5-4008-4333-a379-fca53d13fc1d@github.com>

On Fri, 3 Oct 2025 00:31:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: ed153ee2
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed153ee2c4614c814da92c23c4741eed68ce1a0c
Stats:     72 lines in 1 file changed: 72 ins; 0 del; 0 mod

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

Reviewed-by: honkar

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

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

From tr at openjdk.org  Wed Oct 22 04:10:07 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Oct 2025 04:10:07 GMT
Subject: RFR: 8299304: Test "java/awt/print/PrinterJob/PageDialogTest.java"
 fails on macOS 13 x64 because the Page Dialog blocks the Toolkit
In-Reply-To: <QFHd5fl33BWtFusrpHqoViPZwpEH7-xEYTH0VxcUgJ4=.007d5c24-2aba-47f1-8b86-9d2a7bba3960@github.com>
References: <QFHd5fl33BWtFusrpHqoViPZwpEH7-xEYTH0VxcUgJ4=.007d5c24-2aba-47f1-8b86-9d2a7bba3960@github.com>
Message-ID: <ndf2WJXJtbGEu6dx2R1at4rTRmjnbyuxJ7phY3PspTY=.3585e105-8d08-42f5-a83a-df62f7153f09@github.com>

On Fri, 12 Sep 2025 05:44:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> mac printer dialog blocks underlying window even on native platform so this is not applicable to the test so restricting to run on osx

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27243#pullrequestreview-3363639428

From psadhukhan at openjdk.org  Wed Oct 22 05:24:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Oct 2025 05:24:05 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <tEKlvZL8nngPG0tbW_anpFRtMGdoCxqIQY2uAUg92yE=.b674ed0b-c59a-4f5c-8ef0-bae3625cb122@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
 <f8KCixAR2sfNqHbJ9vM7JTxBp926mV_fxUajNun-89I=.f45957af-9d13-49dd-9fc7-528b9037550a@github.com>
 <Mj4cWwMqQXOAgS0tale2Vl5v8fG47iR_BrdNaVdhq3s=.7c5f4fde-5b50-4a22-9b02-a3efdd538981@github.com>
 <tEKlvZL8nngPG0tbW_anpFRtMGdoCxqIQY2uAUg92yE=.b674ed0b-c59a-4f5c-8ef0-bae3625cb122@github.com>
Message-ID: <dxlTqPseOz1qqArCcem9C5PRvgYVT8fmpn_MllB8u0Y=.a1056987-fda2-4d87-9180-abca8df8e9aa@github.com>

On Sat, 18 Oct 2025 05:59:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > There was a conversation above :
> > Reviewer >> This JBS lists a lot of broken API names. Is this list still valid?
> > Reviewer >> I see that you have chosen to fix only a few.
> > Fixer > Other awt/swing things are fixed already
> 
> The bug is not only about awt/swing, like the next one(still exists?):
> 
> > 10.http://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslServer.html
> > ldap.in = new SecureInputStream(ss, ldap.in);
> > ldap.out = new SecureOutputStream(ss, ldap.out);-> Where are SecureInputStream and SecureOutputStream?
>

As I told, awt/swing were fixed already..This is not client issue..I dont know why those issues are clubbed with this JBS which is in awt area
 
> The ticket also mentioned references to non-public APIs from the specification, such as:
> 
> > 1. http://docs.oracle.com/javase/7/docs/api/index.html?java/awt/Component.html
> >    For paint events, the new event is coalesced into a complex RepaintArea in the peer. > RepaintArea is deleted in 7.0.
> 
> Same for various peers, etc.

RepaintArea is not deleted, it is in sun.awt...I think it was mentioned with the belief that it was deleted and still referenced in the javadoc

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3430548690

From psadhukhan at openjdk.org  Wed Oct 22 05:47:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Oct 2025 05:47:01 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <XXywQrWB8dmw1q8AapaECJigEHXvRPzS91Sj15cSDVM=.b102af32-a6f2-4e6a-92a6-2bc789ed6c48@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <XXywQrWB8dmw1q8AapaECJigEHXvRPzS91Sj15cSDVM=.b102af32-a6f2-4e6a-92a6-2bc789ed6c48@github.com>
Message-ID: <lCq1NGixCFvV_FPuAVDp9o_wH7iRm3Oyf8Pj1_HxvIs=.92bf1b4c-36b3-4b9f-86e8-933a0a5238bb@github.com>

On Sat, 18 Oct 2025 06:53:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I don?t have a strong opinion on whether this is a test bug: using the Motif L&F UI classes while GTK is active, a bug in the Motif UI class that assumes these variables are always set, or a bug in BorderFactory.java as addressed by this PR.

I believe there's always a chance of passing null value to this method from the app since it is public so even if we fix this particular issue somewhere else, there will always be a possibility of getting NPE when null value is passed as highlight and shadow, so this fix is fixing both the motif issue and border NPE issue

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

PR Comment: https://git.openjdk.org/jdk/pull/27839#issuecomment-3430587179

From psadhukhan at openjdk.org  Wed Oct 22 06:11:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Oct 2025 06:11:06 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v3]
In-Reply-To: <YjMNpfVks5hVx8XT03ZBDc0xjldvLi75p-n4FVQL6AY=.b4433aa9-983b-4cdc-bca3-d73435cf67ef@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
 <YjMNpfVks5hVx8XT03ZBDc0xjldvLi75p-n4FVQL6AY=.b4433aa9-983b-4cdc-bca3-d73435cf67ef@github.com>
Message-ID: <6ZpC6SVdBCF7vLR6lpJDONDND0_2v6cE0R4iqkAkgb4=.475f8606-fa22-4d43-957d-938bd7c871c2@github.com>

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

>> When looking into this, it looks like macOS does not support mnemonics. It would therefore make sense to exclude macOS from this test as its main purpose is to test mnemonics on JTabbedPanes. Updated the test header to exclude macOS and test's keyPresses to remove the macOS specific inputs.
>> 
>> https://discussions.apple.com/thread/7983221?sortBy=rank
>
> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8064922/macMnemonics' of github.com:DamonGuy/jdk into 8064922/macMnemonics
>  - Remove unnecessary tags

I guess the testing should not be about mnemonics which does pass in macos as can be seen in [this comment](https://github.com/openjdk/jdk/pull/27371#discussion_r2373050146) but rather `mnemonicsAt` which is tabbed pane specific and I dont know if we have any precedent of this support in native app

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

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

From tr at openjdk.org  Wed Oct 22 06:18:04 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Oct 2025 06:18:04 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v5]
In-Reply-To: <cfecvvipGeuH3nSiDoytFZCFzEFLGG3KsEqIi2JWIU8=.3ec95f7f-a606-4c7c-9b71-e5d1f7decd68@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <cfecvvipGeuH3nSiDoytFZCFzEFLGG3KsEqIi2JWIU8=.3ec95f7f-a606-4c7c-9b71-e5d1f7decd68@github.com>
Message-ID: <qlTSz2XlyuQOgTmXCEaI-VA4p5pwIfv8HxlEckezmZE=.7e28fdfd-7a89-4940-885c-9d4323d7819d@github.com>

On Mon, 6 Oct 2025 06:39:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 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

src/java.desktop/share/classes/javax/swing/JList.java line 2534:

> 2532:                     Rectangle r = getCellBounds(row, row);
> 2533:                     return (r == null) ? 0 :
> 2534:                             (r.height - (visibleRect.y - r.y) < 0) ? 0 : r.height - (visibleRect.y - r.y);

Suggestion:

                            ((r.height - (visibleRect.y - r.y)) < 0) ? 0 : r.height - (visibleRect.y - r.y);

For better readability.

test/jdk/javax/swing/JList/JListTest.java line 47:

> 45:         SwingUtilities.invokeAndWait(() -> {
> 46:             try {
> 47:                 f = new JFrame();

I guess this test can be headless, is there any particular reason for making it headful ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2450534428
PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2450547973

From tr at openjdk.org  Wed Oct 22 06:37:06 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Oct 2025 06:37:06 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v5]
In-Reply-To: <cfecvvipGeuH3nSiDoytFZCFzEFLGG3KsEqIi2JWIU8=.3ec95f7f-a606-4c7c-9b71-e5d1f7decd68@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <cfecvvipGeuH3nSiDoytFZCFzEFLGG3KsEqIi2JWIU8=.3ec95f7f-a606-4c7c-9b71-e5d1f7decd68@github.com>
Message-ID: <jVl7pOBxbi2YPTCPeBnZMLPUQOlD-jmjyMUmzma9sx0=.a3fa54bb-6372-48c5-a1b9-7b2b59e90521@github.com>

On Mon, 6 Oct 2025 06:39:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 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

test/jdk/javax/swing/JList/JListTest.java line 80:

> 78:                 }
> 79:             } finally {
> 80:                 f.dispose();

Null check and EDT is missing for dispose.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2450582621

From abaya at openjdk.org  Wed Oct 22 10:35:20 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 22 Oct 2025 10:35:20 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v2]
In-Reply-To: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
Message-ID: <hm5qXorZOwTfJcVs7ypYBRti_NV2M86fe1S3mRI2Pp8=.1e5cb780-83ab-44a0-a744-20415afb8667@github.com>

> The tests : 
>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>   
>   were failing because the Argument yesno to 'manual' option is invalid 
> the fix is as follow : 
> - Removed yesno
> - Used PassFailJFrame manual test framework 
> - add the missing keyboard  'test' to PolylinePrintingTest.java

Anass Baya has updated the pull request incrementally with two additional commits since the last revision:

 - Verify printer availability at the beginning of the test execution
 - Using the PolylinePrintingTest builder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27916/files
  - new: https://git.openjdk.org/jdk/pull/27916/files/c247b77d..1724e0aa

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

  Stats: 36 lines in 2 files changed: 13 ins; 4 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/27916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27916/head:pull/27916

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

From aivanov at openjdk.org  Wed Oct 22 10:43:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Oct 2025 10:43:02 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v2]
In-Reply-To: <Mq1ycnQUVGgXTqhRAPn-jXKZj6I9PVDwKbp4kkRjsWQ=.46ca3d86-e9e4-4f18-a32a-e43dcdd47edc@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
 <DW2PkkZHidYagtEBCp8VEh0SKk3YZJK_3KCSLta_xYk=.cfc83d60-2394-46b4-b303-ea1dddb93db2@github.com>
 <Mq1ycnQUVGgXTqhRAPn-jXKZj6I9PVDwKbp4kkRjsWQ=.46ca3d86-e9e4-4f18-a32a-e43dcdd47edc@github.com>
Message-ID: <J2dM2t2_iDYsSOUi1lIrKrb_vngHBliGSEqLhIFtFHM=.ac180df6-3138-413b-b47e-ba30d0ddab16@github.com>

On Tue, 21 Oct 2025 17:46:38 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/PageRanges.java line 51:
>> 
>>> 49:     public static void main(String args[]) throws Exception {
>>> 50:         PassFailJFrame passFailJFrame = new PassFailJFrame(INSTRUCTIONS);
>>> 51:         passFailJFrame.positionTestWindow(null, PassFailJFrame.Position.HORIZONTAL);
>> 
>> Use `PassFailJFrame.builder()` to configure and create an instance of `PassFailJFrame`.
>
> Hello @aivanov-jdk,
> Thank you for your review.
> I used this approach to position the instruction window on the left side of the screen so that it won?t be hidden by the print dialog.
> Is it possible to do something similar with the PassFailJFrame.builder()?

The builder supports all the features that you can get when using a `PassFailJFrame` constructor and more.

When you have no test UI, the instructions frame will stay at the centre of the screen when you use the builder. When you call `PassFailJFrame.positionTestWindow(null, PassFailJFrame.Position.HORIZONTAL)`, the instructions frame is still moved to the left as if there's a test window.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451579447

From aivanov at openjdk.org  Wed Oct 22 11:04:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Oct 2025 11:04:31 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v2]
In-Reply-To: <hm5qXorZOwTfJcVs7ypYBRti_NV2M86fe1S3mRI2Pp8=.1e5cb780-83ab-44a0-a744-20415afb8667@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
 <hm5qXorZOwTfJcVs7ypYBRti_NV2M86fe1S3mRI2Pp8=.1e5cb780-83ab-44a0-a744-20415afb8667@github.com>
Message-ID: <4t2GORlV4wan3hbYVbbGu8Ngu8O7TkbzYecRwVQEhuU=.550916d8-c665-4157-b7a8-750efbaf4a3c@github.com>

On Wed, 22 Oct 2025 10:35:20 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> The tests : 
>>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>>   
>>   were failing because the Argument yesno to 'manual' option is invalid 
>> the fix is as follow : 
>> - Removed yesno
>> - Used PassFailJFrame manual test framework 
>> - add the missing keyboard  'test' to PolylinePrintingTest.java
>
> Anass Baya has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Verify printer availability at the beginning of the test execution
>  - Using the PolylinePrintingTest builder

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 49:

> 47:                  In the first dialog, select a page range of 2 to 3, and press OK
> 48:                  In the second dialog, select ALL, to print all pages (in total 5 pages).
> 49:                  Collect the two print outs and confirm the jobs printed correctly.

Suggestion:

                 This test prints two jobs and tests that the specified range
                 of pages is printed.
                 In the first dialog, select a page range of 2 to 3, and press OK.
                 In the second dialog, select ALL, to print all pages (in total 5 pages).
                 Collect the two print outs and confirm the jobs are printed correctly.


Now the test won't start if there's no printer.

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 54:

> 52:     public static void main(String args[]) throws Exception {
> 53:         PrinterJob job = PrinterJob.getPrinterJob();
> 54:         if(job.getPrintService() == null) {

Suggestion:

        if (job.getPrintService() == null) {

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 60:

> 58:         PassFailJFrame passFailJFrame = PassFailJFrame.builder()
> 59:                 .instructions(INSTRUCTIONS)
> 60:                 .rows((int) INSTRUCTIONS.lines().count() + 2)

This is the default value for `.rows`, thus, it can be omitted.

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 78:

> 76:                      throws PrinterException {
> 77: 
> 78:         if (pi >= 5) {

At the same time, I dislike blank lines at the very start of method, they serve no purpose.
Suggestion:

                     throws PrinterException {
        if (pi >= 5) {

test/jdk/java/awt/print/PrinterJob/PageRanges.java line 83:

> 81: 
> 82:         g.drawString("Page : " + (pi+1), 200, 200);
> 83:         return PAGE_EXISTS;

I would keep the blank line here: it separates the body of the printing (drawing a string) from the return value. Although, in such a short method it's not as needed.

test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java line 47:

> 45:     private static final String INSTRUCTIONS = """
> 46:               You must have a printer available to perform this test.
> 47:               OK the print dialog, and collect the printed page.

Suggestion:

              Click OK in the print dialog and collect the printed page.

test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java line 62:

> 60: 
> 61:         passFailJFrame.awaitAndCheck();
> 62:     }

This second test may also throw `jtreg.SkippedException` if the printer is not available. Then you can remove this statement from the instructions.

I would also place the test code inside the main method as it's done in the `PageRanges.java` test.

I also think setting the page format and paper isn't necessary to reproduce the original bug [JDK-8041902](https://bugs.openjdk.org/browse/JDK-8041902), so this can be removed from the test, which will make the code small enough to inline into the main method.

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

PR Review: https://git.openjdk.org/jdk/pull/27916#pullrequestreview-3365146703
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451585936
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451589536
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451592735
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451608653
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451601250
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451615514
PR Review Comment: https://git.openjdk.org/jdk/pull/27916#discussion_r2451662295

From abaya at openjdk.org  Wed Oct 22 11:16:54 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 22 Oct 2025 11:16:54 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v3]
In-Reply-To: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
Message-ID: <0zzOF8evgLHpBQah8L9beZOVEt7qkY-DEtF36AQBTwE=.d32a2da8-d658-4c68-b0c4-5f8659840658@github.com>

> The tests : 
>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>   
>   were failing because the Argument yesno to 'manual' option is invalid 
> the fix is as follow : 
> - Removed yesno
> - Used PassFailJFrame manual test framework 
> - add the missing keyboard  'test' to PolylinePrintingTest.java

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27916/files
  - new: https://git.openjdk.org/jdk/pull/27916/files/1724e0aa..58ca7af3

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

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

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

From abaya at openjdk.org  Wed Oct 22 12:19:42 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 22 Oct 2025 12:19:42 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v4]
In-Reply-To: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
Message-ID: <eoqa3zfvSlLBidoh4oWzpBncVYrO8YWK6eqnwzGlTzk=.d6515a88-fc8e-4370-b6e9-dde75122b70c@github.com>

> The tests : 
>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>   
>   were failing because the Argument yesno to 'manual' option is invalid 
> the fix is as follow : 
> - Removed yesno
> - Used PassFailJFrame manual test framework 
> - add the missing keyboard  'test' to PolylinePrintingTest.java

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Remove page format - throw jtreg.SkippedException if the printer is not available - Enhancments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27916/files
  - new: https://git.openjdk.org/jdk/pull/27916/files/58ca7af3..4803d8a9

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

  Stats: 31 lines in 2 files changed: 11 ins; 18 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27916/head:pull/27916

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

From aivanov at openjdk.org  Wed Oct 22 12:35:20 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Oct 2025 12:35:20 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v4]
In-Reply-To: <eoqa3zfvSlLBidoh4oWzpBncVYrO8YWK6eqnwzGlTzk=.d6515a88-fc8e-4370-b6e9-dde75122b70c@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
 <eoqa3zfvSlLBidoh4oWzpBncVYrO8YWK6eqnwzGlTzk=.d6515a88-fc8e-4370-b6e9-dde75122b70c@github.com>
Message-ID: <61dwNWeXrRrFryfrC-JOksn5yPKpAb2BMp218GSxKT0=.120a8662-11c0-4e44-9ce0-52896f98ab6e@github.com>

On Wed, 22 Oct 2025 12:19:42 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> The tests : 
>>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>>   
>>   were failing because the Argument yesno to 'manual' option is invalid 
>> the fix is as follow : 
>> - Removed yesno
>> - Used PassFailJFrame manual test framework 
>> - add the missing keyboard  'test' to PolylinePrintingTest.java
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove page format - throw jtreg.SkippedException if the printer is not available - Enhancments

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27916#pullrequestreview-3365573874

From abaya at openjdk.org  Wed Oct 22 14:24:14 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 22 Oct 2025 14:24:14 GMT
Subject: RFR: 8274082 : Wrong test case name specified in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java
Message-ID: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>

Following issues were fixed in this test

1. Fixed - Parser error due to yesno in @run main/manual=yesno
2. Fixed Wrong test name specified in @run jtreg
3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
4. Use PassFailJFrame test framework
5. Enhance Instructions
6. Skip the test if no Printer is available

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

Commit messages:
 - - Remove yesno

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

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

From abaya at openjdk.org  Wed Oct 22 15:03:08 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 22 Oct 2025 15:03:08 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v2]
In-Reply-To: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
Message-ID: <pvX3qRKus12pHGo4uthcjgNxfE_9gNH-17muBFyofb4=.9f98f258-6d79-4506-92ae-a905cb880c33@github.com>

> Following issues were fixed in this test
> 
> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
> 2. Fixed Wrong test name specified in @run jtreg
> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 4. Use PassFailJFrame test framework
> 5. Enhance Instructions
> 6. Skip the test if no Printer is available

Anass Baya has updated the pull request incrementally with two additional commits since the last revision:

 - add "manual" tag
 - Align instructions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27938/files
  - new: https://git.openjdk.org/jdk/pull/27938/files/e2318e05..643f4174

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

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

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

From acobbs at openjdk.org  Wed Oct 22 15:21:43 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 22 Oct 2025 15:21:43 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v4]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <mHC6vbCdDTDOUixEI-cZeIvxCy2CEzGlW14LdKzINwE=.0b3e1e71-583b-48ab-9546-3485a1a61e01@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 133 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - 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.
 - ... and 123 more: https://git.openjdk.org/jdk/compare/a1be2979...f2b75547

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=03
  Stats: 1665 lines in 34 files changed: 1490 ins; 49 del; 126 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 honkar at openjdk.org  Wed Oct 22 18:50:27 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Oct 2025 18:50:27 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v3]
In-Reply-To: <YjMNpfVks5hVx8XT03ZBDc0xjldvLi75p-n4FVQL6AY=.b4433aa9-983b-4cdc-bca3-d73435cf67ef@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
 <YjMNpfVks5hVx8XT03ZBDc0xjldvLi75p-n4FVQL6AY=.b4433aa9-983b-4cdc-bca3-d73435cf67ef@github.com>
Message-ID: <9BCcmDR5TMaLaZSxi4X56b54jZ58ZJytAcU708jYC4k=.f0f3a1ca-b1f6-4fa1-ac5c-27002d1f056b@github.com>

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

>> When looking into this, it looks like macOS does not support mnemonics. It would therefore make sense to exclude macOS from this test as its main purpose is to test mnemonics on JTabbedPanes. Updated the test header to exclude macOS and test's keyPresses to remove the macOS specific inputs.
>> 
>> https://discussions.apple.com/thread/7983221?sortBy=rank
>
> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8064922/macMnemonics' of github.com:DamonGuy/jdk into 8064922/macMnemonics
>  - Remove unnecessary tags

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27371#pullrequestreview-3367117211

From honkar at openjdk.org  Wed Oct 22 18:50:28 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Oct 2025 18:50:28 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v3]
In-Reply-To: <6ZpC6SVdBCF7vLR6lpJDONDND0_2v6cE0R4iqkAkgb4=.475f8606-fa22-4d43-957d-938bd7c871c2@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
 <YjMNpfVks5hVx8XT03ZBDc0xjldvLi75p-n4FVQL6AY=.b4433aa9-983b-4cdc-bca3-d73435cf67ef@github.com>
 <6ZpC6SVdBCF7vLR6lpJDONDND0_2v6cE0R4iqkAkgb4=.475f8606-fa22-4d43-957d-938bd7c871c2@github.com>
Message-ID: <MV23f5KFvJ0ycnqqMGEpA9F6gAO_z8najAaZH59p8u4=.8869d028-c5fd-488e-b4d9-9299d1396eca@github.com>

On Wed, 22 Oct 2025 06:07:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch '8064922/macMnemonics' of github.com:DamonGuy/jdk into 8064922/macMnemonics
>>  - Remove unnecessary tags
>
> I guess the testing should not be about mnemonics which does pass in macos as can be seen in [this comment](https://github.com/openjdk/jdk/pull/27371#discussion_r2373050146) but rather `mnemonicsAt` which is tabbed pane specific and I dont know if we have any precedent of this support in native app

@prsadhuk 
> I guess the testing should not be about mnemonics which does pass in macos as can be seen in https://github.com/openjdk/jdk/pull/27371#discussion_r2373050146 but rather mnemonicsAt which is tabbed pane specific and I dont know if we have any precedent of this support in native app

Right, but the post https://discussions.apple.com/thread/7983221?sortBy=rank discusses about general menu mnemonics and quite old post (filed in 2017). Now the menu mnemonics seem to work (native and IntelliJ app), thus wanted to verify if it is the case that mnemonics works frame menu and not for tab mnemonics.

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

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

From honkar at openjdk.org  Wed Oct 22 18:50:30 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Oct 2025 18:50:30 GMT
Subject: RFR: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails [v3]
In-Reply-To: <QMY6-ab0eVFGgjjDNLaLTCg3aBxoKOmoxM0iG11ND8U=.0ca06640-72b4-4a8e-a133-78a314f6520a@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
 <l6azrbG4cj_LmvFiGHiOXya89xErNmvXcRE1mg-ZY-0=.c1d311a2-e305-4c91-80da-4e71c711370f@github.com>
 <k93B17VuvLH4OEpK2l0RFs27m3JA-qKovTWsCVoh12U=.fb584036-e5a8-45fe-8a25-1bed61be700b@github.com>
 <sbV56_XbRrua7HCmLtHEr21AiOSx5g2cbpiNa2TnFdc=.ee5bcc0e-46ee-4c6f-9e12-339faf9162ca@github.com>
 <Cmqkc1YGHsS6dCgQu4SDe8q5a9zQJVWoHxH1M5N6G-w=.90ed0dc9-eaa4-41bb-8441-d6636cf2e7b7@github.com>
 <QMY6-ab0eVFGgjjDNLaLTCg3aBxoKOmoxM0iG11ND8U=.0ca06640-72b4-4a8e-a133-78a314f6520a@github.com>
Message-ID: <9YiY83uAiCR9xXF2lqDAdVxpATbLosxhc3iGjGcX4Vw=.c54fcd63-c922-4b6d-9c24-fafcb761636b@github.com>

On Wed, 24 Sep 2025 04:10:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Also you may want to check another test `EditableFocusTest` which also sets mnemonic "B" on a JButton and it passes in macOS..One difference is it uses setMnemonic(char) instead of setMnemonic(int)
>> 
>> I see that test's `setMnemonic`. This tabbedPane's API is forced to use `setMnemonicAt(int, int)`. I figured, since mnemonics don't seem to be supported on macOS anyway, it does not really make sense to ProblemList this test for macOS only, and instead just exclude macOS from the test since the test fails with the current implementation using `setMnemonicAt`.
>
> It is not macOS but Aqua L&F problem it seems...
> javax/swing/JTabbedPane/8134116/Bug8134116.java also uses `setMnemonicAt` but it uses Nimbus and it seems to pass on macOS as per CI
> but I guess its ok to restrict as native macOS where it doesn't seem to work will run on its own Aqua L&F kind of interface

Even with Nimbus LaF `javax/swing/JTabbedPane/8134116/Bug8134116.java` the mnemonic is set as VK_Z for tab "zero" and though 'z' is underlined it does not respond to the keypress. Looks like it does not work completely in Nimbus LaF too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27371#discussion_r2453045480

From dnguyen at openjdk.org  Wed Oct 22 21:08:30 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Oct 2025 21:08:30 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v4]
In-Reply-To: <eoqa3zfvSlLBidoh4oWzpBncVYrO8YWK6eqnwzGlTzk=.d6515a88-fc8e-4370-b6e9-dde75122b70c@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
 <eoqa3zfvSlLBidoh4oWzpBncVYrO8YWK6eqnwzGlTzk=.d6515a88-fc8e-4370-b6e9-dde75122b70c@github.com>
Message-ID: <9kNV5ULgjhz4Ck7P0f14qlZce6eI7ap7FpjZVdBMiB0=.c544db67-dbaa-46ef-be0f-bfb30397d715@github.com>

On Wed, 22 Oct 2025 12:19:42 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> The tests : 
>>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>>   
>>   were failing because the Argument yesno to 'manual' option is invalid 
>> the fix is as follow : 
>> - Removed yesno
>> - Used PassFailJFrame manual test framework 
>> - add the missing keyboard  'test' to PolylinePrintingTest.java
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove page format - throw jtreg.SkippedException if the printer is not available - Enhancments

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27916#pullrequestreview-3367544382

From dnguyen at openjdk.org  Wed Oct 22 21:08:32 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Oct 2025 21:08:32 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v2]
In-Reply-To: <pvX3qRKus12pHGo4uthcjgNxfE_9gNH-17muBFyofb4=.9f98f258-6d79-4506-92ae-a905cb880c33@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
 <pvX3qRKus12pHGo4uthcjgNxfE_9gNH-17muBFyofb4=.9f98f258-6d79-4506-92ae-a905cb880c33@github.com>
Message-ID: <cfu7au1UDj2wNdQFzBUtSXrSOjjV7V7OW4LDe3vzlGg=.30817b7f-406c-479f-af3d-1a8392e2dc51@github.com>

On Wed, 22 Oct 2025 15:03:08 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> Following issues were fixed in this test
>> 
>> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
>> 2. Fixed Wrong test name specified in @run jtreg
>> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
>> 4. Use PassFailJFrame test framework
>> 5. Enhance Instructions
>> 6. Skip the test if no Printer is available
>
> Anass Baya has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add "manual" tag
>  - Align instructions

test/jdk/java/awt/print/PrinterJob/SwingUIText.java line 30:

> 28:  * @summary Test that text printed in Swing UI measures and looks OK.
> 29:  * @library /java/awt/regtesthelpers /test/lib
> 30:  * @library /test/lib

Do you have `/test/lib` twice?

test/jdk/java/awt/print/PrinterJob/SwingUIText.java line 89:

> 87:         frame = new JFrame();
> 88:         JPanel panel = new JPanel();
> 89:         panel.setLayout(new GridLayout(4,1));

Suggestion:

        frame = new JFrame();
        JPanel panel = new JPanel();
        panel.setLayout(new GridLayout(4, 1));


Just because I happened to see it, you can add a space here to follow the precedent like in `displayText` just below this.

test/jdk/java/awt/print/PrinterJob/SwingUIText.java line 126:

> 124:     static void displayText(JPanel p, String text) {
> 125:         JPanel panel = new JPanel();
> 126:         panel.setLayout(new GridLayout(2,1));

Suggestion:

        panel.setLayout(new GridLayout(2, 1));


There is also another purely syntax issue slightly below this by adding spaces around the `+`:

JButton button = new JButton("Print " + text);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27938#discussion_r2453342500
PR Review Comment: https://git.openjdk.org/jdk/pull/27938#discussion_r2453347020
PR Review Comment: https://git.openjdk.org/jdk/pull/27938#discussion_r2453352039

From honkar at openjdk.org  Wed Oct 22 22:08:47 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Oct 2025 22:08:47 GMT
Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent()
Message-ID: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>

`findComponent(final Container container, final Predicate<Component> predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name.

PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic.

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

Commit messages:
 - refactoring changes

Changes: https://git.openjdk.org/jdk/pull/27944/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353755
  Stats: 60 lines in 3 files changed: 36 ins; 18 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27944/head:pull/27944

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

From dnguyen at openjdk.org  Wed Oct 22 22:46:05 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Oct 2025 22:46:05 GMT
Subject: Integrated: 8064922: [macos] Test
 javax/swing/JTabbedPane/4624207/bug4624207.java fails
In-Reply-To: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
References: <u9z6JZgCRku5tib-fPqTgDIabGA0Fb930UMXcVazU-A=.6d7e63c0-3015-4da8-83ff-c271925d5311@github.com>
Message-ID: <fh6wD4Qo7utyN-fwIcFGJx1Ze0FpNrvC0zrwndwNxaY=.86931b2f-6b3a-444c-a3d5-df10cee9893b@github.com>

On Thu, 18 Sep 2025 18:13:43 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> When looking into this, it looks like macOS does not support mnemonics. It would therefore make sense to exclude macOS from this test as its main purpose is to test mnemonics on JTabbedPanes. Updated the test header to exclude macOS and test's keyPresses to remove the macOS specific inputs.
> 
> https://discussions.apple.com/thread/7983221?sortBy=rank

This pull request has now been integrated.

Changeset: be18e7ec
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be18e7ecfd2e89a0abb168e0d9a5b69598e2199f
Stats:     52 lines in 2 files changed: 12 ins; 24 del; 16 mod

8064922: [macos] Test javax/swing/JTabbedPane/4624207/bug4624207.java fails

Reviewed-by: tr, honkar, psadhukhan

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

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

From abaya at openjdk.org  Wed Oct 22 23:27:19 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 22 Oct 2025 23:27:19 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v3]
In-Reply-To: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
Message-ID: <E45EUf2fvsYuGBaZXBSLxTx5sP1EW2HgRMhdY7Qkxrg=.6f1b9886-51f1-48ce-8fc2-6c238a6b59d2@github.com>

> Following issues were fixed in this test
> 
> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
> 2. Fixed Wrong test name specified in @run jtreg
> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 4. Use PassFailJFrame test framework
> 5. Enhance Instructions
> 6. Skip the test if no Printer is available

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

   DamonGuy review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27938/files
  - new: https://git.openjdk.org/jdk/pull/27938/files/643f4174..255a53df

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

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

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

From duke at openjdk.org  Wed Oct 22 23:27:28 2025
From: duke at openjdk.org (duke)
Date: Wed, 22 Oct 2025 23:27:28 GMT
Subject: RFR: 8320677: Printer tests use invalid '@run main/manual=yesno
 [v4]
In-Reply-To: <eoqa3zfvSlLBidoh4oWzpBncVYrO8YWK6eqnwzGlTzk=.d6515a88-fc8e-4370-b6e9-dde75122b70c@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
 <eoqa3zfvSlLBidoh4oWzpBncVYrO8YWK6eqnwzGlTzk=.d6515a88-fc8e-4370-b6e9-dde75122b70c@github.com>
Message-ID: <60j1nBXd9Sme_PeYMhRF5uvy-WA6kodP4BxJX-TMCIg=.a86d920a-0de0-40b3-bad4-6b73638b8b27@github.com>

On Wed, 22 Oct 2025 12:19:42 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> The tests : 
>>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>>   
>>   were failing because the Argument yesno to 'manual' option is invalid 
>> the fix is as follow : 
>> - Removed yesno
>> - Used PassFailJFrame manual test framework 
>> - add the missing keyboard  'test' to PolylinePrintingTest.java
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove page format - throw jtreg.SkippedException if the printer is not available - Enhancments

@anass-baya 
Your change (at version 4803d8a9c7e56fcdc2806c2cddcec3d1ede03405) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27916#issuecomment-3434524830

From serb at openjdk.org  Wed Oct 22 23:54:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 22 Oct 2025 23:54:49 GMT
Subject: RFR: 6185110: Undefined behaviour of SampleModel for width,
 height < 0
In-Reply-To: <I_NOWCl0A-jhP7oUzZL2B2EhPOpkW48tM_r1cZELA2E=.0d3d3e26-20ec-419c-aadd-8f71a6c0b9fa@github.com>
References: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
 <DNn5LtgCHlzTbjNA_EEYxhdxkMmeqsF2nIL6F6T-Njw=.e98ccfd1-0127-493b-ba6d-6b20c6b93b6f@github.com>
 <I_NOWCl0A-jhP7oUzZL2B2EhPOpkW48tM_r1cZELA2E=.0d3d3e26-20ec-419c-aadd-8f71a6c0b9fa@github.com>
Message-ID: <0BGaxDisBbJuLPWyUCeVrWn52DpIMPzA91NjPEuYojo=.6551d28a-031a-4fa2-b693-044a8b84acad@github.com>

On Thu, 16 Oct 2025 19:20:21 GMT, Phil Race <prr at openjdk.org> wrote:

>That would not help. In fact it makes it harder.

I tried building this method without any additional Javadoc, using only @Override to highlight that it overrides the parent method. The generated Javadoc for ComponentSampleModel does not include a separate description of getPixel, but instead provides a link to the inherited method in the parent class, which contains all the relevant information. Isn?t this exactly the behavior we want to achieve?

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

PR Comment: https://git.openjdk.org/jdk/pull/27754#issuecomment-3434584012

From serb at openjdk.org  Thu Oct 23 01:09:13 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 01:09:13 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <lCq1NGixCFvV_FPuAVDp9o_wH7iRm3Oyf8Pj1_HxvIs=.92bf1b4c-36b3-4b9f-86e8-933a0a5238bb@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <XXywQrWB8dmw1q8AapaECJigEHXvRPzS91Sj15cSDVM=.b102af32-a6f2-4e6a-92a6-2bc789ed6c48@github.com>
 <lCq1NGixCFvV_FPuAVDp9o_wH7iRm3Oyf8Pj1_HxvIs=.92bf1b4c-36b3-4b9f-86e8-933a0a5238bb@github.com>
Message-ID: <JM14OVqCiNUV8-x3Aa0Evb2UEgChfCBfxUXjM8rMDUY=.7980f2eb-b324-4be3-924f-47a3c253955c@github.com>

On Wed, 22 Oct 2025 05:44:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I believe there's always a chance of passing null value to this method from the app since it is public so even if we fix this particular issue somewhere else, there will always be a possibility of getting NPE when null value is passed as highlight and shadow, so this fix is fixing both the gtk issue and border NPE issue

Maybe, but the updated code would not follow the spec, which requires that the new border use the color parameters for rendering. Instead, it would use "brighter shades of the component's current background color for highlighting, and darker shades for shadows." Also, note that there are several other similar methods that gets the colors, do all of them throw a NPE on null?

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

PR Comment: https://git.openjdk.org/jdk/pull/27839#issuecomment-3434723363

From psadhukhan at openjdk.org  Thu Oct 23 01:42:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 01:42:05 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <JM14OVqCiNUV8-x3Aa0Evb2UEgChfCBfxUXjM8rMDUY=.7980f2eb-b324-4be3-924f-47a3c253955c@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <XXywQrWB8dmw1q8AapaECJigEHXvRPzS91Sj15cSDVM=.b102af32-a6f2-4e6a-92a6-2bc789ed6c48@github.com>
 <lCq1NGixCFvV_FPuAVDp9o_wH7iRm3Oyf8Pj1_HxvIs=.92bf1b4c-36b3-4b9f-86e8-933a0a5238bb@github.com>
 <JM14OVqCiNUV8-x3Aa0Evb2UEgChfCBfxUXjM8rMDUY=.7980f2eb-b324-4be3-924f-47a3c253955c@github.com>
Message-ID: <fXPTKUvPxdweQpP6VH2GkW_X7MitUiRaCErjjWgsbfk=.698fdcf1-e716-4501-a40a-4750ff2562e9@github.com>

On Thu, 23 Oct 2025 01:06:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I believe there's always a chance of passing null value to this method from the app since it is public so even if we fix this particular issue somewhere else, there will always be a possibility of getting NPE when null value is passed as highlight and shadow, so this fix is fixing both the gtk issue and border NPE issue
> 
> Maybe, but the updated code would not follow the spec, which requires that the new border use the color parameters for rendering. Instead, it would use "brighter shades of the component's current background color for highlighting, and darker shades for shadows." Also, note that there are several other similar methods that gets the colors, do all of them throw a NPE on null?

It fails for createSoftBevelBorder too..so what do you suggest, update the spec? If it is null, it's quite evident that we will not be using it to obtain brighter shade..

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

PR Comment: https://git.openjdk.org/jdk/pull/27839#issuecomment-3434775528

From psadhukhan at openjdk.org  Thu Oct 23 02:08:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 02:08:59 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v6]
In-Reply-To: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
Message-ID: <rAKx1SGlyBUrAfKqRG3HOcFrPGcc8iFVKA6SbJBUZtQ=.dbeb3365-4367-40e2-8774-aa34557edc70@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 two additional commits since the last revision:

 - Review comment fix
 - Review comment fix

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

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

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

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

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

From psadhukhan at openjdk.org  Thu Oct 23 02:09:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 02:09:04 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v5]
In-Reply-To: <qlTSz2XlyuQOgTmXCEaI-VA4p5pwIfv8HxlEckezmZE=.7e28fdfd-7a89-4940-885c-9d4323d7819d@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <cfecvvipGeuH3nSiDoytFZCFzEFLGG3KsEqIi2JWIU8=.3ec95f7f-a606-4c7c-9b71-e5d1f7decd68@github.com>
 <qlTSz2XlyuQOgTmXCEaI-VA4p5pwIfv8HxlEckezmZE=.7e28fdfd-7a89-4940-885c-9d4323d7819d@github.com>
Message-ID: <xpONYcxMXOAKXIoWLp6MmGcpiQUlaNyf9Z81oUoRHAY=.068dda9b-efcb-4dda-9816-606a110c5add@github.com>

On Wed, 22 Oct 2025 06:06:55 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/java.desktop/share/classes/javax/swing/JList.java line 2534:
> 
>> 2532:                     Rectangle r = getCellBounds(row, row);
>> 2533:                     return (r == null) ? 0 :
>> 2534:                             (r.height - (visibleRect.y - r.y) < 0) ? 0 : r.height - (visibleRect.y - r.y);
> 
> Suggestion:
> 
>                             ((r.height - (visibleRect.y - r.y)) < 0) ? 0 : r.height - (visibleRect.y - r.y);
> 
> For better readability.

ok

> test/jdk/javax/swing/JList/JListTest.java line 47:
> 
>> 45:         SwingUtilities.invokeAndWait(() -> {
>> 46:             try {
>> 47:                 f = new JFrame();
> 
> Can this test be made headless ?

No, it seems it doesn't fail without the fix if it is headless, probably because the scrollable viewport will not be same if its not visible

> test/jdk/javax/swing/JList/JListTest.java line 80:
> 
>> 78:                 }
>> 79:             } finally {
>> 80:                 f.dispose();
> 
> Null check and EDT is missing for dispose.

its already in EDT but null check added even though it probably will not be null as it is in the block

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2453737001
PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2453738662
PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2453739627

From psadhukhan at openjdk.org  Thu Oct 23 02:20:33 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 02:20:33 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel [v2]
In-Reply-To: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
Message-ID: <dryS-UfMZWAbjGsnDQ3WAX45EeXwfEiZJsr5RpnoZmg=.4c4689a1-ef2a-4fa2-815e-a78530a88059@github.com>

> Test fails in GTKLookAndFeel with NPE
> 
> java.lang.NullPointerException
> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
> 
> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
> 
> Fix is made to not use these color to create BevelBorder if these colors are not present..

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

  Update doc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27839/files
  - new: https://git.openjdk.org/jdk/pull/27839/files/6051c685..cb9a559b

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

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

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

From psadhukhan at openjdk.org  Thu Oct 23 02:25:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 02:25:03 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v7]
In-Reply-To: <WIw5ww2DcTINZdf2y9oo-zfT6lo0YbSHBLk2JtmI9vo=.4702adb3-75d5-4490-b5ea-01943505c5ba@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
 <OuWWSPqxroyynHgzTFoYG83eBw4x8DERnGsErjCkM6s=.3e9925de-6e8a-4d1a-8f60-40d6a977c1e6@github.com>
 <WIw5ww2DcTINZdf2y9oo-zfT6lo0YbSHBLk2JtmI9vo=.4702adb3-75d5-4490-b5ea-01943505c5ba@github.com>
Message-ID: <AEqUbZRKNF6kmh0ZpgavVVnWbf9cH9EJVSVvYI47YuE=.f52eaf35-b3b2-4b34-8477-42e2c30846e8@github.com>

On Mon, 20 Oct 2025 21:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

> > That is strange..It is working for me but on retina display but I believe CI osx systems all use external displays and it does not hang there it seems..
> 
> It works for me too on retina. Have you tried an external display on your system ? It is a 100 % consistent hang for me.

I dont have external display setup for my mac to test, adapter issue...but I was wondering our macOS macmini systems in CI should be using external display where it passes for several iterations so what is the difference in configuration?

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

PR Comment: https://git.openjdk.org/jdk/pull/27365#issuecomment-3434836336

From serb at openjdk.org  Thu Oct 23 03:21:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 03:21:05 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <fXPTKUvPxdweQpP6VH2GkW_X7MitUiRaCErjjWgsbfk=.698fdcf1-e716-4501-a40a-4750ff2562e9@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <XXywQrWB8dmw1q8AapaECJigEHXvRPzS91Sj15cSDVM=.b102af32-a6f2-4e6a-92a6-2bc789ed6c48@github.com>
 <lCq1NGixCFvV_FPuAVDp9o_wH7iRm3Oyf8Pj1_HxvIs=.92bf1b4c-36b3-4b9f-86e8-933a0a5238bb@github.com>
 <JM14OVqCiNUV8-x3Aa0Evb2UEgChfCBfxUXjM8rMDUY=.7980f2eb-b324-4be3-924f-47a3c253955c@github.com>
 <fXPTKUvPxdweQpP6VH2GkW_X7MitUiRaCErjjWgsbfk=.698fdcf1-e716-4501-a40a-4750ff2562e9@github.com>
Message-ID: <VhXN4WLTgbzVXQOdd3Jxfy1u75e5kD98QTTDX8U_Fr8=.b7ca860f-1139-4979-9556-f349d53e6bdb@github.com>

On Thu, 23 Oct 2025 01:39:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It fails for createSoftBevelBorder too..so what do you suggest, update the spec? If it is null, it's quite evident that we will not be using it to obtain brighter shade..

This particular bug can be fixed by explicitly setting the Motif L&F in the test before using motif UI classes. This will allow it to be backported. In a separate fix, we can update the specifications of these methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/27839#issuecomment-3434919305

From psadhukhan at openjdk.org  Thu Oct 23 03:26:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 03:26:35 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text.
Message-ID: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>

GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary

Before fix
<img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />


With fix
<img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />

No regressions is observed in CI..A manual verification test is provided..

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

Commit messages:
 - 8017266: Background is painted taller than needed for styled text.

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

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

From psadhukhan at openjdk.org  Thu Oct 23 03:34:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 03:34:38 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel [v3]
In-Reply-To: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
Message-ID: <cQpjFAI3OTfsLfkiUjnZkWQMjg1A8BpHL0yV4hpuf4c=.d0e89bcf-50a7-4c06-85ec-d164f26cc5fa@github.com>

> Test fails in GTKLookAndFeel with NPE
> 
> java.lang.NullPointerException
> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
> 
> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
> 
> Fix is made to not use these color to create BevelBorder if these colors are not present..

Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:

 - Use motif L&F in test
 - Use motif L&F in test
 - Use motif L&F in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27839/files
  - new: https://git.openjdk.org/jdk/pull/27839/files/cb9a559b..546b6caf

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

  Stats: 17 lines in 2 files changed: 2 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27839/head:pull/27839

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

From psadhukhan at openjdk.org  Thu Oct 23 03:34:40 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 03:34:40 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel [v2]
In-Reply-To: <dryS-UfMZWAbjGsnDQ3WAX45EeXwfEiZJsr5RpnoZmg=.4c4689a1-ef2a-4fa2-815e-a78530a88059@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <dryS-UfMZWAbjGsnDQ3WAX45EeXwfEiZJsr5RpnoZmg=.4c4689a1-ef2a-4fa2-815e-a78530a88059@github.com>
Message-ID: <TusuXXLqr-b0OirUqfRZJFvYDZji0eBTo5FcXneQW0M=.118dd812-fffc-4d9a-a769-f6d16650b0cd@github.com>

On Thu, 23 Oct 2025 02:20:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in GTKLookAndFeel with NPE
>> 
>> java.lang.NullPointerException
>> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
>> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
>> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
>> 
>> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
>> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
>> 
>> Fix is made to not use these color to create BevelBorder if these colors are not present..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update doc

ok updated test to set Motif

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

PR Comment: https://git.openjdk.org/jdk/pull/27839#issuecomment-3434937149

From abaya at openjdk.org  Thu Oct 23 06:32:12 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 23 Oct 2025 06:32:12 GMT
Subject: Integrated: 8320677: Printer tests use invalid '@run main/manual=yesno
In-Reply-To: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
References: <2T0Je2pC46ttfrBLdELUfDi4mfCEsVeWcD_2LRB1XyE=.20ca70bb-0273-433c-9c32-12cf1bd09844@github.com>
Message-ID: <l-MprFFruE_0h8UadgcYgsnRvDEsYPFYTOmR8VhQrQY=.e3d07c99-fcc9-4da2-a406-aeacd2dd8f31@github.com>

On Tue, 21 Oct 2025 14:14:46 GMT, Anass Baya <abaya at openjdk.org> wrote:

> The tests : 
>   test/jdk/java/awt/print/PrinterJob/PolylinePrintingTest.java
>   test/jdk/java/awt/print/PrinterJob/PageRanges.java      
>   
>   were failing because the Argument yesno to 'manual' option is invalid 
> the fix is as follow : 
> - Removed yesno
> - Used PassFailJFrame manual test framework 
> - add the missing keyboard  'test' to PolylinePrintingTest.java

This pull request has now been integrated.

Changeset: ffcb1585
Author:    Anass Baya <abaya at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffcb1585ed6c2a2bff28be6854d44a672aa31a0b
Stats:     218 lines in 2 files changed: 44 ins; 152 del; 22 mod

8320677: Printer tests use invalid '@run main/manual=yesno

Reviewed-by: aivanov, dnguyen

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

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

From psadhukhan at openjdk.org  Thu Oct 23 07:03:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 07:03:19 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow
Message-ID: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>

If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder`
it throws NPE which is not mentioned in the spec as the expected outcome.
Fixed the NPE and the spec

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

Commit messages:
 - 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow

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

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

From azvegint at openjdk.org  Thu Oct 23 08:49:02 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 23 Oct 2025 08:49:02 GMT
Subject: RFR: 8369618: Remove outdated reference to JDK 1.1 in the spec of
 BufferedImage.TYPE_INT_ARGB
In-Reply-To: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>
References: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>
Message-ID: <HV6da4jbTRWGq1e9S-LDhXUvg_nige9qElLKX4aYp_g=.0a333f16-20ca-47c7-9793-d7361386aad7@github.com>

On Sun, 12 Oct 2025 01:40:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The reference to "JDK 1.1 and earlier releases" was removed from the BufferedImage.TYPE_INT_ARGB spec.

Please update the `Compatibility Risk` field in the CSR to get it reviewed.

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27758#pullrequestreview-3368855913

From aivanov at openjdk.org  Thu Oct 23 14:01:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Oct 2025 14:01:55 GMT
Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent()
In-Reply-To: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
References: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
Message-ID: <hM_BXfOCkIClqoZI2oBcOaj1ItRLZbjzgY4q1acsLeg=.f99644bd-9fb7-42bb-a511-f9e4b7967283@github.com>

On Wed, 22 Oct 2025 22:02:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> `findComponent(final Container container, final Predicate<Component> predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name.
> 
> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 240:

> 238:     private static JTable findTable(final Container container) {
> 239:         Component result = Util.findComponent(container,
> 240:                                          c -> c instanceof JTable);

Suggestion:

        Component result = Util.findComponent(container,
                                              c -> c instanceof JTable);

I'm sure the second parameter was aligned to the opening parenthesis, it needs to be indented after you added 5 chars to the method call.

test/jdk/javax/swing/JFileChooser/bug4759934.java line 81:

> 79:             }
> 80:             Point cancelLoc = Util.getCenterPoint(cancel);
> 81:             robot.mouseMove(cancelLoc.x, cancelLoc.y);

I am not sure this is the way to go? However, [JDK-4759934](https://bugs.openjdk.org/browse/JDK-4759934) doesn't seem to depend on how the dialog is closed by pressing <kbd>Esc</kbd> or by clicking the **Cancel** button. If it's the case, click the button programmatically by calling `cancel.doClick()`, it's even less error-prone than clicking the button with a robot by sending mouse click.

test/jdk/javax/swing/JFileChooser/bug4759934.java line 133:

> 131:         Component result = Util.findComponent(container,
> 132:                                          c -> c instanceof JButton button
> 133:                                               && "Cancel".equals(button.getText()));

Suggestion:

        Component result = Util.findComponent(container,
                                              c -> c instanceof JButton button
                                                   && "Cancel".equals(button.getText()));

Aligning.

test/jdk/javax/swing/regtesthelpers/Util.java line 1:

> 1: /*

> Existing `Util.findSubComponent()` finds component by class name

To eliminate code duplication, the existing `findSubComponent` should use the new `findComponent` which is more flexible. Just pass `parent.getClass().getName().contains(className)` as the predicate to the new method.

test/jdk/javax/swing/regtesthelpers/Util.java line 153:

> 151:      * Find a component based on predicate.
> 152:      * Always run this method on the EDT thread
> 153:      */

The documentation could then explain the parameters, don't you think?

> Always run this method on the EDT thread

The utility method could ensure this automatically. This *public* method will be a wrapper around a *private* implementation, the implementation will run directly or on EDT using `invokeOnEDT` which already exists in the `Util` class.

test/jdk/javax/swing/regtesthelpers/Util.java line 155:

> 153:      */
> 154:     public static Component findComponent(final Container container,
> 155:                                            final Predicate<Component> predicate) {

Suggestion:

    public static Component findComponent(final Container container,
                                          final Predicate<Component> predicate) {

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

PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3370023732
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2455199133
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2455231458
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2455208680
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2455242012
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2455187844
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2455188360

From psadhukhan at openjdk.org  Thu Oct 23 14:38:22 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 14:38:22 GMT
Subject: RFR: 8026776: Broken API names in API doc [v3]
In-Reply-To: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
Message-ID: <qOOy2oJqvM946PEoGKwiMvNTGca_jBBQXSa3iECotUI=.af5b82df-e91d-414c-affa-629479811c1b@github.com>

> Some of the name typos are corrected

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

  Copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27860/files
  - new: https://git.openjdk.org/jdk/pull/27860/files/8c6dd749..990aeade

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

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

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

From psadhukhan at openjdk.org  Thu Oct 23 14:38:26 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 14:38:26 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <g2Rhy1UQ_Y7IBqU2U2O-F5R1h07IzYj3Z91UHNyH5GA=.7c0820c2-517c-40e6-8f8d-39bcf22c461f@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
 <g2Rhy1UQ_Y7IBqU2U2O-F5R1h07IzYj3Z91UHNyH5GA=.7c0820c2-517c-40e6-8f8d-39bcf22c461f@github.com>
Message-ID: <qAcK1lyA8CHa2zRgmHwMmBt9yKiB5C4H4zkdrmsDUjM=.ca1725a6-01c6-411a-bcb0-4185574c46ed@github.com>

On Mon, 20 Oct 2025 20:43:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo fix in another class
>
> src/java.desktop/share/classes/java/awt/GridBagConstraints.java line 1:
> 
>> 1: /*
> 
> Update the copyright year.

updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2455361518

From aivanov at openjdk.org  Thu Oct 23 14:46:23 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Oct 2025 14:46:23 GMT
Subject: RFR: 8026776: Broken API names in API doc [v3]
In-Reply-To: <qOOy2oJqvM946PEoGKwiMvNTGca_jBBQXSa3iECotUI=.af5b82df-e91d-414c-affa-629479811c1b@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <qOOy2oJqvM946PEoGKwiMvNTGca_jBBQXSa3iECotUI=.af5b82df-e91d-414c-affa-629479811c1b@github.com>
Message-ID: <p1y2ic8MEiLIqM1ZGd0aV6TFhKtYg3VKAAU1-tHmWqM=.9592125b-76df-46ac-a039-0d94707ce2d5@github.com>

On Thu, 23 Oct 2025 14:38:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/ScrollPaneLayout.java line 42:

> 40: /**
> 41:  * The layout manager used by <code>JScrollPane</code>.
> 42:  * {@code ScrollPaneLayout} is

I'd update `<code>JScrollPane</code>` on the line above for consistency.

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

PR Review: https://git.openjdk.org/jdk/pull/27860#pullrequestreview-3370332113
PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2455396215

From psadhukhan at openjdk.org  Thu Oct 23 14:54:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 14:54:00 GMT
Subject: RFR: 8026776: Broken API names in API doc [v4]
In-Reply-To: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
Message-ID: <nTeT7n0qdXEWiPuhaYOCJVGk1f8tXirWB6B1C89eYt8=.737cb594-cb3d-4913-b0c7-6c1c2c91de92@github.com>

> Some of the name typos are corrected

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

  code tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27860/files
  - new: https://git.openjdk.org/jdk/pull/27860/files/990aeade..7a3015ce

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

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

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

From psadhukhan at openjdk.org  Thu Oct 23 14:54:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 14:54:03 GMT
Subject: RFR: 8026776: Broken API names in API doc [v3]
In-Reply-To: <p1y2ic8MEiLIqM1ZGd0aV6TFhKtYg3VKAAU1-tHmWqM=.9592125b-76df-46ac-a039-0d94707ce2d5@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <qOOy2oJqvM946PEoGKwiMvNTGca_jBBQXSa3iECotUI=.af5b82df-e91d-414c-affa-629479811c1b@github.com>
 <p1y2ic8MEiLIqM1ZGd0aV6TFhKtYg3VKAAU1-tHmWqM=.9592125b-76df-46ac-a039-0d94707ce2d5@github.com>
Message-ID: <H7mue9h0OvHePblXlAbPB9PnV1g5J8NxtjBBOywjKcs=.abca86d2-e4c1-46e1-991e-5a48d15e253d@github.com>

On Thu, 23 Oct 2025 14:43:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright update
>
> src/java.desktop/share/classes/javax/swing/ScrollPaneLayout.java line 42:
> 
>> 40: /**
>> 41:  * The layout manager used by <code>JScrollPane</code>.
>> 42:  * {@code ScrollPaneLayout} is
> 
> I'd update `<code>JScrollPane</code>` on the line above for consistency.

updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27860#discussion_r2455425750

From aivanov at openjdk.org  Thu Oct 23 15:28:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Oct 2025 15:28:47 GMT
Subject: RFR: 8026776: Broken API names in API doc [v4]
In-Reply-To: <nTeT7n0qdXEWiPuhaYOCJVGk1f8tXirWB6B1C89eYt8=.737cb594-cb3d-4913-b0c7-6c1c2c91de92@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <nTeT7n0qdXEWiPuhaYOCJVGk1f8tXirWB6B1C89eYt8=.737cb594-cb3d-4913-b0c7-6c1c2c91de92@github.com>
Message-ID: <ygUuWf-Ea6ViwXqUy-bevbo-v0SqjmYq7fJNh7T_SxE=.61867a97-a5bb-4ab1-85e3-36b7b8401f25@github.com>

On Thu, 23 Oct 2025 14:54:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Some of the name typos are corrected
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code tag

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27860#pullrequestreview-3370612838

From abaya at openjdk.org  Thu Oct 23 15:09:03 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 23 Oct 2025 15:09:03 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v2]
In-Reply-To: <bBLvtSEu1s0pAcu4TgPMvuCY8QYKmJqSj6Vw5HM0C78=.b8759e45-cb07-4f07-885c-92d9832303f3@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
 <0tixl2g0Tq-yGHz6_0XsPjZwYoW_YWjuoMcaFOVR_68=.0ef9b8e4-930e-4136-8426-124d1e0a5053@github.com>
 <bBLvtSEu1s0pAcu4TgPMvuCY8QYKmJqSj6Vw5HM0C78=.b8759e45-cb07-4f07-885c-92d9832303f3@github.com>
Message-ID: <cXADm_xtlwaq6LByidOqCWUPTgDmXMTDG-EQ08zAwDY=.335f4c80-5ee2-4c13-a003-9e33f0bc2c59@github.com>

On Wed, 7 Jun 2023 17:22:23 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303904: avoid System.exit(1)
>>   
>>   mrserb recommended against this in a separate PR
>>   
>>   https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212
>
> What is the fate of auto-closed PRs?
> 
> That is: as long as I don't delete this branch in my repo will this be available for future reference if anyone dusts off this ticket in the future?

Hey @mickleness,
the fix is causing a regression.
the test javax/swing/JTable/8236907/LastVisibleRow.java is failing with the fix
I'm investigation that
BR,

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

PR Comment: https://git.openjdk.org/jdk/pull/13196#issuecomment-3437524982

From dnguyen at openjdk.org  Thu Oct 23 15:27:44 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 23 Oct 2025 15:27:44 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v3]
In-Reply-To: <E45EUf2fvsYuGBaZXBSLxTx5sP1EW2HgRMhdY7Qkxrg=.6f1b9886-51f1-48ce-8fc2-6c238a6b59d2@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
 <E45EUf2fvsYuGBaZXBSLxTx5sP1EW2HgRMhdY7Qkxrg=.6f1b9886-51f1-48ce-8fc2-6c238a6b59d2@github.com>
Message-ID: <m7gLSgAJjRyspdgznr8uw7wbDgh5bVIEVQ2qd05y_E4=.91b4c508-23c9-4df6-b708-977a0fad73dd@github.com>

On Wed, 22 Oct 2025 23:27:19 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> Following issues were fixed in this test
>> 
>> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
>> 2. Fixed Wrong test name specified in @run jtreg
>> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
>> 4. Use PassFailJFrame test framework
>> 5. Enhance Instructions
>> 6. Skip the test if no Printer is available
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>    DamonGuy review

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27938#pullrequestreview-3370600876

From serb at openjdk.org  Thu Oct 23 16:13:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 16:13:49 GMT
Subject: RFR: 8369618: Remove outdated reference to JDK 1.1 in the spec of
 BufferedImage.TYPE_INT_ARGB
In-Reply-To: <HV6da4jbTRWGq1e9S-LDhXUvg_nige9qElLKX4aYp_g=.0a333f16-20ca-47c7-9793-d7361386aad7@github.com>
References: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>
 <HV6da4jbTRWGq1e9S-LDhXUvg_nige9qElLKX4aYp_g=.0a333f16-20ca-47c7-9793-d7361386aad7@github.com>
Message-ID: <zFOQeOic0-R4FLOMDMfy5idSFAoUtSUfwDR5_Hm-Ce4=.a6c2bb6b-bebe-42ab-aa20-47d7df678e8b@github.com>

On Thu, 23 Oct 2025 08:46:52 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Please update the `Compatibility Risk` field in the CSR to get it reviewed.

done

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

PR Comment: https://git.openjdk.org/jdk/pull/27758#issuecomment-3437877740

From psadhukhan at openjdk.org  Thu Oct 23 16:28:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Oct 2025 16:28:13 GMT
Subject: Integrated: 8026776: Broken API names in API doc
In-Reply-To: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
Message-ID: <20Tm-M-5K4x_rOmlmDDaRIDkWSi2LtKlhiWzltLkr00=.20794a8a-3e52-4a27-88a2-bc2cc6cf0313@github.com>

On Fri, 17 Oct 2025 03:36:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Some of the name typos are corrected

This pull request has now been integrated.

Changeset: 869112ef
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/869112ef65ec79c8a746a7dc51fa7dbd2384f035
Stats:     9 lines in 4 files changed: 0 ins; 0 del; 9 mod

8026776: Broken API names in API doc

Reviewed-by: aivanov, tr, ayang, prr

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

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

From serb at openjdk.org  Thu Oct 23 16:40:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 16:40:05 GMT
Subject: RFR: 8026776: Broken API names in API doc [v2]
In-Reply-To: <dxlTqPseOz1qqArCcem9C5PRvgYVT8fmpn_MllB8u0Y=.a1056987-fda2-4d87-9180-abca8df8e9aa@github.com>
References: <pGGscPvyriPVnlu5LJgjRDLcPwrZMpMoHuEBkJM5xIM=.e8315e0b-4f3b-4024-807a-4991320bc99c@github.com>
 <SKPe1GPQuQEbyz3s-me29RptgmarXZzBG8Fyz-4dVbQ=.0b95c992-6cd2-46da-ab10-44827a5b4c40@github.com>
 <f8KCixAR2sfNqHbJ9vM7JTxBp926mV_fxUajNun-89I=.f45957af-9d13-49dd-9fc7-528b9037550a@github.com>
 <Mj4cWwMqQXOAgS0tale2Vl5v8fG47iR_BrdNaVdhq3s=.7c5f4fde-5b50-4a22-9b02-a3efdd538981@github.com>
 <tEKlvZL8nngPG0tbW_anpFRtMGdoCxqIQY2uAUg92yE=.b674ed0b-c59a-4f5c-8ef0-bae3625cb122@github.com>
 <dxlTqPseOz1qqArCcem9C5PRvgYVT8fmpn_MllB8u0Y=.a1056987-fda2-4d87-9180-abca8df8e9aa@github.com>
Message-ID: <JppYLJYxdBOm9_zi81MgphlPd0EHEwFAFpIwPlnv4Qg=.2724fbf7-4806-46bf-8ebb-0507130dc1e2@github.com>

On Wed, 22 Oct 2025 05:21:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> As I told, awt/swing were fixed already..This is not client issue..I dont know why those issues are clubbed with this JBS which is in awt area

It was initially part of the report and then assigned to the client. You cannot just ignore that. Now, extract all the issues that are not fixed by this patch and re-report them in a separate JBS.

> > The ticket also mentioned references to non-public APIs from the specification, such as:
> > > 1. http://docs.oracle.com/javase/7/docs/api/index.html?java/awt/Component.html
> > >    For paint events, the new event is coalesced into a complex RepaintArea in the peer. > RepaintArea is deleted in 7.0.
> RepaintArea is not deleted, it is in sun.awt...I think it was mentioned with the belief that it was deleted and still referenced in the javadoc

it is not part of the public API. It is part of implementation similar to peers which should not be mentioned in the spec. And all of that are part of the client, why did you ignore that?

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

PR Comment: https://git.openjdk.org/jdk/pull/27860#issuecomment-3438006811

From kizune at openjdk.org  Thu Oct 23 16:48:43 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 23 Oct 2025 16:48:43 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text.
In-Reply-To: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
Message-ID: <FYXARnn7cbhEPAoYcnu7qhaXzflgxOrmU6HXZRTIcU0=.a23aac46-76e5-40c0-950a-073bdccd4a72@github.com>

On Thu, 23 Oct 2025 03:19:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
> 
> Before fix
> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
> 
> 
> With fix
> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
> 
> No regressions is observed in CI..A manual verification test is provided..

The only problem i have with this fix is that after it the background and the selection are painted differently while before the fix they were painted the same shape.
<img width="59" height="33" alt="noselect" src="https://github.com/user-attachments/assets/478f7ee5-2608-4a6d-b893-2356f9481457" />
<img width="61" height="37" alt="select" src="https://github.com/user-attachments/assets/4b43e453-8d10-4bce-a27e-89e3c9d4923e" />

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

PR Comment: https://git.openjdk.org/jdk/pull/27947#issuecomment-3438052314

From prr at openjdk.org  Thu Oct 23 18:48:23 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Oct 2025 18:48:23 GMT
Subject: RFR: 8370197: Add missing @Override annotations in com.sun.beans
 package
In-Reply-To: <4SAucq5DFcGowDQlLKy2Nop5y5uP80wVQ3h4iCnqjmc=.552d7576-4853-4c31-a164-c4c9a35d3f84@github.com>
References: <4SAucq5DFcGowDQlLKy2Nop5y5uP80wVQ3h4iCnqjmc=.552d7576-4853-4c31-a164-c4c9a35d3f84@github.com>
Message-ID: <smXBTvfm-bFM6bXsfR1xie7N7VkQrubXHPSDPkKmj50=.4f6b57ea-b699-44de-9e81-9e23bb7a050c@github.com>

On Sun, 19 Oct 2025 22:01:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `com.sun.beans` package that override superclass or interface methods.
> Only source annotations are added; there are no behavioral changes.
> 
> Unlike the previous patches, I have skipped adding the `final` to classes, since it should be done carefully when applied to shared code. So I do not want to mix it with other changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27887#pullrequestreview-3371966281

From prr at openjdk.org  Thu Oct 23 19:04:46 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Oct 2025 19:04:46 GMT
Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB
 conversion
In-Reply-To: <bQIpDjCxJPBR6rwkmvU6N9kaUW_8U_DxKgwnfLgNeF0=.ab357a2d-16b0-4684-9c8e-6fe51dda1b10@github.com>
References: <uGPIYHkjIbxRmh5RmDbz2x9-tU9CVRoQ7f9o3-l7jrc=.c40b12ce-297a-4198-b966-041866ad4cbf@github.com>
 <bQIpDjCxJPBR6rwkmvU6N9kaUW_8U_DxKgwnfLgNeF0=.ab357a2d-16b0-4684-9c8e-6fe51dda1b10@github.com>
Message-ID: <ao-4J1StywVvK8yTnGTA_o1lBqbICWcGtTn6WGLL6XY=.7c0df5e8-e67e-4ca0-8837-a7508fd7c831@github.com>

On Thu, 16 Oct 2025 17:37:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> color is initially returned as 4 element array but we over-write with 3 element and so next time through the loop it is used by but is too short.
>> More details in JBS.
>
> src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java line 811:
> 
>> 809:                 for (int x = 0; x < w; x++) {
>> 810:                     pixel = srcRas.getDataElements(x, y, pixel);
>> 811:                     color = srcCM.getNormalizedComponents(pixel, null, 0);
> 
> Since this is executed for each pixel, it will generate garbage equal to the image size. Maybe we can cleanly split the usage of the two vars here? Note that the bug only occurs when the source image does not use an ICC profile, but this change would increase garbage for both ICC and non-ICC profiles.

You mean keep the original returned float[] color separate from the one that's later over-written.
I'd thought about that but I don't think it is worth it.
It can also be over-written at line 835. There's just too much state tracking needed to save
the GC a tiny bit of effort freeing small transient objects.
Also it already is re-initialised for each scanline. See line 807, so it isn't (quite) the same array for the entire image anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2456806807

From azvegint at openjdk.org  Thu Oct 23 19:51:13 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 23 Oct 2025 19:51:13 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does not
 release previously pressed keys
Message-ID: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>

The test does not release previously pressed keys, which may cause failures in subsequent tests.

Testing looks good on all platforms.

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

Commit messages:
 - 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does not release previously pressed keys

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

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

From honkar at openjdk.org  Thu Oct 23 21:02:07 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Oct 2025 21:02:07 GMT
Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent()
 [v2]
In-Reply-To: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
References: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
Message-ID: <vHC0NVy344S7WCYu9jGVqujo3HvgPf5WRj5Bji-QE1M=.895c05f3-672e-4c5e-80a8-073e50cb5e4d@github.com>

> `findComponent(final Container container, final Predicate<Component> predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name.
> 
> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic.

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

  review update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27944/files
  - new: https://git.openjdk.org/jdk/pull/27944/files/f8030256..6bc90058

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

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

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

From honkar at openjdk.org  Thu Oct 23 21:02:10 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Oct 2025 21:02:10 GMT
Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent()
 [v2]
In-Reply-To: <hM_BXfOCkIClqoZI2oBcOaj1ItRLZbjzgY4q1acsLeg=.f99644bd-9fb7-42bb-a511-f9e4b7967283@github.com>
References: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
 <hM_BXfOCkIClqoZI2oBcOaj1ItRLZbjzgY4q1acsLeg=.f99644bd-9fb7-42bb-a511-f9e4b7967283@github.com>
Message-ID: <DjEB-gcRsrrMb_ZLyo3zaVmgFebdAfqHjwV42mY_DEQ=.40fe2151-f79e-40c3-91e6-1fb247802148@github.com>

On Thu, 23 Oct 2025 13:55:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review update
>
> test/jdk/javax/swing/JFileChooser/bug4759934.java line 81:
> 
>> 79:             }
>> 80:             Point cancelLoc = Util.getCenterPoint(cancel);
>> 81:             robot.mouseMove(cancelLoc.x, cancelLoc.y);
> 
> I am not sure this is the way to go? However, [JDK-4759934](https://bugs.openjdk.org/browse/JDK-4759934) doesn't seem to depend on how the dialog is closed by pressing <kbd>Esc</kbd> or by clicking the **Cancel** button. If it's the case, click the button programmatically by calling `cancel.doClick()`, it's even less error-prone than clicking the button with a robot by sending mouse click.

cancel.doClick() seems to be a better option. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2457325240

From honkar at openjdk.org  Thu Oct 23 21:17:58 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Oct 2025 21:17:58 GMT
Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent()
 [v2]
In-Reply-To: <hM_BXfOCkIClqoZI2oBcOaj1ItRLZbjzgY4q1acsLeg=.f99644bd-9fb7-42bb-a511-f9e4b7967283@github.com>
References: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
 <hM_BXfOCkIClqoZI2oBcOaj1ItRLZbjzgY4q1acsLeg=.f99644bd-9fb7-42bb-a511-f9e4b7967283@github.com>
Message-ID: <PB_Y9kb1WeijE-4dPr_uD9jSLLfJUOQdwWrrclE_lSk=.2006a9ee-2adb-449e-a19b-017dede24bc6@github.com>

On Thu, 23 Oct 2025 13:41:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review update
>
> test/jdk/javax/swing/regtesthelpers/Util.java line 153:
> 
>> 151:      * Find a component based on predicate.
>> 152:      * Always run this method on the EDT thread
>> 153:      */
> 
> The documentation could then explain the parameters, don't you think?
> 
>> Always run this method on the EDT thread
> 
> The utility method could ensure this automatically. This *public* method will be a wrapper around a *private* implementation, the implementation will run directly or on EDT using `invokeOnEDT` which already exists in the `Util` class.

There are some tests where EDT calls are interleaved between calls to robot (non-EDT) (e.g bug4759934.java - findCancelButton()) and few other tests (e.g FileSizeCheck.java - findDetailsButton() and findTable() that are within upper level method which is called on EDT). Is it better to leave it as-is for flexibility rather than add a wrapper?

If a wrapper is added we might need to check if it is already on EDT thread or not as below:


if (isEventDispatchThread()) {
   return _findComponent(container, predicate);
} else {
  return Util.invokeOnEDT(() -> _findComponent(container, predicate));
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2457391594

From serb at openjdk.org  Thu Oct 23 21:54:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 23 Oct 2025 21:54:01 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys
In-Reply-To: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
Message-ID: <Vd6csvLvLHR-EPxcIYieo1SsXu2zxEikN3PAbwW3u9Y=.7cfdeaed-8dd1-4018-97ec-36fe81e49b22@github.com>

On Thu, 23 Oct 2025 19:43:14 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test does not release previously pressed keys, which may cause failures in subsequent tests.
> 
> Testing looks good on all platforms.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27959#pullrequestreview-3372934148

From dnguyen at openjdk.org  Thu Oct 23 22:12:35 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 23 Oct 2025 22:12:35 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v10]
In-Reply-To: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
Message-ID: <QN0bI6ih5JaT6Ztd-JjTj3WSPurkP8CUyLV_tW8S7o4=.ef0b8756-6dcd-4f06-8f9b-995d2efaed27@github.com>

> 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:

  Update docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26969/files
  - new: https://git.openjdk.org/jdk/pull/26969/files/9801f136..c20d8263

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

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

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

From dnguyen at openjdk.org  Thu Oct 23 22:12:37 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 23 Oct 2025 22:12:37 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v9]
In-Reply-To: <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@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>
 <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com>
Message-ID: <Y0BXpYS91m6OX6YWbt-5bMWYOSMwFl_BytDk9y8qdVE=.91d296e3-8d9a-4234-a480-246b01bdb372@github.com>

On Tue, 7 Oct 2025 23:24:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Did you compare the behavior of the current implementation with the behavior in [Jemmy](https://github.com/openjdk/jdk/pull/26969#issuecomment-3300887917)

I looked through what I could find with Jemmy in the sanity testsuite and did not find anything regarding mouse movement. Is there something specific you could point me to look at?

AFAIK, the current implementation allows the related tests to pass so there may not be any further changes to the mouse movement needed.

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

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

From dnguyen at openjdk.org  Thu Oct 23 22:12:40 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 23 Oct 2025 22:12:40 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v9]
In-Reply-To: <pkEVHJzNKkDLhkAkgo9lrz-wIzyK5dgPE5EEttCKVoY=.93cb5ced-c97e-4be4-a6b5-51ffc3e43d7b@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <i7VhKRjSOzLQuhWA31Dq03OpFM9i4KCcVVJvMV9nipU=.7dce1618-ca17-4a92-a10b-abf5b5b4c534@github.com>
 <pkEVHJzNKkDLhkAkgo9lrz-wIzyK5dgPE5EEttCKVoY=.93cb5ced-c97e-4be4-a6b5-51ffc3e43d7b@github.com>
Message-ID: <ytAV3Zl_uLxqTJwdrWkadaDQr2MECbvgYZKyd2-hiVg=.912ce4b3-89c9-420b-b0b5-a8ae9ea57745@github.com>

On Tue, 7 Oct 2025 15:06:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 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 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.

Thanks for the suggestions. Updated.

> 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)}.

Went with the second suggestion. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2457567902
PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2457569319

From honkar at openjdk.org  Thu Oct 23 23:36:02 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Oct 2025 23:36:02 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys
In-Reply-To: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
Message-ID: <4UW5-LtOwHCe0ZZp4oPGBkq_IzXZOoiZotmKTHVew5w=.ff9116ee-c5f7-4a6f-a479-a40c494e1654@github.com>

On Thu, 23 Oct 2025 19:43:14 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test does not release previously pressed keys, which may cause failures in subsequent tests.
> 
> Testing looks good on all platforms.

LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27959#pullrequestreview-3373394358

From liach at openjdk.org  Fri Oct 24 00:14:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Oct 2025 00:14:03 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v10]
In-Reply-To: <QN0bI6ih5JaT6Ztd-JjTj3WSPurkP8CUyLV_tW8S7o4=.ef0b8756-6dcd-4f06-8f9b-995d2efaed27@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <QN0bI6ih5JaT6Ztd-JjTj3WSPurkP8CUyLV_tW8S7o4=.ef0b8756-6dcd-4f06-8f9b-995d2efaed27@github.com>
Message-ID: <oG4JZ7Jpyn2Jnf5QUkMDfQaYw22qSQB70g5qRM_siEo=.e8b86dbc-18fb-43da-99ad-94239d9413fc@github.com>

On Thu, 23 Oct 2025 22:12:35 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:
> 
>   Update docs

Looks good javadoc wise. Please have other people more familiar with client area to review actual functionality.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26969#pullrequestreview-3373586821

From honkar at openjdk.org  Fri Oct 24 00:23:01 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 24 Oct 2025 00:23:01 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow
In-Reply-To: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
References: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
Message-ID: <KwSWhy_DOByYSzUz_7NoItymFhd3NqA9sa-xJqNCbZw=.5dbe7a75-a39d-41a4-8cef-0ed2e2f75cc7@github.com>

On Thu, 23 Oct 2025 06:54:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder`
> it throws NPE which is not mentioned in the spec as the expected outcome.
> Fixed the NPE and the spec

src/java.desktop/share/classes/javax/swing/BorderFactory.java line 148:

> 146:      * uses a brighter shade of the shadow color.
> 147:      * If highlight and shadow color are null, then it will
> 148:      * fallback to create beveled border of the specified type.

If the highlight and shadow color are null, are the colors obtained by UIManager defaults?

src/java.desktop/share/classes/javax/swing/BorderFactory.java line 161:

> 159:             return new BevelBorder(type, highlight, shadow);
> 160:         }
> 161:         return new BevelBorder(type);

Do we need to do something similar for other border types such as EtchedBorder ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2458098894
PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2458086432

From honkar at openjdk.org  Fri Oct 24 00:34:10 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 24 Oct 2025 00:34:10 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v3]
In-Reply-To: <E45EUf2fvsYuGBaZXBSLxTx5sP1EW2HgRMhdY7Qkxrg=.6f1b9886-51f1-48ce-8fc2-6c238a6b59d2@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
 <E45EUf2fvsYuGBaZXBSLxTx5sP1EW2HgRMhdY7Qkxrg=.6f1b9886-51f1-48ce-8fc2-6c238a6b59d2@github.com>
Message-ID: <Sj9nOONZjdJs_4GNz5795S5zeb-fVl51_Vx_c7CpZno=.9d1bd0ea-4ec2-4c6b-98e1-105cb21ee27f@github.com>

On Wed, 22 Oct 2025 23:27:19 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> Following issues were fixed in this test
>> 
>> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
>> 2. Fixed Wrong test name specified in @run jtreg
>> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
>> 4. Use PassFailJFrame test framework
>> 5. Enhance Instructions
>> 6. Skip the test if no Printer is available
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>    DamonGuy review

LGTM apart from minor suggestions.

test/jdk/java/awt/print/PrinterJob/SwingUIText.java line 32:

> 30:  * @library /test/lib
> 31:  * @build PassFailJFrame
> 32:  * @build jtreg.SkippedException

`@library and @build` tags can be combined as below

Suggestion:

 * @library /java/awt/regtesthelpers /test/lib
 * @build PassFailJFrame jtreg.SkippedException

test/jdk/java/awt/print/PrinterJob/SwingUIText.java line 120:

> 118:         frame.getContentPane().add(panel);
> 119:         frame.pack();
> 120:         frame.setVisible(true);

frame.setVisible(true) for testUI is not required as PFJ takes care of it

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27938#pullrequestreview-3373676508
PR Review Comment: https://git.openjdk.org/jdk/pull/27938#discussion_r2458133865
PR Review Comment: https://git.openjdk.org/jdk/pull/27938#discussion_r2458138029

From psadhukhan at openjdk.org  Fri Oct 24 01:38:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 01:38:07 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow
In-Reply-To: <KwSWhy_DOByYSzUz_7NoItymFhd3NqA9sa-xJqNCbZw=.5dbe7a75-a39d-41a4-8cef-0ed2e2f75cc7@github.com>
References: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
 <KwSWhy_DOByYSzUz_7NoItymFhd3NqA9sa-xJqNCbZw=.5dbe7a75-a39d-41a4-8cef-0ed2e2f75cc7@github.com>
Message-ID: <r_RADp14fX3dnH27D9U0YVJMNY0pH7B0KmaWObhDyqw=.13c3f3ad-9637-42ad-abe7-cc96a51c9e9f@github.com>

On Fri, 24 Oct 2025 00:19:52 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder`
>> it throws NPE which is not mentioned in the spec as the expected outcome.
>> Fixed the NPE and the spec
>
> src/java.desktop/share/classes/javax/swing/BorderFactory.java line 148:
> 
>> 146:      * uses a brighter shade of the shadow color.
>> 147:      * If highlight and shadow color are null, then it will
>> 148:      * fallback to create beveled border of the specified type.
> 
> If the highlight and shadow color are null, are the colors obtained by UIManager defaults?

No, it will use border of the specified type and there they, as the spec says, will use 

using   brighter shades of the component's current background color
     for highlighting, and darker shading for shadows

> src/java.desktop/share/classes/javax/swing/BorderFactory.java line 161:
> 
>> 159:             return new BevelBorder(type, highlight, shadow);
>> 160:         }
>> 161:         return new BevelBorder(type);
> 
> Do we need to do something similar for other border types such as EtchedBorder ?

No, there it does not use Color.brighter call on null object

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2458301449
PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2458305226

From psadhukhan at openjdk.org  Fri Oct 24 03:59:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 03:59:00 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text.
In-Reply-To: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
Message-ID: <zCJbpjbyFL32sBI1oRY7pV2yzxlS39Awc7y1HXDtMEo=.eb8fb100-3280-4d45-89c6-e497c01d201c@github.com>

On Thu, 23 Oct 2025 03:19:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
> 
> Before fix
> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
> 
> 
> With fix
> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
> 
> No regressions is observed in CI..A manual verification test is provided..

I am not sure I understand. 
I tried selection in the original test. It seems same to me..
WIth fix
<img width="274" height="157" alt="image" src="https://github.com/user-attachments/assets/fea2d1f1-08f0-4d7a-a32b-8de3fac32ee6" />

Before fix
<img width="289" height="129" alt="image" src="https://github.com/user-attachments/assets/1919aa19-7a05-4ba5-a698-57a8452cca8f" />

Part selection
WIth fix
<img width="228" height="94" alt="image" src="https://github.com/user-attachments/assets/310c0400-6908-4212-a7d3-b83b2685119d" />

Before fix
<img width="251" height="95" alt="image" src="https://github.com/user-attachments/assets/397c0874-78c3-455c-a7b0-9ae5bf963bb6" />

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

PR Comment: https://git.openjdk.org/jdk/pull/27947#issuecomment-3440852177

From psadhukhan at openjdk.org  Fri Oct 24 04:32:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 04:32:35 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component.
Message-ID: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>

Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..

Before fix

<img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />

With fix

<img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

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

Commit messages:
 - 8370465: Right to Left Orientation Issues with MenuItem Component.

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

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

From serb at openjdk.org  Fri Oct 24 05:01:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 24 Oct 2025 05:01:03 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel [v3]
In-Reply-To: <cQpjFAI3OTfsLfkiUjnZkWQMjg1A8BpHL0yV4hpuf4c=.d0e89bcf-50a7-4c06-85ec-d164f26cc5fa@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <cQpjFAI3OTfsLfkiUjnZkWQMjg1A8BpHL0yV4hpuf4c=.d0e89bcf-50a7-4c06-85ec-d164f26cc5fa@github.com>
Message-ID: <krbuzskQI2TZ7swhVfPR1UPzZ_AstE5Y2ae5x663p5s=.f39211b4-1e34-4b4a-9e5a-2923bf9fc10e@github.com>

On Thu, 23 Oct 2025 03:34:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in GTKLookAndFeel with NPE
>> 
>> java.lang.NullPointerException
>> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
>> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
>> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
>> 
>> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
>> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
>> 
>> Fix is made to not use these color to create BevelBorder if these colors are not present..
>
> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use motif L&F in test
>  - Use motif L&F in test
>  - Use motif L&F in test

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27839#pullrequestreview-3374574276

From psadhukhan at openjdk.org  Fri Oct 24 05:37:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 05:37:03 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys
In-Reply-To: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
Message-ID: <ox8Ahi-f_Z9lTSGYn9fxV9aoXdW5OC1TKdEomAWQ42o=.a0087841-717e-45a0-b9d7-8396ec48a0a5@github.com>

On Thu, 23 Oct 2025 19:43:14 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test does not release previously pressed keys, which may cause failures in subsequent tests.
> 
> Testing looks good on all platforms.

test/jdk/javax/swing/JSlider/bug4382876.java line 82:

> 80:             });
> 81: 
> 82:             if (upFail) {

`upFail `and `downFail `should be volatile

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27959#discussion_r2458949923

From psadhukhan at openjdk.org  Fri Oct 24 05:49:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 05:49:10 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
Message-ID: <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>

On Mon, 20 Oct 2025 05:58:25 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of eudc.reg

Minor nit..LGTM

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; i++) {

formatting issue..space needs to be given between operator = and <

test/jdk/java/awt/8368882/FallbackFontNPE.java line 25:

> 23:  */
> 24: 
> 25: import java.awt.FontMetrics ;

space before ;

test/jdk/java/awt/8368882/FallbackFontNPE.java line 31:

> 29: public class FallbackFontNPE {
> 30:     public static void main(String[] args) throws Exception {
> 31:         BufferedImage bi = new BufferedImage(1,1,1);

give space in between params

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27551#pullrequestreview-3374649400
PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2458965224
PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2458965624
PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2458966041

From tr at openjdk.org  Fri Oct 24 07:04:10 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 24 Oct 2025 07:04:10 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v6]
In-Reply-To: <rAKx1SGlyBUrAfKqRG3HOcFrPGcc8iFVKA6SbJBUZtQ=.dbeb3365-4367-40e2-8774-aa34557edc70@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <rAKx1SGlyBUrAfKqRG3HOcFrPGcc8iFVKA6SbJBUZtQ=.dbeb3365-4367-40e2-8774-aa34557edc70@github.com>
Message-ID: <B-AUvjV8Gnovo_DRA0YEYOCpO_uzTae0LsiSCVNDCXQ=.e084af5c-dc5a-462c-b333-d5635679cc77@github.com>

On Thu, 23 Oct 2025 02:08:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
> 
>  - Review comment fix
>  - Review comment fix

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26500#pullrequestreview-3374801592

From tr at openjdk.org  Fri Oct 24 07:05:04 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 24 Oct 2025 07:05:04 GMT
Subject: RFR: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel [v3]
In-Reply-To: <cQpjFAI3OTfsLfkiUjnZkWQMjg1A8BpHL0yV4hpuf4c=.d0e89bcf-50a7-4c06-85ec-d164f26cc5fa@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
 <cQpjFAI3OTfsLfkiUjnZkWQMjg1A8BpHL0yV4hpuf4c=.d0e89bcf-50a7-4c06-85ec-d164f26cc5fa@github.com>
Message-ID: <sA0J-L2KzSx9a8hzMBNeW2svFENIFTT1_gHDdGt7ers=.05c776cb-d692-44a6-8786-d4845980e4b1@github.com>

On Thu, 23 Oct 2025 03:34:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails in GTKLookAndFeel with NPE
>> 
>> java.lang.NullPointerException
>> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
>> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
>> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
>> 
>> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
>> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
>> 
>> Fix is made to not use these color to create BevelBorder if these colors are not present..
>
> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use motif L&F in test
>  - Use motif L&F in test
>  - Use motif L&F in test

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27839#pullrequestreview-3374805814

From psadhukhan at openjdk.org  Fri Oct 24 07:29:14 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 07:29:14 GMT
Subject: Integrated: 8068293: [TEST_BUG] Test
 closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java
 fails with GTKLookAndFeel
In-Reply-To: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
References: <MMWFgpk0yXyd0vQOH2_Qwb5588ukPCopAah9vSlzeOY=.1e0f5fb5-3dc6-4867-bf4a-dbc7cff5b463@github.com>
Message-ID: <ssNppkVB6i3nA4hloRrTRAwPoaUJquNcUy27jrTMqIk=.dcc6acd2-1f3c-48bb-895d-13219c60e5a8@github.com>

On Thu, 16 Oct 2025 09:25:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails in GTKLookAndFeel with NPE
> 
> java.lang.NullPointerException
> at javax.swing.border.BevelBorder.<init>(BevelBorder.java:78)
> at javax.swing.BorderFactory.createBevelBorder(BorderFactory.java:155)
> at com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane$Title.<init>(MotifInternalFrameTitlePane.java:325) 
> 
> because `BorderFactory.createBevelBorder` tries to use brighter shade of highlight and shadow color which it tries to obtain from 
> `UIManager.getColor("activeCaptionBorder")` and `UIManager.getColor("inactiveCaptionBorder")` both of which are not defined in GTK L&F as caption border are not used there
> 
> Fix is made to not use these color to create BevelBorder if these colors are not present..

This pull request has now been integrated.

Changeset: 26eed3b6
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26eed3b61e4987a2998f941d7d26790493850612
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8068293: [TEST_BUG] Test closed/com/sun/java/swing/plaf/motif/InternalFrame/4150591/bug4150591.java fails with GTKLookAndFeel

Reviewed-by: serb, tr

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

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

From tr at openjdk.org  Fri Oct 24 07:36:05 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 24 Oct 2025 07:36:05 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v7]
In-Reply-To: <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
Message-ID: <xQ8-TkJT9tC1ayGG5814spdMUvk5EYx0ZuyOm4kp020=.45ca7280-22f9-4d47-828d-ad47e0fbb286@github.com>

On Fri, 26 Sep 2025 07:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test used to timeout even though it seems the test passed..Increased the timeout to a safe value as sometimes it shows elapsed time to timeout > 300secs in macOS in CI and also ensured the wait-time for child process to execute the test is not been waiting endlessly.
>> Also ensured the original display mode is resetted after the test to prevent affecting following tests.
>> 
>> Tried 100 iterations of the fix on all platforms which is ok
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - PL updation
>  - Merge master
>  - Added mac ARM JBS
>  - PL updation
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273617
>  - Remove displayMode reset
>  - EDT fix, timeout reduced
>  - 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12

I tested the fix with dual monitor setup (M1 macos 15.7, laptop connected with external monitor) and the test passes.

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

PR Review: https://git.openjdk.org/jdk/pull/27365#pullrequestreview-3374893410

From psadhukhan at openjdk.org  Fri Oct 24 07:56:33 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 07:56:33 GMT
Subject: RFR: 8370560: Remove non-public API reference from public API javadoc
Message-ID: <3ybm9NpokeckPQYbMRXiPFpbAihUpHhbt2A3_Kfndyc=.151d4f41-960b-423a-aa20-bd3cc2bdaa46@github.com>

Non-public API reference is removed from public API

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

Commit messages:
 - 8370560: Remove non-public API reference from public API

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

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

From azvegint at openjdk.org  Fri Oct 24 09:19:43 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 24 Oct 2025 09:19:43 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys [v2]
In-Reply-To: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
Message-ID: <QdGBEPfRvkaeXY3VR_HYXIvkzZDgT4EmXFUWXAGj7O0=.4e0d7604-1de0-4e52-803b-7deec2c62975@github.com>

> The test does not release previously pressed keys, which may cause failures in subsequent tests.
> 
> Testing looks good on all platforms.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  volatile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27959/files
  - new: https://git.openjdk.org/jdk/pull/27959/files/e766a642..637249bc

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

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

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

From azvegint at openjdk.org  Fri Oct 24 09:19:44 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 24 Oct 2025 09:19:44 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys [v2]
In-Reply-To: <ox8Ahi-f_Z9lTSGYn9fxV9aoXdW5OC1TKdEomAWQ42o=.a0087841-717e-45a0-b9d7-8396ec48a0a5@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
 <ox8Ahi-f_Z9lTSGYn9fxV9aoXdW5OC1TKdEomAWQ42o=.a0087841-717e-45a0-b9d7-8396ec48a0a5@github.com>
Message-ID: <HZgakpslSnVp5UaD_tcT9K6Gv9MEPoM1d2xR2CtM1-w=.d2d82833-bb6a-46a4-94d7-3e33ad9aa118@github.com>

On Fri, 24 Oct 2025 05:33:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   volatile
>
> test/jdk/javax/swing/JSlider/bug4382876.java line 82:
> 
>> 80:             });
>> 81: 
>> 82:             if (upFail) {
> 
> `upFail `and `downFail `should be volatile

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27959#discussion_r2459459431

From psadhukhan at openjdk.org  Fri Oct 24 09:25:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 09:25:06 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
Message-ID: <DS4R5dhVYAKYGcAmridMkuImS6ctg6VcKFXeV6W-riM=.5ff116d1-2cce-4a47-a1d6-eebe693e6a6c@github.com>

On Fri, 24 Oct 2025 05:45:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Get rid of eudc.reg
>
> 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; i++) {
> 
> formatting issue..space needs to be given between operator = and <

Also please update copyright year

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

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

From psadhukhan at openjdk.org  Fri Oct 24 09:25:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 09:25:08 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
Message-ID: <kWQDLLVxZKolEL4k6lv2g-zOuBgOQtGo6TksJ7cvDkI=.4208962d-6c58-407e-9ff1-d2f56018f884@github.com>

On Mon, 20 Oct 2025 05:58:25 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of eudc.reg

test/jdk/java/awt/8368882/FallbackFontNPE.sh line 96:

> 94: 
> 95: exit 0
> 96: 

I am getting this in our CI run although test passed


----------System.out:(12/291)*----------
Setup EUDC.tte font
...Write HKCU\\EUDC\\1252 record
The operation completed successfully.

...Copy custom EUDC.tte file
Setup fallback font
Run java test FallbackFontNPE
Delete fallback font
Restore registry record
The operation completed successfully.

...Delete test EUDC.tte
----------System.err:(3/228)----------
ERROR: The system was unable to find the specified registry key or value.
cp: cannot create regular file 'C:/WINDOWS/Fonts/EUDC.tte': Permission denied
rm: cannot remove 'C:/WINDOWS/Fonts/EUDC.tte': No such file or directory

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

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

From psadhukhan at openjdk.org  Fri Oct 24 09:29:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 09:29:04 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys [v2]
In-Reply-To: <QdGBEPfRvkaeXY3VR_HYXIvkzZDgT4EmXFUWXAGj7O0=.4e0d7604-1de0-4e52-803b-7deec2c62975@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
 <QdGBEPfRvkaeXY3VR_HYXIvkzZDgT4EmXFUWXAGj7O0=.4e0d7604-1de0-4e52-803b-7deec2c62975@github.com>
Message-ID: <KJtau_JSejicv_IMVW-CoQTH9xyekPh8yvxrVxB4PUc=.7394b7d0-7c03-4c99-b995-ccd9e25ff3aa@github.com>

On Fri, 24 Oct 2025 09:19:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test does not release previously pressed keys, which may cause failures in subsequent tests.
>> 
>> Testing looks good on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   volatile

test/jdk/javax/swing/JSlider/bug4382876.java line 64:

> 62:                 slider.setComponentOrientation(ComponentOrientation.LEFT_TO_RIGHT);
> 63:                 slider.putClientProperty("JSlider.isFilled", Boolean.TRUE);
> 64:                 f.add(slider, BorderLayout.CENTER);

also shouldn't we add the component i.e, slider first to frame and then make it visible? here it is made visible and then slider is added..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27959#discussion_r2459494177

From azvegint at openjdk.org  Fri Oct 24 09:32:02 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 24 Oct 2025 09:32:02 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys [v2]
In-Reply-To: <KJtau_JSejicv_IMVW-CoQTH9xyekPh8yvxrVxB4PUc=.7394b7d0-7c03-4c99-b995-ccd9e25ff3aa@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
 <QdGBEPfRvkaeXY3VR_HYXIvkzZDgT4EmXFUWXAGj7O0=.4e0d7604-1de0-4e52-803b-7deec2c62975@github.com>
 <KJtau_JSejicv_IMVW-CoQTH9xyekPh8yvxrVxB4PUc=.7394b7d0-7c03-4c99-b995-ccd9e25ff3aa@github.com>
Message-ID: <GdGOA9m6FDC5iS9htXw10qZicuv7SNlpCgYDl0Ss8c8=.709d390c-8a83-4985-ac06-e2511ce50f34@github.com>

On Fri, 24 Oct 2025 09:26:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   volatile
>
> test/jdk/javax/swing/JSlider/bug4382876.java line 64:
> 
>> 62:                 slider.setComponentOrientation(ComponentOrientation.LEFT_TO_RIGHT);
>> 63:                 slider.putClientProperty("JSlider.isFilled", Boolean.TRUE);
>> 64:                 f.add(slider, BorderLayout.CENTER);
> 
> also shouldn't we add the component i.e, slider first to frame and then make it visible? here it is made visible and then slider is added..

It doesn't matter as we wait long enough, it should work both ways.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27959#discussion_r2459512017

From psadhukhan at openjdk.org  Fri Oct 24 09:41:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 09:41:03 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys [v2]
In-Reply-To: <QdGBEPfRvkaeXY3VR_HYXIvkzZDgT4EmXFUWXAGj7O0=.4e0d7604-1de0-4e52-803b-7deec2c62975@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
 <QdGBEPfRvkaeXY3VR_HYXIvkzZDgT4EmXFUWXAGj7O0=.4e0d7604-1de0-4e52-803b-7deec2c62975@github.com>
Message-ID: <i3Mj_u2Ee8WZS59XLWRTbokYj_Q_yx0a6OoI08okc0Q=.0a95391d-352b-4833-b51a-be72c361718e@github.com>

On Fri, 24 Oct 2025 09:19:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test does not release previously pressed keys, which may cause failures in subsequent tests.
>> 
>> Testing looks good on all platforms.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   volatile

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27959#pullrequestreview-3375406724

From psadhukhan at openjdk.org  Fri Oct 24 09:41:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 09:41:05 GMT
Subject: RFR: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys [v2]
In-Reply-To: <GdGOA9m6FDC5iS9htXw10qZicuv7SNlpCgYDl0Ss8c8=.709d390c-8a83-4985-ac06-e2511ce50f34@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
 <QdGBEPfRvkaeXY3VR_HYXIvkzZDgT4EmXFUWXAGj7O0=.4e0d7604-1de0-4e52-803b-7deec2c62975@github.com>
 <KJtau_JSejicv_IMVW-CoQTH9xyekPh8yvxrVxB4PUc=.7394b7d0-7c03-4c99-b995-ccd9e25ff3aa@github.com>
 <GdGOA9m6FDC5iS9htXw10qZicuv7SNlpCgYDl0Ss8c8=.709d390c-8a83-4985-ac06-e2511ce50f34@github.com>
Message-ID: <Hwd7R9qmZkoFufTyXT3PIErWt_1f2U9Lr5ayZnWKKnQ=.92aae4eb-4df7-4606-b7c1-b3d71cca96bf@github.com>

On Fri, 24 Oct 2025 09:29:46 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> test/jdk/javax/swing/JSlider/bug4382876.java line 64:
>> 
>>> 62:                 slider.setComponentOrientation(ComponentOrientation.LEFT_TO_RIGHT);
>>> 63:                 slider.putClientProperty("JSlider.isFilled", Boolean.TRUE);
>>> 64:                 f.add(slider, BorderLayout.CENTER);
>> 
>> also shouldn't we add the component i.e, slider first to frame and then make it visible? here it is made visible and then slider is added..
>
> It doesn't matter as we wait long enough, it should work both ways.

it doesnt matter till it start failing in some platform in some circumstances :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27959#discussion_r2459542638

From azvegint at openjdk.org  Fri Oct 24 09:49:18 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 24 Oct 2025 09:49:18 GMT
Subject: Integrated: 8370511: test/jdk/javax/swing/JSlider/bug4382876.java does
 not release previously pressed keys
In-Reply-To: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
References: <yZqtsvUur-mEdKcqn41pAU9Z6VpHXaaJTpUyvO_lTMw=.b70f5576-5cf0-4e9b-a698-3b88cc5ede26@github.com>
Message-ID: <CB6fp5Zd66cBNBY1KeyEjogAobtnz4RP73IwZdaQUg4=.5c704460-b3a5-4397-9bf1-3a1af4593927@github.com>

On Thu, 23 Oct 2025 19:43:14 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test does not release previously pressed keys, which may cause failures in subsequent tests.
> 
> Testing looks good on all platforms.

This pull request has now been integrated.

Changeset: 470eedb1
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/470eedb1e9d67058ff8d67a5b0c2250d9f9b3fa5
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8370511: test/jdk/javax/swing/JSlider/bug4382876.java does not release previously pressed keys

Reviewed-by: psadhukhan, serb, honkar

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

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

From psadhukhan at openjdk.org  Fri Oct 24 09:50:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 09:50:55 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
Message-ID: <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>

On Fri, 24 Oct 2025 09:39:28 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> test/jdk/java/awt/8368882/FallbackFontNPE.sh line 96:
>> 
>>> 94: 
>>> 95: exit 0
>>> 96: 
>> 
>> I am getting this in our CI run although test passed
>> 
>> 
>> ----------System.out:(12/291)*----------
>> Setup EUDC.tte font
>> ...Write HKCU\\EUDC\\1252 record
>> The operation completed successfully.
>> 
>> ...Copy custom EUDC.tte file
>> Setup fallback font
>> Run java test FallbackFontNPE
>> Delete fallback font
>> Restore registry record
>> The operation completed successfully.
>> 
>> ...Delete test EUDC.tte
>> ----------System.err:(3/228)----------
>> ERROR: The system was unable to find the specified registry key or value.
>> cp: cannot create regular file 'C:/WINDOWS/Fonts/EUDC.tte': Permission denied
>> rm: cannot remove 'C:/WINDOWS/Fonts/EUDC.tte': No such file or directory
>
> I was afraid of this, and I don't know how to fix it.  Without this file, the test never fails and becomes meaningless.

I guess we can get rid of the test if we cannot test it reliably in CI as we have precedent of fixing this kind of EUDC issue without test as in JDK-8170913 if @prrace is ok with it

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

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

From snazarki at openjdk.org  Fri Oct 24 09:50:45 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 24 Oct 2025 09:50:45 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v6]
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: <qTRPWsRO_2MU3Z3RQpHwFH0cE7s3Ipi8kMhXCUpu72U=.ab560c0f-1b54-480a-9ad6-bc262a63f7e5@github.com>

> 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.

Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:

  Reviewer findings fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27551/files
  - new: https://git.openjdk.org/jdk/pull/27551/files/5fceb547..57a1bcc7

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

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

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

From snazarki at openjdk.org  Fri Oct 24 09:50:46 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 24 Oct 2025 09:50:46 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <VuKhPaBnr8WzUSjKzfLLO2WXUQpTl1JHVF5Kh5t0Y8A=.92b29d19-66d1-49ad-939a-c8055ddda7e0@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <VuKhPaBnr8WzUSjKzfLLO2WXUQpTl1JHVF5Kh5t0Y8A=.92b29d19-66d1-49ad-939a-c8055ddda7e0@github.com>
Message-ID: <1ElY86E72Q040i4Jmkdw9BrZJlwK8jLR0gXikwCldx8=.5c532b56-4006-4b84-83cc-1da3ef7d4f60@github.com>

On Tue, 21 Oct 2025 16:52:35 GMT, Phil Race <prr at openjdk.org> wrote:

> PS as referenced in that bug the updated INTL guide https://docs.oracle.com/en/java/javase/25/intl/font-configuration-files.html#GUID-F8ABF748-F3C3-4781-97B2-66C7E1E10EE9 says
> 
> The JDK places any files that it provides in $JDKHOME/lib. Do not modify that location. Instead, put any updates or custom versions of the configuration files in $JDKHOME/conf/fonts. On platforms that support font configuration files, the runtime will look first in $JDKHOME/conf/fonts.

The JDK still supports fonts in the lib folder. I believe that user apps and fonts have simply migrated between JDK updates over time.

> And I notice that this comment on the method.
> * If so add it as the final fallback component of the composite.
> Should be revised to
> * If so add it as the first fallback component of the composite.

Fixed, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3442182629
PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3442205263

From snazarki at openjdk.org  Fri Oct 24 09:50:49 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 24 Oct 2025 09:50:49 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <CptJHxOMgBqI4DLv3eE8gTA9NnNykSAUpjLN-jux9S8=.eb09ed1a-50c5-4ab0-b439-2eaae62e17a4@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <DS4R5dhVYAKYGcAmridMkuImS6ctg6VcKFXeV6W-riM=.5ff116d1-2cce-4a47-a1d6-eebe693e6a6c@github.com>
 <76OR4EmoqvPTUSWHZMe_3IN1OP2mM9HpQIQJI_jlQRc=.63bbc6db-f52c-4146-8515-28989d1650eb@github.com>
 <CptJHxOMgBqI4DLv3eE8gTA9NnNykSAUpjLN-jux9S8=.eb09ed1a-50c5-4ab0-b439-2eaae62e17a4@github.com>
Message-ID: <ImoIPqDeFmjCnDaEkJMO-0S52966lax54_nmHZrw4QY=.dc078fb7-9228-49d1-bc33-648c703de3cc@github.com>

On Fri, 24 Oct 2025 09:46:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> formatting issue..space needs to be given between operator = and <
>> 
>> I agree with you, but the entire file is formatted this way.  Do you think it would be OK to only fix this line?
>
> ok then no need

> Also please update copyright year

Fixed

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

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

From snazarki at openjdk.org  Fri Oct 24 09:50:47 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 24 Oct 2025 09:50:47 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <DS4R5dhVYAKYGcAmridMkuImS6ctg6VcKFXeV6W-riM=.5ff116d1-2cce-4a47-a1d6-eebe693e6a6c@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <DS4R5dhVYAKYGcAmridMkuImS6ctg6VcKFXeV6W-riM=.5ff116d1-2cce-4a47-a1d6-eebe693e6a6c@github.com>
Message-ID: <76OR4EmoqvPTUSWHZMe_3IN1OP2mM9HpQIQJI_jlQRc=.63bbc6db-f52c-4146-8515-28989d1650eb@github.com>

On Fri, 24 Oct 2025 09:21:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> 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; i++) {
>> 
>> formatting issue..space needs to be given between operator = and <
>
> Also please update copyright year

> formatting issue..space needs to be given between operator = and <

I agree with you, but the entire file is formatted this way.  Do you think it would be OK to only fix this line?

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

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

From snazarki at openjdk.org  Fri Oct 24 09:50:52 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 24 Oct 2025 09:50:52 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
Message-ID: <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>

On Fri, 24 Oct 2025 05:45:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Get rid of eudc.reg
>
> test/jdk/java/awt/8368882/FallbackFontNPE.java line 25:
> 
>> 23:  */
>> 24: 
>> 25: import java.awt.FontMetrics ;
> 
> space before ;

Fixed

> test/jdk/java/awt/8368882/FallbackFontNPE.java line 31:
> 
>> 29: public class FallbackFontNPE {
>> 30:     public static void main(String[] args) throws Exception {
>> 31:         BufferedImage bi = new BufferedImage(1,1,1);
> 
> give space in between params

Fixed

> test/jdk/java/awt/8368882/FallbackFontNPE.sh line 96:
> 
>> 94: 
>> 95: exit 0
>> 96: 
> 
> I am getting this in our CI run although test passed
> 
> 
> ----------System.out:(12/291)*----------
> Setup EUDC.tte font
> ...Write HKCU\\EUDC\\1252 record
> The operation completed successfully.
> 
> ...Copy custom EUDC.tte file
> Setup fallback font
> Run java test FallbackFontNPE
> Delete fallback font
> Restore registry record
> The operation completed successfully.
> 
> ...Delete test EUDC.tte
> ----------System.err:(3/228)----------
> ERROR: The system was unable to find the specified registry key or value.
> cp: cannot create regular file 'C:/WINDOWS/Fonts/EUDC.tte': Permission denied
> rm: cannot remove 'C:/WINDOWS/Fonts/EUDC.tte': No such file or directory

I was afraid of this, and I don't know how to fix it.  Without this file, the test never fails and becomes meaningless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2459579699
PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2459579274
PR Review Comment: https://git.openjdk.org/jdk/pull/27551#discussion_r2459549056

From psadhukhan at openjdk.org  Fri Oct 24 09:50:48 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 24 Oct 2025 09:50:48 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <76OR4EmoqvPTUSWHZMe_3IN1OP2mM9HpQIQJI_jlQRc=.63bbc6db-f52c-4146-8515-28989d1650eb@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <DS4R5dhVYAKYGcAmridMkuImS6ctg6VcKFXeV6W-riM=.5ff116d1-2cce-4a47-a1d6-eebe693e6a6c@github.com>
 <76OR4EmoqvPTUSWHZMe_3IN1OP2mM9HpQIQJI_jlQRc=.63bbc6db-f52c-4146-8515-28989d1650eb@github.com>
Message-ID: <CptJHxOMgBqI4DLv3eE8gTA9NnNykSAUpjLN-jux9S8=.eb09ed1a-50c5-4ab0-b439-2eaae62e17a4@github.com>

On Fri, 24 Oct 2025 09:41:12 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> Also please update copyright year
>
>> formatting issue..space needs to be given between operator = and <
> 
> I agree with you, but the entire file is formatted this way.  Do you think it would be OK to only fix this line?

ok then no need

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

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

From aivanov at openjdk.org  Fri Oct 24 11:30:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 24 Oct 2025 11:30:15 GMT
Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent()
 [v2]
In-Reply-To: <PB_Y9kb1WeijE-4dPr_uD9jSLLfJUOQdwWrrclE_lSk=.2006a9ee-2adb-449e-a19b-017dede24bc6@github.com>
References: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
 <hM_BXfOCkIClqoZI2oBcOaj1ItRLZbjzgY4q1acsLeg=.f99644bd-9fb7-42bb-a511-f9e4b7967283@github.com>
 <PB_Y9kb1WeijE-4dPr_uD9jSLLfJUOQdwWrrclE_lSk=.2006a9ee-2adb-449e-a19b-017dede24bc6@github.com>
Message-ID: <x1yIgMi5bpnUCyjItH8XpVYApmrZigkWRFVd2_y66uc=.3945455e-21b0-49f1-9d22-86844ef73787@github.com>

On Thu, 23 Oct 2025 21:15:02 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> If a wrapper is added we might need to check if it is already on EDT thread or not as below:

This is what I said: *?the implementation will run directly or on EDT.?* So if it's already on EDT, call directly; it it's not, use `invokeOnEDT`.

The utility method can then be used in all the contexts without thinking. (The implementation, if you choose this way, should rather be `findComponentImpl` rather than prefixed with an underscore.)

Likely, one still needs to call `findComponent` on EDT because any other operations on the component need to be on EDT. In this case, `findComponent` could throw an exception if it's called not on EDT.

These things will ensure the method can work correctly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2459914938

From abaya at openjdk.org  Fri Oct 24 13:53:23 2025
From: abaya at openjdk.org (Anass Baya)
Date: Fri, 24 Oct 2025 13:53:23 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v4]
In-Reply-To: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
Message-ID: <e3_Y_N5TKRg6s853qJ84kRSKNZr05e9uKN-_Zt0icmA=.8adae0f3-498d-4c21-80bb-3a1371e31da7@github.com>

> Following issues were fixed in this test
> 
> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
> 2. Fixed Wrong test name specified in @run jtreg
> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 4. Use PassFailJFrame test framework
> 5. Enhance Instructions
> 6. Skip the test if no Printer is available

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  combine tags
  
  Co-authored-by: Harshitha Onkar <harshitha.onkar at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27938/files
  - new: https://git.openjdk.org/jdk/pull/27938/files/255a53df..364ca4a6

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

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

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

From abaya at openjdk.org  Fri Oct 24 13:57:42 2025
From: abaya at openjdk.org (Anass Baya)
Date: Fri, 24 Oct 2025 13:57:42 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v5]
In-Reply-To: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
Message-ID: <XC0XxaRmxz_YmVOIz6cWZxU3o_ACbRgPfbxZ5uMF0Gs=.60b6597a-e426-487c-8b69-95aee3184a76@github.com>

> Following issues were fixed in this test
> 
> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
> 2. Fixed Wrong test name specified in @run jtreg
> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 4. Use PassFailJFrame test framework
> 5. Enhance Instructions
> 6. Skip the test if no Printer is available

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Seting frame visibility is not needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27938/files
  - new: https://git.openjdk.org/jdk/pull/27938/files/364ca4a6..20ed6064

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

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

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

From aivanov at openjdk.org  Fri Oct 24 16:05:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 24 Oct 2025 16:05:07 GMT
Subject: RFR: JDK-8353755 : Add a helper method to Util - findComponent()
 [v2]
In-Reply-To: <vHC0NVy344S7WCYu9jGVqujo3HvgPf5WRj5Bji-QE1M=.895c05f3-672e-4c5e-80a8-073e50cb5e4d@github.com>
References: <cJAV8kRIDBQpvcLNZ7mwDV1mdFuaknyhaZbbofYOGfk=.c249b34a-978e-4cff-9172-592a09f5cdeb@github.com>
 <vHC0NVy344S7WCYu9jGVqujo3HvgPf5WRj5Bji-QE1M=.895c05f3-672e-4c5e-80a8-073e50cb5e4d@github.com>
Message-ID: <9rtLTQpBkQMTf5ZgnT22MIBKtBq3A5M6mi-k9rk3bBk=.aabe8f61-2861-4877-a4d9-f0153f1f7247@github.com>

On Thu, 23 Oct 2025 21:02:07 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> `findComponent(final Container container, final Predicate<Component> predicate)` is a useful utility method and thus added to` javax/swing/regtesthelpers/Util.java` instead of having redundant code in tests. It can be used to find a component by label name.
>> 
>> PS: Existing `Util.findSubComponent()` finds component by class name but `findComponent()` can be used to search for a particular component by label name/title when there are multiple subcomponents of same type by applying a predicate logic.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review update

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 236:

> 234:                                                    && "Details".equals(button.getToolTipText()));
> 235:         return (AbstractButton) result;
> 236:     }

In this case, I would leave the wrapped predicate parameter as is; otherwise, the lines become too long. This is why I chose to use the 8-column indentation for the second parameter rather than aligning it with the opening parenthesis.

test/jdk/javax/swing/JFileChooser/bug4759934.java line 77:

> 75: 
> 76:             JButton cancel = Util.invokeOnEDT(() -> findCancelButton(jfc));
> 77:             cancel.doClick();

`doClick` should also be called on EDT.

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

PR Review: https://git.openjdk.org/jdk/pull/27944#pullrequestreview-3377615091
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2461135990
PR Review Comment: https://git.openjdk.org/jdk/pull/27944#discussion_r2461105056

From honkar at openjdk.org  Fri Oct 24 17:02:32 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 24 Oct 2025 17:02:32 GMT
Subject: RFR: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java [v5]
In-Reply-To: <XC0XxaRmxz_YmVOIz6cWZxU3o_ACbRgPfbxZ5uMF0Gs=.60b6597a-e426-487c-8b69-95aee3184a76@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
 <XC0XxaRmxz_YmVOIz6cWZxU3o_ACbRgPfbxZ5uMF0Gs=.60b6597a-e426-487c-8b69-95aee3184a76@github.com>
Message-ID: <BUjmWUKCDYWnF610T0vfS3NAyMmnI9gkTv-YGOVKm1s=.2d2e63f5-c036-499f-9cf9-1ca21febd015@github.com>

On Fri, 24 Oct 2025 13:57:42 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> Following issues were fixed in this test
>> 
>> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
>> 2. Fixed Wrong test name specified in @run jtreg
>> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
>> 4. Use PassFailJFrame test framework
>> 5. Enhance Instructions
>> 6. Skip the test if no Printer is available
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Seting frame visibility is not needed

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27938#pullrequestreview-3377881965

From abaya at openjdk.org  Fri Oct 24 17:06:51 2025
From: abaya at openjdk.org (Anass Baya)
Date: Fri, 24 Oct 2025 17:06:51 GMT
Subject: Integrated: 8274082 : Wrong test name in jtreg run tag for
 java/awt/print/PrinterJob/SwingUIText.java
In-Reply-To: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
References: <RWZenjz16aTL3pnhlyH6DZDhXV0SXVMKj9RsFCfmRSo=.ef8b7f0d-a298-4854-bd4e-310d817bed6d@github.com>
Message-ID: <Z1OlntiNf87ty578h6NMF976KBfOIcNNzX4r0bs5vrg=.8d36f180-77d3-4ec4-a077-1884aad8f469@github.com>

On Wed, 22 Oct 2025 14:07:50 GMT, Anass Baya <abaya at openjdk.org> wrote:

> Following issues were fixed in this test
> 
> 1. Fixed - Parser error due to yesno in @run main/manual=yesno
> 2. Fixed Wrong test name specified in @run jtreg
> 3. @run main/manual=yesno PrintTextTest . It should be @run main/manual=yesno SwingUIText
> 4. Use PassFailJFrame test framework
> 5. Enhance Instructions
> 6. Skip the test if no Printer is available

This pull request has now been integrated.

Changeset: 13adcd99
Author:    Anass Baya <abaya at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13adcd99db4f14caf90de7f59e341380cfa354b0
Stats:     196 lines in 1 file changed: 36 ins; 140 del; 20 mod

8274082: Wrong test name in jtreg run tag for java/awt/print/PrinterJob/SwingUIText.java

Co-authored-by: Lawrence Andrews <landrews at openjdk.org>
Reviewed-by: honkar, dnguyen

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

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

From azvegint at openjdk.org  Fri Oct 24 17:25:29 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 24 Oct 2025 17:25:29 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF
Message-ID: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>

The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:

* https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
 e.g. setAction vs addActionListener 
<img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
* https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version


This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.

Testing looks good.

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

Commit messages:
 - 8316274: javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu 23.10 with Motif LAF

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

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

From prr at openjdk.org  Fri Oct 24 18:35:27 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 18:35:27 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used. [v2]
In-Reply-To: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
Message-ID: <5j1ZgrPfBbOd_IePXp7QzqCw41Cq1MUh8p9WnRVX8GI=.dcc8d9ca-5683-49be-88c6-bba20825f8a9@github.com>

> macOS printing uses a Quartz surface. It is the SurfaceData for a CPrinterGraphics.
> That Surface is not disconnected from the graphics unless Graphics.dispose() is called.
> If the application uses Graphics.create() then the implementation will not Graphics.dispose() it.
> If it is used after printing is complete and the CGContext is no longer valid a crash will occur.
> We need to invalidate the surface as soon as printing to a page is done.
> Note: this is Graphics.dispose(), and is unrelated to disposal of an object when it becomes unreachable.

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

  8370141

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27905/files
  - new: https://git.openjdk.org/jdk/pull/27905/files/a5af40a2..cba82e10

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

  Stats: 136 lines in 5 files changed: 94 ins; 1 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/27905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27905/head:pull/27905

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

From prr at openjdk.org  Fri Oct 24 18:35:28 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 18:35:28 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used. [v2]
In-Reply-To: <t0uhs0Vi3JNhZcR1fQXL-BIBeB5XDrlj15YuHkOuAHg=.e348c4a6-238a-4efc-9bf1-a56dd30d2b4b@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
 <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>
 <uLFOyknrOKtfnNnF6gGSrl35pg0225eU9Uhe2f5uwBA=.f7adacbb-0368-4367-b004-de5f6da0ca7b@github.com>
 <2u9x88zYKdfGaA78yMwaHWfc8xMO_3miDt-KK1HLSg8=.a6551d99-10ff-4732-b195-a3c714bd9fa4@github.com>
 <t0uhs0Vi3JNhZcR1fQXL-BIBeB5XDrlj15YuHkOuAHg=.e348c4a6-238a-4efc-9bf1-a56dd30d2b4b@github.com>
Message-ID: <Ohwde6DKJ4fdjyBjCJmAAGM_PE_RsudwHy2lKgJSePo=.8cadb10e-9c07-417a-922f-48400716886d@github.com>

On Tue, 21 Oct 2025 21:39:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> delegate.dispose just replaces the reference in the graphics with a NullSurfaceData.
>> There's no synchronization needed.
>
> multi-threaded version of the `PrintJobAfterEndTest` always crashed for me even with a patch:
> 
> 
> import java.awt.Frame;
> import java.awt.Graphics;
> import java.awt.JobAttributes;
> import java.awt.JobAttributes.DialogType;
> import java.awt.PageAttributes;
> import java.awt.PrintJob;
> import java.awt.Toolkit;
> import java.util.concurrent.CountDownLatch;
> 
> public final class MTPrintJobAfterEndTest {
> 
>     public static void main(String[] args) throws InterruptedException {
> 
>         JobAttributes jobAttributes = new JobAttributes();
>         jobAttributes.setDialog(DialogType.NONE);
>         PageAttributes pageAttributes = new PageAttributes();
>         Frame f = new Frame();
>         Toolkit toolkit = f.getToolkit();
> 
>         for (int i = 0; i < 1000; i++) {
>             PrintJob job = toolkit.getPrintJob(f, "Crash Test",jobAttributes,
>                                                pageAttributes);
>             if (job != null) {
>                 Graphics g = job.getGraphics();
>                 CountDownLatch latch = new CountDownLatch(1);
>                 
>                 Thread endThread = new Thread(() -> {
>                     try {
>                         latch.await();
>                         job.end();
>                     } catch (Throwable ignore) {}
>                 });
>                 
>                 Thread drawThread = new Thread(() -> {
>                     try {
>                         latch.await();
>                         g.drawLine(0, 100, 200, 100);
>                     } catch (Throwable ignore) {}
>                 });
>                 
>                 endThread.start();
>                 drawThread.start();
>                 latch.countDown();
>                 
>                 endThread.join();
>                 drawThread.join();
>             }
>         }
>     }
> }

I have updated the fix making the SurfaceData methods synchronized and wrapped the disposed with synchronizing on the same surface.
So now it is not possible to have the state changed whilst executing any of these methods.
This fixes the MT crash. I've updated both the tests to use MT and also added more primitives being drawn.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2461599854

From prr at openjdk.org  Fri Oct 24 18:35:28 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 18:35:28 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used. [v2]
In-Reply-To: <Ohwde6DKJ4fdjyBjCJmAAGM_PE_RsudwHy2lKgJSePo=.8cadb10e-9c07-417a-922f-48400716886d@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
 <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>
 <uLFOyknrOKtfnNnF6gGSrl35pg0225eU9Uhe2f5uwBA=.f7adacbb-0368-4367-b004-de5f6da0ca7b@github.com>
 <2u9x88zYKdfGaA78yMwaHWfc8xMO_3miDt-KK1HLSg8=.a6551d99-10ff-4732-b195-a3c714bd9fa4@github.com>
 <t0uhs0Vi3JNhZcR1fQXL-BIBeB5XDrlj15YuHkOuAHg=.e348c4a6-238a-4efc-9bf1-a56dd30d2b4b@github.com>
 <Ohwde6DKJ4fdjyBjCJmAAGM_PE_RsudwHy2lKgJSePo=.8cadb10e-9c07-417a-922f-48400716886d@github.com>
Message-ID: <g95LYUB6Ucw8Ee7iTGjCPoKYCYJpxQkvXOYTMj3V530=.1b730565-e299-4fce-80ac-d4758c00e152@github.com>

On Fri, 24 Oct 2025 18:30:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> multi-threaded version of the `PrintJobAfterEndTest` always crashed for me even with a patch:
>> 
>> 
>> import java.awt.Frame;
>> import java.awt.Graphics;
>> import java.awt.JobAttributes;
>> import java.awt.JobAttributes.DialogType;
>> import java.awt.PageAttributes;
>> import java.awt.PrintJob;
>> import java.awt.Toolkit;
>> import java.util.concurrent.CountDownLatch;
>> 
>> public final class MTPrintJobAfterEndTest {
>> 
>>     public static void main(String[] args) throws InterruptedException {
>> 
>>         JobAttributes jobAttributes = new JobAttributes();
>>         jobAttributes.setDialog(DialogType.NONE);
>>         PageAttributes pageAttributes = new PageAttributes();
>>         Frame f = new Frame();
>>         Toolkit toolkit = f.getToolkit();
>> 
>>         for (int i = 0; i < 1000; i++) {
>>             PrintJob job = toolkit.getPrintJob(f, "Crash Test",jobAttributes,
>>                                                pageAttributes);
>>             if (job != null) {
>>                 Graphics g = job.getGraphics();
>>                 CountDownLatch latch = new CountDownLatch(1);
>>                 
>>                 Thread endThread = new Thread(() -> {
>>                     try {
>>                         latch.await();
>>                         job.end();
>>                     } catch (Throwable ignore) {}
>>                 });
>>                 
>>                 Thread drawThread = new Thread(() -> {
>>                     try {
>>                         latch.await();
>>                         g.drawLine(0, 100, 200, 100);
>>                     } catch (Throwable ignore) {}
>>                 });
>>                 
>>                 endThread.start();
>>                 drawThread.start();
>>                 latch.countDown();
>>                 
>>                 endThread.join();
>>                 drawThread.join();
>>             }
>>         }
>>     }
>> }
>
> I have updated the fix making the SurfaceData methods synchronized and wrapped the disposed with synchronizing on the same surface.
> So now it is not possible to have the state changed whilst executing any of these methods.
> This fixes the MT crash. I've updated both the tests to use MT and also added more primitives being drawn.

Meanwhile, I tried the MT test on Windows and I got a crash there too.
It took me a while but I think a similar approach is needed there and seems to work.
I'm going to create a separate bug ID for that as it is entirely windows-specific changes and this is (test aside) entirely Mac-specific changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2461609072

From prr at openjdk.org  Fri Oct 24 20:47:23 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 20:47:23 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: <JGbXcnvBa_XA_siJ1R0tVpT8hgPHr9aP131_0k8axVE=.feb76120-3db8-4696-847b-7f929f664e3e@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

I have updated the PR - and the CSR - as a result of the stride==0 discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/27627#issuecomment-3444854492

From prr at openjdk.org  Fri Oct 24 20:47:21 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 20:47:21 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v5]
In-Reply-To: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
Message-ID: <A82Rdrld2CwrvlRcHYDMq1IcrzdmpoTjteMdY47jt9w=.b41577f7-448c-4dd0-85da-7736be75bac7@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.
> 
> 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

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

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

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

  Stats: 88 lines in 2 files changed: 75 ins; 1 del; 12 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 24 20:48:05 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 20:48:05 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF
In-Reply-To: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
Message-ID: <Uhzl617_ePXt59p1OLNh5veXeWvXyLThD2K3TjNn_4g=.bb04c801-7e4c-4278-966e-33fba73f88b1@github.com>

On Fri, 24 Oct 2025 17:07:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
> 
> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>  e.g. setAction vs addActionListener 
> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
> 
> 
> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
> 
> Testing looks good.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27979#pullrequestreview-3378789770

From prr at openjdk.org  Fri Oct 24 20:54:01 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 20:54:01 GMT
Subject: RFR: 8370560: Remove non-public API reference from public API
 javadoc
In-Reply-To: <3ybm9NpokeckPQYbMRXiPFpbAihUpHhbt2A3_Kfndyc=.151d4f41-960b-423a-aa20-bd3cc2bdaa46@github.com>
References: <3ybm9NpokeckPQYbMRXiPFpbAihUpHhbt2A3_Kfndyc=.151d4f41-960b-423a-aa20-bd3cc2bdaa46@github.com>
Message-ID: <K2DyB4piPUVQ0Ev1X4UKn5wmAhzC9gC8BaqGg66GlBY=.f1329662-3955-4d85-a0e9-09de2cd110ec@github.com>

On Fri, 24 Oct 2025 07:46:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Non-public API reference is removed from public API

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27970#pullrequestreview-3378804616

From prr at openjdk.org  Fri Oct 24 21:01:35 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 21:01:35 GMT
Subject: RFR: 4954405: Data buffers created with an offset are unusable
 [v2]
In-Reply-To: <VKT61MUnXijF380GXqIIWlZb_XBEELsMI95TGmgu-C4=.7a803f2a-6f47-44b1-b23e-e91c08a3f027@github.com>
References: <VKT61MUnXijF380GXqIIWlZb_XBEELsMI95TGmgu-C4=.7a803f2a-6f47-44b1-b23e-e91c08a3f027@github.com>
Message-ID: <Nr5OWulOmlpa2PASFOdebgYatGlu00dQXVNdokZBZl0=.0fae82b2-87bf-4666-9b03-a3c656446325@github.com>

> ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements
> The super-class sets it in the constructor which runs very much like this subclass except it omits this.
> The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset
> to adjust dataOffsets values used in all calculations.
> 
> Instead ByteInterleavedRaster  does something a bit different than other classes where it includes it in some instance vars
> that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements.
> 
> It looks to me as if this is what ByteInterleavedRaster should also do instead.
> All existing tests pass, and this resolves the specific complaint in the bug report.

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

  4954405

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27782/files
  - new: https://git.openjdk.org/jdk/pull/27782/files/24603c3f..081e74de

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

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

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

From prr at openjdk.org  Fri Oct 24 21:18:02 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 21:18:02 GMT
Subject: RFR: 6185110: Undefined behaviour of SampleModel for width,
 height < 0
In-Reply-To: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
References: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
Message-ID: <j7P5ExuiTzjblJVCRZizC1CuDWNG1fszutQVU8m5vuY=.a1ad74a9-cf4c-43e4-8d20-49874b4c0a6b@github.com>

On Fri, 10 Oct 2025 22:30:53 GMT, Phil Race <prr at openjdk.org> wrote:

> The only significant change here is to ensure that all SampleModel types throw a specified exception if a client
> calls any of the following methods with a negative width or height.
> getPixels(..)
> setPixels(..)
> getSamples(..)
> setSamples(..)
> 
> The rest is fixing the javadoc to properly describe what happens and some minor cleanup.
> I use {@inheritDoc} to avoid repeating the super-class doc. And no one now has to tediously compare them.
> I could just delete the javadoc but that would cause no javadoc to be generated for an overridden method.
> There were a couple of surprises with {@inheritDoc} and the one I had to deal with is that declared RuntimeExceptions
> are not inherited. You need to explicitly re-add them. This because if it isn't an exception in the method signature (as in  foo() throws BarException), and instead you only have "@throws BarException" it will not be inherited.
> 
> I added a test which verifies the behaviour for illegal arguments.
> 
> CSR is here https://bugs.openjdk.org/browse/JDK-8369623

> > That would not help. In fact it makes it harder.
> 
> I tried building this method without any additional Javadoc, using only @OverRide to highlight that it overrides the parent method. The generated Javadoc for ComponentSampleModel does not include a separate description of getPixel, but instead provides a link to the inherited method in the parent class, which contains all the relevant information. Isn?t this exactly the behavior we want to achieve?

The problem with that, as I wrote somewhere, perhaps not here, is that it looks to the reader of the source as if there is no javadoc for this method. {@inheritDoc} gives you the confidence that someone has thought about javadoc !
That is why it did not seem like an acceptable way to proceed.
But it is an interesting thing that in that case javadoc apparently feels it is OK to include the exceptions which it thinks are inappropriate if you ask to inherit the doc ...

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

PR Comment: https://git.openjdk.org/jdk/pull/27754#issuecomment-3444934443

From serb at openjdk.org  Fri Oct 24 21:25:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 24 Oct 2025 21:25:03 GMT
Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB
 conversion
In-Reply-To: <ao-4J1StywVvK8yTnGTA_o1lBqbICWcGtTn6WGLL6XY=.7c0df5e8-e67e-4ca0-8837-a7508fd7c831@github.com>
References: <uGPIYHkjIbxRmh5RmDbz2x9-tU9CVRoQ7f9o3-l7jrc=.c40b12ce-297a-4198-b966-041866ad4cbf@github.com>
 <bQIpDjCxJPBR6rwkmvU6N9kaUW_8U_DxKgwnfLgNeF0=.ab357a2d-16b0-4684-9c8e-6fe51dda1b10@github.com>
 <ao-4J1StywVvK8yTnGTA_o1lBqbICWcGtTn6WGLL6XY=.7c0df5e8-e67e-4ca0-8837-a7508fd7c831@github.com>
Message-ID: <S3DOPtWt8th5FfQG393Xj9cQBcpuqhXDGskF-exQxk8=.5bbee92d-8886-44b3-8991-00aa4c4e35d7@github.com>

On Thu, 23 Oct 2025 19:02:11 GMT, Phil Race <prr at openjdk.org> wrote:

> It can also be over-written at line 835.

Interesting, is it possible that that line has the same bug?
`color = dstColorSpace.fromCIEXYZ(dstColor);`
Does dstColor always have the same number of components as CIEXYZ? 

Is the logic of using CIEXYZ for mix of non-/ICC source and non-/ICC destination actually correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2462010427

From serb at openjdk.org  Fri Oct 24 21:28:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 24 Oct 2025 21:28:01 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used. [v2]
In-Reply-To: <g95LYUB6Ucw8Ee7iTGjCPoKYCYJpxQkvXOYTMj3V530=.1b730565-e299-4fce-80ac-d4758c00e152@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <oL9EAE1LKX0W1T_Cx-6LhvVBjydIYo5yP17-wo556kg=.4720bbf2-e0a5-41b7-81fa-8a442580e089@github.com>
 <N0lgXNYZXZ7pV98FsYzi4-w4yrLLtqwVExcbG3zinFs=.be2f774c-5859-42ee-be87-c53a6a1802c2@github.com>
 <uLFOyknrOKtfnNnF6gGSrl35pg0225eU9Uhe2f5uwBA=.f7adacbb-0368-4367-b004-de5f6da0ca7b@github.com>
 <2u9x88zYKdfGaA78yMwaHWfc8xMO_3miDt-KK1HLSg8=.a6551d99-10ff-4732-b195-a3c714bd9fa4@github.com>
 <t0uhs0Vi3JNhZcR1fQXL-BIBeB5XDrlj15YuHkOuAHg=.e348c4a6-238a-4efc-9bf1-a56dd30d2b4b@github.com>
 <Ohwde6DKJ4fdjyBjCJmAAGM_PE_RsudwHy2lKgJSePo=.8cadb10e-9c07-417a-922f-48400716886d@github.com>
 <g95LYUB6Ucw8Ee7iTGjCPoKYCYJpxQkvXOYTMj3V530=.1b730565-e299-4fce-80ac-d4758c00e152@github.com>
Message-ID: <DrPYr8bcf3qXNBU3-tlkHuaT1XUsaN7i5lbt51fMYAQ=.76632a6e-d97c-4b6c-ab81-f7ed6f41205e@github.com>

On Fri, 24 Oct 2025 18:32:11 GMT, Phil Race <prr at openjdk.org> wrote:

> Meanwhile, I tried the MT test on Windows and I got a crash there too.

O_o
Bugs just cannot stay away from me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27905#discussion_r2462015256

From prr at openjdk.org  Fri Oct 24 21:50:02 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 21:50:02 GMT
Subject: RFR: 8364583: ColorConvertOp fails for CMYK =?UTF-8?B?4oaS?= RGB
 conversion
In-Reply-To: <S3DOPtWt8th5FfQG393Xj9cQBcpuqhXDGskF-exQxk8=.5bbee92d-8886-44b3-8991-00aa4c4e35d7@github.com>
References: <uGPIYHkjIbxRmh5RmDbz2x9-tU9CVRoQ7f9o3-l7jrc=.c40b12ce-297a-4198-b966-041866ad4cbf@github.com>
 <bQIpDjCxJPBR6rwkmvU6N9kaUW_8U_DxKgwnfLgNeF0=.ab357a2d-16b0-4684-9c8e-6fe51dda1b10@github.com>
 <ao-4J1StywVvK8yTnGTA_o1lBqbICWcGtTn6WGLL6XY=.7c0df5e8-e67e-4ca0-8837-a7508fd7c831@github.com>
 <S3DOPtWt8th5FfQG393Xj9cQBcpuqhXDGskF-exQxk8=.5bbee92d-8886-44b3-8991-00aa4c4e35d7@github.com>
Message-ID: <PSdVKMNdvZR_CckEyd-8Td1CY-fAK-fuvTLkhnJWD_A=.90726f3f-519a-4ee3-949d-47c490c9aff0@github.com>

On Fri, 24 Oct 2025 21:22:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> You mean keep the original returned float[] color separate from the one that's later over-written.
>> I'd thought about that but I don't think it is worth it.
>> It can also be over-written at line 835. There's just too much state tracking needed to save
>> the GC a tiny bit of effort freeing small transient objects.
>> Also it already is re-initialised for each scanline. See line 807, so it isn't (quite) the same array for the entire image anyway.
>
>> It can also be over-written at line 835.
> 
> Interesting, is it possible that that line has the same bug?
> `color = dstColorSpace.fromCIEXYZ(dstColor);`
> Does dstColor always have the same number of components as CIEXYZ? 
> 
> Is the logic of using CIEXYZ for mix of non-/ICC source and non-/ICC destination actually correct?

fromCIEXYZ is defined on ColorSpace, not ICC_ColorSpace.

It requires 3 (or more) components, and then dstColorSpace will return an array of colors in its own colorspace.
The dstColor parameter is always created with at least 3 components based on the dstNumComp
And if there's no bug in dstColorSpace it should return an array of the right length for itself.
So if there's a bug it isn't obvious to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2462083087

From honkar at openjdk.org  Fri Oct 24 22:02:04 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 24 Oct 2025 22:02:04 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF
In-Reply-To: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
Message-ID: <bmJj5T_BkCg1Ovnm-ZexZKwjvUlFPZ-J0mi11yiR1eg=.cc3043ec-f780-47af-a43a-d03655338529@github.com>

On Fri, 24 Oct 2025 17:07:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
> 
> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>  e.g. setAction vs addActionListener 
> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
> 
> 
> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
> 
> Testing looks good.

LGTM apart from minor suggestions (on unchanged lines):

- blockTillDisplayed Ln#177 and Thread.sleep() Ln#184 can be replaced by robot.delay() for a cleaner code
- Frame title "Test" is generic, can be changed to the test name
- toggleButtonActionPerformed, checkboxActionPerformed volatile vars?

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

PR Review: https://git.openjdk.org/jdk/pull/27979#pullrequestreview-3379023451

From prr at openjdk.org  Fri Oct 24 22:10:38 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 22:10:38 GMT
Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end
Message-ID: <w6H8BDyH3Ual_pcy2T_rJoaxk4y-0G_wlrPEShI9cRU=.e7cdbaa8-38a7-4605-ba8c-5a8385e261f2@github.com>

Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use.
The printerDC is released when the job ends. 
It is zero-ed out in the handle in which it is stored
The calls which expect it to be valid now all check for zero and return if it is zero.
The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it.

The tests are the same as in the fix for JDK-8370141 which is also under review.
Which ever is 2nd to be pushed will have to merge in the changes from the first

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

Commit messages:
 - 8370637

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

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

From prr at openjdk.org  Fri Oct 24 22:27:12 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Oct 2025 22:27:12 GMT
Subject: Integrated: 6453640: BandedSampleModel.createCompatibleSampleModel()
 API docs are wrong
In-Reply-To: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
References: <JrXWNBXLhRcI5Inq2c9V3l1n5gQn0iml16BP5cx3dSQ=.483b12aa-f361-43a5-aafb-8780deaceb73@github.com>
Message-ID: <I-i5UlcdjmIMltdlvwG50pszQwanccbZQFx9eQXmeIY=.742f0bc3-7fa6-4570-9a4e-584a1ca10446@github.com>

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

> This corrects some omissions / errors in BandedSampleModel docs and adds a test to verify them.
> 
> CSR here https://bugs.openjdk.org/browse/JDK-8369849

This pull request has now been integrated.

Changeset: a4eaeb47
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a4eaeb47c9c42d8da4e3814c80247f40236a03a2
Stats:     108 lines in 2 files changed: 100 ins; 3 del; 5 mod

6453640: BandedSampleModel.createCompatibleSampleModel() API docs are wrong

Reviewed-by: azvegint, serb

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

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

From kcr at openjdk.org  Fri Oct 24 22:40:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 24 Oct 2025 22:40:13 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <SZPFmkvrKJKYUvjwQ7Yb4OJh92zAGme97AeMZoylG0U=.fc9a4c26-bc9b-49cd-8a5d-e46415ac2953@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
 <CfXG-MLSYOch-83h7yS-Oh3_VqtbtxxaW85NGJWZpJk=.d5624d06-48b8-44d0-887c-f5879794abdb@github.com>
 <SZPFmkvrKJKYUvjwQ7Yb4OJh92zAGme97AeMZoylG0U=.fc9a4c26-bc9b-49cd-8a5d-e46415ac2953@github.com>
Message-ID: <iF9M1itZydZMUoeezYG1vp2qe4EYoVoL27sTQZCHrAU=.a77eee67-e806-4cb3-b1de-d32c3517f9aa@github.com>

On Fri, 17 Oct 2025 22:07:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> There has been some discussion from time-to-time about the possibility of having Skara effectively default to `/reviewers 2` for certain areas of the code (hotspot, client, etc). It would need to be done in such a way that a "Reviewer" can lower it back to 1 (for backouts, critical build failures, problem listing, re-reviews for trivial changes, etc). I might file an RFE for this, but I don't know how likely it will be to get implemented.

Someone had already filed such an RFE for hotspot, [SKARA-2573](https://bugs.openjdk.org/browse/SKARA-2573), so I updated the title and Description to make that more generic.

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3445121667

From azvegint at openjdk.org  Sat Oct 25 02:09:25 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 25 Oct 2025 02:09:25 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v2]
In-Reply-To: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
Message-ID: <OcnGamnJLFMF6wmbZ00lc8Cb7cMhgirt4Q1O8mZ0poE=.6d7052cd-674d-4eb9-bff6-79e0e5c709c0@github.com>

> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
> 
> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>  e.g. setAction vs addActionListener 
> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
> 
> 
> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
> 
> Testing looks good.

Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:

 - title
 - review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27979/files
  - new: https://git.openjdk.org/jdk/pull/27979/files/9d3495c7..a4680193

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

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

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

From azvegint at openjdk.org  Sat Oct 25 02:09:25 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 25 Oct 2025 02:09:25 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v2]
In-Reply-To: <bmJj5T_BkCg1Ovnm-ZexZKwjvUlFPZ-J0mi11yiR1eg=.cc3043ec-f780-47af-a43a-d03655338529@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
 <bmJj5T_BkCg1Ovnm-ZexZKwjvUlFPZ-J0mi11yiR1eg=.cc3043ec-f780-47af-a43a-d03655338529@github.com>
Message-ID: <ljYLg3nKtqiP_IoCVwCP1pVqPokpC54hbwAGhfkaipc=.558923f9-7278-484b-8606-6e2e453e9446@github.com>

On Fri, 24 Oct 2025 21:58:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> LGTM apart from minor suggestions (on unchanged lines) :
> 
>     * blockTillDisplayed Ln#177 and Thread.sleep() Ln#184 can be replaced by robot.delay() for a cleaner code
> 
>     * Frame title "Test" is generic, can be changed to the test name
> 
>     * toggleButtonActionPerformed, checkboxActionPerformed volatile vars?

updated

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

PR Comment: https://git.openjdk.org/jdk/pull/27979#issuecomment-3445478459

From duke at openjdk.org  Sat Oct 25 02:53:01 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:01 GMT
Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver
 [v13]
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <QBwjoRxK6LU0NYy3le6TAPBxXOQ3wd3Cd2AYVzLMq6w=.65496765-65ef-471b-ac18-7cdd8d6c72b9@github.com>

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Update ExchangeImpl.java
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - reduce diff
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - add exception test
 - Create UpgradeOutputStream.java
 - close raw streams
 - ... and 8 more: https://git.openjdk.org/jdk/compare/32697bf6...ae2b1184

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

Changes: https://git.openjdk.org/jdk/pull/27751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=12
  Stats: 25304 lines in 632 files changed: 6529 ins; 14641 del; 4134 mod
  Patch: https://git.openjdk.org/jdk/pull/27751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751

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

From duke at openjdk.org  Sat Oct 25 02:53:02 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:02 GMT
Subject: Withdrawn: 8368695: Support 101 switching protocol in jdk.httpserver
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <xzMm3alltKr_uQFUr-WnPiY0p0n-oXxvx0JY9OcrdHc=.8e9e00b5-731a-41e4-9fe2-68bca97f4413@github.com>

On Fri, 10 Oct 2025 19:45:57 GMT, Josiah Noel <duke at openjdk.org> wrote:

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

This pull request has been closed without being integrated.

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

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

From lbourges at openjdk.org  Sat Oct 25 07:06:15 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 25 Oct 2025 07:06:15 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
Message-ID: <si5_68ei0xfGURxljpd2TKAhUos8XVOo6dM-ULakKAA=.7e80dbdb-be6e-407c-95df-1fbced903487@github.com>

On Sun, 5 Oct 2025 22:16:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - 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

Great, it will help.

Finally what do you think about this patch ? Do you Approve ? even after push.

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3446033228

From kizune at openjdk.org  Sat Oct 25 07:22:00 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 25 Oct 2025 07:22:00 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text.
In-Reply-To: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
Message-ID: <HHxwLdHTIrW8wUjfK670AOKqdQrOkZUUcAGolSzxnuI=.4b4b7e84-ffea-48fb-beb4-15d2cec60e8d@github.com>

On Thu, 23 Oct 2025 03:19:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
> 
> Before fix
> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
> 
> 
> With fix
> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
> 
> No regressions is observed in CI..A manual verification test is provided..

Marked as reviewed by kizune (Reviewer).

Ok, i have experimented with the partial selection and now convinced that with the fix it looks better.

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

PR Review: https://git.openjdk.org/jdk/pull/27947#pullrequestreview-3379797965
PR Comment: https://git.openjdk.org/jdk/pull/27947#issuecomment-3446049893

From serb at openjdk.org  Sun Oct 26 03:28:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 26 Oct 2025 03:28:19 GMT
Subject: RFR: 8370197: Add missing @Override annotations in com.sun.beans
 package [v2]
In-Reply-To: <4SAucq5DFcGowDQlLKy2Nop5y5uP80wVQ3h4iCnqjmc=.552d7576-4853-4c31-a164-c4c9a35d3f84@github.com>
References: <4SAucq5DFcGowDQlLKy2Nop5y5uP80wVQ3h4iCnqjmc=.552d7576-4853-4c31-a164-c4c9a35d3f84@github.com>
Message-ID: <6JAtx8IBISoHmd-dNJ0Ccb6YPUsI6L-K_Yi7vFk8rCc=.2f20e335-79ce-43c7-abd9-3ca27d35f8e7@github.com>

> This patch adds missing `@Override` annotations to methods in the `com.sun.beans` package that override superclass or interface methods.
> Only source annotations are added; there are no behavioral changes.
> 
> Unlike the previous patches, I have skipped adding the `final` to classes, since it should be done carefully when applied to shared code. So I do not want to mix it with other changes.

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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8370197
 - 8370197: Add missing @Override annotations in com.sun.beans package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27887/files
  - new: https://git.openjdk.org/jdk/pull/27887/files/68d5e206..104cbae6

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

  Stats: 17829 lines in 386 files changed: 10904 ins; 4143 del; 2782 mod
  Patch: https://git.openjdk.org/jdk/pull/27887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27887/head:pull/27887

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

From serb at openjdk.org  Sun Oct 26 06:09:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 26 Oct 2025 06:09:09 GMT
Subject: Integrated: 8370197: Add missing @Override annotations in
 com.sun.beans package
In-Reply-To: <4SAucq5DFcGowDQlLKy2Nop5y5uP80wVQ3h4iCnqjmc=.552d7576-4853-4c31-a164-c4c9a35d3f84@github.com>
References: <4SAucq5DFcGowDQlLKy2Nop5y5uP80wVQ3h4iCnqjmc=.552d7576-4853-4c31-a164-c4c9a35d3f84@github.com>
Message-ID: <Gh2YAP6Asx2_TrI15bYY6rE-0WN2j2ixnG64c7fxhg4=.05fe5d87-b7f0-4e5a-bf37-741f983a9885@github.com>

On Sun, 19 Oct 2025 22:01:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `com.sun.beans` package that override superclass or interface methods.
> Only source annotations are added; there are no behavioral changes.
> 
> Unlike the previous patches, I have skipped adding the `final` to classes, since it should be done carefully when applied to shared code. So I do not want to mix it with other changes.

This pull request has now been integrated.

Changeset: e7c7892b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7c7892b9f0fcee37495cce312fdd67dc800f9c9
Stats:     97 lines in 17 files changed: 80 ins; 0 del; 17 mod

8370197: Add missing @Override annotations in com.sun.beans package

Reviewed-by: prr

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

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

From psadhukhan at openjdk.org  Mon Oct 27 05:20:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Oct 2025 05:20:11 GMT
Subject: Integrated: 8370560: Remove non-public API reference from public API
 javadoc
In-Reply-To: <3ybm9NpokeckPQYbMRXiPFpbAihUpHhbt2A3_Kfndyc=.151d4f41-960b-423a-aa20-bd3cc2bdaa46@github.com>
References: <3ybm9NpokeckPQYbMRXiPFpbAihUpHhbt2A3_Kfndyc=.151d4f41-960b-423a-aa20-bd3cc2bdaa46@github.com>
Message-ID: <hC-xE3vq6OOXbZ2lYfd5fDLSibtKi4y5h5uWAAfSvPY=.26f835c3-f484-4fd8-94ed-f8e0a0aa31f7@github.com>

On Fri, 24 Oct 2025 07:46:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Non-public API reference is removed from public API

This pull request has now been integrated.

Changeset: bfc1db7e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfc1db7ed6bf9563c0441b24abe6943607b532e7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8370560: Remove non-public API reference from public API javadoc

Reviewed-by: prr

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

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

From psadhukhan at openjdk.org  Mon Oct 27 09:55:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Oct 2025 09:55:17 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text. [v2]
In-Reply-To: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
Message-ID: <fS-D6EUmQx7Eh4sJP42hkPmGRly3tJmO9Vu6gezpOo8=.72ea0b8d-4c05-4567-846d-e49c151597a3@github.com>

> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
> 
> Before fix
> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
> 
> 
> With fix
> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
> 
> No regressions is observed in CI..A manual verification test is provided..

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

  Automate test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27947/files
  - new: https://git.openjdk.org/jdk/pull/27947/files/611a0f51..ca92f16e

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

  Stats: 66 lines in 1 file changed: 35 ins; 9 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/27947.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27947/head:pull/27947

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

From psadhukhan at openjdk.org  Mon Oct 27 09:55:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Oct 2025 09:55:17 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text.
In-Reply-To: <HHxwLdHTIrW8wUjfK670AOKqdQrOkZUUcAGolSzxnuI=.4b4b7e84-ffea-48fb-beb4-15d2cec60e8d@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
 <HHxwLdHTIrW8wUjfK670AOKqdQrOkZUUcAGolSzxnuI=.4b4b7e84-ffea-48fb-beb4-15d2cec60e8d@github.com>
Message-ID: <Hq95gVnpmPjghnQNPH1biUFR5pRIWvZn9SUjA7RBon4=.69abc902-505b-416e-b05e-0dfae5bc24f0@github.com>

On Sat, 25 Oct 2025 07:19:09 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
>> 
>> Before fix
>> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
>> 
>> 
>> With fix
>> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
>> 
>> No regressions is observed in CI..A manual verification test is provided..
>
> Ok, i have experimented with the partial selection and now convinced that with the fix it looks better.

@azuev-java I have automated the test..Can you please review and reapprove?

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

PR Comment: https://git.openjdk.org/jdk/pull/27947#issuecomment-3450403340

From mbollapragad at openjdk.org  Mon Oct 27 10:16:21 2025
From: mbollapragad at openjdk.org (Maheshkumar Bollapragada)
Date: Mon, 27 Oct 2025 10:16:21 GMT
Subject: RFR: 8370678: Update the Problemlisting for
 java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java
Message-ID: <bh_87LdfAzu6Le7Ve550MFOvvjmaN6zJbzn9die6yjE=.14ad2371-ac09-4e7b-bee0-c6215a1463d9@github.com>

Updating  the java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java problemlisting on windows-x64 with appropriate  bug-id.

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

Commit messages:
 - 8370678: Update the Problemlisting for java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java

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

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

From avu at openjdk.org  Mon Oct 27 11:33:42 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 27 Oct 2025 11:33:42 GMT
Subject: RFR: 4954405: Data buffers created with an offset are unusable
 [v2]
In-Reply-To: <Nr5OWulOmlpa2PASFOdebgYatGlu00dQXVNdokZBZl0=.0fae82b2-87bf-4666-9b03-a3c656446325@github.com>
References: <VKT61MUnXijF380GXqIIWlZb_XBEELsMI95TGmgu-C4=.7a803f2a-6f47-44b1-b23e-e91c08a3f027@github.com>
 <Nr5OWulOmlpa2PASFOdebgYatGlu00dQXVNdokZBZl0=.0fae82b2-87bf-4666-9b03-a3c656446325@github.com>
Message-ID: <7OTVcomR2Dxupq2Pv5eOHPqMllR7rnnGcbpxkm5todw=.d2be2d21-9b53-4f53-9e05-9d00ce73689e@github.com>

On Fri, 24 Oct 2025 21:01:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> ByteInterleavedRaster is not including the DataBuffer offset in returns from getDataElements
>> The super-class sets it in the constructor which runs very much like this subclass except it omits this.
>> The parent class of ByteInterleavedRaster is ByteComponentRaster and it uses the DataBuffer offset
>> to adjust dataOffsets values used in all calculations.
>> 
>> Instead ByteInterleavedRaster  does something a bit different than other classes where it includes it in some instance vars
>> that also have additional offsets that apply for getPixels and getSamples but aren't used in getDataElements.
>> 
>> It looks to me as if this is what ByteInterleavedRaster should also do instead.
>> All existing tests pass, and this resolves the specific complaint in the bug report.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4954405

LGTM

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27782#pullrequestreview-3383023972

From psadhukhan at openjdk.org  Mon Oct 27 12:23:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Oct 2025 12:23:35 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text. [v3]
In-Reply-To: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
Message-ID: <Xhk5MA41Dmy6APxuRr6vxyKGVf0QqthZeBZ_CWtp77U=.6d42408f-3238-4bd2-9d45-74bd66566f22@github.com>

> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
> 
> Before fix
> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
> 
> 
> With fix
> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
> 
> No regressions is observed in CI..A manual verification test is provided..

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

  Use width, height

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27947/files
  - new: https://git.openjdk.org/jdk/pull/27947/files/ca92f16e..4c3ed865

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

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

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

From dgredler at openjdk.org  Mon Oct 27 14:53:50 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 27 Oct 2025 14:53:50 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: <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
 <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
Message-ID: <1qcPxbgBO4HaNB9XuXVZymRfpAafDnnO3CmySzdO3EI=.78016d97-c2be-4651-b0cc-655c351bfddb@github.com>

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

>> `GlyphMetrics` objects returned by `StandardGlyphVector.getGlyphMetrics(int)` contain bounds that are calculated by taking the glyph?s visual bounds and normalizing them by subtracting the glyph?s position.
>> 
>> However, some glyphs (e.g., the glyph for the space character) do not have visual bounds. Their outline is an empty shape. In such a case the bounds in the metrics should not be normalized by the glyph?s position. The code erroneously ignores this special case, thus producing bounds with inconsistent negative x-positions.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split long line

This one needs a second review, when somebody gets a chance. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27580#issuecomment-3451683622

From kizune at openjdk.org  Mon Oct 27 16:39:44 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 27 Oct 2025 16:39:44 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text. [v3]
In-Reply-To: <Xhk5MA41Dmy6APxuRr6vxyKGVf0QqthZeBZ_CWtp77U=.6d42408f-3238-4bd2-9d45-74bd66566f22@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
 <Xhk5MA41Dmy6APxuRr6vxyKGVf0QqthZeBZ_CWtp77U=.6d42408f-3238-4bd2-9d45-74bd66566f22@github.com>
Message-ID: <kG2xyki6qtyRKICVgsxBRsiOTqngQynzQri0I6T0p90=.9e61abbb-040f-4f6c-af48-e56c462b686e@github.com>

On Mon, 27 Oct 2025 12:23:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
>> 
>> Before fix
>> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
>> 
>> 
>> With fix
>> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
>> 
>> No regressions is observed in CI..A manual verification test is provided..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use width, height

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27947#pullrequestreview-3384454334

From honkar at openjdk.org  Mon Oct 27 17:02:43 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 27 Oct 2025 17:02:43 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v2]
In-Reply-To: <OcnGamnJLFMF6wmbZ00lc8Cb7cMhgirt4Q1O8mZ0poE=.6d7052cd-674d-4eb9-bff6-79e0e5c709c0@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
 <OcnGamnJLFMF6wmbZ00lc8Cb7cMhgirt4Q1O8mZ0poE=.6d7052cd-674d-4eb9-bff6-79e0e5c709c0@github.com>
Message-ID: <nRhFW2NZDAAs0Os8h5ha8YG3iMTPV6o1k64db3eAXiY=.618021e3-3153-4e51-b54d-2a1c8229dfac@github.com>

On Sat, 25 Oct 2025 02:09:25 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>>  e.g. setAction vs addActionListener 
>> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
>> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
>> 
>> 
>> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
>> 
>> Testing looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - title
>  - review comments

Changes requested by honkar (Reviewer).

test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java line 166:

> 164:                 if (!textFieldFirst.equals(KeyboardFocusManager.getCurrentKeyboardFocusManager()
> 165:                         .getFocusOwner())) {
> 166:                     robot.delay(100);

Test fails intermittently when run on local macOS (15.7.1). Increasing the delay here to 200-300ms seems to work.

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

PR Review: https://git.openjdk.org/jdk/pull/27979#pullrequestreview-3384557560
PR Review Comment: https://git.openjdk.org/jdk/pull/27979#discussion_r2466418972

From prr at openjdk.org  Mon Oct 27 17:23:42 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Oct 2025 17:23:42 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v6]
In-Reply-To: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
Message-ID: <OORbbo0tbRYLzLdvVOkebYn8nAxS_IYxhdramGYJXpo=.55bf284e-1bd1-482d-87ad-2db474e77317@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.
> 
> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27627/files
  - new: https://git.openjdk.org/jdk/pull/27627/files/62b6edd8..4efc8a4a

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

  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 kcr at openjdk.org  Mon Oct 27 17:49:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 17:49:18 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <si5_68ei0xfGURxljpd2TKAhUos8XVOo6dM-ULakKAA=.7e80dbdb-be6e-407c-95df-1fbced903487@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
 <si5_68ei0xfGURxljpd2TKAhUos8XVOo6dM-ULakKAA=.7e80dbdb-be6e-407c-95df-1fbced903487@github.com>
Message-ID: <tRDmefGBPd9Xoi8NKPsQY8bxeEF9Jwya6d9Bq3JaZvs=.7667e50b-8c2b-4cba-b255-fac4650c2004@github.com>

On Sat, 25 Oct 2025 07:03:21 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> Finally what do you think about this patch ? Do you Approve ? even after push.

I'll take a look. Then if all OK you can create a bug / PR for jfx.

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3452575311

From prappo at openjdk.org  Mon Oct 27 17:51:36 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 Oct 2025 17:51:36 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
Message-ID: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>

Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.

Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

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

Commit messages:
 - Initial commit

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

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

From philip.race at oracle.com  Mon Oct 27 20:10:10 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 27 Oct 2025 13:10:10 -0700
Subject: JDK-8370719: [Linux] Use /etc/os-release values for font
 configuration file names
Message-ID: <84262213-ec1a-4a27-a1b3-011ab27aaab6@oracle.com>

I expect this will be of interest to people who work on distro packaging.

https://bugs.openjdk.org/browse/JDK-8370719

Summary
In the JDk font startup code, stop look for files like 
/etc/redhat-release which doesn't work everywhere and
look only for /etc/os-release and extract ID and ID_VERSION out of it.
If a JDK bundled with a distro includes a custom fontconfig.properties 
file it will need to be named fontconfig.$ID.$ID_VERSION.properties
No more need to "know" what names are baked into JDK source code.

-phil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251027/07f7f0f1/attachment-0001.htm>

From kcr at openjdk.org  Mon Oct 27 20:44:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 20:44:12 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <si5_68ei0xfGURxljpd2TKAhUos8XVOo6dM-ULakKAA=.7e80dbdb-be6e-407c-95df-1fbced903487@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
 <si5_68ei0xfGURxljpd2TKAhUos8XVOo6dM-ULakKAA=.7e80dbdb-be6e-407c-95df-1fbced903487@github.com>
Message-ID: <Y_OHRAWxAYyiUv2ycRIcppstKa554fW6hPA5lP27gCw=.54d1b3d5-95ee-4195-b430-44b863a09d6b@github.com>

On Sat, 25 Oct 2025 07:03:21 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> - 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
>
> Great, it will help.
> 
> Finally what do you think about this patch ? Do you Approve ? even after push.

@bourgesl LGTM

Do you want to create a new bug for the JavaFX version of the fix or would you like me to do it?

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3453225016

From rriggs at openjdk.org  Mon Oct 27 20:45:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Oct 2025 20:45:02 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <Cgql6iI8JuqqSOun9twdTUyH58EbM3FM_jaKF_a8iys=.f58c06ff-2c6b-41fb-bbc7-ae4f92d91401@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3385391439

From lbourges at openjdk.org  Mon Oct 27 20:52:16 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 27 Oct 2025 20:52:16 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
Message-ID: <GFGEQ59FJ0_RA-TRelcATQxZQSKqgukKYcAmOBn5bf0=.5fa40fdc-a989-43e9-9403-f788beab8d89@github.com>

On Sun, 5 Oct 2025 22:16:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - 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

Thanks, please create it for me, I will propose the pull request, the test should be rewritten to adopt javafx api.

?

> @bourgesl LGTM
> 
> Do you want to create a new bug for the JavaFX version of the fix or would you like me to do it?

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3453252075

From kizune at openjdk.org  Mon Oct 27 21:30:22 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 27 Oct 2025 21:30:22 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v6]
In-Reply-To: <y_WqChGVXdsYFm7MusY3Q-hRHhexQoSqIe9od8DN_Ls=.51bb52e0-08e6-4a0f-812a-4cdcb00dee70@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <RsyPHk_GFxqEfx8SaOvWDx2ngw_e6gqzPyZ-wj7Xt_8=.5fc15055-67d9-403d-ab73-16d1fa823196@github.com>
 <j0wiNhwGRFk_037nsA8IvRZmMZJD2aVKQ0dCivN5Y5A=.7c230495-8767-48f9-b9ac-ad6a8a80ced6@github.com>
 <y_WqChGVXdsYFm7MusY3Q-hRHhexQoSqIe9od8DN_Ls=.51bb52e0-08e6-4a0f-812a-4cdcb00dee70@github.com>
Message-ID: <Dwg81LmQ1yqpFoOtlLD48EO6iG3GWHmxGkKBh1Ag9Ps=.8142c3e3-bc82-423b-a006-597e81c013d2@github.com>

On Wed, 17 Sep 2025 06:40:05 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Robot.java line 129:
>> 
>>> 127:     private DirectColorModel screenCapCM = null;
>>> 128: 
>>> 129:     /**
>> 
>> many new lines still longer than 80 chars.
>
> I tried to follow a similar structure to the rest of the class. Some may be longer due to formatting links but I thought the result when generating the html looked fine. Was there any specific issue with the lines that are still longer than 80 chars?

The main reason for the 80 characters limit is to eliminate need to horizontally scroll sources - especially when viewing git history and diffs in terminals. Once it was a part of the Sun (and then Oracle) Java Coding Conventions (JCC 4.1 to be precise). But that document is outdated and no longer maintained so i do not think we need to enforce it - at least when the line length is in reasonable. Personally i would not mind if the string (especially comments with JavaDoc formatting) if shorter than 120 chars. Longer than 120 is still very hard to read even on the modern high resolution displays - the side by side comparison of the diff with such a line would span across more than 240 characters and that is just hard to read which makes it easier to miss an unintended diff beyond the horizontal border.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2467130485

From kcr at openjdk.org  Mon Oct 27 22:17:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Oct 2025 22:17:17 GMT
Subject: RFR: 8341381: Random lines appear in graphic causing by the fix of
 JDK-8297230
In-Reply-To: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
References: <vQMne0Fh-Zwub_Ea8BmdlzvUKpVSJs5FW-t6_V5CA_8=.ba0915bc-c1e4-48f2-a31c-ccc047d7f4cf@github.com>
Message-ID: <FQiT33ViHvZrKc7fuSYlROmsTdImdgk96aZU675xcLM=.01b79c33-d543-4cab-be76-315f4e6c719e@github.com>

On Sun, 5 Oct 2025 22:16:29 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - 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

I filed JDK[JDK-8370729](https://bugs.openjdk.org/browse/JDK-8370729) against JavaFX and assigned it to you.

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

PR Comment: https://git.openjdk.org/jdk/pull/27641#issuecomment-3453527188

From dnguyen at openjdk.org  Mon Oct 27 23:00:03 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 27 Oct 2025 23:00:03 GMT
Subject: RFR: 8017266: Background is painted taller than needed for styled
 text. [v3]
In-Reply-To: <Xhk5MA41Dmy6APxuRr6vxyKGVf0QqthZeBZ_CWtp77U=.6d42408f-3238-4bd2-9d45-74bd66566f22@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
 <Xhk5MA41Dmy6APxuRr6vxyKGVf0QqthZeBZ_CWtp77U=.6d42408f-3238-4bd2-9d45-74bd66566f22@github.com>
Message-ID: <sd7iwAW0so5KCisB8zqQNkJ6h1kCgIETvdP6UjWviGE=.661a44d8-7c49-4032-b216-90ece7dad832@github.com>

On Mon, 27 Oct 2025 12:23:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
>> 
>> Before fix
>> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
>> 
>> 
>> With fix
>> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
>> 
>> No regressions is observed in CI..A manual verification test is provided..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use width, height

Tested locally and on CI and it looks better with the fix. LGTM.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27947#pullrequestreview-3385803088

From psadhukhan at openjdk.org  Tue Oct 28 02:44:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Oct 2025 02:44:13 GMT
Subject: Integrated: 8017266: Background is painted taller than needed for
 styled text.
In-Reply-To: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
References: <mnM2M7wQ6LtDjV12jwGRz8Qmv4_G0LYlAF-4LoBJGDA=.918b6861-f944-4bc0-881c-c584444ceac8@github.com>
Message-ID: <5EqBaa_sZUzPZi7HI-c6RQtU171OIc3bZrQdexIZjBs=.889f3997-4185-488e-b7f7-ccf7731f6dac@github.com>

On Thu, 23 Oct 2025 03:19:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> GlyphView.paint() draws background bounding the passed Shape, while the span reserved for the superscripted text is taller than the height of the glyphs so it is better to use the painter.getHeight() instead of alloc.height to fill the actual glyphs boundary
> 
> Before fix
> <img width="103" height="93" alt="image" src="https://github.com/user-attachments/assets/e673d214-13c7-4a42-8f55-cfd654e5a978" />
> 
> 
> With fix
> <img width="110" height="86" alt="image" src="https://github.com/user-attachments/assets/c13377a6-b4ac-406c-a153-a55c0b9a917b" />
> 
> No regressions is observed in CI..A manual verification test is provided..

This pull request has now been integrated.

Changeset: 460a69bd
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/460a69bd5088f92a2843ee4e89b29a71cab81d52
Stats:     110 lines in 2 files changed: 108 ins; 0 del; 2 mod

8017266: Background is painted taller than needed for styled text.

Reviewed-by: kizune, dnguyen

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

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

From serb at openjdk.org  Tue Oct 28 03:56:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Oct 2025 03:56:03 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used. [v2]
In-Reply-To: <5j1ZgrPfBbOd_IePXp7QzqCw41Cq1MUh8p9WnRVX8GI=.dcc8d9ca-5683-49be-88c6-bba20825f8a9@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <5j1ZgrPfBbOd_IePXp7QzqCw41Cq1MUh8p9WnRVX8GI=.dcc8d9ca-5683-49be-88c6-bba20825f8a9@github.com>
Message-ID: <gtiTF1ywgGdjMHTVp6sbSfX1G61lAxlg0AB5_HvAW8E=.c7b63b7c-0193-4bf7-922d-31c2764de6d6@github.com>

On Fri, 24 Oct 2025 18:35:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS printing uses a Quartz surface. It is the SurfaceData for a CPrinterGraphics.
>> That Surface is not disconnected from the graphics unless Graphics.dispose() is called.
>> If the application uses Graphics.create() then the implementation will not Graphics.dispose() it.
>> If it is used after printing is complete and the CGContext is no longer valid a crash will occur.
>> We need to invalidate the surface as soon as printing to a page is done.
>> Note: this is Graphics.dispose(), and is unrelated to disposal of an object when it becomes unreachable.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370141

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27905#pullrequestreview-3386458015

From alanb at openjdk.org  Tue Oct 28 07:00:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 07:00:03 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <QV5x3ifu4W23G6ObLyr0N87dJl42FMVMrbhQfxCLnlg=.1e26456b-b77d-44b3-94ec-d2956abadd59@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1044:

> 1042:      * already cancelled. This interrupts the threads executing unfinished subtasks. This
> 1043:      * method then waits for all threads to finish. If interrupted while waiting then it
> 1044:      * will continue to wait until the threads finish, before completing with the interrupted

Can you drop the change to this file from the PR as we have reworded this paragraph as part of the updated for JEP 525.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468133283

From tr at openjdk.org  Tue Oct 28 07:32:00 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 28 Oct 2025 07:32:00 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component.
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <fNr0hnWdA4VowZQaV-9hw9YA8S6zqkw_45Hf2odyAHw=.dba629ba-699b-4224-a60c-dae62231b497@github.com>

On Fri, 24 Oct 2025 04:21:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

<img width="400" height="479" alt="image" src="https://github.com/user-attachments/assets/932b9145-3ee7-4fb0-ab96-b6dd0bfa5a88" />

With fix, starting position of text and icon seems to be having an offset compared to metal. Icon is starting a bit right side (2nd line) and text is a bit left side.

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

PR Comment: https://git.openjdk.org/jdk/pull/27968#issuecomment-3454985569

From psadhukhan at openjdk.org  Tue Oct 28 07:40:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Oct 2025 07:40:01 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component.
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <sHSlabKjdq9QIPqHwovBYfVS0n-pGp5N0wmZyLGO37o=.f606d78c-0a7b-4421-8a40-5fb90cd530bc@github.com>

On Fri, 24 Oct 2025 04:21:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

That is expected as for WIndows L&F we are having dedicated offset for icon and checkmark/bullet so that they dont overlap as earlier before [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) the icon and radiobutton bullet/checkmark was overlapping so checkmark was not visible so now each is drawn on its own dedicated position

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

PR Comment: https://git.openjdk.org/jdk/pull/27968#issuecomment-3455004695

From alanb at openjdk.org  Tue Oct 28 07:52:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 07:52:03 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <lkMcK5XyH2Y_la8uIGT2EbV_PfVSagbCirDpFoiPhNI=.218bbaec-0ad7-48be-9909-29668893d58d@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

I skimmed through the replace and it looks okay. There are several places where we should be linking as "interrupted status" will look like a grammatical error with the change. We do that as needed, not this PR.

This is the first update to some of these files in 2025 so you will need to update the copyright header of those files.

src/java.base/share/classes/java/net/DatagramSocket.java line 614:

> 612:      *        interrupting a thread receiving a datagram packet will close the
> 613:      *        underlying channel and cause this method to throw {@link
> 614:      *        java.nio.channels.ClosedByInterruptException} with the interrupted

Can you change this to "the thread's interrupted status set"?

src/java.base/share/classes/java/net/DatagramSocket.java line 620:

> 618:      *        datagram packet. In that case, interrupting the virtual thread will
> 619:      *        cause it to wakeup and close the socket. This method will then throw
> 620:      *        {@code SocketException} with the interrupted status set.

Same thing here, and in ServerSocket and Socket.

test/jdk/java/lang/Thread/virtual/CustomScheduler.java line 207:

> 205: 
> 206:     /**
> 207:      * Test running task with the carrier interrupted status set.

We can change this to "the carrier's interrupted status set".

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387081610
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468253205
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468257078
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468273763

From prappo at openjdk.org  Tue Oct 28 10:06:36 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Oct 2025 10:06:36 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v2]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision:

 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/a10f8b43..89dbafe0

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

  Stats: 67 lines in 47 files changed: 4 ins; 0 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From alanb at openjdk.org  Tue Oct 28 10:10:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 10:10:11 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v2]
In-Reply-To: <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>
Message-ID: <lepfhtvr9Gy7c6wi7Lww4O5l_Fc9HqBdmYsTqOe51Pc=.0e9c56fd-40bc-460c-87f3-aa34f659d111@github.com>

On Tue, 28 Oct 2025 10:06:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
>     + update test/...

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387827557

From prappo at openjdk.org  Tue Oct 28 14:25:06 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Oct 2025 14:25:06 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Pavel Rappo 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 remote-tracking branch 'jdk/master' into 8370568
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/89dbafe0..b3297337

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

  Stats: 3639 lines in 160 files changed: 1891 ins; 1140 del; 608 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From jwaters at openjdk.org  Tue Oct 28 14:41:12 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 28 Oct 2025 14:41:12 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
Message-ID: <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>

On Fri, 24 Oct 2025 12:58:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
> But for other JDK native libs, we do not have support for this feature.
> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

It might be better if we offered this as an option to turn off and on through configure (My personal fork of the JDK has something along the lines of --enable-linktime-opt, can't remember the exact name) rather than making some native code have to use LTO. Additionally I also think this is better done similar to how HotSpot does it instead of adding LTO options as an exported Makefile variable and adding a new parameter to SetupNativeCompilation.

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3443306972

From mbaesken at openjdk.org  Tue Oct 28 14:41:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Oct 2025 14:41:11 GMT
Subject: RFR: 8370438: Offer link time optimization support on library level
Message-ID: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>

We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
But for other JDK native libs, we do not have support for this feature.
LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

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

Commit messages:
 - Suggestions erikj
 - JDK-8370438

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

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

From mbaesken at openjdk.org  Tue Oct 28 14:41:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Oct 2025 14:41:12 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
Message-ID: <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>

On Fri, 24 Oct 2025 13:58:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> It might be better if we offered this as an option to turn off and on through configure (My personal fork of the JDK has something along the lines of --enable-linktime-opt, can't remember the exact name) rather than making some native code have to use LTO. Additionally I also think this is better done similar to how HotSpot does it instead of adding LTO options as an exported Makefile variable and adding a new parameter to SetupNativeCompilation.

The PR gives developers working on some lib , where LTO looks promising, the ability to test the feature on the specific lib.
Enabling it for ALL jdk libs is of course possible too (I did this for experiments locally as well);  the lib idea was discussed here
https://github.com/openjdk/jdk/pull/22464#issuecomment-3423727477

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3455420884

From mbaesken at openjdk.org  Tue Oct 28 14:41:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Oct 2025 14:41:13 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
Message-ID: <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>

On Tue, 28 Oct 2025 09:25:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> the lib idea was discussed here
https://github.com/openjdk/jdk/pull/22464#issuecomment-3423727477

@mrserb is this what you had in mind ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3456694324

From mbaesken at openjdk.org  Tue Oct 28 14:41:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Oct 2025 14:41:13 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
Message-ID: <SGUJy2F4OQzVyECx1844o3pmSC80UMERIEHIgBAtUdw=.107f606e-d618-4e61-b9ca-e7d9ff9d2ce1@github.com>

On Fri, 24 Oct 2025 12:58:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
> But for other JDK native libs, we do not have support for this feature.
> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

I want to remove the changes from` make/modules/java.desktop/lib/ClientLibraries.gmk` because this change is not about changing the settings for single libs, just for offering the LTO support to the lib developers/maintainers.

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3456835343

From erikj at openjdk.org  Tue Oct 28 14:41:16 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Oct 2025 14:41:16 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
Message-ID: <Iilo1U5W_FNLL_ne9LLdZsBkjXB4RCd79K7WQmudGZw=.b2a747d4-a947-4e33-a0ab-af6588c89e65@github.com>

On Fri, 24 Oct 2025 12:58:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
> But for other JDK native libs, we do not have support for this feature.
> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

make/autoconf/flags-ldflags.m4 line 72:

> 70:         -fPIC"
> 71: 
> 72:     LDFLAGS_LTO="-flto=auto -fuse-linker-plugin -fno-strict-aliasing"

I notice that the compiler args for GCC and Clang are different, but the linker args are the same. Just want to make sure that's intentional.

make/common/NativeCompilation.gmk line 101:

> 99: #   SYSROOT_LDFLAGS the linker flags for using the specific sysroot
> 100: #   OPTIMIZATION sets optimization level to NONE, LOW, HIGH, HIGHEST, HIGHEST_JVM, SIZE
> 101: #   LINK_TIME_OPTIMIZATION if set to YES, it enables additionally link time optimization

For boolean options, we use the vales `true`/`false`.

make/common/native/Flags.gmk line 67:

> 65: 
> 66:   ifneq (, $$($1_LINK_TIME_OPTIMIZATION))
> 67:     ifeq ($$($1_LINK_TIME_OPTIMIZATION), YES)

No need to first check if the parameter is not empty.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2460453358
PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2460465286
PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2460467382

From mbaesken at openjdk.org  Tue Oct 28 14:41:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Oct 2025 14:41:18 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <Iilo1U5W_FNLL_ne9LLdZsBkjXB4RCd79K7WQmudGZw=.b2a747d4-a947-4e33-a0ab-af6588c89e65@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <Iilo1U5W_FNLL_ne9LLdZsBkjXB4RCd79K7WQmudGZw=.b2a747d4-a947-4e33-a0ab-af6588c89e65@github.com>
Message-ID: <sx7VmRYgiNiwj_PPDWNDe7L3up4o2jHPDDg6ypgvK2s=.8b708e76-d5f0-48f7-813b-bd2979caaada@github.com>

On Fri, 24 Oct 2025 13:24:43 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
>> But for other JDK native libs, we do not have support for this feature.
>> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.
>
> make/autoconf/flags-ldflags.m4 line 72:
> 
>> 70:         -fPIC"
>> 71: 
>> 72:     LDFLAGS_LTO="-flto=auto -fuse-linker-plugin -fno-strict-aliasing"
> 
> I notice that the compiler args for GCC and Clang are different, but the linker args are the same. Just want to make sure that's intentional.

Yes they are different, this is 'borrowed' from Hotspot flags, see
https://github.com/openjdk/jdk/blob/9625993611bb6acf84d428bea4a65d33b9d66e5f/make/hotspot/lib/JvmFeatures.gmk#L178

where we supported LTO for some time.

> make/common/NativeCompilation.gmk line 101:
> 
>> 99: #   SYSROOT_LDFLAGS the linker flags for using the specific sysroot
>> 100: #   OPTIMIZATION sets optimization level to NONE, LOW, HIGH, HIGHEST, HIGHEST_JVM, SIZE
>> 101: #   LINK_TIME_OPTIMIZATION if set to YES, it enables additionally link time optimization
> 
> For boolean options, we use the vales `true`/`false`.

Thanks for the advice, I'll change it!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2468661804
PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2468644852

From honkar at openjdk.org  Tue Oct 28 22:40:43 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 28 Oct 2025 22:40:43 GMT
Subject: RFR: 8370678: Update the Problemlisting for
 java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java
In-Reply-To: <bh_87LdfAzu6Le7Ve550MFOvvjmaN6zJbzn9die6yjE=.14ad2371-ac09-4e7b-bee0-c6215a1463d9@github.com>
References: <bh_87LdfAzu6Le7Ve550MFOvvjmaN6zJbzn9die6yjE=.14ad2371-ac09-4e7b-bee0-c6215a1463d9@github.com>
Message-ID: <vtQMy20qln6GegG0pPecH4LobGRR6BEShbhRTDfNhlU=.22fbe24d-940c-4d8b-beba-ae686459e7d0@github.com>

On Mon, 27 Oct 2025 10:02:40 GMT, Maheshkumar Bollapragada <mbollapragad at openjdk.org> wrote:

> Updating  the java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java problemlisting on windows-x64 with appropriate  bug-id.

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27996#pullrequestreview-3391084474

From kizune at openjdk.org  Wed Oct 29 00:10:02 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 29 Oct 2025 00:10:02 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component.
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>

On Fri, 24 Oct 2025 04:21:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

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

> 916:                 }
> 917:                 if (icon != null) {
> 918:                     if (!c.getComponentOrientation().equals(ComponentOrientation.RIGHT_TO_LEFT)) {

Why not just if(c.getComponentOrientation().isLeftToRight()) ? Then you will not need the extra import and the documentation for ComponentOrientation clearly says that direct comparison should be avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2471400002

From kizune at openjdk.org  Wed Oct 29 00:19:02 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 29 Oct 2025 00:19:02 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component.
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <EnkEEtfNgdP4VMJ3N4tjM44jRpfrZP6Zt_MJVapv82g=.cb10d8f5-e880-4c29-bc05-bfb45acf5e0a@github.com>

On Fri, 24 Oct 2025 04:21:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 205:

> 203:         if (lh.getCheckIcon() != null && lh.useCheckAndArrow()) {
> 204:             Rectangle rect = lr.getTextRect();
> 205:             if (menuItem.getHorizontalTextPosition() != SwingConstants.LEADING) {

Not sure i understand why we only checking for "LEADING" text position. What if it is specified specifically as "LEFT" or "RIGHT"? What would result look like in the different component orientations with this fix?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2471413125

From rriggs at openjdk.org  Wed Oct 29 01:49:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 01:49:05 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
Message-ID: <v3sPAyJyhuAw4LHK4-chOQbBYB7dYiwWKkEywWCr9XM=.1215b812-d7f6-4217-af78-e753b53dd64d@github.com>

On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo 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 remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test...

Nice cleanup.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3391422490

From duke at openjdk.org  Wed Oct 29 01:57:16 2025
From: duke at openjdk.org (duke)
Date: Wed, 29 Oct 2025 01:57:16 GMT
Subject: Withdrawn: 8361387 : Test bug4655513.java fails intermittently on
 Windows platform.
In-Reply-To: <hfv0hEengRD06RtkUnozVymRc8fPq-bINbh1sq6eUWI=.2c50007d-9239-40ab-85cf-2899fb921268@github.com>
References: <hfv0hEengRD06RtkUnozVymRc8fPq-bINbh1sq6eUWI=.2c50007d-9239-40ab-85cf-2899fb921268@github.com>
Message-ID: <QcjZPcemmciRDL4FTO4JTdjec8CuNr7M2y-XhfBH9Eg=.ea7e6eb8-b53b-47e7-9fda-1d7e6a6667f5@github.com>

On Mon, 18 Aug 2025 16:03:23 GMT, Anass Baya <abaya at openjdk.org> wrote:

> This test was recently automated and is failing intermittently in the CI due to timing issues.
> This enhancement aims to stabilize the test and also adds the missing null pointer check.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Wed Oct 29 03:18:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Oct 2025 03:18:35 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v2]
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <s3fIqah8b0ag0hYWZ15468FZ9zlJyAKIqB3QLZ7bZnE=.8ff94910-e4cc-4812-bc7d-2a82738f87db@github.com>

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:

 - unused import removed
 - formatting
 - Use existing check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27968/files
  - new: https://git.openjdk.org/jdk/pull/27968/files/a664467c..e8446a6e

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

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

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

From psadhukhan at openjdk.org  Wed Oct 29 03:18:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Oct 2025 03:18:38 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v2]
In-Reply-To: <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
Message-ID: <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>

On Wed, 29 Oct 2025 00:07:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - unused import removed
>>  - formatting
>>  - Use existing check
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 918:
> 
>> 916:                 }
>> 917:                 if (icon != null) {
>> 918:                     if (!c.getComponentOrientation().equals(ComponentOrientation.RIGHT_TO_LEFT)) {
> 
> Why not just if(c.getComponentOrientation().isLeftToRight()) ? Then you will not need the extra import and the documentation for ComponentOrientation clearly says that direct comparison should be avoided.

Yes, I have modified to use the existing LTR check already used in the file

> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 205:
> 
>> 203:         if (lh.getCheckIcon() != null && lh.useCheckAndArrow()) {
>> 204:             Rectangle rect = lr.getTextRect();
>> 205:             if (menuItem.getHorizontalTextPosition() != SwingConstants.LEADING) {
> 
> Not sure i understand why we only checking for "LEADING" text position. What if it is specified specifically as "LEFT" or "RIGHT"? What would result look like in the different component orientations with this fix?

LEADING causes the text to appear before icon so need to account for it..Others are working as I can see "Icon at the left..." and "Icon at the right.." which uses LEFT and RIGHT horizontal text positiong

<img width="506" height="159" alt="image" src="https://github.com/user-attachments/assets/d1b84789-223b-4130-9295-a7a4ddc6fa3d" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2471606468
PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2471608490

From jpai at openjdk.org  Wed Oct 29 09:42:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 09:42:22 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
Message-ID: <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>

On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo 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 remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test...

Hello Pavel, these changes look OK to me.

Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392430217

From prappo at openjdk.org  Wed Oct 29 10:25:59 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 10:25:59 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v4]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

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

 - Fix one more occurrence
 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/b3297337..32e4c36a

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

  Stats: 2165 lines in 89 files changed: 1112 ins; 785 del; 268 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From prappo at openjdk.org  Wed Oct 29 10:26:00 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 10:26:00 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
 <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>
Message-ID: <OsOSZtU1oXKFaS2JB5H0w4E8zTaQKAM6felDUtAFfzQ=.a8af697e-0420-40a4-862a-c9582f8dca85@github.com>

On Wed, 29 Oct 2025 09:39:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Pavel, these changes look OK to me.
> 
> Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text.

Moving from "interrupted" to "interrupt" was a slow drift rather than a landslide. I think it's okay to repair it once. _Loom_ is already in and once _structured concurrency_ is in, I don't expect many new occurrences of "interrupt" in the foreseeable future. But you are right, the important bit is the specification, not the code comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/27972#issuecomment-3460767516

From jpai at openjdk.org  Wed Oct 29 10:29:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 10:29:34 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v4]
In-Reply-To: <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>
Message-ID: <scuwz6xRGZcJJf4dzvgO3vy1WipJBC3I3S4tA-0EcuU=.c4b8faf2-5638-4d92-8e3f-2aff06338e1e@github.com>

On Wed, 29 Oct 2025 10:25:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Fix one more occurrence
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
> ...

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392609024

From psadhukhan at openjdk.org  Wed Oct 29 10:47:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Oct 2025 10:47:52 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v3]
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <1IVd2uS3W_AD1OnJ59sPPUJMaFhCvElESGW7P0DgKcE=.d245d46e-bd24-47ff-949c-c3c994445be3@github.com>

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

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

  Correct layouting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27968/files
  - new: https://git.openjdk.org/jdk/pull/27968/files/e8446a6e..201f9aca

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

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

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

From psadhukhan at openjdk.org  Wed Oct 29 10:47:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Oct 2025 10:47:54 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v3]
In-Reply-To: <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
 <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>
Message-ID: <GBb9Q6yNbJxx1M6v23WOdeZ8ssSzapYnmYSUII7Ccb8=.5a46ccc7-034b-4395-91be-043f8c86fec1@github.com>

On Wed, 29 Oct 2025 03:08:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 205:
>> 
>>> 203:         if (lh.getCheckIcon() != null && lh.useCheckAndArrow()) {
>>> 204:             Rectangle rect = lr.getTextRect();
>>> 205:             if (menuItem.getHorizontalTextPosition() != SwingConstants.LEADING) {
>> 
>> Not sure i understand why we only checking for "LEADING" text position. What if it is specified specifically as "LEFT" or "RIGHT"? What would result look like in the different component orientations with this fix?
>
> LEADING causes the text to appear before icon so need to account for it..
> 
> Before fix
> 
> <img width="302" height="188" alt="Image" src="https://github.com/user-attachments/assets/3c7dd877-da0a-44dd-8e1e-8486344b36da" />
> 
> After fix
> 
> <img width="196" height="120" alt="Image" src="https://github.com/user-attachments/assets/14aed6e1-2b42-4d10-9a4d-a4cc4f9f230a" />
> 
> Others are working as I can see "horizontalAlignment = LEFT..." and "horizontalAlignment=RIGHT" which uses LEFT and RIGHT horizontal text positioning
> 
> <img width="536" height="189" alt="Image" src="https://github.com/user-attachments/assets/b6e9b91d-e388-4e01-9243-c08b26bfc370" />

Actually I have modified the PR to rectifying layouting ensuring radiobutton bullet/checkmark are drawn at dedicated position and doesn't interfere with icon position for RTL too..Previous PR iteration was not taking into account of this for RTL so if the menuitem was selected in RTL, it was not shown..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2472508153

From mbollapragad at openjdk.org  Wed Oct 29 11:00:48 2025
From: mbollapragad at openjdk.org (Maheshkumar Bollapragada)
Date: Wed, 29 Oct 2025 11:00:48 GMT
Subject: Integrated: 8370678: Update the Problemlisting for
 java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java
In-Reply-To: <bh_87LdfAzu6Le7Ve550MFOvvjmaN6zJbzn9die6yjE=.14ad2371-ac09-4e7b-bee0-c6215a1463d9@github.com>
References: <bh_87LdfAzu6Le7Ve550MFOvvjmaN6zJbzn9die6yjE=.14ad2371-ac09-4e7b-bee0-c6215a1463d9@github.com>
Message-ID: <scRMZqN0dbkR9r_0gKi7P6ffMyr20R2sv5iirFjtJxU=.db919947-79ac-4faf-b66c-6506b6ad8d5b@github.com>

On Mon, 27 Oct 2025 10:02:40 GMT, Maheshkumar Bollapragada <mbollapragad at openjdk.org> wrote:

> Updating  the java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java problemlisting on windows-x64 with appropriate  bug-id.

This pull request has now been integrated.

Changeset: 78f1c449
Author:    Maheshkumar Bollapragada <mbollapragad at openjdk.org>
Committer: Manukumar V S <mvs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78f1c449da8582c880c7ffcb1e93e054560bcd5a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8370678: Update the Problemlisting for java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java

Reviewed-by: honkar

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

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

From jdv at openjdk.org  Wed Oct 29 12:48:15 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 29 Oct 2025 12:48:15 GMT
Subject: RFR: 8369129: Raster createPackedRaster methods specification
 clean up [v6]
In-Reply-To: <OORbbo0tbRYLzLdvVOkebYn8nAxS_IYxhdramGYJXpo=.55bf284e-1bd1-482d-87ad-2db474e77317@github.com>
References: <Qhus5stXvs9txGkw_lIsKAllo21pYXV9uYnt0yeiJzM=.9bc1da12-9766-436b-826b-95f8c3637126@github.com>
 <OORbbo0tbRYLzLdvVOkebYn8nAxS_IYxhdramGYJXpo=.55bf284e-1bd1-482d-87ad-2db474e77317@github.com>
Message-ID: <0u7sjZMxYDzTkUosKTGqa3YLoCu0gQ_edMEdeeCHL44=.3e0bd0b5-2e70-4448-a5c6-1a5ce602fa56@github.com>

On Mon, 27 Oct 2025 17:23:42 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

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27627#pullrequestreview-3393159161

From mbaesken at openjdk.org  Wed Oct 29 12:53:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Oct 2025 12:53:16 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
Message-ID: <hYaCleaIFX2oeY1NEY5H5SZCG_Ije_O0rCdg2QvajB0=.b5706f56-b379-46ed-9d17-7152da59995f@github.com>

On Fri, 24 Oct 2025 12:58:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
> But for other JDK native libs, we do not have support for this feature.
> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

For libfontmanager the lib sizes decrease quite a lot on most platforms if LTO is enabled in the build of the lib.
libfontmanager.so / dylib / dll size  without/with LTO enabled

38M	 / 17M   aix_ppc64
1.8M / 1.1M  linux_aarch64
2.0M / 1.3M  linux_alpine_x86_64
2.3M / 1.4M  linux_ppc64le
1.8M / 1.2M  linux_x86_64

1.4M / 900K   macos aarch64
1.4M / 952K   macos x86_64

932K / 916K   windows x86_64


(however the freetype lib does not show this decrease in lib size when enabling lto)

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3461353345

From mbaesken at openjdk.org  Wed Oct 29 12:59:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Oct 2025 12:59:07 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v2]
In-Reply-To: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
Message-ID: <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>

> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
> But for other JDK native libs, we do not have support for this feature.
> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Do not enable LTO for some libs in this PR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27976/files
  - new: https://git.openjdk.org/jdk/pull/27976/files/ab71b582..b54cbed6

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

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

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

From azvegint at openjdk.org  Wed Oct 29 13:12:41 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 29 Oct 2025 13:12:41 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v3]
In-Reply-To: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
Message-ID: <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>

> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
> 
> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>  e.g. setAction vs addActionListener 
> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
> 
> 
> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
> 
> Testing looks good.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27979/files
  - new: https://git.openjdk.org/jdk/pull/27979/files/a4680193..5f7b113e

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

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

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

From jdv at openjdk.org  Wed Oct 29 13:31:23 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 29 Oct 2025 13:31:23 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException
In-Reply-To: <N3Nmz5i24w3sym5e-1U_uISBNFG3RPfjq7QtITrc7mM=.0d2f3a96-5636-4262-9379-7ede1f578ac9@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>
 <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@github.com>
 <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com>
 <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com>
 <N3Nmz5i24w3sym5e-1U_uISBNFG3RPfjq7Q
 tITrc7mM=.0d2f3a96-5636-4262-9379-7ede1f578ac9@github.com>
Message-ID: <XnkZwiPmoXerE6aSdAwExYt7vB1BOEuSBiFA0zzfWYs=.10a51f8f-98a2-48a5-a718-67e63f401db2@github.com>

On Tue, 14 Oct 2025 16:17:49 GMT, Phil Race <prr at openjdk.org> wrote:

>>> Do you have a conformant sample implementation that we could consider ?
>> 
>> We already have an implementation of BandedSampleModel and buffers that store color components in separate bands (different arrays). Similarly, we can implement a new subclass of ComponentSampleModel that stores "x lines of the image per bank". 
>> And it should be possible to reuse an existed api of buffers like: https://github.com/openjdk/jdk/blob/4ca4485e9af10a49ca95710c4e26aa3895835d47/src/java.desktop/share/classes/java/awt/image/DataBufferInt.java#L254
>> 
>> Initially these images will the slowest loops, but we can add some new here and there.
>
> BandedSampleModel is not precluded by the current proposed wording, in fact it is explicitly accommodated.
> 
> The spec. for BandedSampleModel has this as its first sentence :
> This class represents image data which is stored in a band interleaved fashion and for which each sample of a pixel occupies one data element of the DataBuffer
> 
> I had actually thought already about the way you suggest with splitting an image so that different parts of it
> are in different data buffers. But that seems nearly impossible. There's too many things in the spec. and
> implementation that would need revisision. I see no value in diluting the wording to allow an impossibility.
> If we ever did that (unlikely) then revising these few words in the spec. would be an insignificant part of it.
> 
> Essentially the proposed spec is saying is "array length imposes a hard limit".
> 
> So I do not see any problem with the spec as proposed.

I see that none of the code path under this API uses BandedSampleModel.

We can continue to create DataBuffer to hold >Integer.MAX_VALUE and use it to create a Raster with BandedSampleModel and then create a BufferedImage out of it.


import java.awt.Transparency;
import java.awt.color.ColorSpace;
import java.awt.image.BandedSampleModel;
import java.awt.image.BufferedImage;
import java.awt.image.ColorModel;
import java.awt.image.ComponentColorModel;
import java.awt.image.DataBuffer;
import java.awt.image.DataBufferByte;
import java.awt.image.Raster;
import java.awt.image.WritableRaster;

public class BandedBufferedImage {
    public static void main (String[] args) {
        int width = 1;
        int height = Integer.MAX_VALUE - 5;
        int numBands = 3; // For RGB
        int dataType = DataBuffer.TYPE_BYTE; // 8-bit per band

        // Create arrays for bank indices and band offsets
        int[] bankIndices = new int[numBands];
        int[] bandOffsets = new int[numBands];
        for (int i = 0; i < numBands; i++) {
            bankIndices[i] = i; // Each band in its own bank
            bandOffsets[i] = 0; // Offset within each bank
        }

        BandedSampleModel sampleModel = new BandedSampleModel(
            dataType, width, height, width, bankIndices, bandOffsets
        );
        DataBuffer dataBuffer = new DataBufferByte(width * height, numBands);
        WritableRaster raster = Raster.createWritableRaster(sampleModel, dataBuffer, null);
        ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB);
        int[] bits = {8, 8, 8}; // 8 bits per color component (R, G, B)
        ColorModel colorModel = new ComponentColorModel(cs, bits, false, false, Transparency.OPAQUE, dataType);
        BufferedImage bufferedImage = new BufferedImage(colorModel, raster, false, null);
    }
}


So there are no restrictions on these values. Even if someone extends ComponentSampleModel and divides data into separate bands they can continue to do so.

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

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

From jdv at openjdk.org  Wed Oct 29 13:34:32 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 29 Oct 2025 13:34:32 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: <T319uex53dcVJ3xkT1DYQms2yJZr5KVM28r2b2QgHzI=.72ea70f7-2126-44b8-a0e8-c5cd78e9aa42@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

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27640#pullrequestreview-3393424477

From snazarki at openjdk.org  Wed Oct 29 14:05:41 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Wed, 29 Oct 2025 14:05:41 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
 <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
Message-ID: <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>

On Fri, 24 Oct 2025 09:45:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I was afraid of this, and I don't know how to fix it.  Without this file, the test never fails and becomes meaningless.
>
> I guess we can get rid of the test if we cannot test it reliably in CI as we have precedent of fixing this kind of EUDC issue without test as in JDK-8170913 if @prrace is ok with it

@prrace Do you agree that the test is unnecessary here? We could leave it in the code with the relevant comment for reference and manual testing.

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

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

From erikj at openjdk.org  Wed Oct 29 14:07:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 29 Oct 2025 14:07:56 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v2]
In-Reply-To: <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
Message-ID: <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>

On Wed, 29 Oct 2025 12:59:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
>> But for other JDK native libs, we do not have support for this feature.
>> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not enable LTO for some libs in this PR

This change on its own doesn't do anything. Do you plan on following up immediately with a set of suggested libs to enable this on? Have you noticed any impact on build performance when enabling this on any JDK libs? I very much doubt any component owner is going to test and apply this on their own. Without that, this is a dead feature and I wouldn't want it to go in.

I wonder if it would be a good idea to add a global on/off switch (configure arg) for this whole thing, I'm really not sure. It kind of depends on what the impact is. If the impact is unknown, then a global on/off switch, default off, would let every distributor evaluate this on their own. That would of course also require that at least some libs have this enabled.

make/common/NativeCompilation.gmk line 101:

> 99: #   SYSROOT_LDFLAGS the linker flags for using the specific sysroot
> 100: #   OPTIMIZATION sets optimization level to NONE, LOW, HIGH, HIGHEST, HIGHEST_JVM, SIZE
> 101: #   LINK_TIME_OPTIMIZATION if set to true, it enables additionally link time optimization

Suggestion:

#   LINK_TIME_OPTIMIZATION if set to true, enables link time optimization

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

PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3393619643
PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2473244871

From mbaesken at openjdk.org  Wed Oct 29 14:35:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Oct 2025 14:35:49 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v2]
In-Reply-To: <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
 <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
 <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com>
Message-ID: <rYzlbrvNX9MjncrPmAiCWNaVqIgC_bw6Fnew9iXSMRs=.9e29cf9a-67c7-41dd-8352-148620e3dc88@github.com>

On Wed, 29 Oct 2025 14:30:43 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> This change on its own doesn't do anything. Do you plan on following up immediately with a set of suggested libs to enable this on? Have you noticed any impact on build performance when enabling this on any JDK libs? I very much doubt any component owner is going to test and apply this on their own. Without that, this is a dead feature and I wouldn't want it to go in.
> 
> I wonder if it would be a good idea to add a global on/off switch (configure arg) for this whole thing, I'm really not sure. It kind of depends on what the impact is. If the impact is unknown, then a global on/off switch, default off, would let every distributor evaluate this on their own. That would of course also require that at least some libs have this enabled.


There was some interest on the lib-level solution here  https://github.com/openjdk/jdk/pull/22464#issuecomment-3423727477  . 'Provide an option for library owners to opt-in, which can be enabled per-library, per-platform and per-compiler after appropriate testing for performance, functionality, and footprint.'

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3461892551

From mbaesken at openjdk.org  Wed Oct 29 14:35:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Oct 2025 14:35:50 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v2]
In-Reply-To: <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
 <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
Message-ID: <RUFiZGY4WbPRod5rgpFY0RdWeennR8IDfsULhWuLplA=.27cccf75-ce0e-4151-8a1c-580cedd8aeec@github.com>

On Wed, 29 Oct 2025 13:57:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not enable LTO for some libs in this PR
>
> make/common/NativeCompilation.gmk line 101:
> 
>> 99: #   SYSROOT_LDFLAGS the linker flags for using the specific sysroot
>> 100: #   OPTIMIZATION sets optimization level to NONE, LOW, HIGH, HIGHEST, HIGHEST_JVM, SIZE
>> 101: #   LINK_TIME_OPTIMIZATION if set to true, it enables additionally link time optimization
> 
> Suggestion:
> 
> #   LINK_TIME_OPTIMIZATION if set to true, enables link time optimization

I adjusted the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2473462679

From mbaesken at openjdk.org  Wed Oct 29 14:35:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Oct 2025 14:35:46 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v3]
In-Reply-To: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
Message-ID: <z2m4zM6bsfP7WdLKYPlKJBabL-DVKQEDfTJ_g08yL3Q=.0e757cf1-208d-4363-be1d-3ea544240ba2@github.com>

> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
> But for other JDK native libs, we do not have support for this feature.
> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27976/files
  - new: https://git.openjdk.org/jdk/pull/27976/files/b54cbed6..de4dbf2b

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

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

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

From jwaters at openjdk.org  Wed Oct 29 14:35:48 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 29 Oct 2025 14:35:48 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v2]
In-Reply-To: <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
 <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
Message-ID: <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com>

On Wed, 29 Oct 2025 14:05:18 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This change on its own doesn't do anything. Do you plan on following up immediately with a set of suggested libs to enable this on? Have you noticed any impact on build performance when enabling this on any JDK libs? I very much doubt any component owner is going to test and apply this on their own. Without that, this is a dead feature and I wouldn't want it to go in.
> 
> I wonder if it would be a good idea to add a global on/off switch (configure arg) for this whole thing, I'm really not sure. It kind of depends on what the impact is. If the impact is unknown, then a global on/off switch, default off, would let every distributor evaluate this on their own. That would of course also require that at least some libs have this enabled.

I was suggesting a configure switch too, in my fork I have a UTIL_ARG_ENABLE for the configure option and then in LibCommon.gmk and LauncherCommon.gmk I implemented the options as such:

https://github.com/TheShermanTanker/jdk/blob/e3d33aee0270d2ce674367f787bdea77a7ad0c58/make/common/modules/LibCommon.gmk#L33

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3461884343

From mbaesken at openjdk.org  Wed Oct 29 14:41:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Oct 2025 14:41:25 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v2]
In-Reply-To: <rYzlbrvNX9MjncrPmAiCWNaVqIgC_bw6Fnew9iXSMRs=.9e29cf9a-67c7-41dd-8352-148620e3dc88@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
 <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
 <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com>
 <rYzlbrvNX9MjncrPmAiCWNaVqIgC_bw6Fnew9iXSMRs=.9e29cf9a-67c7-41dd-8352-148620e3dc88@github.com>
Message-ID: <yrvJ4Bgom2xFi0lB-WDKPOuh9APj832iHpAG2VdWz6Y=.5c18ad4d-ccba-437d-8dd2-b58096cd59f1@github.com>

On Wed, 29 Oct 2025 14:32:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Have you noticed any impact on build performance when enabling this on any JDK libs? 

I see not much difference when looking at the build times of our builds with and without this patch. But this is the time for a whole scratch-build , not for single libs.  For single libs with LTO enabled the time might be slower, but because this is just a small part of the (parallel) whole JDK build, it does not matter so much.

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3461931477

From prappo at openjdk.org  Wed Oct 29 15:39:31 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 15:39:31 GMT
Subject: Integrated: 8370568: Refer to Thread.interrupted as
 "interrupted status" consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <uaeBmYjuxH0uTzmwhhHFy2gkyLBM1oT6f9PTUvlLIYs=.1da2ac77-fc8c-473a-8f67-dee5c28b327c@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

This pull request has now been integrated.

Changeset: 28f2591b
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28f2591bad49c4d1590325c3d315d850ab6bcc7d
Stats:     260 lines in 77 files changed: 4 ins; 0 del; 256 mod

8370568: Refer to Thread.interrupted as "interrupted status" consistently

Reviewed-by: jpai, rriggs, alanb

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

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

From dnguyen at openjdk.org  Wed Oct 29 16:09:24 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 29 Oct 2025 16:09:24 GMT
Subject: RFR: 8273617: UninitializedDisplayModeChangeTest.java times out on
 macOS 12 [v7]
In-Reply-To: <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
References: <dplWXfTXqtbGRz6-5ksucxPPvedsHufN7OtVxlgdEKU=.9fd2718d-c7c4-41eb-a332-5697af2003cf@github.com>
 <f56vvSyVJnvVsxPZ4cRdQhmr6HoLAOoyOg_6z6sF4L0=.b6578681-cfac-43c0-9edb-d76e3b130259@github.com>
Message-ID: <3MHUKfKx8j3cNuEE_PDSZbppMxSE015jKCVZmnzCIW4=.5c4381ca-ee77-492f-8ad8-adbdae0536ed@github.com>

On Fri, 26 Sep 2025 07:04:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test used to timeout even though it seems the test passed..Increased the timeout to a safe value as sometimes it shows elapsed time to timeout > 300secs in macOS in CI and also ensured the wait-time for child process to execute the test is not been waiting endlessly.
>> Also ensured the original display mode is resetted after the test to prevent affecting following tests.
>> 
>> Tried 100 iterations of the fix on all platforms which is ok
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - PL updation
>  - Merge master
>  - Added mac ARM JBS
>  - PL updation
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8273617
>  - Remove displayMode reset
>  - EDT fix, timeout reduced
>  - 8273617: UninitializedDisplayModeChangeTest.java times out on macOS 12

I tested the fix on both a retina display and on an external display, but could not recreate the hang. AFAIK, this seems to work and LGTM. This is on MacOS 15.7.1 on M4.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27365#pullrequestreview-3394604960

From dnguyen at openjdk.org  Wed Oct 29 16:17:10 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 29 Oct 2025 16:17:10 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v11]
In-Reply-To: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
Message-ID: <dbMAQb5OcXMRlQ9g4mUoZT8-aFYZd8GdcQN0OqX2IQk=.ab473d3a-4995-4497-9ffc-8a7f67d87b98@github.com>

> 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:

  Update changes to adhere to line limit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26969/files
  - new: https://git.openjdk.org/jdk/pull/26969/files/c20d8263..1651f708

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

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

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

From dnguyen at openjdk.org  Wed Oct 29 16:17:11 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 29 Oct 2025 16:17:11 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v6]
In-Reply-To: <Dwg81LmQ1yqpFoOtlLD48EO6iG3GWHmxGkKBh1Ag9Ps=.8142c3e3-bc82-423b-a006-597e81c013d2@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <RsyPHk_GFxqEfx8SaOvWDx2ngw_e6gqzPyZ-wj7Xt_8=.5fc15055-67d9-403d-ab73-16d1fa823196@github.com>
 <j0wiNhwGRFk_037nsA8IvRZmMZJD2aVKQ0dCivN5Y5A=.7c230495-8767-48f9-b9ac-ad6a8a80ced6@github.com>
 <y_WqChGVXdsYFm7MusY3Q-hRHhexQoSqIe9od8DN_Ls=.51bb52e0-08e6-4a0f-812a-4cdcb00dee70@github.com>
 <Dwg81LmQ1yqpFoOtlLD48EO6iG3GWHmxGkKBh1Ag9Ps=.8142c3e3-bc82-423b-a006-597e81c013d2@github.com>
Message-ID: <IYICOAsk4fuqoxddlmJ_qz-d5yp3Nw-ow7DaeF2fLQk=.e8ad7cff-3926-4e1c-9c2e-1b25d2252674@github.com>

On Mon, 27 Oct 2025 21:27:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> I tried to follow a similar structure to the rest of the class. Some may be longer due to formatting links but I thought the result when generating the html looked fine. Was there any specific issue with the lines that are still longer than 80 chars?
>
> The main reason for the 80 characters limit is to eliminate need to horizontally scroll sources - especially when viewing git history and diffs in terminals. Once it was a part of the Sun (and then Oracle) Java Coding Conventions (JCC 4.1 to be precise). But that document is outdated and no longer maintained so i do not think we need to enforce it - at least when the line length is in reasonable. Personally i would not mind if the string (especially comments with JavaDoc formatting) if shorter than 120 chars. Longer than 120 is still very hard to read even on the modern high resolution displays - the side by side comparison of the diff with such a line would span across more than 240 characters and that is just hard to read which makes it easier to miss an unintended diff beyond the horizontal border.

@azuev-java I updated the few lines that seemed too long (mostly due to having multiple `@code` or `@value` links in it. Appreciate if you could take another look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2474101453

From serb at openjdk.org  Wed Oct 29 16:51:08 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Oct 2025 16:51:08 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
Message-ID: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>

On Tue, 28 Oct 2025 14:11:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> @mrserb is this what you had in mind ?

Yes, this looks fine. It might be useful to update the documentation to mention which toolchains are supported (or at least have been tested once). Do we already have this documented somewhere for hotspot?

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3462659843

From serb at openjdk.org  Wed Oct 29 16:56:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Oct 2025 16:56:05 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
 <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
 <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>
Message-ID: <Jo-qmqNJmngHFMBqT4wrRt3tK3nAiORiO9Ho_H8dsHk=.9b7d7d5f-407b-4392-a0e8-304213a618f1@github.com>

On Wed, 29 Oct 2025 14:02:34 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> I guess we can get rid of the test if we cannot test it reliably in CI as we have precedent of fixing this kind of EUDC issue without test as in JDK-8170913 if @prrace is ok with it
>
> @prrace Do you agree that the test is unnecessary here? We could leave it in the code with the relevant comment for reference and manual testing.

>Without this file, the test never fails and becomes meaningless.

Even on the system with JP locale?

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

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

From snazarki at openjdk.org  Wed Oct 29 17:05:57 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Wed, 29 Oct 2025 17:05:57 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <Jo-qmqNJmngHFMBqT4wrRt3tK3nAiORiO9Ho_H8dsHk=.9b7d7d5f-407b-4392-a0e8-304213a618f1@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
 <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
 <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>
 <Jo-qmqNJmngHFMBqT4wrRt3tK3nAiORiO9Ho_H8dsHk=.9b7d7d5f-407b-4392-a0e8-304213a618f1@github.com>
Message-ID: <te8uNRhNMsBuXudOpl0HfieTRptibV_U3jCZeE78mEI=.5db0f8bc-522a-440d-9957-a2764db73089@github.com>

On Wed, 29 Oct 2025 16:53:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @prrace Do you agree that the test is unnecessary here? We could leave it in the code with the relevant comment for reference and manual testing.
>
>>Without this file, the test never fails and becomes meaningless.
> 
> Even on the system with JP locale?

yes, without this file broken branch is never executed.

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

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

From serb at openjdk.org  Wed Oct 29 17:21:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Oct 2025 17:21:40 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v9]
In-Reply-To: <Y0BXpYS91m6OX6YWbt-5bMWYOSMwFl_BytDk9y8qdVE=.91d296e3-8d9a-4234-a480-246b01bdb372@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>
 <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com>
 <Y0BXpYS91m6OX6YWbt-5bMWYOSMwFl_BytDk9y8qdVE=.91d296e3-8d9a-4234-a480-246b01bdb372@github.com>
Message-ID: <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com>

On Thu, 23 Oct 2025 22:09:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> I looked through what I could find with Jemmy in the sanity testsuite and did not find anything regarding mouse movement. Is there something specific you could point me to look at?

you can start the sanity/client/SwingSet/src/ToolTipDemoTest.java and check how smoothly mouse is moved on the screen.

>By the way, I think it's worth comparing this to some other API, like Jemmy, which is used in the sanity testsuite. It implements a nice mouse movement with acceleration and deceleration to demonstrate the tooltips. Just to think about other ways to implement sliding.

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

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

From honkar at openjdk.org  Wed Oct 29 17:24:31 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Oct 2025 17:24:31 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v3]
In-Reply-To: <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
 <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>
Message-ID: <rR9re69tOm9b6NWeihVQXyd1fsU4oKjdbF7IoWA7Iu0=.03b78394-236c-407e-9a6b-aa2312a31fc4@github.com>

On Wed, 29 Oct 2025 13:12:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>>  e.g. setAction vs addActionListener 
>> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
>> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
>> 
>> 
>> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
>> 
>> Testing looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27979#pullrequestreview-3394930235

From serb at openjdk.org  Wed Oct 29 17:34:44 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Oct 2025 17:34:44 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <te8uNRhNMsBuXudOpl0HfieTRptibV_U3jCZeE78mEI=.5db0f8bc-522a-440d-9957-a2764db73089@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
 <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
 <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>
 <Jo-qmqNJmngHFMBqT4wrRt3tK3nAiORiO9Ho_H8dsHk=.9b7d7d5f-407b-4392-a0e8-304213a618f1@github.com>
 <te8uNRhNMsBuXudOpl0HfieTRptibV_U3jCZeE78mEI=.5db0f8bc-522a-440d-9957-a2764db73089@github.com>
Message-ID: <oRz3peOL2yaZlD1RBXLEpzpWIIFsWSAHNttq4k5qZRc=.2d5be648-2303-4304-8a0d-83a4f355babe@github.com>

On Wed, 29 Oct 2025 17:02:55 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>>>Without this file, the test never fails and becomes meaningless.
>> 
>> Even on the system with JP locale?
>
> yes, without this file broken branch is never executed.

Then It might be better to drop it, or at least mark it as manual. The current issue with the test is that it modifies the system and JDK, which could affect other tests running in parallel.

For the JDK, we can create a copy of TESTJAVA and run the test there. However, we can?t do the same for the system. The situation could become worse if the tests are terminated midway, as the cleanup step wouldn?t be executed and the system could remain misconfigured.

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

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

From prr at openjdk.org  Wed Oct 29 18:39:25 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 29 Oct 2025 18:39:25 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <oRz3peOL2yaZlD1RBXLEpzpWIIFsWSAHNttq4k5qZRc=.2d5be648-2303-4304-8a0d-83a4f355babe@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
 <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
 <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>
 <Jo-qmqNJmngHFMBqT4wrRt3tK3nAiORiO9Ho_H8dsHk=.9b7d7d5f-407b-4392-a0e8-304213a618f1@github.com>
 <te8uNRhNMsBuXudOpl0HfieTRptibV_U3jCZeE78mEI=.5db0f8bc-522a-440d-9957-a2764db73089@github.com>
 <oRz3peOL2yaZlD1RBXLEpzpWIIFsWSAHNttq4k5qZRc=.2d5be648-2303-4304-8a0d-83a4f355babe@github.com>
Message-ID: <P6kPCSRHPAk05SAYfTOQLDAxn-cNbxG7zExIz0dxBGk=.669dcf37-bb5a-4b6d-996f-dcc572304331@github.com>

On Wed, 29 Oct 2025 17:32:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> yes, without this file broken branch is never executed.
>
> Then It might be better to drop it, or at least mark it as manual. The current issue with the test is that it modifies the system and JDK, which could affect other tests running in parallel.
> 
> For the JDK, we can create a copy of TESTJAVA and run the test there. However, we can?t do the same for the system. The situation could become worse if the tests are terminated midway, as the cleanup step wouldn?t be executed and the system could remain misconfigured.

A test that modifies the windows registry is going to be a problem. I would just scrap the test.
I wouldn't even want to run such a test manually.

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

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

From snazarki at openjdk.org  Wed Oct 29 18:39:26 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Wed, 29 Oct 2025 18:39:26 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <P6kPCSRHPAk05SAYfTOQLDAxn-cNbxG7zExIz0dxBGk=.669dcf37-bb5a-4b6d-996f-dcc572304331@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
 <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
 <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>
 <Jo-qmqNJmngHFMBqT4wrRt3tK3nAiORiO9Ho_H8dsHk=.9b7d7d5f-407b-4392-a0e8-304213a618f1@github.com>
 <te8uNRhNMsBuXudOpl0HfieTRptibV_U3jCZeE78mEI=.5db0f8bc-522a-440d-9957-a2764db73089@github.com>
 <oRz3peOL2yaZlD1RBXLEpzpWIIFsWSAHNttq4k5qZRc=.2d5be648-2303-4304-8a0d-83a4f355babe@github.com>
 <P6kPCSRHPAk05SAYfTOQLDAxn-cNbxG7zExIz0dxBGk=.669dcf37-bb5a-4b6d-996f-dcc572304331@github.com>
Message-ID: <ddu2dYnBWBjKJhR6rikbGxlbzqPawM422Se8m0R9Zdo=.eacd2d78-6b4d-49f6-b809-bef87890c8d4@github.com>

On Wed, 29 Oct 2025 18:35:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Then It might be better to drop it, or at least mark it as manual. The current issue with the test is that it modifies the system and JDK, which could affect other tests running in parallel.
>> 
>> For the JDK, we can create a copy of TESTJAVA and run the test there. However, we can?t do the same for the system. The situation could become worse if the tests are terminated midway, as the cleanup step wouldn?t be executed and the system could remain misconfigured.
>
> A test that modifies the windows registry is going to be a problem. I would just scrap the test.
> I wouldn't even want to run such a test manually.

As far as I can see, the 'manual' is not intended for manual environment preparation/cleanup. So I am inclined to remove the test entirely.

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

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

From prr at openjdk.org  Wed Oct 29 18:43:07 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 29 Oct 2025 18:43:07 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <1ElY86E72Q040i4Jmkdw9BrZJlwK8jLR0gXikwCldx8=.5c532b56-4006-4b84-83cc-1da3ef7d4f60@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <VuKhPaBnr8WzUSjKzfLLO2WXUQpTl1JHVF5Kh5t0Y8A=.92b29d19-66d1-49ad-939a-c8055ddda7e0@github.com>
 <1ElY86E72Q040i4Jmkdw9BrZJlwK8jLR0gXikwCldx8=.5c532b56-4006-4b84-83cc-1da3ef7d4f60@github.com>
Message-ID: <USX9F2y-RPlsVd1vxLGGEzzbs0fzfN5t_zVyVvfKmzg=.c5ec9bdf-5047-4cc0-938e-ec7291a64ba4@github.com>

On Fri, 24 Oct 2025 09:43:27 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> > PS as referenced in that bug the updated INTL guide https://docs.oracle.com/en/java/javase/25/intl/font-configuration-files.html#GUID-F8ABF748-F3C3-4781-97B2-66C7E1E10EE9 says
> > The JDK places any files that it provides in $JDKHOME/lib. Do not modify that location. Instead, put any updates or custom versions of the configuration files in $JDKHOME/conf/fonts. On platforms that support font configuration files, the runtime will look first in $JDKHOME/conf/fonts.
> 
> The JDK still supports fonts in the lib folder. I believe that user apps and fonts have simply migrated between JDK updates over time.

There may still be code that looks there but that isn't support in the sense of "supports as  a feature of the product"

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3463186746

From snazarki at openjdk.org  Wed Oct 29 19:09:13 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Wed, 29 Oct 2025 19:09:13 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v7]
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: <v9QmXl6MNbphY6umKtFPZ8CiQ9Bl5n1ExkFOiuw7qZk=.6cb14793-d48a-4417-ba10-ae3cf14f90bb@github.com>

> 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.

Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:

  Remove test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27551/files
  - new: https://git.openjdk.org/jdk/pull/27551/files/57a1bcc7..af3eb2f8

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

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

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

From snazarki at openjdk.org  Wed Oct 29 19:09:15 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Wed, 29 Oct 2025 19:09:15 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <USX9F2y-RPlsVd1vxLGGEzzbs0fzfN5t_zVyVvfKmzg=.c5ec9bdf-5047-4cc0-938e-ec7291a64ba4@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <VuKhPaBnr8WzUSjKzfLLO2WXUQpTl1JHVF5Kh5t0Y8A=.92b29d19-66d1-49ad-939a-c8055ddda7e0@github.com>
 <1ElY86E72Q040i4Jmkdw9BrZJlwK8jLR0gXikwCldx8=.5c532b56-4006-4b84-83cc-1da3ef7d4f60@github.com>
 <USX9F2y-RPlsVd1vxLGGEzzbs0fzfN5t_zVyVvfKmzg=.c5ec9bdf-5047-4cc0-938e-ec7291a64ba4@github.com>
Message-ID: <m7ys92MOYAcbgw8NISr1QA0tLVzbnw33y_MIQxHQVmk=.f1a55eb6-dd89-4cf8-bebb-0334930263af@github.com>

On Wed, 29 Oct 2025 18:40:01 GMT, Phil Race <prr at openjdk.org> wrote:

> > The JDK still supports fonts in the lib folder. I believe that user apps and fonts have simply migrated between JDK updates over time.
> 
> There may still be code that looks there but that isn't support in the sense of "supports as a feature of the product"

I agree with you, but we can't just leave this bug. The feature should either be eliminated or fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27551#issuecomment-3463336166

From snazarki at openjdk.org  Wed Oct 29 19:09:16 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Wed, 29 Oct 2025 19:09:16 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v5]
In-Reply-To: <ddu2dYnBWBjKJhR6rikbGxlbzqPawM422Se8m0R9Zdo=.eacd2d78-6b4d-49f6-b809-bef87890c8d4@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <mHjgqa06jemqj3djWqzDYsGXpEg7GVJgY9NptqvYw9w=.e2c047e8-320d-497d-93c8-a1999fe76d4e@github.com>
 <sW41HjNgN3NDIL_d_Zo-kxPISggDJssccvwTDeDjnyk=.31224300-29a5-448f-aff7-321a411aca23@github.com>
 <RsWAuOhRpbe-2u_X_jis1RQqHxMayH6GUkxW1S8kC3E=.935b4ea6-f73b-4434-9c43-96cd97ee723a@github.com>
 <xHMFLWcI9XnZeIWkdt8mUJDhiTkD24EABY0ipUhDzVk=.59180766-7120-4ef1-a85d-fc8e341a8a56@github.com>
 <ARRsospgYoqEbZgVrM4d_70LKpNHrt2ALxZM-ET6Ars=.d497a368-0751-4ee4-bde1-1b1e933a51a2@github.com>
 <Jo-qmqNJmngHFMBqT4wrRt3tK3nAiORiO9Ho_H8dsHk=.9b7d7d5f-407b-4392-a0e8-304213a618f1@github.com>
 <te8uNRhNMsBuXudOpl0HfieTRptibV_U3jCZeE78mEI=.5db0f8bc-522a-440d-9957-a2764db73089@github.com>
 <oRz3peOL2yaZlD1RBXLEpzpWIIFsWSAHNttq4k5qZRc=.2d5be648-2303-4304-8a0d-83a4f355babe@github.com>
 <P6kPCSRHPAk05SAYfTOQLDAxn-cNbxG7zExIz0dxBGk=.669dcf37-bb5a-4b6d-996f-dcc572304331@github.com>
 <ddu2dYnBWBjKJhR6rikbGxlbzqPawM422Se
 8m0R9Zdo=.eacd2d78-6b4d-49f6-b809-bef87890c8d4@github.com>
Message-ID: <RAlVGFO7guROG7O8Nxyv4fHhxHJmdhZk_gcTOErGA0Y=.cf96620e-367d-482a-b097-bca056b4f218@github.com>

On Wed, 29 Oct 2025 18:36:27 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> A test that modifies the windows registry is going to be a problem. I would just scrap the test.
>> I wouldn't even want to run such a test manually.
>
> As far as I can see, the 'manual' is not intended for manual environment preparation/cleanup. So I am inclined to remove the test entirely.

Test was removed

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

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

From azvegint at openjdk.org  Wed Oct 29 20:19:46 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 29 Oct 2025 20:19:46 GMT
Subject: Integrated: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF
In-Reply-To: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
Message-ID: <hE_IS2ZOKCGTKSWM1WQ40cLYLQCROLP14y6Pq_Yhhjk=.b1a996c4-682e-4a58-ac77-887ec279ac54@github.com>

On Fri, 24 Oct 2025 17:07:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
> 
> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>  e.g. setAction vs addActionListener 
> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
> 
> 
> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
> 
> Testing looks good.

This pull request has now been integrated.

Changeset: d62553d8
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d62553d8dce7fe21942ec7a1268f536d9725b054
Stats:     57 lines in 1 file changed: 0 ins; 45 del; 12 mod

8316274: javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu 23.10 with Motif LAF

Reviewed-by: honkar, prr

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

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

From acobbs at openjdk.org  Wed Oct 29 20:54:19 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 29 Oct 2025 20:54:19 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression
In-Reply-To: <81JqWQPRbafWl22IItWNL52faigZS1l31SXsD9Zq1EE=.b6d84001-edd9-443a-8ca7-555a81ae6af0@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <81JqWQPRbafWl22IItWNL52faigZS1l31SXsD9Zq1EE=.b6d84001-edd9-443a-8ca7-555a81ae6af0@github.com>
Message-ID: <4Vtxklt1aGLbaZHO8bzuV1ZgR5YCmzvvQB1kdxxZvHw=.1ce1039c-d4df-4bd6-be04-c3c359b3de09@github.com>

On Tue, 16 Sep 2025 13:32:15 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> 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
>
>> /label remove kulla
> 
> I have removed kulla-dev from the bot configuration so the stuck label is now benign.

@erikj79, @magicus - Would you mind updating your review since the recent changes that addressed merge conflicts?

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3463955731

From erikj at openjdk.org  Wed Oct 29 21:10:33 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 29 Oct 2025 21:10:33 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v4]
In-Reply-To: <mHC6vbCdDTDOUixEI-cZeIvxCy2CEzGlW14LdKzINwE=.0b3e1e71-583b-48ab-9546-3485a1a61e01@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
 <mHC6vbCdDTDOUixEI-cZeIvxCy2CEzGlW14LdKzINwE=.0b3e1e71-583b-48ab-9546-3485a1a61e01@github.com>
Message-ID: <3TYbuRwZvS0UJxfI1fFZN4HXZwbsX6fHFbkgndH6cNU=.adcd31f8-12c8-4087-be78-b679f6f9e275@github.com>

On Wed, 22 Oct 2025 15:21:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> 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 133 commits:
> 
>  - Merge branch 'master' into JDK-8344159 to fix conflict.
>  - 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.
>  - ... and 123 more: https://git.openjdk.org/jdk/compare/a1be2979...f2b75547

Build changes still look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25167#pullrequestreview-3396264627

From honkar at openjdk.org  Wed Oct 29 22:29:02 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Oct 2025 22:29:02 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v3]
In-Reply-To: <1IVd2uS3W_AD1OnJ59sPPUJMaFhCvElESGW7P0DgKcE=.d245d46e-bd24-47ff-949c-c3c994445be3@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <1IVd2uS3W_AD1OnJ59sPPUJMaFhCvElESGW7P0DgKcE=.d245d46e-bd24-47ff-949c-c3c994445be3@github.com>
Message-ID: <Ix9c9GtpW6TBPYtr00TrMl50g6v_HgsZ6h5j4FvtYLU=.c8ae7921-f826-4356-a5f3-9409764de120@github.com>

On Wed, 29 Oct 2025 10:47:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
>> 
>> Before fix
>> 
>> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
>> 
>> With fix
>> 
>> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct layouting

There seems to be less gap between text and icon in RTL Windows L&F case. The border looks different when the icon is to the left and right side of text, is that expected?

<img width="200" height="200" alt="image" src="https://github.com/user-attachments/assets/60cb104d-8b25-45b1-89d4-67dbd8b6f0b0" />

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

PR Comment: https://git.openjdk.org/jdk/pull/27968#issuecomment-3464511099

From kizune at openjdk.org  Wed Oct 29 23:03:05 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 29 Oct 2025 23:03:05 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v3]
In-Reply-To: <GBb9Q6yNbJxx1M6v23WOdeZ8ssSzapYnmYSUII7Ccb8=.5a46ccc7-034b-4395-91be-043f8c86fec1@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
 <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>
 <GBb9Q6yNbJxx1M6v23WOdeZ8ssSzapYnmYSUII7Ccb8=.5a46ccc7-034b-4395-91be-043f8c86fec1@github.com>
Message-ID: <sL8qrf-pDRIRSK33jsagrb7ev_LUfYOBldsMH6_MHNE=.3ed83df1-d411-4667-84c8-a26d7993207b@github.com>

On Wed, 29 Oct 2025 10:44:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> LEADING causes the text to appear before icon so need to account for it..
>> 
>> Before fix
>> 
>> <img width="302" height="188" alt="Image" src="https://github.com/user-attachments/assets/3c7dd877-da0a-44dd-8e1e-8486344b36da" />
>> 
>> After fix
>> 
>> <img width="196" height="120" alt="Image" src="https://github.com/user-attachments/assets/14aed6e1-2b42-4d10-9a4d-a4cc4f9f230a" />
>> 
>> Others are working as I can see "horizontalAlignment = LEFT..." and "horizontalAlignment=RIGHT" which uses LEFT and RIGHT horizontal text positioning
>> 
>> <img width="524" height="77" alt="image" src="https://github.com/user-attachments/assets/f2b5eb41-b48d-4187-bc55-1f1359142d4f" />
>
> Actually I have modified the PR to rectify layouting ensuring radiobutton bullet/checkmark are drawn at dedicated position and doesn't interfere with icon position for RTL too..Previous PR iteration was not taking into account of this for RTL so if the menuitem was selected in RTL, it was not shown..

I just tested the latest version of the fix with the slightly modified test case (i added two extra menu items with 
`menuItem.setHorizontalTextPosition(SwingConstants.LEFT);`
and
`menuItem.setHorizontalTextPosition(SwingConstants.RIGHT);`
and it does not look exactly correct. Here's the screenshot:
<img width="331" height="511" alt="image" src="https://github.com/user-attachments/assets/8494241e-aefd-4259-bcb2-8b3cf2360d7d" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2475883606

From serb at openjdk.org  Wed Oct 29 23:31:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Oct 2025 23:31:02 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow
In-Reply-To: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
References: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
Message-ID: <o5tmoOEPQ62U_jKZ8s6psW67xoPttUPwZwpCpFvH5bU=.e6dd1b9a-4c6d-41ba-b961-cc5c729d3d15@github.com>

On Thu, 23 Oct 2025 06:54:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder`
> it throws NPE which is not mentioned in the spec as the expected outcome.
> Fixed the NPE and the spec

The constructors of BevelBorder, SoftBevelBorder, and BevelBorderUIResource still throw unspecified NPE. Is it necessary to update only the "createXX.." methods, or should we instead update the spec of the potential NPE for all of these classes/methods?

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

PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3465022354

From psadhukhan at openjdk.org  Thu Oct 30 02:16:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 02:16:58 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v4]
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <FnXAylkbqdAUiCLAst9PmQEjvitklaJNb7O67BY2C2c=.ce6f7ff7-26f5-4f63-8e84-5754eab9a734@github.com>

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

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

  SwingConstants LEFT and RIGHT fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27968/files
  - new: https://git.openjdk.org/jdk/pull/27968/files/201f9aca..ca4e1904

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

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

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

From psadhukhan at openjdk.org  Thu Oct 30 02:16:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 02:16:59 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v3]
In-Reply-To: <Ix9c9GtpW6TBPYtr00TrMl50g6v_HgsZ6h5j4FvtYLU=.c8ae7921-f826-4356-a5f3-9409764de120@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <1IVd2uS3W_AD1OnJ59sPPUJMaFhCvElESGW7P0DgKcE=.d245d46e-bd24-47ff-949c-c3c994445be3@github.com>
 <Ix9c9GtpW6TBPYtr00TrMl50g6v_HgsZ6h5j4FvtYLU=.c8ae7921-f826-4356-a5f3-9409764de120@github.com>
Message-ID: <qyzSjK56k0OHtuVEaqngkkZzdx4KTyjigCH7VqbA65k=.39bc3c0a-05b3-4e9d-8abd-510d0231f484@github.com>

On Wed, 29 Oct 2025 22:26:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> There seems to be less gap between text and icon in RTL Windows L&F case. The icon border looks different when the icon is to the left and right side of text, is that expected?

should be ok now in latest iteration..

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

PR Comment: https://git.openjdk.org/jdk/pull/27968#issuecomment-3465853392

From psadhukhan at openjdk.org  Thu Oct 30 02:17:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 02:17:00 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v4]
In-Reply-To: <sL8qrf-pDRIRSK33jsagrb7ev_LUfYOBldsMH6_MHNE=.3ed83df1-d411-4667-84c8-a26d7993207b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
 <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>
 <GBb9Q6yNbJxx1M6v23WOdeZ8ssSzapYnmYSUII7Ccb8=.5a46ccc7-034b-4395-91be-043f8c86fec1@github.com>
 <sL8qrf-pDRIRSK33jsagrb7ev_LUfYOBldsMH6_MHNE=.3ed83df1-d411-4667-84c8-a26d7993207b@github.com>
Message-ID: <7oc1fcfvSu1R2nYRDnHM26cy4UI0YEllg_Yuw7DZBNk=.11f9b395-561f-474d-afb6-23c74f9724cb@github.com>

On Wed, 29 Oct 2025 23:00:35 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Actually I have modified the PR to rectify layouting ensuring radiobutton bullet/checkmark are drawn at dedicated position and doesn't interfere with icon position for RTL too..Previous PR iteration was not taking into account of this for RTL so if the menuitem was selected in RTL, it was not shown..
>
> I just tested the latest version of the fix with the slightly modified test case (i added two extra menu items with 
> `menuItem.setHorizontalTextPosition(SwingConstants.LEFT);`
> and
> `menuItem.setHorizontalTextPosition(SwingConstants.RIGHT);`
> and it does not look exactly correct. Here's the screenshot:
> <img width="331" height="511" alt="image" src="https://github.com/user-attachments/assets/8494241e-aefd-4259-bcb2-8b3cf2360d7d" />

Fixed..it now looks ok to me...Please check

<img width="391" height="614" alt="image" src="https://github.com/user-attachments/assets/46661a18-947b-4483-969d-c7d05ace3ff0" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2476200429

From psadhukhan at openjdk.org  Thu Oct 30 03:18:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 03:18:05 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow [v2]
In-Reply-To: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
References: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
Message-ID: <LMAuCJ4Nnn2FMbCMwGI7EvyG0ELHuvGGrZ-WoAfkLT8=.e3c05bfd-5f61-474e-95d7-85f435f91c9a@github.com>

> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder`
> it throws NPE which is not mentioned in the spec as the expected outcome.
> Fixed the NPE and the spec

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

  Ensure no NPE for BevelBorder constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27949/files
  - new: https://git.openjdk.org/jdk/pull/27949/files/ec182a9a..4e8f0fd3

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

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

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

From psadhukhan at openjdk.org  Thu Oct 30 03:18:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 03:18:06 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow
In-Reply-To: <o5tmoOEPQ62U_jKZ8s6psW67xoPttUPwZwpCpFvH5bU=.e6dd1b9a-4c6d-41ba-b961-cc5c729d3d15@github.com>
References: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
 <o5tmoOEPQ62U_jKZ8s6psW67xoPttUPwZwpCpFvH5bU=.e6dd1b9a-4c6d-41ba-b961-cc5c729d3d15@github.com>
Message-ID: <_N2kICeF_vXEi3oxsFFB5Bc3N5pBGxA6AulyY0qHNgA=.2d1f9151-3e7b-42fb-93e0-9e765cc3e089@github.com>

On Wed, 29 Oct 2025 23:28:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The constructors of BevelBorder, SoftBevelBorder, and BevelBorderUIResource still throw unspecified NPE. Is it necessary to update only the "createXX.." methods, or should we instead update the spec of the potential NPE for all of these classes/methods?

I have updated for those too..

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

PR Comment: https://git.openjdk.org/jdk/pull/27949#issuecomment-3465956495

From psadhukhan at openjdk.org  Thu Oct 30 03:30:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 03:30:45 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow [v3]
In-Reply-To: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
References: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
Message-ID: <LnsNC4jxfbj_hTkDuSBf7u6i3gPTXwdD_202l01VjhE=.6170cec2-fe5a-4387-84be-7fe6a2db9797@github.com>

> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder`
> it throws NPE which is not mentioned in the spec as the expected outcome.
> Fixed the NPE and the spec

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27949/files
  - new: https://git.openjdk.org/jdk/pull/27949/files/4e8f0fd3..0ecc57ba

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

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

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

From serb at openjdk.org  Thu Oct 30 04:20:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Oct 2025 04:20:19 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v3]
In-Reply-To: <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
 <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>
Message-ID: <KSC05BmHbeO_FTXzMPkjH6mKKv8d7AVGnFO1NUHEvac=.b13574cb-2073-44a5-930c-b332d5ecd976@github.com>

On Wed, 29 Oct 2025 13:12:41 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The test began to fail in Ubuntu 23.10. While investigating, I found and filed two new issues:
>> 
>> * https://bugs.openjdk.org/browse/JDK-8370624 JToggleButton does not display caption if setAction is called
>>  e.g. setAction vs addActionListener 
>> <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/28d24449-e5aa-41fb-a5f1-470ab11d6899" /> vs <img width="287" height="86" alt="image" src="https://github.com/user-attachments/assets/04cdd4ed-6ea4-403c-86c3-f60971d16007" />
>> * https://bugs.openjdk.org/browse/JDK-8370627 motif look and feel focus traversal order may vary depending on the system version
>> 
>> 
>> This test fix changes `setAction` to  `addActionListener` and it is to avoid problemlisting the test on Linux.
>> 
>> Testing looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

>This test fix changes setAction to addActionListener and it is to avoid problemlisting the test on Linux.

Why does replacing setAction with addActionListener to make the text visible affect the test execution?

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

PR Comment: https://git.openjdk.org/jdk/pull/27979#issuecomment-3466057735

From psadhukhan at openjdk.org  Thu Oct 30 06:07:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 06:07:04 GMT
Subject: RFR: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used. [v2]
In-Reply-To: <5j1ZgrPfBbOd_IePXp7QzqCw41Cq1MUh8p9WnRVX8GI=.dcc8d9ca-5683-49be-88c6-bba20825f8a9@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
 <5j1ZgrPfBbOd_IePXp7QzqCw41Cq1MUh8p9WnRVX8GI=.dcc8d9ca-5683-49be-88c6-bba20825f8a9@github.com>
Message-ID: <K46FIoLhVOccbQLhxeqsQIeFtzUtrGBlRcfpfrHgCTI=.f2cc9c95-a5bd-4b1c-8388-e1be863c996d@github.com>

On Fri, 24 Oct 2025 18:35:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> macOS printing uses a Quartz surface. It is the SurfaceData for a CPrinterGraphics.
>> That Surface is not disconnected from the graphics unless Graphics.dispose() is called.
>> If the application uses Graphics.create() then the implementation will not Graphics.dispose() it.
>> If it is used after printing is complete and the CGContext is no longer valid a crash will occur.
>> We need to invalidate the surface as soon as printing to a page is done.
>> Note: this is Graphics.dispose(), and is unrelated to disposal of an object when it becomes unreachable.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8370141

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27905#pullrequestreview-3397561312

From psadhukhan at openjdk.org  Thu Oct 30 06:14:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Oct 2025 06:14:03 GMT
Subject: RFR: 8370160: NumericShaper allows illegal ranges
In-Reply-To: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
References: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
Message-ID: <DPEKNmJzsHV0mW0WWnGi1tF5D3-G31k0X6d4BrU2KqM=.576371a6-9a09-452d-bef2-3708369c4de9@github.com>

On Sat, 18 Oct 2025 05:05:48 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a follow-on to 8365077: java.awt.font.NumericShaper violates equals/hashCode contract
> 
> The factory method to construct a contextual shaper from a bitmask will happily store illegal, unspecified bits.
> So there are still ways to create instances which violate the contract.
> 
> This isn't possible with the enum approach. We should align these two. And we should document it.
> 
> Additionally the behaviour of eliminating an value which is of lesser precedence is also something we should specify.
> 
> CSR : https://bugs.openjdk.org/browse/JDK-8370161

Marked as reviewed by psadhukhan (Reviewer).

src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 1446:

> 1444:      * Any bit set in the {@code ranges} bitmask which is not a
> 1445:      * recognised value is discarded. Similarly if two bits are
> 1446:      * specified where one takes precedence, the lesser one is discarded.

should we mention "take precedence over the other" to be consistent with other updated javadoc?

src/java.desktop/share/classes/java/awt/font/NumericShaper.java line 1467:

> 1465:      *
> 1466:      * If two ranges are specified where one takes precedence over the
> 1467:      * other the lesser range is discarded.

shouldn't there be a "," after other?

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

PR Review: https://git.openjdk.org/jdk/pull/27884#pullrequestreview-3397575640
PR Review Comment: https://git.openjdk.org/jdk/pull/27884#discussion_r2476528313
PR Review Comment: https://git.openjdk.org/jdk/pull/27884#discussion_r2476527196

From mbaesken at openjdk.org  Thu Oct 30 08:34:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 30 Oct 2025 08:34:55 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
Message-ID: <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>

On Wed, 29 Oct 2025 16:48:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > @mrserb is this what you had in mind ?
> 
> Yes, this looks fine. It might be useful to update the documentation to mention which toolchains are supported (or at least have been tested once). Do we already have this documented somewhere for hotspot?

We have support for all important toolchains (gcc, clang, MSVC).  (when testing the PR on libfontmanager and freetype I had this enabled on all our SAP supported platforms).
However it might not work for all versions of these compilers.
And when building HS with lto support I remember a few jtreg tests failed (so it  might need some more work to look into all details).

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3466650220

From erikj at openjdk.org  Thu Oct 30 13:24:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 30 Oct 2025 13:24:43 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
 <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
Message-ID: <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>

On Thu, 30 Oct 2025 08:32:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> However it might not work for all versions of these compilers.

When introducing new compiler flags, you need to do one of:

1. Verify that the flags are supported on all versions of the compiler we support. There is a minimum version defined for each. Reading the documentation to find out when the compiler feature was introduced is enough, you don't need to actually test every version yourself.
2. If 1 couldn't be proved, then only add the flag conditionally with a check in configure.

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3467974190

From mbaesken at openjdk.org  Thu Oct 30 15:43:44 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 30 Oct 2025 15:43:44 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v2]
In-Reply-To: <rYzlbrvNX9MjncrPmAiCWNaVqIgC_bw6Fnew9iXSMRs=.9e29cf9a-67c7-41dd-8352-148620e3dc88@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
 <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
 <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com>
 <rYzlbrvNX9MjncrPmAiCWNaVqIgC_bw6Fnew9iXSMRs=.9e29cf9a-67c7-41dd-8352-148620e3dc88@github.com>
Message-ID: <kPI53wkRZsLOQmMjbdTQM41ZLAt38evgMjwprONSQoQ=.aa87e062-d7b5-4686-8e00-13a46d209f9f@github.com>

On Wed, 29 Oct 2025 14:32:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I wonder if it would be a good idea to add a global on/off switch (configure arg) for this whole thing, I'm really not sure. It kind of depends on what the impact is. If the impact is unknown, then a global on/off switch, default off, would let every distributor evaluate this on their own. That would of course also require that at least some libs have this enabled.

I can find a few other libs besides libfontmanager where we see some size reduction (performance improvement will be hard to prove without good benchmarks on lib level).
The for those libs set LTO = true; and add a global  on/off  configure arg to enable this.  This way, we do not cause issues for distributors because still the configure flag must be set; but provide an easy way to enable it and use lto on JDK lib level (and it will be easy to add it for more libs if it is seen as beneficial).

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3468662909

From azvegint at openjdk.org  Thu Oct 30 15:49:50 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 30 Oct 2025 15:49:50 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v3]
In-Reply-To: <KSC05BmHbeO_FTXzMPkjH6mKKv8d7AVGnFO1NUHEvac=.b13574cb-2073-44a5-930c-b332d5ecd976@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
 <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>
 <KSC05BmHbeO_FTXzMPkjH6mKKv8d7AVGnFO1NUHEvac=.b13574cb-2073-44a5-930c-b332d5ecd976@github.com>
Message-ID: <FteAJGGvpZR-kWvvR-FWFkRC7KQRjX1dvMc8ZNWKIyo=.eef59d2c-8fa9-4cf3-afb2-793e793c51ee@github.com>

On Thu, 30 Oct 2025 04:17:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why does replacing setAction with addActionListener to make the text visible affect the test execution?

It is not clear yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/27979#issuecomment-3468690700

From mbaesken at openjdk.org  Thu Oct 30 15:51:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 30 Oct 2025 15:51:46 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level
In-Reply-To: <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
 <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
 <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>
Message-ID: <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com>

On Thu, 30 Oct 2025 13:22:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > However it might not work for all versions of these compilers.
> 
> When introducing new compiler flags, you need to do one of:
> 
> 1. Verify that the flags are supported on all versions of the compiler we support. There is a minimum version defined for each. Reading the documentation to find out when the compiler feature was introduced is enough, you don't need to actually test every version yourself.
> 2. If 1 couldn't be proved, then only add the flag conditionally with a check in configure.

The compiler flags are not really 'new' but borrowed from Hotspot LTO.

`MSVC ( -GL -LTCG:INCREMENTAL ): ` available for a long time (~20 years), all our supported compilers

`AIX :` we only support XLC 14.X, there it is available

`gcc   :`  -flto=auto -fuse-linker-plugin -fno-strict-aliasing -fno-fat-lto-objects
         since 4.8  (-flto=auto is documented since gcc-10 but older compilers seem to understand it too)

`clang:`  I can find -flto in the clang13 manual (https://releases.llvm.org/13.0.0/tools/clang/docs/UsersManual.html) but cannot find -flto=auto , so maybe we should just just -flto in the link flags for clang ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3468699988

From kizune at openjdk.org  Thu Oct 30 16:24:49 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 16:24:49 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: <VOeNDUxLE6ozg4zV7xyBN2dQO3bgryMFzAA2pw4JSBI=.2e26819a-7ba4-4d0c-a335-e68b8f720cec@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 kizune (Reviewer).

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

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

From kizune at openjdk.org  Thu Oct 30 16:28:02 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 16:28:02 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v11]
In-Reply-To: <dbMAQb5OcXMRlQ9g4mUoZT8-aFYZd8GdcQN0OqX2IQk=.ab473d3a-4995-4497-9ffc-8a7f67d87b98@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <dbMAQb5OcXMRlQ9g4mUoZT8-aFYZd8GdcQN0OqX2IQk=.ab473d3a-4995-4497-9ffc-8a7f67d87b98@github.com>
Message-ID: <is9qa78ZU02m-OyPXCK6pIuL-n374I3WB0KdguuPavY=.3cca37fe-4274-4f32-82c9-e804e2a3488a@github.com>

On Wed, 29 Oct 2025 16:17:10 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:
> 
>   Update changes to adhere to line limit

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26969#pullrequestreview-3400538236

From kizune at openjdk.org  Thu Oct 30 16:28:03 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 16:28:03 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v6]
In-Reply-To: <IYICOAsk4fuqoxddlmJ_qz-d5yp3Nw-ow7DaeF2fLQk=.e8ad7cff-3926-4e1c-9c2e-1b25d2252674@github.com>
References: <bBZcBspszsAQpyKzJhfwPOHxN_QmoyLjpcxrc-Cem0I=.e990b61b-33e1-4d12-9e70-fce2211cc186@github.com>
 <RsyPHk_GFxqEfx8SaOvWDx2ngw_e6gqzPyZ-wj7Xt_8=.5fc15055-67d9-403d-ab73-16d1fa823196@github.com>
 <j0wiNhwGRFk_037nsA8IvRZmMZJD2aVKQ0dCivN5Y5A=.7c230495-8767-48f9-b9ac-ad6a8a80ced6@github.com>
 <y_WqChGVXdsYFm7MusY3Q-hRHhexQoSqIe9od8DN_Ls=.51bb52e0-08e6-4a0f-812a-4cdcb00dee70@github.com>
 <Dwg81LmQ1yqpFoOtlLD48EO6iG3GWHmxGkKBh1Ag9Ps=.8142c3e3-bc82-423b-a006-597e81c013d2@github.com>
 <IYICOAsk4fuqoxddlmJ_qz-d5yp3Nw-ow7DaeF2fLQk=.e8ad7cff-3926-4e1c-9c2e-1b25d2252674@github.com>
Message-ID: <eBR6gNuwTe3f4O9HXVHP_abS9wyEHIOgm5NmaBer8r0=.e365888e-1fde-4553-ae12-9718c575158f@github.com>

On Wed, 29 Oct 2025 16:12:19 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The main reason for the 80 characters limit is to eliminate need to horizontally scroll sources - especially when viewing git history and diffs in terminals. Once it was a part of the Sun (and then Oracle) Java Coding Conventions (JCC 4.1 to be precise). But that document is outdated and no longer maintained so i do not think we need to enforce it - at least when the line length is in reasonable. Personally i would not mind if the string (especially comments with JavaDoc formatting) if shorter than 120 chars. Longer than 120 is still very hard to read even on the modern high resolution displays - the side by side comparison of the diff with such a line would span across more than 240 characters and that is just hard to read which makes it easier to miss an unintended diff beyond the horizontal border.
>
> @azuev-java I updated the few lines that seemed too long (mostly due to having multiple `@code` or `@value` links in it. Appreciate if you could take another look.

Much better, thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2478752728

From kizune at openjdk.org  Thu Oct 30 16:34:39 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 16:34:39 GMT
Subject: RFR: 8370160: NumericShaper allows illegal ranges
In-Reply-To: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
References: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
Message-ID: <316H5WmI3eOmimvCkHtbTZarrVyloyp0tC9jBwLdAj4=.bf297216-254b-4a16-a88a-4aa2f5668fb8@github.com>

On Sat, 18 Oct 2025 05:05:48 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a follow-on to 8365077: java.awt.font.NumericShaper violates equals/hashCode contract
> 
> The factory method to construct a contextual shaper from a bitmask will happily store illegal, unspecified bits.
> So there are still ways to create instances which violate the contract.
> 
> This isn't possible with the enum approach. We should align these two. And we should document it.
> 
> Additionally the behaviour of eliminating an value which is of lesser precedence is also something we should specify.
> 
> CSR : https://bugs.openjdk.org/browse/JDK-8370161

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27884#pullrequestreview-3400577406

From kizune at openjdk.org  Thu Oct 30 16:35:42 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 16:35:42 GMT
Subject: RFR: 8369618: Remove outdated reference to JDK 1.1 in the spec of
 BufferedImage.TYPE_INT_ARGB
In-Reply-To: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>
References: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>
Message-ID: <V3KjgSXVaD5RPCV0Vg169yGmSNbLmAabAzLicUDH4HM=.b5656458-c836-4f81-9cef-043e533cd651@github.com>

On Sun, 12 Oct 2025 01:40:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The reference to "JDK 1.1 and earlier releases" was removed from the BufferedImage.TYPE_INT_ARGB spec.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27758#pullrequestreview-3400582866

From prr at openjdk.org  Thu Oct 30 18:06:38 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 18:06:38 GMT
Subject: Integrated: 8370160: NumericShaper allows illegal ranges
In-Reply-To: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
References: <Dvd5Ziq885lRNyzgG7OhcDvtsrBWFZdFOlpydt7SXGU=.906ee796-5e7c-4e7f-ad46-ec5893de4545@github.com>
Message-ID: <bcTCsMdoPG2lkeoJPLwVI5mP9nQrS8rqpGcsTTpS43U=.674c6313-93a1-49cf-b247-fe2cc7655923@github.com>

On Sat, 18 Oct 2025 05:05:48 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a follow-on to 8365077: java.awt.font.NumericShaper violates equals/hashCode contract
> 
> The factory method to construct a contextual shaper from a bitmask will happily store illegal, unspecified bits.
> So there are still ways to create instances which violate the contract.
> 
> This isn't possible with the enum approach. We should align these two. And we should document it.
> 
> Additionally the behaviour of eliminating an value which is of lesser precedence is also something we should specify.
> 
> CSR : https://bugs.openjdk.org/browse/JDK-8370161

This pull request has now been integrated.

Changeset: 4b315111
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b315111493ac65511890bc2127489ceee693915
Stats:     17 lines in 2 files changed: 15 ins; 0 del; 2 mod

8370160: NumericShaper allows illegal ranges

Reviewed-by: serb, psadhukhan, kizune

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

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

From prr at openjdk.org  Thu Oct 30 18:59:06 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 18:59:06 GMT
Subject: RFR: 8357252: sun/awt/font/TestArabicHebrew.java fails in OEL 9 and 10
 x64
Message-ID: <2DGbd1T9g477NOXI2G6bIcP7dYyM1-ur745qYQA69_o=.e5c976f6-b72d-4688-b8cc-3e9f68db192b@github.com>

A long time ago (JDK 7) when the linux font properties were largely replaced by using fontconfig logic was included to try to limit the number of slots used for composite fonts by requiring that fonts add sufficient code points.
In practice today this limitation seems to be reductions like having 40 slots instead of 50. 
Except for keeping it for debugging, this fix removes that limitation which had a bad consequence on some recent Linuxes where the primary Hebrew font  (Noto Sans Hebrew) came after another font (DejaVu Sans) that provided some Hebrew accents and punctuation but not the alphabet and was also far enough down the list (14th) to be where we require 50 new code points to be worthy of inclusion and it only added 33.

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

Commit messages:
 - 8357252

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

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

From prr at openjdk.org  Thu Oct 30 19:12:11 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 19:12:11 GMT
Subject: Integrated: 8370141: [macOS] Crash after PrinterJob ends when
 Graphics.create() is used.
In-Reply-To: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
References: <0LTXRwV4FDHZhkKP5bz0W1R6q7J55pEUnqCYl-8G1yE=.04227cf5-02bd-4c69-b3ef-799510363d2d@github.com>
Message-ID: <0u4rJY1DEmT0YYWB3UG8yXSiQzc_xiETMal7TCMyypc=.ad116bf1-f814-4b52-a56e-0d82967c5fc7@github.com>

On Mon, 20 Oct 2025 20:45:47 GMT, Phil Race <prr at openjdk.org> wrote:

> macOS printing uses a Quartz surface. It is the SurfaceData for a CPrinterGraphics.
> That Surface is not disconnected from the graphics unless Graphics.dispose() is called.
> If the application uses Graphics.create() then the implementation will not Graphics.dispose() it.
> If it is used after printing is complete and the CGContext is no longer valid a crash will occur.
> We need to invalidate the surface as soon as printing to a page is done.
> Note: this is Graphics.dispose(), and is unrelated to disposal of an object when it becomes unreachable.

This pull request has now been integrated.

Changeset: 414e7286
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/414e72869895562adcea5c21ff3e7252cef5b13f
Stats:     256 lines in 5 files changed: 234 ins; 5 del; 17 mod

8370141: [macOS] Crash after PrinterJob ends when Graphics.create() is used.

Reviewed-by: serb, psadhukhan

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

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

From prr at openjdk.org  Thu Oct 30 19:16:17 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 19:16:17 GMT
Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font
 configuration file names
Message-ID: <PZKplDqUxD8Z2EQKVpYYB8lQKuoafomUIvla1cFgmj0=.56d454e8-d6ea-4db5-802b-84fa528147a8@github.com>

The JBS issue has a long discussion and explanation but here's a short version.
Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux
use the standard ID and VERSION_ID fields in /etc/os-release which is now standard.
even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release
And if it doesn't we just use "Linux" as the name.

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

Commit messages:
 - 8370719

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

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

From serb at openjdk.org  Thu Oct 30 19:31:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Oct 2025 19:31:52 GMT
Subject: RFR: 8368882: NPE during text drawing on machine with JP locale
 [v7]
In-Reply-To: <v9QmXl6MNbphY6umKtFPZ8CiQ9Bl5n1ExkFOiuw7qZk=.6cb14793-d48a-4417-ba10-ae3cf14f90bb@github.com>
References: <YNShQqKUGwp1InxU0F-fmVwuUuvF2OPsa26z-d4dd94=.47e2d2e0-a886-4b8d-8bb0-875ff30a8b74@github.com>
 <v9QmXl6MNbphY6umKtFPZ8CiQ9Bl5n1ExkFOiuw7qZk=.6cb14793-d48a-4417-ba10-ae3cf14f90bb@github.com>
Message-ID: <mmvdG98DodyIUa7Z_ZhdmhXriqOlJr5r-Cr_LKyF4Uw=.2746d0d7-d0b8-4431-8a10-72c758f237b1@github.com>

On Wed, 29 Oct 2025 19:09:13 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.
>
> Sergey Nazarkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove test

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27551#pullrequestreview-3401297072

From serb at openjdk.org  Thu Oct 30 19:36:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Oct 2025 19:36:33 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v3]
In-Reply-To: <FteAJGGvpZR-kWvvR-FWFkRC7KQRjX1dvMc8ZNWKIyo=.eef59d2c-8fa9-4cf3-afb2-793e793c51ee@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
 <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>
 <KSC05BmHbeO_FTXzMPkjH6mKKv8d7AVGnFO1NUHEvac=.b13574cb-2073-44a5-930c-b332d5ecd976@github.com>
 <FteAJGGvpZR-kWvvR-FWFkRC7KQRjX1dvMc8ZNWKIyo=.eef59d2c-8fa9-4cf3-afb2-793e793c51ee@github.com>
Message-ID: <Slqh5oKDZNcQC2IqErFmtus3AAXsb-4z0-5SPD32Ci8=.808a3e9f-aac2-4c5d-a685-9e840ef99722@github.com>

On Thu, 30 Oct 2025 15:46:35 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>It is not clear yet.

So this test patch will be reverted once JDK-8370627 is integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/27979#issuecomment-3469749935

From dnguyen at openjdk.org  Thu Oct 30 19:54:14 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 30 Oct 2025 19:54:14 GMT
Subject: Withdrawn: 8360160: ubuntu-22-04 machine is failing client tests
In-Reply-To: <LJR5GwDbYFRueT-FHkuo2-vk0Mu_rUHzA9XGk7skmt8=.b6248e26-d4c5-4f91-b772-fc234a7c22ba@github.com>
References: <LJR5GwDbYFRueT-FHkuo2-vk0Mu_rUHzA9XGk7skmt8=.b6248e26-d4c5-4f91-b772-fc234a7c22ba@github.com>
Message-ID: <3MMpiPf605mAxlSyW011XGCMuib8bt-kMUs63yQYRlw=.3786a8db-e357-4b90-98bf-420427d612bf@github.com>

On Thu, 21 Aug 2025 01:21:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Ubuntu machine has multiple failing java awt tests. When looking at the screenshots of the desktop when each test fails, a white square can be seen at the top-left of the desktop.
> 
> <img width="803" height="344" alt="Screenshot 2025-08-20 at 10 06 37?AM" src="https://github.com/user-attachments/assets/52d023f6-18ff-46d4-98c4-e2e332ab6a03" />
> 
> This seems to be similar to the white square that `FrameVisualTest.java` creates so the frame was not disposed of properly during this failure. I have tried re-creating this failure on Ubuntu 22.04, similar to the failure OS that this originally occurred on, to no avail. I ran this test individually, and with all of the listed failing tests back-to-back but all the tests pass as normal. This stabilization fix to the test attempts to prevent this in case it occurs again.

This pull request has been closed without being integrated.

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

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

From dnguyen at openjdk.org  Thu Oct 30 19:52:20 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 30 Oct 2025 19:52:20 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v9]
In-Reply-To: <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@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>
 <1nxKOtN4B2h026FhyQp8t-1IOZBFPMfnif7I5a0Vnuc=.9ffffa12-226f-49ac-8b85-fac3750c649f@github.com>
 <Y0BXpYS91m6OX6YWbt-5bMWYOSMwFl_BytDk9y8qdVE=.91d296e3-8d9a-4234-a480-246b01bdb372@github.com>
 <3hw1X_jGyDqVuyleOkeirF2hj4ZnfuBPoG9J-e4Rw50=.914a54f6-f2f8-491d-b2af-e84dfdc5967b@github.com>
Message-ID: <VGQr31w5XCEGxU-lbd_zGJcOXLvpCJUHSlr7ljHa5bA=.6f6bf6ce-4af3-4171-a59c-4d672cc271d2@github.com>

On Wed, 29 Oct 2025 17:19:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> you can start the sanity/client/SwingSet/src/ToolTipDemoTest.java and check how smoothly mouse is moved on the screen.
> 
> > By the way, I think it's worth comparing this to some other API, like Jemmy, which is used in the sanity testsuite. It implements a nice mouse movement with acceleration and deceleration to demonstrate the tooltips. Just to think about other ways to implement sliding.

@mrserb I see where `ToolTipDemoTest.java` uses Jemmy's mouse movement now, thanks. However, since the current implementation is functional and is what the tests are working with, I'd prefer to keep the current implementation of `glide` as is for now.

If the mouse movement used in Jemmy really does turn out to be preferred, we can make a future update to the mouse movement implementation since it does not seem to need any API doc changes. It would be a simple implementation update so I don't see any difficulties with this down the line.

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

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

From prr at openjdk.org  Thu Oct 30 20:06:32 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 20:06:32 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
Message-ID: <9laKluorZwfx_Zo5zghvmrAWLqHloigB6eHhrWCcwW0=.7e8113ab-8c09-415b-861f-865d1da4959e@github.com>

On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann <duke at openjdk.org> wrote:

>> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
>> 
>> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.
>
> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
>  - Merge branch 'master' into pr/11266
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS

In the table above you have rows where the attribute set contains PageRanges(3, 5)
You record what page range you then "manually enter" into the dialog. 
But you aren't clear as to whether the initially displayed range in the dialog is 3,5
Since you are on macOS 26 and the issue reported as https://bugs.openjdk.org/browse/JDK-8341058 is supposed to be fixed by Apple in macOS 26 I'd expect it to be displayed as 3, 5 and for that to be the range printed unless  the user changes it.
Can you please clarify.

Note as I wrote in an old comment in this PR, this JBS issue title needed to be improved.
I've updated it and now you'll need to make the PR title match.

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

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3469863366
PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3469877228

From kizune at openjdk.org  Thu Oct 30 20:11:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 20:11:56 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v4]
In-Reply-To: <7oc1fcfvSu1R2nYRDnHM26cy4UI0YEllg_Yuw7DZBNk=.11f9b395-561f-474d-afb6-23c74f9724cb@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
 <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>
 <GBb9Q6yNbJxx1M6v23WOdeZ8ssSzapYnmYSUII7Ccb8=.5a46ccc7-034b-4395-91be-043f8c86fec1@github.com>
 <sL8qrf-pDRIRSK33jsagrb7ev_LUfYOBldsMH6_MHNE=.3ed83df1-d411-4667-84c8-a26d7993207b@github.com>
 <7oc1fcfvSu1R2nYRDnHM26cy4UI0YEllg_Yuw7DZBNk=.11f9b395-561f-474d-afb6-23c74f9724cb@github.com>
Message-ID: <1WF8JjMA36bT6WyQBIvY1-43DpwFXwkPuoqBAddxpvw=.3df2cd83-30b4-4a45-a09b-f6df20a2d4c8@github.com>

On Thu, 30 Oct 2025 02:11:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I just tested the latest version of the fix with the slightly modified test case (i added two extra menu items with 
>> `menuItem.setHorizontalTextPosition(SwingConstants.LEFT);`
>> and
>> `menuItem.setHorizontalTextPosition(SwingConstants.RIGHT);`
>> and it does not look exactly correct. Here's the screenshot:
>> <img width="331" height="511" alt="image" src="https://github.com/user-attachments/assets/8494241e-aefd-4259-bcb2-8b3cf2360d7d" />
>
> Fixed..it now looks ok to me...Please check
> 
> <img width="391" height="614" alt="image" src="https://github.com/user-attachments/assets/46661a18-947b-4483-969d-c7d05ace3ff0" />

Yes, new version works correctly. I would suggest to add these menu items to the regression test but that is optional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2479381292

From prr at openjdk.org  Thu Oct 30 20:12:51 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 20:12:51 GMT
Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL
 events when launched as subprocess [v2]
In-Reply-To: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com>
References: <uWgL0eCGLxkGigE-IPkEgbq2i3t-dHmAyyPmedZrgFA=.8ff131f6-bc00-4a1e-ada2-99346bae1220@github.com>
 <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com>
Message-ID: <uM2ltW52fUeMKt_-ZzVbvqWkbwprZsDiuEMbglTpnp4=.11ee5aad-d5ee-40e1-89f2-64feb916d753@github.com>

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

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

I'm happy to integrate as it is.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25967#pullrequestreview-3401450671

From kizune at openjdk.org  Thu Oct 30 20:11:54 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 20:11:54 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v4]
In-Reply-To: <FnXAylkbqdAUiCLAst9PmQEjvitklaJNb7O67BY2C2c=.ce6f7ff7-26f5-4f63-8e84-5754eab9a734@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <FnXAylkbqdAUiCLAst9PmQEjvitklaJNb7O67BY2C2c=.ce6f7ff7-26f5-4f63-8e84-5754eab9a734@github.com>
Message-ID: <fLZ0IpQTOI_7cDIkouplaYxPSvltLz4rWnVBs7pV9mQ=.2ce886f5-9ce1-4c54-bfa5-dd3eabb1aad7@github.com>

On Thu, 30 Oct 2025 02:16:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
>> 
>> Before fix
>> 
>> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
>> 
>> With fix
>> 
>> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SwingConstants LEFT and RIGHT fix

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27968#pullrequestreview-3401446123

From prr at openjdk.org  Thu Oct 30 20:11:59 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 20:11:59 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v7]
In-Reply-To: <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>
Message-ID: <CKeF4rr7_-dlAO1c-GNcHvtsDgPO67HTpNi1W9tYZzE=.cd966737-c63b-4140-b380-dfaceea7b7f6@github.com>

On Fri, 22 Aug 2025 22:53:28 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>> 
>> ### Describing This Bug
>> 
>> The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here.
>> 
>> All three frames in the unit test's GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous.
>> 
>> The first frame produces 3 circles from left to right using these colors:
>> 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green)
>> 
>> The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is:
>> 
>> <img width="200" height="100" alt="frame_0" src="https://github.com/user-attachments/assets/8bb53530-fc2b-4a8b-b3a6-5c58782ea5ab" />
>> 
>> Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index.
>> 
>> When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers.
>> 
>> The 2nd frame, after being painted on the 1st frame, looks like:
>> <img width="200" height="100" alt="frame_1" src="https://github.com/user-attachments/assets/0c8ca55b-e25d-418e-bb95-2e6f9e427c08" />
>> ?
>> The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is:
>> 
>> <img width="200" height="100" alt="frame_2_awt" src="https://github...
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - 8357034: switch to `isSavedModelReliable`
>    
>    This reduces how often we resort to "the hard way". The previous implementation would resort to the hard way *any* time the disposal code was SAVE and there was a transparent pixel in use.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264/files#r2292318270
>  - Merge branch 'master' into JDK-8357034
>  - 8357034: re-wrapping line breaks
>  - 8356137, 8357034: add debug option to dump PNGs of frames
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
>  - Merge branch 'master' into JDK-8357034
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>  - Merge branch 'master' into JDK-8357034
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/57553ca1...e7796df0

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25264#pullrequestreview-3401446230

From azvegint at openjdk.org  Thu Oct 30 21:04:19 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 30 Oct 2025 21:04:19 GMT
Subject: RFR: 8316274:
 javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu
 23.10 with Motif LAF [v3]
In-Reply-To: <Slqh5oKDZNcQC2IqErFmtus3AAXsb-4z0-5SPD32Ci8=.808a3e9f-aac2-4c5d-a685-9e840ef99722@github.com>
References: <G89zthFdpfFhXB2XBzzGNrFuVsk3kwKaS81RasyAN_Q=.b94230fb-6343-4a2e-9032-345890a02cb6@github.com>
 <axbF90mcX_ee9_KA3u-yEZ3Fk61Hsu2ntDI7GscXYjE=.c090a49f-29eb-49e4-9482-f6c80768af36@github.com>
 <KSC05BmHbeO_FTXzMPkjH6mKKv8d7AVGnFO1NUHEvac=.b13574cb-2073-44a5-930c-b332d5ecd976@github.com>
 <FteAJGGvpZR-kWvvR-FWFkRC7KQRjX1dvMc8ZNWKIyo=.eef59d2c-8fa9-4cf3-afb2-793e793c51ee@github.com>
 <Slqh5oKDZNcQC2IqErFmtus3AAXsb-4z0-5SPD32Ci8=.808a3e9f-aac2-4c5d-a685-9e840ef99722@github.com>
Message-ID: <oVRzxlO8IC-LY8mi8VGhA8LPCm-2zOHgZRRSDMObyko=.1715761a-e294-42d6-8723-cfb22b1f25a6@github.com>

On Thu, 30 Oct 2025 19:33:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > It is not clear yet.
> 
> So this test patch will be reverted once JDK-8370627 is integrated?

It can be reverted, but I think it's better to use toggle buttons without captions in this case.
This will produce the same visual appearance, even after JDK-8370624 is fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27979#issuecomment-3470217531

From prr at openjdk.org  Thu Oct 30 21:17:50 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Oct 2025 21:17:50 GMT
Subject: RFR: 8370637: [Windows] Crash if use Graphics after PrintJob.end
 [v2]
In-Reply-To: <w6H8BDyH3Ual_pcy2T_rJoaxk4y-0G_wlrPEShI9cRU=.e7cdbaa8-38a7-4605-ba8c-5a8385e261f2@github.com>
References: <w6H8BDyH3Ual_pcy2T_rJoaxk4y-0G_wlrPEShI9cRU=.e7cdbaa8-38a7-4605-ba8c-5a8385e261f2@github.com>
Message-ID: <DGnPN_7R9H6vUJzMc4JeWjmoUd6t2hzf61a5DcjSpZQ=.270a1ea1-f4ba-42e0-800d-f1bae7762664@github.com>

> Synchronize WPrinterJob calls which use the printDC to avoid crash in case of mis-use.
> The printerDC is released when the job ends. 
> It is zero-ed out in the handle in which it is stored
> The calls which expect it to be valid now all check for zero and return if it is zero.
> The calls are made synchronized as is the call to endDoc which zeroes it, so that they cannot have it zeroed out whilst using it.
> 
> The tests are the same as in the fix for JDK-8370141 which is also under review.
> Which ever is 2nd to be pushed will have to merge in the changes from the first

Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - 8370637
 - 8370637
 - Merge
 - 8370637

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

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

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

From kizune at openjdk.org  Thu Oct 30 21:57:08 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 30 Oct 2025 21:57:08 GMT
Subject: RFR: 8370719: [Linux] Use /etc/os-release values for font
 configuration file names
In-Reply-To: <PZKplDqUxD8Z2EQKVpYYB8lQKuoafomUIvla1cFgmj0=.56d454e8-d6ea-4db5-802b-84fa528147a8@github.com>
References: <PZKplDqUxD8Z2EQKVpYYB8lQKuoafomUIvla1cFgmj0=.56d454e8-d6ea-4db5-802b-84fa528147a8@github.com>
Message-ID: <GYfmQJZBAJmNEJf-R8LbvZ6JB2nAz8BK_OpfJQ28vKU=.c2fe4f0c-6044-4fe5-b6b9-32dbecc502ed@github.com>

On Thu, 30 Oct 2025 19:07:04 GMT, Phil Race <prr at openjdk.org> wrote:

> The JBS issue has a long discussion and explanation but here's a short version.
> Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux
> use the standard ID and VERSION_ID fields in /etc/os-release which is now standard.
> even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release
> And if it doesn't we just use "Linux" as the name.

Marked as reviewed by kizune (Reviewer).

Changes looks reasonable and i checked that there is no usage of osVersion not guarded by the null check because right now of the /etc/os-release is not readable the value i think will be left as null? But anyways the code that uses it assumes that it can be null so all is well in this department. At the time i wrote this comment the CSR issue is still being filled in - i will take another look tomorrow.

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

PR Review: https://git.openjdk.org/jdk/pull/28073#pullrequestreview-3401796804
PR Comment: https://git.openjdk.org/jdk/pull/28073#issuecomment-3470409290

From honkar at openjdk.org  Thu Oct 30 23:01:17 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 30 Oct 2025 23:01:17 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v4]
In-Reply-To: <FnXAylkbqdAUiCLAst9PmQEjvitklaJNb7O67BY2C2c=.ce6f7ff7-26f5-4f63-8e84-5754eab9a734@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <FnXAylkbqdAUiCLAst9PmQEjvitklaJNb7O67BY2C2c=.ce6f7ff7-26f5-4f63-8e84-5754eab9a734@github.com>
Message-ID: <-0XGwqbYTDA9S9U3gqFv9WnARlFanRGEBvaDyam4uTg=.3a167974-c40d-4930-b8f8-a20b96405c29@github.com>

On Thu, 30 Oct 2025 02:16:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
>> 
>> Before fix
>> 
>> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
>> 
>> With fix
>> 
>> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   SwingConstants LEFT and RIGHT fix

Updated fix LGTM apart from minor test suggestions.

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

> 46: /*
> 47:  * @test id=windows
> 48:  * @bug 4211052 8370465

Instead of multiple separate jtreg tags for each LaF we can combine it using `@run` tags as below:

/*
...
...
 * @run main/manual RightLeftOrientation windows
 * @run main/manual RightLeftOrientation motif
 * @run main/manual RightLeftOrientation metal
 */

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27968#pullrequestreview-3401944709
PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2479710355

From honkar at openjdk.org  Thu Oct 30 23:01:18 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 30 Oct 2025 23:01:18 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v4]
In-Reply-To: <1WF8JjMA36bT6WyQBIvY1-43DpwFXwkPuoqBAddxpvw=.3df2cd83-30b4-4a45-a09b-f6df20a2d4c8@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
 <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>
 <GBb9Q6yNbJxx1M6v23WOdeZ8ssSzapYnmYSUII7Ccb8=.5a46ccc7-034b-4395-91be-043f8c86fec1@github.com>
 <sL8qrf-pDRIRSK33jsagrb7ev_LUfYOBldsMH6_MHNE=.3ed83df1-d411-4667-84c8-a26d7993207b@github.com>
 <7oc1fcfvSu1R2nYRDnHM26cy4UI0YEllg_Yuw7DZBNk=.11f9b395-561f-474d-afb6-23c74f9724cb@github.com>
 <1WF8JjMA36bT6WyQBIvY1-43DpwFXwkPuoqBAddxpvw=.3df2cd83-30b4-4a45-a09b-f6df20a2d4c8@github.com>
Message-ID: <-tgqLtUv8JYPwytUjmyLXfUtAuq8cZVOk1FeQmrDXEQ=.4d720a35-a503-4696-8028-75df0f1aee30@github.com>

On Thu, 30 Oct 2025 20:09:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Fixed..it now looks ok to me...Please check
>> 
>> <img width="391" height="614" alt="image" src="https://github.com/user-attachments/assets/46661a18-947b-4483-969d-c7d05ace3ff0" />
>
> Yes, new version works correctly. I would suggest to add these menu items to the regression test but that is optional.

As @azuev-java suggested, it might be a good idea to add the extra cases to the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2479716683

From duke at openjdk.org  Fri Oct 31 00:49:24 2025
From: duke at openjdk.org (duke)
Date: Fri, 31 Oct 2025 00:49:24 GMT
Subject: Withdrawn: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java'
 automatically failed on Windows 2025 x64 with message
 "Failed. Compilation failed: Compilation failed"
In-Reply-To: <WCblnM26Qwn3nBeMTF7K0kMgzIg-aggiAXUhOGtGoEk=.ed63569d-3b85-4415-a42b-1ba1c89860cf@github.com>
References: <WCblnM26Qwn3nBeMTF7K0kMgzIg-aggiAXUhOGtGoEk=.ed63569d-3b85-4415-a42b-1ba1c89860cf@github.com>
Message-ID: <mU6ul0AchmFpsFSgW5mTVGOTzIJcwQUo3e-cG3_MdxA=.a183eae2-e2a0-43ee-ab54-38ef47e4d326@github.com>

On Wed, 18 Jun 2025 19:28:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Compilation error on windows with `WindowsButtonUI` used. Replaced it with `BasicButtonUI` to maintain overriding the `paintText` method but this was not the same as Windows L&F buttons. I attempted to import `WindowsButtonUI` and extending it, but the class is `final`. Instead, I chose to add a LineBorder in the same way as when a Rectangle was drawn to keep the same test behavior. It seems the extra 1 pixel width is unnecessary now when testing, so the changes only include removing `MyButtonUI` and adding a LineBorder.
> 
> This updated test now compiles and runs as expected. The test has all of the text within the blue button border. There does not seem to be any overlapping or out of bounds text as originally described with the original test.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Fri Oct 31 01:39:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 31 Oct 2025 01:39:04 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v5]
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <2E1x-7Q8kclj55YSHm3yKXUuoBfL45nT9j2uJ5xrigE=.6776c4f7-da05-4029-a94f-63126505e67b@github.com>

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

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

  Add LEFT, RIGHT textPosition to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27968/files
  - new: https://git.openjdk.org/jdk/pull/27968/files/ca4e1904..ccc2368e

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

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

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

From psadhukhan at openjdk.org  Fri Oct 31 01:39:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 31 Oct 2025 01:39:05 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v5]
In-Reply-To: <-tgqLtUv8JYPwytUjmyLXfUtAuq8cZVOk1FeQmrDXEQ=.4d720a35-a503-4696-8028-75df0f1aee30@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <iIPRlifWJY3R_1itQlWSn81_QCXTJaoDDnrnrjPNONk=.ce6b60dd-3730-4fde-80fb-d8ff0e095259@github.com>
 <K4tImZCOmst1BVtqAEQs4KRoKFrgFE56_xxePF2xqdA=.0342101d-21e7-4190-b35b-423c2a07bd95@github.com>
 <GBb9Q6yNbJxx1M6v23WOdeZ8ssSzapYnmYSUII7Ccb8=.5a46ccc7-034b-4395-91be-043f8c86fec1@github.com>
 <sL8qrf-pDRIRSK33jsagrb7ev_LUfYOBldsMH6_MHNE=.3ed83df1-d411-4667-84c8-a26d7993207b@github.com>
 <7oc1fcfvSu1R2nYRDnHM26cy4UI0YEllg_Yuw7DZBNk=.11f9b395-561f-474d-afb6-23c74f9724cb@github.com>
 <1WF8JjMA36bT6WyQBIvY1-43DpwFXwkPuoqBAddxpvw=.3df2cd83-30b4-4a45-a09b-f6df20a2d4c8@github.com>
 <-tgqLtUv8JYPwytUjmyLXfUtAuq8cZVOk1FeQmrDXEQ=.4d720a35-a503-4696-8028-75df0f1aee30@github.com>
Message-ID: <rmBZOqaqh4KovOgqUgNRHFaGtRpSchfJRRTU1rGbc0k=.9d3f2e29-3be3-4dd1-a8b0-cb3e49bd13ad@github.com>

On Thu, 30 Oct 2025 22:55:42 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Yes, new version works correctly. I would suggest to add these menu items to the regression test but that is optional.
>
> As @azuev-java suggested, it might be a good idea to add the extra cases to the test.

Added the menu items
@azuev-java Please take a look

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2479929346

From psadhukhan at openjdk.org  Fri Oct 31 02:57:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 31 Oct 2025 02:57:03 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v4]
In-Reply-To: <-0XGwqbYTDA9S9U3gqFv9WnARlFanRGEBvaDyam4uTg=.3a167974-c40d-4930-b8f8-a20b96405c29@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <FnXAylkbqdAUiCLAst9PmQEjvitklaJNb7O67BY2C2c=.ce6f7ff7-26f5-4f63-8e84-5754eab9a734@github.com>
 <-0XGwqbYTDA9S9U3gqFv9WnARlFanRGEBvaDyam4uTg=.3a167974-c40d-4930-b8f8-a20b96405c29@github.com>
Message-ID: <BD7-V1HS2uNnL4bUsYtA7SemU6l9ETxwUobjFI7d1w0=.4bb41f54-b173-487e-9c89-d39fdf215cce@github.com>

On Thu, 30 Oct 2025 22:52:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   SwingConstants LEFT and RIGHT fix
>
> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 48:
> 
>> 46: /*
>> 47:  * @test id=windows
>> 48:  * @bug 4211052 8370465
> 
> Instead of multiple separate jtreg tags for each LaF we can combine it using `@run` tags as below:
> 
> /*
> ...
> ...
>  * @run main/manual RightLeftOrientation windows
>  * @run main/manual RightLeftOrientation motif
>  * @run main/manual RightLeftOrientation metal
>  */

We decided to use it that way in [[8346753](https://github.com/openjdk/jdk/pull/25907#top)](https://github.com/openjdk/jdk/pull/25907#issuecomment-3036103833) sometime back

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27968#discussion_r2480013415

From kizune at openjdk.org  Fri Oct 31 03:29:02 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 31 Oct 2025 03:29:02 GMT
Subject: RFR: 8370465: Right to Left Orientation Issues with MenuItem
 Component [v5]
In-Reply-To: <2E1x-7Q8kclj55YSHm3yKXUuoBfL45nT9j2uJ5xrigE=.6776c4f7-da05-4029-a94f-63126505e67b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
 <2E1x-7Q8kclj55YSHm3yKXUuoBfL45nT9j2uJ5xrigE=.6776c4f7-da05-4029-a94f-63126505e67b@github.com>
Message-ID: <YH1-Po5Ihyc5nGfXLgl7saVrv-KMp9wdTr_--Jkyj5I=.11240989-d73a-4db5-b0c8-2d9ab04b9b69@github.com>

On Fri, 31 Oct 2025 01:39:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
>> 
>> Before fix
>> 
>> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
>> 
>> With fix
>> 
>> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add LEFT, RIGHT textPosition to test

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27968#pullrequestreview-3402457913

From psadhukhan at openjdk.org  Fri Oct 31 03:37:13 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 31 Oct 2025 03:37:13 GMT
Subject: Integrated: 8370465: Right to Left Orientation Issues with MenuItem
 Component
In-Reply-To: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
References: <Mjw5gptI2rVZeTs9E7puISiBSP3spzgKk3L9hn2Cwqk=.510f189c-9d74-41f1-915e-0df3d3567f6b@github.com>
Message-ID: <AxnLAYDrYTU5wpHM-42mpN4LvnmvQwZh3QZqPXtX6Js=.a6987f7e-9972-4634-ae87-98791f6ce23c@github.com>

On Fri, 24 Oct 2025 04:21:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Icon rendering offset is wrong for RTL orientation which is why the icon was not rendered properly..Also, LEADING horizontal text position was not accounted for..
> 
> Before fix
> 
> <img width="386" height="487" alt="image" src="https://github.com/user-attachments/assets/d33140e0-85f1-471c-abf4-bfc7992cd79e" />
> 
> With fix
> 
> <img width="384" height="491" alt="image" src="https://github.com/user-attachments/assets/9df65234-2b84-48ae-b85e-eefdbfbd544e" />

This pull request has now been integrated.

Changeset: fc5df4ac
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc5df4ac8f11f25611bd4def5b655578af27c882
Stats:     37 lines in 3 files changed: 31 ins; 0 del; 6 mod

8370465: Right to Left Orientation Issues with MenuItem Component

Reviewed-by: kizune, honkar

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

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

From dnguyen at openjdk.org  Fri Oct 31 16:30:17 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 31 Oct 2025 16:30: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: <lgMuYZu-u-m5YOXtmdtzhxJDHni2kcdGCeauROVH_ag=.8806ee68-e02a-4de1-bc56-7b3fe1afc566@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".

Double-checked this myself and it passes. Does `FrameLocation` need to be added to the PL then?

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

Marked as reviewed by dnguyen (Committer).

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

From dgredler at openjdk.org  Fri Oct 31 17:25:48 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 31 Oct 2025 17:25:48 GMT
Subject: RFR: 8371066: Remove unused class TextSourceLabel and associated class
 hierarchy
Message-ID: <g1Z44cRZrsPVco5cV1Ux2vQMb6IPuLq6JmIDliZ7-Uw=.3059ff68-582d-45ac-a582-5c11589a87bf@github.com>

The class `TextSourceLabel` is unused, as is the associated factory method `TextLabelFactory.createSimple(...)`.

The abstractions provided by the abstract classes `TextLabel` and `ExtendedTextLabel` only make sense when there are two types of text labels (`TextSourceLabel` and `ExtendedTextSourceLabel`). With the deletion of `TextSourceLabel`, both `TextLabel` and `ExtendedTextLabel` can also be removed.

The JavaDoc for the abstract methods in `TextLabel` and `ExtendedTextLabel`, which are implemented in `ExtendedTextSourceLabel`, was moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes.

The few small convenience methods in `TextLabel` and `ExtendedTextLabel` were also moved to `ExtendedTextSourceLabel` prior to the deletion of these two classes.

I would have liked to give the combined `TextLabel` + `ExtendedTextLabel` + `ExtendedTextSourceLabel` class the name `TextLabel`, but I've used `ExtendedTextSourceLabel` instead because it makes the diff much smaller and maximizes code history traceability.

See initial mailing list discussion: https://mail.openjdk.org/pipermail/client-libs-dev/2025-September/032302.html

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

Commit messages:
 - Combine TextLabel + ExtendedTextLabel + ExtendedTextSourceLabel -> ExtendedTextSourceLabel
 - Delete unused class sun.font.TextSourceLabel

Changes: https://git.openjdk.org/jdk/pull/28090/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28090&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371066
  Stats: 649 lines in 7 files changed: 137 ins; 480 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/28090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28090/head:pull/28090

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

From markyag at gmail.com  Fri Oct 31 18:34:32 2025
From: markyag at gmail.com (Mark Yagnatinsky)
Date: Fri, 31 Oct 2025 14:34:32 -0400
Subject: a last-minute plea to reconsider JEP 504: removing the applet API
 breaks non-applets
Message-ID: <CAPbNvUyzeBS29yRkzUFgnXBVCG5xsZMWn8nYo+b0M6EJ=8gW5A@mail.gmail.com>

In the olden days, it was pretty common to make apps that supported two
launch modes:
1. entry point in main() created its own window using JFrame or whatever.
2. But also extend Applet so as to run in the browser.

These days, the second mode no longer works because no browser supports
applets.
But the first mode still works fine.  It would STOP working if the applet
API were removed.
(In particular, class loading would fail if the JVM can't find the parent
class.)

Normally, when we talk about removing APIs, there is a simple bit of
messaging that goes something like this:
1. This is hopefully a simple code change (e.g., stop extending Applet,
since it does you no good anyway).
2. If you're not ready to make the code change, stay on an old version for
now
3. If you're not going to be ready soon, use an LTS release.

There's a cluster of vague implicit assumptions buried in such messaging,
such as:
1. The application is actively maintained, or at least there exists a
person or group of people nominally in charge of maintaining it.
2. The user and developer of the application are one and the same person,
or at least know each other or have some sort of business relationship or
SOMETHING.
3. In short, it assumes that if the application doesn't run, the developer
has some reason to care.  If the developer doesn't care, it's presumably
because the app has no users and hence nobody cares.

In the case of the applet API, this is all largely false.
There are people who once upon a time put a cute little applet on the web,
and also made it runnable standalone.
If anyone happens to find this useful to them, then all the better, but
those people are not customers, just like someone is not your customer just
because they happen to read your blog.
In other words, if these cute little former applets stop working, the
original author has no incentive to care and might not even notice for many
years.

But even though these are all unmaintained, it does not mean they are
unused!
They may indeed have users, possibly users who find them indispensable!
But those users may not have access to the code, and may not be programmers
even if they did have access.
To those users, removing the applet API means that these apps no longer
work on the latest JDK, and they have no one to complain to.

For a while, they can stay on old JDK, but eventually this becomes harder
and harder as old JDK versions may not support new operating systems and
CPUs and stuff.
(Not everyone knows how to set up a VM and an emulator and stuff.)
Also, some people may be too nervous to run an old JVM that hasn't gotten
security updates in a long time.

Conversely, consider the cost of keeping these APIs.  They would still be
deprecated.
Nobody is filing bug reports against them, since they are unusable anyway.
They are not "literally free" but the maintenance burden for the OpenJDK
team should be only marginally higher than the maintenance burden of dead
code.

Thoughts?

Thanks,
Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251031/881e4803/attachment.htm>

From prr at openjdk.org  Fri Oct 31 20:20:11 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 31 Oct 2025 20:20:11 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v7]
In-Reply-To: <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>
Message-ID: <b8CaJMuSWx6JWVGGBpuPPHsTdY1b0b7nydwtCK6x0d8=.d45aa018-bf1b-4dac-a448-5b0ff43721aa@github.com>

On Fri, 22 Aug 2025 22:53:28 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>> 
>> ### Describing This Bug
>> 
>> The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here.
>> 
>> All three frames in the unit test's GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous.
>> 
>> The first frame produces 3 circles from left to right using these colors:
>> 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green)
>> 
>> The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is:
>> 
>> <img width="200" height="100" alt="frame_0" src="https://github.com/user-attachments/assets/8bb53530-fc2b-4a8b-b3a6-5c58782ea5ab" />
>> 
>> Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index.
>> 
>> When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers.
>> 
>> The 2nd frame, after being painted on the 1st frame, looks like:
>> <img width="200" height="100" alt="frame_1" src="https://github.com/user-attachments/assets/0c8ca55b-e25d-418e-bb95-2e6f9e427c08" />
>> ?
>> The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is:
>> 
>> <img width="200" height="100" alt="frame_2_awt" src="https://github...
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - 8357034: switch to `isSavedModelReliable`
>    
>    This reduces how often we resort to "the hard way". The previous implementation would resort to the hard way *any* time the disposal code was SAVE and there was a transparent pixel in use.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264/files#r2292318270
>  - Merge branch 'master' into JDK-8357034
>  - 8357034: re-wrapping line breaks
>  - 8356137, 8357034: add debug option to dump PNGs of frames
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
>  - Merge branch 'master' into JDK-8357034
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>  - Merge branch 'master' into JDK-8357034
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/57553ca1...e7796df0

hmm. Why is this PR not 'ready' ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25264#issuecomment-3474750486

From prr at openjdk.org  Fri Oct 31 21:02:06 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 31 Oct 2025 21:02:06 GMT
Subject: RFR: 8370467: BorderFactory.createBevelBorder and
 createSoftBevelBorder throws NPE for null highlight and shadow [v3]
In-Reply-To: <LnsNC4jxfbj_hTkDuSBf7u6i3gPTXwdD_202l01VjhE=.6170cec2-fe5a-4387-84be-7fe6a2db9797@github.com>
References: <qT1Uv2lZkk9y3Ncm6OY0v834gueeT3hO5RqUevPxlyo=.14aca7f0-26ff-4d72-af1c-2baef7de7aed@github.com>
 <LnsNC4jxfbj_hTkDuSBf7u6i3gPTXwdD_202l01VjhE=.6170cec2-fe5a-4387-84be-7fe6a2db9797@github.com>
Message-ID: <uGjvumx3iDU2Ylk_O2I9DNI5-LR3m_sSgi2zjjXdPGQ=.01b85184-c02d-4013-a34c-140e8d281628@github.com>

On Thu, 30 Oct 2025 03:30:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If we pass null as highlight and shadow color to `BorderFactory.createBevelBorder` and `createSoftBevelBorder`
>> it throws NPE which is not mentioned in the spec as the expected outcome.
>> Fixed the NPE and the spec
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

src/java.desktop/share/classes/javax/swing/BorderFactory.java line 147:

> 145:      * the highlight color. The inner edge of the shadow area
> 146:      * uses a brighter shade of the shadow color.
> 147:      * If highlight and shadow color are null, then it will

The text above says that if both are null it will fall back. You don't mean that. 
You mean if either is null it will fall back.

This results in the colors all being null.

And I think you need to look further.
The NPE happens because BevelBorder does this
        this(bevelType, highlight.brighter(), highlight, shadow, shadow.brighter());

But the constructor it is calling is also public and will happily allow nulls for any specific case.
So perhaps the above constructor should be doing something like
((highlight != null) ? highlight.brighter : null)

src/java.desktop/share/classes/javax/swing/BorderFactory.java line 158:

> 156:      */
> 157:     public static Border createBevelBorder(int type, Color highlight, Color shadow) {
> 158:         if (highlight != null && shadow != null) {

What happens if type isn't a known type ?
Looks to me like no errors but no painting but I've not looked very closely.
Whatever we want should be specified everywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2482611678
PR Review Comment: https://git.openjdk.org/jdk/pull/27949#discussion_r2482622608

From prr at openjdk.org  Fri Oct 31 21:12:04 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 31 Oct 2025 21:12:04 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out [v8]
In-Reply-To: <2P9yAjeyFGmTJteDo7RN0EDAI4RES3hEWYvNVO19EmE=.60bc2c18-53ba-440c-9913-559167e964d8@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
 <2P9yAjeyFGmTJteDo7RN0EDAI4RES3hEWYvNVO19EmE=.60bc2c18-53ba-440c-9913-559167e964d8@github.com>
Message-ID: <DRRPRM_hcyowONKciXl0VQhM2FUsSpg3JnWmquhHoiM=.d84a7bd5-1f4b-417c-a345-f7663690ede0@github.com>

On Mon, 22 Sep 2025 14:48:36 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> The fix for the https://bugs.openjdk.org/browse/JDK-8251928.
>> 
>> **Description**.
>> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.
>> 
>> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
>> 1. Convert the user-space point, size, or rectangle value to device space coordinates;
>> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
>> 3. Convert the normalized value back to user space;
>> 4. Draw your content using the adjusted value. 
>>     
>> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
>> The 2-nd step is a drawing process in the java code (without changes).
>> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
>> The 4-th step is a drawing process in the native code (without changes).
>> 
>> **Tests**.
>> I run all tests from javax.print package and there is no any regression.
>> New test covers macOS and Linux only because we know its default DPI - 300.
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert PeekGraphics

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25489#pullrequestreview-3406180017

From jwood at openjdk.org  Fri Oct 31 21:26:45 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 31 Oct 2025 21:26:45 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v8]
In-Reply-To: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
Message-ID: <DsGk9TAi6dK5sfjDM8yKngoNmjanUzjDcEzNun-rNKY=.a04b3aee-910d-40d9-9080-55fa1ccb3f92@github.com>

> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
> 
> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
> 
> There are a cluster of four related PRs that share the GifComparison class in this PR.
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
> 
> This bug can be observed reading these gif animations:
> 
> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
> 
> ### Describing This Bug
> 
> The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here.
> 
> All three frames in the unit test's GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous.
> 
> The first frame produces 3 circles from left to right using these colors:
> 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green)
> 
> The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is:
> 
> <img width="200" height="100" alt="frame_0" src="https://github.com/user-attachments/assets/8bb53530-fc2b-4a8b-b3a6-5c58782ea5ab" />
> 
> Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index.
> 
> When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers.
> 
> The 2nd frame, after being painted on the 1st frame, looks like:
> <img width="200" height="100" alt="frame_1" src="https://github.com/user-attachments/assets/0c8ca55b-e25d-418e-bb95-2e6f9e427c08" />
> ?
> The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is:
> 
> <img width="200" height="100" alt="frame_2_awt" src="https://github.com/user-attachments/assets/835dd918-f1bc-459e-9967-295fd01fa61c" />
> 
> Because it'...

Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Merge branch 'master' into JDK-8357034
 - 8357034: switch to `isSavedModelReliable`
   
   This reduces how often we resort to "the hard way". The previous implementation would resort to the hard way *any* time the disposal code was SAVE and there was a transparent pixel in use.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25264/files#r2292318270
 - Merge branch 'master' into JDK-8357034
 - 8357034: re-wrapping line breaks
 - 8356137, 8357034: add debug option to dump PNGs of frames
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
 - Merge branch 'master' into JDK-8357034
   
   # Conflicts:
   #	test/jdk/sun/awt/image/gif/GifBuilder.java
   #	test/jdk/sun/awt/image/gif/GifComparison.java
 - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
 - Merge branch 'master' into JDK-8357034
 - 8356320: Use new GifBuilder and remove ukraine-flag.gif
   
   This is an extension of work for this PR:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: adding copyright
 - ... and 25 more: https://git.openjdk.org/jdk/compare/1781b186...ece8707a

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

Changes: https://git.openjdk.org/jdk/pull/25264/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=07
  Stats: 147 lines in 5 files changed: 112 ins; 4 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/25264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25264/head:pull/25264

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