From kizune at openjdk.org  Sun Feb  1 04:41:00 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Sun, 1 Feb 2026 04:41:00 GMT
Subject: RFR: 8376755: Remove AppContext from Swing javax/swing/plaf/basic
 classes
In-Reply-To: <0AjFtP2_UXLP6zBNsu4hGWJHwOrD7Qit0klcwMtemWA=.e0d35933-90ad-456d-8313-bd9c18e954ca@github.com>
References: <0AjFtP2_UXLP6zBNsu4hGWJHwOrD7Qit0klcwMtemWA=.e0d35933-90ad-456d-8313-bd9c18e954ca@github.com>
Message-ID: <Wk7WKef-a5LOedNOvU0jlSWJp3RnXOboXFWvU8j-ulY=.c5efe6ea-9d0f-43d5-94ce-a4cf9c4be220@github.com>

On Thu, 29 Jan 2026 23:02:45 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from the Swing basic plaf package
> One test is updated to use the now non-appcontext internal variables.

LGTM

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29495#pullrequestreview-3734936496
PR Review: https://git.openjdk.org/jdk/pull/29495#pullrequestreview-3734936676

From prr at openjdk.org  Sun Feb  1 19:22:11 2026
From: prr at openjdk.org (Phil Race)
Date: Sun, 1 Feb 2026 19:22:11 GMT
Subject: Integrated: 8376755: Remove AppContext from Swing
 javax/swing/plaf/basic classes
In-Reply-To: <0AjFtP2_UXLP6zBNsu4hGWJHwOrD7Qit0klcwMtemWA=.e0d35933-90ad-456d-8313-bd9c18e954ca@github.com>
References: <0AjFtP2_UXLP6zBNsu4hGWJHwOrD7Qit0klcwMtemWA=.e0d35933-90ad-456d-8313-bd9c18e954ca@github.com>
Message-ID: <lShYOn4vDstPcGdhWD_k_lJndzWAcUtG6w5oRxPkoDY=.df1741ab-d4e3-4d43-b84f-888bba10af98@github.com>

On Thu, 29 Jan 2026 23:02:45 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from the Swing basic plaf package
> One test is updated to use the now non-appcontext internal variables.

This pull request has now been integrated.

Changeset: f4765abd
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4765abd7ef76108c1ae5777f2822800be22030e
Stats:     156 lines in 10 files changed: 5 ins; 103 del; 48 mod

8376755: Remove AppContext from Swing javax/swing/plaf/basic classes

Reviewed-by: dnguyen, kizune

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

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

From psadhukhan at openjdk.org  Mon Feb  2 01:28:19 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 2 Feb 2026 01:28:19 GMT
Subject: [jdk26] Integrated: 8376169: JPopupMenu.setInvoker(null) causes NPE
In-Reply-To: <kISpgbNmAqn6wvCA-7wiA0N9MvDZY5wB_YpQMY1aaHg=.c988e000-9b37-4db2-a279-b523a3411984@github.com>
References: <kISpgbNmAqn6wvCA-7wiA0N9MvDZY5wB_YpQMY1aaHg=.c988e000-9b37-4db2-a279-b523a3411984@github.com>
Message-ID: <JxysbK9kZxDr2khSsc5hitxT5hjLCHlBeBHvm1cD9_8=.109874d2-417a-41fe-b849-e97c39ff2b59@github.com>

On Thu, 29 Jan 2026 02:33:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> 8376169: JPopupMenu.setInvoker(null) causes NPE

This pull request has now been integrated.

Changeset: 21a3ed36
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21a3ed36d48f1d86e4d84eb0e84ccdbe4fd1a57e
Stats:     14 lines in 2 files changed: 10 ins; 0 del; 4 mod

8376169: JPopupMenu.setInvoker(null) causes NPE

Reviewed-by: aivanov, azvegint, kizune
Backport-of: 2529e2fe8dfe9685033bb0ae558266b8bc3cf95c

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

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

From psadhukhan at openjdk.org  Mon Feb  2 13:25:18 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 2 Feb 2026 13:25:18 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v2]
In-Reply-To: <Qxljkg21J8C0LpG2ATB_z_PdQl6wqkGQmaDR6I4BlzQ=.a66f3356-caab-46a2-b572-389c36e06273@github.com>
References: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com>
 <Qxljkg21J8C0LpG2ATB_z_PdQl6wqkGQmaDR6I4BlzQ=.a66f3356-caab-46a2-b572-389c36e06273@github.com>
Message-ID: <_bnlKFJ79S6haDS0hCUnnsl9cJ7__LSF1wldQGtv4oA=.f81dde97-a6c2-487e-9ea4-a031749ec066@github.com>

On Thu, 29 Jan 2026 00:33:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts:
>> 
>>  - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized.
>> 
>>  - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient.
>
> 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-6441373
>  - Update JTableSerialization.java
>  - 6441373: Editing JTable is not Serializable

Marked as reviewed by psadhukhan (Reviewer).

src/java.desktop/share/classes/javax/swing/JTable.java line 6011:

> 6009:         editorRemover = (PropertyChangeListener) f.get("editorRemover", null);
> 6010:         editingColumn = -1;
> 6011:         editingRow = -1;

Thanks for this ingenious solution

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

PR Review: https://git.openjdk.org/jdk/pull/29313#pullrequestreview-3739371304
PR Review Comment: https://git.openjdk.org/jdk/pull/29313#discussion_r2754312620

From jwood at openjdk.org  Mon Feb  2 17:26:36 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Mon, 2 Feb 2026 17:26:36 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box [v3]
In-Reply-To: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
Message-ID: <5p_S8bp_V4Ms_-zq2xOf7N8H7pCbPrync16_Th_cZTU=.cfda64c8-5f79-4a9a-ab89-a0b5bcb8429f@github.com>

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

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

  4197755: use directed inherit with getBounds()
  
  This is in response to darcy's comment:
  https://bugs.openjdk.org/browse/JDK-8374859

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26715/files
  - new: https://git.openjdk.org/jdk/pull/26715/files/de609581..d06c5669

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

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

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

From duke at openjdk.org  Mon Feb  2 18:36:56 2026
From: duke at openjdk.org (MrPowerGamerBR)
Date: Mon, 2 Feb 2026 18:36:56 GMT
Subject: RFR: 8280982: [Wayland] [XWayland] java.awt.Robot taking
 screenshots [v12]
In-Reply-To: <auVxv04EYiFDlMm71gvri4HjAdKEcEK5dGiZouI6T_c=.66ac608d-eac4-47bc-ac5d-2aff24c38dd9@github.com>
References: <c4dUjQifUu-lR3yTFxnXJ_10GravMCu5MpCc7SePqA0=.0251dd1b-c607-4924-ae3e-3bf1dfb42dc2@github.com>
 <auVxv04EYiFDlMm71gvri4HjAdKEcEK5dGiZouI6T_c=.66ac608d-eac4-47bc-ac5d-2aff24c38dd9@github.com>
Message-ID: <OUTPMlgXViXjZ0I7reiPmuVo2cZwxfgGkMeDRLKqWRM=.2c8fa967-f1a8-4c5e-92af-65175638b4af@github.com>

On Wed, 7 Jun 2023 10:36:19 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Modern Linux systems often come with [Wayland](https://wayland.freedesktop.org/) by default.
>> This comes with some difficulties, and one of them is the inability to get screenshots from the system.
>> This is because we now use the [X Window System API](https://en.wikipedia.org/wiki/X_Window_System) to capture screenshots and it cannot access data outside the [XWayland server](https://wayland.freedesktop.org/xserver.html) 
>> 
>> But this functionality is a very important part of automated testing.
>> 
>> 
>> At the moment there are two obvious solutions to this problem, and both use [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal):
>> 
>> 1. [org.freedesktop.portal.Screenshot DBUS API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Screenshot)
>> It has several drawbacks though:
>> + It saves a screenshot to disk, which must be read and deleted(may add some delays depending on the type of a disk drive).
>> + There is no way to disable the visual "screen flash" after screenshot
>> + It asks a user confirmation to save a screenshot. This confirmation can be saved on Gnome 43+. 
>> Since we would like Ubuntu 22.04 LTS which comes with Gnome 42 this option is not acceptable for us because it would require user confirmation for each screenshot.
>> But we still can consider this option as a fallback.
>> 
>> 
>> 
>> 2. [org.freedesktop.portal.ScreenCast](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.ScreenCast)
>> It typically used by applications that need to capture the contents of the user's screen or a specific window for the purpose of sharing, recording, or streaming.
>> This might be a bit of overkill, but it avoids several of the problems mentioned in the Screenshot API.
>> 
>> + implementation is more complicated comparing to Screenshot API
>> + no intermediate file, screenshot data can be obtained from memory
>> + Permission to make screenshots can be stored with [`restore_token`](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-ScreenCast.SelectSources)
>> 
>> 
>> So this PR adds the ability to take screenshots using the ScreenCast API. This functionality is currently disabled by default.
>> 
>> This change also introduces some new behavior for the robot:
>> A system window now appears asking for confirmation from the user to capture the screen.
>> + The user can refuse the screen capture completely. In this case a security exception will be thrown.
>> + The user can allow...
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Just a fyi for anyone that stumbles upon this PR trying to figure out how to screenshot in Wayland, but finds out that, even when using JDK 21+, the screenshots are still black: If you are using KDE Plasma with fractional scaling (I use 150%) the capture will always fail with


callbackScreenCastStart:745 available screen count 1
rebuildScreenData:116 
==== screenId#98
rebuildScreenData:161 -----------------------
rebuildScreenData:162 screenId#98
||	bounds         x     0 y     0 w  1707 h   960
||	capture area   x     0 y     0 w     0 h     0 shouldCapture 0

rebuildScreenData:163 #---------------------#

callbackScreenCastStart:751 rebuildScreenData result |0|
callbackScreenCastStart:764 restore_token |5b0f7d56-d05f-483e-a85a-99727b3a36f6|
storeRestoreToken:805 saving token, old: |16521d36-3b86-4b25-b990-319ce54e3283| > new: |5b0f7d56-d05f-483e-a85a-99727b3a36f6|
portalScreenCastStart:843 ScreenCastResult |0|
initAndStartSession:1116 portalScreenCastStart result |0|
checkCanCaptureAllRequiredScreens:991 Could not find required screen 0 0 2560 1440 in allowed bounds
getPipewireFd:1132 The location of the screens has changed, the capture area is outside the allowed area.
Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl:1036 Screencast attempt failed with -12, re-trying...


The reason is because it keeps trying to find the bounds with the "logical" resolution size (the size without any scaling) and it keeps failing because the Screencast API gives the scaled resolution size.

Using the default non-scaled resolution fixes the issue, but that's quite annoying so I think this should be reported on the bug tracker later.

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

PR Comment: https://git.openjdk.org/jdk/pull/13803#issuecomment-3836935621

From prr at openjdk.org  Mon Feb  2 20:01:19 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 20:01:19 GMT
Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for
 SinglePixelPackedSampleModel.getSampleSize(int) [v3]
In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com>
References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com>
Message-ID: <m5KDF8ILOVKS7QBF7GZO2835MQBykms4Wp7gcISo_z8=.9e1f8993-7c2d-4ae1-afc2-939976a4bb68@github.com>

> Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave.
> It isn't entirely pretty because 2 of them ignore the band parameter and always have ..

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

  8376297

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29457/files
  - new: https://git.openjdk.org/jdk/pull/29457/files/ebde5c8a..ea3124dd

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

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

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

From prr at openjdk.org  Mon Feb  2 20:01:23 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 20:01:23 GMT
Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for
 SinglePixelPackedSampleModel.getSampleSize(int) [v3]
In-Reply-To: <dxM-7RePzyRseB8xp4nZohFovsjfMSdFEuc-yTWF29Q=.e71ec67f-7e33-431e-81e7-12873efa32bf@github.com>
References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com>
 <dxM-7RePzyRseB8xp4nZohFovsjfMSdFEuc-yTWF29Q=.e71ec67f-7e33-431e-81e7-12873efa32bf@github.com>
Message-ID: <y_-1qWypibsZivhy7r_z-NQGK7EXXsLOZDrQxIH3IEg=.ebfd6ca8-565c-4ad7-878a-4158ed656be3@github.com>

On Thu, 29 Jan 2026 18:50:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8376297
>
> test/jdk/java/awt/image/GetSampleSizeTest.java line 1:
> 
>> 1: /*
> 
> I suggest creating `test-` methods rather than using a code block inside the `main` method and call the methods from main, it would make the code better structured and convey the intent clearer.

I don't think it needs multiple methods.
I didn't really need to do even the { .. } but it made it easier to make sure of not re-using the var names.

> test/jdk/java/awt/image/GetSampleSizeTest.java line 47:
> 
>> 45:             ComponentSampleModel csm =
>> 46:             new ComponentSampleModel(DataBuffer.TYPE_BYTE,
>> 47:                   width, height, 1, width, bandOffsets);
> 
> Suggestion:
> 
>             ComponentSampleModel csm =
>                     new ComponentSampleModel(DataBuffer.TYPE_BYTE,
>                           width, height, 1, width, bandOffsets);
> 
> Indent the continuation lines by 8 spaces which is the standard indentation for continuation lines.

ok

> test/jdk/java/awt/image/GetSampleSizeTest.java line 59:
> 
>> 57:             MultiPixelPackedSampleModel mppsm =
>> 58:                 new MultiPixelPackedSampleModel(DataBuffer.TYPE_BYTE,
>> 59:                  width, height, 4);
> 
> Suggestion:
> 
>             MultiPixelPackedSampleModel mppsm =
>                     new MultiPixelPackedSampleModel(DataBuffer.TYPE_BYTE,
>                             width, height, 4);
> 
> Indent the continuation lines by 8 spaces

I removed the line break instead

> test/jdk/java/awt/image/GetSampleSizeTest.java line 72:
> 
>> 70:                 new SinglePixelPackedSampleModel(DataBuffer.TYPE_BYTE,
>> 71:                         width, height, bitMask);
>> 72:                 int numBands = sppsm.getNumBands();
> 
> Suggestion:
> 
>             SinglePixelPackedSampleModel sppsm  =
>                     new SinglePixelPackedSampleModel(DataBuffer.TYPE_BYTE,
>                             width, height, bitMask);
>             int numBands = sppsm.getNumBands();
> 
> Indent the continuation lines by 8 spaces; `numBands` isn't a continuation line, and it should align to `SinglePixelPackedSampleModel` declaration.

fixed int numBands, removed line break from the constructor parameter list

> test/jdk/java/awt/image/GetSampleSizeTest.java line 76:
> 
>> 74:             if (numBands != 4) {
>> 75:                 throw new RuntimeException("Unexpected numBands");
>> 76:     }
> 
> Suggestion:
> 
>             if (numBands != 4) {
>                 throw new RuntimeException("Unexpected numBands");
>             }
> 
> Misaligned closing brace.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743954454
PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743950893
PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743946838
PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743944431
PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2743940310

From prr at openjdk.org  Mon Feb  2 20:01:26 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 20:01:26 GMT
Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for
 SinglePixelPackedSampleModel.getSampleSize(int) [v2]
In-Reply-To: <wSCBhttL7kknPV3Cess09WjELssUCVR0MpqExrylmXA=.3f4793d3-0e85-4ee0-b84e-a958e5d599b9@github.com>
References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com>
 <ax-A2ZZGba7IHXNN1zEYN7WQPdg_DTeaTrrdxQtlXYY=.1ab2be11-1375-4723-a033-22d1ee41925a@github.com>
 <wSCBhttL7kknPV3Cess09WjELssUCVR0MpqExrylmXA=.3f4793d3-0e85-4ee0-b84e-a958e5d599b9@github.com>
Message-ID: <ES1FEvuw0yWceV7cIsZrX6BRn04R1BDt16toeUjBwmw=.a70c40c4-c2bb-44ee-a258-be1585375f78@github.com>

On Fri, 30 Jan 2026 13:00:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8376297
>
> test/jdk/java/awt/image/GetSampleSizeTest.java line 47:
> 
>> 45:             ComponentSampleModel csm =
>> 46:                 new ComponentSampleModel(DataBuffer.TYPE_BYTE,
>> 47:                         width, height, 1, width, bandOffsets);
> 
> I still think the lines 46?47 should be indented by 4 more spaces: either is a continuation line of the line above.
> 
> 
> Suggestion:
> 
>             ComponentSampleModel csm =
>                     new ComponentSampleModel(DataBuffer.TYPE_BYTE,
>                             width, height, 1, width, bandOffsets);
> 
> 
> However, the indentation is somewhat consistent now: lines 58 and 69 are also indented by 4 spaces only. Yet they should be indented by 8 spaces.

I don't know where this 8 spaces rule came from and I thought you meant it for the 2nd or later continuation line, not for the first. 
My preferred style is to always indent 4 more except I like to line up the arg lists vertically.

> test/jdk/java/awt/image/GetSampleSizeTest.java line 75:
> 
>> 73:                 throw new RuntimeException("Unexpected numBands");
>> 74:         }
>> 75:             try {
> 
> Suggestion:
> 
>             if (numBands != 4) {
>                 throw new RuntimeException("Unexpected numBands");
>             }
>             try {
> 
> The brace that closes the `if` block is still indented incorrectly, it should be in the same column as `i` and `t` of `if` above and `try` below.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2755945238
PR Review Comment: https://git.openjdk.org/jdk/pull/29457#discussion_r2755944985

From prr at openjdk.org  Mon Feb  2 20:14:04 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 20:14:04 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
Message-ID: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>

Remove AppContext from java/awt/SystemTray

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

Commit messages:
 - 8376992

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

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

From prr at openjdk.org  Mon Feb  2 20:20:45 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 20:20:45 GMT
Subject: RFR: 8376994: Remove AppContext from
 sun/awt/datatransfer/DataTransferer.java
Message-ID: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>

Remove AppContext from sun/awt/datatransfer/DataTransferer.java

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

Commit messages:
 - 8376994

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

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

From prr at openjdk.org  Mon Feb  2 20:24:12 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 20:24:12 GMT
Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal
 classes [v2]
In-Reply-To: <St2y0VKNxNBZIXon-3AysUoPwHF9HJBOL9HhzFyTnn8=.8b3f2112-b65e-4de5-801b-d12da96fad73@github.com>
References: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
 <ngd2K0HyYjUkBQhaT_4eGdhhriuNdBZ4U8Veb6Yujcw=.c8523b46-0148-4c0c-9396-4e2c89665605@github.com>
 <St2y0VKNxNBZIXon-3AysUoPwHF9HJBOL9HhzFyTnn8=.8b3f2112-b65e-4de5-801b-d12da96fad73@github.com>
Message-ID: <7ke0m-SnpLCsJuSdnYzeaZfvK_xDoMPRUGfaXctIEtk=.9ee5c49c-9a1a-43bc-8975-ee6af3b14165@github.com>

On Thu, 29 Jan 2026 00:01:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8376627
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBumps.java line 52:
> 
>> 50:     protected Color backColor;
>> 51: 
>> 52:     private static final List<BumpBuffer> BUMPS_LIST = new ArrayList<BumpBuffer>();
> 
> This doesn?t seem to be a constant, does it? I think at some point we should implement some kind of cleanup logic for this list.

The list is constant. The contents are added to.
I suppose (some day) something like a soft ref could be used, but I am not sure that there will ever be stale members to make it worthwhile or appropriate.
Either way, out of scope for this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29474#discussion_r2756014560

From prr at openjdk.org  Mon Feb  2 21:04:24 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 21:04:24 GMT
Subject: RFR: 8376996: Remove AppContext usage from SunClipboard.java
Message-ID: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>

Remove AppContext from SunClipboard.

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

Commit messages:
 - 8376996

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

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

From prr at openjdk.org  Mon Feb  2 21:13:29 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 21:13:29 GMT
Subject: RFR: 8376998: [macOS] Remove AppContext from AppEventHandler
Message-ID: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>

This removes AppContext from the _AppEventHandler class used on macOS.

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

Commit messages:
 - 8376998
 - 8376998

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

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

From prr at openjdk.org  Mon Feb  2 21:13:31 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 21:13:31 GMT
Subject: RFR: 8376998: [macOS] Remove AppContext from AppEventHandler
In-Reply-To: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
References: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
Message-ID: <ZAEYmzf0BW7VyNajUZH0wFuG5ewdxlwhH7dRDUDlFNo=.222e1d7f-0ca3-411f-bec4-28e13fec979b@github.com>

On Mon, 2 Feb 2026 21:05:37 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes AppContext from the _AppEventHandler class used on macOS.

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 541:

> 539:     }
> 540: 
> 541:      public static void invokeLater(Runnable dispatcher) {

Eventually invokeLaterOnAppContext will be completely replaced by this once nothing needs it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29534#discussion_r2756126559

From kizune at openjdk.org  Mon Feb  2 21:26:47 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 2 Feb 2026 21:26:47 GMT
Subject: RFR: 8375057: Update HarfBuzz to 12.3.2
In-Reply-To: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com>
References: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com>
Message-ID: <sKiTUaKXxdxL99kF_e8vcfrIA-Nn2d5kP9WP2O1R6hA=.875358fe-b8a4-4cb0-8706-2948332b489e@github.com>

On Thu, 29 Jan 2026 00:32:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> HarfBuzz updated to 12.3.2
> 
> 2 new files
> 1 renamed file
> 170 updated files

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29475#pullrequestreview-3741742549

From prr at openjdk.org  Mon Feb  2 21:29:42 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 21:29:42 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box [v3]
In-Reply-To: <5p_S8bp_V4Ms_-zq2xOf7N8H7pCbPrync16_Th_cZTU=.cfda64c8-5f79-4a9a-ab89-a0b5bcb8429f@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
 <5p_S8bp_V4Ms_-zq2xOf7N8H7pCbPrync16_Th_cZTU=.cfda64c8-5f79-4a9a-ab89-a0b5bcb8429f@github.com>
Message-ID: <MuKEDpp6c5I1zZWnIMLxxhWaxyVXCzeNvqr0s_-f1Rk=.c70c533d-0016-47a6-a35a-ac213b063ac0@github.com>

On Mon, 2 Feb 2026 17:26:36 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.
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4197755: use directed inherit with getBounds()
>   
>   This is in response to darcy's comment:
>   https://bugs.openjdk.org/browse/JDK-8374859

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26715#pullrequestreview-3741749638

From prr at openjdk.org  Mon Feb  2 21:32:30 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 2 Feb 2026 21:32:30 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <4T5cSAaROTH9gsM3k0xeQxujShyN7JaW_E6TCewGTjY=.0349f633-1b2f-439b-a09d-7de741f794ac@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
 <ZY7Mirv_R2UiSTGphyP1tF763ZELVzWOZMJmIkGiGso=.70febef7-9824-4db6-96f9-7ea79c3828e9@github.com>
 <uDJcqvMy9l9x-AlJcJ9e5iPH1If2EvmAYJ-wfzEq6bY=.8973bffa-3888-4769-b9a5-9befde1215f2@github.com>
 <4T5cSAaROTH9gsM3k0xeQxujShyN7JaW_E6TCewGTjY=.0349f633-1b2f-439b-a09d-7de741f794ac@github.com>
Message-ID: <nHjC1MVGtEz9EjDB49MT4RARI6gKFKbgrckCa8uDXf8=.c0076cb6-9dd1-4071-8b9f-9a0f4b6b6347@github.com>

On Fri, 30 Jan 2026 12:53:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> @ThomasDevoogdt A PR isn't announced on the mailing list until it's _ready for review_ which includes a valid JBS bug.
>>> 
>>> I suggest you write an email to build-dev and client-libs-dev mailing lists to propose this change and discuss it. I haven't found an existing issue in JBS for not requiring X11 libraries in headless mode. I can submit one on your behalf.
>>> 
>>> If I have time, I'll test your patch locally and run it in the Oracle CI.
>> 
>> All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress.
>
>> > If I have time, I'll test your patch locally and run it in the Oracle CI.
>> 
>> All our build systems have X11. So a test build there doesn't prove much, and also it can easily regress.
> 
> This is why I'm going to use a VM which doesn't have X11 headers installed.
> 
>> is that a reason to not merge this kind of code?
> 
> I think it's a good change. Looking at the history at which @dholmes-ora pointed, building headless JDK without X11 was supported, but it has become broken again.

I am fine with this (once @aivanov-jdk has done the test build). I am just pointing out that it has apparently regressed before so could regress again because this configuration is not part of our testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3837497493

From dnguyen at openjdk.org  Mon Feb  2 21:56:02 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 2 Feb 2026 21:56:02 GMT
Subject: Integrated: 8375057: Update HarfBuzz to 12.3.2
In-Reply-To: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com>
References: <4VKAIWM9Ud-2zdY7NhEw1dCek4mTTVPC3tx_6HAKARE=.e03f6f17-ff2a-408f-bd50-f071b296dce3@github.com>
Message-ID: <C2TuCeEALi-5xW6A1GDL84nEJ41OK9O1WPI8U4PCZUM=.eb482f61-0cd9-449a-920c-c02970b797c3@github.com>

On Thu, 29 Jan 2026 00:32:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> HarfBuzz updated to 12.3.2
> 
> 2 new files
> 1 renamed file
> 170 updated files

This pull request has now been integrated.

Changeset: 4db0f7f2
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4db0f7f29154d6618c63a30ef2a86267c842ebb3
Stats:     14888 lines in 173 files changed: 5161 ins; 3058 del; 6669 mod

8375057: Update HarfBuzz to 12.3.2

Reviewed-by: prr, kizune

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

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

From serb at openjdk.org  Mon Feb  2 23:14:36 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 2 Feb 2026 23:14:36 GMT
Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal
 classes [v2]
In-Reply-To: <7ke0m-SnpLCsJuSdnYzeaZfvK_xDoMPRUGfaXctIEtk=.9ee5c49c-9a1a-43bc-8975-ee6af3b14165@github.com>
References: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
 <ngd2K0HyYjUkBQhaT_4eGdhhriuNdBZ4U8Veb6Yujcw=.c8523b46-0148-4c0c-9396-4e2c89665605@github.com>
 <St2y0VKNxNBZIXon-3AysUoPwHF9HJBOL9HhzFyTnn8=.8b3f2112-b65e-4de5-801b-d12da96fad73@github.com>
 <7ke0m-SnpLCsJuSdnYzeaZfvK_xDoMPRUGfaXctIEtk=.9ee5c49c-9a1a-43bc-8975-ee6af3b14165@github.com>
Message-ID: <eNJpxkCt3eMHhaNG9w1j24vy9SCeHkeE199DGsSywn8=.5dbbf2d8-92fe-42ca-a8d7-9fcf35295e8b@github.com>

On Mon, 2 Feb 2026 20:21:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBumps.java line 52:
>> 
>>> 50:     protected Color backColor;
>>> 51: 
>>> 52:     private static final List<BumpBuffer> BUMPS_LIST = new ArrayList<BumpBuffer>();
>> 
>> This doesn?t seem to be a constant, does it? I think at some point we should implement some kind of cleanup logic for this list.
>
> The list is constant. The contents are added to.
> I suppose (some day) something like a soft ref could be used, but I am not sure that there will ever be stale members to make it worthwhile or appropriate.
> Either way, out of scope for this change.

If it is not a constant should we still use BUMPS_LIST? By constant I mean something that does not change and we can return it from the methods as it is without cloning/etc. This looks like just a field stored as static final.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29474#discussion_r2756417674

From rkannathpari at openjdk.org  Tue Feb  3 03:50:40 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 3 Feb 2026 03:50:40 GMT
Subject: RFR: 8328977: JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v5]
In-Reply-To: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
Message-ID: <o8saMSQ-txv-CblVlqEvmFZi-kasHFSux1Wqex0NaAI=.ba168bab-406b-4bd3-82c3-6cdbf88517c1@github.com>

> Hi Reviewers,
> 
> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
> 
> Regards,
> Renjith.

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

 - Merge master
 - Merge branch 'openjdk:master' into 8328977-v1
 - Fixed bug4492274 test failure
 - Merge master
 - Fixes NullPointerException
 - Merge master
 - Rearranged if based on suggesion
 - Suggesions updated
 - Removed space
 - JDK-8328977 : JEditorPane.setPage not thread-safe, pageLoader not cancelled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18670/files
  - new: https://git.openjdk.org/jdk/pull/18670/files/6fccd277..17b764b7

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

  Stats: 1533608 lines in 16584 files changed: 859036 ins; 514058 del; 160514 mod
  Patch: https://git.openjdk.org/jdk/pull/18670.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18670/head:pull/18670

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

From rkannathpari at openjdk.org  Tue Feb  3 03:58:41 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 3 Feb 2026 03:58:41 GMT
Subject: RFR: 8328977: JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v6]
In-Reply-To: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
Message-ID: <TdxeGTlre-A5sYDP9Hwum31BXOEaxdBymkk2h7Igu_M=.501f15b3-104e-4e8d-b2f1-9775086e795d@github.com>

> Hi Reviewers,
> 
> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
> 
> Regards,
> Renjith.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18670/files
  - new: https://git.openjdk.org/jdk/pull/18670/files/17b764b7..d1d1f448

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

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

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

From rkannathpari at openjdk.org  Tue Feb  3 04:03:12 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 3 Feb 2026 04:03:12 GMT
Subject: RFR: 8328977: JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <S9dCdr9PFuQ5fKA1LUPECSnBV3o6JNjwkgmzN-fmN-o=.e4fecad8-a404-4580-875b-d0f8a5b3a937@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
 <S9dCdr9PFuQ5fKA1LUPECSnBV3o6JNjwkgmzN-fmN-o=.e4fecad8-a404-4580-875b-d0f8a5b3a937@github.com>
Message-ID: <AJe-rEBit8vZOX1GpZoqouNLiq2kPGa68dDihiPi3zI=.a3e8a362-1cb6-49aa-adac-e8bd8fa865f7@github.com>

On Wed, 5 Feb 2025 12:18:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearranged if based on suggesion
>
> src/java.desktop/share/classes/javax/swing/JEditorPane.java line 480:
> 
>> 478:         final String reference = page.getRef();
>> 479: 
>> 480:         if ((postData == null) && page.sameFile(loaded)) {
> 
> This line of code causes lots of test failures because `page.sameFile(loaded)` doesn't accept a `null` parameter, which results in `NullPointerException`.

Post **null** check and bringing back missing code at [482](https://github.com/Renjithkannath/jdk/blob/d1d1f448bfd196913039cbb822eada9b98a5e557/src/java.desktop/share/classes/javax/swing/JEditorPane.java#L482)  there is no failure on tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r2757076163

From aivanov at openjdk.org  Tue Feb  3 18:40:19 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Feb 2026 18:40:19 GMT
Subject: RFR: 8376297: ArrayIndexOutOfBoundsException Not Documented for
 SinglePixelPackedSampleModel.getSampleSize(int) [v3]
In-Reply-To: <m5KDF8ILOVKS7QBF7GZO2835MQBykms4Wp7gcISo_z8=.9e1f8993-7c2d-4ae1-afc2-939976a4bb68@github.com>
References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com>
 <m5KDF8ILOVKS7QBF7GZO2835MQBykms4Wp7gcISo_z8=.9e1f8993-7c2d-4ae1-afc2-939976a4bb68@github.com>
Message-ID: <Aljc0XLyZfHZnM0VQ31wvVDnMUGKLBisenxL_GtQUUU=.476d1a18-3b78-4b0a-b853-404eeadc6a06@github.com>

On Mon, 2 Feb 2026 20:01:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave.
>> It isn't entirely pretty because 2 of them ignore the band parameter and always have ..
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376297

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29457#pullrequestreview-3746933966

From prr at openjdk.org  Tue Feb  3 19:28:16 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Feb 2026 19:28:16 GMT
Subject: Integrated: 8376297: ArrayIndexOutOfBoundsException Not Documented for
 SinglePixelPackedSampleModel.getSampleSize(int)
In-Reply-To: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com>
References: <_HTsu1feDn37DkgRgdGO7m_K7INr7UPsK4noSDbF_gY=.5f296e4b-a877-4bf5-8637-d749c2449688@github.com>
Message-ID: <kW5N-DiA3MFKidG4JFeqnwPp6qBu_pZ_DrIzdXvmRKk=.f1f3b818-4c28-4dcb-b7b9-0e071d2ee619@github.com>

On Tue, 27 Jan 2026 22:51:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Update the specification of concrete SampleModel classes which over-ride getSampleSize(int band) to describe how the behave.
> It isn't entirely pretty because 2 of them ignore the band parameter and always have ..

This pull request has now been integrated.

Changeset: 5fea0741
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fea0741a6b7ff7e3a41844c86e422c0f0582333
Stats:     104 lines in 4 files changed: 98 ins; 0 del; 6 mod

8376297: ArrayIndexOutOfBoundsException Not Documented for SinglePixelPackedSampleModel.getSampleSize(int)

Reviewed-by: aivanov, serb, azvegint, kizune

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

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

From serb at openjdk.org  Tue Feb  3 19:59:12 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Feb 2026 19:59:12 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v3]
In-Reply-To: <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
Message-ID: <ZskMIzx4ZnVS1g9daQaiZziei2FsGe1OzKX44YkB2oA=.cc1ff07a-e48d-4a64-b81e-a0ad43b76b5d@github.com>

On Thu, 22 Jan 2026 17:57:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
>> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
>> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
>> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
>> 
>> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
>> I did that and ran all our existing automated tests on our CI systems.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8373626

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29257#pullrequestreview-3747279579

From serb at openjdk.org  Tue Feb  3 20:01:38 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Feb 2026 20:01:38 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
In-Reply-To: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
Message-ID: <N6C_z9FjFYIgq2-Fm3MQ66G2NWJ7QbSilEBlBTN_dK4=.63d0f47b-dd87-472c-b941-f961073011fd@github.com>

On Mon, 2 Feb 2026 20:07:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from java/awt/SystemTray

src/java.desktop/share/classes/java/awt/SystemTray.java line 317:

> 315:      */
> 316:     public TrayIcon[] getTrayIcons() {
> 317:         if (icons != null) {

This looks like a synchronization bug. Previously, it seemed to be synced via the app context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29531#discussion_r2760760956

From serb at openjdk.org  Tue Feb  3 20:06:20 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Feb 2026 20:06:20 GMT
Subject: RFR: 8376996: Remove AppContext usage from SunClipboard.java
In-Reply-To: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
References: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
Message-ID: <oMQ3ROofwgyV6r1ymFbgteg9wdSSD_b6iT1FQnKMmec=.352615c7-7c97-45e4-8063-80a4593464f4@github.com>

On Mon, 2 Feb 2026 20:56:02 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SunClipboard.

src/java.desktop/share/classes/sun/awt/datatransfer/SunClipboard.java line 64:

> 62: public abstract class SunClipboard extends Clipboard {
> 63: 
> 64:     private final Object CLIPBOARD_FLAVOR_LISTENER_KEY;

This field is not needed anymore?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29533#discussion_r2760776099

From serb at openjdk.org  Tue Feb  3 20:06:32 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Feb 2026 20:06:32 GMT
Subject: RFR: 8376994: Remove AppContext from
 sun/awt/datatransfer/DataTransferer.java
In-Reply-To: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
References: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
Message-ID: <SAG23y5meOzv21lP6IIUbu4IdEuVIwl1scvk-AWD2TU=.fb484ccd-a18b-478a-a64a-9744b25283b1@github.com>

On Mon, 2 Feb 2026 20:11:33 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from sun/awt/datatransfer/DataTransferer.java

src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java line 155:

> 153:             Collections.synchronizedMap(new HashMap<>());
> 154: 
> 155:     private static volatile Runnable dataConverterInstance;

Doc about "pending data conversion" can be preserved?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29532#discussion_r2760768690

From serb at openjdk.org  Tue Feb  3 20:12:13 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 3 Feb 2026 20:12:13 GMT
Subject: RFR: 8376998: [macOS] Remove AppContext from AppEventHandler
In-Reply-To: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
References: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
Message-ID: <QQ1FK4By0guq_twppvot_HJUPYT1LyWUqsWEgs8ZHcQ=.7d380430-1947-480b-b452-f85290658c42@github.com>

On Mon, 2 Feb 2026 21:05:37 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes AppContext from the _AppEventHandler class used on macOS.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29534#pullrequestreview-3747333263

From prr at openjdk.org  Tue Feb  3 20:26:14 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Feb 2026 20:26:14 GMT
Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal
 classes [v3]
In-Reply-To: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
References: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
Message-ID: <u3AR-GrsltQqW0U_XljLEipoF3SVM0aSa2r_GtnLrQg=.84c3d0b1-41de-410e-9044-baa82a09e5ea@github.com>

> Remove AppContext from Metal L&F

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

  8376627

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29474/files
  - new: https://git.openjdk.org/jdk/pull/29474/files/99a78477..e855a2f6

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

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

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

From prr at openjdk.org  Tue Feb  3 20:26:15 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Feb 2026 20:26:15 GMT
Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal
 classes [v2]
In-Reply-To: <eNJpxkCt3eMHhaNG9w1j24vy9SCeHkeE199DGsSywn8=.5dbbf2d8-92fe-42ca-a8d7-9fcf35295e8b@github.com>
References: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
 <ngd2K0HyYjUkBQhaT_4eGdhhriuNdBZ4U8Veb6Yujcw=.c8523b46-0148-4c0c-9396-4e2c89665605@github.com>
 <St2y0VKNxNBZIXon-3AysUoPwHF9HJBOL9HhzFyTnn8=.8b3f2112-b65e-4de5-801b-d12da96fad73@github.com>
 <7ke0m-SnpLCsJuSdnYzeaZfvK_xDoMPRUGfaXctIEtk=.9ee5c49c-9a1a-43bc-8975-ee6af3b14165@github.com>
 <eNJpxkCt3eMHhaNG9w1j24vy9SCeHkeE199DGsSywn8=.5dbbf2d8-92fe-42ca-a8d7-9fcf35295e8b@github.com>
Message-ID: <BPF4VI9ge-ySOqcvrk8-ly9jGE55dFin4prfyNTrUpA=.5de42a2e-9cf7-4525-808f-d9849e8f6ff5@github.com>

On Mon, 2 Feb 2026 23:12:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The list is constant. The contents are added to.
>> I suppose (some day) something like a soft ref could be used, but I am not sure that there will ever be stale members to make it worthwhile or appropriate.
>> Either way, out of scope for this change.
>
> If it is not a constant should we still use BUMPS_LIST? By constant I mean something that does not change and we can return it from the methods as it is without cloning/etc. This looks like just a field stored as static final.

Ok I've changed the name to bumpsList

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29474#discussion_r2760834088

From prr at openjdk.org  Tue Feb  3 20:28:22 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Feb 2026 20:28:22 GMT
Subject: RFR: 8376996: Remove AppContext usage from SunClipboard.java [v2]
In-Reply-To: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
References: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
Message-ID: <HcJUPWsi9VrTRQ_49yp6VLwTUsfAOcm4hflywm0ygw4=.87789fed-17d7-46cd-aeb3-b415dd38e21b@github.com>

> Remove AppContext from SunClipboard.

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

  8376996

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29533/files
  - new: https://git.openjdk.org/jdk/pull/29533/files/4115b658..a219df02

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

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

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

From prr at openjdk.org  Tue Feb  3 20:28:24 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Feb 2026 20:28:24 GMT
Subject: RFR: 8376996: Remove AppContext usage from SunClipboard.java [v2]
In-Reply-To: <oMQ3ROofwgyV6r1ymFbgteg9wdSSD_b6iT1FQnKMmec=.352615c7-7c97-45e4-8063-80a4593464f4@github.com>
References: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
 <oMQ3ROofwgyV6r1ymFbgteg9wdSSD_b6iT1FQnKMmec=.352615c7-7c97-45e4-8063-80a4593464f4@github.com>
Message-ID: <nasTrLrnR7T7Ju72V11P82b9jhs9-Gkqjx-zB0qisq4=.4ec5d8ee-81d3-42dc-b71c-5b8d56f72d04@github.com>

On Tue, 3 Feb 2026 20:03:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8376996
>
> src/java.desktop/share/classes/sun/awt/datatransfer/SunClipboard.java line 64:
> 
>> 62: public abstract class SunClipboard extends Clipboard {
>> 63: 
>> 64:     private final Object CLIPBOARD_FLAVOR_LISTENER_KEY;
> 
> This field is not needed anymore?

Indeed. I will remove it now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29533#discussion_r2760847444

From aivanov at openjdk.org  Tue Feb  3 20:37:48 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Feb 2026 20:37:48 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <ohQH9xJJo_KXeaKMBzx7Ed-ostrt4-DFhm2wByZTxlE=.d488ab29-ff15-4ff6-80bd-24bb04d3413d@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

I tested it in a live Ubuntu image. I installed all the dependencies except for X11 headers. The regular run of `configure` failed for me complaining about the missing X11 headers. When I passed the `--enable-headless-only` option to `configure`, it succeeded, and the build succeeded.

I ran headless AWT tests, and all the tests passed.

The fix for [JDK-8255785](https://bugs.openjdk.org/browse/JDK-8255785) that enabled building headless JDK without the X11 headers was reverted by [JDK-8258465](https://bugs.openjdk.org/browse/JDK-8258465) because there was a dependency on definition of the rectangle structure.

The fix proposed in this PR removes that dependency by providing an alternative definition, the same one that's already used on macOS. Thus, this fix also resolves [JDK-8273258](https://bugs.openjdk.org/browse/JDK-8273258).

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28310#pullrequestreview-3747431493

From aivanov at openjdk.org  Tue Feb  3 20:40:12 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Feb 2026 20:40:12 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <kMSFyEou2-x58CsS_FIrsXEg57tOiB0LDE1O8R1tum8=.a6c4d8a6-c7ef-4140-811a-d9941ca6a605@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

I also ran the clientlibs tests in Oracle CI. There were a few failures, they were unrelated to this fix. To play it safe, today I merged `master` into my local branch with this fix and submitted a new test job.

The test job hasn't completed yet, but there are no failures so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843529266

From duke at openjdk.org  Tue Feb  3 21:21:14 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Tue, 3 Feb 2026 21:21:14 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <DDwxy5GBQhXydGSdcjvus4F4rty3XK_HA__tmgnaCJQ=.e800915b-4b79-4e58-9931-3104d7242abe@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

Thanks for the reviews and tests. I assume that merging goes automatically now?

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843732377

From aivanov at openjdk.org  Tue Feb  3 21:29:38 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 3 Feb 2026 21:29:38 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <DDwxy5GBQhXydGSdcjvus4F4rty3XK_HA__tmgnaCJQ=.e800915b-4b79-4e58-9931-3104d7242abe@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <DDwxy5GBQhXydGSdcjvus4F4rty3XK_HA__tmgnaCJQ=.e800915b-4b79-4e58-9931-3104d7242abe@github.com>
Message-ID: <VFVt_BSOdy84B4ogjB3BRTHDQroAUUJyaDM7rz7xo0Y=.da643743-8993-4f0e-92f6-e4c176f7775b@github.com>

On Tue, 3 Feb 2026 21:18:00 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> Thanks for the reviews and tests. I assume that merging goes automatically now?

No, you have to issue the [`/integrate` command](https://wiki.openjdk.org/spaces/SKARA/pages/56524908/Pull+Request+Commands#PullRequestCommands-/integrate).

Then a [*Committer*](https://openjdk.org/bylaws#committer) will use the [`/sponsor` command](https://wiki.openjdk.org/spaces/SKARA/pages/56524908/Pull+Request+Commands#PullRequestCommands-/sponsor) to integrate the changeset. I'll happily sponsor once the test job finishes. I'll also allow some time for Phil to approve this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843766391

From prr at openjdk.org  Tue Feb  3 21:31:44 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Feb 2026 21:31:44 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
In-Reply-To: <N6C_z9FjFYIgq2-Fm3MQ66G2NWJ7QbSilEBlBTN_dK4=.63d0f47b-dd87-472c-b941-f961073011fd@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
 <N6C_z9FjFYIgq2-Fm3MQ66G2NWJ7QbSilEBlBTN_dK4=.63d0f47b-dd87-472c-b941-f961073011fd@github.com>
Message-ID: <pSqhxwe3G1YJL0scyHFytMmMzCB_DLJlt0-cZXSGwNc=.5da48dfa-3119-45d7-825d-7073711d4577@github.com>

On Tue, 3 Feb 2026 19:58:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Remove AppContext from java/awt/SystemTray
>
> src/java.desktop/share/classes/java/awt/SystemTray.java line 317:
> 
>> 315:      */
>> 316:     public TrayIcon[] getTrayIcons() {
>> 317:         if (icons != null) {
> 
> This looks like a synchronization bug. Previously, it seemed to be synced via the app context.

I noticed  that this isn't synchronized whilst other cases are, and it may be a bug but I really hope it wasn't designed to rely on AppContext internals for synchronization !
I can add a synchronized block but the worst that can happen without it is that it sees null and returns an empty array of TrayIcon instead of one with some concurrently added icon, and that could happen anyway depending on which thread entered first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29531#discussion_r2761083054

From duke at openjdk.org  Tue Feb  3 21:33:59 2026
From: duke at openjdk.org (duke)
Date: Tue, 3 Feb 2026 21:33:59 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <tNVNwhJoNVKJKhYzSsrJE9_RdLBnMT8ysHzJMtSv8C8=.90e2d1a9-a7eb-48b8-9ebc-549fe30baf7b@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3843781354

From prr at openjdk.org  Tue Feb  3 21:47:01 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 3 Feb 2026 21:47:01 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
 [v2]
In-Reply-To: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
Message-ID: <FUrLqA_jl3oTsFc--sxqfpZMsZ7Fe-T27BG27hLM_6k=.a62b7093-5254-40db-9f33-5927bf46dcb5@github.com>

> Remove AppContext from java/awt/SystemTray

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

  8376992

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29531/files
  - new: https://git.openjdk.org/jdk/pull/29531/files/febc5002..2930b0e0

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

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

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

From serb at openjdk.org  Wed Feb  4 01:24:03 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 4 Feb 2026 01:24:03 GMT
Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal
 classes [v3]
In-Reply-To: <u3AR-GrsltQqW0U_XljLEipoF3SVM0aSa2r_GtnLrQg=.84c3d0b1-41de-410e-9044-baa82a09e5ea@github.com>
References: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
 <u3AR-GrsltQqW0U_XljLEipoF3SVM0aSa2r_GtnLrQg=.84c3d0b1-41de-410e-9044-baa82a09e5ea@github.com>
Message-ID: <4P695wPVpYB7XwnLsVxBqgDwf8gqNB_JggqrHu0EwRM=.c8bfb8d3-00c4-42c3-9d17-a1d554d8ad3a@github.com>

On Tue, 3 Feb 2026 20:26:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from Metal L&F
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376627

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29474#pullrequestreview-3748452259

From duke at openjdk.org  Wed Feb  4 06:52:38 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Wed, 4 Feb 2026 06:52:38 GMT
Subject: Integrated: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
Message-ID: <r5WN2dDxh12hkB5DVQVjV-af1FANOWt6AtloHgS9byM=.788fdc74-603d-43d0-9f2e-00b99eff5a79@github.com>

On Thu, 13 Nov 2025 22:17:23 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> This to support linux headless mode without X11. E.g. A headless server.

This pull request has now been integrated.

Changeset: 1069cceb
Author:    Thomas Devoogdt <thomas at devoogdt.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1069ccebcc32e02055985e2babfa2986a2e295ca
Stats:     30 lines in 5 files changed: 14 ins; 5 del; 11 mod

8376684: Compile OpenJDK in headless mode without required X11 libraries

Reviewed-by: erikj, aivanov

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

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

From duke at openjdk.org  Wed Feb  4 07:08:07 2026
From: duke at openjdk.org (Thomas Devoogdt)
Date: Wed, 4 Feb 2026 07:08:07 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
Message-ID: <5Vj1Hpwga_JuLq8z4OpkIVrNN3_HC92t2xYB7QFtDNo=.2fdf6efb-4353-4322-8e74-6349e8985577@github.com>

On Thu, 29 Jan 2026 09:56:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This to support linux headless mode without X11. E.g. A headless server.
>
> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.
> 
> But I am no expert in this area; @magicus and @prrace should look at this.
> 
> If this gets pushed, downporting it to LTSes is possible.

@tstuefe What is the procedure to get this back ported to the LTS branches? Just open PRs there with a reference to this one?

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3845731350

From duke at openjdk.org  Wed Feb  4 07:42:11 2026
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Wed, 4 Feb 2026 07:42:11 GMT
Subject: RFR: 8372952: Printed content is cut off when width > height
Message-ID: <lb8GZRWbO4rnHCVFF8MQfgV3DIuOGIt4f49RRyhW8Ng=.7ce8594c-eef8-4a99-ab73-14ebf3130646@github.com>

These changes fix https://bugs.openjdk.org/browse/JDK-8372952 "Printed content is cut off when width > height". 

There are three issues which cause this bug.
#### The first issue
Media printable area does not match the corresponding media size for the landscape-oriented medias. \
An example of the actual prints on a paper 80mmx40mm (Epson T-TA88V) 
[actual_cut_off.pdf](https://github.com/user-attachments/files/25064646/actual_cut_off.pdf)

#### The second issue
_MediaSize_ does not allow landscape-oriented medias (X dimension bigger than Y dimension of the media) so rotated size is used, but the media printable area stays the same - landscape-oriented. 
Current implementation does not allow to use landscape-oriented paper because _MediaSize_
constructor allows portrait paper only (width < height). 

I read comments about _MediaSize_ restrictions (width<height) in https://bugs.openjdk.org/browse/JDK-8041911, which states that this is "by design" and specification. But I did not find media size restrictions in the https://datatracker.ietf.org/doc/html/rfc2911.
The RFC defines "orientation-requested" attribute, that was mentioned in the JDK-8041911 comments, but this attribute indicates the desired orientation for printed print-stream pages and is used for only a subset of the supported document formats ('text/plain' or 'text/html') to format the document. \
As described in the RFC https://datatracker.ietf.org/doc/html/rfc2911#section-15.3
> If the document data has been formatted, then go to step 2. Otherwise, the document data MUST be formatted. The formatting detection algorithm is implementation defined and is not specified by this document.  The formatting of the document data uses the "orientation-requested" attribute to determine how the formatted print data should be placed on a print-stream page

Therefore, if a printer object uses a landscape-oriented paper, a document format is "text/plain" and an "orientation-requested" attribute contains "portrait" value then the printer object should rotate the document 90 degrees. \
If a printer uses a portrait-oriented paper, a document format is "text/plain," and an "orientation-requested" attribute contains value "portrait" then the printer object does no rotation.

Also, https://datatracker.ietf.org/doc/html/rfc3382 defines a "media-size" IPP attribute which identifies the size of the media. The RFC contains an example of this attribute where the X-dimension (the width of the media in inch) larger than the Y-dimension (the height of the media in inch units).

>       "media-col" =
>         {  "media-color" =  'blue';
>            "media-size" =
>            {    "x-dimension" = 6;
>                 "y-dimension" = 4
>              }
>         },


#### The third issue
Implicit selection of the paper on macOS. Desired paper size and orientation is set during printer job setup and there is no explicit paper selection (landscape-oriented or portrait-oriented), so users cannot choose landscape-oriented paper if portrait-oriented paper with the same size exists and unable to set valid margins for landscape-oriented prints. If a label printer charged with landscape-oriented sticks but has a portrait sticks in settings with the same size then printer prints on the landscape-oriented sticks with portrait-oriented settings. \
An examples: \
Incorrect margins.
[incorrect_margins_landscape.pdf](https://github.com/user-attachments/files/25064640/incorrect_margins_landscape.pdf) \
A landscape-oriented (Ledger) is selected by a user but portrait-oriented (Tabloid) paper is used.
[incorrect_orientation.pdf](https://github.com/user-attachments/files/25064638/incorrect_orientation.pdf)

#### Changes
To solve the first and the second issues I added a new class _CustomMediaSize_, a wrapper for the _MediaSize_,
that allows to create a landscape media size (width > height). The getX, getY methods of the new class return the real
size of the media depending on paper orientation. The _CustomMediaSize_ is used in _CustomMediaSizeName_ during new _MediaSize_ creation and catches _IllegalArgumentException_ exception (X dimension > Y dimension) instead of swapping the width and height of the paper. The _CustomMediaSize_ implementation fixes the media printable area mismatch.

To solve the third problem I changed _CPrinterJob_ and _PrinterView_ files and added explicit paper selection. The _PMPaper_ and _PMPageFormat_ classes are used to choose desired paper. First of all, new approach tries to find existing paper with desired size and margins and use it, if the paper doesn't exist - it creates a new one. Also, this approach takes into account page format orientation to set paper margins properly, so this solves the issue with incorrect margins during landscape printing and allows reverse landscape printing.

An example of printings with this fix
[fixed_wo_cut_off.pdf](https://github.com/user-attachments/files/25064627/fixed_wo_cut_off.pdf)

#### Tests
I've run jtreg tests from the _java.awt.print_ and _javax.print_, there is no regression after updates. \
Two new test added to check media printable area and margins.

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

Commit messages:
 - landscape paper

Changes: https://git.openjdk.org/jdk/pull/29560/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29560&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372952
  Stats: 990 lines in 7 files changed: 809 ins; 127 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/29560.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29560/head:pull/29560

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

From duke at openjdk.org  Wed Feb  4 08:26:01 2026
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Wed, 4 Feb 2026 08:26:01 GMT
Subject: RFR: 8372952: Printed content is cut off when width > height [v2]
In-Reply-To: <lb8GZRWbO4rnHCVFF8MQfgV3DIuOGIt4f49RRyhW8Ng=.7ce8594c-eef8-4a99-ab73-14ebf3130646@github.com>
References: <lb8GZRWbO4rnHCVFF8MQfgV3DIuOGIt4f49RRyhW8Ng=.7ce8594c-eef8-4a99-ab73-14ebf3130646@github.com>
Message-ID: <L6epQJ_wv79hftjql8paFgsDF3zRzNRW6dX_f3-O8Aw=.5f6e8760-58b9-4e68-980f-1948f72a8c7a@github.com>

> These changes fix https://bugs.openjdk.org/browse/JDK-8372952 "Printed content is cut off when width > height". 
> 
> There are three issues which cause this bug.
> #### The first issue
> Media printable area does not match the corresponding media size for the landscape-oriented medias. \
> An example of the actual prints on a paper 80mmx40mm (Epson T-TA88V) 
> [actual_cut_off.pdf](https://github.com/user-attachments/files/25064646/actual_cut_off.pdf)
> 
> #### The second issue
> _MediaSize_ does not allow landscape-oriented medias (X dimension bigger than Y dimension of the media) so rotated size is used, but the media printable area stays the same - landscape-oriented. 
> Current implementation does not allow to use landscape-oriented paper because _MediaSize_
> constructor allows portrait paper only (width < height). 
> 
> I read comments about _MediaSize_ restrictions (width<height) in https://bugs.openjdk.org/browse/JDK-8041911, which states that this is "by design" and specification. But I did not find media size restrictions in the https://datatracker.ietf.org/doc/html/rfc2911.
> The RFC defines "orientation-requested" attribute, that was mentioned in the JDK-8041911 comments, but this attribute indicates the desired orientation for printed print-stream pages and is used for only a subset of the supported document formats ('text/plain' or 'text/html') to format the document. \
> As described in the RFC https://datatracker.ietf.org/doc/html/rfc2911#section-15.3
>> If the document data has been formatted, then go to step 2. Otherwise, the document data MUST be formatted. The formatting detection algorithm is implementation defined and is not specified by this document.  The formatting of the document data uses the "orientation-requested" attribute to determine how the formatted print data should be placed on a print-stream page
> 
> Therefore, if a printer object uses a landscape-oriented paper, a document format is "text/plain" and an "orientation-requested" attribute contains "portrait" value then the printer object should rotate the document 90 degrees. \
> If a printer uses a portrait-oriented paper, a document format is "text/plain," and an "orientation-requested" attribute contains value "portrait" then the printer object does no rotation.
> 
> Also, https://datatracker.ietf.org/doc/html/rfc3382 defines a "media-size" IPP attribute which identifies the size of the media. The RFC contains an example of this attribute where the X-dimension (the width of the media in inch) larger than the...

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

  Reformat test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29560/files
  - new: https://git.openjdk.org/jdk/pull/29560/files/95935d4f..8fdbdb2a

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

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

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

From aivanov at openjdk.org  Wed Feb  4 12:01:27 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 4 Feb 2026 12:01:27 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <5Vj1Hpwga_JuLq8z4OpkIVrNN3_HC92t2xYB7QFtDNo=.2fdf6efb-4353-4322-8e74-6349e8985577@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
 <5Vj1Hpwga_JuLq8z4OpkIVrNN3_HC92t2xYB7QFtDNo=.2fdf6efb-4353-4322-8e74-6349e8985577@github.com>
Message-ID: <KtXjE8c9tpFFXgK3rOMRavILmYoZWMiyOIRu3z32YFA=.6c627b8a-db96-45f3-a489-1efc9043f183@github.com>

On Wed, 4 Feb 2026 07:05:27 GMT, Thomas Devoogdt <duke at openjdk.org> wrote:

> What is the procedure to get this back ported to the LTS branches? Just open PRs there with a reference to this one?

See the guidelines for [Backporting](https://openjdk.org/guide/#backporting), and in particular [Requesting approvals for backports](https://openjdk.org/guide/#requesting-approvals-for-backports).

Essentially, you create backport PRs for LTS releases and request approvals.

You can look for examples at the [*jdk-updates-dev* mailing list](https://mail.openjdk.org/pipermail/jdk-updates-dev/).

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3847022323

From syan at openjdk.org  Wed Feb  4 14:11:12 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 4 Feb 2026 14:11:12 GMT
Subject: RFR: 8377167: javax/imageio/ReadAbortTest.java throw NPE when x11
 unavailable
Message-ID: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>

Hi all,

Test javax/imageio/ReadAbortTest.java and javax/imageio/WriteAbortTest.java throw java.lang.NullPointerException when x11 display unavailable, because object `path` unable to initial. This PR check the `path` is null or not before use it, this will make test failure report friendly when x11 display unavailable but DISPLAY was seted.

Change has been verified locally on linux-x64.

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

Commit messages:
 - 8377167: javax/imageio/ReadAbortTest.java throw NPE when x11 unavailable

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

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

From prr at openjdk.org  Wed Feb  4 16:15:05 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 16:15:05 GMT
Subject: RFR: 8376684: Compile OpenJDK in headless mode without required
 X11 libraries
In-Reply-To: <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
References: <L-KGc9a0uaL-3_LAFdnVx-9nEZAlJwMfWq-tTo_XDps=.25d260e4-04ae-46cd-918a-094e97886aaa@github.com>
 <pRFIrRjlg5tqncJ1mRr_Fg2sRKURPoLcypyumyfH-_I=.44f80e29-363b-4058-8ba4-f7f81891ffbf@github.com>
Message-ID: <Cg5vPHpX4QMKmPaMFYGgZpzGHYCrWKrfuUCr7m3EhFU=.418384a4-07cc-405a-a89d-e5eacebde73a@github.com>

On Thu, 29 Jan 2026 09:56:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This to support linux headless mode without X11. E.g. A headless server.
>
> Sorry, this keeps falling through the cracks. I opened https://bugs.openjdk.org/browse/JDK-8376684 - I guess Alexey was snowed in.
> 
> But I am no expert in this area; @magicus and @prrace should look at this.
> 
> If this gets pushed, downporting it to LTSes is possible.

ahem @tstuefe I was waiting for Alexey to finish testing before adding my approval, did you not see the comments by Alexey ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28310#issuecomment-3848367244

From prr at openjdk.org  Wed Feb  4 16:20:35 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 16:20:35 GMT
Subject: RFR: 8377167: javax/imageio/ReadAbortTest.java throw NPE when x11
 unavailable
In-Reply-To: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
References: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
Message-ID: <Z2X2W62JzuIXe9mz6lG1bZ8ufrVzDN47bJChiWLllH8=.15573d17-c84c-4819-9713-2562b0916143@github.com>

On Wed, 4 Feb 2026 14:02:51 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test javax/imageio/ReadAbortTest.java and javax/imageio/WriteAbortTest.java throw java.lang.NullPointerException when x11 display unavailable, because object `path` unable to initial. This PR check the `path` is null or not before use it, this will make test failure report friendly when x11 display unavailable but DISPLAY was seted.
> 
> Change has been verified locally on linux-x64.

This does not make one bit of sense. These tests do nothing with DISPLAY. They do not start AWT.

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

PR Comment: https://git.openjdk.org/jdk/pull/29569#issuecomment-3848393987

From alexey.ivanov at oracle.com  Wed Feb  4 16:38:27 2026
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 4 Feb 2026 16:38:27 +0000
Subject: Unwanted artifacts on my JButton
In-Reply-To: <CAA9v-_P0cvBXjKkSnPEfgJy2b5v17osue82rtwk5nyA8oxJFKg@mail.gmail.com>
References: <CAA9v-_P77qAAo68Tr=+D5HhrZzjHOPUxEf8FMp5TUvryKA3rCw@mail.gmail.com>
 <fad04be1-b16a-426d-850a-608ba25c3170@oracle.com>
 <CAA9v-_Om=VG7DLNGFxwv7ceRpLNPzeOh8OzA4uCznn+23fSrNg@mail.gmail.com>
 <28b550b0-3633-4f69-a334-f1aa4a3fcd59@oracle.com>
 <CAA9v-_P0cvBXjKkSnPEfgJy2b5v17osue82rtwk5nyA8oxJFKg@mail.gmail.com>
Message-ID: <336fb9a5-5de4-4759-9d3f-7f74fdd5c97d@oracle.com>

Hi David,

I stumbled upon this message in my inbox and realised I hadn't replied 
your latest questions.

On 2025-08-30 15:15, David Alayachew wrote:
> Thanks Alexey,
>
> I use 125%, so looks like I got the unlucky hand here. And thanks 
> about the multiple of 4 detail.
>
> I understand that this is a difficult problem to fix, but this is 
> still something that will eventually be fixed, right? Or is this 
> something that will just not be addressed?

I hope this problem will get fixed eventually. At the same time, I don't 
see an easy way to do so.

I believe the button in your test case falls at an ?edge? of pixel grid. 
When the parent component is painted, the button is clipped from erasing 
the background, and the clip area ends up being 1 pixel larger than the 
area which the button paints. This is how you can see the garbage left 
in the back buffer.

We may need to look at the approaches other UI frameworks employ. As far 
as I know, Java FX handles scaling better than Swing. As an example, a 
layout manager could ensure that the coordinates and the width and 
height of each component are multiples of 4, the gaps between components 
should also be multiples of 4. But it still could break UI layouts? just 
in a different way.

As always, any suggestions on how to tackle the problem, including 
patches, are welcome.

-- 
Regards,
Alexey

>
> Thank you for your time and help.
> David Alayachew
>
> On Fri, Aug 29, 2025, 5:24?AM Alexey Ivanov <alexey.ivanov at oracle.com> 
> wrote:
>
>     Hi David,
>
>     It is a known issue because of fractional scale. Unfortunately,
>     it's not
>     so easy to fix. The artifact that you see is the result of
>     rounding: the
>     button should've painted more pixels, but it didn't, therefore you
>     see
>     garbage left in the back buffer.
>
>     What is the default / recommended scale on your system? I assume it's
>     150%, which is the most common scale for laptops and monitors.
>
>     With 125% and 175%, you usually get more artifacts than with 150%.
>     With
>     integral scales, 200%, the UI usually looks good without artifacts.
>
>
>     To workaround, you can increase the height of the button. In
>     general, if
>     you use coordinates and widths and heights that are multiples of
>     4, you
>     shouldn't see such artifacts because the standard scales will
>     produce an
>     integer.
>
>     Your test case on Stack Overflow can be minimised to display only the
>     button. If its coordinates and its width and height aren't
>     multiples of
>     4, there are high chances of seeing artifacts, however, this requires
>     the back buffer to contain garbage that's not filled with the
>     background
>     colour of the frame.
>
>
>     If you have a JBS account, you can click "Start watching this
>     issue" to
>     receive notifications when it's changed.
>
>     -- 
>     Regards,
>     Alexey
>
>     On 2025-08-29 04:40, David Alayachew wrote:
>     > Ty vm?Prasanta. Please keep me in the loop. I will also check
>     back in
>     > to the JBS page on occasion to see progress on this.
>     >
>     > On Thu, Aug 28, 2025 at 10:23?PM Prasanta Sadhukhan
>     > <prasanta.sadhukhan at oracle.com> wrote:
>     >
>     >? ? ?Hi David,
>     >
>     >? ? ?It seems to be a bug and its there from JDK9 when HiDPI feature
>     >? ? ?was introduced in 2015..We will look into it but cannot
>     commit on
>     >? ? ?a timeframe for now..
>     >
>     >? ? ?Regards
>     >? ? ?Prasanta
>     >? ? ?On 28-08-2025 04:11, David Alayachew wrote:
>     >>? ? ?Hello @client-libs-dev at openjdk.org
>     >>? ? ?<mailto:client-libs-dev at openjdk.org>,
>     >>
>     >>? ? ?Here is my StackOverflow post --
>     >>
>     https://stackoverflow.com/questions/79748482/how-do-i-get-rid-of-these-artifacts-on-my-jbutton-and-or-what-am-i-doing-wrong
>     <https://urldefense.com/v3/__https://stackoverflow.com/questions/79748482/how-do-i-get-rid-of-these-artifacts-on-my-jbutton-and-or-what-am-i-doing-wrong__;!!ACWV5N9M2RV99hQ!PCN9WQxrtDa26-bo7WfYqg5k4dYWSuT5FhHWJFLQSBdWqJOY0hccMnH-4RZaQo6xnJSHkZgbj1lRFTnW3SczyElChE0h$>
>     >>
>     >>? ? ?I have a simple Swing GUI that takes in an image, puts it in a
>     >>? ? ?JPanel via JLabel, then adds a button to that same JPanel. When
>     >>? ? ?doing so, I get artifacts at the bottom of my JButton. You can
>     >>? ? ?see the StackOverflow post to see the code example and the
>     artifacts.
>     >>
>     >>? ? ?I was directed to the following bug entry --
>     >> https://bugs.openjdk.org/browse/JDK-8253530
>     >>
>     >>? ? ?Long story short, the issue is with the default scaling set for
>     >>? ? ?HI DPI monitors on Windows 11 (maybe other versions too?). If I
>     >>? ? ?set the scaling down to 100%, this issue goes away, and things
>     >>? ? ?work as expected.
>     >>
>     >>? ? ?Anyways, my question is, is the linked bug something that is
>     >>? ? ?being considered? Based on the comments on it, looks like it is
>     >>? ? ?being treated as not an issue, but it wasn't flagged as such.
>     >>
>     >>? ? ?Thanks for your time and consideration.
>     >>? ? ?David Alayachew
>     >
>


From prr at openjdk.org  Wed Feb  4 20:42:39 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 20:42:39 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager
Message-ID: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>

Remove AppContext from KeyboardFocusManager

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

Commit messages:
 - 8377191

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

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

From prr at openjdk.org  Wed Feb  4 20:42:40 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 20:42:40 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager
In-Reply-To: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
Message-ID: <yOH8alJYzoPatEJsrQTC2UlQMQ3vS8k8WJsDB5kCEbk=.7827d72e-3045-4c53-bcf8-ec81351e9447@github.com>

On Wed, 4 Feb 2026 20:33:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from KeyboardFocusManager

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 429:

> 427:     }
> 428: 
> 429:     public static void postEvent(AWTEvent event) {

The non-app context versions of various SunToolkit methods will eventually replace the overloads with AppContext.
I'm adding similar overloads to other methods in other PRs that may be concurrent so please don't ask for a (c) year update - that'll just be a merge conflict.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29578#discussion_r2765892683

From prr at openjdk.org  Wed Feb  4 20:53:13 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 20:53:13 GMT
Subject: RFR: 8377192: Remove AppContext from MenuSelectionManager
Message-ID: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>

remove AppContext from Swing's MenuSelectionManager

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

Commit messages:
 - 8377192

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

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

From prr at openjdk.org  Wed Feb  4 20:53:14 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 20:53:14 GMT
Subject: RFR: 8377192: Remove AppContext from MenuSelectionManager
In-Reply-To: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
References: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
Message-ID: <O4obdzOPRnVUEjSJc0L1TInMRxw7JLl-RR31uthvZv4=.95954786-d2b5-47bc-837a-f6e6153eb6e7@github.com>

On Wed, 4 Feb 2026 20:44:02 GMT, Phil Race <prr at openjdk.org> wrote:

> remove AppContext from Swing's MenuSelectionManager

src/java.desktop/share/classes/javax/swing/MenuSelectionManager.java line 75:

> 73:                 // installing additional listener if found in the AppContext
> 74:                 Object o = context.get(SwingUtilities2.MENU_SELECTION_MANAGER_LISTENER_KEY);
> 75:                 if (o instanceof ChangeListener listener) {

Why am I not preserving this listener logic ?
Well nothing adds such a listener to the AppContext or anywhere else.
This is the only usage ... because this was added to be used from closed Java Plugin applet related code that we don't have in current JDK. So it has been obsolete for a while.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29579#discussion_r2765914076

From prr at openjdk.org  Wed Feb  4 21:00:38 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 21:00:38 GMT
Subject: RFR: 8377193: Remove AppContext from SwingUtilties3
Message-ID: <Ks3j-dS4eLoh7kU5t__YhFuJojFTevTzQuAFjQ4IOGE=.1f9c07b9-fd47-47a9-ac7a-32da510696d4@github.com>

Remove AppContext from SU3

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

Commit messages:
 - 8377193

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

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

From serb at openjdk.org  Wed Feb  4 21:04:31 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 4 Feb 2026 21:04:31 GMT
Subject: RFR: 8377167: javax/imageio/ReadAbortTest.java throw NPE when x11
 unavailable
In-Reply-To: <Z2X2W62JzuIXe9mz6lG1bZ8ufrVzDN47bJChiWLllH8=.15573d17-c84c-4819-9713-2562b0916143@github.com>
References: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
 <Z2X2W62JzuIXe9mz6lG1bZ8ufrVzDN47bJChiWLllH8=.15573d17-c84c-4819-9713-2562b0916143@github.com>
Message-ID: <d-mICD53IdbGQbm6G-izhSF8xmfOjXH76ToeKm6oI2w=.7c2af711-6cee-465a-813f-7cc3adcdb51d@github.com>

On Wed, 4 Feb 2026 16:17:31 GMT, Phil Race <prr at openjdk.org> wrote:

> This does not make one bit of sense. These tests do nothing with DISPLAY. They do not start AWT.

Since DISPLAY is set, the GraphicsEnvironment considers the system as headful and tries to connect to display. After this patch, the test will not pass in that environment but will instead show the real stack trace.

java.awt.AWTError: Can't connect to X11 window server using ':123' as the value of the DISPLAY variable.
        at java.desktop/sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
        at java.desktop/sun.awt.X11GraphicsEnvironment.initStatic(X11GraphicsEnvironment.java:100)
        at java.desktop/sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:57)
        at java.desktop/sun.awt.PlatformGraphicsInfo.createGE(PlatformGraphicsInfo.java:35)
        at java.desktop/java.awt.GraphicsEnvironment$LocalGE.createGE(GraphicsEnvironment.java:89)
        at java.desktop/java.awt.GraphicsEnvironment$LocalGE.<clinit>(GraphicsEnvironment.java:80)
        at java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:102)
        at java.desktop/java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1167)
        at ReadAbortTest.<init>(ReadAbortTest.java:64)
        at ReadAbortTest.main(ReadAbortTest.java:149)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1516)

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

PR Comment: https://git.openjdk.org/jdk/pull/29569#issuecomment-3849723754

From prr at openjdk.org  Wed Feb  4 21:21:28 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 21:21:28 GMT
Subject: RFR: 8377167: javax/imageio/ReadAbortTest.java throw NPE when x11
 unavailable
In-Reply-To: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
References: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
Message-ID: <j5SDVozRhVd9p0NQ86MBXSTBiaexAbEWbpoQKbEIQc8=.1fbb45af-c2fd-458d-bb58-05570a27783b@github.com>

On Wed, 4 Feb 2026 14:02:51 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test javax/imageio/ReadAbortTest.java and javax/imageio/WriteAbortTest.java throw java.lang.NullPointerException when x11 display unavailable, because object `path` unable to initial. This PR check the `path` is null or not before use it, this will make test failure report friendly when x11 display unavailable but DISPLAY was seted.
> 
> Change has been verified locally on linux-x64.

I see. An odd case.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29569#pullrequestreview-3753355754

From serb at openjdk.org  Wed Feb  4 21:21:29 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 4 Feb 2026 21:21:29 GMT
Subject: RFR: 8377167: javax/imageio/ReadAbortTest.java throw NPE when x11
 unavailable
In-Reply-To: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
References: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
Message-ID: <450mME1sYRkav8rCHOuOYicdVYLDK10Y5cAE0P5Eq0g=.17265e23-3ff0-4109-a947-ec5b542688c0@github.com>

On Wed, 4 Feb 2026 14:02:51 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test javax/imageio/ReadAbortTest.java and javax/imageio/WriteAbortTest.java throw java.lang.NullPointerException when x11 display unavailable, because object `path` unable to initial. This PR check the `path` is null or not before use it, this will make test failure report friendly when x11 display unavailable but DISPLAY was seted.
> 
> Change has been verified locally on linux-x64.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29569#pullrequestreview-3753356913

From prr at openjdk.org  Wed Feb  4 23:09:57 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 4 Feb 2026 23:09:57 GMT
Subject: RFR: 8377199: Remove AppContext from AWTKeyStroke
Message-ID: <hOjJ0uG72o3M1ls5nbiTvtOP4b-j45qOlfk9Neo2rTM=.2f565dfe-61e1-4fd9-9926-7ce5ec1a5230@github.com>

Remove AppContext from AWTKeyStroke

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

Commit messages:
 - 8377199

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

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

From tr at openjdk.org  Thu Feb  5 07:04:09 2026
From: tr at openjdk.org (Tejesh R)
Date: Thu, 5 Feb 2026 07:04:09 GMT
Subject: RFR: 8377199: Remove AppContext from AWTKeyStroke
In-Reply-To: <hOjJ0uG72o3M1ls5nbiTvtOP4b-j45qOlfk9Neo2rTM=.2f565dfe-61e1-4fd9-9926-7ce5ec1a5230@github.com>
References: <hOjJ0uG72o3M1ls5nbiTvtOP4b-j45qOlfk9Neo2rTM=.2f565dfe-61e1-4fd9-9926-7ce5ec1a5230@github.com>
Message-ID: <k5HEdg7_e5V6c5jqIWmZY49_X7l-2MlTsee_KmoF1e8=.836891d3-c0f4-4260-a244-351f44ae4192@github.com>

On Wed, 4 Feb 2026 23:02:56 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from AWTKeyStroke

LGTM.

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29581#pullrequestreview-3754896833

From tr at openjdk.org  Thu Feb  5 07:09:50 2026
From: tr at openjdk.org (Tejesh R)
Date: Thu, 5 Feb 2026 07:09:50 GMT
Subject: RFR: 8377193: Remove AppContext from SwingUtilties3
In-Reply-To: <Ks3j-dS4eLoh7kU5t__YhFuJojFTevTzQuAFjQ4IOGE=.1f9c07b9-fd47-47a9-ac7a-32da510696d4@github.com>
References: <Ks3j-dS4eLoh7kU5t__YhFuJojFTevTzQuAFjQ4IOGE=.1f9c07b9-fd47-47a9-ac7a-32da510696d4@github.com>
Message-ID: <3RradDoymdkgEp123bEmKqBH3QLOF4LDrWmslB5OdIs=.fbca4ba5-6bff-4f22-9fd1-41bb79dafe4d@github.com>

On Wed, 4 Feb 2026 20:53:05 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SU3

LGTM.

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29580#pullrequestreview-3754913283

From azvegint at openjdk.org  Thu Feb  5 10:58:51 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 5 Feb 2026 10:58:51 GMT
Subject: RFR: 8377193: Remove AppContext from SwingUtilties3
In-Reply-To: <Ks3j-dS4eLoh7kU5t__YhFuJojFTevTzQuAFjQ4IOGE=.1f9c07b9-fd47-47a9-ac7a-32da510696d4@github.com>
References: <Ks3j-dS4eLoh7kU5t__YhFuJojFTevTzQuAFjQ4IOGE=.1f9c07b9-fd47-47a9-ac7a-32da510696d4@github.com>
Message-ID: <CiHsm6Y3IoiDd2FhOqr2wEFHCMSbwA_LvUulFKoe5ds=.9aa6a70e-f67a-4f46-a3bf-5563cacc0709@github.com>

On Wed, 4 Feb 2026 20:53:05 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SU3

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29580#pullrequestreview-3756174532

From syan at openjdk.org  Thu Feb  5 11:59:51 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Feb 2026 11:59:51 GMT
Subject: RFR: 8377167: javax/imageio/ReadAbortTest.java throw NPE when x11
 unavailable
In-Reply-To: <d-mICD53IdbGQbm6G-izhSF8xmfOjXH76ToeKm6oI2w=.7c2af711-6cee-465a-813f-7cc3adcdb51d@github.com>
References: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
 <Z2X2W62JzuIXe9mz6lG1bZ8ufrVzDN47bJChiWLllH8=.15573d17-c84c-4819-9713-2562b0916143@github.com>
 <d-mICD53IdbGQbm6G-izhSF8xmfOjXH76ToeKm6oI2w=.7c2af711-6cee-465a-813f-7cc3adcdb51d@github.com>
Message-ID: <gVurz7agggF15t9BV_4vBrsMafZDcyeRSmoeXFA7CCU=.05f1dff2-6f6d-45a6-b3cd-c352f1905d8d@github.com>

On Wed, 4 Feb 2026 21:02:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This does not make one bit of sense. These tests do nothing with DISPLAY. They do not start AWT.
>
>> This does not make one bit of sense. These tests do nothing with DISPLAY. They do not start AWT.
> 
> Since DISPLAY is set, the GraphicsEnvironment considers the system as headful and tries to connect to display. After this patch, the test will not pass in that environment but will instead show the real stack trace.
> 
> java.awt.AWTError: Can't connect to X11 window server using ':123' as the value of the DISPLAY variable.
>         at java.desktop/sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
>         at java.desktop/sun.awt.X11GraphicsEnvironment.initStatic(X11GraphicsEnvironment.java:100)
>         at java.desktop/sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:57)
>         at java.desktop/sun.awt.PlatformGraphicsInfo.createGE(PlatformGraphicsInfo.java:35)
>         at java.desktop/java.awt.GraphicsEnvironment$LocalGE.createGE(GraphicsEnvironment.java:89)
>         at java.desktop/java.awt.GraphicsEnvironment$LocalGE.<clinit>(GraphicsEnvironment.java:80)
>         at java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:102)
>         at java.desktop/java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1167)
>         at ReadAbortTest.<init>(ReadAbortTest.java:64)
>         at ReadAbortTest.main(ReadAbortTest.java:149)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1516)

Sorry, I did not describe the issue clearly enough. Thanks @mrserb the additionly details.

Thanks the reviews @prrace @mrserb

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

PR Comment: https://git.openjdk.org/jdk/pull/29569#issuecomment-3853148859

From syan at openjdk.org  Thu Feb  5 11:59:53 2026
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Feb 2026 11:59:53 GMT
Subject: Integrated: 8377167: javax/imageio/ReadAbortTest.java throw NPE when
 x11 unavailable
In-Reply-To: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
References: <mk33uDbo6d3ybDlc04ZTg4xsJwwURRN6asTbmIzFTlg=.0fbc25be-2f3a-4e79-bbd5-f722a8bd0eea@github.com>
Message-ID: <TuDZn7MGbPhQ2A_KjmwMPP4rAQTAkmD7VTZx40NMKBU=.686379cb-4bcb-4be3-a4e5-9fa93fb95a0f@github.com>

On Wed, 4 Feb 2026 14:02:51 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test javax/imageio/ReadAbortTest.java and javax/imageio/WriteAbortTest.java throw java.lang.NullPointerException when x11 display unavailable, because object `path` unable to initial. This PR check the `path` is null or not before use it, this will make test failure report friendly when x11 display unavailable but DISPLAY was seted.
> 
> Change has been verified locally on linux-x64.

This pull request has now been integrated.

Changeset: d93bd18d
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d93bd18d67555ba998735196576c337249f4932b
Stats:     23 lines in 2 files changed: 13 ins; 7 del; 3 mod

8377167: javax/imageio/ReadAbortTest.java throw NPE when x11 unavailable

Reviewed-by: prr, serb

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

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

From dnguyen at openjdk.org  Thu Feb  5 18:18:58 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 5 Feb 2026 18:18:58 GMT
Subject: RFR: 8375065: Update LCMS to 2.18
Message-ID: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>

Upgrade Little Color Management System to latest version (2.18).

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

Commit messages:
 - Headers
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/29592/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29592&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8375065
  Stats: 213 lines in 30 files changed: 106 ins; 23 del; 84 mod
  Patch: https://git.openjdk.org/jdk/pull/29592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29592/head:pull/29592

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

From prr at openjdk.org  Thu Feb  5 18:49:09 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Feb 2026 18:49:09 GMT
Subject: Integrated: 8377199: Remove AppContext from AWTKeyStroke
In-Reply-To: <hOjJ0uG72o3M1ls5nbiTvtOP4b-j45qOlfk9Neo2rTM=.2f565dfe-61e1-4fd9-9926-7ce5ec1a5230@github.com>
References: <hOjJ0uG72o3M1ls5nbiTvtOP4b-j45qOlfk9Neo2rTM=.2f565dfe-61e1-4fd9-9926-7ce5ec1a5230@github.com>
Message-ID: <wsMXjKUlEeAofk0WoGNg227zEREDjkIY89tjXA8KKic=.0928b395-fbec-402a-8fa2-4f148aad3c13@github.com>

On Wed, 4 Feb 2026 23:02:56 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from AWTKeyStroke

This pull request has now been integrated.

Changeset: bd9c94d1
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd9c94d19755232070e88af33147f4a3f21f02f4
Stats:     21 lines in 1 file changed: 8 ins; 11 del; 2 mod

8377199: Remove AppContext from AWTKeyStroke

Reviewed-by: tr, azvegint

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

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

From prr at openjdk.org  Thu Feb  5 20:17:39 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Feb 2026 20:17:39 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
 [v3]
In-Reply-To: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
Message-ID: <xo7eO6EA7MAGDuw_Jf84MmLrjnObKm2cNf2s3oeVisA=.ef04d3e0-3429-4d07-994d-6d6bd71bfb4e@github.com>

> Remove AppContext from java/awt/SystemTray

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

  8376992

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29531/files
  - new: https://git.openjdk.org/jdk/pull/29531/files/2930b0e0..bdc42357

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

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

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

From prr at openjdk.org  Thu Feb  5 20:19:25 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Feb 2026 20:19:25 GMT
Subject: RFR: 8375065: Update LCMS to 2.18
In-Reply-To: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
Message-ID: <8esbgMafhZ2Iw3vOSzxN3L203LjFTSLcrUjg8F9MmC4=.a44f5b45-2361-43c0-a332-52c543c94cd0@github.com>

On Thu, 5 Feb 2026 18:12:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Upgrade Little Color Management System to latest version (2.18).

src/java.desktop/share/native/liblcms/cmssamp.c line 30:

> 28: // file:
> 29: //
> 30: /*

You seem to have the GPL twice now in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29592#discussion_r2770974886

From prr at openjdk.org  Thu Feb  5 20:19:37 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Feb 2026 20:19:37 GMT
Subject: Integrated: 8377193: Remove AppContext from SwingUtilties3
In-Reply-To: <Ks3j-dS4eLoh7kU5t__YhFuJojFTevTzQuAFjQ4IOGE=.1f9c07b9-fd47-47a9-ac7a-32da510696d4@github.com>
References: <Ks3j-dS4eLoh7kU5t__YhFuJojFTevTzQuAFjQ4IOGE=.1f9c07b9-fd47-47a9-ac7a-32da510696d4@github.com>
Message-ID: <WsmYpPLx_kpY1VoSOoGIVD7Uhvjo5WkffohpG0QpiC0=.0c21d02d-5cc6-4a76-83c0-56c731517d08@github.com>

On Wed, 4 Feb 2026 20:53:05 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SU3

This pull request has now been integrated.

Changeset: 37ae15a4
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37ae15a4896c700e0a47a43de3330e8879d147c2
Stats:     9 lines in 1 file changed: 2 ins; 3 del; 4 mod

8377193: Remove AppContext from SwingUtilties3

Reviewed-by: tr, azvegint

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

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

From dnguyen at openjdk.org  Thu Feb  5 20:27:27 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 5 Feb 2026 20:27:27 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
Message-ID: <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>

> Upgrade Little Color Management System to latest version (2.18).

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

  Remove redundancy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29592/files
  - new: https://git.openjdk.org/jdk/pull/29592/files/21c3ed20..05a8db00

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

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

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

From dnguyen at openjdk.org  Thu Feb  5 20:27:28 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 5 Feb 2026 20:27:28 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <8esbgMafhZ2Iw3vOSzxN3L203LjFTSLcrUjg8F9MmC4=.a44f5b45-2361-43c0-a332-52c543c94cd0@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
 <8esbgMafhZ2Iw3vOSzxN3L203LjFTSLcrUjg8F9MmC4=.a44f5b45-2361-43c0-a332-52c543c94cd0@github.com>
Message-ID: <ftT7j_qttXIHGP-2YG9JI394BlWRrRs7jUQmNgujgRc=.2185c730-92cc-4594-b510-32baac90ca85@github.com>

On Thu, 5 Feb 2026 20:17:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundancy
>
> src/java.desktop/share/native/liblcms/cmssamp.c line 30:
> 
>> 28: // file:
>> 29: //
>> 30: /*
> 
> You seem to have the GPL twice now in this file.

Thanks! Odd that this happened since I didn't touch this part, but this was incorrect and fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29592#discussion_r2770994098

From prr at openjdk.org  Thu Feb  5 20:45:45 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Feb 2026 20:45:45 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
 <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
Message-ID: <APK_DFrOq4kVw7cdtbGWdFq12UfQ0YJWVL3T2DgZQZA=.af63cfc8-8932-4b18-b1e0-5529d590ca87@github.com>

On Thu, 5 Feb 2026 20:27:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Upgrade Little Color Management System to latest version (2.18).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundancy

So it looks Ok now. What testing did you do ? As well as the automated tests, I recommend building and running the J2Demo and take particular note of the color tab.

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

PR Comment: https://git.openjdk.org/jdk/pull/29592#issuecomment-3856084127

From dnguyen at openjdk.org  Thu Feb  5 21:13:29 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 5 Feb 2026 21:13:29 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <APK_DFrOq4kVw7cdtbGWdFq12UfQ0YJWVL3T2DgZQZA=.af63cfc8-8932-4b18-b1e0-5529d590ca87@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
 <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
 <APK_DFrOq4kVw7cdtbGWdFq12UfQ0YJWVL3T2DgZQZA=.af63cfc8-8932-4b18-b1e0-5529d590ca87@github.com>
Message-ID: <LRj6tOS2gzznJVi39AzlLQ5t3Zzj1ACQQPbezrverAc=.d4070116-46f0-4ec9-884c-71a42dc6b884@github.com>

On Thu, 5 Feb 2026 20:43:11 GMT, Phil Race <prr at openjdk.org> wrote:

> So it looks Ok now. What testing did you do ? As well as the automated tests, I recommend building and running the J2Demo and take particular note of the color tab.

Thanks for the suggestion. I compared the before and after with J2Demo and all looks normal. Checked out the Color tab and tried the various controls as well.

The automated tests all pass as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/29592#issuecomment-3856240031

From prr at openjdk.org  Thu Feb  5 23:07:14 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 5 Feb 2026 23:07:14 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
 <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
Message-ID: <_XEDakK-QIolDLW6MR2fbAnHC719KU0e5WEbE9e4vds=.7778bfdf-7142-4716-be60-8c9c820497b8@github.com>

On Thu, 5 Feb 2026 20:27:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Upgrade Little Color Management System to latest version (2.18).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundancy

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29592#pullrequestreview-3759877800

From dnguyen at openjdk.org  Thu Feb  5 23:28:47 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 5 Feb 2026 23:28:47 GMT
Subject: RFR: 8377192: Remove AppContext from MenuSelectionManager
In-Reply-To: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
References: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
Message-ID: <bOGdzXUuN0Ic9b385Hua-IgzWMlaUBg9RX_MLGSb9iM=.06c85683-15d8-45d3-ab54-a677f264a582@github.com>

On Wed, 4 Feb 2026 20:44:02 GMT, Phil Race <prr at openjdk.org> wrote:

> remove AppContext from Swing's MenuSelectionManager

Built and tested the changes. Confirmed that removing that listener logic seems to be harmless. All looks good to me.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29579#pullrequestreview-3759933375

From duke at openjdk.org  Fri Feb  6 14:29:42 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 6 Feb 2026 14:29:42 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v31]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <JXQ2M_6Ql7UiC70RRITITOLUkrcsziaN6VFmPN9RQ9w=.ce589ed6-ea8c-4964-b9d1-4b458bf9cc85@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Changes point location to prevent pixelpick error in some macosx-aarch64 machines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/614c8bc7..f82f3db2

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

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

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

From duke at openjdk.org  Fri Feb  6 14:47:44 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 6 Feb 2026 14:47:44 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v32]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <Fi5s7cVPto3gRGrR2_yqPzZ_dxj6aFkjSfKoyE-B8K4=.4352979c-90c3-483d-aa48-fbf77b74e274@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 124 commits:

 - Merge branch 'openjdk:master' into jdk-8360498
 - Changes point location to prevent pixelpick error in some macosx-aarch64 machines
 - Merge branch 'openjdk:master' into jdk-8360498
 - Removes some mixing tests from problem list
 - Fixes few issues when sorting formatting ...
 - Updates formatting and removes extra blank line
 - Removes blank lines
 - Removes blank lines
 - Applies suggested change
 - Simplifies return expression
 - ... and 114 more: https://git.openjdk.org/jdk/compare/9f13ec1c...c21fc2a1

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

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=31
  Stats: 130 lines in 9 files changed: 96 ins; 11 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From jwood at openjdk.org  Mon Feb  9 21:25:14 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Mon, 9 Feb 2026 21:25:14 GMT
Subject: RFR: 8377428: VoiceOver Cursor Navigates Invisible Components
Message-ID: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>

This PR prevents VoiceOver from letting me navigate the VoiceOver cursor to hidden components.

### Technical Details

VoiceOver is responsible for a call to `CAccessibility.getChildrenAndRoles(JFrame, JFrame, JAVA_AX_ALL_CHILDREN, false)`.

That last boolean is `allowIgnored`.

When `allowedIgnored == false` we already omitted certain components based on their AccessibleRole. This PR expands our definition of "what should be ignored" to include invisible Components.

### Other Considerations

1. Originally I thought the resolution to this problem would be to change JAVA_AX_ALL_CHILDREN to JAVA_AX_VISIBLE_CHILDREN . And maybe that's still a viable option, but after some research I've come to believe it's simpler/appropriate to change our definition of "ignored".
2. NSViews have a separate property `isHidden`. Another approach to this ticket might be to try to assign `myNSView.isHidden = !myJavaComponent.isVisible()`. Some reading suggests that this might (?) automatically resolve this ticket.

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

Commit messages:
 - 8377428: code cleanup for PR
 - 8377428: add TestVoiceOverHiddenComponentNavigation
 - 8377428: don't include non-visible components

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

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

From serb at openjdk.org  Mon Feb  9 21:27:24 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 21:27:24 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v3]
In-Reply-To: <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
Message-ID: <lcutAFzitKhkZsf9RCVk30q5d8yEj7w3tJrUwzKXhwU=.2e714ec3-66b2-4247-a3b7-bfcafdb6c721@github.com>

On Thu, 22 Jan 2026 17:57:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
>> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
>> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
>> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
>> 
>> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
>> I did that and ran all our existing automated tests on our CI systems.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8373626

src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16nw.c line 922:

> 920:           off += kw;
> 921: 
> 922:           sp += (kw - 1)*chan1;

Just to check: before the patch, the code read data from sp to set pXX, then increased sp. After the patch, the order is different. Is that correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2776761075

From jwood at openjdk.org  Mon Feb  9 21:34:25 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Mon, 9 Feb 2026 21:34:25 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box [v4]
In-Reply-To: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
Message-ID: <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>

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

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

 - 4197755: use directed inherit with getBounds()
   
   This is in response to darcy's comments:
   https://bugs.openjdk.org/browse/JDK-8374859
 - Merge branch 'master' into JDK-4197755
 - 4197755: use directed inherit with getBounds()
   
   This is in response to darcy's comment:
   https://bugs.openjdk.org/browse/JDK-8374859
 - 4197755: Updating copyright year
 - 4197755: update copyright year
 - 4197755: shorten javadoc
 - 4197755: make Arc2D.getBounds() similar to getBounds2D()
 - 4197755: add failing unit test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26715/files
  - new: https://git.openjdk.org/jdk/pull/26715/files/d06c5669..bc980c06

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

  Stats: 854869 lines in 10580 files changed: 550180 ins; 189903 del; 114786 mod
  Patch: https://git.openjdk.org/jdk/pull/26715.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26715/head:pull/26715

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

From prr at openjdk.org  Mon Feb  9 21:34:35 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Feb 2026 21:34:35 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box [v4]
In-Reply-To: <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
 <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
Message-ID: <OAcmAJLqpcVpFGs9u-eir_JdaIVulF9b5WMIyYxiO-0=.0f79e033-c82b-42be-8b67-68b5c80681f6@github.com>

On Mon, 9 Feb 2026 19:27:05 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.
>
> 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 eight additional commits since the last revision:
> 
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comments:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - Merge branch 'master' into JDK-4197755
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comment:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - 4197755: Updating copyright year
>  - 4197755: update copyright year
>  - 4197755: shorten javadoc
>  - 4197755: make Arc2D.getBounds() similar to getBounds2D()
>  - 4197755: add failing unit test

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26715#pullrequestreview-3774368011

From prr at openjdk.org  Mon Feb  9 21:35:56 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Feb 2026 21:35:56 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v32]
In-Reply-To: <TUXq2U04LFslUrmXQ835-ZEGhi-Ppi2hdtOxSRqfaEc=.01ada26e-12f1-455f-ac48-95b9e89f57b2@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <LsdKyc72N6MxqoYLqBJgXePthWC5P3_7RNvjhYJZz7A=.c0e003e6-f645-4448-8ed4-4ffe5c8845c1@github.com>
 <TUXq2U04LFslUrmXQ835-ZEGhi-Ppi2hdtOxSRqfaEc=.01ada26e-12f1-455f-ac48-95b9e89f57b2@github.com>
Message-ID: <CANR9eHFHn8NmVciokXia5y_z4RHwLr4mnT3Fa5Lxe8=.17ca9f53-c9e3-4f5e-86c9-f1e776ad6032@github.com>

On Wed, 7 Jan 2026 20:35:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 124 commits:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8360498
>>  - Changes point location to prevent pixelpick error in some macosx-aarch64 machines
>>  - Merge branch 'openjdk:master' into jdk-8360498
>>  - Removes some mixing tests from problem list
>>  - Fixes few issues when sorting formatting ...
>>  - Updates formatting and removes extra blank line
>>  - Removes blank lines
>>  - Removes blank lines
>>  - Applies suggested change
>>  - Simplifies return expression
>>  - ... and 114 more: https://git.openjdk.org/jdk/compare/9f13ec1c...c21fc2a1
>
> test/jdk/ProblemList.txt line 157:
> 
>> 155: java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java 8370584 windows-x64
>> 156: java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java 8048171 generic-all
>> 157: java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java 8159451 linux-all,windows-all,macosx-all
> 
> 8159451 is about specifically this test, so I don't know why we needed JDK-8361190 to be filed.
> And 8159451 is now no longer used in the problem list. So one way or another it should be closed via this PR.

What is the plan for 8159451 ? Are you closing it as a duplicate ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2775585363

From duke at openjdk.org  Mon Feb  9 21:36:05 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 9 Feb 2026 21:36:05 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v32]
In-Reply-To: <CANR9eHFHn8NmVciokXia5y_z4RHwLr4mnT3Fa5Lxe8=.17ca9f53-c9e3-4f5e-86c9-f1e776ad6032@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <LsdKyc72N6MxqoYLqBJgXePthWC5P3_7RNvjhYJZz7A=.c0e003e6-f645-4448-8ed4-4ffe5c8845c1@github.com>
 <TUXq2U04LFslUrmXQ835-ZEGhi-Ppi2hdtOxSRqfaEc=.01ada26e-12f1-455f-ac48-95b9e89f57b2@github.com>
 <CANR9eHFHn8NmVciokXia5y_z4RHwLr4mnT3Fa5Lxe8=.17ca9f53-c9e3-4f5e-86c9-f1e776ad6032@github.com>
Message-ID: <gufHvpIGw-jrSmHgrLV8PnsmT5JAyddxqXSOFJWo4ns=.de427545-1ea5-4bed-aae6-48a53e426f2e@github.com>

On Fri, 6 Feb 2026 19:01:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 157:
>> 
>>> 155: java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java 8370584 windows-x64
>>> 156: java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java 8048171 generic-all
>>> 157: java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java 8159451 linux-all,windows-all,macosx-all
>> 
>> 8159451 is about specifically this test, so I don't know why we needed JDK-8361190 to be filed.
>> And 8159451 is now no longer used in the problem list. So one way or another it should be closed via this PR.
>
> What is the plan for 8159451 ? Are you closing it as a duplicate ?

JDK-8159451 is now closed as duplicate of JDK-8158801.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2782273289

From psadhukhan at openjdk.org  Mon Feb  9 21:37:59 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 9 Feb 2026 21:37:59 GMT
Subject: RFR: 8376627: Remove AppContext from javax/swing/plaf/metal
 classes [v3]
In-Reply-To: <u3AR-GrsltQqW0U_XljLEipoF3SVM0aSa2r_GtnLrQg=.84c3d0b1-41de-410e-9044-baa82a09e5ea@github.com>
References: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
 <u3AR-GrsltQqW0U_XljLEipoF3SVM0aSa2r_GtnLrQg=.84c3d0b1-41de-410e-9044-baa82a09e5ea@github.com>
Message-ID: <7PNadEx1FPruvZ88OwoXs-ZEnrz8nFwl5atoaXdSKCg=.5834603a-827a-463e-8c4f-56e9c25e445f@github.com>

On Tue, 3 Feb 2026 20:26:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from Metal L&F
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376627

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29474#pullrequestreview-3773099913

From prr at openjdk.org  Mon Feb  9 21:38:15 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Feb 2026 21:38:15 GMT
Subject: Integrated: 8376627: Remove AppContext from javax/swing/plaf/metal
 classes
In-Reply-To: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
References: <qC76RJEAJtx8l4kSLgfPkGizDgcG4vwAYJGU9L5aLp8=.99a73900-72da-41d6-8434-d0b69a45170c@github.com>
Message-ID: <ynDTLkGWnOJY477duV2-zWKkeclonRPUq9L4MbKrXM4=.fed8d502-c5e9-44cb-891a-7aa88502b8e0@github.com>

On Wed, 28 Jan 2026 22:48:02 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from Metal L&F

This pull request has now been integrated.

Changeset: 3065aa48
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3065aa48c9d72bb0c4e2e14a866ec7d9b5515b35
Stats:     438 lines in 9 files changed: 2 ins; 414 del; 22 mod

8376627: Remove AppContext from javax/swing/plaf/metal classes

Reviewed-by: serb, psadhukhan

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

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

From serb at openjdk.org  Mon Feb  9 21:37:55 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 21:37:55 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
 <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
Message-ID: <jTG61ZDPvCLl-hpkIipaxgQA5ilfL7m3J4byll61XkE=.27ba09e0-1f1f-436f-b85f-67904236288b@github.com>

On Thu, 5 Feb 2026 20:27:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Upgrade Little Color Management System to latest version (2.18).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundancy

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29592#pullrequestreview-3765829750

From serb at openjdk.org  Mon Feb  9 21:38:15 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 21:38:15 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v3]
In-Reply-To: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com>
References: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com>
Message-ID: <xvjfotXwt2uNuzb6n14sI7BSpLjHuSx1uJiM7Jtva6s=.4a81a3f7-4cfa-4969-8d1c-b703a47d4ee0@github.com>

> The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts:
> 
>  - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized.
> 
>  - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient.

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-6441373
 - Merge branch 'openjdk:master' into JDK-6441373
 - Update JTableSerialization.java
 - 6441373: Editing JTable is not Serializable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29313/files
  - new: https://git.openjdk.org/jdk/pull/29313/files/c2fb2cd5..203666fd

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

  Stats: 61829 lines in 982 files changed: 31138 ins; 18531 del; 12160 mod
  Patch: https://git.openjdk.org/jdk/pull/29313.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29313/head:pull/29313

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

From jdv at openjdk.org  Mon Feb  9 21:38:00 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 9 Feb 2026 21:38:00 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
 <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
Message-ID: <0RNt3X2tT_lk2YzPUMVujOEViY1zfw6qCasRAJiYpdk=.aa595dc0-785d-445a-8698-ec94b46dae2f@github.com>

On Thu, 5 Feb 2026 20:27:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Upgrade Little Color Management System to latest version (2.18).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundancy

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29592#pullrequestreview-3770953385

From serb at openjdk.org  Mon Feb  9 21:38:28 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 21:38:28 GMT
Subject: Integrated: 6441373: Editing JTable is not Serializable
In-Reply-To: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com>
References: <24EVy67ZyIy7uxUtvIUDB1v-9j1q6vdDl88LoS9K5WY=.37595035-7c7e-4f6e-9554-9276225d608b@github.com>
Message-ID: <MTY1B5SEjqP_gvRL8_GNisf2Q58e7aWjdfqzJUBNHgg=.02212451-963d-4875-a775-e600a0f00421@github.com>

On Tue, 20 Jan 2026 09:12:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The patch implements serialization for editable JTables. Currently, most classes responsible for JTable editing are not serializable, so trying to serialize them causes an exception. The patch has two parts:
> 
>  - The editable JTable is reset to non-editable using the common pattern stopCellEditing + cancelCellEditing. This is added to the compWriteObjectNotify method, which acts as an entry point for serialization of Swing components. It allows actions to be performed before the parent classes are serialized.
> 
>  - The editing coordinates for all JTables are reset to -1. Before this patch, even non-editable JTables had their coordinates reset to 0 from -1 because the fields were transient.

This pull request has now been integrated.

Changeset: f9ded7f8
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9ded7f88cce75151cec32d1ef1f9662ea10431a
Stats:     174 lines in 2 files changed: 174 ins; 0 del; 0 mod

6441373: Editing JTable is not Serializable

Reviewed-by: psadhukhan

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

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

From aivanov at openjdk.org  Mon Feb  9 21:38:21 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Feb 2026 21:38:21 GMT
Subject: RFR: 8376420: Remove AppContext from javax/swing/ImageIcon.java
 [v2]
In-Reply-To: <wVbmbU1UDrfHUjMLETtNoqOQ8sOPeiNtyo59jqJpzCA=.ae4da698-dee7-41ca-8f77-1aa0db136a88@github.com>
References: <vaUUn_KK3pu_VmTbUyypbE13CKxKaaOi1w25Q6da8Qo=.c942d9c5-3ce8-4092-81dd-0cb11a119627@github.com>
 <M0ItqG0nAsD_0b_g32xKBn5BSEIlfyHLYJFIYQkwqmY=.84007701-e210-4ed4-afd7-b2b870160555@github.com>
 <nSv00NbM7XiHiaDX4cIYuh5iuQjTU46_RFmiAAD2b3Q=.54f9d2f4-0f68-4695-a363-c47379a58445@github.com>
 <otIg5X9H6hZwtO0qG45xdKP-kddaZoemBMvKOBykosE=.dd459d72-bd80-4c76-a91e-5d9729dc5674@github.com>
 <Y4i2k7zRMWRut6YoYOseYJJqs2c0qJ8AIC462lJWfvo=.72affa3a-ed15-4174-b71f-6c0ed45fd52e@github.com>
 <IV5ya7QsE_JzdQw8VqQDTULGeLSMzeSPvi7t4iRDgYY=.944add93-3289-4677-bdbb-20808ac72862@github.com>
 <uTjfWpVGy0JrvIojGJdCnWH5Dr1VQxSBI27P6SEoEjw=.18daee52-4d86-414d-94b2-e1f5202cecc2@github.com>
 <xPZlrDrMAW6pk70nrPuZWsuzIcd1TR0USgQumOdfbZE=.4e0ff521-aab7-456b-8019-0be834ec8003@github.com>
 <G3u8m-nQdokZhP1thf2WOJ0YXNn8p_w4lt4KNMevT_k=.d133bad6-8531-4961-a1ff-8b603944ec21@github.com>
 <wVbmbU1UDrfHUjMLETtNoqOQ8sOPeiNtyo59jqJpzCA=.ae4da698-dee7-41ca-8f77-1aa0db136a88@github.com>
Message-ID: <FJiUKNt_0iMiqrJrX4c8zEtV5sriBUwbjy537wcjbpY=.a9452204-0697-4ffe-88ec-4f71949acc00@github.com>

On Fri, 30 Jan 2026 20:50:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The field yes, but the component itself is not a constant.

Does it matter? The component is needed to create the `MediaTracker` instance. Then, media tracker uses `checkImage` and `prepareImage` which delegate to the `Toolkit`.

Can the application change anything in the `Component` instance which would prevent the `checkImage` and `prepareImage` method from working correctly? *Unlikely*.

Either way, I'm for using a different component to create the `MediaTracker` instance instead of re-using the long-deprecated `component` field. It's cleaner and safer, isn't it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29433#discussion_r2782658010

From dnguyen at openjdk.org  Mon Feb  9 21:38:10 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 9 Feb 2026 21:38:10 GMT
Subject: RFR: 8375065: Update LCMS to 2.18 [v2]
In-Reply-To: <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
 <lRFh-WMH_SfnQbU4qQ-bv2NugvFo6e9KVSMEhx_CQ08=.f901ce71-de94-4bc6-befa-a8e806161a76@github.com>
Message-ID: <FRcQVO7AnwESM3e4HoSArZq6TVIZW_hBU2ztWPZXd3U=.81c7f9b9-6652-46f5-afb4-8e7f27396ee4@github.com>

On Thu, 5 Feb 2026 20:27:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Upgrade Little Color Management System to latest version (2.18).
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundancy

@jayathirthrao Could you be a 2nd reviewer for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/29592#issuecomment-3861834811

From dnguyen at openjdk.org  Mon Feb  9 21:38:23 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 9 Feb 2026 21:38:23 GMT
Subject: Integrated: 8375065: Update LCMS to 2.18
In-Reply-To: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
References: <Ohj2SlnYols8HM4f3mqZmAFb8-z9YHunatQIl9Sz77Y=.9607cc31-1354-4bbf-996e-addd57b8d203@github.com>
Message-ID: <rJrEVpAJZjuS17II0MXg3wdBq2iwZY62yeXROssqpGw=.aefa4e34-e524-430e-a7ae-6d70d5faa225@github.com>

On Thu, 5 Feb 2026 18:12:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Upgrade Little Color Management System to latest version (2.18).

This pull request has now been integrated.

Changeset: 3871b889
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3871b8899df79fa85619975bd1c7f59792a839d1
Stats:     189 lines in 30 files changed: 82 ins; 23 del; 84 mod

8375065: Update LCMS to 2.18

Reviewed-by: prr, serb, jdv

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

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

From dnguyen at openjdk.org  Mon Feb  9 21:59:46 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 9 Feb 2026 21:59:46 GMT
Subject: RFR: 8377183: Impossible or redundant condition in
 AwtFrame::_NotifyModalBlocked of awt_Frame.cpp:1635
Message-ID: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>

In awt_Frame.cpp, there is a conditional that includes a "not-null" check in a scenario where null is impossible. Starting on line 1589, each conditional ends in a return statement. The only possibility in awt_Frame.cpp's line 1635 is peer is not null and f is not null. So, checking for `f != NULL` is redundant and unnecessary. And the fix is simply to remove this extraneous check in the conditional.

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

Commit messages:
 - Update copyright year
 - Initial commit

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

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

From prr at openjdk.org  Mon Feb  9 21:59:50 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Feb 2026 21:59:50 GMT
Subject: RFR: 8377183: Impossible or redundant condition in
 AwtFrame::_NotifyModalBlocked of awt_Frame.cpp:1635
In-Reply-To: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
References: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
Message-ID: <eFj3YlNS_75_jU2T_9IRWK8kVPg9e1mOzcNnFO3a944=.b406d0fc-4b35-4f24-82af-51431fd4531c@github.com>

On Mon, 9 Feb 2026 06:26:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> In awt_Frame.cpp, there is a conditional that includes a "not-null" check in a scenario where null is impossible. Starting on line 1589, each conditional ends in a return statement. The only possibility in awt_Frame.cpp's line 1635 is peer is not null and f is not null. So, checking for `f != NULL` is redundant and unnecessary. And the fix is simply to remove this extraneous check in the conditional.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29625#pullrequestreview-3774307924

From serb at openjdk.org  Mon Feb  9 21:59:58 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 21:59:58 GMT
Subject: RFR: 8377183: Impossible or redundant condition in
 AwtFrame::_NotifyModalBlocked of awt_Frame.cpp:1635
In-Reply-To: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
References: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
Message-ID: <TjIlzEaT7L1x3kd27Rn6pVjQDfFQAncNOR3ropQH_BI=.7ff8d0cb-3987-486a-b1ad-9dd04d80adfd@github.com>

On Mon, 9 Feb 2026 06:26:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> In awt_Frame.cpp, there is a conditional that includes a "not-null" check in a scenario where null is impossible. Starting on line 1589, each conditional ends in a return statement. The only possibility in awt_Frame.cpp's line 1635 is peer is not null and f is not null. So, checking for `f != NULL` is redundant and unnecessary. And the fix is simply to remove this extraneous check in the conditional.

src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1635:

> 1633:     }
> 1634: 
> 1635:     if (::IsWindow(f->GetHWnd()))

please update the copyright year

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29625#discussion_r2784189094

From dnguyen at openjdk.org  Mon Feb  9 22:00:02 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 9 Feb 2026 22:00:02 GMT
Subject: RFR: 8377183: Impossible or redundant condition in
 AwtFrame::_NotifyModalBlocked of awt_Frame.cpp:1635
In-Reply-To: <TjIlzEaT7L1x3kd27Rn6pVjQDfFQAncNOR3ropQH_BI=.7ff8d0cb-3987-486a-b1ad-9dd04d80adfd@github.com>
References: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
 <TjIlzEaT7L1x3kd27Rn6pVjQDfFQAncNOR3ropQH_BI=.7ff8d0cb-3987-486a-b1ad-9dd04d80adfd@github.com>
Message-ID: <592aeZTgikhQWNuxCFnzVoFNKDVuS0n2X4qJHFIqoO8=.8f60adcc-8d08-4b02-815e-0579660b4d4d@github.com>

On Mon, 9 Feb 2026 19:34:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In awt_Frame.cpp, there is a conditional that includes a "not-null" check in a scenario where null is impossible. Starting on line 1589, each conditional ends in a return statement. The only possibility in awt_Frame.cpp's line 1635 is peer is not null and f is not null. So, checking for `f != NULL` is redundant and unnecessary. And the fix is simply to remove this extraneous check in the conditional.
>
> src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1635:
> 
>> 1633:     }
>> 1634: 
>> 1635:     if (::IsWindow(f->GetHWnd()))
> 
> please update the copyright year

Thanks! Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29625#discussion_r2784283617

From prr at openjdk.org  Mon Feb  9 22:00:20 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Feb 2026 22:00:20 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v32]
In-Reply-To: <Fi5s7cVPto3gRGrR2_yqPzZ_dxj6aFkjSfKoyE-B8K4=.4352979c-90c3-483d-aa48-fbf77b74e274@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <Fi5s7cVPto3gRGrR2_yqPzZ_dxj6aFkjSfKoyE-B8K4=.4352979c-90c3-483d-aa48-fbf77b74e274@github.com>
Message-ID: <2Yct__oZtBzC19Iq4tOKTf8iaxlcAs2eR1ZKP1sPhX8=.ab83e8cb-2af7-41ad-9269-e5fdf7d44449@github.com>

On Fri, 6 Feb 2026 14:47:44 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 124 commits:
> 
>  - Merge branch 'openjdk:master' into jdk-8360498
>  - Changes point location to prevent pixelpick error in some macosx-aarch64 machines
>  - Merge branch 'openjdk:master' into jdk-8360498
>  - Removes some mixing tests from problem list
>  - Fixes few issues when sorting formatting ...
>  - Updates formatting and removes extra blank line
>  - Removes blank lines
>  - Removes blank lines
>  - Applies suggested change
>  - Simplifies return expression
>  - ... and 114 more: https://git.openjdk.org/jdk/compare/9f13ec1c...c21fc2a1

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26625#pullrequestreview-3775550523

From prr at openjdk.org  Mon Feb  9 22:00:24 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Feb 2026 22:00:24 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v32]
In-Reply-To: <gufHvpIGw-jrSmHgrLV8PnsmT5JAyddxqXSOFJWo4ns=.de427545-1ea5-4bed-aae6-48a53e426f2e@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <LsdKyc72N6MxqoYLqBJgXePthWC5P3_7RNvjhYJZz7A=.c0e003e6-f645-4448-8ed4-4ffe5c8845c1@github.com>
 <TUXq2U04LFslUrmXQ835-ZEGhi-Ppi2hdtOxSRqfaEc=.01ada26e-12f1-455f-ac48-95b9e89f57b2@github.com>
 <CANR9eHFHn8NmVciokXia5y_z4RHwLr4mnT3Fa5Lxe8=.17ca9f53-c9e3-4f5e-86c9-f1e776ad6032@github.com>
 <gufHvpIGw-jrSmHgrLV8PnsmT5JAyddxqXSOFJWo4ns=.de427545-1ea5-4bed-aae6-48a53e426f2e@github.com>
Message-ID: <b8OsFdwA7A41H7HEhTUuRwutL7mlaXuD-N9F1OnXnNE=.ba1d5c05-b8db-4d84-908d-f4ced690f0cc@github.com>

On Mon, 9 Feb 2026 12:06:59 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> What is the plan for 8159451 ? Are you closing it as a duplicate ?
>
> JDK-8159451 is now closed as duplicate of JDK-8158801.

OK. Just be aware that now it is closed but still in the problem list, some one will flag it :-)
However I expect you'll be integrating this very soon and that will fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2784675319

From serb at openjdk.org  Mon Feb  9 22:53:10 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 22:53:10 GMT
Subject: RFR: 8377183: Impossible or redundant condition in
 AwtFrame::_NotifyModalBlocked of awt_Frame.cpp:1635
In-Reply-To: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
References: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
Message-ID: <HBuFXilOrqLBGwahnf4D2QKKGMGD6tiRK42eqyS_OJY=.9e325f72-3b7b-4fc1-96ca-f21b7b9bda01@github.com>

On Mon, 9 Feb 2026 06:26:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> In awt_Frame.cpp, there is a conditional that includes a "not-null" check in a scenario where null is impossible. Starting on line 1589, each conditional ends in a return statement. The only possibility in awt_Frame.cpp's line 1635 is peer is not null and f is not null. So, checking for `f != NULL` is redundant and unnecessary. And the fix is simply to remove this extraneous check in the conditional.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29625#pullrequestreview-3775798000

From serb at openjdk.org  Mon Feb  9 23:08:47 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 23:08:47 GMT
Subject: RFR: 8377428: VoiceOver Cursor Navigates Invisible Components
In-Reply-To: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
References: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
Message-ID: <iVGvBm3kqnM11Uo0sRMKgFv56fw7b-EHpzPZ764KBbM=.85d6378d-5142-4f94-ad6f-4309e2d1bfda@github.com>

On Mon, 9 Feb 2026 08:35:13 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> This PR prevents VoiceOver from letting me navigate the VoiceOver cursor to hidden components.
> 
> ### Technical Details
> 
> VoiceOver is responsible for a call to `CAccessibility.getChildrenAndRoles(JFrame, JFrame, JAVA_AX_ALL_CHILDREN, false)`.
> 
> That last boolean is `allowIgnored`.
> 
> When `allowedIgnored == false` we already omitted certain components based on their AccessibleRole. This PR expands our definition of "what should be ignored" to include invisible Components.
> 
> ### Other Considerations
> 
> 1. Originally I thought the resolution to this problem would be to change JAVA_AX_ALL_CHILDREN to JAVA_AX_VISIBLE_CHILDREN . And maybe that's still a viable option, but after some research I've come to believe it's simpler/appropriate to change our definition of "ignored".
> 2. NSViews have a separate property `isHidden`. Another approach to this ticket might be to try to assign `myNSView.isHidden = !myJavaComponent.isVisible()`. Some reading suggests that this might (?) automatically resolve this ticket.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 1077:

> 1075:         }
> 1076: 
> 1077:         AccessibleStateSet ass = context.getAccessibleStateSet();

Could you please add a test to verify that these methods from AccessibleContext are actually working? I doubt we currently have any tests that cover this code path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29630#discussion_r2784969123

From serb at openjdk.org  Mon Feb  9 23:42:14 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 9 Feb 2026 23:42:14 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
 [v3]
In-Reply-To: <xo7eO6EA7MAGDuw_Jf84MmLrjnObKm2cNf2s3oeVisA=.ef04d3e0-3429-4d07-994d-6d6bd71bfb4e@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
 <xo7eO6EA7MAGDuw_Jf84MmLrjnObKm2cNf2s3oeVisA=.ef04d3e0-3429-4d07-994d-6d6bd71bfb4e@github.com>
Message-ID: <NPjpk2QZxRjOc7NhKui89nc_SpV8SmGgLcrGGU0JdD4=.f3aa7603-26c6-45bb-92bb-be551708b56d@github.com>

On Thu, 5 Feb 2026 20:17:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from java/awt/SystemTray
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376992

src/java.desktop/share/classes/java/awt/SystemTray.java line 371:

> 369:      * </table>
> 370:      * <p>
> 371:      * The {@code listener} listens to property changes only in this context.

The reference to "context" is outdated(possibly in some other javadoc in this class as well)?

src/java.desktop/share/classes/java/awt/SystemTray.java line 464:

> 462:      * calling thread's context.
> 463:      *
> 464:      * @return this thread's context's PropertyChangeSupport

The comment is outdated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29531#discussion_r2785051794
PR Review Comment: https://git.openjdk.org/jdk/pull/29531#discussion_r2785046383

From jwood at openjdk.org  Tue Feb 10 01:07:46 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Tue, 10 Feb 2026 01:07:46 GMT
Subject: RFR: 8377428: VoiceOver Cursor Navigates Invisible Components [v2]
In-Reply-To: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
References: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
Message-ID: <6gKkkewPdR9Kyw3idBwN02A2DP75g9nnJ2XWIicIPw0=.6ed34a65-f401-497c-b6d6-7181f21cb4a9@github.com>

> This PR prevents VoiceOver from letting me navigate the VoiceOver cursor to hidden components.
> 
> ### Technical Details
> 
> VoiceOver is responsible for a call to `CAccessibility.getChildrenAndRoles(JFrame, JFrame, JAVA_AX_ALL_CHILDREN, false)`.
> 
> That last boolean is `allowIgnored`.
> 
> When `allowedIgnored == false` we already omitted certain components based on their AccessibleRole. This PR expands our definition of "what should be ignored" to include invisible Components.
> 
> ### Other Considerations
> 
> 1. Originally I thought the resolution to this problem would be to change JAVA_AX_ALL_CHILDREN to JAVA_AX_VISIBLE_CHILDREN . And maybe that's still a viable option, but after some research I've come to believe it's simpler/appropriate to change our definition of "ignored".
> 2. NSViews have a separate property `isHidden`. Another approach to this ticket might be to try to assign `myNSView.isHidden = !myJavaComponent.isVisible()`. Some reading suggests that this might (?) automatically resolve this ticket.

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8377428: simplify test instructions
   
   Now that there are other interesting components in the UI: we don't need to press CTRL + ALT + UP.
 - 8377428: test condition where axComp is null
   
   If AccessibleComponent is null, when the new CAccessibility.isShowing(..) method falls back to consulting the AccessibleStateSet.
   
   This change makes sure we follow that code path, too.
   
   When I checked CAccessibility.isShowing() in the debugger, I observed:
   
   For "row 1": we had an AccessibleComponent where isShowing() is false
   
   For "row 2": we had a no AccessibleComponent. We checked the AccessibleStateSelection and did not see SHOWING, so CAccessibility.isShowing(context) returned TRUE. This is not accurate, but it's working as designed. We had incomplete information, and we're supposed to err on the side of returning true (to minimize invasive risk). Meanwhile: the test still passes, because then _addChildren recursively inspects the JButton, and CAccessibility.isShowing(buttonContext) returns false.
   
   For "row 3": we had an AccessibleComponent where isShowing() is true.
   
   For "row 4": we had no AccessibleComponent. We checked AccessibleStateSelection and DID see SHOWING, so we returned true.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/29630#discussion_r2784969123

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29630/files
  - new: https://git.openjdk.org/jdk/pull/29630/files/c4e9fc45..724050cd

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

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

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

From jwood at openjdk.org  Tue Feb 10 01:14:17 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Tue, 10 Feb 2026 01:14:17 GMT
Subject: RFR: 8377428: VoiceOver Cursor Navigates Invisible Components [v2]
In-Reply-To: <iVGvBm3kqnM11Uo0sRMKgFv56fw7b-EHpzPZ764KBbM=.85d6378d-5142-4f94-ad6f-4309e2d1bfda@github.com>
References: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
 <iVGvBm3kqnM11Uo0sRMKgFv56fw7b-EHpzPZ764KBbM=.85d6378d-5142-4f94-ad6f-4309e2d1bfda@github.com>
Message-ID: <J7pZbiwGFLEOEnEsFpM1lZgFjFcghNmWjSkKpNVbtY0=.40ccc629-0d02-47db-8432-4909c96e0040@github.com>

On Mon, 9 Feb 2026 23:05:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8377428: simplify test instructions
>>    
>>    Now that there are other interesting components in the UI: we don't need to press CTRL + ALT + UP.
>>  - 8377428: test condition where axComp is null
>>    
>>    If AccessibleComponent is null, when the new CAccessibility.isShowing(..) method falls back to consulting the AccessibleStateSet.
>>    
>>    This change makes sure we follow that code path, too.
>>    
>>    When I checked CAccessibility.isShowing() in the debugger, I observed:
>>    
>>    For "row 1": we had an AccessibleComponent where isShowing() is false
>>    
>>    For "row 2": we had a no AccessibleComponent. We checked the AccessibleStateSelection and did not see SHOWING, so CAccessibility.isShowing(context) returned TRUE. This is not accurate, but it's working as designed. We had incomplete information, and we're supposed to err on the side of returning true (to minimize invasive risk). Meanwhile: the test still passes, because then _addChildren recursively inspects the JButton, and CAccessibility.isShowing(buttonContext) returns false.
>>    
>>    For "row 3": we had an AccessibleComponent where isShowing() is true.
>>    
>>    For "row 4": we had no AccessibleComponent. We checked AccessibleStateSelection and DID see SHOWING, so we returned true.
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/29630#discussion_r2784969123
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 1077:
> 
>> 1075:         }
>> 1076: 
>> 1077:         AccessibleStateSet ass = context.getAccessibleStateSet();
> 
> Could you please add a test to verify that these methods from AccessibleContext are actually working? I doubt we currently have any tests that cover this code path.

I expanded the test to include 4 rows: two visible, and two with no AccessibleComponent.

I confirmed in IntelliJ's debugger that each of the 4 predicted scenarios are addressed. I detailed what I observed here: https://github.com/openjdk/jdk/pull/29630/changes/1a6b53be73e6445d79216abe94a73922b2d17a66

I'm also fine with removing these new references to AccessibleStateSet in `isShowing(..)` entirely. It's intended to be a fallback. I have seen several examples of incomplete accessibility info, but I don't think I've seen a case where the AccessibleComponent is missing. (I have seen cases where the AccessibleStateSet contains incomplete data, though. That's why I only look for the presence of the SHOWING state, but I don't interpret the absence of the SHOWING state as a clear guarantee that we're not showing...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29630#discussion_r2785294585

From acobbs at openjdk.org  Tue Feb 10 02:38:09 2026
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Feb 2026 02:38:09 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v8]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <_JCaqe5WEHkjbjttTdOWj_iqkoUJpkMw3KjoVsem_Jg=.3558dcd1-6c15-49e9-adc9-b67ccd282197@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 141 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Update copyrights to 2026.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159
 - Suppress new unnecessary suppresion warnings created by recent commits.
 - Merge branch 'master' into JDK-8344159
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - ... and 131 more: https://git.openjdk.org/jdk/compare/57eb9c79...4fa9e3f0

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=07
  Stats: 1695 lines in 37 files changed: 1492 ins; 50 del; 153 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 tr at openjdk.org  Tue Feb 10 05:38:18 2026
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Feb 2026 05:38:18 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v32]
In-Reply-To: <Fi5s7cVPto3gRGrR2_yqPzZ_dxj6aFkjSfKoyE-B8K4=.4352979c-90c3-483d-aa48-fbf77b74e274@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <Fi5s7cVPto3gRGrR2_yqPzZ_dxj6aFkjSfKoyE-B8K4=.4352979c-90c3-483d-aa48-fbf77b74e274@github.com>
Message-ID: <PQhnU1IkdAoLaelpO7dU3ZgNcIv1ouNMTSSnuMsshpg=.627e8ca0-2c39-4717-a895-5501eb572ac5@github.com>

On Fri, 6 Feb 2026 14:47:44 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 124 commits:
> 
>  - Merge branch 'openjdk:master' into jdk-8360498
>  - Changes point location to prevent pixelpick error in some macosx-aarch64 machines
>  - Merge branch 'openjdk:master' into jdk-8360498
>  - Removes some mixing tests from problem list
>  - Fixes few issues when sorting formatting ...
>  - Updates formatting and removes extra blank line
>  - Removes blank lines
>  - Removes blank lines
>  - Applies suggested change
>  - Simplifies return expression
>  - ... and 114 more: https://git.openjdk.org/jdk/compare/9f13ec1c...c21fc2a1

test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 83:

> 81:         frame.add(cb);
> 82:         propagateAWTControls(frame);
> 83:         frame.setLocationRelativeTo(null);

Did you forget to remove from here?

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 253:

> 251:     //  it for now.
> 252:     public static void main(String args[]) throws Exception {
> 253:         try {

I don't think try-catch is required here.

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 385:

> 383:     private static boolean isValidForPixelCheck(Component component) {
> 384:         return !(component == null ||
> 385:                  (component instanceof java.awt.Scrollbar) ||

Suggestion:

                 (component instanceof Scrollbar) ||

Same can be done to Button too by adding import.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2785873831
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2785890828
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2785894508

From tr at openjdk.org  Tue Feb 10 06:04:22 2026
From: tr at openjdk.org (Tejesh R)
Date: Tue, 10 Feb 2026 06:04:22 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager
In-Reply-To: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
Message-ID: <4UdckzHah1S-gfITkIEoABc-INNnKGZsyfK5-nt3d6w=.4dbe2865-4075-453e-bb48-a2a1010f4275@github.com>

On Wed, 4 Feb 2026 20:33:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from KeyboardFocusManager

src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 67:

> 65: import sun.awt.AWTAccessor;
> 66: import sun.awt.AWTAccessor.ComponentAccessor;
> 67: import sun.awt.AppContext;

I guess you have missed to remove the import.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29578#discussion_r2785948305

From crschnick at xpipe.io  Tue Feb 10 15:45:00 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 10 Feb 2026 16:45:00 +0100
Subject: Changed behaviour of Desktop.browse on Windows
Message-ID: <8e4f0374-e387-488d-b003-24bb7a8bf4ac@xpipe.io>

Hello,

We recently upgraded our application to JDK 25.0.2 and saw a changed 
behaviour in the Desktop.browse method when opening any non-http URLs on 
Windows. Previously, those URLs were opened with the default application 
associated with that URL scheme, now it always opens the URL in the web 
browser, even though it shouldn't really do that. Even stuff like 
file:// URLs are opened in the browser.

I saw there were PRs for both the AWT and JavaFX implementation for 
opening URLs, but the related JBS issues are private. So I'm guessing 
some kind of security issue?

Is this the expected behaviour now due to security constraints or is 
this a bug?

Best
Christopher Schnick


From serb at openjdk.org  Wed Feb 11 09:28:48 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Feb 2026 09:28:48 GMT
Subject: RFR: 8377428: VoiceOver Cursor Navigates Invisible Components [v2]
In-Reply-To: <6gKkkewPdR9Kyw3idBwN02A2DP75g9nnJ2XWIicIPw0=.6ed34a65-f401-497c-b6d6-7181f21cb4a9@github.com>
References: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
 <6gKkkewPdR9Kyw3idBwN02A2DP75g9nnJ2XWIicIPw0=.6ed34a65-f401-497c-b6d6-7181f21cb4a9@github.com>
Message-ID: <Wvi-_gDCL18bgna9V9l82ICwltKGg1DeMdOXQgRFtIA=.ad81360e-bede-4fed-ad4b-e571e19f97af@github.com>

On Tue, 10 Feb 2026 01:07:46 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> This PR prevents VoiceOver from letting me navigate the VoiceOver cursor to hidden components.
>> 
>> ### Technical Details
>> 
>> VoiceOver is responsible for a call to `CAccessibility.getChildrenAndRoles(JFrame, JFrame, JAVA_AX_ALL_CHILDREN, false)`.
>> 
>> That last boolean is `allowIgnored`.
>> 
>> When `allowedIgnored == false` we already omitted certain components based on their AccessibleRole. This PR expands our definition of "what should be ignored" to include invisible Components.
>> 
>> ### Other Considerations
>> 
>> 1. Originally I thought the resolution to this problem would be to change JAVA_AX_ALL_CHILDREN to JAVA_AX_VISIBLE_CHILDREN . And maybe that's still a viable option, but after some research I've come to believe it's simpler/appropriate to change our definition of "ignored".
>> 2. NSViews have a separate property `isHidden`. Another approach to this ticket might be to try to assign `myNSView.isHidden = !myJavaComponent.isVisible()`. Some reading suggests that this might (?) automatically resolve this ticket.
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8377428: simplify test instructions
>    
>    Now that there are other interesting components in the UI: we don't need to press CTRL + ALT + UP.
>  - 8377428: test condition where axComp is null
>    
>    If AccessibleComponent is null, when the new CAccessibility.isShowing(..) method falls back to consulting the AccessibleStateSet.
>    
>    This change makes sure we follow that code path, too.
>    
>    When I checked CAccessibility.isShowing() in the debugger, I observed:
>    
>    For "row 1": we had an AccessibleComponent where isShowing() is false
>    
>    For "row 2": we had a no AccessibleComponent. We checked the AccessibleStateSelection and did not see SHOWING, so CAccessibility.isShowing(context) returned TRUE. This is not accurate, but it's working as designed. We had incomplete information, and we're supposed to err on the side of returning true (to minimize invasive risk). Meanwhile: the test still passes, because then _addChildren recursively inspects the JButton, and CAccessibility.isShowing(buttonContext) returns false.
>    
>    For "row 3": we had an AccessibleComponent where isShowing() is true.
>    
>    For "row 4": we had no AccessibleComponent. We checked AccessibleStateSelection and DID see SHOWING, so we returned true.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/29630#discussion_r2784969123

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29630#pullrequestreview-3781167232

From dnguyen at openjdk.org  Wed Feb 11 09:30:04 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 11 Feb 2026 09:30:04 GMT
Subject: RFR: 8376998: [macOS] Remove AppContext from AppEventHandler
In-Reply-To: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
References: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
Message-ID: <Yq0z3kqeB8iShSm_UTbVnLzefuWWLCRBTpxJ875OKjI=.afc93e6a-20a3-4d20-a7da-c8eb76755f27@github.com>

On Mon, 2 Feb 2026 21:05:37 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes AppContext from the _AppEventHandler class used on macOS.

Marked as reviewed by dnguyen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29534#pullrequestreview-3780620241

From serb at openjdk.org  Wed Feb 11 09:34:53 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Feb 2026 09:34:53 GMT
Subject: RFR: 8377128: Add missing @Override annotations in "java.beans.*"
 packages
Message-ID: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>

This patch adds missing `@Override `annotations to methods in the java.beans.*" packages that override methods from a superclass or interface.
Only source annotations are added; there are no behavioral changes.

The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

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

Commit messages:
 - 8377128: Add missing @Override annotations in "java.beans.*" packages

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

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

From tr at openjdk.org  Wed Feb 11 09:34:55 2026
From: tr at openjdk.org (Tejesh R)
Date: Wed, 11 Feb 2026 09:34:55 GMT
Subject: RFR: 8377128: Add missing @Override annotations in "java.beans.*"
 packages
In-Reply-To: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
References: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
Message-ID: <ufVoomI56Bf-ibbYQx4010nd1KwloageL9s9u5QPqm0=.7eca47ea-75a8-46d9-917f-53f10fb8436b@github.com>

On Wed, 4 Feb 2026 02:01:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override `annotations to methods in the java.beans.*" packages that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

LGTM

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29553#pullrequestreview-3776826753

From dnguyen at openjdk.org  Wed Feb 11 09:45:58 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 11 Feb 2026 09:45:58 GMT
Subject: Integrated: 8377183: Impossible or redundant condition in
 AwtFrame::_NotifyModalBlocked of awt_Frame.cpp:1635
In-Reply-To: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
References: <Xj3H1hozPmLhfwlmXCqe8PioW2PJ3Tud3sSOK2XQfeo=.a75431b6-7e7c-4ca2-88ac-d203d442c8e7@github.com>
Message-ID: <rCDMkHdaq_g8-2l2f8asR8qXKtq3FhOHS4xZ3mpJG0o=.a281b454-a22d-421b-83eb-ce1ec1df5703@github.com>

On Mon, 9 Feb 2026 06:26:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> In awt_Frame.cpp, there is a conditional that includes a "not-null" check in a scenario where null is impossible. Starting on line 1589, each conditional ends in a return statement. The only possibility in awt_Frame.cpp's line 1635 is peer is not null and f is not null. So, checking for `f != NULL` is redundant and unnecessary. And the fix is simply to remove this extraneous check in the conditional.

This pull request has now been integrated.

Changeset: 3de6dbab
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3de6dbab14e950c1725a48686478e4155c8d93c7
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8377183: Impossible or redundant condition in AwtFrame::_NotifyModalBlocked of awt_Frame.cpp:1635

Reviewed-by: serb, prr

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

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

From duke at openjdk.org  Wed Feb 11 09:46:52 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 11 Feb 2026 09:46:52 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v33]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <zAPDG_3DFJFC7HMJm0hzGzIuAsosXRhtPfr4DsBL0Mw=.d9f212b1-1fd7-4b40-b93b-2f4130633f66@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision:

 - Adds missing import
 - Moves mouse out from frame for precheckcolor
 - Removes fully qualified paths of classes and uses import instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/c21fc2a1..929bd9d0

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

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

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

From kizune at openjdk.org  Wed Feb 11 10:08:48 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 11 Feb 2026 10:08:48 GMT
Subject: RFR: 8376233: Clean up code in Desktop native peer
Message-ID: <loJuaT5pcQrHuXID92ldB_qg3hfS1Es9zBwVc_LKdYw=.157af799-fe70-4f47-b4ac-5762bfc9d270@github.com>

Add corresponding memory release instructions into all the conditional return branches.

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

Commit messages:
 - 8376233: Clean up code in Desktop native peer

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

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

From duke at openjdk.org  Wed Feb 11 14:29:06 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 11 Feb 2026 14:29:06 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v34]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <4vaxxQVVKM2BIaIsJVDtH51Cugeq92TtTHWQvncqowo=.ec4b79c4-4bf3-442b-9237-8082ef319bd7@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Fixes resizing issue in Macos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/929bd9d0..3d304f41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=32-33

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

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

From duke at openjdk.org  Wed Feb 11 17:23:58 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 11 Feb 2026 17:23:58 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v35]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <rsvi7rO3qg3zxypAQ0lLnoiRM7BTW83s4D03Q4_QpjI=.baa66d8c-2991-46be-a8f6-5db173737618@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision:

 - De problem list few tests
 - Removed duplicate frame.setLocationRelativeTo(null);

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/3d304f41..db9cf242

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=33-34

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

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

From duke at openjdk.org  Wed Feb 11 17:24:02 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 11 Feb 2026 17:24:02 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v32]
In-Reply-To: <PQhnU1IkdAoLaelpO7dU3ZgNcIv1ouNMTSSnuMsshpg=.627e8ca0-2c39-4717-a895-5501eb572ac5@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <Fi5s7cVPto3gRGrR2_yqPzZ_dxj6aFkjSfKoyE-B8K4=.4352979c-90c3-483d-aa48-fbf77b74e274@github.com>
 <PQhnU1IkdAoLaelpO7dU3ZgNcIv1ouNMTSSnuMsshpg=.627e8ca0-2c39-4717-a895-5501eb572ac5@github.com>
Message-ID: <Q-a4Vmz9WE0DWAo2ZXUYIsdDXZ5xlrvApzcv1fcCcoU=.420d13e9-59ce-4ca5-88a0-33b540e35c4d@github.com>

On Tue, 10 Feb 2026 05:26:14 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 124 commits:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8360498
>>  - Changes point location to prevent pixelpick error in some macosx-aarch64 machines
>>  - Merge branch 'openjdk:master' into jdk-8360498
>>  - Removes some mixing tests from problem list
>>  - Fixes few issues when sorting formatting ...
>>  - Updates formatting and removes extra blank line
>>  - Removes blank lines
>>  - Removes blank lines
>>  - Applies suggested change
>>  - Simplifies return expression
>>  - ... and 114 more: https://git.openjdk.org/jdk/compare/9f13ec1c...c21fc2a1
>
> test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 83:
> 
>> 81:         frame.add(cb);
>> 82:         propagateAWTControls(frame);
>> 83:         frame.setLocationRelativeTo(null);
> 
> Did you forget to remove from here?

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2794518246

From duke at openjdk.org  Wed Feb 11 17:29:15 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 11 Feb 2026 17:29:15 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v35]
In-Reply-To: <rsvi7rO3qg3zxypAQ0lLnoiRM7BTW83s4D03Q4_QpjI=.baa66d8c-2991-46be-a8f6-5db173737618@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <rsvi7rO3qg3zxypAQ0lLnoiRM7BTW83s4D03Q4_QpjI=.baa66d8c-2991-46be-a8f6-5db173737618@github.com>
Message-ID: <6AG1zM0cuiZLg-hMhKlG7m6vwNgFsaf0OYRmE0hqq7Q=.21d5ecea-ab25-47d2-8559-62141812c4bf@github.com>

On Wed, 11 Feb 2026 17:23:58 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - De problem list few tests
>  - Removed duplicate frame.setLocationRelativeTo(null);

Two tests remain problem listed and were not fixed in this PR: 

java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java 8048171 linux-all,windows-all
java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java 6986109 windows-all

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

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3885857954

From prr at openjdk.org  Wed Feb 11 19:07:10 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 19:07:10 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
 [v4]
In-Reply-To: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
Message-ID: <5CRKGN9vH6e7EeaIKVAl9ksAmhJ1zxh_7iofkZe2nRY=.8ce607b9-5ea2-4407-a845-80f1f2075c20@github.com>

> Remove AppContext from java/awt/SystemTray

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

  8376992

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29531/files
  - new: https://git.openjdk.org/jdk/pull/29531/files/bdc42357..e40cde2a

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

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

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

From prr at openjdk.org  Wed Feb 11 19:26:29 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 19:26:29 GMT
Subject: Integrated: 8376998: [macOS] Remove AppContext from AppEventHandler
In-Reply-To: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
References: <QviujZ32BKM68FE0az7Q1gaWZU8KsBQeukpPdmBWDpA=.2b14b083-b2f0-4909-a008-55a6fce7c861@github.com>
Message-ID: <IpWM8-_RIbwcYMJ6HsYTSdVYAIBOm6Ut8PiAzEr0f5Y=.14d61ba8-610c-447e-b3fa-c2abb378004f@github.com>

On Mon, 2 Feb 2026 21:05:37 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes AppContext from the _AppEventHandler class used on macOS.

This pull request has now been integrated.

Changeset: 39a1d1c8
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39a1d1c801a9cbf8d21051a9af7f6279873ae260
Stats:     49 lines in 2 files changed: 4 ins; 30 del; 15 mod

8376998: [macOS] Remove AppContext from AppEventHandler

Reviewed-by: serb, dnguyen

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

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

From aivanov at openjdk.org  Wed Feb 11 19:48:15 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Feb 2026 19:48:15 GMT
Subject: RFR: 8376233: Clean up code in Desktop native peer
In-Reply-To: <loJuaT5pcQrHuXID92ldB_qg3hfS1Es9zBwVc_LKdYw=.157af799-fe70-4f47-b4ac-5762bfc9d270@github.com>
References: <loJuaT5pcQrHuXID92ldB_qg3hfS1Es9zBwVc_LKdYw=.157af799-fe70-4f47-b4ac-5762bfc9d270@github.com>
Message-ID: <jlRVBjnvGtpPhG2ERMuFxT5qCpAZP_Ur9Is6xYRe9oI=.08d7fc2f-6c18-4ddf-8d45-f77c9fb4c842@github.com>

On Wed, 11 Feb 2026 06:44:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add corresponding memory release instructions into all the conditional return branches.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29667#pullrequestreview-3786983143

From kizune at openjdk.org  Wed Feb 11 20:10:38 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 11 Feb 2026 20:10:38 GMT
Subject: RFR: 8377428: VoiceOver Cursor Navigates Invisible Components [v2]
In-Reply-To: <6gKkkewPdR9Kyw3idBwN02A2DP75g9nnJ2XWIicIPw0=.6ed34a65-f401-497c-b6d6-7181f21cb4a9@github.com>
References: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
 <6gKkkewPdR9Kyw3idBwN02A2DP75g9nnJ2XWIicIPw0=.6ed34a65-f401-497c-b6d6-7181f21cb4a9@github.com>
Message-ID: <WJJFYOC8VEVImQGE9iAuVdV5hMankssDdWczukCTv0k=.6bb69248-8798-42eb-ac44-2a230ed9897d@github.com>

On Tue, 10 Feb 2026 01:07:46 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> This PR prevents VoiceOver from letting me navigate the VoiceOver cursor to hidden components.
>> 
>> ### Technical Details
>> 
>> VoiceOver is responsible for a call to `CAccessibility.getChildrenAndRoles(JFrame, JFrame, JAVA_AX_ALL_CHILDREN, false)`.
>> 
>> That last boolean is `allowIgnored`.
>> 
>> When `allowedIgnored == false` we already omitted certain components based on their AccessibleRole. This PR expands our definition of "what should be ignored" to include invisible Components.
>> 
>> ### Other Considerations
>> 
>> 1. Originally I thought the resolution to this problem would be to change JAVA_AX_ALL_CHILDREN to JAVA_AX_VISIBLE_CHILDREN . And maybe that's still a viable option, but after some research I've come to believe it's simpler/appropriate to change our definition of "ignored".
>> 2. NSViews have a separate property `isHidden`. Another approach to this ticket might be to try to assign `myNSView.isHidden = !myJavaComponent.isVisible()`. Some reading suggests that this might (?) automatically resolve this ticket.
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8377428: simplify test instructions
>    
>    Now that there are other interesting components in the UI: we don't need to press CTRL + ALT + UP.
>  - 8377428: test condition where axComp is null
>    
>    If AccessibleComponent is null, when the new CAccessibility.isShowing(..) method falls back to consulting the AccessibleStateSet.
>    
>    This change makes sure we follow that code path, too.
>    
>    When I checked CAccessibility.isShowing() in the debugger, I observed:
>    
>    For "row 1": we had an AccessibleComponent where isShowing() is false
>    
>    For "row 2": we had a no AccessibleComponent. We checked the AccessibleStateSelection and did not see SHOWING, so CAccessibility.isShowing(context) returned TRUE. This is not accurate, but it's working as designed. We had incomplete information, and we're supposed to err on the side of returning true (to minimize invasive risk). Meanwhile: the test still passes, because then _addChildren recursively inspects the JButton, and CAccessibility.isShowing(buttonContext) returns false.
>    
>    For "row 3": we had an AccessibleComponent where isShowing() is true.
>    
>    For "row 4": we had no AccessibleComponent. We checked AccessibleStateSelection and DID see SHOWING, so we returned true.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/29630#discussion_r2784969123

Seems to be working fine - i haven't noticed any regressions due to this change.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29630#pullrequestreview-3787129622

From prr at openjdk.org  Wed Feb 11 20:51:45 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 20:51:45 GMT
Subject: RFR: 8337853: Remove SunLayoutEngineKey and SunLayoutEngineFactory and
 its cache.
Message-ID: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>

For a long time I've looked at the unnecessary complexity around the code that manages "LayoutEngines' for OpenType font layout.

The code was written a very long time ago when it was supposed that you might have a layout engine that could do Arabic. An unrelated one for Devanagari. An unrelated one for Thai. An unrelated one that knew how to handle some special font format ...

It uses keys to look up these 'instances' thereby creating caches that prevent GC.
It was the cause of this bug report that font instances created from streams that were being used by layout aren't being deleted.
There is also the implication there's some 'state' to the engines, when in fact the methods that
invoke the native code are static methods and no state is relevant. Instances of the native engine are created and discarded as we need them in each layout call. There's minimal overhead to this, and whatever there is, we've been living with for a long time, and if we *were* re-using them we'd have overhead to ensure there was only one thread using it .. which we don't have and don't want.

So this PR deletes various interfaces and classes with LayoutEngine in the name, keeping only SunLayoutEngine, and making all its methods static - most already were.
And fixes one very definite problem with the GCing of created fonts.

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

Commit messages:
 - 8337853

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

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

From prr at openjdk.org  Wed Feb 11 20:55:00 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 20:55:00 GMT
Subject: RFR: 8376233: Clean up code in Desktop native peer
In-Reply-To: <loJuaT5pcQrHuXID92ldB_qg3hfS1Es9zBwVc_LKdYw=.157af799-fe70-4f47-b4ac-5762bfc9d270@github.com>
References: <loJuaT5pcQrHuXID92ldB_qg3hfS1Es9zBwVc_LKdYw=.157af799-fe70-4f47-b4ac-5762bfc9d270@github.com>
Message-ID: <wFIV6V_kgcgaunkZUITOzreZzWtnw29FBgwL2aidFMo=.0ebd6209-8d47-4d07-9c05-2b921ab36a72@github.com>

On Wed, 11 Feb 2026 06:44:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add corresponding memory release instructions into all the conditional return branches.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29667#pullrequestreview-3787418985

From prr at openjdk.org  Wed Feb 11 21:02:55 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 21:02:55 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager [v2]
In-Reply-To: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
Message-ID: <Xqm0gkIVrG-B6_XTzvwsXFe5r3cSAkQ-RFtx5PQOoX8=.1faf84e2-e95e-47ee-aa20-182983289fb2@github.com>

> Remove AppContext from KeyboardFocusManager

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

  8377191

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29578/files
  - new: https://git.openjdk.org/jdk/pull/29578/files/dd5134b5..4422ab50

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

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

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

From prr at openjdk.org  Wed Feb 11 21:02:57 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 21:02:57 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager [v2]
In-Reply-To: <4UdckzHah1S-gfITkIEoABc-INNnKGZsyfK5-nt3d6w=.4dbe2865-4075-453e-bb48-a2a1010f4275@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
 <4UdckzHah1S-gfITkIEoABc-INNnKGZsyfK5-nt3d6w=.4dbe2865-4075-453e-bb48-a2a1010f4275@github.com>
Message-ID: <r9tihTcnUcZcn_LmwCoK7fMfkqDM4CinMDOKSlt_-18=.909fe016-6d3e-4ed8-ad83-e21070d2fe59@github.com>

On Tue, 10 Feb 2026 05:55:29 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377191
>
> src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java line 67:
> 
>> 65: import sun.awt.AWTAccessor;
>> 66: import sun.awt.AWTAccessor.ComponentAccessor;
>> 67: import sun.awt.AppContext;
> 
> I guess you have missed to remove the import.

I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29578#discussion_r2795500026

From prr at openjdk.org  Wed Feb 11 21:02:58 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 21:02:58 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager [v2]
In-Reply-To: <_4JmpXvJqSRQNrC9UYelWFIcUOSeRKqzvhsV0i_LP0I=.a0b92f6c-c2d5-4f92-a33e-32ae2ab76add@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
 <_4JmpXvJqSRQNrC9UYelWFIcUOSeRKqzvhsV0i_LP0I=.a0b92f6c-c2d5-4f92-a33e-32ae2ab76add@github.com>
Message-ID: <AZr4kQOmmUEW6-ueXb2CyqxEQxQPm4-dAd3fmUn_QaU=.a5c6b43c-2f91-4598-a73d-66d302f52736@github.com>

On Mon, 9 Feb 2026 22:57:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377191
>
> src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java line 265:
> 
>> 263:     static boolean sendMessage(Component target, AWTEvent e) {
>> 264:         e.isPosted = true;
>> 265:         final SentEvent se = new DefaultKeyboardFocusManagerSentEvent(e);
> 
> "final" for local variable is rarely used. Is it necessary here?

I did not add that. It was already there. See line 275 in the "original" code.
There may have been a reason but I don't see it. However it isn't a problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29578#discussion_r2786009001

From prr at openjdk.org  Wed Feb 11 21:13:41 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 21:13:41 GMT
Subject: RFR: 8376994: Remove AppContext from
 sun/awt/datatransfer/DataTransferer.java [v2]
In-Reply-To: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
References: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
Message-ID: <xskPiGokj9meVlw8dl_Mg2yP_5dkDX0Qv5Rb__W2Itk=.84228ac7-0f39-40bd-a8fe-1dad65c64f47@github.com>

> Remove AppContext from sun/awt/datatransfer/DataTransferer.java

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

  8376994

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29532/files
  - new: https://git.openjdk.org/jdk/pull/29532/files/7ab028df..9ed7d8e0

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

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

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

From prr at openjdk.org  Wed Feb 11 21:13:43 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 21:13:43 GMT
Subject: RFR: 8376994: Remove AppContext from
 sun/awt/datatransfer/DataTransferer.java [v2]
In-Reply-To: <SAG23y5meOzv21lP6IIUbu4IdEuVIwl1scvk-AWD2TU=.fb484ccd-a18b-478a-a64a-9744b25283b1@github.com>
References: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
 <SAG23y5meOzv21lP6IIUbu4IdEuVIwl1scvk-AWD2TU=.fb484ccd-a18b-478a-a64a-9744b25283b1@github.com>
Message-ID: <9lidy9XHkXK39jEZtFbA3SVFcc00tDP_C21NaZzmiPA=.25f9453a-519c-4053-9ed5-cf53798d31e4@github.com>

On Tue, 3 Feb 2026 20:01: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:
>> 
>>   8376994
>
> src/java.desktop/share/classes/sun/awt/datatransfer/DataTransferer.java line 155:
> 
>> 153:             Collections.synchronizedMap(new HashMap<>());
>> 154: 
>> 155:     private static volatile Runnable dataConverterInstance;
> 
> Doc about "pending data conversion" can be preserved?

I added a comment to the new variable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29532#discussion_r2795546442

From prr at openjdk.org  Wed Feb 11 21:14:31 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Feb 2026 21:14:31 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box [v4]
In-Reply-To: <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
 <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
Message-ID: <9OCNQQD_Zir73VUoOZ_2DQbaOqXKIXtOCOM6VDkeFKU=.25b89f88-7749-4fbe-8286-ff07546f0964@github.com>

On Mon, 9 Feb 2026 21:34:25 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.
>
> 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 eight additional commits since the last revision:
> 
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comments:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - Merge branch 'master' into JDK-4197755
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comment:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - 4197755: Updating copyright year
>  - 4197755: update copyright year
>  - 4197755: shorten javadoc
>  - 4197755: make Arc2D.getBounds() similar to getBounds2D()
>  - 4197755: add failing unit test

@prsadhuk please be 2nd reviewer on this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3887250425

From serb at openjdk.org  Wed Feb 11 21:37:49 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Feb 2026 21:37:49 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
 [v4]
In-Reply-To: <5CRKGN9vH6e7EeaIKVAl9ksAmhJ1zxh_7iofkZe2nRY=.8ce607b9-5ea2-4407-a845-80f1f2075c20@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
 <5CRKGN9vH6e7EeaIKVAl9ksAmhJ1zxh_7iofkZe2nRY=.8ce607b9-5ea2-4407-a845-80f1f2075c20@github.com>
Message-ID: <ACy-glk3dstFVUsXfmvwXhj9DGVp5yFmHucLotFDHiw=.d3b1fbcc-1c7d-41b9-8a53-4a8ec9fb0fe3@github.com>

On Wed, 11 Feb 2026 19:07:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from java/awt/SystemTray
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376992

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29531#pullrequestreview-3787595828

From serb at openjdk.org  Wed Feb 11 21:45:27 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Feb 2026 21:45:27 GMT
Subject: RFR: 8376994: Remove AppContext from
 sun/awt/datatransfer/DataTransferer.java [v2]
In-Reply-To: <xskPiGokj9meVlw8dl_Mg2yP_5dkDX0Qv5Rb__W2Itk=.84228ac7-0f39-40bd-a8fe-1dad65c64f47@github.com>
References: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
 <xskPiGokj9meVlw8dl_Mg2yP_5dkDX0Qv5Rb__W2Itk=.84228ac7-0f39-40bd-a8fe-1dad65c64f47@github.com>
Message-ID: <tdpZr-rE4TJgjfq9b4Vg_sN6zEEjHqWM2932q5kff0A=.2362bdcf-10a9-43b7-9d5c-ad7f08c71b14@github.com>

On Wed, 11 Feb 2026 21:13:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from sun/awt/datatransfer/DataTransferer.java
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376994

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29532#pullrequestreview-3787627828

From serb at openjdk.org  Thu Feb 12 02:18:17 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Feb 2026 02:18:17 GMT
Subject: RFR: 8376996: Remove AppContext usage from SunClipboard.java [v2]
In-Reply-To: <HcJUPWsi9VrTRQ_49yp6VLwTUsfAOcm4hflywm0ygw4=.87789fed-17d7-46cd-aeb3-b415dd38e21b@github.com>
References: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
 <HcJUPWsi9VrTRQ_49yp6VLwTUsfAOcm4hflywm0ygw4=.87789fed-17d7-46cd-aeb3-b415dd38e21b@github.com>
Message-ID: <qiVLzHVCou8R42bUWlginz3CgEGwQuC9_tGjiavgS50=.2310c475-55a5-46b9-8e70-7f7a60ee7823@github.com>

On Tue, 3 Feb 2026 20:28:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from SunClipboard.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376996

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29533#pullrequestreview-3788410991

From serb at openjdk.org  Thu Feb 12 07:21:11 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Feb 2026 07:21:11 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons when
 -Xcheck:jni is enabled
Message-ID: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>

ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8376253
 - 8376253: [macOS] FileSystemView may not report system icons when -Xcheck:jni is enabled

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

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

From jwood at openjdk.org  Thu Feb 12 08:42:05 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Thu, 12 Feb 2026 08:42:05 GMT
Subject: RFR: 8377745: VoiceOver Identifies Hyperlink as Text
Message-ID: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>

If we use `new AccessibleRole("AXLink") {}`, then VoiceOver reads this more like other native apps.

There isn't a similar precedent in CAccessibility for creating custom AccessibleRoles, so I won't mind if this PR is declined. (But I don't know off the top of my head where else to inject code to get the desired result...)

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

Commit messages:
 - 8377745: add unit test
 - 8377745: use custom "AXLink" AccessibleRole

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

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

From mickleness at gmail.com  Thu Feb 12 08:49:05 2026
From: mickleness at gmail.com (Jeremy Wood)
Date: Thu, 12 Feb 2026 08:49:05 +0000
Subject: Maintaining CAccessibility
Message-ID: <em4ace0b31-2dd5-4809-b554-5f989a1e9ae5@gmail.com>

If I open a PR to clean up CAccessibility.java: is there any interest in 
code reviewing it?

Just tonight I think I?ve identified three topics to explore:

A. The native method `roleKey(AccessibleRole)` looks redundant compared 
to `AWTAccessor.getAccessibleBundleAccessor().getKey(AccessibleRole)`. I 
think we can remove one. (Or at least better document when to use each.)

B. There?s an if statement: `if (?label?.equals(?`. This looks like it 
will break if the Locale is not English. However it (mostly) doesn?t, 
because?

C. The method getAccessibleRoleForLabel also appears mostly redundant 
compared to AccessibleJLabel#getAccessibleRole. (See 2021 commit 
70bad89b012eb200ca1e76f384a6e5fb307cf26d for 8277497 ).

I could submit a PR to clean these up, but I know sometime?s it's hard 
to justify maintenance work without a customer-facing issue.

Any thoughts?

Regards,
  - Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20260212/01ccb161/attachment.htm>

From kizune at openjdk.org  Thu Feb 12 16:34:58 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 12 Feb 2026 16:34:58 GMT
Subject: Integrated: 8376233: Clean up code in Desktop native peer
In-Reply-To: <loJuaT5pcQrHuXID92ldB_qg3hfS1Es9zBwVc_LKdYw=.157af799-fe70-4f47-b4ac-5762bfc9d270@github.com>
References: <loJuaT5pcQrHuXID92ldB_qg3hfS1Es9zBwVc_LKdYw=.157af799-fe70-4f47-b4ac-5762bfc9d270@github.com>
Message-ID: <sYngbQO77OrKmYCekUcuLO25Oa6auaQ6M-O2IuOx9G4=.664ab324-fdaa-4b06-add4-a524d903901a@github.com>

On Wed, 11 Feb 2026 06:44:32 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Add corresponding memory release instructions into all the conditional return branches.

This pull request has now been integrated.

Changeset: c73f05be
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c73f05bec95c3ef0d8b6235b67478352db9a48a9
Stats:     7 lines in 2 files changed: 5 ins; 0 del; 2 mod

8376233: Clean up code in Desktop native peer

Reviewed-by: aivanov, prr

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

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

From azvegint at openjdk.org  Thu Feb 12 17:35:26 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 12 Feb 2026 17:35:26 GMT
Subject: RFR: 8376992: Remove AppContext from SystemTray implementation
 [v4]
In-Reply-To: <5CRKGN9vH6e7EeaIKVAl9ksAmhJ1zxh_7iofkZe2nRY=.8ce607b9-5ea2-4407-a845-80f1f2075c20@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
 <5CRKGN9vH6e7EeaIKVAl9ksAmhJ1zxh_7iofkZe2nRY=.8ce607b9-5ea2-4407-a845-80f1f2075c20@github.com>
Message-ID: <v5OPRhCS3uVjuPItk1E1CiyrhoWaQ4c3Ul-hRHThEcg=.65eae3bb-6ec3-4e6e-ba16-bbe1852b6184@github.com>

On Wed, 11 Feb 2026 19:07:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from java/awt/SystemTray
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376992

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29531#pullrequestreview-3792529364

From prr at openjdk.org  Thu Feb 12 17:46:08 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Feb 2026 17:46:08 GMT
Subject: RFR: 8377128: Add missing @Override annotations in "java.beans.*"
 packages
In-Reply-To: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
References: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
Message-ID: <eLwf0Y4YC21qZvXZu80qkQwTl3X4_YiQ1mtfYxmzs0w=.5369ae82-89e4-4806-a3c6-2da1427bae5f@github.com>

On Wed, 4 Feb 2026 02:01:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override `annotations to methods in the java.beans.*" packages that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29553#pullrequestreview-3792600986

From crschnick at xpipe.io  Thu Feb 12 17:55:44 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Thu, 12 Feb 2026 18:55:44 +0100
Subject: Changed behaviour of Desktop.browse on Windows
In-Reply-To: <8e4f0374-e387-488d-b003-24bb7a8bf4ac@xpipe.io>
References: <8e4f0374-e387-488d-b003-24bb7a8bf4ac@xpipe.io>
Message-ID: <054aa5b3-bd0b-438f-bd3c-c87e84bba175@xpipe.io>

Does anyone have input on this? I had to revert all deployments I made 
with JDK 25.0.2 back to JDK 25.0.1 due to it breaking various different 
features that relied on opening URLs of specific applications. The same 
will probably also apply to many other applications out there.

Is there a supported way in JDK 25.0.2 to open an URL with the 
associated application instead of the web browser on Windows?

On 10/02/2026 16:45, Christopher Schnick wrote:
> Hello,
>
> We recently upgraded our application to JDK 25.0.2 and saw a changed 
> behaviour in the Desktop.browse method when opening any non-http URLs 
> on Windows. Previously, those URLs were opened with the default 
> application associated with that URL scheme, now it always opens the 
> URL in the web browser, even though it shouldn't really do that. Even 
> stuff like file:// URLs are opened in the browser.
>
> I saw there were PRs for both the AWT and JavaFX implementation for 
> opening URLs, but the related JBS issues are private. So I'm guessing 
> some kind of security issue?
>
> Is this the expected behaviour now due to security constraints or is 
> this a bug?
>
> Best
> Christopher Schnick
>

From prr at openjdk.org  Thu Feb 12 18:09:28 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Feb 2026 18:09:28 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v35]
In-Reply-To: <rsvi7rO3qg3zxypAQ0lLnoiRM7BTW83s4D03Q4_QpjI=.baa66d8c-2991-46be-a8f6-5db173737618@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <rsvi7rO3qg3zxypAQ0lLnoiRM7BTW83s4D03Q4_QpjI=.baa66d8c-2991-46be-a8f6-5db173737618@github.com>
Message-ID: <qOxWyY65GTcSfPd9BXqc28q-xf6YagwRDLj4WkqMm-A=.2811d979-438d-49e3-a2a4-4cf7e4434a48@github.com>

On Wed, 11 Feb 2026 17:23:58 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - De problem list few tests
>  - Removed duplicate frame.setLocationRelativeTo(null);

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26625#pullrequestreview-3792759208

From prr at openjdk.org  Thu Feb 12 23:44:40 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Feb 2026 23:44:40 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled
In-Reply-To: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
Message-ID: <g6kqJ9bFhYcxA6J5Jp73Pye44sQvASRWEd7OFyBgUjo=.b70da9f4-2dfe-409e-b073-3928ddc596cf@github.com>

On Wed, 4 Feb 2026 09:05:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back

This passes for me on my Apple Silicon Mac running macOS 15.7
However it fails on an Intel Mac (in our CI) also running macOS 15.7
I find that puzzling. I don't have access to that Mac to reproduce it and perhaps it is something to do with the way the CI system is configured that is causing it .. but here's the log.

----------System.out:(4/211)----------
LookAndFeel: javax.swing.plaf.metal.MetalLookAndFeel
LookAndFeel: javax.swing.plaf.nimbus.NimbusLookAndFeel
LookAndFeel: com.sun.java.swing.plaf.motif.MotifLookAndFeel
LookAndFeel: com.apple.laf.AquaLookAndFeel
----------System.err:(24/1668)----------
java.lang.reflect.InvocationTargetException
	at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1303)
	at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1278)
	at SystemIconPixelDataTest.main(SystemIconPixelDataTest.java:50)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1527)
Caused by: java.lang.RuntimeException: All pixels are zero
	at SystemIconPixelDataTest.test(SystemIconPixelDataTest.java:90)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:714)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:693)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

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

PR Comment: https://git.openjdk.org/jdk/pull/29563#issuecomment-3893992519

From prr at openjdk.org  Fri Feb 13 00:04:42 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Feb 2026 00:04:42 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled
In-Reply-To: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
Message-ID: <cd7TM9IfHiScsnxEa5TvYcdzVXlvqwVHvpBqDGymlKI=.40d6d32a-ee58-4d5a-8a13-1cb6d2b97b15@github.com>

On Wed, 4 Feb 2026 09:05:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back

FWIW I see the aarch64 version of the test is still pending. I thought it had passed.
So if it fails there too it is probably a config issue and since these headless tests are run without desktop access, I wonder if this test in fact really needs it for Aqua. I'm running on my desktop so it has access so that isn't the headless environment.

Maybe you need to make this test headful - at least for Mac.

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

PR Comment: https://git.openjdk.org/jdk/pull/29563#issuecomment-3894039518

From serb at openjdk.org  Fri Feb 13 00:42:33 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Feb 2026 00:42:33 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled
In-Reply-To: <cd7TM9IfHiScsnxEa5TvYcdzVXlvqwVHvpBqDGymlKI=.40d6d32a-ee58-4d5a-8a13-1cb6d2b97b15@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
 <cd7TM9IfHiScsnxEa5TvYcdzVXlvqwVHvpBqDGymlKI=.40d6d32a-ee58-4d5a-8a13-1cb6d2b97b15@github.com>
Message-ID: <YWpmCzhaav5e7gWXtFjpqs0Ja0dckGiIX5bz1qhV9cc=.ea855508-0b17-4833-84c6-06b36fd37537@github.com>

On Thu, 12 Feb 2026 23:57:49 GMT, Phil Race <prr at openjdk.org> wrote:

>Maybe you need to make this test headful - at least for Mac.

I can change that, but it sounds strange since this api should not depend on a headful vs headless environment.

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

PR Comment: https://git.openjdk.org/jdk/pull/29563#issuecomment-3894171916

From dnguyen at openjdk.org  Fri Feb 13 00:44:32 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 13 Feb 2026 00:44:32 GMT
Subject: RFR: 8376996: Remove AppContext usage from SunClipboard.java [v2]
In-Reply-To: <HcJUPWsi9VrTRQ_49yp6VLwTUsfAOcm4hflywm0ygw4=.87789fed-17d7-46cd-aeb3-b415dd38e21b@github.com>
References: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
 <HcJUPWsi9VrTRQ_49yp6VLwTUsfAOcm4hflywm0ygw4=.87789fed-17d7-46cd-aeb3-b415dd38e21b@github.com>
Message-ID: <5hCAwx-wsqJ43Zh183cluucMPu0wAPh0uqMoia_p8uc=.8e48957c-b8fa-4b18-8f1a-75614251133a@github.com>

On Tue, 3 Feb 2026 20:28:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from SunClipboard.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376996

Marked as reviewed by dnguyen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29533#pullrequestreview-3794460147

From prr at openjdk.org  Fri Feb 13 01:08:25 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Feb 2026 01:08:25 GMT
Subject: Integrated: 8376996: Remove AppContext usage from SunClipboard.java
In-Reply-To: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
References: <5VLN0_KSQOcybXdS4c4RrCWbSk7XZZtBZfw9Lipc1Qg=.fd9a6f2a-7800-421b-9330-d84413129dac@github.com>
Message-ID: <rAg3l5Y6WNNJVs2c1AuopmpPj33nJzEdf--AgF9PgeQ=.1e82cdc9-d729-44bc-845a-1c0c2873b11c@github.com>

On Mon, 2 Feb 2026 20:56:02 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SunClipboard.

This pull request has now been integrated.

Changeset: eecc0d69
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eecc0d69047d88840b18a66a4a6f940c0665ab50
Stats:     114 lines in 3 files changed: 13 ins; 75 del; 26 mod

8376996: Remove AppContext usage from SunClipboard.java

Reviewed-by: serb, dnguyen

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

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

From serb at openjdk.org  Fri Feb 13 01:48:19 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Feb 2026 01:48:19 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled [v2]
In-Reply-To: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
Message-ID: <YLdhwdGeXIctXt6HOJYSudhDPKnvIykNBTri8gBxv-w=.f613e0f2-16e9-41aa-b4b3-eafdc705943d@github.com>

> ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back

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

  Add headful keyword

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29563/files
  - new: https://git.openjdk.org/jdk/pull/29563/files/67f798ba..04e803f1

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

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

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

From serb at openjdk.org  Fri Feb 13 02:33:18 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Feb 2026 02:33:18 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled
In-Reply-To: <YWpmCzhaav5e7gWXtFjpqs0Ja0dckGiIX5bz1qhV9cc=.ea855508-0b17-4833-84c6-06b36fd37537@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
 <cd7TM9IfHiScsnxEa5TvYcdzVXlvqwVHvpBqDGymlKI=.40d6d32a-ee58-4d5a-8a13-1cb6d2b97b15@github.com>
 <YWpmCzhaav5e7gWXtFjpqs0Ja0dckGiIX5bz1qhV9cc=.ea855508-0b17-4833-84c6-06b36fd37537@github.com>
Message-ID: <vhTysmVN3NzGXtkH5rKd8089drH0OMNhC9rtsLDMTPY=.9386e8e0-3dd7-4f0e-8871-cf3e4653179e@github.com>

On Fri, 13 Feb 2026 00:39:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I can change that, but it sounds strange since this api should not depend on a headful vs headless environment.

I found the reason: the Aqua L&F has a headless check that skips all image creation. It was added to skip Aqua theme rendering via JRSUI, but it is too strict it also skips icons read from the file system, which do not need a screen session. Will work on that in separate bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/29563#issuecomment-3894477207

From serb at openjdk.org  Fri Feb 13 04:37:35 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Feb 2026 04:37:35 GMT
Subject: RFR: 8377128: Add missing @Override annotations in "java.beans.*"
 packages [v2]
In-Reply-To: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
References: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
Message-ID: <_9n1OlmJcLk3VC1oWgHLuLMlhsH8k8kZGeV1x3LNw7Y=.6478f5fe-eda2-40b9-96c2-80b0a4c79a28@github.com>

> This patch adds missing `@Override `annotations to methods in the java.beans.*" packages that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

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-8377128
 - 8377128: Add missing @Override annotations in "java.beans.*" packages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29553/files
  - new: https://git.openjdk.org/jdk/pull/29553/files/8850e2ba..e9c2b217

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

  Stats: 85161 lines in 1635 files changed: 41724 ins; 22926 del; 20511 mod
  Patch: https://git.openjdk.org/jdk/pull/29553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29553/head:pull/29553

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

From tr at openjdk.org  Fri Feb 13 05:42:22 2026
From: tr at openjdk.org (Tejesh R)
Date: Fri, 13 Feb 2026 05:42:22 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager [v2]
In-Reply-To: <Xqm0gkIVrG-B6_XTzvwsXFe5r3cSAkQ-RFtx5PQOoX8=.1faf84e2-e95e-47ee-aa20-182983289fb2@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
 <Xqm0gkIVrG-B6_XTzvwsXFe5r3cSAkQ-RFtx5PQOoX8=.1faf84e2-e95e-47ee-aa20-182983289fb2@github.com>
Message-ID: <o_TbHE29ztei4zS5lbLKNcoXvFQtuTA3stOANBlfF8g=.8de9fd96-15ee-4d71-90c9-7d4395facdc2@github.com>

On Wed, 11 Feb 2026 21:02:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from KeyboardFocusManager
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377191

LGTM.

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29578#pullrequestreview-3795160926

From tr at openjdk.org  Fri Feb 13 06:13:55 2026
From: tr at openjdk.org (Tejesh R)
Date: Fri, 13 Feb 2026 06:13:55 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v35]
In-Reply-To: <rsvi7rO3qg3zxypAQ0lLnoiRM7BTW83s4D03Q4_QpjI=.baa66d8c-2991-46be-a8f6-5db173737618@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <rsvi7rO3qg3zxypAQ0lLnoiRM7BTW83s4D03Q4_QpjI=.baa66d8c-2991-46be-a8f6-5db173737618@github.com>
Message-ID: <OqDjZVGMdSBAtLH7DC6cei0sB6iZlXvNHn44b66_21A=.14e5d833-4857-4c82-b7f6-2c9887e48234@github.com>

On Wed, 11 Feb 2026 17:23:58 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - De problem list few tests
>  - Removed duplicate frame.setLocationRelativeTo(null);

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26625#pullrequestreview-3795253853

From serb at openjdk.org  Fri Feb 13 07:44:17 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Feb 2026 07:44:17 GMT
Subject: Integrated: 8377128: Add missing @Override annotations in
 "java.beans.*" packages
In-Reply-To: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
References: <h4ObaAzs51KohwqMy-kvpbGSohWU4FwkmDl22PlMmoM=.c05e5e31-b131-4edc-93f8-c0781033b7fc@github.com>
Message-ID: <AKLPcppDgqfhST90cUjYkDxKl-lkSRsTRv1jROehVWs=.968806f2-5caf-48e8-a3a7-17bcbec276a1@github.com>

On Wed, 4 Feb 2026 02:01:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override `annotations to methods in the java.beans.*" packages that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

This pull request has now been integrated.

Changeset: 93c87ffe
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93c87ffe4037221725798f6d0ba78cb20d67fcab
Stats:     219 lines in 26 files changed: 193 ins; 0 del; 26 mod

8377128: Add missing @Override annotations in "java.beans.*" packages

Reviewed-by: tr, prr

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

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

From duke at openjdk.org  Fri Feb 13 08:15:54 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 13 Feb 2026 08:15:54 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v36]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <WjVNj7G3LB-87LHrhYfcctVogTyBguDwH9h4wVUQTjs=.47cde889-e1f4-4771-bf71-aff693ea949b@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Re problem list unstable test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/db9cf242..a2b9a388

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=34-35

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

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

From psadhukhan at openjdk.org  Fri Feb 13 09:18:37 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 13 Feb 2026 09:18:37 GMT
Subject: Withdrawn: 6441373: Editing JTable is not Serializable
In-Reply-To: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
Message-ID: <MXtkQ3eOdSGmQ0lpoAmjeVEPLJ-TduqEvmsWacD_o5s=.a8bb566d-886f-4004-819a-fb6b02e0b7c1@github.com>

On Wed, 3 Dec 2025 10:05:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is when JTable is in editing mode, it is not Serializable as it gives exception
> 
> java.io.NotSerializableException: java.lang.reflect.Constructor
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1149) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502)
>         at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1467)
>         at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1385)
>         at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1143) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1502)
> .......
> 
> 
> It is caused by creation of `GenericEditor` class which uses a non-serializable Constructor field.
> This is fixed by making the field transient..
> Also, `editorRemover` field is made transient as it is object of `CellEditorRemover` class which is not Serializable..

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Fri Feb 13 09:30:37 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 13 Feb 2026 09:30:37 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box [v4]
In-Reply-To: <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
 <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
Message-ID: <hxFE1HejzUmegYR1q7V-1O7cbvLF-hu3ZoLMViphs28=.70d807c2-7e95-4e84-b163-9fcd7633cdc0@github.com>

On Mon, 9 Feb 2026 21:34:25 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.
>
> 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 eight additional commits since the last revision:
> 
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comments:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - Merge branch 'master' into JDK-4197755
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comment:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - 4197755: Updating copyright year
>  - 4197755: update copyright year
>  - 4197755: shorten javadoc
>  - 4197755: make Arc2D.getBounds() similar to getBounds2D()
>  - 4197755: add failing unit test

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26715#pullrequestreview-3796063840

From serb at openjdk.org  Fri Feb 13 17:48:21 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Feb 2026 17:48:21 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager [v2]
In-Reply-To: <Xqm0gkIVrG-B6_XTzvwsXFe5r3cSAkQ-RFtx5PQOoX8=.1faf84e2-e95e-47ee-aa20-182983289fb2@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
 <Xqm0gkIVrG-B6_XTzvwsXFe5r3cSAkQ-RFtx5PQOoX8=.1faf84e2-e95e-47ee-aa20-182983289fb2@github.com>
Message-ID: <qMhdmZJ8etwYWZyY2AQ8MM-hx2ZWVViyl_kmym8Bwas=.16b95c94-f4cb-45b3-a414-076b1b6c976b@github.com>

On Wed, 11 Feb 2026 21:02:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from KeyboardFocusManager
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377191

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29578#pullrequestreview-3798629074

From duke at openjdk.org  Fri Feb 13 17:58:48 2026
From: duke at openjdk.org (duke)
Date: Fri, 13 Feb 2026 17:58:48 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box [v4]
In-Reply-To: <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
 <iIbT1BydqL1_H8Xru4h46Vjo238IW3WNIZSYqKNeE7A=.24d92185-4710-4651-a57a-5fdda78269ad@github.com>
Message-ID: <47SzCA7QF5SVyr5I9PvSsEWSE8_545ZIjdwvwGgC9P4=.ea3dcd08-8790-4c77-bc42-8f33d5abe552@github.com>

On Mon, 9 Feb 2026 21:34:25 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.
>
> 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 eight additional commits since the last revision:
> 
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comments:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - Merge branch 'master' into JDK-4197755
>  - 4197755: use directed inherit with getBounds()
>    
>    This is in response to darcy's comment:
>    https://bugs.openjdk.org/browse/JDK-8374859
>  - 4197755: Updating copyright year
>  - 4197755: update copyright year
>  - 4197755: shorten javadoc
>  - 4197755: make Arc2D.getBounds() similar to getBounds2D()
>  - 4197755: add failing unit test

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3898534962

From philip.race at oracle.com  Fri Feb 13 19:26:29 2026
From: philip.race at oracle.com (Philip Race)
Date: Fri, 13 Feb 2026 11:26:29 -0800
Subject: Java 25 swing bug - pending review ID 9079510
In-Reply-To: <CAEpX__DzLMD3be8WzYORabi2YZw+AfH8g7PE4anoQMNUeHgGXg@mail.gmail.com>
References: <CAEpX__DzLMD3be8WzYORabi2YZw+AfH8g7PE4anoQMNUeHgGXg@mail.gmail.com>
Message-ID: <fe2f5277-a9b2-4ad0-b4ee-0c039c598fa9@oracle.com>

This is https://bugs.openjdk.org/browse/JDK-8370945

I agree the padding should not be there unless it is needed.

-phil.

On 11/16/25 11:55 PM, Nicolas Baumann wrote:
> Hello,
>
> Here?s a link with all the details:
>
> https://stackoverflow.com/q/79820806/8315843
>
>
> Thanks,
> Nicolas.


From aivanov at openjdk.org  Fri Feb 13 19:35:20 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Feb 2026 19:35:20 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v18]
In-Reply-To: <WHKz-RLjG5BYTB2mxm0aRlNVOAjUvG5d7OcQocl4zWI=.af663504-9638-43ed-a619-f6dcb1a3ca98@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <f98wRo4E-Yx4AvMFOzq_Gycl5HZYehgzumytphz7BR0=.716a9711-bc7d-4c7e-8f80-cec0d9218c0c@github.com>
 <WHKz-RLjG5BYTB2mxm0aRlNVOAjUvG5d7OcQocl4zWI=.af663504-9638-43ed-a619-f6dcb1a3ca98@github.com>
Message-ID: <SiqOHd1k0ByoYpPNLF_Zi5qjUpgXxjbzG-mU8WgJE74=.d98d0e00-1711-4327-822f-386f735e8eef@github.com>

On Thu, 11 Dec 2025 20:48:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge branch 'pr/25971' into jdk-8360498
>>  - Merge branch 'openjdk:master' into jdk-8360498
>>  - Resolves confict for when there is a merge with jdk-8158801
>>  - Merge branch 'openjdk:master' into jdk-8360498
>>  - Removes not needed changes
>>  - Revert "Removes not needed changes"
>>    
>>    This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb.
>>  - Removes not needed changes
>>  - Removes extra white lines
>>  - Merge branch 'pr/25971' into jdk-8360498
>>  - Merge branch 'pr/25971' into jdk-8360498
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/59a937ac...900a7943
>
> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 85:
> 
>> 83:         try {
>> 84:             Process p = Runtime.getRuntime()
>> 85:                     .exec(JAVA_HOME + "/bin/java FrameBorderCounter");
> 
> Did I already asked this question?
> 
> Why can't the code in `FrameBorderCounter` be run in the same JVM? I'm pretty sure it can be.
> 
> It's like for a separate refactoring, yet I'd like to have a tracking bug for getting rid of launching another process to count something that can be done by executing `FrameBorderCounter.main` directly and ensuring the frame is disposed of.

I've submitted [JDK-8377916](https://bugs.openjdk.org/browse/JDK-8377916): *Run `FrameBorderCounter` in-process in `AWT_Mixing` tests*.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805606386

From aivanov at openjdk.org  Fri Feb 13 19:35:15 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Feb 2026 19:35:15 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v36]
In-Reply-To: <WjVNj7G3LB-87LHrhYfcctVogTyBguDwH9h4wVUQTjs=.47cde889-e1f4-4771-bf71-aff693ea949b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <WjVNj7G3LB-87LHrhYfcctVogTyBguDwH9h4wVUQTjs=.47cde889-e1f4-4771-bf71-aff693ea949b@github.com>
Message-ID: <8srBbh1qp02liPUGq8270a36DK1Biv3TuLlICviflEQ=.64640651-0007-4d32-bb08-3ed5a6dd2c02@github.com>

On Fri, 13 Feb 2026 08:15:54 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> This PR will consolidate fixes of the following bugs:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361188
>> https://bugs.openjdk.org/browse/JDK-8361189
>> https://bugs.openjdk.org/browse/JDK-8361190
>> https://bugs.openjdk.org/browse/JDK-8361191
>> https://bugs.openjdk.org/browse/JDK-8361192
>> https://bugs.openjdk.org/browse/JDK-8361193
>> https://bugs.openjdk.org/browse/JDK-8361195
>> 
>> This PR depends on https://github.com/openjdk/jdk/pull/25971
>> 
>> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
>> 
>> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
>> 
>> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re problem list unstable test

In addition to my other comments, bump up the copyright year in the updated `.java` files to 2026.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 133:

> 131:                         testedComponent.setBounds(0, 0,
> 132:                                 testedComponent.getPreferredSize().width,
> 133:                                 testedComponent.getPreferredSize().height + 20);

This added code fully duplicates the existing code at lines [167?184](https://github.com/kboulanou/jdk/blob/a2b9a388fbcf836de159705500bdb22cedb2d1d9/test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java#L167-L184) except for focus handling. Modify the code below.

Otherwise, lines 167?184 are unreachable.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 135:

> 133:                                 testedComponent.getPreferredSize().height + 20);
> 134:                         Component focusOwner = KeyboardFocusManager.getCurrentKeyboardFocusManager()
> 135:                                 .getFocusOwner();

Suggestion:

                        Component focusOwner = KeyboardFocusManager
                                               .getCurrentKeyboardFocusManager()
                                               .getFocusOwner();

What do you think about this way? The line isn't as long.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 148:

> 146:             }
> 147:             Point lLoc = testedComponent.getLocationOnScreen();
> 148:             lLoc.translate(1, testedComponent.getPreferredSize().height + 1);

`getLocationOnScreen` and `getPreferredSize` are better called on EDT, however, I think it's safe here. You've got a synchronisation point with `invokeAndWait`, neither `getLocationOnScreen` and `getPreferredSize` could change, therefore the returned values would be consistent.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 165:

> 163: 
> 164:             return true;
> 165:         }

This looks weird. I'd separate the logical blocks above with blank lines, but here the blank is absolutely redundant.

Moreover, it seems to me `if (!resize)` should've remained above. That is if `!resize` we don't need the latch, we don't need anything because the test is skipped. So keep it that way: exit from the method early than later.

Everything the follows `if (!resize)` block is where the action is happening.

In other words, what I suggest is


    protected boolean performTest() {
        if (!super.performTest()) {
            return false;
        }

        if (!testResize) {
            return true;
        }

        // The above piece of code remains unchanged

        // Create the latch and handle focus here
        // ...

test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 29:

> 27: import java.awt.event.ActionEvent;
> 28: import java.awt.event.ActionListener;
> 29: import java.lang.Override;

No need to explicitly import anything from the `java.lang` package.

test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 70:

> 68:         frame.getContentPane().setLayout(new BoxLayout(frame.getContentPane(), BoxLayout.Y_AXIS));
> 69:         frame.setSize(200, 200);
> 70:         cb = new JComboBox(petStrings);

I prefer to keep this blank line, it separates creating the frame and setting its size from creating and configuring the combo box.

test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 104:

> 102: 
> 103:         loc2.translate(75, 75);
> 104:         robot.mouseMove(0, 0);

I believe this line is asking for comment:


Suggestion:

        robot.mouseMove(0, 0);  // Avoid capturing mouse cursor

test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 32:

> 30: import java.awt.event.MouseAdapter;
> 31: import java.awt.event.MouseEvent;
> 32: import java.lang.Override;

Suggestion:


Redundant import.

test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 79:

> 77:         frame.setLocationRelativeTo(null);
> 78:         frame.setVisible(true);
> 79:         menuBar = new JMenuBar();

Suggestion:

        frame.setLocationRelativeTo(null);
        frame.setVisible(true);

        menuBar = new JMenuBar();

Preserve the blank line.

test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 110:

> 108:         propagateAWTControls(frame);
> 109: 
> 110:     }

Suggestion:

    }

A blank line right before the closing brace is redundant.

test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 126:

> 124:         Robot robot = Util.createRobot();
> 125:         robot.setAutoDelay(ROBOT_DELAY);
> 126:         robot.mouseMove(0, 0);

A comment would be nice.

test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 92:

> 90:         frame.setVisible(true);
> 91:         loc = frame.getContentPane().getLocationOnScreen();
> 92:     }

You removed `setLocationRelativeTo` and `setVisible` in `JMenuBarOverlapping.java`, should these be removed too?

`setLocationRelativeTo` is redundant here, as you already called it on line 73.

test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 99:

> 97:         Robot robot = Util.createRobot();
> 98:         robot.setAutoDelay(ROBOT_DELAY);
> 99:         robot.mouseMove(0, 0);

I'd add a comment to explain moving to (0, 0).

test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 104:

> 102: 
> 103:         pixelPreCheck(robot, loc, currentAwtControl);
> 104:         try {

If removing a blank line, I'd rather remove the one between `translate` and `pixelPreCheck` instead of this. Those calls are closer related than the `try` block below.

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 61:

> 59: public class MixingPanelsResizing {
> 60: 
> 61:     static final int TOLERANCE_MACOSX = 15;

Suggestion:

    private static final int TOLERANCE_MACOSX = 15;

For consistency with other declarations.

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 62:

> 60: 
> 61:     static final int TOLERANCE_MACOSX = 15;
> 62:     static volatile boolean failed = false;

The field `failed` in unused, it can be removed then.

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 119:

> 117:                 Math.abs(borderShift) == 1 ?
> 118:                 borderShift :
> 119:                 (borderShift / 2);

Suggestion:

        borderShift = Math.abs(borderShift) == 1
                      ? borderShift
                      : (borderShift / 2);

I prefer this formatting. Yet we don't have a style guide to follow.

In general, wrapping before the operator makes it clearer that it's a continuation line.

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 169:

> 167:         SwingUtilities.invokeAndWait(new Runnable() {
> 168: 
> 169:             public void run() {

Suggestion:

SwingUtilities.invokeAndWait(new Runnable() {
public void run() {

I'd rather not add this line? On the other hand, it's more or less consistent with other cases where the `Runnable` interface is implemented.

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 255:

> 253:     public static void main(String args[]) throws Exception {
> 254: 
> 255:         if (!Toolkit.getDefaultToolkit().isDynamicLayoutActive()) {

I'm strongly against adding blank lines at the start of a method. The declaration of a method serves as the start of a new logical block by itself.

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 277:

> 275:             //Timed out, so fail the test
> 276:             throw new RuntimeException(
> 277:                     "Timed out after " + sleepTime / 1000 + " seconds");

Suggestion:

                    "Timed out after " + (sleepTime / 1000) + " seconds");

Parentheses aren't required here, yet they help avoid any ambiguity.

test/jdk/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java line 1:

> 1: /*

If there's nothing else modified in the `OpaqueOverlapping.java` file, I'd rather revert these changes and leave the file untouched, moreover importing `java.lang.Override` is not needed.

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 32:

> 30: import java.awt.Dimension;
> 31: import java.awt.Font;
> 32: import java.awt.Helper;

I'd probably put the helper into the section of helper classes? but this means that imports need manual editing after IDE updates them for you. So, probably leave it as is now.

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 47:

> 45: import java.io.InputStream;
> 46: import java.io.InputStreamReader;
> 47: import java.lang.Override;

No need to import `Override`.

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 389:

> 387:         return !(component == null ||
> 388:                  (component instanceof Scrollbar) ||
> 389:                  (isMac && (component instanceof Button)));

Suggestion:

        return !(component == null
                 || (component instanceof Scrollbar)
                 || (isMac && (component instanceof Button)));

Wrap before the operator to clearly indicate a continuation line.

test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 389:

> 387:         return !(component == null ||
> 388:                  (component instanceof Scrollbar) ||
> 389:                  (isMac && (component instanceof Button)));

Does inverting the condition makes it clearer?


        return component != null
               && !(component instanceof Scrollbar)
               && !(isMac && (component instanceof Button));

That is verify any non-null component except `Scrollbar`, and in addition `Button` on macOS.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 161:

> 159:         JFrame ancestor = (JFrame) (testedComponent.getTopLevelAncestor());
> 160:         final CountDownLatch latch = new CountDownLatch(1);
> 161:         if (ancestor != null) {

Suggestion:

        final CountDownLatch latch = new CountDownLatch(1);

        JFrame ancestor = (JFrame) (testedComponent.getTopLevelAncestor());
        if (ancestor != null) {

I suggest moving the declarations around. The `latch` is helper object. You then get the ancestor and work with it.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 171:

> 169:             latch.countDown();
> 170:         }
> 171:         try {

Add a blank line between the `if` statement and `try`. The `if` block prepares for the code inside `try`, they're related, but still do separate job.

Reading code that separates logical blocks with blank lines is easier.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 173:

> 171:         try {
> 172:             boolean await = latch.await(1, TimeUnit.SECONDS);
> 173:             if (!await) {

Suggestion:

            if (!latch.await(1, TimeUnit.SECONDS)) {

The usage of a local variable doesn't add clarity.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 181:

> 179:             throw new RuntimeException(e);
> 180:         }
> 181:         if (ancestor != null && isMultiFramesTest()) {

Move the call to `clickAndBlink` back here along with the blank line.

You [say](https://github.com/openjdk/jdk/pull/26625/changes#r2650824338), ?`clickAndBlink` happens only when we get focus?, which is directly after the `try` block. If the focus isn't received, an exception is thrown from the `try` block.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26625#pullrequestreview-3797926253
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804821645
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804848528
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804834467
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804799689
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804853122
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804864577
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804869126
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804874542
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804873518
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804879173
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804891685
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804922132
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804908185
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2804912887
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805615814
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805612960
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805633218
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805636375
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805645029
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805647581
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805658685
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805702649
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805662864
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805689266
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805695680
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805715826
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805726748
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805730100
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805750733

From aivanov at openjdk.org  Fri Feb 13 19:35:21 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Feb 2026 19:35:21 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v20]
In-Reply-To: <ow7pFpsREldbAOqN3VWqFjQ1HrIC30makGYLut1z93Y=.5a7a23b2-39cd-4979-bed0-60b2a752cc25@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <ao-B6Iw7YEHu8en61oqXqxlG7QQWz02wxJuQQQ8SqSc=.ee552bfa-fa15-43b7-b589-4264775dd732@github.com>
 <EAb1eY3g0aPtPGEagBVWx3Jpey10x10SoWv_AFoV6iY=.5883957e-2026-434b-8e70-4e71a03e690e@github.com>
 <ow7pFpsREldbAOqN3VWqFjQ1HrIC30makGYLut1z93Y=.5a7a23b2-39cd-4979-bed0-60b2a752cc25@github.com>
Message-ID: <EV15jQ618wM7ZSbL4bNQN7Yt3UtuOoLa6Zazb75zAtQ=.a4a3a341-17b3-4aa4-a18f-4ca004d79ea5@github.com>

On Mon, 29 Dec 2025 12:02:09 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 177:
>> 
>>> 175:                         "focus");
>>> 176:             }
>>> 177:             clickAndBlink(robot, lLoc);
>> 
>> Is `clickAndBlink` supposed to fix the focus issue?
>> 
>> Is it still required if the ancestor received the focus? (If it didn't, you throw an exception.)
>
> I had duplicated code during merge, by mistake. This is fixed now and clickAndBlink happens only when we get focus.

In this case, `clickAndBlink` could've just stayed where where it was? before the following `if` statement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2805742392

From jwood at openjdk.org  Fri Feb 13 19:37:09 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 13 Feb 2026 19:37:09 GMT
Subject: Integrated: 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: <IG7_zjV6F_Q60VxE_3ZtdKPcoJVk-sKViVOZc12SBZU=.0761fb68-9d4f-48ef-8487-d78bd9ba76b0@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.

This pull request has now been integrated.

Changeset: a98d3a76
Author:    Jeremy Wood <jwood at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a98d3a76a5d44096321aa02ed86e865066c89bdc
Stats:     112 lines in 2 files changed: 98 ins; 12 del; 2 mod

4197755: Arc2D.getBounds() returns an unnecessarily large bounding box

Reviewed-by: prr, psadhukhan

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

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

From prr at openjdk.org  Fri Feb 13 19:46:23 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Feb 2026 19:46:23 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager [v3]
In-Reply-To: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
Message-ID: <x-cmsR8249tCKy5SBXvfVlCeZv20O5qfC5yl6CC_XV0=.7affec0c-b598-4c02-8360-ddd73a4ba26e@github.com>

> Remove AppContext from KeyboardFocusManager

Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge
 - 8377191
 - 8377191

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

Changes: https://git.openjdk.org/jdk/pull/29578/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29578&range=02
  Stats: 189 lines in 6 files changed: 2 ins; 143 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/29578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29578/head:pull/29578

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

From aivanov at openjdk.org  Fri Feb 13 20:06:52 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 13 Feb 2026 20:06:52 GMT
Subject: RFR: 8377602: Create automated test for PageRange
Message-ID: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>

As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.

With this PR, I'm contributing the test to OpenJDK.

Without the fix for JDK-8297191, the test fails with the following error messages:

<details>
<summary>test log</summary>


java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
	at PageRangesAuto.main(PageRangesAuto.java:146)

</details>

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

Commit messages:
 - Remove trailing whitespace
 - Merge master
 - Merge master
 - Merge master
 - Update formatting of page methods
 - Bump the copyright to 2026
 - Merge master
 - Merge master
 - Merge master
 - Automatic test for printing page ranges - JDK-8297191

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

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

From prr at openjdk.org  Fri Feb 13 20:14:49 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Feb 2026 20:14:49 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled [v2]
In-Reply-To: <YLdhwdGeXIctXt6HOJYSudhDPKnvIykNBTri8gBxv-w=.f613e0f2-16e9-41aa-b4b3-eafdc705943d@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
 <YLdhwdGeXIctXt6HOJYSudhDPKnvIykNBTri8gBxv-w=.f613e0f2-16e9-41aa-b4b3-eafdc705943d@github.com>
Message-ID: <hjWZ44SAhy7TZZDMcQ4D3_O9LhMMPU71u_hXVQZbjHU=.351eaa80-311c-46da-a63e-d3c38cc39b47@github.com>

On Fri, 13 Feb 2026 01:48:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add headful keyword

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29563#pullrequestreview-3799303363

From philip.race at oracle.com  Fri Feb 13 20:48:13 2026
From: philip.race at oracle.com (Philip Race)
Date: Fri, 13 Feb 2026 12:48:13 -0800
Subject: Maintaining CAccessibility
In-Reply-To: <em4ace0b31-2dd5-4809-b554-5f989a1e9ae5@gmail.com>
References: <em4ace0b31-2dd5-4809-b554-5f989a1e9ae5@gmail.com>
Message-ID: <5e003688-aa4a-4a05-8446-f067a410dba9@oracle.com>

Go ahead.

BTW this doesn't mean I've done a "pre-review" of the specifics, I'm 
just saying OK to the idea.
So in review it may be found that there's a reason to keep some of these 
as they are.


-phil.

On 2/12/26 12:49 AM, Jeremy Wood wrote:
> If I open a PR to clean up CAccessibility.java: is there any interest 
> in code reviewing it?
>
> Just tonight I think I?ve identified three topics to explore:
>
> A. The native method `roleKey(AccessibleRole)` looks redundant 
> compared to 
> `AWTAccessor.getAccessibleBundleAccessor().getKey(AccessibleRole)`. I 
> think we can remove one. (Or at least better document when to use each.)
>
> B. There?s an if statement: `if (?label?.equals(?`. This looks like it 
> will break if the Locale is not English. However it (mostly) doesn?t, 
> because?
>
> C. The method getAccessibleRoleForLabel also appears mostly redundant 
> compared to AccessibleJLabel#getAccessibleRole. (See 2021 commit 
> 70bad89b012eb200ca1e76f384a6e5fb307cf26d for 8277497 ).
>
> I could submit a PR to clean these up, but I know sometime?s it's hard 
> to justify maintenance work without a customer-facing issue.
>
> Any thoughts?
>
> Regards,
> ?- Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20260213/624fa594/attachment.htm>

From philip.race at oracle.com  Fri Feb 13 20:58:08 2026
From: philip.race at oracle.com (Philip Race)
Date: Fri, 13 Feb 2026 12:58:08 -0800
Subject: Making ImageIO.read() 15% faster for JPEGs
In-Reply-To: <emdc14f409-accd-48c9-a862-a64b516c7b12@gmail.com>
References: <emdc14f409-accd-48c9-a862-a64b516c7b12@gmail.com>
Message-ID: <e5e2140f-4413-4798-9309-72a99db22497@oracle.com>

So you'd end up with a BI that is of TYPE_CUSTOM ?
That might make decoding a bit faster but rendering would be very slow. 
I'm not sure I'd want that trade-off.

-phil.


On 1/6/26 8:59 AM, Jeremy Wood wrote:
> I?m exploring the performance of loading BufferedImages. I recently 
> noticed that ImageIO.read() can be made ~15% faster by changing the 
> BufferedImage type (so we'd avoid a RGB -> BGR conversion).
>
> IMO this wouldn?t be too hard to program, but it might be considered 
> too invasive to accept. Is there any interest/support in exploring 
> this idea if I submit a PR for it?
>
> Specifically this is the performance I?m observing on my MacBook:
>
> Benchmark? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?Mode? Cnt ?Score? ?Error? 
> Units
> JPEG_Default_vs_RGB.measureDefaultImageType? avgt? ?15 42.589 ? 0.137? 
> ms/op
> JPEG_Default_vs_RGB.measureRGBImageType? ?? ?avgt? ?15 35.624 ? 0.589? 
> ms/op
>
> The first ?default? approach uses ImageIO.read(inputStream).
>
> The second ?RGB? approach creates a BufferedImage target with a custom 
> ColorModel that is similar to TYPE_3BYTE_BGR, except it reverse the 
> colors so they are ordered RGB.
>
> This derives from the observation that in JPEGImageReader we create a 
> one-line raster field that uses this 3-byte RGB model. Later in 
> acceptPixels() we call target.setRect(x, y, raster) . Here target is 
> the WritableRaster of the final BufferedImage. By default it will be a 
> 3-byte BGR. So we?re spending 15+% of our time converting RGB-encoded 
> data (from raster) to BGR-encoded data (for target).
>
> So the ?pros? of my proposal should include a faster loading time for 
> many JPEG images. I?d argue ImageIO should always default to the 
> fastest (reasonable) implementation possible.
>
> IMO the major ?con? is: target.getType() would change from 
> BufferedImage.TYPE_3BYTE_BGR to BufferedImage.TYPE_CUSTOM . This 
> doesn?t technically violate any documentation that I know of, but it 
> seems (IMO) like something some clients will have made assumptions 
> about, and therefore some downstream code may break. (And maybe other 
> devs here can identify other problems I?m not anticipating.)
>
> Any thoughts / feedback?
>
> Regards,
> ?- Jeremy
>
> Below is the JMH code used to generate the output above:
>
> package org.sun.awt.image;
>
> import org.openjdk.jmh.annotations.*;
> import org.openjdk.jmh.infra.Blackhole;
>
> import javax.imageio.ImageIO;
> import javax.imageio.ImageReadParam;
> import javax.imageio.ImageReader;
> import java.awt.*;
> import java.awt.color.ColorSpace;
> import java.awt.image.*;
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.io.IOException;
> import java.util.Iterator;
> import java.util.Random;
> import java.util.concurrent.TimeUnit;
>
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.MILLISECONDS)
> @Warmup(iterations = 5, time = 1)
> @Measurement(iterations = 5, time = 20)
> @Fork(3)
> @State(Scope.Thread)
> public class JPEG_Default_vs_RGB {
>
> ? ? byte[] jpgImageData;
>
> ? ? @Setup
> ? ? public void setup() throws Exception {
> ? ? ? ? jpgImageData = createImageData(2_500);
> ? ? }
>
> ? ? @Benchmark
> ? ? public void measureDefaultImageType(Blackhole bh) throws Exception {
> ? ? ? ? BufferedImage bi = readJPG(false);
> ? ? ? ? bi.flush();
> ? ? ? ? bh.consume(bi);
> ? ? }
>
> ? ? @Benchmark
> ? ? public void measureRGBImageType(Blackhole bh) throws Exception {
> ? ? ? ? BufferedImage bi = readJPG(true);
> ? ? ? ? bi.flush();
> ? ? ? ? bh.consume(bi);
> ? ? }
>
> ? ? private BufferedImage readJPG(boolean useRGBTarget) throws Exception {
> ? ? ? ? Iterator<ImageReader>?readers;
> ? ? ? ? try (ByteArrayInputStream byteIn = new 
> ByteArrayInputStream(jpgImageData)) {
> ? ? ? ? ? ? if (!useRGBTarget)
> ? ? ? ? ? ? ? ? return ImageIO.read(byteIn);
>
> ? ? ? ? ? ? readers = 
> ImageIO.getImageReaders(ImageIO.createImageInputStream(byteIn));
> ? ? ? ? ? ? if (!readers.hasNext()) {
> ? ? ? ? ? ? ? ? throw new IOException("No reader found for the given 
> file.?);
> ? ? ? ? ? ? }
> ? ? ? ? }
>
> ? ? ? ? ImageReader reader = readers.next();
> ? ? ? ? try (ByteArrayInputStream byteIn = new 
> ByteArrayInputStream(jpgImageData)) {
> reader.setInput(ImageIO.createImageInputStream(byteIn));
>
> ? ? ? ? ? ? int width = reader.getWidth(0);
> ? ? ? ? ? ? int height = reader.getHeight(0);
>
> ? ? ? ? ? ? // this is copied from how BufferedImage sets up a 
> TYPE_3BYTE_BGR image,
> ? ? ? ? ? ? // except we use {0, 1, 2} to make it an RGB image:
> ? ? ? ? ? ? ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB);
> ? ? ? ? ? ? int[] nBits = {8, 8, 8};
> ? ? ? ? ? ? int[] bOffs = {0, 1, 2};
> ? ? ? ? ? ? ColorModel colorModel = new ComponentColorModel(cs, nBits, 
> false, false,
> ? ? ? ? ? ? ? ? ? ? Transparency.OPAQUE,
> ? ? ? ? ? ? ? ? ? ? DataBuffer.TYPE_BYTE);
> ? ? ? ? ? ? WritableRaster raster = 
> Raster.createInterleavedRaster(DataBuffer.TYPE_BYTE,
> ? ? ? ? ? ? ? ? ? ? width, height, width * 3, 3, bOffs, null);
>
> ? ? ? ? ? ? BufferedImage rgbImage = new BufferedImage(colorModel, 
> raster, false, null);
>
> ? ? ? ? ? ? ImageReadParam param = reader.getDefaultReadParam();
> ? ? ? ? ? ? param.setDestination(rgbImage);
>
> ? ? ? ? ? ? reader.read(0, param);
>
> ? ? ? ? ? ? return rgbImage;
> ? ? ? ? } finally {
> ? ? ? ? ? ? reader.dispose();
> ? ? ? ? }
> ? ? }
>
> ? ? /**
> ? ? ?* Create a large sample image stored as a JPG
> ? ? ?*
> ? ? ?* @return the byte representation of the JPG image.
> ? ? ?*/
> ? ? private static byte[] createImageData(int squareSize) throws 
> Exception {
> ? ? ? ? BufferedImage bi = new BufferedImage(squareSize, squareSize,
> ? ? ? ? ? ? ? ? BufferedImage.TYPE_INT_RGB);
> ? ? ? ? Random r = new Random(0);
> ? ? ? ? Graphics2D g = bi.createGraphics();
> ? ? ? ? for (int a = 0; a < 20000; a++) {
> ? ? ? ? ? ? g.setColor(new Color(r.nextInt(0xffffff)));
> ? ? ? ? ? ? int radius = 10 + r.nextInt(90);
> ? ? ? ? ? ? g.fillOval(r.nextInt(bi.getWidth()), 
> r.nextInt(bi.getHeight()),
> ? ? ? ? ? ? ? ? ? ? radius, radius);
> ? ? ? ? }
> ? ? ? ? g.dispose();
>
> ? ? ? ? try (ByteArrayOutputStream out = new ByteArrayOutputStream()) {
> ? ? ? ? ? ? ImageIO.write(bi, "jpg", out);
> ? ? ? ? ? ? return out.toByteArray();
> ? ? ? ? }
> ? ? }
> }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20260213/dc7abc42/attachment-0001.htm>

From kizune at openjdk.org  Fri Feb 13 21:06:04 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 13 Feb 2026 21:06:04 GMT
Subject: RFR: 8377745: VoiceOver Identifies Hyperlink as Text
In-Reply-To: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
References: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
Message-ID: <wy5XIDa5ej2WCHgJUoOeu9HrzVwhhsMeSJkjpUisB2Y=.51fe669f-37b4-4aac-a49c-0f1bbd318921@github.com>

On Thu, 12 Feb 2026 08:32:43 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> If we use `new AccessibleRole("AXLink") {}`, then VoiceOver reads this more like other native apps.
> 
> There isn't a similar precedent in CAccessibility for creating custom AccessibleRoles, so I won't mind if this PR is declined. (But I don't know off the top of my head where else to inject code to get the desired result...)

The issue of wrong reporting of the hyperlink component does exist but this is not the correct way to solve it. For starters it would force old and deprecated property-based accessibility API on this component so when Apple will finally fully switch to the new API this will outright stop working. Currently the hyperlink accessibility role is bound to the native peer StaticTextAccessibility so either there should be a special case for correctly reporting the native accessibility role and the corresponding role selectors such as `isVisited` should be added to it or - ideally - the new peer specific for the hyperlink needs to be created and binding in `[CommonComponentAccessibility initializeRolesMap]` should be updated referencing a new class.

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

PR Comment: https://git.openjdk.org/jdk/pull/29686#issuecomment-3899448303

From dnguyen at openjdk.org  Fri Feb 13 22:08:57 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 13 Feb 2026 22:08:57 GMT
Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager [v3]
In-Reply-To: <x-cmsR8249tCKy5SBXvfVlCeZv20O5qfC5yl6CC_XV0=.7affec0c-b598-4c02-8360-ddd73a4ba26e@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
 <x-cmsR8249tCKy5SBXvfVlCeZv20O5qfC5yl6CC_XV0=.7affec0c-b598-4c02-8360-ddd73a4ba26e@github.com>
Message-ID: <5yJ6uwob_jDXEEaf3EAThgcsW2MJcVnkd6EmGd6kKJE=.03481d55-f27e-4382-9350-1049e3f62684@github.com>

On Fri, 13 Feb 2026 19:46:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from KeyboardFocusManager
>
> Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - 8377191
>  - 8377191

Merge conflict looks to be resolved.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29578#pullrequestreview-3799821008

From jwood at openjdk.org  Fri Feb 13 22:15:31 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 13 Feb 2026 22:15:31 GMT
Subject: RFR: 8377745: VoiceOver Identifies Hyperlink as Text [v2]
In-Reply-To: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
References: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
Message-ID: <vikiKuDi1QPsG_ovP_YQJqWZ7c4x2EEhbZ8f0tes4oU=.5a9705ac-4fd3-4efb-94bd-b8740c947195@github.com>

> If we use `new AccessibleRole("AXLink") {}`, then VoiceOver reads this more like other native apps.
> 
> There isn't a similar precedent in CAccessibility for creating custom AccessibleRoles, so I won't mind if this PR is declined. (But I don't know off the top of my head where else to inject code to get the desired result...)

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - 8377745: creating new LinkAccessibility
   
   This helps convert from AccessibleRole.HYPERLINK to the new LinkAccessibility.
   
   The new LinkAccessible still references `CommonTextAccessibility<NSAccessibilityStaticText>`.
   
   This (both the subject matter and the programming language) is outside of my area of expertise, but the unit test passes.
   
   This is based on this feedback:
   https://github.com/openjdk/jdk/pull/29686#issuecomment-3899448303
 - Revert "8377745: use custom "AXLink" AccessibleRole"
   
   This reverts commit d66355973918458352d15174a2cf21a177763c23.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29686/files
  - new: https://git.openjdk.org/jdk/pull/29686/files/49c63a19..96159c51

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

  Stats: 63 lines in 4 files changed: 42 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/29686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29686/head:pull/29686

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

From jwood at openjdk.org  Fri Feb 13 22:22:18 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 13 Feb 2026 22:22:18 GMT
Subject: RFR: 8377745: VoiceOver Identifies Hyperlink as Text
In-Reply-To: <wy5XIDa5ej2WCHgJUoOeu9HrzVwhhsMeSJkjpUisB2Y=.51fe669f-37b4-4aac-a49c-0f1bbd318921@github.com>
References: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
 <wy5XIDa5ej2WCHgJUoOeu9HrzVwhhsMeSJkjpUisB2Y=.51fe669f-37b4-4aac-a49c-0f1bbd318921@github.com>
Message-ID: <y3tOofgReaJ5Edy2_CNJ9Ll4RC41CMtGaL7P1vsrQYI=.cbb67785-ce8f-4504-b044-6774827e61f8@github.com>

On Fri, 13 Feb 2026 21:03:28 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> this is not the correct way to solve it.

OK, thanks. I rewrote this PR based on my (limited understanding) of your feedback. VoiceOver and the Accessibility Inspector still identify the link correctly in my latest execution of the unit test.

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

PR Comment: https://git.openjdk.org/jdk/pull/29686#issuecomment-3899846339

From prr at openjdk.org  Fri Feb 13 22:43:24 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Feb 2026 22:43:24 GMT
Subject: Integrated: 8377191: Remove AppContext from KeyboardFocusManager
In-Reply-To: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
References: <yTD7eKN688aY64Rv-eTEkNbrTfDu8AiTzNj_uCQTLc4=.52359060-4227-483a-92ea-b79e0fe9f160@github.com>
Message-ID: <GHvOrEfLA_hoWur88T1vxrwAJy8RX1Q3lzN7AzqWpn8=.4e2cac27-7443-4680-9334-d53a4217e136@github.com>

On Wed, 4 Feb 2026 20:33:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from KeyboardFocusManager

This pull request has now been integrated.

Changeset: 1920983e
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1920983edb4001c71efaeefcf819feb977accbea
Stats:     189 lines in 6 files changed: 2 ins; 143 del; 44 mod

8377191: Remove AppContext from KeyboardFocusManager

Reviewed-by: dnguyen, tr, serb

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

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

From dgredler at openjdk.org  Sat Feb 14 16:19:59 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Sat, 14 Feb 2026 16:19:59 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation
Message-ID: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>

On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.

This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).

`FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.

Tested on mac, Linux and Windows:
- make test TEST="jtreg:test/jdk/java/awt/font"
- make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"

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

Commit messages:
 - Add bug ID to test
 - Fix rotated advance on mac
 - Add rotated font test

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

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

From jwood at openjdk.org  Sat Feb 14 23:52:59 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Sat, 14 Feb 2026 23:52:59 GMT
Subject: RFR: 8377938: VoiceOver Uses Mouse to Activate JButtons in German
Message-ID: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>

Previously:
The action description would be localized text. So in German's case `getAccessibleActionDescription(0)` would return `Klicken`. As that String is passed upwards towards VoiceOver, we're counting on VoiceOver's code interpreting it correctly.

With this PR:
We always return "click" (using the AccessibleAction.CLICK constant). VoiceOver knows how to interpret an unlocalized "click".

## Context

I looked up references to other AccessibleAction constants:

- AccessibleAction.TOGGLE_EXPAND is referenced in JTree.java's `getAccessibleActionDescription` method.
- AccessibleAction.INCREMENT and AccessibleAction.DECREMENT are referenced in JSlider's and JSpinner's `getAccessibleActionDescription` method.
- AccessibleAction.CLICK and AccessibleAction.TOGGLE_POPUP are NOT currently referenced (prior to this PR)

The javadoc for `getAccessibleActionDescription` simply describes the return value as "a String description of the action". It makes no comment on whether it should be localized or not.

JList.java is similar to AbstractButton:

public String getAccessibleActionDescription(int i) {
    if (i == 0) {
        return UIManager.getString("AbstractButton.clickText");
    } else {
        return null;
    }
}


JComboBox.java includes:

public String getAccessibleActionDescription(int i) {
    if (i == 0) {
        return UIManager.getString("ComboBox.togglePopupText");
    }
    else {
        return null;
    }
}


I'd argue that we need to be consistent: either JTree/JSlider/JSpinner should be modified to return a localized action description, OR AbstractButton/JList/JComboBox should be modified to return the unlocalized constant.

My preference is to modify AbstractButton and JList (as shown in this PR). (And I'd recommend addressing JComboBox in a separate PR.)

(Also, I really like JTextComponent.java's implementation that combined Swing's ActionMap with AccessibleActions:

public String getAccessibleActionDescription(int i) {
    Action [] actions = JTextComponent.this.getActions();
    if (i < 0 || i >= actions.length) {
        return null;
    }
    return (String)actions[i].getValue(Action.NAME);
}

... but that's straying pretty far from the original ticket.)

## Non-Swing Context

I also searched for `getAccessibleActionDescription` in general.

In Button.java and MenuItem.java we have:

public String getAccessibleActionDescription(int i) {
    if (i == 0) {
        // [[[PENDING:  WDW -- need to provide a localized string]]]
        return "click";
    } else {
        return null;
    }
}


These comments date back to the beginning of the git history. This commenter (WDW maybe William D. Walker?) appears to take the opposite view.

## Regarding the Test

Since we prefer automated tests over manual tests: I'm proposing in this PR an automated test that only identifies the description String. (This way we don't have to toggle VoiceOver on/off, so we don't need a manual test.)

I have separately confirmed the original bug test case from the ticket does not reproduce in this branch, but as of this writing I am NOT including that as a new manual test.

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

Commit messages:
 - 8377938: Fixing test to fail
 - 8377938: AbstractAction should describe actions using AccessibleAction.CLICK

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

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

From duke at openjdk.org  Sun Feb 15 00:25:17 2026
From: duke at openjdk.org (duke)
Date: Sun, 15 Feb 2026 00:25:17 GMT
Subject: RFR: 8377428: VoiceOver Cursor Navigates Invisible Components [v2]
In-Reply-To: <6gKkkewPdR9Kyw3idBwN02A2DP75g9nnJ2XWIicIPw0=.6ed34a65-f401-497c-b6d6-7181f21cb4a9@github.com>
References: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
 <6gKkkewPdR9Kyw3idBwN02A2DP75g9nnJ2XWIicIPw0=.6ed34a65-f401-497c-b6d6-7181f21cb4a9@github.com>
Message-ID: <N4noZIfVb5wCa5E7mEO8N_NibZTBBZFac11R7uDZktw=.9c46ec1b-3db7-47eb-8ac8-4ab96ab8dfaf@github.com>

On Tue, 10 Feb 2026 01:07:46 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> This PR prevents VoiceOver from letting me navigate the VoiceOver cursor to hidden components.
>> 
>> ### Technical Details
>> 
>> VoiceOver is responsible for a call to `CAccessibility.getChildrenAndRoles(JFrame, JFrame, JAVA_AX_ALL_CHILDREN, false)`.
>> 
>> That last boolean is `allowIgnored`.
>> 
>> When `allowedIgnored == false` we already omitted certain components based on their AccessibleRole. This PR expands our definition of "what should be ignored" to include invisible Components.
>> 
>> ### Other Considerations
>> 
>> 1. Originally I thought the resolution to this problem would be to change JAVA_AX_ALL_CHILDREN to JAVA_AX_VISIBLE_CHILDREN . And maybe that's still a viable option, but after some research I've come to believe it's simpler/appropriate to change our definition of "ignored".
>> 2. NSViews have a separate property `isHidden`. Another approach to this ticket might be to try to assign `myNSView.isHidden = !myJavaComponent.isVisible()`. Some reading suggests that this might (?) automatically resolve this ticket.
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8377428: simplify test instructions
>    
>    Now that there are other interesting components in the UI: we don't need to press CTRL + ALT + UP.
>  - 8377428: test condition where axComp is null
>    
>    If AccessibleComponent is null, when the new CAccessibility.isShowing(..) method falls back to consulting the AccessibleStateSet.
>    
>    This change makes sure we follow that code path, too.
>    
>    When I checked CAccessibility.isShowing() in the debugger, I observed:
>    
>    For "row 1": we had an AccessibleComponent where isShowing() is false
>    
>    For "row 2": we had a no AccessibleComponent. We checked the AccessibleStateSelection and did not see SHOWING, so CAccessibility.isShowing(context) returned TRUE. This is not accurate, but it's working as designed. We had incomplete information, and we're supposed to err on the side of returning true (to minimize invasive risk). Meanwhile: the test still passes, because then _addChildren recursively inspects the JButton, and CAccessibility.isShowing(buttonContext) returns false.
>    
>    For "row 3": we had an AccessibleComponent where isShowing() is true.
>    
>    For "row 4": we had no AccessibleComponent. We checked AccessibleStateSelection and DID see SHOWING, so we returned true.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/29630#discussion_r2784969123

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

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

PR Comment: https://git.openjdk.org/jdk/pull/29630#issuecomment-3902850898

From jwood at openjdk.org  Sun Feb 15 06:07:22 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Sun, 15 Feb 2026 06:07:22 GMT
Subject: Integrated: 8377428: VoiceOver Cursor Navigates Invisible Components
In-Reply-To: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
References: <krN_EBtvKIupO9NfxP3tCdB3m7N45PyuJSYPzonigi0=.5865e2ab-3a7d-4330-b820-3baf6e072e37@github.com>
Message-ID: <pH7XH25a8E6fEbL-tV9go4mUF_JVtBR0j-OCicEU4DA=.b3b81e7c-7837-4709-84d7-85dc3f5b68c6@github.com>

On Mon, 9 Feb 2026 08:35:13 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> This PR prevents VoiceOver from letting me navigate the VoiceOver cursor to hidden components.
> 
> ### Technical Details
> 
> VoiceOver is responsible for a call to `CAccessibility.getChildrenAndRoles(JFrame, JFrame, JAVA_AX_ALL_CHILDREN, false)`.
> 
> That last boolean is `allowIgnored`.
> 
> When `allowedIgnored == false` we already omitted certain components based on their AccessibleRole. This PR expands our definition of "what should be ignored" to include invisible Components.
> 
> ### Other Considerations
> 
> 1. Originally I thought the resolution to this problem would be to change JAVA_AX_ALL_CHILDREN to JAVA_AX_VISIBLE_CHILDREN . And maybe that's still a viable option, but after some research I've come to believe it's simpler/appropriate to change our definition of "ignored".
> 2. NSViews have a separate property `isHidden`. Another approach to this ticket might be to try to assign `myNSView.isHidden = !myJavaComponent.isVisible()`. Some reading suggests that this might (?) automatically resolve this ticket.

This pull request has now been integrated.

Changeset: ef0851d8
Author:    Jeremy Wood <jwood at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef0851d8adbb834e1cd5aff5b3b973b953e57e2d
Stats:     175 lines in 2 files changed: 167 ins; 0 del; 8 mod

8377428: VoiceOver Cursor Navigates Invisible Components

Reviewed-by: serb, kizune

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

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

From dnguyen at openjdk.org  Mon Feb 16 01:31:11 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 16 Feb 2026 01:31:11 GMT
Subject: RFR: 8376994: Remove AppContext from
 sun/awt/datatransfer/DataTransferer.java [v2]
In-Reply-To: <xskPiGokj9meVlw8dl_Mg2yP_5dkDX0Qv5Rb__W2Itk=.84228ac7-0f39-40bd-a8fe-1dad65c64f47@github.com>
References: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
 <xskPiGokj9meVlw8dl_Mg2yP_5dkDX0Qv5Rb__W2Itk=.84228ac7-0f39-40bd-a8fe-1dad65c64f47@github.com>
Message-ID: <QjTY52aFrU_hJUkLzp8GlCMvdDagaVew7yZ6YUEroNY=.c4c02c50-eed5-47c3-82a6-e934fefaaf72@github.com>

On Wed, 11 Feb 2026 21:13:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from sun/awt/datatransfer/DataTransferer.java
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8376994

Changes look good to me. Built and tested it without any issues.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29532#pullrequestreview-3806181099

From psadhukhan at openjdk.org  Mon Feb 16 01:57:28 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 16 Feb 2026 01:57:28 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
Message-ID: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>

[JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.

Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon

Before fix

<img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />


After fix

<img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

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

Commit messages:
 - jcheck
 - 8370945: With Windows LAF, the location of a JMenuItem icon is incorrect

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

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

From psadhukhan at openjdk.org  Mon Feb 16 05:23:19 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 16 Feb 2026 05:23:19 GMT
Subject: RFR: 8372952: Printed content is cut off when width > height [v2]
In-Reply-To: <L6epQJ_wv79hftjql8paFgsDF3zRzNRW6dX_f3-O8Aw=.5f6e8760-58b9-4e68-980f-1948f72a8c7a@github.com>
References: <lb8GZRWbO4rnHCVFF8MQfgV3DIuOGIt4f49RRyhW8Ng=.7ce8594c-eef8-4a99-ab73-14ebf3130646@github.com>
 <L6epQJ_wv79hftjql8paFgsDF3zRzNRW6dX_f3-O8Aw=.5f6e8760-58b9-4e68-980f-1948f72a8c7a@github.com>
Message-ID: <1Ry15_1J9BKz3mANlXPpq2pBoLP_a9lPQ9Z9Qbi-2vU=.7eb835fb-b505-4d53-812b-c6b9055a8114@github.com>

On Wed, 4 Feb 2026 08:26:01 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> These changes fix https://bugs.openjdk.org/browse/JDK-8372952 "Printed content is cut off when width > height". 
>> 
>> There are three issues which cause this bug.
>> #### The first issue
>> Media printable area does not match the corresponding media size for the landscape-oriented medias. \
>> An example of the actual prints on a paper 80mmx40mm (Epson T-TA88V) 
>> [actual_cut_off.pdf](https://github.com/user-attachments/files/25064646/actual_cut_off.pdf)
>> 
>> #### The second issue
>> _MediaSize_ does not allow landscape-oriented medias (X dimension bigger than Y dimension of the media) so rotated size is used, but the media printable area stays the same - landscape-oriented. 
>> Current implementation does not allow to use landscape-oriented paper because _MediaSize_
>> constructor allows portrait paper only (width < height). 
>> 
>> I read comments about _MediaSize_ restrictions (width<height) in https://bugs.openjdk.org/browse/JDK-8041911, which states that this is "by design" and specification. But I did not find media size restrictions in the https://datatracker.ietf.org/doc/html/rfc2911.
>> The RFC defines "orientation-requested" attribute, that was mentioned in the JDK-8041911 comments, but this attribute indicates the desired orientation for printed print-stream pages and is used for only a subset of the supported document formats ('text/plain' or 'text/html') to format the document. \
>> As described in the RFC https://datatracker.ietf.org/doc/html/rfc2911#section-15.3
>>> If the document data has been formatted, then go to step 2. Otherwise, the document data MUST be formatted. The formatting detection algorithm is implementation defined and is not specified by this document.  The formatting of the document data uses the "orientation-requested" attribute to determine how the formatted print data should be placed on a print-stream page
>> 
>> Therefore, if a printer object uses a landscape-oriented paper, a document format is "text/plain" and an "orientation-requested" attribute contains "portrait" value then the printer object should rotate the document 90 degrees. \
>> If a printer uses a portrait-oriented paper, a document format is "text/plain," and an "orientation-requested" attribute contains value "portrait" then the printer object does no rotation.
>> 
>> Also, https://datatracker.ietf.org/doc/html/rfc3382 defines a "media-size" IPP attribute which identifies the size of the media. The RFC contains an example of this attribute where the X-dimension (the ...
>
> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat test

I believe the same was fixed in [JDK-8295737](https://bugs.openjdk.org/browse/JDK-8295737)...That fix was also for macos.
Did it regress?

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

PR Comment: https://git.openjdk.org/jdk/pull/29560#issuecomment-3906505013

From psadhukhan at openjdk.org  Mon Feb 16 06:12:09 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 16 Feb 2026 06:12:09 GMT
Subject: RFR: 8377192: Remove AppContext from MenuSelectionManager
In-Reply-To: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
References: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
Message-ID: <4sq6vVVZVVvILu_pOKTtXpeCDZpReERF-X9MxcsRBO0=.d5c9acc1-2c22-471e-ab7b-7de1baa84e1d@github.com>

On Wed, 4 Feb 2026 20:44:02 GMT, Phil Race <prr at openjdk.org> wrote:

> remove AppContext from Swing's MenuSelectionManager

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29579#pullrequestreview-3806816526

From rkannathpari at openjdk.org  Mon Feb 16 06:37:24 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 16 Feb 2026 06:37:24 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print"
Message-ID: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>

Hi Reviewers,

Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.

Please review and let me know your suggestions.

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

Commit messages:
 - 8268675: RTE from "Printable.print" propagates through "PrinterJob.print"

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

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

From rkannathpari at openjdk.org  Mon Feb 16 06:54:08 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 16 Feb 2026 06:54:08 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v2]
In-Reply-To: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
Message-ID: <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>

> Hi Reviewers,
> 
> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29733/files
  - new: https://git.openjdk.org/jdk/pull/29733/files/33ec67b9..9cc2d549

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

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

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

From psadhukhan at openjdk.org  Mon Feb 16 10:52:29 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 16 Feb 2026 10:52:29 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
Message-ID: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>

The FocusTraversalPolicy of a JOptionPane (JDialog) "reports" via `FocusTraversalPolicy.getInitialComponent`/`FocusTraversalPolicy.getFirstComponnent` that the focusable component passed to a JOptionPane, should get the initial focus. This however doesn't always happen, as the text field's FocusListener methods focusGained and focusLost are not invoked.
Fix is made to honor the first focusable component of custom component (if present) and set the focus accordingly..
This will cause the component's focusGained/focusLost method to get called.
CI testing is ok..

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

Commit messages:
 - jcheck
 - 6741930: JOptionPane doesn't honour Focus Traversal Policy

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

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

From duke at openjdk.org  Mon Feb 16 18:25:42 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 16 Feb 2026 18:25:42 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v37]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <3lsxbKL5U4cnbgtx6bGHkgq4dNVQEMF71JzXwwMZuSE=.198fe787-b75e-45d0-8d31-2d79ddf418f5@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Updates copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/a2b9a388..42930ab0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=35-36

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

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

From philip.race at oracle.com  Mon Feb 16 20:43:58 2026
From: philip.race at oracle.com (Philip Race)
Date: Mon, 16 Feb 2026 12:43:58 -0800
Subject: Changed behaviour of Desktop.browse on Windows
In-Reply-To: <054aa5b3-bd0b-438f-bd3c-c87e84bba175@xpipe.io>
References: <8e4f0374-e387-488d-b003-24bb7a8bf4ac@xpipe.io>
 <054aa5b3-bd0b-438f-bd3c-c87e84bba175@xpipe.io>
Message-ID: <2afcc1f1-8c71-4bf7-aa5d-0b99841f5e6d@oracle.com>

Can you explain specifically what you used this for and how you obtained 
the URL passed to the API,
and whether it was a user-initiated action ? The specific URL and scheme 
will help.
Also is your specific case FX or AWT ?

If any of this is something you consider private/proprietary to your 
application, you can send me off-list if that works.

I'm not promising anything, but it will help if we understand the use 
case in detail.

-phil.

On 2/12/26 9:55 AM, Christopher Schnick wrote:
> Does anyone have input on this? I had to revert all deployments I made 
> with JDK 25.0.2 back to JDK 25.0.1 due to it breaking various 
> different features that relied on opening URLs of specific 
> applications. The same will probably also apply to many other 
> applications out there.
>
> Is there a supported way in JDK 25.0.2 to open an URL with the 
> associated application instead of the web browser on Windows?
>
> On 10/02/2026 16:45, Christopher Schnick wrote:
>> Hello,
>>
>> We recently upgraded our application to JDK 25.0.2 and saw a changed 
>> behaviour in the Desktop.browse method when opening any non-http URLs 
>> on Windows. Previously, those URLs were opened with the default 
>> application associated with that URL scheme, now it always opens the 
>> URL in the web browser, even though it shouldn't really do that. Even 
>> stuff like file:// URLs are opened in the browser.
>>
>> I saw there were PRs for both the AWT and JavaFX implementation for 
>> opening URLs, but the related JBS issues are private. So I'm guessing 
>> some kind of security issue?
>>
>> Is this the expected behaviour now due to security constraints or is 
>> this a bug?
>>
>> Best
>> Christopher Schnick
>>


From crschnick at xpipe.io  Mon Feb 16 21:44:40 2026
From: crschnick at xpipe.io (Christopher Schnick)
Date: Mon, 16 Feb 2026 22:44:40 +0100
Subject: Changed behaviour of Desktop.browse on Windows
In-Reply-To: <9b2764dd-0a8e-4221-8dfc-6da86b3dacbb@xpipe.io>
References: <8e4f0374-e387-488d-b003-24bb7a8bf4ac@xpipe.io>
 <054aa5b3-bd0b-438f-bd3c-c87e84bba175@xpipe.io>
 <2afcc1f1-8c71-4bf7-aa5d-0b99841f5e6d@oracle.com>
 <9b2764dd-0a8e-4221-8dfc-6da86b3dacbb@xpipe.io>
Message-ID: <f1fdb8ce-74d1-421e-ad66-4976bfb3b056@xpipe.io>

Edit: I meant the behaviour for *Desktop.browse* is now platform 
specific and the javadocs are wrong for it.

Furthermore, a good solution to solving this issue properly if security 
constraints disallow the normal Desktop.browse method to be used for 
arbitrary URLs, would be to add a new method to the Desktop class which 
supports this.

On 16/02/2026 22:38, Christopher Schnick wrote:
> There are plenty of applications on Windows that use URL schemes to 
> allow for a unified way of launching applications with some arguments. 
> In our main app, one application we call via Desktop.browse is the 
> Warp Terminal that requires URLs to be properly launched with 
> arguments with the warp:// scheme. Other apps we call in some internal 
> tools are GitHub Desktop with x-github-client:// and msteams with 
> msteams://. But there are plenty more of those URL schemes for all 
> kinds of applications out there, and someone is probably going to rely 
> on them.
>
> The URLs are manually constructed in the code, e.g. when the user 
> wants open a certain session to a system. The use case here is for AWT 
> as the FX desktop integration does not have all the features that AWT 
> has.
>
> Regardless of specific apps, the change in handling the file:// URLs 
> is also a problem. Before, in the code you didn't really need to care 
> whether a URL was of a specific type, Desktop.browse launched the 
> right application for any URL. Now, I have to check whether it is a 
> file URL and use the Desktop.open method instead with the URL path. 
> For other types of custom URLs, we resorted to manually calling new 
> ProcessBuilder("rundll32", "url.dll,FileProtocolHandler", url) on 
> Windows.
>
> The behaviour of Desktop.open is now also platform-specific as this 
> does not behave the same way on Linux or macOS. Technically, the 
> javadocs for Desktop.browse were already wrong, now they are still 
> wrong for the Linux/macOS behaviour.
>
> I also don't see the huge security issue with allowing applications to 
> open URLs how they like. If a JVM-based application opens a malicious 
> URL from user input without verifying it, the JVM shouldn't prevent 
> that as that is an application issue. You could block ProcessBuilder 
> from spawning arbitrary programs with the same reasoning if you go 
> down that route.
>
> On 16/02/2026 21:43, Philip Race wrote:
>> Can you explain specifically what you used this for and how you 
>> obtained the URL passed to the API,
>> and whether it was a user-initiated action ? The specific URL and 
>> scheme will help.
>> Also is your specific case FX or AWT ?
>>
>> If any of this is something you consider private/proprietary to your 
>> application, you can send me off-list if that works.
>>
>> I'm not promising anything, but it will help if we understand the use 
>> case in detail.
>>
>> -phil.
>>
>> On 2/12/26 9:55 AM, Christopher Schnick wrote:
>>> Does anyone have input on this? I had to revert all deployments I 
>>> made with JDK 25.0.2 back to JDK 25.0.1 due to it breaking various 
>>> different features that relied on opening URLs of specific 
>>> applications. The same will probably also apply to many other 
>>> applications out there.
>>>
>>> Is there a supported way in JDK 25.0.2 to open an URL with the 
>>> associated application instead of the web browser on Windows?
>>>
>>> On 10/02/2026 16:45, Christopher Schnick wrote:
>>>> Hello,
>>>>
>>>> We recently upgraded our application to JDK 25.0.2 and saw a 
>>>> changed behaviour in the Desktop.browse method when opening any 
>>>> non-http URLs on Windows. Previously, those URLs were opened with 
>>>> the default application associated with that URL scheme, now it 
>>>> always opens the URL in the web browser, even though it shouldn't 
>>>> really do that. Even stuff like file:// URLs are opened in the 
>>>> browser.
>>>>
>>>> I saw there were PRs for both the AWT and JavaFX implementation for 
>>>> opening URLs, but the related JBS issues are private. So I'm 
>>>> guessing some kind of security issue?
>>>>
>>>> Is this the expected behaviour now due to security constraints or 
>>>> is this a bug?
>>>>
>>>> Best
>>>> Christopher Schnick
>>>>
>>

From serb at openjdk.org  Mon Feb 16 23:01:49 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 16 Feb 2026 23:01:49 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading
Message-ID: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>

Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
 - rgba -> argb, since this is the format described in the spec
 - hasalpha -> hasAlpha, to follow common naming conventions

Also adds a basic test for the constructor.

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

Commit messages:
 - 6434110: Color constructor parameter name is misleading

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

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

From serb at openjdk.org  Mon Feb 16 23:57:10 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 16 Feb 2026 23:57:10 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
Message-ID: <-1jZ9tPTRC-5SfZSkYs0_vQtfEz2DXTtfakIdNKb2mM=.d4672075-eb10-4fe4-8f19-46a73f6f1705@github.com>

On Mon, 16 Feb 2026 10:43:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The FocusTraversalPolicy of a JOptionPane (JDialog) "reports" via `FocusTraversalPolicy.getInitialComponent`/`FocusTraversalPolicy.getFirstComponnent` that the focusable component passed to a JOptionPane, should get the initial focus. This however doesn't always happen, as the text field's FocusListener methods focusGained and focusLost are not invoked.
> Fix is made to honor the first focusable component of custom component (if present) and set the focus accordingly..
> This will cause the component's focusGained/focusLost method to get called.
> CI testing is ok..

This seems to contradict the spec of BasicOptionPaneUI#initialFocusComponent and the spec of the BasicOptionPaneUI#selectInitialValue() itself?


    /** Component to receive focus when messaged with selectInitialValue. */
    protected Component           initialFocusComponent;

    /**
     * If inputComponent is non-null, the focus is requested on that,
     * otherwise request focus on the default value
     */
    public void selectInitialValue(JOptionPane op) {

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3911037641

From serb at openjdk.org  Tue Feb 17 00:09:24 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 00:09:24 GMT
Subject: RFR: 8378050: Add missing @Override annotations in "java.awt.color"
 package
Message-ID: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>

This patch adds missing `@Override` annotations to methods in the `java.awt.color` package that override methods from a superclass or interface.
Only source annotations are added; there are no behavioral changes.

The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

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

Commit messages:
 - 8378050: Add missing @Override annotations in "java.awt.color" package

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

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

From psadhukhan at openjdk.org  Tue Feb 17 03:07:14 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 17 Feb 2026 03:07:14 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
Message-ID: <K75Pg0Lyv31mB5FPB0Hpcp02xQNHUbOkyCpvkXEHqPo=.d1185305-2abe-46b4-bfaf-bced6040505d@github.com>

On Mon, 16 Feb 2026 10:43:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The FocusTraversalPolicy of a JOptionPane (JDialog) "reports" via `FocusTraversalPolicy.getInitialComponent`/`FocusTraversalPolicy.getFirstComponnent` that the focusable component passed to a JOptionPane, should get the initial focus. This however doesn't always happen, as the text field's FocusListener methods focusGained and focusLost are not invoked.
> Fix is made to honor the first focusable component of custom component (if present) and set the focus accordingly..
> This will cause the component's focusGained/focusLost method to get called.
> CI testing is ok..

I believe it is honoring that too. It will check and requestFocus to `selectInitialValue(op)` initialValue and then fallback to `initialFocusComponent` if it is not set..


Object paneInitVal = op.getInitialValue();
                // must be from pane because BasicOptionPane
                // sets intialFocusComponent to the default button
                if (paneInitVal != null) {
                    if (paneInitVal instanceof JComponent) {
                        // if JOptionPane initialValue is a JComponent
                        ((JComponent) paneInitVal).requestFocus();
                    } else if (initialFocusComponent != null) {
                        // else custom option button gets
                        // the focus if available
                        initialFocusComponent.requestFocus();

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3911539414

From psadhukhan at openjdk.org  Tue Feb 17 07:58:45 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 17 Feb 2026 07:58:45 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API)
Message-ID: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>

`JProgressBar` is not printed if JDK 1.1 printing API is used.
JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
`g2.setStroke(new BasicStroke(...))`

Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"

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

Commit messages:
 - jcheck
 - 6328248: JProgessBar doesn't show if printed on paper with PrintJob (1.1 Graphics API)
 - 6328248: JProgessBar doesn't show if printed on paper with PrintJob (1.1 Graphics API)

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

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

From duke at openjdk.org  Tue Feb 17 08:28:22 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 17 Feb 2026 08:28:22 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v38]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <zOu5lo_YPQUE_EKUcvByJjpWZRwplLr5vLyZdL3y2Ks=.d344e0c2-d09f-41dc-ba9c-b2b51ed8f884@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare 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 'openjdk:master' into jdk-8360498
 - Updates copyright year
 - Re problem list unstable test
 - De problem list few tests
 - Removed duplicate frame.setLocationRelativeTo(null);
 - Fixes resizing issue in Macos
 - Adds missing import
 - Moves mouse out from frame for precheckcolor
 - Removes fully qualified paths of classes and uses import instead
 - Merge branch 'openjdk:master' into jdk-8360498
 - ... and 123 more: https://git.openjdk.org/jdk/compare/03703f34...63b9faab

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

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=37
  Stats: 155 lines in 10 files changed: 102 ins; 15 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From tr at openjdk.org  Tue Feb 17 09:06:05 2026
From: tr at openjdk.org (Tejesh R)
Date: Tue, 17 Feb 2026 09:06:05 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <K-lecZ08Zpe6ky31lP45pvQMLljNNcTSJpJsbg3vg6I=.9c4a500c-2099-4b14-9a58-64084e67a81f@github.com>

On Mon, 16 Feb 2026 01:30:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

LGTM

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29730#pullrequestreview-3812553095

From dtabata at openjdk.org  Tue Feb 17 10:48:20 2026
From: dtabata at openjdk.org (Daishi Tabata)
Date: Tue, 17 Feb 2026 10:48:20 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <zH2R3RbFil-O5ww5cYoRqpCg8XjOAgQ5v_KG8ik6G78=.02b5b5fc-e419-44bb-9def-4f1b160b43e2@github.com>

On Mon, 16 Feb 2026 01:30:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

I don't have review permissions, but I'd like to comment on something that caught my eye.

The following image is a screenshot of the test `test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java` that was added by [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760).

Before
<img width="250" height="248" alt="before" src="https://github.com/user-attachments/assets/51c44938-bf61-44f0-a6fe-f5cf6b05a2c3" />

After
<img width="248" height="247" alt="after" src="https://github.com/user-attachments/assets/b5d01603-3bc7-4f4b-a538-20fcb13e74d9" />

Before this change, the left edges of all the red squares are aligned, and the text of each menu item is also left-aligned.
However, after this change, for menu items without radio buttons or checkboxes, the red squares and the text are misaligned compared to the others.
Is this an expected behavioral change introduced by this fix?

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3913870880

From aivanov at openjdk.org  Tue Feb 17 11:35:40 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 11:35:40 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <zH2R3RbFil-O5ww5cYoRqpCg8XjOAgQ5v_KG8ik6G78=.02b5b5fc-e419-44bb-9def-4f1b160b43e2@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <zH2R3RbFil-O5ww5cYoRqpCg8XjOAgQ5v_KG8ik6G78=.02b5b5fc-e419-44bb-9def-4f1b160b43e2@github.com>
Message-ID: <Luf5rYzVicK2KI4BCDBNMZ2lFVA390Tgy2tZ-PnjTbw=.0993236c-9c96-444c-8560-cf6e3330a1ac@github.com>

On Tue, 17 Feb 2026 10:45:27 GMT, Daishi Tabata <dtabata at openjdk.org> wrote:

> However, after this change, for menu items without radio buttons or checkboxes, the red squares and the text are misaligned compared to the others.
> Is this an expected behavioral change introduced by this fix?

This was the question I had, but I didn't have time yesterday to run additional tests.

I strongly believe it shouldn't be like this. The icons have to remain aligned.

There's one more case: What if there are `JRadioButtonMenuItem` or `JCheckBoxMenuItem` (or both) that don't have any icons? I think the check mark and bullets should be rendered as they were before [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760), that is the icons of other menu items and the check mark and bullets should remain in one column.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3914177391

From aivanov at openjdk.org  Tue Feb 17 11:38:30 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 11:38:30 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <zH2R3RbFil-O5ww5cYoRqpCg8XjOAgQ5v_KG8ik6G78=.02b5b5fc-e419-44bb-9def-4f1b160b43e2@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <zH2R3RbFil-O5ww5cYoRqpCg8XjOAgQ5v_KG8ik6G78=.02b5b5fc-e419-44bb-9def-4f1b160b43e2@github.com>
Message-ID: <ZPRdW4ZQW3oPMLo0m5YNexsDmhwoKD0nedZ9xH1dcHw=.6e1f3062-a795-42fe-b0b9-1b59362392cb@github.com>

On Tue, 17 Feb 2026 10:45:27 GMT, Daishi Tabata <dtabata at openjdk.org> wrote:

>> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
>> 
>> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
>> 
>> Before fix
>> 
>> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
>> 
>> 
>> After fix
>> 
>> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />
>
> I don't have review permissions, but I'd like to comment on something that caught my eye.
> 
> The following image is a screenshot of the test `test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java` that was added by [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760).
> 
> Before
> <img width="250" height="248" alt="before" src="https://github.com/user-attachments/assets/51c44938-bf61-44f0-a6fe-f5cf6b05a2c3" />
> 
> After
> <img width="248" height="247" alt="after" src="https://github.com/user-attachments/assets/b5d01603-3bc7-4f4b-a538-20fcb13e74d9" />
> 
> Before this change, the left edges of all the red squares are aligned, and the text of each menu item is also left-aligned.
> However, after this change, for menu items without radio buttons or checkboxes, the red squares and the text are misaligned compared to the others.
> Is this an expected behavioral change introduced by this fix?

@tabata-d If you have an OpenJDK id, you can still review, and your review will be recorded in `Reviewed-by` section. Yet your review won't count towards ?Change must be properly reviewed?.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3914202063

From psadhukhan at openjdk.org  Tue Feb 17 11:46:10 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 17 Feb 2026 11:46:10 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <75atHuiJA9MOYBXVEAxNEqc5MjBXNOrV80N_tBhVEHs=.c03e1eaf-5769-4727-8303-7548ce37749a@github.com>

On Mon, 16 Feb 2026 01:30:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

> I don't have review permissions, but I'd like to comment on something that caught my eye.
> 
> The following image is a screenshot of the test `test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java` that was added by [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760).
> 
> Before <img alt="before" width="250" height="248" src="https://private-user-images.githubusercontent.com/146925119/550911585-51c44938-bf61-44f0-a6fe-f5cf6b05a2c3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzEzMjg2NTUsIm5iZiI6MTc3MTMyODM1NSwicGF0aCI6Ii8xNDY5MjUxMTkvNTUwOTExNTg1LTUxYzQ0OTM4LWJmNjEtNDRmMC1hNmZlLWY1Y2Y2YjA1YTJjMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjE3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIxN1QxMTM5MTVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT01OTFhNWU1NzU0MjMwNTBmZGMwZTY2YjdhYWM3ODRjNmUyNTFiNjM1Y2U1MWUzMGE2ODNiYTE5YjNlOGI4NTEzJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.JVknLnmwMeCEXFBeTx66ucfslNJKAZ6e5Clx7D-mDyc">
> 
> After <img alt="after" width="248" height="247" src="https://private-user-images.githubusercontent.com/146925119/550911838-b5d01603-3bc7-4f4b-a538-20fcb13e74d9.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzEzMjg2NTUsIm5iZiI6MTc3MTMyODM1NSwicGF0aCI6Ii8xNDY5MjUxMTkvNTUwOTExODM4LWI1ZDAxNjAzLTNiYzctNGY0Yi1hNTM4LTIwZmNiMTNlNzRkOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjE3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIxN1QxMTM5MTVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0yMTIwZWI1M2E2NGIxZWU3MjM1OTVjNmRiMTU5NDY2M2UxOTAzMmU2OTgwMGMyNmQ2MjljYmViZDg1ZWYxMTEwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.uskBGN3tWshAur6s2yO6doqTGGMVYLCJ37DlFW9s820">
> 
> Before this change, the left edges of all the red squares are aligned, and the text of each menu item is also left-aligned. However, after this change, for menu items without radio buttons or checkboxes, the red squares and the text are misaligned compared to the others. Is this an expected behavioral change introduced by this fix?

I dont think we can align normal JMenuItem icon location with JRadioButtonMenuItem/JCheckBoxMenuItem icon location.
The latter needs a two column layout while normal JMenuItem as in this case needs 1 column as was asked in this JBS so the icon is left aligned for normal JMenuItem so it's expected change as far I am concerned.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3914250494

From aivanov at openjdk.org  Tue Feb 17 12:34:50 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 12:34:50 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <75atHuiJA9MOYBXVEAxNEqc5MjBXNOrV80N_tBhVEHs=.c03e1eaf-5769-4727-8303-7548ce37749a@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <75atHuiJA9MOYBXVEAxNEqc5MjBXNOrV80N_tBhVEHs=.c03e1eaf-5769-4727-8303-7548ce37749a@github.com>
Message-ID: <6Dr4K-epsYRbsHcTaiVLsFdnKQFiGqqvtyIdmWSAiVM=.873af05d-002d-49c8-b7de-2302c2dc0227@github.com>

On Tue, 17 Feb 2026 11:43:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I dont think we can align normal JMenuItem icon location with JRadioButtonMenuItem/JCheckBoxMenuItem icon location.
> The latter needs a two column layout while normal JMenuItem as in this case needs 1 column as was asked in this JBS so the icon is left aligned for normal JMenuItem so it's expected change as far I am concerned.

Why can't we?

Both Metal and Nimbus perfect align them. See [the screenshots](https://github.com/openjdk/jdk/pull/23324#issuecomment-3008593168) I posted in #23324 for [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760).
![JMenu layout with radio bullets, check marks and icons in Metal Look-and-Feel](https://github.com/user-attachments/assets/65c5b4bb-dc3b-46dd-a74a-2cb6ef53ccc9)

Why can't Windows L&F?

The entire popup menu has to have a consistent layout, and that layout should be performed by `DefaultMenuLayout` and `MenuItemLayoutHelper` with minimal (preferably no tweaks) from the menu item UI itself.

At this time, Windows L&F implementation does *too much tweaking*, which comes from how icons were implemented in Windows L&F, specifically the check mark or bullet were hidden if a `JCheckBoxMenuItem` or `JRadioButtonMenuItem` had an icon. After JDK-8348760, the check mark or bullet and the icon are two separate entities that have to be handled separately.

This is why `VistaMenuItemCheckIcon` needs revising and likely dropping altogether. [I said it already](https://github.com/openjdk/jdk/pull/28889#discussion_r2694197701) in #28889:

> Is it because Windows icons used to be special and combined the icon and check mark / bullet mark, or rather replaced the check mark / bullet mark with the icon? Should we get rid of that special treatment?
>
> ? Both Metal and Nimbus L&F have similar column layouts where a separate column is allocated for marks and icons, Windows L&F should re-use that code.

And now it comes up again.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3914455950

From duke at openjdk.org  Tue Feb 17 13:21:28 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 17 Feb 2026 13:21:28 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v39]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <bvAIisBKOD_c8DBoewIKFiRXZAdX1DFuN7FaGEA1DIk=.f4f7a015-6886-4514-bdcf-29e6a07baf4a@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with nine additional commits since the last revision:

 - Runs getLocationOnScreen abd getPreferredSize in EDT and re-orders sequence of execution in performTest method
 - Formats code
 - Formats code and re-orders sequence of execution in performTest
 - Formats code and removes unnecessary imports
 - Formats code and removes unnecessary fields
 - Restores file, no changes needed
 - Adds comment on mouse move and removes duplicate setLocationRelativeTo
 - Removes unnecessary import and adds comment on mouse move
 - Updates formatting and adds comment on mouse move

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/63b9faab..985d3fc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=37-38

  Stats: 149 lines in 8 files changed: 55 ins; 59 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From duke at openjdk.org  Tue Feb 17 13:21:48 2026
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 17 Feb 2026 13:21:48 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v36]
In-Reply-To: <8srBbh1qp02liPUGq8270a36DK1Biv3TuLlICviflEQ=.64640651-0007-4d32-bb08-3ed5a6dd2c02@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <WjVNj7G3LB-87LHrhYfcctVogTyBguDwH9h4wVUQTjs=.47cde889-e1f4-4771-bf71-aff693ea949b@github.com>
 <8srBbh1qp02liPUGq8270a36DK1Biv3TuLlICviflEQ=.64640651-0007-4d32-bb08-3ed5a6dd2c02@github.com>
Message-ID: <nYosATKvF8v_vVWeUuS-Zbdy26z1JKAiNwC4_G93Iig=.f01a7b25-bf1f-47c2-a650-5215e581a210@github.com>

On Fri, 13 Feb 2026 15:36:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re problem list unstable test
>
> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 133:
> 
>> 131:                         testedComponent.setBounds(0, 0,
>> 132:                                 testedComponent.getPreferredSize().width,
>> 133:                                 testedComponent.getPreferredSize().height + 20);
> 
> This added code fully duplicates the existing code at lines [167?184](https://github.com/kboulanou/jdk/blob/a2b9a388fbcf836de159705500bdb22cedb2d1d9/test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java#L167-L184) except for focus handling. Modify the code below.
> 
> Otherwise, lines 167?184 are unreachable.

Code modified as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 135:
> 
>> 133:                                 testedComponent.getPreferredSize().height + 20);
>> 134:                         Component focusOwner = KeyboardFocusManager.getCurrentKeyboardFocusManager()
>> 135:                                 .getFocusOwner();
> 
> Suggestion:
> 
>                         Component focusOwner = KeyboardFocusManager
>                                                .getCurrentKeyboardFocusManager()
>                                                .getFocusOwner();
> 
> What do you think about this way? The line isn't as long.

Looks good to me. I updated code accordingly.

> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 148:
> 
>> 146:             }
>> 147:             Point lLoc = testedComponent.getLocationOnScreen();
>> 148:             lLoc.translate(1, testedComponent.getPreferredSize().height + 1);
> 
> `getLocationOnScreen` and `getPreferredSize` are better called on EDT, however, I think it's safe here. You've got a synchronisation point with `invokeAndWait`, neither `getLocationOnScreen` and `getPreferredSize` could change, therefore the returned values would be consistent.

Tasks run in EDT, please have a look. Thanks.

> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 165:
> 
>> 163: 
>> 164:             return true;
>> 165:         }
> 
> This looks weird. I'd separate the logical blocks above with blank lines, but here the blank is absolutely redundant.
> 
> Moreover, it seems to me `if (!resize)` should've remained above. That is if `!resize` we don't need the latch, we don't need anything because the test is skipped. So keep it that way: exit from the method early than later.
> 
> Everything the follows `if (!resize)` block is where the action is happening.
> 
> In other words, what I suggest is
> 
> 
>     protected boolean performTest() {
>         if (!super.performTest()) {
>             return false;
>         }
> 
>         if (!testResize) {
>             return true;
>         }
> 
>         // The above piece of code remains unchanged
> 
>         // Create the latch and handle focus here
>         // ...

I  have re-ordered the sequence of execution here. Please have a look. Thanks.

> test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 29:
> 
>> 27: import java.awt.event.ActionEvent;
>> 28: import java.awt.event.ActionListener;
>> 29: import java.lang.Override;
> 
> No need to explicitly import anything from the `java.lang` package.

I have removed this unnecess ary import from this class and other classes.

> test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 70:
> 
>> 68:         frame.getContentPane().setLayout(new BoxLayout(frame.getContentPane(), BoxLayout.Y_AXIS));
>> 69:         frame.setSize(200, 200);
>> 70:         cb = new JComboBox(petStrings);
> 
> I prefer to keep this blank line, it separates creating the frame and setting its size from creating and configuring the combo box.

I have restored back this space.

> test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 104:
> 
>> 102: 
>> 103:         loc2.translate(75, 75);
>> 104:         robot.mouseMove(0, 0);
> 
> I believe this line is asking for comment:
> 
> 
> Suggestion:
> 
>         robot.mouseMove(0, 0);  // Avoid capturing mouse cursor

Comment added as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 32:
> 
>> 30: import java.awt.event.MouseAdapter;
>> 31: import java.awt.event.MouseEvent;
>> 32: import java.lang.Override;
> 
> Suggestion:
> 
> 
> Redundant import.

Unnecessary comment removed.

> test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 79:
> 
>> 77:         frame.setLocationRelativeTo(null);
>> 78:         frame.setVisible(true);
>> 79:         menuBar = new JMenuBar();
> 
> Suggestion:
> 
>         frame.setLocationRelativeTo(null);
>         frame.setVisible(true);
> 
>         menuBar = new JMenuBar();
> 
> Preserve the blank line.

Blank line restored as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 110:
> 
>> 108:         propagateAWTControls(frame);
>> 109: 
>> 110:     }
> 
> Suggestion:
> 
>     }
> 
> A blank line right before the closing brace is redundant.

Blank line added.

> test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 126:
> 
>> 124:         Robot robot = Util.createRobot();
>> 125:         robot.setAutoDelay(ROBOT_DELAY);
>> 126:         robot.mouseMove(0, 0);
> 
> A comment would be nice.

Comment added as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 92:
> 
>> 90:         frame.setVisible(true);
>> 91:         loc = frame.getContentPane().getLocationOnScreen();
>> 92:     }
> 
> You removed `setLocationRelativeTo` and `setVisible` in `JMenuBarOverlapping.java`, should these be removed too?
> 
> `setLocationRelativeTo` is redundant here, as you already called it on line 73.

setLocationRelativeTo and setVisible removed as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 99:
> 
>> 97:         Robot robot = Util.createRobot();
>> 98:         robot.setAutoDelay(ROBOT_DELAY);
>> 99:         robot.mouseMove(0, 0);
> 
> I'd add a comment to explain moving to (0, 0).

Comment added.

> test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 104:
> 
>> 102: 
>> 103:         pixelPreCheck(robot, loc, currentAwtControl);
>> 104:         try {
> 
> If removing a blank line, I'd rather remove the one between `translate` and `pixelPreCheck` instead of this. Those calls are closer related than the `try` block below.

Blank line restored and removed blank line between `translate` and `pixelPreCheck`.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 61:
> 
>> 59: public class MixingPanelsResizing {
>> 60: 
>> 61:     static final int TOLERANCE_MACOSX = 15;
> 
> Suggestion:
> 
>     private static final int TOLERANCE_MACOSX = 15;
> 
> For consistency with other declarations.

Field accessor added as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 62:
> 
>> 60: 
>> 61:     static final int TOLERANCE_MACOSX = 15;
>> 62:     static volatile boolean failed = false;
> 
> The field `failed` in unused, it can be removed then.

Unnecessary field removed as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 119:
> 
>> 117:                 Math.abs(borderShift) == 1 ?
>> 118:                 borderShift :
>> 119:                 (borderShift / 2);
> 
> Suggestion:
> 
>         borderShift = Math.abs(borderShift) == 1
>                       ? borderShift
>                       : (borderShift / 2);
> 
> I prefer this formatting. Yet we don't have a style guide to follow.
> 
> In general, wrapping before the operator makes it clearer that it's a continuation line.

Formatting updated as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 169:
> 
>> 167:         SwingUtilities.invokeAndWait(new Runnable() {
>> 168: 
>> 169:             public void run() {
> 
> Suggestion:
> 
>         SwingUtilities.invokeAndWait(new Runnable() {
>             public void run() {
> 
> I'd rather not add this line? On the other hand, it's more or less consistent with other cases where the `Runnable` interface is implemented.

Blank line removed as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 255:
> 
>> 253:     public static void main(String args[]) throws Exception {
>> 254: 
>> 255:         if (!Toolkit.getDefaultToolkit().isDynamicLayoutActive()) {
> 
> I'm strongly against adding blank lines at the start of a method. The declaration of a method serves as the start of a new logical block by itself.

I have removed blank line as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 277:
> 
>> 275:             //Timed out, so fail the test
>> 276:             throw new RuntimeException(
>> 277:                     "Timed out after " + sleepTime / 1000 + " seconds");
> 
> Suggestion:
> 
>                     "Timed out after " + (sleepTime / 1000) + " seconds");
> 
> Parentheses aren't required here, yet they help avoid any ambiguity.

Formatting updated as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java line 1:
> 
>> 1: /*
> 
> If there's nothing else modified in the `OpaqueOverlapping.java` file, I'd rather revert these changes and leave the file untouched, moreover importing `java.lang.Override` is not needed.

File restored from previous version.

> test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 32:
> 
>> 30: import java.awt.Dimension;
>> 31: import java.awt.Font;
>> 32: import java.awt.Helper;
> 
> I'd probably put the helper into the section of helper classes? but this means that imports need manual editing after IDE updates them for you. So, probably leave it as is now.

I see, I have left it as it is. Thanks

> test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 47:
> 
>> 45: import java.io.InputStream;
>> 46: import java.io.InputStreamReader;
>> 47: import java.lang.Override;
> 
> No need to import `Override`.

Unnecessary import removed.

> test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 389:
> 
>> 387:         return !(component == null ||
>> 388:                  (component instanceof Scrollbar) ||
>> 389:                  (isMac && (component instanceof Button)));
> 
> Suggestion:
> 
>         return !(component == null
>                  || (component instanceof Scrollbar)
>                  || (isMac && (component instanceof Button)));
> 
> Wrap before the operator to clearly indicate a continuation line.

Operators location updated as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 389:
> 
>> 387:         return !(component == null ||
>> 388:                  (component instanceof Scrollbar) ||
>> 389:                  (isMac && (component instanceof Button)));
> 
> Does inverting the condition makes it clearer?
> 
> 
>         return component != null
>                && !(component instanceof Scrollbar)
>                && !(isMac && (component instanceof Button));
> 
> That is verify any non-null component except `Scrollbar`, and in addition `Button` on macOS.

Code update as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 161:
> 
>> 159:         JFrame ancestor = (JFrame) (testedComponent.getTopLevelAncestor());
>> 160:         final CountDownLatch latch = new CountDownLatch(1);
>> 161:         if (ancestor != null) {
> 
> Suggestion:
> 
>         final CountDownLatch latch = new CountDownLatch(1);
> 
>         JFrame ancestor = (JFrame) (testedComponent.getTopLevelAncestor());
>         if (ancestor != null) {
> 
> I suggest moving the declarations around. The `latch` is helper object. You then get the ancestor and work with it.

Order of execution updated as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 171:
> 
>> 169:             latch.countDown();
>> 170:         }
>> 171:         try {
> 
> Add a blank line between the `if` statement and `try`. The `if` block prepares for the code inside `try`, they're related, but still do separate job.
> 
> Reading code that separates logical blocks with blank lines is easier.

Blank line added as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 173:
> 
>> 171:         try {
>> 172:             boolean await = latch.await(1, TimeUnit.SECONDS);
>> 173:             if (!await) {
> 
> Suggestion:
> 
>             if (!latch.await(1, TimeUnit.SECONDS)) {
> 
> The usage of a local variable doesn't add clarity.

Unnecessary local variable removed as suggested.

> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 181:
> 
>> 179:             throw new RuntimeException(e);
>> 180:         }
>> 181:         if (ancestor != null && isMultiFramesTest()) {
> 
> Move the call to `clickAndBlink` back here along with the blank line.
> 
> You [say](https://github.com/openjdk/jdk/pull/26625/changes#r2650824338), ?`clickAndBlink` happens only when we get focus?, which is directly after the `try` block. If the focus isn't received, an exception is thrown from the `try` block.

Order of execution updated as requested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816923053
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816931726
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816928616
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816921525
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816938618
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816941556
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816942827
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816989616
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816944949
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816947178
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816988145
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816953294
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816948090
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816951576
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816957213
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816954624
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816958353
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816960534
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816986266
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816962036
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816983209
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816998102
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816963085
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816965367
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816968056
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816970509
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816980813
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816979573
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2816977810

From aivanov at openjdk.org  Tue Feb 17 15:56:04 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 15:56:04 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading
In-Reply-To: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
Message-ID: <D68_gvBfSOYf9JPnH7oWHSOj5qqm31Aeb-gfACT32c4=.00167277-be17-4b63-8f24-1e6e04204ac1@github.com>

On Mon, 16 Feb 2026 07:40:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>  - rgba -> argb, since this is the format described in the spec
>  - hasalpha -> hasAlpha, to follow common naming conventions
> 
> Also adds a basic test for the constructor.

src/java.desktop/share/classes/java/awt/Color.java line 404:

> 402:      * the green component in bits 8-15, and the blue component in bits 0-7. If
> 403:      * the {@code hasAlpha} argument is {@code false}, alpha is defaulted to
> 404:      * 255.

Suggestion:

     * Creates an sRGB color with the specified combined ARGB value consisting of
     * <ul>
     *    <li>the alpha component in bits 24-31,</li>
     *    <li>the red component in bits 16-23,</li>
     *    <li>the green component in bits 8-15, and</li>
     *    <li>the blue component in bits 0-7.</li>
     * </ul>
     * If the {@code hasAlpha} argument is {@code false}, alpha is defaulted to 255.


What do you think about such formatting? Each color component stands out this way.

I'd also change the last sentence to _?alpha defaults to 255.?_

However, changing the formatting for this constructor will require changing the formatting for `Color(int rgb)`. And it will break the first sentence summary displayed in the table of contructors methods.

src/java.desktop/share/classes/java/awt/Color.java line 408:

> 406:      * @param  argb the combined ARGB components
> 407:      * @param  hasAlpha {@code true} if the alpha bits are valid; {@code false}
> 408:      *         otherwise

Suggestion:

     * @param argb the combined ARGB components
     * @param hasAlpha {@code true} if the alpha bits are valid; {@code false}
     *        otherwise

Remove an extra space between the `@param` tag and the parameter name, other constructors don't have this additional space and use only one space.

test/jdk/java/awt/ColorClass/ColorARGBConstructorTest.java line 49:

> 47:         int expA = hasAlpha ? argb >>> 24 : 0xFF;
> 48:         int expR = (argb >> 16) & 0xFF;
> 49:         int expG = (argb >> 8) & 0xFF;

I suggest using `>>>` or `>>` in all the cases for consistency.

`(argb >> 24) & 0xFF` will produce the same result for `expA`.

Alternatively, `argb >>> 16` for `expR` will not need `& 0xFF`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2817755415
PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2817772086
PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2817727317

From duke at openjdk.org  Tue Feb 17 17:57:23 2026
From: duke at openjdk.org (Roland Mesde)
Date: Tue, 17 Feb 2026 17:57:23 GMT
Subject: RFR: 8377908: sun/java2d/OpenGL/ScaleParamsOOB.java test fails on
 Linux (xvfb, libmesa software rendering) after JDK-8358058
Message-ID: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>

Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.

Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:

make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java

Results attached:

[linux-x64-specific-test.log](https://github.com/user-attachments/files/25369364/linux-x64-specific-test.log)

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

Commit messages:
 - 8377908: sun/java2d/OpenGL/ScaleParamsOOB.java test fails on Linux (xvfb, libmesa software rendering) after JDK-8358058

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

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

From prr at openjdk.org  Tue Feb 17 18:12:17 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 18:12:17 GMT
Subject: RFR: 8377908: sun/java2d/OpenGL/ScaleParamsOOB.java test fails on
 Linux (xvfb, libmesa software rendering) after JDK-8358058
In-Reply-To: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
References: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
Message-ID: <KUprprv7BWjvIPWKe1ObzG9MPvLfQFraX_GmMY4Whac=.7a6be30a-c670-4a87-a5d4-530447f55880@github.com>

On Tue, 17 Feb 2026 16:10:19 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
> 
> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
> 
> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25369364/linux-x64-specific-test.log)

test/jdk/ProblemList.txt line 226:

> 224: sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java 8196180 windows-all,macosx-all
> 225: sun/java2d/OpenGL/OpaqueDest.java#id1 8367574 macosx-all
> 226: sun/java2d/OpenGL/ScaleParamsOOB.java#id0 8377908 linux-all

You can't use the bug ID that problem lists to problem list.
The bug ID in the problem list is the OPEN bug that describes the reason the test fails and you'd then fix that bug to remove it.
So you'd need to file another bug that describes the problem and use that.
And should we problem list for everyone because of this ? ie the problem seems to be in the test environment, not the test, and not the JDK. So what is your plan to fix that ?
So I am not ready to approve this. Also I am not sure xvfb is appropriate for running any of our UI tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29761#discussion_r2818388116

From prr at openjdk.org  Tue Feb 17 18:37:19 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 18:37:19 GMT
Subject: Integrated: 8377192: Remove AppContext from MenuSelectionManager
In-Reply-To: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
References: <K5ztIuxFWYGu9L2QK9jBrbgLgUHj_kczlV7Y6ghkevI=.3d078dad-d2d7-41a2-81e2-88e31dc2b49e@github.com>
Message-ID: <vUuUrCfDyf_TQPuyRNJqsgt58LuDa3bLOdNwwFUCcx0=.e4596fad-3036-4fa9-ab4b-31d23ebfedf0@github.com>

On Wed, 4 Feb 2026 20:44:02 GMT, Phil Race <prr at openjdk.org> wrote:

> remove AppContext from Swing's MenuSelectionManager

This pull request has now been integrated.

Changeset: caaebf35
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/caaebf358c0a396664a58ef3e0fc01c16bfd8c03
Stats:     24 lines in 2 files changed: 0 ins; 21 del; 3 mod

8377192: Remove AppContext from MenuSelectionManager

Reviewed-by: dnguyen, psadhukhan, serb

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

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

From prr at openjdk.org  Tue Feb 17 18:38:24 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 18:38:24 GMT
Subject: Integrated: 8376994: Remove AppContext from
 sun/awt/datatransfer/DataTransferer.java
In-Reply-To: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
References: <nvWrhG5tTE7GJSdBGPKk9WvFPk64s3guPK_M8MM4mAY=.7ad4ba03-b9fb-411c-a761-02d6a577255f@github.com>
Message-ID: <lZMDtA2shbyIX1-H4WEmqUNW2lvzHXzvFOolRHKiAMM=.9da3320e-c505-43f6-a581-43669cb8dfdc@github.com>

On Mon, 2 Feb 2026 20:11:33 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from sun/awt/datatransfer/DataTransferer.java

This pull request has now been integrated.

Changeset: 1b192613
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b192613782b06636f68e6cb25871bbebae5445c
Stats:     16 lines in 1 file changed: 0 ins; 9 del; 7 mod

8376994: Remove AppContext from sun/awt/datatransfer/DataTransferer.java

Reviewed-by: serb, dnguyen

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

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

From duke at openjdk.org  Tue Feb 17 18:44:08 2026
From: duke at openjdk.org (Roland Mesde)
Date: Tue, 17 Feb 2026 18:44:08 GMT
Subject: RFR: 8377908: sun/java2d/OpenGL/ScaleParamsOOB.java test fails on
 Linux (xvfb, libmesa software rendering) after JDK-8358058
In-Reply-To: <KUprprv7BWjvIPWKe1ObzG9MPvLfQFraX_GmMY4Whac=.7a6be30a-c670-4a87-a5d4-530447f55880@github.com>
References: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
 <KUprprv7BWjvIPWKe1ObzG9MPvLfQFraX_GmMY4Whac=.7a6be30a-c670-4a87-a5d4-530447f55880@github.com>
Message-ID: <NTPAP0KFJEP74_weZ5B5uiqHTv3oWfzAuGjooczNeew=.4152a9c6-64d2-49bc-b945-e89271932dd6@github.com>

On Tue, 17 Feb 2026 18:09:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
>> 
>> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
>> 
>> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
>> 
>> Results attached:
>> 
>> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25369364/linux-x64-specific-test.log)
>
> test/jdk/ProblemList.txt line 226:
> 
>> 224: sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java 8196180 windows-all,macosx-all
>> 225: sun/java2d/OpenGL/OpaqueDest.java#id1 8367574 macosx-all
>> 226: sun/java2d/OpenGL/ScaleParamsOOB.java#id0 8377908 linux-all
> 
> You can't use the bug ID that problem lists to problem list.
> The bug ID in the problem list is the OPEN bug that describes the reason the test fails and you'd then fix that bug to remove it.
> So you'd need to file another bug that describes the problem and use that.
> And should we problem list for everyone because of this ? ie the problem seems to be in the test environment, not the test, and not the JDK. So what is your plan to fix that ?
> So I am not ready to approve this. Also I am not sure xvfb is appropriate for running any of our UI tests.

I also run it with vglrun and X11 forwarding over SSH with similar results. I'll withdraw this PR and create a separate bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29761#discussion_r2818520904

From duke at openjdk.org  Tue Feb 17 18:44:09 2026
From: duke at openjdk.org (Roland Mesde)
Date: Tue, 17 Feb 2026 18:44:09 GMT
Subject: RFR: 8377908: sun/java2d/OpenGL/ScaleParamsOOB.java test fails on
 Linux (xvfb, libmesa software rendering) after JDK-8358058
In-Reply-To: <NTPAP0KFJEP74_weZ5B5uiqHTv3oWfzAuGjooczNeew=.4152a9c6-64d2-49bc-b945-e89271932dd6@github.com>
References: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
 <KUprprv7BWjvIPWKe1ObzG9MPvLfQFraX_GmMY4Whac=.7a6be30a-c670-4a87-a5d4-530447f55880@github.com>
 <NTPAP0KFJEP74_weZ5B5uiqHTv3oWfzAuGjooczNeew=.4152a9c6-64d2-49bc-b945-e89271932dd6@github.com>
Message-ID: <LKGTaCBVWGcwf-zUPjfp3vndB5YD3CmOjgbaalW_B_c=.73d42878-cae5-4984-8141-1e2c81408eef@github.com>

On Tue, 17 Feb 2026 18:40:48 GMT, Roland Mesde <duke at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 226:
>> 
>>> 224: sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java 8196180 windows-all,macosx-all
>>> 225: sun/java2d/OpenGL/OpaqueDest.java#id1 8367574 macosx-all
>>> 226: sun/java2d/OpenGL/ScaleParamsOOB.java#id0 8377908 linux-all
>> 
>> You can't use the bug ID that problem lists to problem list.
>> The bug ID in the problem list is the OPEN bug that describes the reason the test fails and you'd then fix that bug to remove it.
>> So you'd need to file another bug that describes the problem and use that.
>> And should we problem list for everyone because of this ? ie the problem seems to be in the test environment, not the test, and not the JDK. So what is your plan to fix that ?
>> So I am not ready to approve this. Also I am not sure xvfb is appropriate for running any of our UI tests.
>
> I also run it with vglrun and X11 forwarding over SSH with similar results. I'll withdraw this PR and create a separate bug.

Updated the existing ticket with details on the testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29761#discussion_r2818525129

From serb at openjdk.org  Tue Feb 17 19:10:29 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 19:10:29 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
Message-ID: <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>

> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>  - rgba -> argb, since this is the format described in the spec
>  - hasalpha -> hasAlpha, to follow common naming conventions
> 
> Also adds a basic test for the constructor.

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

  review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29734/files
  - new: https://git.openjdk.org/jdk/pull/29734/files/1752fdff..3ae10ac3

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

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

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

From serb at openjdk.org  Tue Feb 17 19:10:31 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 19:10:31 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <D68_gvBfSOYf9JPnH7oWHSOj5qqm31Aeb-gfACT32c4=.00167277-be17-4b63-8f24-1e6e04204ac1@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <D68_gvBfSOYf9JPnH7oWHSOj5qqm31Aeb-gfACT32c4=.00167277-be17-4b63-8f24-1e6e04204ac1@github.com>
Message-ID: <T-4wlPIQXsQkUHmMApW9Dn7DWyo4oscyofABLLluS08=.8c880d4b-a5db-4522-91c2-8f99619e4b81@github.com>

On Tue, 17 Feb 2026 15:50:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback
>
> src/java.desktop/share/classes/java/awt/Color.java line 404:
> 
>> 402:      * the green component in bits 8-15, and the blue component in bits 0-7. If
>> 403:      * the {@code hasAlpha} argument is {@code false}, alpha is defaulted to
>> 404:      * 255.
> 
> Suggestion:
> 
>      * Creates an sRGB color with the specified combined ARGB value consisting of
>      * <ul>
>      *    <li>the alpha component in bits 24-31,</li>
>      *    <li>the red component in bits 16-23,</li>
>      *    <li>the green component in bits 8-15, and</li>
>      *    <li>the blue component in bits 0-7.</li>
>      * </ul>
>      * If the {@code hasAlpha} argument is {@code false}, alpha is defaulted to 255.
> 
> 
> What do you think about such formatting? Each color component stands out this way.
> 
> I'd also change the last sentence to _?alpha defaults to 255.?_
> 
> However, changing the formatting for this constructor will require changing the formatting for `Color(int rgb)`. And it will break the first sentence summary displayed in the table of contructors methods.

I'll experiment with this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818620545

From duke at openjdk.org  Tue Feb 17 19:15:40 2026
From: duke at openjdk.org (Roland Mesde)
Date: Tue, 17 Feb 2026 19:15:40 GMT
Subject: RFR: 8377908: sun/java2d/OpenGL/ScaleParamsOOB.java test fails on
 Linux (xvfb, libmesa software rendering) after JDK-8358058
In-Reply-To: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
References: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
Message-ID: <2o7SrxNoAAMzyA6vyPwQTR29-TmwHkPcx7-rJ3JDKYQ=.9f49d992-2810-446f-92d9-c2a8a7732db0@github.com>

On Tue, 17 Feb 2026 16:10:19 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
> 
> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
> 
> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25369364/linux-x64-specific-test.log)

Based on feedback. Withdrawing the PR and replacing it with: https://github.com/openjdk/jdk/pull/29765

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

PR Comment: https://git.openjdk.org/jdk/pull/29761#issuecomment-3916617740

From duke at openjdk.org  Tue Feb 17 19:15:40 2026
From: duke at openjdk.org (Roland Mesde)
Date: Tue, 17 Feb 2026 19:15:40 GMT
Subject: Withdrawn: 8377908: sun/java2d/OpenGL/ScaleParamsOOB.java test fails
 on Linux (xvfb, libmesa software rendering) after JDK-8358058
In-Reply-To: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
References: <rKrwNRZpagomE1PuRV2mI7ZiYLPden4co6CHAqdWkHk=.cc131e85-3801-4138-8a5f-878b6b0cf89a@github.com>
Message-ID: <8yE8VE8WVaOpc8yf2azArx4o-3nwUWxg1VFxm74m_PA=.a982a736-7768-4cf8-9eb7-2b18357c97fc@github.com>

On Tue, 17 Feb 2026 16:10:19 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
> 
> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
> 
> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25369364/linux-x64-specific-test.log)

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Feb 17 19:18:13 2026
From: duke at openjdk.org (Roland Mesde)
Date: Tue, 17 Feb 2026 19:18:13 GMT
Subject: RFR: 8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the
 ProblemList.txt file
Message-ID: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>

Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.

Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:

make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java

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

Commit messages:
 - 8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the ProblemList.txt file

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

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

From kizune at openjdk.org  Tue Feb 17 19:22:51 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 17 Feb 2026 19:22:51 GMT
Subject: RFR: 8378050: Add missing @Override annotations in
 "java.awt.color" package
In-Reply-To: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
References: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
Message-ID: <tUJDa9CoFxm7XGcnmaZTpqejj0upU1c6Pza5qjRy4C0=.fc4206fb-6b1c-4562-89ca-56cddbfb41ec@github.com>

On Mon, 16 Feb 2026 20:56:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `java.awt.color` package that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29749#pullrequestreview-3815843311

From prr at openjdk.org  Tue Feb 17 19:26:20 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 19:26:20 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions
Message-ID: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>

This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
A new egression test for each of the constructor and getter/setter cases is supplied.

No existing regression tests fail with this change, and standard demos work.

Problems caused by these changes are most likely to occur if the client has a bug such that 
- a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
- a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 

Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.

A CSR will be submitted.

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

Commit messages:
 - 8377568
 - 8377568

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

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

From prr at openjdk.org  Tue Feb 17 19:35:17 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 19:35:17 GMT
Subject: RFR: 8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the
 ProblemList.txt file
In-Reply-To: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
References: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
Message-ID: <rEpeWeDuvLJA1mxIYSdjGRkzp--p-emYzsxPH6bet30=.5b56f0de-7191-4f73-9133-d9978e1e8a9b@github.com>

On Tue, 17 Feb 2026 19:08:48 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
> 
> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
> 
> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25372774/linux-x64-specific-test.log)

OK. Approving.
Maybe we have a product bug ?
 Ignoring some response from mesa  in the software case that a feature is not available ?

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29765#pullrequestreview-3815890516

From aivanov at openjdk.org  Tue Feb 17 19:46:32 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 19:46:32 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
Message-ID: <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>

On Tue, 17 Feb 2026 19:10:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>>  - rgba -> argb, since this is the format described in the spec
>>  - hasalpha -> hasAlpha, to follow common naming conventions
>> 
>> Also adds a basic test for the constructor.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

src/java.desktop/share/classes/java/awt/Color.java line 337:

> 335:      * on finding the best match given the color space
> 336:      * available for a given output device.
> 337:      * Alpha defaults to 255.

I think it's better this way, but I'll leave it to Phil.

test/jdk/java/awt/ColorClass/ColorARGBConstructorTest.java line 49:

> 47:         int expA = hasAlpha ? (argb >>> 24) : 0xFF;
> 48:         int expR = (argb >> 16) & 0xFF;
> 49:         int expG = (argb >> 8) & 0xFF;

This was not what I meant:

Suggestion:

        int expA = hasAlpha ? (argb >>> 24) : 0xFF;
        int expR = (argb >>> 16);
        int expG = (argb >>> 8);


or 


Suggestion:

        int expA = hasAlpha ? ((argb >> 24)  & 0xFF) : 0xFF;
        int expR = (argb >> 16) & 0xFF;
        int expG = (argb >> 8) & 0xFF;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818761015
PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818758144

From serb at openjdk.org  Tue Feb 17 19:51:42 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 19:51:42 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
Message-ID: <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>

On Tue, 17 Feb 2026 19:42:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback
>
> test/jdk/java/awt/ColorClass/ColorARGBConstructorTest.java line 49:
> 
>> 47:         int expA = hasAlpha ? (argb >>> 24) : 0xFF;
>> 48:         int expR = (argb >> 16) & 0xFF;
>> 49:         int expG = (argb >> 8) & 0xFF;
> 
> This was not what I meant:
> 
> Suggestion:
> 
>         int expA = hasAlpha ? (argb >>> 24) : 0xFF;
>         int expR = (argb >>> 16);
>         int expG = (argb >>> 8);
> 
> 
> or 
> 
> 
> Suggestion:
> 
>         int expA = hasAlpha ? ((argb >> 24)  & 0xFF) : 0xFF;
>         int expR = (argb >> 16) & 0xFF;
>         int expG = (argb >> 8) & 0xFF;

I understand that, but prefer >>> for alpha only. "()" is added to make operation order clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818782217

From serb at openjdk.org  Tue Feb 17 20:04:17 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 20:04:17 GMT
Subject: RFR: 8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the
 ProblemList.txt file
In-Reply-To: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
References: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
Message-ID: <M3vscJHGh21RSUQAGTx7bBB5IRaEzW5MBxLbVXJFWbM=.cc04b546-9898-4e94-9c77-1d5fd0907276@github.com>

On Tue, 17 Feb 2026 19:08:48 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
> 
> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
> 
> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25372774/linux-x64-specific-test.log)

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29765#pullrequestreview-3815998149

From serb at openjdk.org  Tue Feb 17 20:04:18 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 20:04:18 GMT
Subject: RFR: 8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the
 ProblemList.txt file
In-Reply-To: <rEpeWeDuvLJA1mxIYSdjGRkzp--p-emYzsxPH6bet30=.5b56f0de-7191-4f73-9133-d9978e1e8a9b@github.com>
References: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
 <rEpeWeDuvLJA1mxIYSdjGRkzp--p-emYzsxPH6bet30=.5b56f0de-7191-4f73-9133-d9978e1e8a9b@github.com>
Message-ID: <iX_SN0H3AtqkirfIQnQjtQIM7Xgt-ajkHJIn7RfTMhk=.ba131f24-6684-4844-b254-86d399ff3602@github.com>

On Tue, 17 Feb 2026 19:32:38 GMT, Phil Race <prr at openjdk.org> wrote:

> Maybe we have a product bug ?

Seems so.

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

PR Comment: https://git.openjdk.org/jdk/pull/29765#issuecomment-3916810440

From aivanov at openjdk.org  Tue Feb 17 20:23:39 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 20:23:39 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
Message-ID: <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>

On Tue, 17 Feb 2026 19:49:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/java/awt/ColorClass/ColorARGBConstructorTest.java line 49:
>> 
>>> 47:         int expA = hasAlpha ? (argb >>> 24) : 0xFF;
>>> 48:         int expR = (argb >> 16) & 0xFF;
>>> 49:         int expG = (argb >> 8) & 0xFF;
>> 
>> This was not what I meant:
>> 
>> Suggestion:
>> 
>>         int expA = hasAlpha ? (argb >>> 24) : 0xFF;
>>         int expR = (argb >>> 16);
>>         int expG = (argb >>> 8);
>> 
>> 
>> or 
>> 
>> 
>> Suggestion:
>> 
>>         int expA = hasAlpha ? ((argb >> 24)  & 0xFF) : 0xFF;
>>         int expR = (argb >> 16) & 0xFF;
>>         int expG = (argb >> 8) & 0xFF;
>
> I understand that, but prefer >>> for alpha only. "()" is added to make operation order clear.

You can still use `>>>` for other components, it will look consistent at least. Otherwise, you can't help wondering why different operators are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818896177

From aivanov at openjdk.org  Tue Feb 17 20:23:40 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 20:23:40 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
 <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
Message-ID: <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>

On Tue, 17 Feb 2026 20:19:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I understand that, but prefer >>> for alpha only. "()" is added to make operation order clear.
>
> You can still use `>>>` for other components, it will look consistent at least. Otherwise, you can't help wondering why different operators are used.

That is


        int expR = (argb >>> 16) & 0xFF;
        int expG = (argb >>> 8) & 0xFF;

wouldn't raise questions.

(And I was wrong in my suggestion above, you still need `&`.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818904872

From serb at openjdk.org  Tue Feb 17 20:27:02 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 20:27:02 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
 <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
 <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>
Message-ID: <ExRte_gTcE2IoCNHBW6XF5sU5AUAkEaQc_n0bXgCTCU=.6dcc4c5e-3226-4986-9c72-6453d7f7fd6b@github.com>

On Tue, 17 Feb 2026 20:21:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> You can still use `>>>` for other components, it will look consistent at least. Otherwise, you can't help wondering why different operators are used.
>
> That is
> 
> 
>         int expR = (argb >>> 16) & 0xFF;
>         int expG = (argb >>> 8) & 0xFF;
> 
> wouldn't raise questions.
> 
> (And I was wrong in my suggestion above, you still need `&`.)

>int expR = (argb >>> 16);
>You can still use >>> for other components, 

it does not work for others, it works only for alpha.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818918391

From serb at openjdk.org  Tue Feb 17 20:32:54 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 20:32:54 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v3]
In-Reply-To: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
Message-ID: <p-BaTiQk2-emijZiUsiMb3-suBzcfLYw5AHu8Hjoy7A=.6036b2bf-f41f-4d93-b564-fc65983fe8eb@github.com>

> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>  - rgba -> argb, since this is the format described in the spec
>  - hasalpha -> hasAlpha, to follow common naming conventions
> 
> Also adds a basic test for the constructor.

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

  lists via "<ul>" is added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29734/files
  - new: https://git.openjdk.org/jdk/pull/29734/files/3ae10ac3..f12b4406

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

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

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

From serb at openjdk.org  Tue Feb 17 20:32:56 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 20:32:56 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v3]
In-Reply-To: <T-4wlPIQXsQkUHmMApW9Dn7DWyo4oscyofABLLluS08=.8c880d4b-a5db-4522-91c2-8f99619e4b81@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <D68_gvBfSOYf9JPnH7oWHSOj5qqm31Aeb-gfACT32c4=.00167277-be17-4b63-8f24-1e6e04204ac1@github.com>
 <T-4wlPIQXsQkUHmMApW9Dn7DWyo4oscyofABLLluS08=.8c880d4b-a5db-4522-91c2-8f99619e4b81@github.com>
Message-ID: <GwZAb5O-NcOI9t5fy-qWIGBUFteelbOaXv5rha970TU=.671fd652-c313-4ca8-86b9-a0a1d7c45b25@github.com>

On Tue, 17 Feb 2026 19:06:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Color.java line 404:
>> 
>>> 402:      * the green component in bits 8-15, and the blue component in bits 0-7. If
>>> 403:      * the {@code hasAlpha} argument is {@code false}, alpha is defaulted to
>>> 404:      * 255.
>> 
>> Suggestion:
>> 
>>      * Creates an sRGB color with the specified combined ARGB value consisting of
>>      * <ul>
>>      *    <li>the alpha component in bits 24-31,</li>
>>      *    <li>the red component in bits 16-23,</li>
>>      *    <li>the green component in bits 8-15, and</li>
>>      *    <li>the blue component in bits 0-7.</li>
>>      * </ul>
>>      * If the {@code hasAlpha} argument is {@code false}, alpha is defaulted to 255.
>> 
>> 
>> What do you think about such formatting? Each color component stands out this way.
>> 
>> I'd also change the last sentence to _?alpha defaults to 255.?_
>> 
>> However, changing the formatting for this constructor will require changing the formatting for `Color(int rgb)`. And it will break the first sentence summary displayed in the table of contructors methods.
>
> I'll experiment with this.

It actually handled by javadoc properly -> correct summary is generated, I tried to unify the text in the constructors and getRGB method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818940601

From aivanov at openjdk.org  Tue Feb 17 20:32:57 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 20:32:57 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <ExRte_gTcE2IoCNHBW6XF5sU5AUAkEaQc_n0bXgCTCU=.6dcc4c5e-3226-4986-9c72-6453d7f7fd6b@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
 <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
 <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>
 <ExRte_gTcE2IoCNHBW6XF5sU5AUAkEaQc_n0bXgCTCU=.6dcc4c5e-3226-4986-9c72-6453d7f7fd6b@github.com>
Message-ID: <JtfxmtQs-fKHTnSRhM3cw6aTVS-BCQskSUzRehnCd6c=.4ab96382-26d7-4f22-b32a-4c35bb7dfe86@github.com>

On Tue, 17 Feb 2026 20:24:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > int expR = (argb >>> 16);
> > You can still use >>> for other components,
> 
> it does not work for others, it works only for alpha.

No, it doesn't work without `& 0xFF`.

How can this not work?


        int expR = (argb >>> 16) & 0xFF;
        int expG = (argb >>> 8) & 0xFF;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818938012

From serb at openjdk.org  Tue Feb 17 20:39:52 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 20:39:52 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <JtfxmtQs-fKHTnSRhM3cw6aTVS-BCQskSUzRehnCd6c=.4ab96382-26d7-4f22-b32a-4c35bb7dfe86@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
 <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
 <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>
 <ExRte_gTcE2IoCNHBW6XF5sU5AUAkEaQc_n0bXgCTCU=.6dcc4c5e-3226-4986-9c72-6453d7f7fd6b@github.com>
 <JtfxmtQs-fKHTnSRhM3cw6aTVS-BCQskSUzRehnCd6c=.4ab96382-26d7-4f22-b32a-4c35bb7dfe86@github.com>
Message-ID: <cLC4w0WH36I363iirCUbfgaBZ-N_vwrQ6_FK1MgGeVc=.048b624a-5daa-406d-95bc-7278a12d529b@github.com>

On Tue, 17 Feb 2026 20:28:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>No, it doesn't work without & 0xFF.

Initially, you suggested it without &FF, and my answer was about the text I quoted.

> int expG = (argb >>> 8) & 0xFF;

That is not necessary to use >>> shift for red and green, as well as >> plus &FF for blue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818952177

From aivanov at openjdk.org  Tue Feb 17 20:39:53 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 20:39:53 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <cLC4w0WH36I363iirCUbfgaBZ-N_vwrQ6_FK1MgGeVc=.048b624a-5daa-406d-95bc-7278a12d529b@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
 <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
 <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>
 <ExRte_gTcE2IoCNHBW6XF5sU5AUAkEaQc_n0bXgCTCU=.6dcc4c5e-3226-4986-9c72-6453d7f7fd6b@github.com>
 <JtfxmtQs-fKHTnSRhM3cw6aTVS-BCQskSUzRehnCd6c=.4ab96382-26d7-4f22-b32a-4c35bb7dfe86@github.com>
 <cLC4w0WH36I363iirCUbfgaBZ-N_vwrQ6_FK1MgGeVc=.048b624a-5daa-406d-95bc-7278a12d529b@github.com>
Message-ID: <IhgnrtFjbYR1GnOL96EFmrmS_ETb4L1sJgLt_Q12_wc=.b3f4f56a-4a53-49f0-acce-f79a7eb95bd1@github.com>

On Tue, 17 Feb 2026 20:32:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > int expR = (argb >>> 16);
>>> > You can still use >>> for other components,
>>> 
>>> it does not work for others, it works only for alpha.
>> 
>> No, it doesn't work without `& 0xFF`.
>> 
>> How can this not work?
>> 
>> 
>>         int expR = (argb >>> 16) & 0xFF;
>>         int expG = (argb >>> 8) & 0xFF;
>
>>No, it doesn't work without & 0xFF.
> 
> Initially, you suggested it without &FF, and my answer was about the text I quoted.
> 
>> int expG = (argb >>> 8) & 0xFF;
> 
> That is not necessary to use >>> shift for red and green, as well as >> plus &FF for blue.

Not necessary, but using `>>>` doesn't change the result, and using the same operator in all the three cases looks *consistent*.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2818961050

From serb at openjdk.org  Tue Feb 17 20:48:54 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Feb 2026 20:48:54 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <IhgnrtFjbYR1GnOL96EFmrmS_ETb4L1sJgLt_Q12_wc=.b3f4f56a-4a53-49f0-acce-f79a7eb95bd1@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
 <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
 <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>
 <ExRte_gTcE2IoCNHBW6XF5sU5AUAkEaQc_n0bXgCTCU=.6dcc4c5e-3226-4986-9c72-6453d7f7fd6b@github.com>
 <JtfxmtQs-fKHTnSRhM3cw6aTVS-BCQskSUzRehnCd6c=.4ab96382-26d7-4f22-b32a-4c35bb7dfe86@github.com>
 <cLC4w0WH36I363iirCUbfgaBZ-N_vwrQ6_FK1MgGeVc=.048b624a-5daa-406d-95bc-7278a12d529b@github.com>
 <IhgnrtFjbYR1GnOL96EFmrmS_ETb4L1sJgLt_Q12_wc=.b3f4f56a-4a53-49f0-acce-f79a7eb95bd1@github.com>
Message-ID: <ni74XwWt2K2IwCOkLYVZ72FU9KqTXxEW4X3KXMRpWF8=.b948cb6e-1ca0-4183-98c1-4c6fa6ff17d1@github.com>

On Tue, 17 Feb 2026 20:34:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>>No, it doesn't work without & 0xFF.
>> 
>> Initially, you suggested it without &FF, and my answer was about the text I quoted.
>> 
>>> int expG = (argb >>> 8) & 0xFF;
>> 
>> That is not necessary to use >>> shift for red and green, as well as >> plus &FF for blue.
>
> Not necessary, but using `>>>` doesn't change the result, and using the same operator in all the three cases looks *consistent*.

Why should it use the same operator for all of them if some are unnecessary? I prefer >>> for alpha because it works well without additional masking, and masking only for blue, which does not need a shift by zero. It is short and clean, and there is no need to align it beautifully just to make it look better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2819007083

From aivanov at openjdk.org  Tue Feb 17 21:22:38 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 21:22:38 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <P_X0ebK3z863Girui9Z4PaECUZwgQrxv7Pk23HI8KIE=.032bf0cd-a45f-41eb-8cc6-5c9a74983155@github.com>

On Tue, 17 Feb 2026 19:17:27 GMT, Phil Race <prr at openjdk.org> wrote:

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> A CSR will be submitted.

You have to use the `@throws` javadoc tag, `throw` will not work.

Usually, the description of condition where an exception is thrown doesn't have a full stop. Currently, the ending punctuation is inconsistent even within one constructor, for example `public DataBufferByte(byte[][] dataArray, int size)`.

https://github.com/prrace/jdk/blob/2c9edaaad1a7ec66f73703b458ee3684eae886e1/src/java.desktop/share/classes/java/awt/image/DataBufferByte.java#L188-L194

The first has `.`; the second has `,`; the third has `.` where `,` should be and has no `.` at the end.

src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 555:

> 553:             throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
> 554:                  "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);
> 555:         }

Suggestion:

      if ((i + offsets[bank]) >= size) {
          throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
                  "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);
      }

Wrong indentation.

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 74:

> 72:      *
> 73:      * @param size The size of the {@code DataBuffer}.
> 74:      * throw IllegalArgumentException if {@code size} is less than zero.

Suggestion:

     * @throws IllegalArgumentException if {@code size} is less than zero

You have to use `@throws` javadoc tag. Usually, `@throws` descriptions don't have a full stop.

https://github.com/openjdk/jdk/blob/4ab05d25c170036cd85155c45e58930fedf614a4/src/java.desktop/share/classes/java/awt/image/DataBuffer.java#L117-L118

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 93:

> 91:      * @param numBanks The number of banks in the {@code DataBuffer}.
> 92:      * throw IllegalArgumentException if {@code size} is less than zero,
> 93:      * or {@code numBanks} is less than one

Suggestion:

     * @throws IllegalArgumentException if {@code size} is less than zero,
     *         or {@code numBanks} is less than one

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 159:

> 157:      * throw NullPointerException if {@code dataArray} is {@code null}.
> 158:      * throw IllegalArgumentException if {@code size} is less than zero,
> 159:      * or {@code (offset + size)} is greater than the length of {@code dataArray}

Suggestion:

     * @throws NullPointerException if {@code dataArray} is {@code null}
     * @throws IllegalArgumentException if {@code size} is less than zero,
     *         or {@code (offset + size)} is greater than the length of {@code dataArray}

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29766#pullrequestreview-3816313674
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819087749
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819097726
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819099213
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819102952

From prr at openjdk.org  Tue Feb 17 21:36:15 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 21:36:15 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v2]
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <cJHcU1uRDiyg9F3UhFqu8aHSonvwi6nmNZaLe9FKzls=.3799a625-920b-403c-ae18-ed718883afd1@github.com>

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> A CSR will be submitted.

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

  8377568

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29766/files
  - new: https://git.openjdk.org/jdk/pull/29766/files/2c9edaaa..6f355941

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

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

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

From aivanov at openjdk.org  Tue Feb 17 21:48:38 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 21:48:38 GMT
Subject: RFR: 8377924: Inconsistent parsing of XBM files after JDK-8361748
Message-ID: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>

[JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748 "Enforce limits on the size of an XBM image") and [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727 "New XBM images parser regression: only the first line of the bitmap array is parsed") changed how XBM files are parsed, and now some of the valid XBM images are parsed inconsistently. For example,


#define ht 1
#define th 8
k[] = {0xAB}; 


is parsed as image of size 1?8 instead of 8?1 after JDK-8361748.

The above problem is addressed by [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727). However, the code to differentiate between width and height differs from the original code that was used before [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748). Due to this difference,


#define ht 1
#define h 8 


is rejected: Invalid values for width or height.

Previously, `-h` was a marker for width, and `-ht` was for height.

https://github.com/openjdk/jdk/blob/fc807d0914c4d8d2a174410a35acf3520ff4e60a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112

But [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727) uses `-th` for width and `-t` for height.

https://github.com/openjdk/jdk/blob/7f707ba8e746d859ac171d71ef8f731953a92e6a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L114-L118

For backward compatibility, we should revert to `-h` and `-ht`.

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

Commit messages:
 - 8377924: Inconsistent parsing of XBM files after JDK-8361748

Changes: https://git.openjdk.org/jdk/pull/29769/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29769&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377924
  Stats: 162 lines in 12 files changed: 144 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/29769.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29769/head:pull/29769

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

From aivanov at openjdk.org  Tue Feb 17 21:59:06 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 21:59:06 GMT
Subject: RFR: 8373727: New XBM images parser regression: only the first
 line of the bitmap array is parsed [v3]
In-Reply-To: <2z_rf5DfYIl4DYFm58a35_oJK-PGoONVdnGyAlsGmYc=.772a0f35-7f1c-42c2-be49-17683f32003b@github.com>
References: <MiL3Jr_pDrK2X8IeUXCzib46rRj82GN94gihPB5ddMw=.b5dab032-978f-47bb-8e71-d77b5dd2d9b7@github.com>
 <2z_rf5DfYIl4DYFm58a35_oJK-PGoONVdnGyAlsGmYc=.772a0f35-7f1c-42c2-be49-17683f32003b@github.com>
Message-ID: <T5Tj_mDQZ0R7T7v2wHmswWdFkwUDHVp3gSFvguEfYig=.deb5b460-743c-4608-8b2a-68ca568bc5b4@github.com>

On Mon, 12 Jan 2026 20:00:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> There were three concerns with the previous changes to `XbmImageDecoder`.
>> 1. Only the first line of the bit array was read.
>> 2. The regex was incorrect because it used `[]` instead of `()` for some grouping.
>> 3. The ordering of the width and height in the xbm file was too strict and had to be width first, then height.
>> 
>> To fix these issues, I have:
>> 1. Used a StringBuilder to append lines of the bit array to parse the entire array at once. This required changing the parsing loop and moving some code.
>> 2. Updated the regex to capture starting whitespace, optionally start with `0x`, include all chars/digits/punctuation (minus `,` and `};`) instead of just valid hex digits, and end with either `,` or `};`. This also allows for incorrect hex values such as `0x12345abcde` to be detected since the new regex allows for multiple chars after the `0x` until the next delimiter is found. This is accounted for in the test xbm files.
>> 3. Determined width or height based off of ending letters (`th` or `t`). This is similar to https://github.com/openjdk/jdk/blob/jdk-26+10/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112.
>> 
>> A new method is added to `XBMDecoderTest.java` to better check that the bit array parsing works. This method checks for non-empty pixel data.
>> 
>> A new xbm file is also added to check for the case where `0xAB+` exists in the bit array. This should be invalid, and the previous regex would allow this to pass. 
>> 
>> All tests pass with the new changes made here.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new xbm file to test for multiple lines in bit array

src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java line 118:

> 116:                             } else if (token[1].endsWith("t")) {
> 117:                                 H = Integer.parseInt(token[2]);
> 118:                             }

~~Wouldn't it be better to use `width` and `height` in `endsWith`? The code would be clearer.~~ But it will break backwards compatibility.

I submitted [JDK-8377924](https://bugs.openjdk.org/browse/JDK-8377924 "Inconsistent parsing of XBM files after JDK-8361748") to address inconsistency with parsing `.xbm` files after [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748) and [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727): the old code used `-h` and `-ht` as the markers for width and height correspondingly.

src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java line 127:

> 125:                             }
> 126:                             state = 2; // after second dimension is set
> 127:                         }

~~Isn't a problem that state 2 can be reached where only `W` or `H` are set?~~

I found the answer myself: `state == 2 && (W <= 0 || H <= 0)` will throw an error.

test/jdk/java/awt/image/XBMDecoder/XBMDecoderTest.java line 2:

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

It should've become `(c) 2025, 2026, Oracle`.

Addressed in #29769.

test/jdk/java/awt/image/XBMDecoder/invalid_empty.xbm line 1:

> 1: #define test_width 16

Why is `invalid_empty.xbm` invalid?

If it is, then an exception should be thrown while decoding the image, but no exception is thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29120#discussion_r2747895862
PR Review Comment: https://git.openjdk.org/jdk/pull/29120#discussion_r2732166730
PR Review Comment: https://git.openjdk.org/jdk/pull/29120#discussion_r2819266987
PR Review Comment: https://git.openjdk.org/jdk/pull/29120#discussion_r2818621385

From aivanov at openjdk.org  Tue Feb 17 22:00:49 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 22:00:49 GMT
Subject: RFR: 8377924: Inconsistent parsing of XBM files after JDK-8361748
In-Reply-To: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
References: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
Message-ID: <tSFX3vAPjcHrLtPiXBPdO_LzmcQfe6tVuhJLbPSVHds=.7b55d36b-debf-4834-b89a-0502810bf167@github.com>

On Tue, 17 Feb 2026 21:41:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748 "Enforce limits on the size of an XBM image") and [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727 "New XBM images parser regression: only the first line of the bitmap array is parsed") changed how XBM files are parsed, and now some of the valid XBM images are parsed inconsistently. For example,
> 
> 
> #define ht 1
> #define th 8
> k[] = {0xAB}; 
> 
> 
> is parsed as image of size 1?8 instead of 8?1 after JDK-8361748.
> 
> The above problem is addressed by [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727). However, the code to differentiate between width and height differs from the original code that was used before [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748). Due to this difference,
> 
> 
> #define ht 1
> #define h 8 
> 
> 
> is rejected: Invalid values for width or height.
> 
> Previously, `-h` was a marker for width, and `-ht` was for height.
> 
> https://github.com/openjdk/jdk/blob/fc807d0914c4d8d2a174410a35acf3520ff4e60a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112
> 
> But [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727) uses `-th` for width and `-t` for height.
> 
> https://github.com/openjdk/jdk/blob/7f707ba8e746d859ac171d71ef8f731953a92e6a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L114-L118
> 
> For backward compatibility, we should revert to `-h` and `-ht`.

@DamonGuy, @prrace, @jayathirthrao Could you take a look?

This PR addresses an issue I discovered in #29120.

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

PR Comment: https://git.openjdk.org/jdk/pull/29769#issuecomment-3917285688

From duke at openjdk.org  Tue Feb 17 22:03:27 2026
From: duke at openjdk.org (duke)
Date: Tue, 17 Feb 2026 22:03:27 GMT
Subject: RFR: 8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the
 ProblemList.txt file
In-Reply-To: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
References: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
Message-ID: <v3Hj19xOnTMrb43BduCRUpir0pLGVYPTHutE5Y69GwY=.5a0bbf70-65a4-49e1-ba4b-fda2394d8386@github.com>

On Tue, 17 Feb 2026 19:08:48 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
> 
> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
> 
> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25372774/linux-x64-specific-test.log)

@rm-gh-8 
Your change (at version 21bb42953a492e0f1250afc32eef5f52009b674f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29765#issuecomment-3917298426

From prr at openjdk.org  Tue Feb 17 22:04:50 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 22:04:50 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v3]
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <vTYDoizYHGuQ2R5i0_E8UqZ9VxJJNR5HW8Q60zAtZMk=.3a9d1b2a-7ba8-4969-a9cb-85cc25b1846b@github.com>

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> A CSR will be submitted.

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

  8377568

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29766/files
  - new: https://git.openjdk.org/jdk/pull/29766/files/6f355941..9d393f74

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

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

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

From prr at openjdk.org  Tue Feb 17 22:04:52 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 22:04:52 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v3]
In-Reply-To: <P_X0ebK3z863Girui9Z4PaECUZwgQrxv7Pk23HI8KIE=.032bf0cd-a45f-41eb-8cc6-5c9a74983155@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <P_X0ebK3z863Girui9Z4PaECUZwgQrxv7Pk23HI8KIE=.032bf0cd-a45f-41eb-8cc6-5c9a74983155@github.com>
Message-ID: <hMt6tdgH6hJJxlazdIRtJJjJGRDNE2M8tP2ZkxzJuZQ=.dbde0e51-d99a-4640-a24a-ae9cf48d02d9@github.com>

On Tue, 17 Feb 2026 21:05:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377568
>
> src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 555:
> 
>> 553:             throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
>> 554:                  "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);
>> 555:         }
> 
> Suggestion:
> 
>       if ((i + offsets[bank]) >= size) {
>           throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
>                   "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);
>       }
> 
> Wrong indentation.

It may not be what you meant but I changed it to 4.

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 74:
> 
>> 72:      *
>> 73:      * @param size The size of the {@code DataBuffer}.
>> 74:      * throw IllegalArgumentException if {@code size} is less than zero.
> 
> Suggestion:
> 
>      * @throws IllegalArgumentException if {@code size} is less than zero
> 
> You have to use `@throws` javadoc tag. Usually, `@throws` descriptions don't have a full stop.
> 
> https://github.com/openjdk/jdk/blob/4ab05d25c170036cd85155c45e58930fedf614a4/src/java.desktop/share/classes/java/awt/image/DataBuffer.java#L117-L118

I fixed this.

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 93:
> 
>> 91:      * @param numBanks The number of banks in the {@code DataBuffer}.
>> 92:      * throw IllegalArgumentException if {@code size} is less than zero,
>> 93:      * or {@code numBanks} is less than one
> 
> Suggestion:
> 
>      * @throws IllegalArgumentException if {@code size} is less than zero,
>      *         or {@code numBanks} is less than one

fixed

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 159:
> 
>> 157:      * throw NullPointerException if {@code dataArray} is {@code null}.
>> 158:      * throw IllegalArgumentException if {@code size} is less than zero,
>> 159:      * or {@code (offset + size)} is greater than the length of {@code dataArray}
> 
> Suggestion:
> 
>      * @throws NullPointerException if {@code dataArray} is {@code null}
>      * @throws IllegalArgumentException if {@code size} is less than zero,
>      *         or {@code (offset + size)} is greater than the length of {@code dataArray}

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819282173
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819284940
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819286298
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819285624

From aivanov at openjdk.org  Tue Feb 17 22:13:04 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Feb 2026 22:13:04 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v3]
In-Reply-To: <vTYDoizYHGuQ2R5i0_E8UqZ9VxJJNR5HW8Q60zAtZMk=.3a9d1b2a-7ba8-4969-a9cb-85cc25b1846b@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <vTYDoizYHGuQ2R5i0_E8UqZ9VxJJNR5HW8Q60zAtZMk=.3a9d1b2a-7ba8-4969-a9cb-85cc25b1846b@github.com>
Message-ID: <llieCRvASoQ6arYPFBpBLQ6zZa6eUCatXl99leht3Ok=.b1b38b80-c13e-452f-adaa-e80791d5a120@github.com>

On Tue, 17 Feb 2026 22:04:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
>> A new egression test for each of the constructor and getter/setter cases is supplied.
>> 
>> No existing regression tests fail with this change, and standard demos work.
>> 
>> Problems caused by these changes are most likely to occur if the client has a bug such that 
>> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
>> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
>> 
>> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
>> 
>> A CSR will be submitted.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377568

src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 555:

> 553:             throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
> 554:                 "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);
> 555:         }

No, it wasn't what I meant. The `throw` statement should be indented by 4 spaces?now there are 6 spaces. The continuation lines should be indented by 8 spaces, but there were 7. This is the recommendation from the [Java Style Guide for Indentation](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819317188

From prr at openjdk.org  Tue Feb 17 22:39:42 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 22:39:42 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v4]
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <5StOPdQH7yYKKBeqyzMYzpiAhys6tOURG6jQc8-ViUA=.fc69b8a4-0f4c-4d91-b809-3dc8a5c5408d@github.com>

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116

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

  8377568

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29766/files
  - new: https://git.openjdk.org/jdk/pull/29766/files/9d393f74..1ef21b8a

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

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

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

From prr at openjdk.org  Tue Feb 17 22:39:44 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 22:39:44 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v3]
In-Reply-To: <llieCRvASoQ6arYPFBpBLQ6zZa6eUCatXl99leht3Ok=.b1b38b80-c13e-452f-adaa-e80791d5a120@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <vTYDoizYHGuQ2R5i0_E8UqZ9VxJJNR5HW8Q60zAtZMk=.3a9d1b2a-7ba8-4969-a9cb-85cc25b1846b@github.com>
 <llieCRvASoQ6arYPFBpBLQ6zZa6eUCatXl99leht3Ok=.b1b38b80-c13e-452f-adaa-e80791d5a120@github.com>
Message-ID: <LOGkg3i6RaMW0Y_vnK80bnB0MLx4TW86d9k27ryi5AA=.b5fc4357-827a-4e9a-9461-ecdcd5518487@github.com>

On Tue, 17 Feb 2026 22:10:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377568
>
> src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 555:
> 
>> 553:             throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
>> 554:                 "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);
>> 555:         }
> 
> No, it wasn't what I meant. The `throw` statement should be indented by 4 spaces?now there are 6 spaces. The continuation lines should be indented by 8 spaces, but there were 7. This is the recommendation from the [Java Style Guide for Indentation](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html).

They are (now) consistently 4. I don't think I've ever used 8 for continuation.
I use 4 (more) unless there's a natural alignment that seems attractive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2819390886

From prr at openjdk.org  Tue Feb 17 23:18:05 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 23:18:05 GMT
Subject: RFR: 8378050: Add missing @Override annotations in
 "java.awt.color" package
In-Reply-To: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
References: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
Message-ID: <BTO5KqHQ1xS3vNPjvN5fBFFr-wfMAWvnupz4hMzaBEc=.4e4a4127-3a2b-4806-8521-6f442bc483b8@github.com>

On Mon, 16 Feb 2026 20:56:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `java.awt.color` package that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29749#pullrequestreview-3816789057

From prr at openjdk.org  Tue Feb 17 23:19:51 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Feb 2026 23:19:51 GMT
Subject: RFR: 8377938: VoiceOver Uses Mouse to Activate JButtons in German
In-Reply-To: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
References: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
Message-ID: <bIBHypFymcbp1EfvECXUC9BNslcaAKNM9w_v-8UVV5Q=.83522539-e026-47b1-b7e6-3fdbb29f26cf@github.com>

On Sat, 14 Feb 2026 23:47:10 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> Previously:
> The action description would be localized text. So in German's case `getAccessibleActionDescription(0)` would return `Klicken`. As that String is passed upwards towards VoiceOver, we're counting on VoiceOver's code interpreting it correctly.
> 
> With this PR:
> We always return "click" (using the AccessibleAction.CLICK constant). VoiceOver knows how to interpret an unlocalized "click".
> 
> ## Context
> 
> I looked up references to other AccessibleAction constants:
> 
> - AccessibleAction.TOGGLE_EXPAND is referenced in JTree.java's `getAccessibleActionDescription` method.
> - AccessibleAction.INCREMENT and AccessibleAction.DECREMENT are referenced in JSlider's and JSpinner's `getAccessibleActionDescription` method.
> - AccessibleAction.CLICK and AccessibleAction.TOGGLE_POPUP are NOT currently referenced (prior to this PR)
> 
> The javadoc for `getAccessibleActionDescription` simply describes the return value as "a String description of the action". It makes no comment on whether it should be localized or not.
> 
> JList.java is similar to AbstractButton:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("AbstractButton.clickText");
>     } else {
>         return null;
>     }
> }
> 
> 
> JComboBox.java includes:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("ComboBox.togglePopupText");
>     }
>     else {
>         return null;
>     }
> }
> 
> 
> I'd argue that we need to be consistent: either JTree/JSlider/JSpinner should be modified to return a localized action description, OR AbstractButton/JList/JComboBox should be modified to return the unlocalized constant.
> 
> My preference is to modify AbstractButton and JList (as shown in this PR). (And I'd recommend addressing JComboBox in a separate PR.)
> 
> (Also, I really like JTextComponent.java's implementation that combined Swing's ActionMap with AccessibleActions:
> 
> public String getAccessibleActionDescription(int i) {
>     Action [] actions = JTextComponent.this.getActions();
>     if (i < 0 || i >= actions.length) {
>         return null;
>     }
>     return (String)actions[i].getValue(Action.NAME);
> }
> 
> ... but that's straying pretty far from the original ticket.)
> 
> ## Non-Swing Context
> 
> I also searched for `getAccessibleActionDescription` in general.
> 
> In Button.java and MenuItem.java we have:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         // [[[PENDING:  WDW -- need to provide a localized string]]]
>         retur...

@azuev-java please review

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

PR Comment: https://git.openjdk.org/jdk/pull/29727#issuecomment-3917571285

From duke at openjdk.org  Tue Feb 17 23:38:06 2026
From: duke at openjdk.org (Roland Mesde)
Date: Tue, 17 Feb 2026 23:38:06 GMT
Subject: Integrated: 8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the
 ProblemList.txt file
In-Reply-To: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
References: <bJF29t-I5B2zQt1yNXieYWNv0upsVWfC07gZaDy06rI=.2bda04aa-306a-448a-8e77-4486c1c1735b@github.com>
Message-ID: <ylxwKvvUwkSzsvfePeVXz_uYbbfMYHn6mwJ01sjm6Q0=.24184883-6fb6-4361-a2c7-84f0e48f8124@github.com>

On Tue, 17 Feb 2026 19:08:48 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Added the sun/java2d/OpenGL/ScaleParamsOOB.java test to the problem list due to test failures on Linux (software rendering) since it was added.
> 
> Confirmed that the test no longer runs after it was added to the problem list by running the following on linux-x64:
> 
> make test TEST=test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/25372774/linux-x64-specific-test.log)

This pull request has now been integrated.

Changeset: 2bc43681
Author:    Roland Mesde <mesde at amazon.com>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bc436816f86187335846b289fac0fd8ebb3759e
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8378113: Add sun/java2d/OpenGL/ScaleParamsOOB.java to the ProblemList.txt file

Reviewed-by: prr, serb

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

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

From psadhukhan at openjdk.org  Wed Feb 18 03:23:35 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 18 Feb 2026 03:23:35 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v2]
In-Reply-To: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
Message-ID: <v1KhOmtMgOKhXJODGZa3nCoFlQnIX74-PXQvPyLhAM4=.f1267655-a91c-44e0-a7f6-57a5d306e293@github.com>

> `JProgressBar` is not printed if JDK 1.1 printing API is used.
> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
> `g2.setStroke(new BasicStroke(...))`
> 
> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Optimize
 - Optimize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29752/files
  - new: https://git.openjdk.org/jdk/pull/29752/files/bf8e0ffa..8950b529

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

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

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

From serb at openjdk.org  Wed Feb 18 05:03:11 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Feb 2026 05:03:11 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <K75Pg0Lyv31mB5FPB0Hpcp02xQNHUbOkyCpvkXEHqPo=.d1185305-2abe-46b4-bfaf-bced6040505d@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
 <K75Pg0Lyv31mB5FPB0Hpcp02xQNHUbOkyCpvkXEHqPo=.d1185305-2abe-46b4-bfaf-bced6040505d@github.com>
Message-ID: <kjF3G4TITurBCso3w2_0TlXHTZPEQz-r8IPAEEt5qnc=.d41ee304-63a7-4b19-accd-86e80e0a7a50@github.com>

On Tue, 17 Feb 2026 02:00:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I believe it is honoring that too. It will check and requestFocus to `selectInitialValue(op)` initialValue and then fallback to `initialFocusComponent` if it is not set..

The check for hasCustomComponents bypasses the use of initialFocusComponent, so we need to update the specification one way or another. we need to [decide](https://bugs.openjdk.org/browse/JDK-6741930?focusedId=12228349&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12228349) what behavior is correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3918652268

From serb at openjdk.org  Wed Feb 18 05:10:16 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Feb 2026 05:10:16 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v4]
In-Reply-To: <5StOPdQH7yYKKBeqyzMYzpiAhys6tOURG6jQc8-ViUA=.fc69b8a4-0f4c-4d91-b809-3dc8a5c5408d@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <5StOPdQH7yYKKBeqyzMYzpiAhys6tOURG6jQc8-ViUA=.fc69b8a4-0f4c-4d91-b809-3dc8a5c5408d@github.com>
Message-ID: <yL-n8nf3ZFwKt1_MTkl2hX_pRZ-Lr2r4kXaRHjQnROI=.85ab27b5-ac65-4518-a537-bf11f2254af4@github.com>

On Tue, 17 Feb 2026 22:39:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
>> A new egression test for each of the constructor and getter/setter cases is supplied.
>> 
>> No existing regression tests fail with this change, and standard demos work.
>> 
>> Problems caused by these changes are most likely to occur if the client has a bug such that 
>> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
>> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
>> 
>> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
>> 
>> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377568

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 167:

> 165:         }
> 166:         if (size < 0 || (size + offset) > dataArray.length) {
> 167:             throw new IllegalArgumentException("Bad size/offset. Size = " + size +

how it is supposed to work if the size is zero and the dataArray is empty? is it a valid config?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2820378530

From psadhukhan at openjdk.org  Wed Feb 18 05:13:13 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 18 Feb 2026 05:13:13 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <kjF3G4TITurBCso3w2_0TlXHTZPEQz-r8IPAEEt5qnc=.d41ee304-63a7-4b19-accd-86e80e0a7a50@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
 <K75Pg0Lyv31mB5FPB0Hpcp02xQNHUbOkyCpvkXEHqPo=.d1185305-2abe-46b4-bfaf-bced6040505d@github.com>
 <kjF3G4TITurBCso3w2_0TlXHTZPEQz-r8IPAEEt5qnc=.d41ee304-63a7-4b19-accd-86e80e0a7a50@github.com>
Message-ID: <ThGBeR0FqUO2tgwFgT8XALTuNDbWh0xr2lJYwCuHYyk=.92588da1-68dd-4e4a-8bae-621c3740c211@github.com>

On Wed, 18 Feb 2026 05:00:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I believe it is honoring that too. It will check and requestFocus to `selectInitialValue(op)` initialValue and then fallback to `initialFocusComponent` if it is not set..
> 
> The check for hasCustomComponents bypasses the use of initialFocusComponent, so we need to update the specification one way or another. we need to [decide](https://bugs.openjdk.org/browse/JDK-6741930?focusedId=12228349&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12228349) what behavior is correct.

initialFocusComponent is still used inside hasCustomComponents  check too but priority is given to passed op argument first otherwise there's no need to pass the argument and we can as well remove the parameter..

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3918707901

From serb at openjdk.org  Wed Feb 18 05:13:11 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Feb 2026 05:13:11 GMT
Subject: RFR: 8377938: VoiceOver Uses Mouse to Activate JButtons in German
In-Reply-To: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
References: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
Message-ID: <S-9z1XoVJn2M9KgX474b32TVnSN4QIFjyLexZo3C7H4=.9705ea13-1081-4aab-910a-3935fd38dd5b@github.com>

On Sat, 14 Feb 2026 23:47:10 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> Previously:
> The action description would be localized text. So in German's case `getAccessibleActionDescription(0)` would return `Klicken`. As that String is passed upwards towards VoiceOver, we're counting on VoiceOver's code interpreting it correctly.
> 
> With this PR:
> We always return "click" (using the AccessibleAction.CLICK constant). VoiceOver knows how to interpret an unlocalized "click".
> 
> ## Context
> 
> I looked up references to other AccessibleAction constants:
> 
> - AccessibleAction.TOGGLE_EXPAND is referenced in JTree.java's `getAccessibleActionDescription` method.
> - AccessibleAction.INCREMENT and AccessibleAction.DECREMENT are referenced in JSlider's and JSpinner's `getAccessibleActionDescription` method.
> - AccessibleAction.CLICK and AccessibleAction.TOGGLE_POPUP are NOT currently referenced (prior to this PR)
> 
> The javadoc for `getAccessibleActionDescription` simply describes the return value as "a String description of the action". It makes no comment on whether it should be localized or not.
> 
> JList.java is similar to AbstractButton:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("AbstractButton.clickText");
>     } else {
>         return null;
>     }
> }
> 
> 
> JComboBox.java includes:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("ComboBox.togglePopupText");
>     }
>     else {
>         return null;
>     }
> }
> 
> 
> I'd argue that we need to be consistent: either JTree/JSlider/JSpinner should be modified to return a localized action description, OR AbstractButton/JList/JComboBox should be modified to return the unlocalized constant.
> 
> My preference is to modify AbstractButton and JList (as shown in this PR). (And I'd recommend addressing JComboBox in a separate PR.)
> 
> (Also, I really like JTextComponent.java's implementation that combined Swing's ActionMap with AccessibleActions:
> 
> public String getAccessibleActionDescription(int i) {
>     Action [] actions = JTextComponent.this.getActions();
>     if (i < 0 || i >= actions.length) {
>         return null;
>     }
>     return (String)actions[i].getValue(Action.NAME);
> }
> 
> ... but that's straying pretty far from the original ticket.)
> 
> ## Non-Swing Context
> 
> I also searched for `getAccessibleActionDescription` in general.
> 
> In Button.java and MenuItem.java we have:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         // [[[PENDING:  WDW -- need to provide a localized string]]]
>         retur...

Does this change affect JAWS on windows as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/29727#issuecomment-3918711297

From prr at openjdk.org  Wed Feb 18 05:42:09 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 05:42:09 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v4]
In-Reply-To: <yL-n8nf3ZFwKt1_MTkl2hX_pRZ-Lr2r4kXaRHjQnROI=.85ab27b5-ac65-4518-a537-bf11f2254af4@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <5StOPdQH7yYKKBeqyzMYzpiAhys6tOURG6jQc8-ViUA=.fc69b8a4-0f4c-4d91-b809-3dc8a5c5408d@github.com>
 <yL-n8nf3ZFwKt1_MTkl2hX_pRZ-Lr2r4kXaRHjQnROI=.85ab27b5-ac65-4518-a537-bf11f2254af4@github.com>
Message-ID: <KZrx4jQsdwwm1pf13ppkjVd0A-7a6LO8N0R12ZwWcxA=.71d7bf45-11fb-40dc-bcf4-7d97f3257286@github.com>

On Wed, 18 Feb 2026 05:07:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377568
>
> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 167:
> 
>> 165:         }
>> 166:         if (size < 0 || (size + offset) > dataArray.length) {
>> 167:             throw new IllegalArgumentException("Bad size/offset. Size = " + size +
> 
> how it is supposed to work if the size is zero and the dataArray is empty? is it a valid config?

Do you mean the equivalent of new DataBufferByte(0) ?
You get  a valid DataBuffer but there isn't a normal use for it.,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2820451888

From prr at openjdk.org  Wed Feb 18 05:47:20 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 05:47:20 GMT
Subject: Integrated: 8376992: Remove AppContext from SystemTray implementation
In-Reply-To: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
References: <RSkXXy3CK3zHgRC-8kyrhDzJ4Org5_1Zs5ocKRV5KiA=.71d29fa2-de5a-46d6-82d4-0067e8067e00@github.com>
Message-ID: <6W0KexF-Hp6IzQFDAhCUeSmtxv-DlX-D6hXj_uldsyk=.6c9f3230-05d2-474a-98c7-f98930853895@github.com>

On Mon, 2 Feb 2026 20:07:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from java/awt/SystemTray

This pull request has now been integrated.

Changeset: bfac97c5
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfac97c5c14b188dda662d1f9591bdc22034161c
Stats:     40 lines in 3 files changed: 10 ins; 21 del; 9 mod

8376992: Remove AppContext from SystemTray implementation

Reviewed-by: serb, azvegint

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

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

From psadhukhan at openjdk.org  Wed Feb 18 07:17:21 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 18 Feb 2026 07:17:21 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <5Nr7jWXEo5A_t1rIku6YmKWrg08unNsSUqmSqYlQSFA=.e8814758-cba1-4ca3-b40e-bfafcb6b704a@github.com>

On Mon, 16 Feb 2026 01:30:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

Metal and Nimbus are platform independent so they can do their own things but Windows L&F need to do similar to what native application does, if not in pixel-perfect way, but atleast in essence, and as mentioned in JBS and seen in windows app, normal menu item icon is aligned to left edge as seen below

<img width="387" height="179" alt="image" src="https://github.com/user-attachments/assets/574fe54e-4328-463e-a6df-ef337f7f8cfb" />

and
<img width="331" height="449" alt="image" src="https://github.com/user-attachments/assets/606d15ae-294a-4ce1-9ae0-a962564f21d4" />

I couldn't find any native app view that will have radiobutton, checkmark and normal menuitem along with imageicon as is tested in `test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java` but I think it will behave in same way as it is doing in current PR
This is the closest I could find with checkmark and menuitem icon but it does not have image icon along with checkmark but as we can see menuitem icon is left+vertical aligned with checkmark (as we have as seen in https://github.com/openjdk/jdk/pull/29730#issuecomment-3913870880)
<img width="270" height="393" alt="image" src="https://github.com/user-attachments/assets/49784a32-736e-4189-a0ad-dae0709b726b" />

However, if one feels the layouting is wrong and needs to be changed, one can also propose own PR but I think it is fine from my perspective as it is now..

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3919123593

From serb at openjdk.org  Wed Feb 18 07:35:10 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Feb 2026 07:35:10 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v4]
In-Reply-To: <KZrx4jQsdwwm1pf13ppkjVd0A-7a6LO8N0R12ZwWcxA=.71d7bf45-11fb-40dc-bcf4-7d97f3257286@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <5StOPdQH7yYKKBeqyzMYzpiAhys6tOURG6jQc8-ViUA=.fc69b8a4-0f4c-4d91-b809-3dc8a5c5408d@github.com>
 <yL-n8nf3ZFwKt1_MTkl2hX_pRZ-Lr2r4kXaRHjQnROI=.85ab27b5-ac65-4518-a537-bf11f2254af4@github.com>
 <KZrx4jQsdwwm1pf13ppkjVd0A-7a6LO8N0R12ZwWcxA=.71d7bf45-11fb-40dc-bcf4-7d97f3257286@github.com>
Message-ID: <ZYIulohWyYm3ckUCA0GESHRa5YCAcfifOO7APnE2QM4=.a1ac7a63-f114-4bb5-8e9b-0b3b025bd6ba@github.com>

On Wed, 18 Feb 2026 05:39:47 GMT, Phil Race <prr at openjdk.org> wrote:

> You get a valid DataBuffer but there isn't a normal use for it.,

Yes, calling any methods on it will cause an exception, right? In that case, we should probably reject it? Or are there cases where an empty data buffer could actually be useful?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2820781114

From serb at openjdk.org  Wed Feb 18 07:42:09 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Feb 2026 07:42:09 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <ThGBeR0FqUO2tgwFgT8XALTuNDbWh0xr2lJYwCuHYyk=.92588da1-68dd-4e4a-8bae-621c3740c211@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
 <K75Pg0Lyv31mB5FPB0Hpcp02xQNHUbOkyCpvkXEHqPo=.d1185305-2abe-46b4-bfaf-bced6040505d@github.com>
 <kjF3G4TITurBCso3w2_0TlXHTZPEQz-r8IPAEEt5qnc=.d41ee304-63a7-4b19-accd-86e80e0a7a50@github.com>
 <ThGBeR0FqUO2tgwFgT8XALTuNDbWh0xr2lJYwCuHYyk=.92588da1-68dd-4e4a-8bae-621c3740c211@github.com>
Message-ID: <qqINp_5SayUpaJBwzPfctUw97K6eXxUcpFdbU6fnww8=.c7c52b2b-f61f-44e7-823e-edbccdfa4106@github.com>

On Wed, 18 Feb 2026 05:10:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> initialFocusComponent is still used inside hasCustomComponents check too but priority is given to passed op argument first otherwise there's no need to pass the argument and we can as well remove the parameter..

That?s the problem: the BasicOptionPaneUI spec says nothing about that parameter (unlike the parent class), and the implementation ignores it, instead checking the inputComponent and then the initialFocusComponent.

So the question is: how should the parameter passed to that method be handled, and what priority should it have compared to inputComponent and initialFocusComponent?

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3919206719

From dtabata at openjdk.org  Wed Feb 18 07:45:10 2026
From: dtabata at openjdk.org (Daishi Tabata)
Date: Wed, 18 Feb 2026 07:45:10 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <MxfF93ePdTuseggPzVvB0aXCj_F867LUdSLcDO8K7XY=.aaa07087-d226-4207-b5e7-fbf416445a0e@github.com>

On Mon, 16 Feb 2026 01:30:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

I will record my comment from yesterday as a review comment.
https://github.com/openjdk/jdk/pull/29730#issuecomment-3913870880

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

PR Review: https://git.openjdk.org/jdk/pull/29730#pullrequestreview-3818256448

From psadhukhan at openjdk.org  Wed Feb 18 07:50:09 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 18 Feb 2026 07:50:09 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
Message-ID: <EVYg-KsdTwAhuhj6xGYs1Qg7V3zD6qRYnlDZ0bEMlCU=.3bd2d97a-a333-4aa7-9283-80750f79abdd@github.com>

On Mon, 16 Feb 2026 10:43:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The FocusTraversalPolicy of a JOptionPane (JDialog) "reports" via `FocusTraversalPolicy.getInitialComponent`/`FocusTraversalPolicy.getFirstComponnent` that the focusable component passed to a JOptionPane, should get the initial focus. This however doesn't always happen, as the text field's FocusListener methods focusGained and focusLost are not invoked.
> Fix is made to honor the first focusable component of custom component (if present) and set the focus accordingly..
> This will cause the component's focusGained/focusLost method to get called.
> CI testing is ok..

So, how can we decide? we can either close this as "Wont Fix" or fix as per this PR as it is not causing any regression

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3919234426

From dtabata at openjdk.org  Wed Feb 18 08:27:49 2026
From: dtabata at openjdk.org (Daishi Tabata)
Date: Wed, 18 Feb 2026 08:27:49 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <5Nr7jWXEo5A_t1rIku6YmKWrg08unNsSUqmSqYlQSFA=.e8814758-cba1-4ca3-b40e-bfafcb6b704a@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <5Nr7jWXEo5A_t1rIku6YmKWrg08unNsSUqmSqYlQSFA=.e8814758-cba1-4ca3-b40e-bfafcb6b704a@github.com>
Message-ID: <DBPHI9eLNVza-GgJp4PSRaYKku6rtMaByU7WQ-LRYtg=.7b82b4a8-0685-40d9-b132-ab8f6795740a@github.com>

On Wed, 18 Feb 2026 07:15:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I couldn't find any native app view that will have radiobutton, checkmark and normal menuitem along with imageicon as is tested in test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java

There?s no normal menu item that has an ImageIcon, but I did find a native app where a radio button and an ImageIcon are displayed side by side. The screenshot is from the ?View? menu in Windows 11 Explorer.

<img width="169" height="305" alt="example" src="https://github.com/user-attachments/assets/5a8983a2-160e-484f-ba8a-5cf242e8fb6e" />

The last ?Show? opens a submenu, so it might be treated differently from a normal menu item, but the menu text is left-aligned.

I still think it?s not good if the ImageIcon and text of each menu item end up misaligned.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3919381079

From jdv at openjdk.org  Wed Feb 18 09:29:45 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 18 Feb 2026 09:29:45 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v3]
In-Reply-To: <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
Message-ID: <Khxns4tFJ9oJ8EQCnvFBljFV6a_lHzWaJr1cqdeUCIk=.bd54aa05-1715-4ae4-807b-170814124bc9@github.com>

On Thu, 22 Jan 2026 17:57:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
>> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
>> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
>> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
>> 
>> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
>> I did that and ran all our existing automated tests on our CI systems.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8373626

Looks like we need to delete or update code at some places.

src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16nw.c line 922:

> 920:           off += kw;
> 921: 
> 922:           p2 = sp[0]; p3 = sp[chan1]; p4 = sp[chan2];

Do we need to delete these lines? Since the values are getting copied individually for each conditions?

src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8nw.c line 923:

> 921:           off += kw;
> 922: 
> 923:           sp += (kw - 1)*chan1;

Do we need to move this change in address of `sp` to each conditions?

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

PR Review: https://git.openjdk.org/jdk/pull/29257#pullrequestreview-3818618306
PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2821164498
PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2821233636

From jdv at openjdk.org  Wed Feb 18 09:34:39 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 18 Feb 2026 09:34:39 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v3]
In-Reply-To: <lcutAFzitKhkZsf9RCVk30q5d8yEj7w3tJrUwzKXhwU=.2e714ec3-66b2-4247-a3b7-bfcafdb6c721@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
 <lcutAFzitKhkZsf9RCVk30q5d8yEj7w3tJrUwzKXhwU=.2e714ec3-66b2-4247-a3b7-bfcafdb6c721@github.com>
Message-ID: <qIfA1Tb-MmxbHl34dvkGNrR3mSTrWbgVZXBFN0psvJk=.fdcb2f9b-70b1-47cb-977f-c7e45bcfddfd@github.com>

On Sat, 7 Feb 2026 02:32:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8373626
>
> src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16nw.c line 922:
> 
>> 920:           off += kw;
>> 921: 
>> 922:           sp += (kw - 1)*chan1;
> 
> Just to check: before the patch, the code read data from sp to set pXX, then increased sp. After the patch, the order is different. Is that correct?

I also have same query.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2821284638

From jdv at openjdk.org  Wed Feb 18 10:24:34 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 18 Feb 2026 10:24:34 GMT
Subject: RFR: 8372651: Remove unreachable code in
 sun.awt.geom.AreaOp::calculate
In-Reply-To: <okgf1Zxa-wzLYg3WlbjoILhXQQkrNM8Vw3y3aYnTC-4=.f44508ca-2760-4da0-8be8-d16c56c2708f@github.com>
References: <okgf1Zxa-wzLYg3WlbjoILhXQQkrNM8Vw3y3aYnTC-4=.f44508ca-2760-4da0-8be8-d16c56c2708f@github.com>
Message-ID: <ZvcYEBEy7c2XO7gNR-Zp-fsvDmX6TUX00cI7bAE5QuQ=.612c1efe-34ee-4c98-8bd1-b71d577ee55b@github.com>

On Thu, 27 Nov 2025 08:58:50 GMT, wb-zjp846396 <duke at openjdk.org> wrote:

> JBS: https://bugs.openjdk.org/browse/JDK-8372651
> 
> Summary:
> - Fix a constant-condition `if` statement in `AreaOp.java` line 160.
> - Clean up dead code and clarify control flow.
> 
> Testing:
> - No functional modification involved.

We have these debug logs with `if (false)` at multiple places in same file.
These debug logs are easy way for us to track the curves, subcurves, edges when we are working with complex paths.

It will be useful if we maintain them. We can add a debug flag and print these logs only when it is enabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/28528#issuecomment-3919949014

From prr at openjdk.org  Wed Feb 18 18:50:23 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 18:50:23 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v4]
In-Reply-To: <ZYIulohWyYm3ckUCA0GESHRa5YCAcfifOO7APnE2QM4=.a1ac7a63-f114-4bb5-8e9b-0b3b025bd6ba@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <5StOPdQH7yYKKBeqyzMYzpiAhys6tOURG6jQc8-ViUA=.fc69b8a4-0f4c-4d91-b809-3dc8a5c5408d@github.com>
 <yL-n8nf3ZFwKt1_MTkl2hX_pRZ-Lr2r4kXaRHjQnROI=.85ab27b5-ac65-4518-a537-bf11f2254af4@github.com>
 <KZrx4jQsdwwm1pf13ppkjVd0A-7a6LO8N0R12ZwWcxA=.71d7bf45-11fb-40dc-bcf4-7d97f3257286@github.com>
 <ZYIulohWyYm3ckUCA0GESHRa5YCAcfifOO7APnE2QM4=.a1ac7a63-f114-4bb5-8e9b-0b3b025bd6ba@github.com>
Message-ID: <7pTcxScQTrrk7DUOwa29-XVrRRoWud6UyTDyvNePQpc=.803e79a2-fb17-406c-abb5-643695e40ab3@github.com>

On Wed, 18 Feb 2026 07:32:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Do you mean the equivalent of new DataBufferByte(0) ?
>> You get  a valid DataBuffer but there isn't a normal use for it.,
>
>> You get a valid DataBuffer but there isn't a normal use for it.,
> 
> Yes, calling any methods on it will cause an exception, right? In that case, we should probably reject it? Or are there cases where an empty data buffer could actually be useful?

I can't think of any use for it once it is created.

Because everything that uses a DataBuffer (in the imaging APIs) like Raster and BufferedImage require w/h of at least 1. So I'm not sure how a zero-length DataBuffer could ever be used once created.
And getElem() / setElem() can never be used either. 
The only use  would be in tests that see if you can create it  .. not a particularly practical real world use.

But because the spec. didn't disallow it, I didn't want to do anything about it. I tried to keep this change as much as possible to enforcing what the existing spec says. Already a tiny bit worried about breaking some weird code somewhere that ignores the spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2823894016

From prr at openjdk.org  Wed Feb 18 19:29:58 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 19:29:58 GMT
Subject: RFR: 8378192: Remove AppContext from SwingUtilities2
Message-ID: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>

Remove AppContext from SwingUtilities2

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

Commit messages:
 - 8378192

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

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

From prr at openjdk.org  Wed Feb 18 19:29:59 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 19:29:59 GMT
Subject: RFR: 8378192: Remove AppContext from SwingUtilities2
In-Reply-To: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
References: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
Message-ID: <92I1zetccQHxEflPHo5azaz0k-GAQ3sAnE-E4dTuOQA=.3b194962-24e6-400c-abfe-8e350299cc5e@github.com>

On Wed, 18 Feb 2026 19:19:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SwingUtilities2

src/java.desktop/share/classes/sun/swing/SwingUtilities2.java line 1243:

> 1241:     }
> 1242: 
> 1243:     private static final Map<Object, FontRenderContext> cache = new HashMap<>();

This cache looks like it could grow without bounds but
(1) In fact the transforms are just the set of default transforms for graphics configs, so it is very limited
(2) Nothing changing here anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29798#discussion_r2824036612

From prr at openjdk.org  Wed Feb 18 19:35:01 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 19:35:01 GMT
Subject: RFR: 8378193: Remove AppContext from JinternalFrame
Message-ID: <0piE6_vP3udG1F1qMLU3hH8JE3kSxiU-mlpp9zl0MBA=.77c6a9de-fa47-410e-91b7-2384d6669017@github.com>

We don't need a per-AppContext JInternalFrame focusListener any more.

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

Commit messages:
 - 8378193

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

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

From prr at openjdk.org  Wed Feb 18 20:07:14 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 20:07:14 GMT
Subject: RFR: 8378197: Remove AppContext from
 sun/swing/plaf/DesktopProperty.java
Message-ID: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>

A straightforward removal of a per-AppContext flag which can now be static

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

Commit messages:
 - 8378197

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

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

From prr at openjdk.org  Wed Feb 18 20:11:58 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 20:11:58 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v2]
In-Reply-To: <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
Message-ID: <Aq9cOyRsFnhC19-30qTDvGjPvvYl6I4U7XnAM1mQkPI=.b43e8b49-da50-4e46-8adc-4b06a9068fae@github.com>

On Mon, 16 Feb 2026 06:54:08 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

Did you test this yourself using jtreg locally on Windows and Linux ?

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

PR Comment: https://git.openjdk.org/jdk/pull/29733#issuecomment-3922935239

From prr at openjdk.org  Wed Feb 18 22:58:23 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 22:58:23 GMT
Subject: RFR: 8378202: Remove AppContext from XAWT classes
Message-ID: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>

Remove AppContext from XAWT.

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

Commit messages:
 - 8378202
 - 8378202

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

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

From prr at openjdk.org  Wed Feb 18 23:09:12 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 23:09:12 GMT
Subject: RFR: 8378203: Remove AppContext from jdk.unsupported.desktop
Message-ID: <xrjfUalJ1r4WdJRx2QGNg720qdXacw8EGX8E-reC_PU=.e6707d59-143d-49e6-b347-2e03eb74a337@github.com>

Remove AppContext from jdk.unsupported.desktop module

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

Commit messages:
 - 8378203

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

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

From prr at openjdk.org  Wed Feb 18 23:30:38 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 23:30:38 GMT
Subject: RFR: 8378204: Remove AppContext from two Swing UI classes
Message-ID: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>

A couple of missed cases of removing AppContext from Swing UI classes and one dead import

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

Commit messages:
 - 8378204

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

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

From prr at openjdk.org  Wed Feb 18 23:30:39 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 23:30:39 GMT
Subject: RFR: 8378204: Remove AppContext from two Swing UI classes
In-Reply-To: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
References: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
Message-ID: <vlH1ovo138vHkY_HxZKmsPS3orpAIyo-jPE-9eKJpaU=.0dfec9fb-785c-41f5-b9e5-6d3c5b4ab10d@github.com>

On Wed, 18 Feb 2026 23:06:18 GMT, Phil Race <prr at openjdk.org> wrote:

> A couple of missed cases of removing AppContext from Swing UI classes and one dead import

src/java.desktop/share/classes/sun/awt/im/InputMethodManager.java line 38:

> 36: import java.awt.MenuItem;
> 37: import java.awt.Toolkit;
> 38: import sun.awt.AppContext;

This is (I admit) unrelated. But since I spotted it I've been looking for a PR where it might fit and haven't yet found one, so I'm including it here as It really does not merit the overhead of a PR for itself !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29806#discussion_r2824876059

From prr at openjdk.org  Wed Feb 18 23:34:50 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Feb 2026 23:34:50 GMT
Subject: RFR: 8378205: Remove AppContext from Swing MenuComponent
Message-ID: <nT5VY9x1BoJJXs-vko9-Y-iAWGmmJEaPSIkiZK7AsHE=.419bc238-6250-40c2-b55a-99e06b213fa8@github.com>

Remove AppContext from Swing MenuComponent

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

Commit messages:
 - 8378205

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

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

From serb at openjdk.org  Thu Feb 19 02:09:50 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 19 Feb 2026 02:09:50 GMT
Subject: RFR: 8378153: Robot.getPixelColor() may return stale pixels due to
 missing Toolkit.sync()
Message-ID: <fzKmq08t4pxg-FdtZcN5EdKUU7IfH6g76Q0yVp43XzU=.1dd383ef-f88f-4786-944b-1be9d3ace77d@github.com>

Robot.getPixelColor() does not call Toolkit.getDefaultToolkit().sync() before reading the pixel, unlike Robot.createScreenCapture() which has had this call since [JDK-6725214](https://bugs.openjdk.org/browse/JDK-6725214).

When a hardware-accelerated pipeline (OGL, D3D, Metal) is active, rendering may be buffered and not yet flushed to the screen when getPixelColor() reads the pixel. This causes it to return stale values typically the window background color instead of the rendered content.

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

Commit messages:
 - 8378153: Robot.getPixelColor() may return stale pixels due to missing Toolkit.sync()

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

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

From prr at openjdk.org  Thu Feb 19 02:57:42 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 02:57:42 GMT
Subject: RFR: 8378153: Robot.getPixelColor() may return stale pixels due to
 missing Toolkit.sync()
In-Reply-To: <fzKmq08t4pxg-FdtZcN5EdKUU7IfH6g76Q0yVp43XzU=.1dd383ef-f88f-4786-944b-1be9d3ace77d@github.com>
References: <fzKmq08t4pxg-FdtZcN5EdKUU7IfH6g76Q0yVp43XzU=.1dd383ef-f88f-4786-944b-1be9d3ace77d@github.com>
Message-ID: <81nYYW0mHF0SP_815kGXDjpfpKZiiFsz837z-ihB43c=.d1215744-c6b7-4d5e-abc3-a1e792791849@github.com>

On Wed, 18 Feb 2026 08:24:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Robot.getPixelColor() does not call Toolkit.getDefaultToolkit().sync() before reading the pixel, unlike Robot.createScreenCapture() which has had this call since [JDK-6725214](https://bugs.openjdk.org/browse/JDK-6725214).
> 
> When a hardware-accelerated pipeline (OGL, D3D, Metal) is active, rendering may be buffered and not yet flushed to the screen when getPixelColor() reads the pixel. This causes it to return stale values typically the window background color instead of the rendered content.

I don't know how often this is a problem but it seems like a safe and good change.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29780#pullrequestreview-3823242186

From psadhukhan at openjdk.org  Thu Feb 19 02:59:09 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Feb 2026 02:59:09 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F
Message-ID: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>

If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon

MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
`MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.

Without fix
<img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />

With fix
<img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />

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

Commit messages:
 - 8078744: Right half of system menu icon on title bar does not activate when clicked in Metal L&F

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

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

From psadhukhan at openjdk.org  Thu Feb 19 03:27:03 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Feb 2026 03:27:03 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect [v2]
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <tU43Td72GCjDMYaZvutje-maTFW5Y3dqBK2ngq2VwF8=.c8be7d2c-927b-44c9-be22-a149a4ba1ed0@github.com>

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

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

  Text alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29730/files
  - new: https://git.openjdk.org/jdk/pull/29730/files/fd677cb9..910b1db0

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

  Stats: 138 lines in 3 files changed: 6 ins; 126 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/29730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29730/head:pull/29730

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

From psadhukhan at openjdk.org  Thu Feb 19 03:27:04 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Feb 2026 03:27:04 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <an6b7vEfwE9TzdtmFFoX8-FG5vXyR4QnukgwC8TgZRo=.534b5101-5db3-4fa4-80ff-f595b2fc733f@github.com>

On Mon, 16 Feb 2026 01:30:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

Reverted the text alignment to have vertical alignment as before, but kept the JMenuItem imageicon alignment as it seems to be at par with native app for normal non-radio/non-check JMenuItem (as mentioned here https://github.com/openjdk/jdk/pull/29730#issuecomment-3919123593) and this JBS is about that only..

<img width="415" height="387" alt="image" src="https://github.com/user-attachments/assets/4b5f11d8-cade-4f07-8cb3-cc188a994a73" />

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3924464416

From psadhukhan at openjdk.org  Thu Feb 19 03:34:55 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Feb 2026 03:34:55 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect [v3]
In-Reply-To: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
Message-ID: <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>

> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
> 
> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
> 
> Before fix
> 
> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
> 
> 
> After fix
> 
> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />

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

  Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29730/files
  - new: https://git.openjdk.org/jdk/pull/29730/files/910b1db0..7eab253c

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

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

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

From psadhukhan at openjdk.org  Thu Feb 19 03:51:37 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Feb 2026 03:51:37 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v3]
In-Reply-To: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
Message-ID: <HRobHdhbpaCzxUYEXer53Qq2tgaejqvnZHgv2CfQMZg=.1ec9e358-a0c9-44d8-acab-c475dda68da6@github.com>

> `JProgressBar` is not printed if JDK 1.1 printing API is used.
> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
> `g2.setStroke(new BasicStroke(...))`
> 
> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unused imports
 - Remove unused imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29752/files
  - new: https://git.openjdk.org/jdk/pull/29752/files/8950b529..df542555

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

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

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

From psadhukhan at openjdk.org  Thu Feb 19 08:18:47 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 19 Feb 2026 08:18:47 GMT
Subject: RFR: 8378192: Remove AppContext from SwingUtilities2
In-Reply-To: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
References: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
Message-ID: <fAOCm6yVhzS_aBW3Fn8CNaqQc_gUrsr13410pdW0gyw=.349818ae-67c8-42b3-931d-aeb113274976@github.com>

On Wed, 18 Feb 2026 19:19:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SwingUtilities2

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29798#pullrequestreview-3824113865

From serb at openjdk.org  Thu Feb 19 09:37:32 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 19 Feb 2026 09:37:32 GMT
Subject: RFR: 8378204: Remove AppContext from two Swing UI classes
In-Reply-To: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
References: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
Message-ID: <X2P4mw8iF_WrYQ5i9xozrf5UreNnkzVxCus0VGX9zUw=.f2d62931-140b-4985-8c49-a248ab628a7c@github.com>

On Wed, 18 Feb 2026 23:06:18 GMT, Phil Race <prr at openjdk.org> wrote:

> A couple of missed cases of removing AppContext from Swing UI classes and one dead import

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29806#pullrequestreview-3824469234

From kizune at openjdk.org  Thu Feb 19 09:57:42 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 19 Feb 2026 09:57:42 GMT
Subject: RFR: 8378205: Remove AppContext from Swing MenuComponent
In-Reply-To: <nT5VY9x1BoJJXs-vko9-Y-iAWGmmJEaPSIkiZK7AsHE=.419bc238-6250-40c2-b55a-99e06b213fa8@github.com>
References: <nT5VY9x1BoJJXs-vko9-Y-iAWGmmJEaPSIkiZK7AsHE=.419bc238-6250-40c2-b55a-99e06b213fa8@github.com>
Message-ID: <4AyUnveDJ_qCvRC4Fj38-le6mY1PtFaC3oTqXxbqdGk=.1be8cd89-ab20-4e94-9337-1dd347fa6f00@github.com>

On Wed, 18 Feb 2026 23:12:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from Swing MenuComponent

Looks good

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29807#pullrequestreview-3824597288

From kizune at openjdk.org  Thu Feb 19 09:58:48 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 19 Feb 2026 09:58:48 GMT
Subject: RFR: 8378204: Remove AppContext from two Swing UI classes
In-Reply-To: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
References: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
Message-ID: <K5KF4XA6ccrF1Hz_yL5PnUiUsiUle9nFBZbpz1sf-hE=.05451414-1c29-4ff7-9bdd-d39a668a2efd@github.com>

On Wed, 18 Feb 2026 23:06:18 GMT, Phil Race <prr at openjdk.org> wrote:

> A couple of missed cases of removing AppContext from Swing UI classes and one dead import

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29806#pullrequestreview-3824603289

From kizune at openjdk.org  Thu Feb 19 10:00:46 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 19 Feb 2026 10:00:46 GMT
Subject: RFR: 8378192: Remove AppContext from SwingUtilities2
In-Reply-To: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
References: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
Message-ID: <lqt6bnH_bRl4BxRriXmDjCwebrXCh8E3PZoyR2QLAuc=.574f2627-4ef9-4117-b6c4-e899d3e531f4@github.com>

On Wed, 18 Feb 2026 19:19:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SwingUtilities2

Looks reasonable.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29798#pullrequestreview-3824619148

From kizune at openjdk.org  Thu Feb 19 10:09:53 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 19 Feb 2026 10:09:53 GMT
Subject: RFR: 8377938: VoiceOver Uses Mouse to Activate JButtons in German
In-Reply-To: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
References: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
Message-ID: <Li4CynAu2IkRu06ZShKjBX6aPF_U_5V2sjfFSaPEpwM=.83de2505-9d73-4c5d-af3a-1f512e72f2ee@github.com>

On Sat, 14 Feb 2026 23:47:10 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> Previously:
> The action description would be localized text. So in German's case `getAccessibleActionDescription(0)` would return `Klicken`. As that String is passed upwards towards VoiceOver, we're counting on VoiceOver's code interpreting it correctly.
> 
> With this PR:
> We always return "click" (using the AccessibleAction.CLICK constant). VoiceOver knows how to interpret an unlocalized "click".
> 
> ## Context
> 
> I looked up references to other AccessibleAction constants:
> 
> - AccessibleAction.TOGGLE_EXPAND is referenced in JTree.java's `getAccessibleActionDescription` method.
> - AccessibleAction.INCREMENT and AccessibleAction.DECREMENT are referenced in JSlider's and JSpinner's `getAccessibleActionDescription` method.
> - AccessibleAction.CLICK and AccessibleAction.TOGGLE_POPUP are NOT currently referenced (prior to this PR)
> 
> The javadoc for `getAccessibleActionDescription` simply describes the return value as "a String description of the action". It makes no comment on whether it should be localized or not.
> 
> JList.java is similar to AbstractButton:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("AbstractButton.clickText");
>     } else {
>         return null;
>     }
> }
> 
> 
> JComboBox.java includes:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("ComboBox.togglePopupText");
>     }
>     else {
>         return null;
>     }
> }
> 
> 
> I'd argue that we need to be consistent: either JTree/JSlider/JSpinner should be modified to return a localized action description, OR AbstractButton/JList/JComboBox should be modified to return the unlocalized constant.
> 
> My preference is to modify AbstractButton and JList (as shown in this PR). (And I'd recommend addressing JComboBox in a separate PR.)
> 
> (Also, I really like JTextComponent.java's implementation that combined Swing's ActionMap with AccessibleActions:
> 
> public String getAccessibleActionDescription(int i) {
>     Action [] actions = JTextComponent.this.getActions();
>     if (i < 0 || i >= actions.length) {
>         return null;
>     }
>     return (String)actions[i].getValue(Action.NAME);
> }
> 
> ... but that's straying pretty far from the original ticket.)
> 
> ## Non-Swing Context
> 
> I also searched for `getAccessibleActionDescription` in general.
> 
> In Button.java and MenuItem.java we have:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         // [[[PENDING:  WDW -- need to provide a localized string]]]
>         retur...

I really do not like this idea because a) It might affect other platforms and we have two other platforms to worry about - Windows with JAWS and NVDA that we support and Linux which we do not officially support but there are unofficial ports of accessbridge that allows Java applications to be accessible with Gnome based UI and while we do not support it we do not want to intentionally break it either; and b) It might not work correctly with other locales - we can not tell for sure until we test.

Bottom line - fixing platform specific issue in the shared code requires testing on all affected platforms and changing localization without testing it with at least 3-4 most commonly used locales is also questionable.

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

PR Comment: https://git.openjdk.org/jdk/pull/29727#issuecomment-3926136693

From dtabata at openjdk.org  Thu Feb 19 10:45:36 2026
From: dtabata at openjdk.org (Daishi Tabata)
Date: Thu, 19 Feb 2026 10:45:36 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect [v3]
In-Reply-To: <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>
Message-ID: <jLOcBckPjQq08M9ur0toRxWS_W4Gil_uUJpFu6xFtic=.ad7bc03f-b33e-41ce-984e-7ef20d4146f5@github.com>

On Thu, 19 Feb 2026 03:34:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
>> 
>> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
>> 
>> Before fix
>> 
>> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
>> 
>> 
>> After fix
>> 
>> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

The native app menu (where ImageIcon and check are on the same row), as described in https://github.com/openjdk/jdk/pull/29730#issuecomment-3919123593 looks like this:

<img width="213" height="214" alt="good" src="https://github.com/user-attachments/assets/32cc8f63-5c77-4831-ad7f-4b324af63429" />

This is rendered correctly (thanks to this fix).
However, we haven?t found a native app menu that corresponds to `test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java`, so I'm not sure the following claim holds:

> kept the JMenuItem imageicon alignment as it seems to be at par with native app for normal non-radio/non-check JMenuItem (as mentioned here #29730 (comment))

Also, in Nimbus and Metal, the square is left-aligned:

Numbus
<img width="271" height="217" alt="numbus" src="https://github.com/user-attachments/assets/4a5f7148-510e-4106-9533-f49cf5a83a25" />

Metal
<img width="241" height="218" alt="metal" src="https://github.com/user-attachments/assets/ddbfa109-fb8c-48ae-b12a-bd56e8c4d876" />

If the alignment in Windows LAF and Nimbus (or Metal) is required to be the same, then this fix is still not sufficient.
However, I don?t actually know whether they are required to match. Because of that, although it feels a bit unintuitive to me, I?m not sure what the correct behavior should be.

I?m sorry that I can only point this out without being able to provide a clear suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3926380644

From aivanov at openjdk.org  Thu Feb 19 15:46:13 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Feb 2026 15:46:13 GMT
Subject: RFR: 8377602: Create automated test for PageRange
In-Reply-To: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
Message-ID: <kzqR2or-6RjdwOqzyx4O_CEXcs-lwCvM0_srgz7Bfrk=.51c1b0e7-f9e8-4924-a84a-766c2c039862@github.com>

On Tue, 10 Feb 2026 20:45:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
> 
> With this PR, I'm contributing the test to OpenJDK.
> 
> Without the fix for JDK-8297191, the test fails with the following error messages:
> 
> <details>
> <summary>test log</summary>
> 
> 
> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
> 	at PageRangesAuto.main(PageRangesAuto.java:146)
> 
> </details>

Any volunteers to review?

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

PR Comment: https://git.openjdk.org/jdk/pull/29660#issuecomment-3928093630

From kizune at openjdk.org  Thu Feb 19 16:26:48 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 19 Feb 2026 16:26:48 GMT
Subject: RFR: 8378203: Remove AppContext from jdk.unsupported.desktop
In-Reply-To: <xrjfUalJ1r4WdJRx2QGNg720qdXacw8EGX8E-reC_PU=.e6707d59-143d-49e6-b347-2e03eb74a337@github.com>
References: <xrjfUalJ1r4WdJRx2QGNg720qdXacw8EGX8E-reC_PU=.e6707d59-143d-49e6-b347-2e03eb74a337@github.com>
Message-ID: <iOKkW3OjXZQk6f4jFPB1Bf4IJ8kW67btAVnnkILvG5Q=.5e1e12df-c27e-4b64-8fe4-562a8cdf0ccb@github.com>

On Wed, 18 Feb 2026 23:01:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from jdk.unsupported.desktop module

Looks good

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29805#pullrequestreview-3826959663

From kizune at openjdk.org  Thu Feb 19 16:28:02 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 19 Feb 2026 16:28:02 GMT
Subject: RFR: 8377745: VoiceOver Identifies Hyperlink as Text [v2]
In-Reply-To: <vikiKuDi1QPsG_ovP_YQJqWZ7c4x2EEhbZ8f0tes4oU=.5a9705ac-4fd3-4efb-94bd-b8740c947195@github.com>
References: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
 <vikiKuDi1QPsG_ovP_YQJqWZ7c4x2EEhbZ8f0tes4oU=.5a9705ac-4fd3-4efb-94bd-b8740c947195@github.com>
Message-ID: <W1Q-g6F7EZRsosswdy1CuS2xzIRQzHG1SYf4U3P__rI=.63736025-a7dc-46ef-96d1-85ecb485af83@github.com>

On Fri, 13 Feb 2026 22:15:31 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> ~~If we use `new AccessibleRole("AXLink") {}`, then VoiceOver reads this more like other native apps.~~
>> 
>> ~~There isn't a similar precedent in CAccessibility for creating custom AccessibleRoles, so I won't mind if this PR is declined. (But I don't know off the top of my head where else to inject code to get the desired result...)~~
>> 
>> This introduces a new LinkAccessibility.m file to help VoiceOver and Accessibility Inspector correctly identify AccessibleRole.HYPERLINK as "link"
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8377745: creating new LinkAccessibility
>    
>    This helps convert from AccessibleRole.HYPERLINK to the new LinkAccessibility.
>    
>    The new LinkAccessible still references `CommonTextAccessibility<NSAccessibilityStaticText>`.
>    
>    This (both the subject matter and the programming language) is outside of my area of expertise, but the unit test passes.
>    
>    This is based on this feedback:
>    https://github.com/openjdk/jdk/pull/29686#issuecomment-3899448303
>  - Revert "8377745: use custom "AXLink" AccessibleRole"
>    
>    This reverts commit d66355973918458352d15174a2cf21a177763c23.

Latest version looks reasonable.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29686#pullrequestreview-3826968658

From kizune at openjdk.org  Thu Feb 19 16:33:59 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 19 Feb 2026 16:33:59 GMT
Subject: RFR: 8378193: Remove AppContext from JinternalFrame
In-Reply-To: <0piE6_vP3udG1F1qMLU3hH8JE3kSxiU-mlpp9zl0MBA=.77c6a9de-fa47-410e-91b7-2384d6669017@github.com>
References: <0piE6_vP3udG1F1qMLU3hH8JE3kSxiU-mlpp9zl0MBA=.77c6a9de-fa47-410e-91b7-2384d6669017@github.com>
Message-ID: <aLPyjwQl10qEJHNJQc7dvVE8HlvzUtsGInyw_hG5gbE=.ad9478f4-2a4f-4ff3-bdb5-6b7f5a34738e@github.com>

On Wed, 18 Feb 2026 19:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

> We don't need a per-AppContext JInternalFrame focusListener any more.

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29799#pullrequestreview-3827009477

From jwood at openjdk.org  Thu Feb 19 17:27:26 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Thu, 19 Feb 2026 17:27:26 GMT
Subject: RFR: 8377938: VoiceOver Uses Mouse to Activate JButtons in German
In-Reply-To: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
References: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
Message-ID: <ClrsKTH2V0Vm6a1FBW2Qruzu8f0Sd-1Yp7AAbc3XMYY=.e40ccd5d-672c-4ae0-a91d-0225b135c1a5@github.com>

On Sat, 14 Feb 2026 23:47:10 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> Previously:
> The action description would be localized text. So in German's case `getAccessibleActionDescription(0)` would return `Klicken`. As that String is passed upwards towards VoiceOver, we're counting on VoiceOver's code interpreting it correctly.
> 
> With this PR:
> We always return "click" (using the AccessibleAction.CLICK constant). VoiceOver knows how to interpret an unlocalized "click".
> 
> ## Context
> 
> I looked up references to other AccessibleAction constants:
> 
> - AccessibleAction.TOGGLE_EXPAND is referenced in JTree.java's `getAccessibleActionDescription` method.
> - AccessibleAction.INCREMENT and AccessibleAction.DECREMENT are referenced in JSlider's and JSpinner's `getAccessibleActionDescription` method.
> - AccessibleAction.CLICK and AccessibleAction.TOGGLE_POPUP are NOT currently referenced (prior to this PR)
> 
> The javadoc for `getAccessibleActionDescription` simply describes the return value as "a String description of the action". It makes no comment on whether it should be localized or not.
> 
> JList.java is similar to AbstractButton:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("AbstractButton.clickText");
>     } else {
>         return null;
>     }
> }
> 
> 
> JComboBox.java includes:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("ComboBox.togglePopupText");
>     }
>     else {
>         return null;
>     }
> }
> 
> 
> I'd argue that we need to be consistent: either JTree/JSlider/JSpinner should be modified to return a localized action description, OR AbstractButton/JList/JComboBox should be modified to return the unlocalized constant.
> 
> My preference is to modify AbstractButton and JList (as shown in this PR). (And I'd recommend addressing JComboBox in a separate PR.)
> 
> (Also, I really like JTextComponent.java's implementation that combined Swing's ActionMap with AccessibleActions:
> 
> public String getAccessibleActionDescription(int i) {
>     Action [] actions = JTextComponent.this.getActions();
>     if (i < 0 || i >= actions.length) {
>         return null;
>     }
>     return (String)actions[i].getValue(Action.NAME);
> }
> 
> ... but that's straying pretty far from the original ticket.)
> 
> ## Non-Swing Context
> 
> I also searched for `getAccessibleActionDescription` in general.
> 
> In Button.java and MenuItem.java we have:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         // [[[PENDING:  WDW -- need to provide a localized string]]]
>         retur...

OK, thanks for the feedback. I was going to try to test Windows this weekend, but if this is DOA I can skip it.

More broadly:
A. Do you think the original ticket is a valid complaint that should remain open? (Or should it be closed as "won't fix"? or some other option?)

B. Do you agree with my assertion:
> we need to be consistent: either JTree/JSlider/JSpinner should be modified to return a localized action description, OR AbstractButton/JList/JComboBox should be modified to return the unlocalized constant.

This PR currently focuses on the second option. I could write up a new ticket/PR to explore the first option (localizing other action action descriptions)

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

PR Comment: https://git.openjdk.org/jdk/pull/29727#issuecomment-3928695623

From aron.rahman at parcit.de  Thu Feb 19 09:55:39 2026
From: aron.rahman at parcit.de (Aron Rahman)
Date: Thu, 19 Feb 2026 09:55:39 +0000
Subject: Issues similar to JDK-8359433
Message-ID: <FRSP281MB5667BBBD5B9922DF65956007ED6BA@FRSP281MB5667.DEUP281.PROD.OUTLOOK.COM>

Dear openJDK devs,

I contacted Sergey Bylokhov via LinkedIn in December because we are unable to migrate to JDK25 due to commit https://github.com/openjdk/jdk25u/commit/477da161e62040d77079196ea27d24b27de75b64. In this commit, internal Swing classes were declared as final.
We have (unfortunately) built derivation hierarchies of several affected classes on which our entire Swing UI is based. If we were to abandon the derivations, it would mean undesirable changes in the behavior of our GUIs. Maintaining the behavior would be very expensive/impossible. We are working step by step to replace our Swing UI with a modern UI, but this is likely to take longer than JDK21 support lasts.
Sergey Bylokhov recommended that I should send an email about ticket https://bugs.openjdk.org/browse/JDK-8359433 and contact this mailing list. He asked for a detailed description of which classes are being extended and why. Due to an urgent feature, the responsible devs were busy and my response took two months. I'm sorry for that. Here is the description:

Original class
What we've changed via derivation:
WindowsButtonUI

  *   veto listener for mouse clicks
  *   look & feel
WindowsCheckBoxUI

  *   look & feel for read-only
  *   drawing CellHint-function
  *
WindowsComboBoxUI

  *   look & feel for read-only
  *   read-only function
  *   change keyboard behavior
  *   small other changes in look & feel
WindowsRadioButtonUI

  *   look & feel
WindowsTextAreaUI

  *   look & feel for read-only
WindowsLabelUI

  *   look & feel
WindowsTreeUI

  *   changing DefaultCellRenderer
  *   look & feel for read-only function
  *   drawing lines, adapting width in tables, background color
ToolBarBorder

  *   look & feel
WindowsSliderUI

  *   changing slider's behaviour
WindowsTabbedPaneUI

  *   look & feel

I hope, this helps. When we implemented this years ago, we obviously should have found a better solution than overwriting internal classes. On the other hand, it may not be very important to you that overwriting internal classes has now been prohibited for legacy Swing UI.
We would be very grateful to you if you could undo the commit or parts of it so that we can continue to use the overwrites with JDK25 or higher. If this is not possible, we are also interested in other solution ideas. Otherwise, we will unfortunately have to go to the trouble of replacing this historical code at some point.

Best regards,
Aron from Cologne, Germany, working for parcIT



Aron Rahman
Team Lead Software Development

aron.rahman at parcIT.de<mailto:aron.rahman at parcIT.de>
Tel.: +49 221 584 75 156

parcIT GmbH
Erftstra?e 15
50672 K?ln

Sitz der Gesellschaft: K?ln
AG K?ln HRB 67455
Gesch?ftsf?hrer: Thomas Jagodzinsky, Patrick Yousefian
www.parcIT.de<http://www.parcit.de/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20260219/d9edc62b/attachment-0001.htm>

From prr at openjdk.org  Thu Feb 19 18:01:50 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 18:01:50 GMT
Subject: Integrated: 8378204: Remove AppContext from two Swing UI classes
In-Reply-To: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
References: <cO00hlrUNkhvTzN5P8UihuPKW5LWbQl37bfkyjPKasY=.03b121d7-142e-46bc-bf66-087b1b29964f@github.com>
Message-ID: <P26uDOtyhpAU_vDOPRAczkuNOkYhAwPPqoagoCoh7Z0=.fc0ea607-b409-4cd5-90fb-46366c34f509@github.com>

On Wed, 18 Feb 2026 23:06:18 GMT, Phil Race <prr at openjdk.org> wrote:

> A couple of missed cases of removing AppContext from Swing UI classes and one dead import

This pull request has now been integrated.

Changeset: 9b44ea39
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b44ea39bf07b1d76e5bf9ebddbcae6bfc93e357
Stats:     14 lines in 3 files changed: 0 ins; 11 del; 3 mod

8378204: Remove AppContext from two Swing UI classes

Reviewed-by: serb, kizune

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

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

From prr at openjdk.org  Thu Feb 19 18:07:32 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 18:07:32 GMT
Subject: Integrated: 8378192: Remove AppContext from SwingUtilities2
In-Reply-To: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
References: <3D7XYpszBXJpP1vZVThk1Hc5gxWX9Vf2Ye2UO0vPMzw=.609038e5-7ca5-4961-ab40-768f3a05341e@github.com>
Message-ID: <qp2OFHZX8MY4bAIEeHOCvsTOBOma1Jz6V6BnZr7_2R8=.48980303-4e27-4ad5-9f69-2788964eeb05@github.com>

On Wed, 18 Feb 2026 19:19:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from SwingUtilities2

This pull request has now been integrated.

Changeset: 2a71f89b
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a71f89bc8d72be8095113695e541f4f38acdeca
Stats:     11 lines in 1 file changed: 0 ins; 10 del; 1 mod

8378192: Remove AppContext from SwingUtilities2

Reviewed-by: psadhukhan, kizune

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

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

From prr at openjdk.org  Thu Feb 19 18:36:25 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 18:36:25 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v3]
In-Reply-To: <HRobHdhbpaCzxUYEXer53Qq2tgaejqvnZHgv2CfQMZg=.1ec9e358-a0c9-44d8-acab-c475dda68da6@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
 <HRobHdhbpaCzxUYEXer53Qq2tgaejqvnZHgv2CfQMZg=.1ec9e358-a0c9-44d8-acab-c475dda68da6@github.com>
Message-ID: <5zsD6woqsilZcxJ1QYJFjCEIrU7imrOr_YpJzpN3caA=.f1aa3135-5cfa-48a6-b72c-d13343dc3f55@github.com>

On Thu, 19 Feb 2026 03:51:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `JProgressBar` is not printed if JDK 1.1 printing API is used.
>> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
>> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
>> `g2.setStroke(new BasicStroke(...))`
>> 
>> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
>> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused imports
>  - Remove unused imports

The bug report says
 "I note that BasicTabbedPaneUI.java also bails if it's not got a Graphics2D."

Is that still an issue ? If yes, can it be fixed here ?
 If yes to the first and no to the second a new bug should be submitted.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java line 731:

> 729:         int amountFull = getAmountFull(b, barRectWidth, barRectHeight);
> 730: 
> 731:         Graphics g2 = null;

Naming it g2 implies it is a Graphics2D .. I guess you were trying to minimize lines that need to change but it is better to name the Graphics just 'g'. and may be use g2d for the Graphics2D ?
So we'll see every line that needs to change.

Also if I'm reading this right you just draw a 1 user space pixel line if its not a G2D ?
The use of barRectHeight for the stroke width tells  me that you need something more like fillRect as an alternative don't you ?

Also the cellspacing case (lines 749-751)  looks like it needs individual fillRect calls.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java line 876:

> 874:                 g2.setColor(getSelectionForeground());
> 875:                 g2.clipRect(fillStart, y, amountFull, height);
> 876:                 SwingUtilities2.drawString(progressBar, g2, progressString,

surely you can't just skip the drawString ? 
Also SFAICS that call accepts a Graphics and internally handles printing. Why is it excluded here ? 
The explanation in the PR description "not to clip progress string" is way too vague.

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 532:

> 530:             int[][] members = range.getMembers();
> 531:             jobAttributes.setPageRanges(members);
> 532:         }

Hmm. This seems a very odd thing to include in this PR. It it is unrelated.
 I don't think it should be here and we've managed for 20 years without this null check, so why now ?

Is it a regression caused by https://github.com/openjdk/jdk/pull/29312/ ?

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

PR Review: https://git.openjdk.org/jdk/pull/29752#pullrequestreview-3827686047
PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2829439935
PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2829475969
PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2829490964

From prr at openjdk.org  Thu Feb 19 19:42:05 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 19:42:05 GMT
Subject: RFR: 8377602: Create automated test for PageRange
In-Reply-To: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
Message-ID: <ysh9mNG7VKVA-in_b9hUcUmN_a3PBrlZ7ISyF91KFkI=.a002b0cb-9aae-454b-976c-022789fd49f2@github.com>

On Tue, 10 Feb 2026 20:45:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
> 
> With this PR, I'm contributing the test to OpenJDK.
> 
> Without the fix for JDK-8297191, the test fails with the following error messages:
> 
> <details>
> <summary>test log</summary>
> 
> 
> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
> 	at PageRangesAuto.main(PageRangesAuto.java:146)
> 
> </details>

test/jdk/java/awt/print/PrinterJob/PageRangesAuto.java line 99:

> 97:                           : String.format("%s-%d-%d.pdf",
> 98:                                           baseName,
> 99:                                           pageRange.getMembers()[0][1],

are these both supposed to be [0][1] ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2829797479

From aivanov at openjdk.org  Thu Feb 19 20:01:09 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Feb 2026 20:01:09 GMT
Subject: RFR: 8377602: Create automated test for PageRange
In-Reply-To: <ysh9mNG7VKVA-in_b9hUcUmN_a3PBrlZ7ISyF91KFkI=.a002b0cb-9aae-454b-976c-022789fd49f2@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <ysh9mNG7VKVA-in_b9hUcUmN_a3PBrlZ7ISyF91KFkI=.a002b0cb-9aae-454b-976c-022789fd49f2@github.com>
Message-ID: <E76QHO50rmPkytOSFLasaiDqfMr3ytmn7aiWbnXVVjI=.754d7775-dcc6-4441-8bda-7eacd5989ff7@github.com>

On Thu, 19 Feb 2026 19:39:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
>> 
>> With this PR, I'm contributing the test to OpenJDK.
>> 
>> Without the fix for JDK-8297191, the test fails with the following error messages:
>> 
>> <details>
>> <summary>test log</summary>
>> 
>> 
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
>> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> 	at PageRangesAuto.main(PageRangesAuto.java:146)
>> 
>> </details>
>
> test/jdk/java/awt/print/PrinterJob/PageRangesAuto.java line 99:
> 
>> 97:                           : String.format("%s-%d-%d.pdf",
>> 98:                                           baseName,
>> 99:                                           pageRange.getMembers()[0][1],
> 
> are these both supposed to be [0][1] ?

No, the first one has to be `[0][0]`.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2829877123

From aivanov at openjdk.org  Thu Feb 19 20:04:13 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Feb 2026 20:04:13 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
Message-ID: <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>

> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
> 
> With this PR, I'm contributing the test to OpenJDK.
> 
> Without the fix for JDK-8297191, the test fails with the following error messages:
> 
> <details>
> <summary>test log</summary>
> 
> 
> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
> 	at PageRangesAuto.main(PageRangesAuto.java:146)
> 
> </details>

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Use the first page of the rage in the filename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29660/files
  - new: https://git.openjdk.org/jdk/pull/29660/files/aa53a5c2..e075bba0

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

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

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

From prr at openjdk.org  Thu Feb 19 20:11:40 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 20:11:40 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v3]
In-Reply-To: <p-BaTiQk2-emijZiUsiMb3-suBzcfLYw5AHu8Hjoy7A=.6036b2bf-f41f-4d93-b564-fc65983fe8eb@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <p-BaTiQk2-emijZiUsiMb3-suBzcfLYw5AHu8Hjoy7A=.6036b2bf-f41f-4d93-b564-fc65983fe8eb@github.com>
Message-ID: <4zVoJ7_NKIMewlpAkjf9mFxzdiKc62YIXNYrLzSkJM0=.531f7cd0-2127-4240-8ad5-a8b10ca68b8f@github.com>

On Tue, 17 Feb 2026 20:32:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>>  - rgba -> argb, since this is the format described in the spec
>>  - hasalpha -> hasAlpha, to follow common naming conventions
>> 
>> Also adds a basic test for the constructor.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lists via "<ul>" is added

Marked as reviewed by prr (Reviewer).

src/java.desktop/share/classes/java/awt/Color.java line 408:

> 406:      *   <li>the red component in bits 16-23,
> 407:      *   <li>the green component in bits 8-15, and
> 408:      *   <li>the blue component in bits 0-7.

The list is cleaner.

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

PR Review: https://git.openjdk.org/jdk/pull/29734#pullrequestreview-3828251315
PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2829918733

From prr at openjdk.org  Thu Feb 19 20:11:43 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 20:11:43 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
Message-ID: <zdCOJuzRx0FDdpd9Szp8zl5hnz4BEKj4InnZGafrrN0=.3d06727c-7322-485c-a4ba-fdea9e984a13@github.com>

On Tue, 17 Feb 2026 19:43:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback
>
> src/java.desktop/share/classes/java/awt/Color.java line 337:
> 
>> 335:      * on finding the best match given the color space
>> 336:      * available for a given output device.
>> 337:      * Alpha defaults to 255.
> 
> I think it's better this way, but I'll leave it to Phil.

Either way is OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2829917557

From serb at openjdk.org  Thu Feb 19 22:00:28 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 19 Feb 2026 22:00:28 GMT
Subject: RFR: 8378050: Add missing @Override annotations in
 "java.awt.color" package [v2]
In-Reply-To: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
References: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
Message-ID: <QrVZLtvf823QxtDQFUSv55g7fUiCY0jqlMCjgPZkFfk=.80d011ea-9d23-46e4-a73e-f69f2ad32ee0@github.com>

> This patch adds missing `@Override` annotations to methods in the `java.awt.color` package that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

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-8378050
 - 8378050: Add missing @Override annotations in "java.awt.color" package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29749/files
  - new: https://git.openjdk.org/jdk/pull/29749/files/7a9a2af3..9d73846d

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

  Stats: 80650 lines in 271 files changed: 33816 ins; 34219 del; 12615 mod
  Patch: https://git.openjdk.org/jdk/pull/29749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29749/head:pull/29749

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

From serb at openjdk.org  Thu Feb 19 23:07:59 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 19 Feb 2026 23:07:59 GMT
Subject: RFR: 8378193: Remove AppContext from JinternalFrame
In-Reply-To: <0piE6_vP3udG1F1qMLU3hH8JE3kSxiU-mlpp9zl0MBA=.77c6a9de-fa47-410e-91b7-2384d6669017@github.com>
References: <0piE6_vP3udG1F1qMLU3hH8JE3kSxiU-mlpp9zl0MBA=.77c6a9de-fa47-410e-91b7-2384d6669017@github.com>
Message-ID: <1CXxGQaLAgGPb2E7VWwZWR4ilo-zIAFzRsQr9OXoWSo=.8bc33866-af35-48d8-b949-60226969a480@github.com>

On Wed, 18 Feb 2026 19:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

> We don't need a per-AppContext JInternalFrame focusListener any more.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29799#pullrequestreview-3828986632

From serb at openjdk.org  Thu Feb 19 23:10:44 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 19 Feb 2026 23:10:44 GMT
Subject: RFR: 8378197: Remove AppContext from
 sun/swing/plaf/DesktopProperty.java
In-Reply-To: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
References: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
Message-ID: <C8PZXxY60EyHn8L8LXLXlne-kq9kFoaV-A3qFFFDzMI=.85f52223-a37b-4801-be58-dbd8cbe04d3c@github.com>

On Wed, 18 Feb 2026 19:57:15 GMT, Phil Race <prr at openjdk.org> wrote:

> A straightforward removal of a per-AppContext flag which can now be static

src/java.desktop/share/classes/sun/swing/plaf/DesktopProperty.java line 98:

> 96:      */
> 97:     private static synchronized void setUpdatePending(boolean update) {
> 98:         updatePending = update;

It seems the synchronized accessors are no longer needed? And the field itself marked as volatile can be used instead, since both of these methods are called from just the updateUI() method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29801#discussion_r2830585643

From serb at openjdk.org  Thu Feb 19 23:15:23 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 19 Feb 2026 23:15:23 GMT
Subject: RFR: 8378203: Remove AppContext from jdk.unsupported.desktop
In-Reply-To: <xrjfUalJ1r4WdJRx2QGNg720qdXacw8EGX8E-reC_PU=.e6707d59-143d-49e6-b347-2e03eb74a337@github.com>
References: <xrjfUalJ1r4WdJRx2QGNg720qdXacw8EGX8E-reC_PU=.e6707d59-143d-49e6-b347-2e03eb74a337@github.com>
Message-ID: <Dd-8eed_AVTVnT2NdgMQVKlpTxjcP-vWu1P1Rhu6m-g=.3817094e-a454-4789-a9e5-df47399ee2d9@github.com>

On Wed, 18 Feb 2026 23:01:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from jdk.unsupported.desktop module

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29805#pullrequestreview-3829006474

From prr at openjdk.org  Thu Feb 19 23:20:24 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 23:20:24 GMT
Subject: RFR: 8378296: Remove AppContext from java.awt.event.FocusEvent
Message-ID: <H9Vv_-t2x9oz_Bdxyqo5SH4q5u2ugHBXgbKn_LDpNRU=.01552d56-ba28-4912-b49a-7ffb75d37029@github.com>

Remove AppContext from java.awt.event.FocusEvent

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

Commit messages:
 - 8378296

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

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

From prr at openjdk.org  Thu Feb 19 23:26:19 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 23:26:19 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes
Message-ID: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>

Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).

One ToolTipManager test for the AppContext is removed.

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

Commit messages:
 - 8378297

Changes: https://git.openjdk.org/jdk/pull/29830/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29830&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378297
  Stats: 208 lines in 8 files changed: 15 ins; 151 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/29830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29830/head:pull/29830

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

From prr at openjdk.org  Thu Feb 19 23:47:37 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 23:47:37 GMT
Subject: Integrated: 8378203: Remove AppContext from jdk.unsupported.desktop
In-Reply-To: <xrjfUalJ1r4WdJRx2QGNg720qdXacw8EGX8E-reC_PU=.e6707d59-143d-49e6-b347-2e03eb74a337@github.com>
References: <xrjfUalJ1r4WdJRx2QGNg720qdXacw8EGX8E-reC_PU=.e6707d59-143d-49e6-b347-2e03eb74a337@github.com>
Message-ID: <kIFm4ho_wwpBpG4N10O9y8dK3eh3UcwS93kh1doFJKc=.e8fc9bb1-ab12-4f70-b290-d2e537e04aad@github.com>

On Wed, 18 Feb 2026 23:01:26 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from jdk.unsupported.desktop module

This pull request has now been integrated.

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

8378203: Remove AppContext from jdk.unsupported.desktop

Reviewed-by: kizune, serb

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

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

From prr at openjdk.org  Thu Feb 19 23:49:24 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 19 Feb 2026 23:49:24 GMT
Subject: Integrated: 8378193: Remove AppContext from JinternalFrame
In-Reply-To: <0piE6_vP3udG1F1qMLU3hH8JE3kSxiU-mlpp9zl0MBA=.77c6a9de-fa47-410e-91b7-2384d6669017@github.com>
References: <0piE6_vP3udG1F1qMLU3hH8JE3kSxiU-mlpp9zl0MBA=.77c6a9de-fa47-410e-91b7-2384d6669017@github.com>
Message-ID: <NudwDm1U6jnERi4Dx-c5w3Z1-dF6KprAJpvaCp3CbPw=.c9a0941a-a8c1-44bb-a470-b48ae9d3e0e1@github.com>

On Wed, 18 Feb 2026 19:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

> We don't need a per-AppContext JInternalFrame focusListener any more.

This pull request has now been integrated.

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

8378193: Remove AppContext from JinternalFrame

Reviewed-by: kizune, serb

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

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

From prr at openjdk.org  Fri Feb 20 01:02:44 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 01:02:44 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation
In-Reply-To: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
Message-ID: <Ty1WuwuksjctjhONgN7pDAzEUvPFbu3DHpwkO9bX8cU=.aa9dd586-8ac5-4d1f-9c55-a77eed728e8a@github.com>

On Sat, 14 Feb 2026 16:13:27 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
> 
> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
> 
> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
> 
> Tested on mac, Linux and Windows:
> - make test TEST="jtreg:test/jdk/java/awt/font"
> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"

LGTM. I ran all our automated tests and they all passed (including the new test passes on all platforms, not just macOS).

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29726#pullrequestreview-3829312300

From serb at openjdk.org  Fri Feb 20 01:01:59 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 20 Feb 2026 01:01:59 GMT
Subject: Integrated: 8378050: Add missing @Override annotations in
 "java.awt.color" package
In-Reply-To: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
References: <ZmC6zqdp72Yco-dKwaVOaErUd0B6Z0mO1jsvJR6LPbc=.fa0b00ab-c3a7-421b-b6b3-aa5c979b317b@github.com>
Message-ID: <9Xu7DX8sCFUQEMKB9Z3DFDJIOklXZ_LjENNcj8XltII=.0420ceaa-b5d7-4451-8150-9810826d3099@github.com>

On Mon, 16 Feb 2026 20:56:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `java.awt.color` package that override methods from a superclass or interface.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for com.sun.beans can be found here: https://github.com/openjdk/jdk/pull/27887.

This pull request has now been integrated.

Changeset: 866cbcbe
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/866cbcbecb02bf9d7bbc37941a503cc968f34428
Stats:     13 lines in 3 files changed: 10 ins; 0 del; 3 mod

8378050: Add missing @Override annotations in "java.awt.color" package

Reviewed-by: kizune, prr

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

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

From azvegint at openjdk.org  Fri Feb 20 01:26:56 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 20 Feb 2026 01:26:56 GMT
Subject: RFR: 8378153: Robot.getPixelColor() may return stale pixels due to
 missing Toolkit.sync()
In-Reply-To: <fzKmq08t4pxg-FdtZcN5EdKUU7IfH6g76Q0yVp43XzU=.1dd383ef-f88f-4786-944b-1be9d3ace77d@github.com>
References: <fzKmq08t4pxg-FdtZcN5EdKUU7IfH6g76Q0yVp43XzU=.1dd383ef-f88f-4786-944b-1be9d3ace77d@github.com>
Message-ID: <6aAuSHdeWO3vOIuONgPynQWlxqMgksHfUU3FavnuQI8=.7d5b22e0-b618-4b16-9b0e-e690eb710e6d@github.com>

On Wed, 18 Feb 2026 08:24:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Robot.getPixelColor() does not call Toolkit.getDefaultToolkit().sync() before reading the pixel, unlike Robot.createScreenCapture() which has had this call since [JDK-6725214](https://bugs.openjdk.org/browse/JDK-6725214).
> 
> When a hardware-accelerated pipeline (OGL, D3D, Metal) is active, rendering may be buffered and not yet flushed to the screen when getPixelColor() reads the pixel. This causes it to return stale values typically the window background color instead of the rendered content.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29780#pullrequestreview-3829366575

From prr at openjdk.org  Fri Feb 20 01:48:26 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 01:48:26 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
Message-ID: <GPi6BPG7AvhBZy_tXX471-cty1LjkcgVxfXu_VarmtU=.24b7351d-8c2e-49d8-bdcb-f28f56631cf7@github.com>

On Thu, 19 Feb 2026 20:04:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
>> 
>> With this PR, I'm contributing the test to OpenJDK.
>> 
>> Without the fix for JDK-8297191, the test fails with the following error messages:
>> 
>> <details>
>> <summary>test log</summary>
>> 
>> 
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
>> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> 	at PageRangesAuto.main(PageRangesAuto.java:146)
>> 
>> </details>
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the first page of the rage in the filename

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29660#pullrequestreview-3829415983

From prr at openjdk.org  Fri Feb 20 01:52:56 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 01:52:56 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v5]
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <81c7TYE-4y_68a-6NTNEnLaRfoDxtAQfRWQUFnpyy2U=.68042616-306d-4737-8fce-f1017fcaaf16@github.com>

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116

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

  8377568

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29766/files
  - new: https://git.openjdk.org/jdk/pull/29766/files/1ef21b8a..f17761b4

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

  Stats: 146 lines in 7 files changed: 46 ins; 0 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/29766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29766/head:pull/29766

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

From prr at openjdk.org  Fri Feb 20 01:52:56 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 01:52:56 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v4]
In-Reply-To: <7pTcxScQTrrk7DUOwa29-XVrRRoWud6UyTDyvNePQpc=.803e79a2-fb17-406c-abb5-643695e40ab3@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <5StOPdQH7yYKKBeqyzMYzpiAhys6tOURG6jQc8-ViUA=.fc69b8a4-0f4c-4d91-b809-3dc8a5c5408d@github.com>
 <yL-n8nf3ZFwKt1_MTkl2hX_pRZ-Lr2r4kXaRHjQnROI=.85ab27b5-ac65-4518-a537-bf11f2254af4@github.com>
 <KZrx4jQsdwwm1pf13ppkjVd0A-7a6LO8N0R12ZwWcxA=.71d7bf45-11fb-40dc-bcf4-7d97f3257286@github.com>
 <ZYIulohWyYm3ckUCA0GESHRa5YCAcfifOO7APnE2QM4=.a1ac7a63-f114-4bb5-8e9b-0b3b025bd6ba@github.com>
 <7pTcxScQTrrk7DUOwa29-XVrRRoWud6UyTDyvNePQpc=.803e79a2-fb17-406c-abb5-643695e40ab3@github.com>
Message-ID: <ikMVUPB7r_Jc94UHXciRP9VkF3em-MrTMCfqNLHfhjM=.0be1e6b6-e330-4c87-9633-b7954d89218c@github.com>

On Wed, 18 Feb 2026 18:47:03 GMT, Phil Race <prr at openjdk.org> wrote:

>>> You get a valid DataBuffer but there isn't a normal use for it.,
>> 
>> Yes, calling any methods on it will cause an exception, right? In that case, we should probably reject it? Or are there cases where an empty data buffer could actually be useful?
>
> I can't think of any use for it once it is created.
> 
> Because everything that uses a DataBuffer (in the imaging APIs) like Raster and BufferedImage require w/h of at least 1. So I'm not sure how a zero-length DataBuffer could ever be used once created.
> And getElem() / setElem() can never be used either. 
> The only use  would be in tests that see if you can create it  .. not a particularly practical real world use.
> 
> But because the spec. didn't disallow it, I didn't want to do anything about it. I tried to keep this change as much as possible to enforcing what the existing spec says. Already a tiny bit worried about breaking some weird code somewhere that ignores the spec.

I slept on this and I can't think of any legitimate use that needs a DataBuffer of size 0. Hope I'm right on this, since I've updated the code and the spec to disallow zero. Pushing that to the PR in just a few moments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2830977478

From psadhukhan at openjdk.org  Fri Feb 20 08:53:59 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 20 Feb 2026 08:53:59 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v4]
In-Reply-To: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
Message-ID: <_mGtxE7NoNXvggpgQhMj0x1OX78a9KAbhpLx4JtjvZ0=.746966af-5999-43bd-9581-b5f4a274783c@github.com>

> `JProgressBar` is not printed if JDK 1.1 printing API is used.
> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
> `g2.setStroke(new BasicStroke(...))`
> 
> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"

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/29752/files
  - new: https://git.openjdk.org/jdk/pull/29752/files/df542555..1bba1b20

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

  Stats: 109 lines in 2 files changed: 72 ins; 5 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/29752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29752/head:pull/29752

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

From psadhukhan at openjdk.org  Fri Feb 20 08:57:12 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 20 Feb 2026 08:57:12 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v3]
In-Reply-To: <5zsD6woqsilZcxJ1QYJFjCEIrU7imrOr_YpJzpN3caA=.f1aa3135-5cfa-48a6-b72c-d13343dc3f55@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
 <HRobHdhbpaCzxUYEXer53Qq2tgaejqvnZHgv2CfQMZg=.1ec9e358-a0c9-44d8-acab-c475dda68da6@github.com>
 <5zsD6woqsilZcxJ1QYJFjCEIrU7imrOr_YpJzpN3caA=.f1aa3135-5cfa-48a6-b72c-d13343dc3f55@github.com>
Message-ID: <28rW_tYV7qIbk6Mp_p0m-QCS754qrEDB9B5hcaqVpxk=.0d28d09d-a1be-4cd3-8e48-eb2691cee38e@github.com>

On Thu, 19 Feb 2026 18:22:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove unused imports
>>  - Remove unused imports
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java line 731:
> 
>> 729:         int amountFull = getAmountFull(b, barRectWidth, barRectHeight);
>> 730: 
>> 731:         Graphics g2 = null;
> 
> Naming it g2 implies it is a Graphics2D .. I guess you were trying to minimize lines that need to change but it is better to name the Graphics just 'g'. and may be use g2d for the Graphics2D ?
> So we'll see every line that needs to change.
> 
> Also if I'm reading this right you just draw a 1 user space pixel line if its not a G2D ?
> The use of barRectHeight for the stroke width tells  me that you need something more like fillRect as an alternative don't you ?
> 
> Also the cellspacing case (lines 749-751)  looks like it needs individual fillRect calls.

Variables renamed..and fillRect used instead of drawLine...also, individual fillRect calls used for cellSpacing case..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2832117051

From psadhukhan at openjdk.org  Fri Feb 20 09:06:31 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 20 Feb 2026 09:06:31 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v4]
In-Reply-To: <_mGtxE7NoNXvggpgQhMj0x1OX78a9KAbhpLx4JtjvZ0=.746966af-5999-43bd-9581-b5f4a274783c@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
 <_mGtxE7NoNXvggpgQhMj0x1OX78a9KAbhpLx4JtjvZ0=.746966af-5999-43bd-9581-b5f4a274783c@github.com>
Message-ID: <FVVWzTYPNeYdmapKu3z-TpPCLj9MIz1lQaHfTROoZmw=.97177f73-f990-44c5-ba5b-0763996362ec@github.com>

On Fri, 20 Feb 2026 08:53:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `JProgressBar` is not printed if JDK 1.1 printing API is used.
>> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
>> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
>> `g2.setStroke(new BasicStroke(...))`
>> 
>> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
>> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Horizontal print with fix
<img width="378" height="66" alt="image" src="https://github.com/user-attachments/assets/aaca9387-154d-4b18-b835-d1ba812ac843" />

Vertical print
<img width="62" height="358" alt="image" src="https://github.com/user-attachments/assets/53ba5605-5e17-4d6b-8e4e-c3d2ab23ab2b" />

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsProgressBarUI.java line 153:

> 151:                 int dpi = java.awt.Toolkit.getDefaultToolkit().getScreenResolution();
> 152:                 scaleX = (double) dpi / 96.0;
> 153:                 scaleY = (double) dpi / 96.0;

Is there any other way to get scale factor that doesn't use AffineTransform?

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

PR Comment: https://git.openjdk.org/jdk/pull/29752#issuecomment-3932523552
PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2832150218

From psadhukhan at openjdk.org  Fri Feb 20 09:06:35 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 20 Feb 2026 09:06:35 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v3]
In-Reply-To: <5zsD6woqsilZcxJ1QYJFjCEIrU7imrOr_YpJzpN3caA=.f1aa3135-5cfa-48a6-b72c-d13343dc3f55@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
 <HRobHdhbpaCzxUYEXer53Qq2tgaejqvnZHgv2CfQMZg=.1ec9e358-a0c9-44d8-acab-c475dda68da6@github.com>
 <5zsD6woqsilZcxJ1QYJFjCEIrU7imrOr_YpJzpN3caA=.f1aa3135-5cfa-48a6-b72c-d13343dc3f55@github.com>
Message-ID: <A79vWzS2GvQ_ZFCiRjKRRe74kgZw6mvW1hN7PXLIMMo=.7b292b50-d464-424b-81aa-235d83686057@github.com>

On Thu, 19 Feb 2026 18:33:39 GMT, Phil Race <prr at openjdk.org> wrote:

> The bug report says "I note that BasicTabbedPaneUI.java also bails if it's not got a Graphics2D."
> 
> Is that still an issue ? If yes, can it be fixed here ? If yes to the first and no to the second a new bug should be submitted.

I will check and submit a new bug for it if the issue exists..Let this be about ProgressBar only..

> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java line 876:
> 
>> 874:                 g2.setColor(getSelectionForeground());
>> 875:                 g2.clipRect(fillStart, y, amountFull, height);
>> 876:                 SwingUtilities2.drawString(progressBar, g2, progressString,
> 
> surely you can't just skip the drawString ? 
> Also SFAICS that call accepts a Graphics and internally handles printing. Why is it excluded here ? 
> The explanation in the PR description "not to clip progress string" is way too vague.

There was a drawString before that block that draws the full string.
This block fills the color inside the string and there was an issue with that which was basically preventing the string that was inside the progressbar filledpart to be filled with foreground color and the clipped part was rendered white
But that is now resolved with current version..

> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 532:
> 
>> 530:             int[][] members = range.getMembers();
>> 531:             jobAttributes.setPageRanges(members);
>> 532:         }
> 
> Hmm. This seems a very odd thing to include in this PR. It it is unrelated.
>  I don't think it should be here and we've managed for 20 years without this null check, so why now ?
> 
> Is it a regression caused by https://github.com/openjdk/jdk/pull/29312/ ?

Yes, it seems so..Clicking "All" will result in NPE so resolved that here..

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

PR Comment: https://git.openjdk.org/jdk/pull/29752#issuecomment-3932526895
PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2832130554
PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2832133268

From psadhukhan at openjdk.org  Fri Feb 20 09:28:59 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 20 Feb 2026 09:28:59 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v5]
In-Reply-To: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
Message-ID: <4ziZRgP5kHetXwfPlaVABNjPv9YRPSM0AQqxBSHylRc=.e0334204-a6ab-45ca-aac7-2382cea8c3a9@github.com>

> `JProgressBar` is not printed if JDK 1.1 printing API is used.
> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
> `g2.setStroke(new BasicStroke(...))`
> 
> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"

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

  Variable rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29752/files
  - new: https://git.openjdk.org/jdk/pull/29752/files/1bba1b20..08bc35dd

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

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

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

From rkannathpari at openjdk.org  Fri Feb 20 11:00:53 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 20 Feb 2026 11:00:53 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v2]
In-Reply-To: <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
Message-ID: <1s0iBlr0T2mAj7zvtvKfzhG36lf7tiXOIYIuNX8lNXg=.99a354f0-e189-4859-bdbf-5f55060dc1f2@github.com>

On Mon, 16 Feb 2026 06:54:08 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

Yes, I did it on my local machine and verified for Windows and Linux

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

PR Comment: https://git.openjdk.org/jdk/pull/29733#issuecomment-3933079150

From psadhukhan at openjdk.org  Fri Feb 20 12:00:57 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 20 Feb 2026 12:00:57 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v6]
In-Reply-To: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
Message-ID: <D8V6Dchj_fMxJBNBnWTXPcEc9Ax8V-8Tpuq_mSkf6rE=.22a0e723-4ed1-4152-82ac-c851010410a4@github.com>

> `JProgressBar` is not printed if JDK 1.1 printing API is used.
> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
> `g2.setStroke(new BasicStroke(...))`
> 
> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"

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

  Test enhancement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29752/files
  - new: https://git.openjdk.org/jdk/pull/29752/files/08bc35dd..4b29eafc

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

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

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

From aivanov at openjdk.org  Fri Feb 20 13:54:40 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 20 Feb 2026 13:54:40 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v3]
In-Reply-To: <p-BaTiQk2-emijZiUsiMb3-suBzcfLYw5AHu8Hjoy7A=.6036b2bf-f41f-4d93-b564-fc65983fe8eb@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <p-BaTiQk2-emijZiUsiMb3-suBzcfLYw5AHu8Hjoy7A=.6036b2bf-f41f-4d93-b564-fc65983fe8eb@github.com>
Message-ID: <1vxyRsKoNR4kllpVcK8F49uWXQL1Kt3-L9ONe8xnmZ8=.9f3913d2-f950-4a2f-adf4-14f56e0d2d4c@github.com>

On Tue, 17 Feb 2026 20:32:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>>  - rgba -> argb, since this is the format described in the spec
>>  - hasalpha -> hasAlpha, to follow common naming conventions
>> 
>> Also adds a basic test for the constructor.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lists via "<ul>" is added

Looks good to me, yet I left a few minor comments.

src/java.desktop/share/classes/java/awt/Color.java line 578:

> 576: 
> 577:     /**
> 578:      * Returns the RGB value representing the color in the default sRGB

Should it say **ARGB**? The alpha bits are always included and are valid.

src/java.desktop/share/classes/java/awt/Color.java line 579:

> 577:     /**
> 578:      * Returns the RGB value representing the color in the default sRGB
> 579:      * {@link ColorModel}, consisting of

I think `ColorModel` should be replaced with ?color model? because the meaning is literal rather than implies a class name.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29734#pullrequestreview-3832086779
PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2833268472
PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2833276558

From aivanov at openjdk.org  Fri Feb 20 13:54:42 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 20 Feb 2026 13:54:42 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <zdCOJuzRx0FDdpd9Szp8zl5hnz4BEKj4InnZGafrrN0=.3d06727c-7322-485c-a4ba-fdea9e984a13@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <zdCOJuzRx0FDdpd9Szp8zl5hnz4BEKj4InnZGafrrN0=.3d06727c-7322-485c-a4ba-fdea9e984a13@github.com>
Message-ID: <M9i6RnN27CiRu4nm0CA3p_0hhjUCQCsQcSRNiuJYasY=.8f44251d-739a-455f-934e-c088fe695f5c@github.com>

On Thu, 19 Feb 2026 20:08:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Color.java line 337:
>> 
>>> 335:      * on finding the best match given the color space
>>> 336:      * available for a given output device.
>>> 337:      * Alpha defaults to 255.
>> 
>> I think it's better this way, but I'll leave it to Phil.
>
> Either way is OK.

Then I prefer *?defaults?*, and Sergey has updated the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2833257985

From aivanov at openjdk.org  Fri Feb 20 13:54:44 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 20 Feb 2026 13:54:44 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v3]
In-Reply-To: <GwZAb5O-NcOI9t5fy-qWIGBUFteelbOaXv5rha970TU=.671fd652-c313-4ca8-86b9-a0a1d7c45b25@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <D68_gvBfSOYf9JPnH7oWHSOj5qqm31Aeb-gfACT32c4=.00167277-be17-4b63-8f24-1e6e04204ac1@github.com>
 <T-4wlPIQXsQkUHmMApW9Dn7DWyo4oscyofABLLluS08=.8c880d4b-a5db-4522-91c2-8f99619e4b81@github.com>
 <GwZAb5O-NcOI9t5fy-qWIGBUFteelbOaXv5rha970TU=.671fd652-c313-4ca8-86b9-a0a1d7c45b25@github.com>
Message-ID: <11vi60gCU-j8J6zD6ziVC3f213gbeVtlhwvCaH0iUf8=.38f16f41-2aa2-4a31-8116-9371170d9dc3@github.com>

On Tue, 17 Feb 2026 20:29:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I'll experiment with this.
>
> It actually handled by javadoc properly -> correct summary is generated, I tried to unify the text in the constructors and getRGB method.

Perfect! I verified it, the summary is the same and includes all the components of the list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2833292825

From aivanov at openjdk.org  Fri Feb 20 13:54:45 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 20 Feb 2026 13:54:45 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v2]
In-Reply-To: <ni74XwWt2K2IwCOkLYVZ72FU9KqTXxEW4X3KXMRpWF8=.b948cb6e-1ca0-4183-98c1-4c6fa6ff17d1@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
 <UsmZtLJx0nuRrd9_u98I5UBqiF1NqXrN4tkyjNpbzdE=.74310e2b-d18e-4386-8f8d-d6c23889d6b6@github.com>
 <Jo89s-OYzdOu-96eA598QX3LKFjxNgy4Yu2BdvJ_Ka4=.f6543536-d88e-4c40-b9f8-bcd306327577@github.com>
 <NPYiFtVaqdA7npJQqAE9OXyd2z6IwiGp6vyDUG5bYao=.b7fbb77e-fcc6-4698-abb5-7774bf852d29@github.com>
 <2-g_bbIeyazMe9VGbKD-6pOU9n6SqUhTGdooOPq7laM=.e6c25538-b9e1-430a-8dae-7fd641751d6b@github.com>
 <PfvlCkISRFT4pgFvAkZ3_FN2dUV20UJLoUM2VgNjaL0=.db1b6e1b-e52e-4c2b-975a-469bfd8787b6@github.com>
 <ExRte_gTcE2IoCNHBW6XF5sU5AUAkEaQc_n0bXgCTCU=.6dcc4c5e-3226-4986-9c72-6453d7f7fd6b@github.com>
 <JtfxmtQs-fKHTnSRhM3cw6aTVS-BCQskSUzRehnCd6c=.4ab96382-26d7-4f22-b32a-4c35bb7dfe86@github.com>
 <cLC4w0WH36I363iirCUbfgaBZ-N_vwrQ6_FK1MgGeVc=.048b624a-5daa-406d-95bc-7278a12d529b@github.com>
 <IhgnrtFjbYR1GnOL96EFmrmS_ETb4L1sJgLt_Q12_wc=.b3f4f56a-4a53-49f0-acce-f79a7eb95bd1@github.com>
 <ni74XwWt2K2IwCOkLYVZ72FU9KqTXxEW4X3
 KXMRpWF8=.b948cb6e-1ca0-4183-98c1-4c6fa6ff17d1@github.com>
Message-ID: <R8xP4PXDtp1kXyCn5sw7IeozCIS1fltXKwqY928IvEI=.b663d44d-0e07-4822-80c7-1af570127433@github.com>

On Tue, 17 Feb 2026 20:46:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Not necessary, but using `>>>` doesn't change the result, and using the same operator in all the three cases looks *consistent*.
>
> Why should it use the same operator for all of them if some are unnecessary? I prefer >>> for alpha because it works well without additional masking, and masking only for blue, which does not need a shift by zero. It is short and clean, and there is no need to align it beautifully just to make it look better.

I'd still go for the same operator in all the color components so that all of the cases look *consistently*.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29734#discussion_r2833301384

From azvegint at openjdk.org  Fri Feb 20 14:17:33 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 20 Feb 2026 14:17:33 GMT
Subject: RFR: 8337853: Remove SunLayoutEngineKey and SunLayoutEngineFactory
 and its cache.
In-Reply-To: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
References: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
Message-ID: <LgwruZUcpi5hiGSkqKhAmKMrL6Jl9AHOZeYYJg038ys=.9ec25271-5958-4e8d-ac80-1bb225c5a196@github.com>

On Wed, 11 Feb 2026 20:42:50 GMT, Phil Race <prr at openjdk.org> wrote:

> For a long time I've looked at the unnecessary complexity around the code that manages "LayoutEngines' for OpenType font layout.
> 
> The code was written a very long time ago when it was supposed that you might have a layout engine that could do Arabic. An unrelated one for Devanagari. An unrelated one for Thai. An unrelated one that knew how to handle some special font format ...
> 
> It uses keys to look up these 'instances' thereby creating caches that prevent GC.
> It was the cause of this bug report that font instances created from streams that were being used by layout aren't being deleted.
> There is also the implication there's some 'state' to the engines, when in fact the methods that
> invoke the native code are static methods and no state is relevant. Instances of the native engine are created and discarded as we need them in each layout call. There's minimal overhead to this, and whatever there is, we've been living with for a long time, and if we *were* re-using them we'd have overhead to ensure there was only one thread using it .. which we don't have and don't want.
> 
> So this PR deletes various interfaces and classes with LayoutEngine in the name, keeping only SunLayoutEngine, and making all its methods static - most already were.
> And fixes one very definite problem with the GCing of created fonts.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29680#pullrequestreview-3832243578

From aivanov at openjdk.org  Fri Feb 20 17:16:27 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 20 Feb 2026 17:16:27 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v5]
In-Reply-To: <81c7TYE-4y_68a-6NTNEnLaRfoDxtAQfRWQUFnpyy2U=.68042616-306d-4737-8fce-f1017fcaaf16@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <81c7TYE-4y_68a-6NTNEnLaRfoDxtAQfRWQUFnpyy2U=.68042616-306d-4737-8fce-f1017fcaaf16@github.com>
Message-ID: <UkEYK18gckCwNtf4ne9Nb9lMbMQCZa-oG8sybhROvkg=.b3076cf2-f533-4f9f-b018-c36d26d390e0@github.com>

On Fri, 20 Feb 2026 01:52:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
>> A new egression test for each of the constructor and getter/setter cases is supplied.
>> 
>> No existing regression tests fail with this change, and standard demos work.
>> 
>> Problems caused by these changes are most likely to occur if the client has a bug such that 
>> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
>> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
>> 
>> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
>> 
>> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377568

I haven't viewed all the files, my comments are applicable to most of the classes.

Some of the checks could be moved into more helper methods.

The constructors for the specific data types are updated, however, some checks could be performed in the super class, and likely the constructors of the super class, `DataBuffer` need also document that an exception could be thrown.

The `getElem` and `setElem` method in `DataBuffer` should specify an exception will occur if the parameters are invalid. Otherwise, it doesn't look right to me. All the specific implementations throw exception, but the super class doesn't specify them.

src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 544:

> 542:     }
> 543: 
> 544:     void checkIndex(int i) {

Should both `checkIndex(int i)` and `checkIndex(int bank, int i)` be declared as `final`? Neither is supposed to be overridden.

src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 545:

> 543: 
> 544:     void checkIndex(int i) {
> 545:         if ((i + offset) >= size) {

Is there ever a possibility for integer overflow? Should we care?

src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 554:

> 552:       if ((i + offsets[bank]) >= size) {
> 553:           throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
> 554:               "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);

Now, the `if` statement is indented by 2 spaces instead of 4.

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 93:

> 91:      * @param numBanks The number of banks in the {@code DataBuffer}.
> 92:      * @throws IllegalArgumentException if {@code size} is less than or equal to zero.
> 93:      *         or {@code numBanks} is less than one.

Suggestion:

     * @throws IllegalArgumentException if {@code size} is less than or equal to zero,
     *         or {@code numBanks} is less than one.

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 134:

> 132:         }
> 133:         if (size <= 0 || size > dataArray.length) {
> 134:             throw new IllegalArgumentException("Bad size : " + size);

Is there a reason for a space *before* the colon?

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 167:

> 165:             throw new NullPointerException("Null dataArray");
> 166:         }
> 167:         if (size <= 0 || (size + offset) > dataArray.length) {

Could it ever happen that `size + offset` overflows such that the condition becomes `false` and the parameters are accepted as valid?

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 193:

> 191:      * @throws IllegalArgumentException if {@code dataArray} does not have at least one bank.
> 192:      * @throws NullPointerException if any bank of {@code dataArray} is {@code null}.
> 193:      *         or {@code (offset + size)} is greater than the length of {@code dataArray}

Suggestion:

     * @throws IllegalArgumentException if {@code dataArray} does not have at least one bank.
     * @throws NullPointerException if any bank of {@code dataArray} is {@code null}.

It looks as if a copy-paste mistake as `(offset + size) > dataArray.length` doesn't apply.

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 195:

> 193:      *         or {@code (offset + size)} is greater than the length of {@code dataArray}
> 194:      * @throws IllegalArgumentException if the length of any bank of {@code dataArray}.
> 195:      *         is less than {@code size}.

Suggestion:

     * @throws IllegalArgumentException if the length of any bank of {@code dataArray}
     *         is less than {@code size}.

It's one sentence, isn't it?

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 244:

> 242:      * @throws IllegalArgumentException if {@code dataArray} does not have at least one bank.
> 243:      * @throws NullPointerException if {@code offsets} is {@code null}.
> 244:      * @throws ArrayIndexOutOfBoundsException if the lengths of {@code dataArray} and {@code offsets} differ.

The code throws `IllegalArgumentException` if `dataArray.length > offsets.length` instead of AIOOBE.

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 247:

> 245:      * @throws NullPointerException if any bank of {@code dataArray} is {@code null}.
> 246:      * @throws IllegalArgumentException if the length of any bank of {@code dataArray}.
> 247:      *         is less than ({@code size} + offsets[bankIndex]).

Suggestion:

     * @throws IllegalArgumentException if the length of any bank of {@code dataArray}
     *         is less than {@code (size + offsets[bankIndex])}.

src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 259:

> 257:         if (dataArray.length == 0) {
> 258:             throw new IllegalArgumentException("Must have at least one bank");
> 259:         }

The first three conditions are the same as in the constructor above. Are they worth moving into a static helper method?

src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 95:

> 93:         if (numBanks < 1) {
> 94:             throw new IllegalArgumentException("Must have at least one bank");
> 95:         }

Why can't these checks be performed in the super class, `DataBuffer`?

I see the same statements here, in `DataBufferDouble`, and in `DataBufferByte`:

https://github.com/prrace/jdk/blob/f17761b4b0ced616734825d486d6a3250c81c24e/src/java.desktop/share/classes/java/awt/image/DataBufferByte.java#L95-L102

src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 126:

> 124:         if (dataArray == null) {
> 125:             throw new NullPointerException("Null dataArray");
> 126:         }

Can we drop the explicit `null`-check? If the `dataArray` parameter is `null`, getting the length of the array in the following statement will result in NPE.

src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 129:

> 127:         if (size <= 0 || size > dataArray.length) {
> 128:             throw new IllegalArgumentException("Bad size : " + size);
> 129:         }

A static helper method `checkArraySize` would avoid duplicating validation of the `dataArray` size between different data types:


        checkArraySize(size, dataArray.length);


where


    static void checkArraySize(int size, int dataArrayLength) {
        if (size <= 0 || size > dataArrayLength) {
            throw new IllegalArgumentException("Bad size : " + size);
        }
    }


is in the `DataBuffer` class.

src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 332:

> 330:      */
> 331:     public int getElem(int i) {
> 332:         checkIndex(i);

Shouldn't the `DataBuffer.getElem` method also specify `@throws ArrayIndexOutOfBoundsException`?

src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 365:

> 363:      */
> 364:     public void setElem(int i, int val) {
> 365:         checkIndex(i);

Shouldn't the `DataBuffer.setElem` method also specify `@throws ArrayIndexOutOfBoundsException`?

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29766#pullrequestreview-3832237800
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834041275
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833935983
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833933747
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833671481
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833919036
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833944794
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833982271
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833984032
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834014142
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834016112
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834008457
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834060976
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834173709
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834162048
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834208733
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834212839

From aivanov at openjdk.org  Fri Feb 20 17:16:30 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 20 Feb 2026 17:16:30 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v3]
In-Reply-To: <LOGkg3i6RaMW0Y_vnK80bnB0MLx4TW86d9k27ryi5AA=.b5fc4357-827a-4e9a-9461-ecdcd5518487@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <vTYDoizYHGuQ2R5i0_E8UqZ9VxJJNR5HW8Q60zAtZMk=.3a9d1b2a-7ba8-4969-a9cb-85cc25b1846b@github.com>
 <llieCRvASoQ6arYPFBpBLQ6zZa6eUCatXl99leht3Ok=.b1b38b80-c13e-452f-adaa-e80791d5a120@github.com>
 <LOGkg3i6RaMW0Y_vnK80bnB0MLx4TW86d9k27ryi5AA=.b5fc4357-827a-4e9a-9461-ecdcd5518487@github.com>
Message-ID: <iPZynQ1oeGvAPY1fai_vkwCyVNb67Hr8_rysVwY5nXI=.b1f48f49-53cc-464d-8601-52342cfabff3@github.com>

On Tue, 17 Feb 2026 22:33:22 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't think I've ever used 8 for continuation.

Odd. Your original code in this code review used 8 spaces for continuation, it was like this in another PR too, but you also changed it to 4 spaces after I pointed out at the inconsistent indentation.

8 spaces for continuations is the most standard indentation?increasing from the regular 4 spaces signals it's a continuation line.

> there's a natural alignment that seems attractive.

I usually choose this option if it's viable, if such an alignment doesn't make the code harder to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2833394964

From dnguyen at openjdk.org  Fri Feb 20 19:51:55 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 20 Feb 2026 19:51:55 GMT
Subject: RFR: 8377924: Inconsistent parsing of XBM files after JDK-8361748
In-Reply-To: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
References: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
Message-ID: <iCzD852sQfamdHeh-5Nm1GToMAGp_t3f4aDf-6XpRw0=.6389a205-6496-4c29-b43f-89d52e1dcd50@github.com>

On Tue, 17 Feb 2026 21:41:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748 "Enforce limits on the size of an XBM image") and [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727 "New XBM images parser regression: only the first line of the bitmap array is parsed") changed how XBM files are parsed, and now some of the valid XBM images are parsed inconsistently. For example,
> 
> 
> #define ht 1
> #define th 8
> k[] = {0xAB}; 
> 
> 
> is parsed as image of size 1?8 instead of 8?1 after JDK-8361748.
> 
> The above problem is addressed by [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727). However, the code to differentiate between width and height differs from the original code that was used before [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748). Due to this difference,
> 
> 
> #define ht 1
> #define h 8 
> 
> 
> is rejected: Invalid values for width or height.
> 
> Previously, `-h` was a marker for width, and `-ht` was for height.
> 
> https://github.com/openjdk/jdk/blob/fc807d0914c4d8d2a174410a35acf3520ff4e60a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112
> 
> But [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727) uses `-th` for width and `-t` for height.
> 
> https://github.com/openjdk/jdk/blob/7f707ba8e746d859ac171d71ef8f731953a92e6a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L114-L118
> 
> For backward compatibility, we should revert to `-h` and `-ht`.

Looks like you're covering all the possible width/height combinations which is nice. Should we add one with just a bitmap line (no #define width/height lines at all)?

Reverting the width/height parsing to "ht" and "h" looks good to me.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29769#pullrequestreview-3833943359

From dnguyen at openjdk.org  Fri Feb 20 20:41:05 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 20 Feb 2026 20:41:05 GMT
Subject: RFR: 8377745: VoiceOver Identifies Hyperlink as Text [v2]
In-Reply-To: <vikiKuDi1QPsG_ovP_YQJqWZ7c4x2EEhbZ8f0tes4oU=.5a9705ac-4fd3-4efb-94bd-b8740c947195@github.com>
References: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
 <vikiKuDi1QPsG_ovP_YQJqWZ7c4x2EEhbZ8f0tes4oU=.5a9705ac-4fd3-4efb-94bd-b8740c947195@github.com>
Message-ID: <kPVaD6PhLk-LMEs1MKbfAIp2ssSaK8SG0LbhueA9ilc=.e3d8b93f-08dc-411d-be47-170ad24744f6@github.com>

On Fri, 13 Feb 2026 22:15:31 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> ~~If we use `new AccessibleRole("AXLink") {}`, then VoiceOver reads this more like other native apps.~~
>> 
>> ~~There isn't a similar precedent in CAccessibility for creating custom AccessibleRoles, so I won't mind if this PR is declined. (But I don't know off the top of my head where else to inject code to get the desired result...)~~
>> 
>> This introduces a new LinkAccessibility.m file to help VoiceOver and Accessibility Inspector correctly identify AccessibleRole.HYPERLINK as "link"
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8377745: creating new LinkAccessibility
>    
>    This helps convert from AccessibleRole.HYPERLINK to the new LinkAccessibility.
>    
>    The new LinkAccessible still references `CommonTextAccessibility<NSAccessibilityStaticText>`.
>    
>    This (both the subject matter and the programming language) is outside of my area of expertise, but the unit test passes.
>    
>    This is based on this feedback:
>    https://github.com/openjdk/jdk/pull/29686#issuecomment-3899448303
>  - Revert "8377745: use custom "AXLink" AccessibleRole"
>    
>    This reverts commit d66355973918458352d15174a2cf21a177763c23.

Looks like the test passes as expected. The link is actually identified as a link with the changes, when it is not without the changes. Tested looks good.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29686#pullrequestreview-3834120292

From prr at openjdk.org  Fri Feb 20 21:40:35 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 21:40:35 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v6]
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <ETztDJ7-uIeNUtY5iW13iAlMJxrmIq7JiO2lWjcop2A=.bab9225a-f65c-4660-b148-98027da19664@github.com>

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116

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

  8377568

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29766/files
  - new: https://git.openjdk.org/jdk/pull/29766/files/f17761b4..2685b305

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

  Stats: 441 lines in 8 files changed: 58 ins; 247 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/29766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29766/head:pull/29766

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

From prr at openjdk.org  Fri Feb 20 21:40:48 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 21:40:48 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v5]
In-Reply-To: <UkEYK18gckCwNtf4ne9Nb9lMbMQCZa-oG8sybhROvkg=.b3076cf2-f533-4f9f-b018-c36d26d390e0@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <81c7TYE-4y_68a-6NTNEnLaRfoDxtAQfRWQUFnpyy2U=.68042616-306d-4737-8fce-f1017fcaaf16@github.com>
 <UkEYK18gckCwNtf4ne9Nb9lMbMQCZa-oG8sybhROvkg=.b3076cf2-f533-4f9f-b018-c36d26d390e0@github.com>
Message-ID: <4b3Q6POk5CDvC7wDctDt9msHrhPKEOS4l_p1Tpm7w-E=.5463fe42-04cd-4a57-87b7-ba979b388ea3@github.com>

On Fri, 20 Feb 2026 16:29:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377568
>
> src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 544:
> 
>> 542:     }
>> 543: 
>> 544:     void checkIndex(int i) {
> 
> Should both `checkIndex(int i)` and `checkIndex(int bank, int i)` be declared as `final`? Neither is supposed to be overridden.

I don't see it as important but I can do that.

> src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 545:
> 
>> 543: 
>> 544:     void checkIndex(int i) {
>> 545:         if ((i + offset) >= size) {
> 
> Is there ever a possibility for integer overflow? Should we care?

I don't think it matters here.

> src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 554:
> 
>> 552:       if ((i + offsets[bank]) >= size) {
>> 553:           throw new ArrayIndexOutOfBoundsException("Invalid index (bankOffset+i) is " +
>> 554:               "(" + offsets[bank] + " + " + i + ") which is too large for size : " + size);
> 
> Now, the `if` statement is indented by 2 spaces instead of 4.

oops. fixing.

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 93:
> 
>> 91:      * @param numBanks The number of banks in the {@code DataBuffer}.
>> 92:      * @throws IllegalArgumentException if {@code size} is less than or equal to zero.
>> 93:      *         or {@code numBanks} is less than one.
> 
> Suggestion:
> 
>      * @throws IllegalArgumentException if {@code size} is less than or equal to zero,
>      *         or {@code numBanks} is less than one.

fixed.

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 134:
> 
>> 132:         }
>> 133:         if (size <= 0 || size > dataArray.length) {
>> 134:             throw new IllegalArgumentException("Bad size : " + size);
> 
> Is there a reason for a space *before* the colon?

just the way I think it looks cleaner.

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 167:
> 
>> 165:             throw new NullPointerException("Null dataArray");
>> 166:         }
>> 167:         if (size <= 0 || (size + offset) > dataArray.length) {
> 
> Could it ever happen that `size + offset` overflows such that the condition becomes `false` and the parameters are accepted as valid?

I've updated the code to check for that.

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 193:
> 
>> 191:      * @throws IllegalArgumentException if {@code dataArray} does not have at least one bank.
>> 192:      * @throws NullPointerException if any bank of {@code dataArray} is {@code null}.
>> 193:      *         or {@code (offset + size)} is greater than the length of {@code dataArray}
> 
> Suggestion:
> 
>      * @throws IllegalArgumentException if {@code dataArray} does not have at least one bank.
>      * @throws NullPointerException if any bank of {@code dataArray} is {@code null}.
> 
> It looks as if a copy-paste mistake as `(offset + size) > dataArray.length` doesn't apply.

fixed

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 195:
> 
>> 193:      *         or {@code (offset + size)} is greater than the length of {@code dataArray}
>> 194:      * @throws IllegalArgumentException if the length of any bank of {@code dataArray}.
>> 195:      *         is less than {@code size}.
> 
> Suggestion:
> 
>      * @throws IllegalArgumentException if the length of any bank of {@code dataArray}
>      *         is less than {@code size}.
> 
> It's one sentence, isn't it?

removed stray "."

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 244:
> 
>> 242:      * @throws IllegalArgumentException if {@code dataArray} does not have at least one bank.
>> 243:      * @throws NullPointerException if {@code offsets} is {@code null}.
>> 244:      * @throws ArrayIndexOutOfBoundsException if the lengths of {@code dataArray} and {@code offsets} differ.
> 
> The code throws `IllegalArgumentException` if `dataArray.length > offsets.length` instead of AIOOBE.

It should be AIIOBE. This is the one case I see where a DataBuffer superclass constructor declares and even throws exception and it said AIIOBE so I decided no reason to change that.

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 247:
> 
>> 245:      * @throws NullPointerException if any bank of {@code dataArray} is {@code null}.
>> 246:      * @throws IllegalArgumentException if the length of any bank of {@code dataArray}.
>> 247:      *         is less than ({@code size} + offsets[bankIndex]).
> 
> Suggestion:
> 
>      * @throws IllegalArgumentException if the length of any bank of {@code dataArray}
>      *         is less than {@code (size + offsets[bankIndex])}.

fixed

> src/java.desktop/share/classes/java/awt/image/DataBufferByte.java line 259:
> 
>> 257:         if (dataArray.length == 0) {
>> 258:             throw new IllegalArgumentException("Must have at least one bank");
>> 259:         }
> 
> The first three conditions are the same as in the constructor above. Are they worth moving into a static helper method?

I've updated all these subclass constructors to use static helpers as much as possible.

> src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 95:
> 
>> 93:         if (numBanks < 1) {
>> 94:             throw new IllegalArgumentException("Must have at least one bank");
>> 95:         }
> 
> Why can't these checks be performed in the super class, `DataBuffer`?
> 
> I see the same statements here, in `DataBufferDouble`, and in `DataBufferByte`:
> 
> https://github.com/prrace/jdk/blob/f17761b4b0ced616734825d486d6a3250c81c24e/src/java.desktop/share/classes/java/awt/image/DataBufferByte.java#L95-L102

I could but I don't think there is much to be gained by it. More trouble than it is worth
Not all checks can be moved there and here I have the checks in the same place the RTE is declared and thrown.
Also I'd have to update that spec as well as this one. And javadoc doesn't inherit RTE so they will have to be here anyway .. so all you get is a few shared lines .. especially since I've now created utility methods.

> src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 126:
> 
>> 124:         if (dataArray == null) {
>> 125:             throw new NullPointerException("Null dataArray");
>> 126:         }
> 
> Can we drop the explicit `null`-check? If the `dataArray` parameter is `null`, getting the length of the array in the following statement will result in NPE.

I prefer to keep it so I can give a meaningful exception message. As well as being explicit.

> src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 129:
> 
>> 127:         if (size <= 0 || size > dataArray.length) {
>> 128:             throw new IllegalArgumentException("Bad size : " + size);
>> 129:         }
> 
> A static helper method `checkArraySize` would avoid duplicating validation of the `dataArray` size between different data types:
> 
> 
>         checkArraySize(size, dataArray.length);
> 
> 
> where
> 
> 
>     static void checkArraySize(int size, int dataArrayLength) {
>         if (size <= 0 || size > dataArrayLength) {
>             throw new IllegalArgumentException("Bad size : " + size);
>         }
>     }
> 
> 
> is in the `DataBuffer` class.

I added static helpers.

> src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 332:
> 
>> 330:      */
>> 331:     public int getElem(int i) {
>> 332:         checkIndex(i);
> 
> Shouldn't the `DataBuffer.getElem` method also specify `@throws ArrayIndexOutOfBoundsException`?

I don't see a need to touch the super-class spec. The method there doesn't actually throw anything.
It just calls the abstract method getElem(int, int). So it is all down to the subclasses.

> src/java.desktop/share/classes/java/awt/image/DataBufferDouble.java line 365:
> 
>> 363:      */
>> 364:     public void setElem(int i, int val) {
>> 365:         checkIndex(i);
> 
> Shouldn't the `DataBuffer.setElem` method also specify `@throws ArrayIndexOutOfBoundsException`?

As mentioned above, this is an abstract method. I didn't see a need to touch it to declare a RTE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834894590
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834898507
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834899042
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834906756
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834908941
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834911555
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834932087
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834918421
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2835166664
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834936740
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834939109
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2835184416
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834952287
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834950397
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834946782
PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834949276

From prr at openjdk.org  Fri Feb 20 21:40:50 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 21:40:50 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v3]
In-Reply-To: <iPZynQ1oeGvAPY1fai_vkwCyVNb67Hr8_rysVwY5nXI=.b1f48f49-53cc-464d-8601-52342cfabff3@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <vTYDoizYHGuQ2R5i0_E8UqZ9VxJJNR5HW8Q60zAtZMk=.3a9d1b2a-7ba8-4969-a9cb-85cc25b1846b@github.com>
 <llieCRvASoQ6arYPFBpBLQ6zZa6eUCatXl99leht3Ok=.b1b38b80-c13e-452f-adaa-e80791d5a120@github.com>
 <LOGkg3i6RaMW0Y_vnK80bnB0MLx4TW86d9k27ryi5AA=.b5fc4357-827a-4e9a-9461-ecdcd5518487@github.com>
 <iPZynQ1oeGvAPY1fai_vkwCyVNb67Hr8_rysVwY5nXI=.b1f48f49-53cc-464d-8601-52342cfabff3@github.com>
Message-ID: <hueLTQxNOP4a2zI8DFM8Wrs-N5jPHpDm3dWy2ezgpUw=.a3b66e47-1022-40fe-9f99-2630b7fb0c75@github.com>

On Fri, 20 Feb 2026 14:13:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> They are (now) consistently 4. I don't think I've ever used 8 for continuation.
>> I use 4 (more) unless there's a natural alignment that seems attractive.
>
>> I don't think I've ever used 8 for continuation.
> 
> Odd. Your original code in this code review used 8 spaces for continuation, it was like this in another PR too, but you also changed it to 4 spaces after I pointed out at the inconsistent indentation.
> 
> 8 spaces for continuations is the most standard indentation?increasing from the regular 4 spaces signals it's a continuation line.
> 
>> there's a natural alignment that seems attractive.
> 
> I usually choose this option if it's viable, if such an alignment doesn't make the code harder to read.

So I think I've fixed indentation now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2834901054

From prr at openjdk.org  Fri Feb 20 22:18:09 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 20 Feb 2026 22:18:09 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v7]
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <OLFnr21zToRn9AdP1IZB1e5HZl-9PTWirAy4X-WeM_o=.9ff3bd33-69c9-4ff9-b359-d107fd476866@github.com>

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116

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

  8377568

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29766/files
  - new: https://git.openjdk.org/jdk/pull/29766/files/2685b305..587b6a7e

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

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

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

From kizune at openjdk.org  Fri Feb 20 22:21:04 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 20 Feb 2026 22:21:04 GMT
Subject: RFR: 8378296: Remove AppContext from java.awt.event.FocusEvent
In-Reply-To: <H9Vv_-t2x9oz_Bdxyqo5SH4q5u2ugHBXgbKn_LDpNRU=.01552d56-ba28-4912-b49a-7ffb75d37029@github.com>
References: <H9Vv_-t2x9oz_Bdxyqo5SH4q5u2ugHBXgbKn_LDpNRU=.01552d56-ba28-4912-b49a-7ffb75d37029@github.com>
Message-ID: <a8kx5chQgCTwO6nT5g-8bssH3guYripCUkm4unxUhYU=.298b6fae-430f-47b7-88ab-c6ce1d0420e1@github.com>

On Thu, 19 Feb 2026 23:13:21 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from java.awt.event.FocusEvent

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29829#pullrequestreview-3834453986

From kizune at openjdk.org  Fri Feb 20 22:26:57 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 20 Feb 2026 22:26:57 GMT
Subject: RFR: 8377938: VoiceOver Uses Mouse to Activate JButtons in German
In-Reply-To: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
References: <zesXWB2qdSSAZ8-MSvw6cvAM-tj2w4k-fVbeXbMQLQs=.eca2e348-80c4-4456-b05e-91dd75186f3e@github.com>
Message-ID: <AKPvzIZvdqXvI-y7yQ4fOFhm1AeGVxipBQW8cVo98Rw=.926cf3a2-9c2f-4c98-b845-3396550b6d76@github.com>

On Sat, 14 Feb 2026 23:47:10 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> Previously:
> The action description would be localized text. So in German's case `getAccessibleActionDescription(0)` would return `Klicken`. As that String is passed upwards towards VoiceOver, we're counting on VoiceOver's code interpreting it correctly.
> 
> With this PR:
> We always return "click" (using the AccessibleAction.CLICK constant). VoiceOver knows how to interpret an unlocalized "click".
> 
> ## Context
> 
> I looked up references to other AccessibleAction constants:
> 
> - AccessibleAction.TOGGLE_EXPAND is referenced in JTree.java's `getAccessibleActionDescription` method.
> - AccessibleAction.INCREMENT and AccessibleAction.DECREMENT are referenced in JSlider's and JSpinner's `getAccessibleActionDescription` method.
> - AccessibleAction.CLICK and AccessibleAction.TOGGLE_POPUP are NOT currently referenced (prior to this PR)
> 
> The javadoc for `getAccessibleActionDescription` simply describes the return value as "a String description of the action". It makes no comment on whether it should be localized or not.
> 
> JList.java is similar to AbstractButton:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("AbstractButton.clickText");
>     } else {
>         return null;
>     }
> }
> 
> 
> JComboBox.java includes:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         return UIManager.getString("ComboBox.togglePopupText");
>     }
>     else {
>         return null;
>     }
> }
> 
> 
> I'd argue that we need to be consistent: either JTree/JSlider/JSpinner should be modified to return a localized action description, OR AbstractButton/JList/JComboBox should be modified to return the unlocalized constant.
> 
> My preference is to modify AbstractButton and JList (as shown in this PR). (And I'd recommend addressing JComboBox in a separate PR.)
> 
> (Also, I really like JTextComponent.java's implementation that combined Swing's ActionMap with AccessibleActions:
> 
> public String getAccessibleActionDescription(int i) {
>     Action [] actions = JTextComponent.this.getActions();
>     if (i < 0 || i >= actions.length) {
>         return null;
>     }
>     return (String)actions[i].getValue(Action.NAME);
> }
> 
> ... but that's straying pretty far from the original ticket.)
> 
> ## Non-Swing Context
> 
> I also searched for `getAccessibleActionDescription` in general.
> 
> In Button.java and MenuItem.java we have:
> 
> public String getAccessibleActionDescription(int i) {
>     if (i == 0) {
>         // [[[PENDING:  WDW -- need to provide a localized string]]]
>         retur...

Well, first is to understand why VO does not trigger the correct action directly. VO does not invoke the Java accessibility API directly, instead it calls to the button's native accessibility peer and if that does not work we need to understand why - probably the platform specific code needs to be updated.

As for the consistency - i think the description has to be localized for all the components. Not sure why it does not.

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

PR Comment: https://git.openjdk.org/jdk/pull/29727#issuecomment-3937439049

From serb at openjdk.org  Sat Feb 21 00:17:05 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Feb 2026 00:17:05 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <EVYg-KsdTwAhuhj6xGYs1Qg7V3zD6qRYnlDZ0bEMlCU=.3bd2d97a-a333-4aa7-9283-80750f79abdd@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
 <EVYg-KsdTwAhuhj6xGYs1Qg7V3zD6qRYnlDZ0bEMlCU=.3bd2d97a-a333-4aa7-9283-80750f79abdd@github.com>
Message-ID: <BKqWwrLwxW1abtgiW0OOi9GBRvQIm5T30YPRXqnAWuM=.c0a45a2b-26a2-484a-a60e-489771f95913@github.com>

On Wed, 18 Feb 2026 07:47:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>So, how can we decide? we can either close this as "Wont Fix" or fix as per this PR as it is not causing any regression

You could also do some research into how this API is actually used. Since you already started changing that method, I assume you have an idea why the method parameter should be used instead of the fields, as suggested by this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3937733949

From serb at openjdk.org  Sat Feb 21 00:20:03 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Feb 2026 00:20:03 GMT
Subject: RFR: 8378202: Remove AppContext from XAWT classes
In-Reply-To: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
References: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
Message-ID: <i2g7MW3un-Ze1GMUct3s60X7K_sedNYTHhwQAfoRtQs=.0427f050-adf3-424d-92cb-42bea2827ccd@github.com>

On Wed, 18 Feb 2026 22:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from XAWT.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29804#pullrequestreview-3834695077

From serb at openjdk.org  Sat Feb 21 00:20:03 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Feb 2026 00:20:03 GMT
Subject: RFR: 8378205: Remove AppContext from Swing MenuComponent
In-Reply-To: <nT5VY9x1BoJJXs-vko9-Y-iAWGmmJEaPSIkiZK7AsHE=.419bc238-6250-40c2-b55a-99e06b213fa8@github.com>
References: <nT5VY9x1BoJJXs-vko9-Y-iAWGmmJEaPSIkiZK7AsHE=.419bc238-6250-40c2-b55a-99e06b213fa8@github.com>
Message-ID: <n1TETkOi6od0f2c6m7phk-gRq6zJb-HJCCJmqtoMYcc=.e694ebc5-f043-4b15-b75b-b071f97c1e39@github.com>

On Wed, 18 Feb 2026 23:12:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from Swing MenuComponent

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29807#pullrequestreview-3834696047

From serb at openjdk.org  Sat Feb 21 00:21:01 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Feb 2026 00:21:01 GMT
Subject: RFR: 8378296: Remove AppContext from java.awt.event.FocusEvent
In-Reply-To: <H9Vv_-t2x9oz_Bdxyqo5SH4q5u2ugHBXgbKn_LDpNRU=.01552d56-ba28-4912-b49a-7ffb75d37029@github.com>
References: <H9Vv_-t2x9oz_Bdxyqo5SH4q5u2ugHBXgbKn_LDpNRU=.01552d56-ba28-4912-b49a-7ffb75d37029@github.com>
Message-ID: <2ZDeVRlVWu1P2gB2lZoU19dkR1U-IF1TCzThBdPkg7Q=.a89d305d-aec2-4615-83c1-ad30fa6900a4@github.com>

On Thu, 19 Feb 2026 23:13:21 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from java.awt.event.FocusEvent

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29829#pullrequestreview-3834696551

From prr at openjdk.org  Sat Feb 21 04:16:20 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:16:20 GMT
Subject: Integrated: 8378205: Remove AppContext from Swing MenuComponent
In-Reply-To: <nT5VY9x1BoJJXs-vko9-Y-iAWGmmJEaPSIkiZK7AsHE=.419bc238-6250-40c2-b55a-99e06b213fa8@github.com>
References: <nT5VY9x1BoJJXs-vko9-Y-iAWGmmJEaPSIkiZK7AsHE=.419bc238-6250-40c2-b55a-99e06b213fa8@github.com>
Message-ID: <qZ8jnspXtiEAbaewfwZR-DNEtQpp9iz2oeqC2DIQia0=.cbb92375-8751-4390-8a03-97bb3f76ef9e@github.com>

On Wed, 18 Feb 2026 23:12:48 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from Swing MenuComponent

This pull request has now been integrated.

Changeset: facbcaf0
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/facbcaf06af2c94d319b32da99d2cc4ff69408f1
Stats:     35 lines in 3 files changed: 0 ins; 33 del; 2 mod

8378205: Remove AppContext from Swing MenuComponent

Reviewed-by: kizune, serb

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

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

From prr at openjdk.org  Sat Feb 21 04:17:18 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:17:18 GMT
Subject: Integrated: 8378296: Remove AppContext from java.awt.event.FocusEvent
In-Reply-To: <H9Vv_-t2x9oz_Bdxyqo5SH4q5u2ugHBXgbKn_LDpNRU=.01552d56-ba28-4912-b49a-7ffb75d37029@github.com>
References: <H9Vv_-t2x9oz_Bdxyqo5SH4q5u2ugHBXgbKn_LDpNRU=.01552d56-ba28-4912-b49a-7ffb75d37029@github.com>
Message-ID: <_y90ARcnWuKFQymvrRBVCmM4rw7BFTaFn9T8rhlIKIg=.71d7bd1f-dda7-43ad-8d09-63134f5207f7@github.com>

On Thu, 19 Feb 2026 23:13:21 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from java.awt.event.FocusEvent

This pull request has now been integrated.

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

8378296: Remove AppContext from java.awt.event.FocusEvent

Reviewed-by: kizune, serb

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

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

From prr at openjdk.org  Sat Feb 21 04:22:10 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:22:10 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation
In-Reply-To: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
Message-ID: <t1LRPjZ4_SUPAvYvxE6IWL6BOJe_QUDKplr2dZgGi8k=.eda1a652-754c-4bc1-abf1-1bbd283acee7@github.com>

On Sat, 14 Feb 2026 16:13:27 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
> 
> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
> 
> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
> 
> Tested on mac, Linux and Windows:
> - make test TEST="jtreg:test/jdk/java/awt/font"
> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"

@prsadhuk we need a 2nd reviewer here.

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

PR Comment: https://git.openjdk.org/jdk/pull/29726#issuecomment-3938133098

From prr at openjdk.org  Sat Feb 21 04:24:10 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:24:10 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v2]
In-Reply-To: <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
Message-ID: <1wo78mmh7PfDNXe4OuaKdMz3sF3eSq480PukNlurK2k=.2c6e986f-0ba7-4f37-89c9-a140c49a2b23@github.com>

On Mon, 16 Feb 2026 06:54:08 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

Marked as reviewed by prr (Reviewer).

@prsadhukneed you to be the 2nd reviewer here

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

PR Review: https://git.openjdk.org/jdk/pull/29733#pullrequestreview-3835025330
PR Comment: https://git.openjdk.org/jdk/pull/29733#issuecomment-3938134195

From prr at openjdk.org  Sat Feb 21 04:25:08 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:25:08 GMT
Subject: RFR: 8337853: Remove SunLayoutEngineKey and SunLayoutEngineFactory
 and its cache.
In-Reply-To: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
References: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
Message-ID: <Fi5u8YFMhbZSGTeURq5BCGswaHgXC8Mp3V6IPWxY8qo=.611af28e-2e95-4f6a-9387-1fcc7c9e777b@github.com>

On Wed, 11 Feb 2026 20:42:50 GMT, Phil Race <prr at openjdk.org> wrote:

> For a long time I've looked at the unnecessary complexity around the code that manages "LayoutEngines' for OpenType font layout.
> 
> The code was written a very long time ago when it was supposed that you might have a layout engine that could do Arabic. An unrelated one for Devanagari. An unrelated one for Thai. An unrelated one that knew how to handle some special font format ...
> 
> It uses keys to look up these 'instances' thereby creating caches that prevent GC.
> It was the cause of this bug report that font instances created from streams that were being used by layout aren't being deleted.
> There is also the implication there's some 'state' to the engines, when in fact the methods that
> invoke the native code are static methods and no state is relevant. Instances of the native engine are created and discarded as we need them in each layout call. There's minimal overhead to this, and whatever there is, we've been living with for a long time, and if we *were* re-using them we'd have overhead to ensure there was only one thread using it .. which we don't have and don't want.
> 
> So this PR deletes various interfaces and classes with LayoutEngine in the name, keeping only SunLayoutEngine, and making all its methods static - most already were.
> And fixes one very definite problem with the GCing of created fonts.

@prsadhuk need you to review this one

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

PR Comment: https://git.openjdk.org/jdk/pull/29680#issuecomment-3938135965

From prr at openjdk.org  Sat Feb 21 04:26:11 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:26:11 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
Message-ID: <icx7BT-3A6HVkfqKDverbXVKSI7i9OqvH-5s1d1iKuY=.d6ab1236-aa9c-4994-944d-834102761d3b@github.com>

On Thu, 19 Feb 2026 20:04:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
>> 
>> With this PR, I'm contributing the test to OpenJDK.
>> 
>> Without the fix for JDK-8297191, the test fails with the following error messages:
>> 
>> <details>
>> <summary>test log</summary>
>> 
>> 
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
>> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> 	at PageRangesAuto.main(PageRangesAuto.java:146)
>> 
>> </details>
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the first page of the rage in the filename

@prsadhuk need you to review this one

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

PR Comment: https://git.openjdk.org/jdk/pull/29660#issuecomment-3938136409

From prr at openjdk.org  Sat Feb 21 04:28:10 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:28:10 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F
In-Reply-To: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
Message-ID: <lEngHLSETDiS84HsqgqWjE0kIfeY8gYUVQkprqRI2ec=.42bf20f0-9822-4c6d-afde-6e003af00aef@github.com>

On Thu, 19 Feb 2026 02:52:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
> 
> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
> 
> Without fix
> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
> 
> With fix
> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />

@TejeshR13 @DamonGuy please review

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

PR Comment: https://git.openjdk.org/jdk/pull/29808#issuecomment-3938139102

From prr at openjdk.org  Sat Feb 21 04:29:09 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:29:09 GMT
Subject: RFR: 8378202: Remove AppContext from XAWT classes
In-Reply-To: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
References: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
Message-ID: <LWaXdnu7_zsObEOxjIQBB40QmETgKoZDXGCjXpgbAWQ=.cdb908ef-7c2d-46eb-b374-107dc12720fc@github.com>

On Wed, 18 Feb 2026 22:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from XAWT.

@azvegint need a 2nd reviewer

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

PR Comment: https://git.openjdk.org/jdk/pull/29804#issuecomment-3938139949

From prr at openjdk.org  Sat Feb 21 04:29:10 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:29:10 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes
In-Reply-To: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
Message-ID: <Et8HiaX2Uc6na7mqCpJePsYAITgicE59LFdkWmiersI=.2ef6a296-33cc-4880-ac96-4fbc7a41dbd1@github.com>

On Thu, 19 Feb 2026 23:20:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
> 
> One ToolTipManager test for the AppContext is removed.

@prsadhuk @DamonGuy please review

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

PR Comment: https://git.openjdk.org/jdk/pull/29830#issuecomment-3938139533

From prr at openjdk.org  Sat Feb 21 04:39:13 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:39:13 GMT
Subject: RFR: 8377924: Inconsistent parsing of XBM files after JDK-8361748
In-Reply-To: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
References: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
Message-ID: <tWAuSl8BLVnOB2OYw9nnn5U7amDXVtsMS1YV4rcob7A=.d58b5df6-8e48-40cb-a898-5f6f77f0dc58@github.com>

On Tue, 17 Feb 2026 21:41:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748 "Enforce limits on the size of an XBM image") and [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727 "New XBM images parser regression: only the first line of the bitmap array is parsed") changed how XBM files are parsed, and now some of the valid XBM images are parsed inconsistently. For example,
> 
> 
> #define ht 1
> #define th 8
> k[] = {0xAB}; 
> 
> 
> is parsed as image of size 1?8 instead of 8?1 after JDK-8361748.
> 
> The above problem is addressed by [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727). However, the code to differentiate between width and height differs from the original code that was used before [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748). Due to this difference,
> 
> 
> #define ht 1
> #define h 8 
> 
> 
> is rejected: Invalid values for width or height.
> 
> Previously, `-h` was a marker for width, and `-ht` was for height.
> 
> https://github.com/openjdk/jdk/blob/fc807d0914c4d8d2a174410a35acf3520ff4e60a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112
> 
> But [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727) uses `-th` for width and `-t` for height.
> 
> https://github.com/openjdk/jdk/blob/7f707ba8e746d859ac171d71ef8f731953a92e6a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L114-L118
> 
> For backward compatibility, we should revert to `-h` and `-ht`.

xbm is so sloppy

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29769#pullrequestreview-3835038419

From prr at openjdk.org  Sat Feb 21 04:53:34 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 04:53:34 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane
Message-ID: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>

Remove AppContext from JEditorPane

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

Commit messages:
 - 8378377

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

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

From prr at openjdk.org  Sat Feb 21 05:03:10 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 05:03:10 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane
In-Reply-To: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
Message-ID: <spXboJdmmWkWIuU-h3fVOX8DgOlbhCSoo8ZPP58vA5k=.54a86e6e-893b-42d8-9911-0d4a1af3368a@github.com>

On Sat, 21 Feb 2026 04:47:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from JEditorPane

@prsadhuk @DamonGuy please review

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

PR Comment: https://git.openjdk.org/jdk/pull/29855#issuecomment-3938177987

From prr at openjdk.org  Sat Feb 21 05:06:09 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 05:06:09 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v3]
In-Reply-To: <A79vWzS2GvQ_ZFCiRjKRRe74kgZw6mvW1hN7PXLIMMo=.7b292b50-d464-424b-81aa-235d83686057@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
 <HRobHdhbpaCzxUYEXer53Qq2tgaejqvnZHgv2CfQMZg=.1ec9e358-a0c9-44d8-acab-c475dda68da6@github.com>
 <5zsD6woqsilZcxJ1QYJFjCEIrU7imrOr_YpJzpN3caA=.f1aa3135-5cfa-48a6-b72c-d13343dc3f55@github.com>
 <A79vWzS2GvQ_ZFCiRjKRRe74kgZw6mvW1hN7PXLIMMo=.7b292b50-d464-424b-81aa-235d83686057@github.com>
Message-ID: <BgWjXRBdsHwqQVwU21-bVPIEbgcXglvBfeAtPmaWUxE=.1f68e94b-dc86-496d-b414-cc8306952ad6@github.com>

On Fri, 20 Feb 2026 08:59:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 532:
>> 
>>> 530:             int[][] members = range.getMembers();
>>> 531:             jobAttributes.setPageRanges(members);
>>> 532:         }
>> 
>> Hmm. This seems a very odd thing to include in this PR. It it is unrelated.
>>  I don't think it should be here and we've managed for 20 years without this null check, so why now ?
>> 
>> Is it a regression caused by https://github.com/openjdk/jdk/pull/29312/ ?
>
> Yes, it seems so..Clicking "All" will result in NPE so resolved that here..

This needs to be in a separate bug. If someone wants to back port that other fix and then finds the NPE, I'm quite sure they don't want to back port a Swing fix to get the portion of it that includes the printing fix.
How did we miss this in the other fix ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29752#discussion_r2835838508

From prr at openjdk.org  Sat Feb 21 07:18:58 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 07:18:58 GMT
Subject: RFR: 8378197: Remove AppContext from
 sun/swing/plaf/DesktopProperty.java [v2]
In-Reply-To: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
References: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
Message-ID: <ZbI7yL6VT9uSWLYNZBBSHCpg6SYTsGNTATaArFUP2FI=.020f33b1-9492-4a21-9c45-227b2edc09b3@github.com>

> A straightforward removal of a per-AppContext flag which can now be static

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

  8378197

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29801/files
  - new: https://git.openjdk.org/jdk/pull/29801/files/b404e83e..5daf3547

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

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

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

From prr at openjdk.org  Sat Feb 21 07:19:01 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 07:19:01 GMT
Subject: RFR: 8378197: Remove AppContext from
 sun/swing/plaf/DesktopProperty.java [v2]
In-Reply-To: <C8PZXxY60EyHn8L8LXLXlne-kq9kFoaV-A3qFFFDzMI=.85f52223-a37b-4801-be58-dbd8cbe04d3c@github.com>
References: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
 <C8PZXxY60EyHn8L8LXLXlne-kq9kFoaV-A3qFFFDzMI=.85f52223-a37b-4801-be58-dbd8cbe04d3c@github.com>
Message-ID: <ZgDgA-pw7cCeoi7UG9JTQgXHRunKFZ9kAvX4o9SdH_Q=.758bee4a-d245-409c-b748-bf0085cc337f@github.com>

On Thu, 19 Feb 2026 23:08:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378197
>
> src/java.desktop/share/classes/sun/swing/plaf/DesktopProperty.java line 98:
> 
>> 96:      */
>> 97:     private static synchronized void setUpdatePending(boolean update) {
>> 98:         updatePending = update;
> 
> It seems the synchronized accessors are no longer needed? And the field itself marked as volatile can be used instead, since both of these methods are called from just the updateUI() method?

updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29801#discussion_r2835932183

From aivanov at openjdk.org  Sat Feb 21 11:58:09 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 21 Feb 2026 11:58:09 GMT
Subject: RFR: 8377924: Inconsistent parsing of XBM files after JDK-8361748
In-Reply-To: <iCzD852sQfamdHeh-5Nm1GToMAGp_t3f4aDf-6XpRw0=.6389a205-6496-4c29-b43f-89d52e1dcd50@github.com>
References: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
 <iCzD852sQfamdHeh-5Nm1GToMAGp_t3f4aDf-6XpRw0=.6389a205-6496-4c29-b43f-89d52e1dcd50@github.com>
Message-ID: <a2aVR4u_6eR2aySq9lXgRQX0co1riQnvy-b3cyAYItE=.f336a74c-b464-456f-bf4e-2f52c990b656@github.com>

On Fri, 20 Feb 2026 19:49:08 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Should we add one with just a bitmap line (no #define lines at all)?

If the file doesn't start with `#define`, the image isn't loaded at all, the decoder isn't invoked.

I'm thinking about covering other scenarios. It would be good to have a comprehensive coverage of all the branches in the decoder.

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

PR Comment: https://git.openjdk.org/jdk/pull/29769#issuecomment-3938668295

From thomas at devoogdt.com  Sat Feb 21 15:37:30 2026
From: thomas at devoogdt.com (Thomas Devoogdt)
Date: Sat, 21 Feb 2026 16:37:30 +0100
Subject: Fixing compilation on older GCC6 toolchains.
Message-ID: <CACXRmJhK=gTuLB3cV+WwWKc52vhacZFZFW4T+9hkWTT=tFnp=w@mail.gmail.com>

Hi all,


I'm busy with bringing JDK25 support to Buildroot and had to fix a few
things. Which I bundled in this pull request:
https://github.com/openjdk/jdk/pull/29856. Beware that I can't create
an issue for this, so someone will have to step in.


Kind regards,

Thomas Devoogdt

From prr at openjdk.org  Sat Feb 21 20:34:19 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 20:34:19 GMT
Subject: RFR: 8378385: Remove AppContext from AWT Windows implementation
 classes
Message-ID: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>

Remove most uses of AppContext from Windows AWT classes.
No existing tests fail with this change.

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

Commit messages:
 - 8378385

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

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

From prr at openjdk.org  Sat Feb 21 20:39:11 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 20:39:11 GMT
Subject: RFR: 8378386: Remove AppContext from AWT ModalEventFilter.java
Message-ID: <fObg-UJKZJhnWUFIO6dQ-6flRUSWSy_A_dUSN7fIC_I=.b66ec145-014e-4079-ac4e-1d97f5b04938@github.com>

Remove AppContext from java/awt/ModalEventFilter.java

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

Commit messages:
 - 8378386

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

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

From prr at openjdk.org  Sat Feb 21 20:43:19 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 21 Feb 2026 20:43:19 GMT
Subject: RFR: 8378387: Remove AppContext from several macOS AWT classes
Message-ID: <hiSGCYboiSxd9IrLtN_RTbq2X4UDZckWv5Ma9UaK7E0=.723817db-d4a3-43a4-98f3-1e736d65005e@github.com>

Remove AppContext from several LAWT classes.

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

Commit messages:
 - 8378387

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

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

From serb at openjdk.org  Sat Feb 21 23:45:09 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 21 Feb 2026 23:45:09 GMT
Subject: RFR: 8378197: Remove AppContext from
 sun/swing/plaf/DesktopProperty.java [v2]
In-Reply-To: <ZbI7yL6VT9uSWLYNZBBSHCpg6SYTsGNTATaArFUP2FI=.020f33b1-9492-4a21-9c45-227b2edc09b3@github.com>
References: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
 <ZbI7yL6VT9uSWLYNZBBSHCpg6SYTsGNTATaArFUP2FI=.020f33b1-9492-4a21-9c45-227b2edc09b3@github.com>
Message-ID: <JfEPXnQr-jCkhrX1A4k0KA6uPcwLT8ICiwx359af7Yw=.61cb7106-81af-438f-8476-813ccc96a49d@github.com>

On Sat, 21 Feb 2026 07:18:58 GMT, Phil Race <prr at openjdk.org> wrote:

>> A straightforward removal of a per-AppContext flag which can now be static
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378197

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29801#pullrequestreview-3836230130

From serb at openjdk.org  Sun Feb 22 00:15:18 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Feb 2026 00:15:18 GMT
Subject: Integrated: 8378153: Robot.getPixelColor() may return stale pixels due
 to missing Toolkit.sync()
In-Reply-To: <fzKmq08t4pxg-FdtZcN5EdKUU7IfH6g76Q0yVp43XzU=.1dd383ef-f88f-4786-944b-1be9d3ace77d@github.com>
References: <fzKmq08t4pxg-FdtZcN5EdKUU7IfH6g76Q0yVp43XzU=.1dd383ef-f88f-4786-944b-1be9d3ace77d@github.com>
Message-ID: <gIwlfntaqhLwji_bN5rtEC758FM6qJIZTF4iYuhyPoY=.d296bffa-2723-484a-9c82-ea5e3de7b14d@github.com>

On Wed, 18 Feb 2026 08:24:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Robot.getPixelColor() does not call Toolkit.getDefaultToolkit().sync() before reading the pixel, unlike Robot.createScreenCapture() which has had this call since [JDK-6725214](https://bugs.openjdk.org/browse/JDK-6725214).
> 
> When a hardware-accelerated pipeline (OGL, D3D, Metal) is active, rendering may be buffered and not yet flushed to the screen when getPixelColor() reads the pixel. This causes it to return stale values typically the window background color instead of the rendered content.

This pull request has now been integrated.

Changeset: 497dca25
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/497dca2549a9829530670576115bf4b8fab386b3
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8378153: Robot.getPixelColor() may return stale pixels due to missing Toolkit.sync()

Reviewed-by: prr, azvegint

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

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

From duke at openjdk.org  Sun Feb 22 00:33:10 2026
From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac)
Date: Sun, 22 Feb 2026 00:33:10 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v2]
In-Reply-To: <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
Message-ID: <ZNK5fE14VqrWZPK4tE-ElXnPNhzPYFCXSWTeZhUGljQ=.b4f5809a-111e-4cfb-a683-4e4837c88b6a@github.com>

On Mon, 16 Feb 2026 06:54:08 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year

src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 1614:

> 1612: 
> 1613:         } catch (Throwable printError) {
> 1614:             if (printError instanceof PrinterException) {

Suggestion:

        } catch (PrinterException e) {
            throw e;
        } catch (Throwable printError) {
            throw (PrinterException)
                    new PrinterException().initCause(printError.getCause());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29733#discussion_r2836881012

From serb at openjdk.org  Sun Feb 22 00:45:10 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Feb 2026 00:45:10 GMT
Subject: RFR: 8378385: Remove AppContext from AWT Windows implementation
 classes
In-Reply-To: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
References: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
Message-ID: <m_YhthGKNQ8t0B_x_6-VvxumK7jAZr9nPeyiinJ5qeY=.e5e553f0-154e-499b-bebb-95fcd5822e27@github.com>

On Sat, 21 Feb 2026 20:27:45 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove most uses of AppContext from Windows AWT classes.
> No existing tests fail with this change.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29858#pullrequestreview-3836301866

From prr at openjdk.org  Sun Feb 22 00:48:31 2026
From: prr at openjdk.org (Phil Race)
Date: Sun, 22 Feb 2026 00:48:31 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager
Message-ID: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>

Remove AppContext from RepaintManager

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

Commit messages:
 - 8378389

Changes: https://git.openjdk.org/jdk/pull/29862/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29862&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378389
  Stats: 52 lines in 4 files changed: 4 ins; 19 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/29862.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29862/head:pull/29862

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

From prr at openjdk.org  Sun Feb 22 00:48:31 2026
From: prr at openjdk.org (Phil Race)
Date: Sun, 22 Feb 2026 00:48:31 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager
In-Reply-To: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
Message-ID: <eZDJCAJnZVW0girqSKnWkAh1OKWM_hcXsjpl_MmHOJM=.c291426c-dc33-4fc5-8051-3758376f4e3a@github.com>

On Sun, 22 Feb 2026 00:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from RepaintManager

src/java.desktop/share/classes/javax/swing/RepaintManager.java line 287:

> 285:      * Set the RepaintManager that should be used for the calling
> 286:      * thread. <b>aRepaintManager</b> will become the current RepaintManager
> 287:      * for the calling thread's thread group.

These words about thread group mean I have to do a CSR :-(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2836896660

From prr at openjdk.org  Sun Feb 22 03:04:11 2026
From: prr at openjdk.org (Phil Race)
Date: Sun, 22 Feb 2026 03:04:11 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect [v3]
In-Reply-To: <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>
Message-ID: <tMhqKcoDvXhTcVXSGxJKNcnLsefd6MKGWIWBzKufH3c=.59103700-ef37-4e30-a424-8da1427f3dfb@github.com>

On Thu, 19 Feb 2026 03:34:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
>> 
>> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
>> 
>> Before fix
>> 
>> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
>> 
>> 
>> After fix
>> 
>> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

They do need to be aligned. Anything else is weird.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3940005768

From jwood at openjdk.org  Sun Feb 22 19:32:55 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Sun, 22 Feb 2026 19:32:55 GMT
Subject: RFR: 8378057: CAccessibility roleKey and
 AWTAccessor.AccessibleBundleAccessor are Redundant
Message-ID: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>

This PR proposes replacing the native `roleKey` method with the `AWTAccessor.AccessibleBundleAccessor`. They appear to do the same thing.

I ran all the existing jtreg tests in the javax/accessibility folder and observed no new regressions (tested on Mac).

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

Commit messages:
 - 8378057: remove CAccessibility.roleKey

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

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

From kizune at openjdk.org  Sun Feb 22 19:58:08 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Sun, 22 Feb 2026 19:58:08 GMT
Subject: RFR: 8378197: Remove AppContext from
 sun/swing/plaf/DesktopProperty.java [v2]
In-Reply-To: <ZbI7yL6VT9uSWLYNZBBSHCpg6SYTsGNTATaArFUP2FI=.020f33b1-9492-4a21-9c45-227b2edc09b3@github.com>
References: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
 <ZbI7yL6VT9uSWLYNZBBSHCpg6SYTsGNTATaArFUP2FI=.020f33b1-9492-4a21-9c45-227b2edc09b3@github.com>
Message-ID: <13Hf9o4lf8tfTX6GisXl6sM5zN2hqOvmlDXsX-d9iAc=.2431cbed-9409-4770-82e3-119c44c17027@github.com>

On Sat, 21 Feb 2026 07:18:58 GMT, Phil Race <prr at openjdk.org> wrote:

>> A straightforward removal of a per-AppContext flag which can now be static
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378197

Looks good

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29801#pullrequestreview-3838527556

From serb at openjdk.org  Sun Feb 22 20:03:15 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 22 Feb 2026 20:03:15 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation
In-Reply-To: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
Message-ID: <8tU6fqIS0KwThGLVUCCSJiQROlPzoYvK3pbn8klkdaY=.aec7cae0-805d-4a00-9034-317c4f0901fc@github.com>

On Sat, 14 Feb 2026 16:13:27 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
> 
> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
> 
> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
> 
> Tested on mac, Linux and Windows:
> - make test TEST="jtreg:test/jdk/java/awt/font"
> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"

The [FileFontStrike.getGlyphMetrics( )](https://github.com/openjdk/jdk/blob/497dca2549a9829530670576115bf4b8fab386b3/src/java.desktop/share/classes/sun/font/FileFontStrike.java#L802) has a check `if (glyphPtr != 0L)` before calling `StrikeCache.getGlyphXAdvance`. Do not we need the same check in the new code? I am not sure that getGlyphImagePtr always return non-0 value. Another difference is handing invisible INVISIBLE_GLYPHS, which I assume works fine on macOS as is.

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

PR Comment: https://git.openjdk.org/jdk/pull/29726#issuecomment-3941617536

From psadhukhan at openjdk.org  Mon Feb 23 01:26:09 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Feb 2026 01:26:09 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect [v3]
In-Reply-To: <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>
Message-ID: <0QlU6uDg3-OI6fc3DMatPPGL6NGgZwksF3IIYZLIhL0=.fbafb7bf-8d46-40ba-864d-c74013e08fc7@github.com>

On Thu, 19 Feb 2026 03:34:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) fixed an issue in Windows L&F JMenuItem layout whereby radio bullet/checkmark was rendered in different columnspace than menuitem imageicon so radiobullet/checkmark is rendered in first column and imageicon is rendered in 2nd column but this rendering of imageicon in 2nd columnspace was done invariably for all JMenuItem irrespective of if it is JRadioButtonMenuItem or JCheckBoxMenuItem or JMenuItem, which is wrong.
>> 
>> Normal JMenuItem (which are not JRadioButtonMenuItem or JCheckBoxMenuItem) imageicon rendering should be done in first columnspace as was done before JDK-8348760 fix because there is no radiobullet/checkmark to render for those menuitems so no need to reserve columnspace for those bullet/checkmark icon
>> 
>> Before fix
>> 
>> <img width="205" height="127" alt="image" src="https://github.com/user-attachments/assets/13a1e352-5e8d-4251-b7a7-032935eab74e" />
>> 
>> 
>> After fix
>> 
>> <img width="195" height="131" alt="image" src="https://github.com/user-attachments/assets/84ec3ee6-2823-4bf7-840d-b53f2e9d44c3" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

Reverted the text alignment to have vertical alignment as before, but kept the JMenuItem imageicon alignment as it seems to be at par with native app for normal non-radio/non-check JMenuItem (as mentioned here https://github.com/openjdk/jdk/pull/29730#issuecomment-3919123593) and this JBS is about that only..

<img width="415" height="387" alt="image" src="https://github.com/user-attachments/assets/4b5f11d8-cade-4f07-8cb3-cc188a994a73" />


> They do need to be aligned. Anything else is weird.

It was aligned before this PR and so I closed this JBS as Not an Issue but it was reopened..

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3942093367

From dnguyen at openjdk.org  Mon Feb 23 01:26:14 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 23 Feb 2026 01:26:14 GMT
Subject: RFR: 8337853: Remove SunLayoutEngineKey and SunLayoutEngineFactory
 and its cache.
In-Reply-To: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
References: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
Message-ID: <TisX-XVCjwTpm5jbiHMiM3iSHW-s7iJ1W7r4wobWilM=.6120e589-ed59-4d81-b0c2-cd90c54fc8db@github.com>

On Wed, 11 Feb 2026 20:42:50 GMT, Phil Race <prr at openjdk.org> wrote:

> For a long time I've looked at the unnecessary complexity around the code that manages "LayoutEngines' for OpenType font layout.
> 
> The code was written a very long time ago when it was supposed that you might have a layout engine that could do Arabic. An unrelated one for Devanagari. An unrelated one for Thai. An unrelated one that knew how to handle some special font format ...
> 
> It uses keys to look up these 'instances' thereby creating caches that prevent GC.
> It was the cause of this bug report that font instances created from streams that were being used by layout aren't being deleted.
> There is also the implication there's some 'state' to the engines, when in fact the methods that
> invoke the native code are static methods and no state is relevant. Instances of the native engine are created and discarded as we need them in each layout call. There's minimal overhead to this, and whatever there is, we've been living with for a long time, and if we *were* re-using them we'd have overhead to ensure there was only one thread using it .. which we don't have and don't want.
> 
> So this PR deletes various interfaces and classes with LayoutEngine in the name, keeping only SunLayoutEngine, and making all its methods static - most already were.
> And fixes one very definite problem with the GCing of created fonts.

All the in file changes make sense to me. Also built and tested this and all seems to be stable/working.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29680#pullrequestreview-3838789205

From psadhukhan at openjdk.org  Mon Feb 23 02:30:34 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Feb 2026 02:30:34 GMT
Subject: RFR: 8378417: Printing All pages results in NPE for 1.1 PrintJob
Message-ID: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>

After [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239):, Printing ALL pages results in NPE for 1.1 PrintJob because of lack of set pageranges citing

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Cannot invoke "javax.print.attribute.standard.PageRanges.getMembers()" because "range" is null
        at java.desktop/sun.print.PrintJobDelegate.updateAttributes(PrintJobDelegate.java:529)
        at java.desktop/sun.print.PrintJobDelegate.printDialog(PrintJobDelegate.java:424)
        at java.desktop/sun.print.PrintJob2D.printDialog(PrintJob2D.java:65)
        at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:644)
        at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:629) 

A null check is now added as we are now removing PageRange attribute if not set..It works fine for PrinterJob but fails for 1.1 PrintJob as PrintJobDelegate.updateAttributes called in 1.1 PrintJob use pageRange variable without checking if it exists.

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

Commit messages:
 - 8378417: Printing All pages results in NPE for 1.1 PrintJob

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

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

From rkannathpari at openjdk.org  Mon Feb 23 04:56:55 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 23 Feb 2026 04:56:55 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v3]
In-Reply-To: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
Message-ID: <lrUvNM0qPZXIkpRaeIJjcvkf8Pg5cIUBFTx1ZIU2PBY=.a03abaaa-f766-48b6-b8e5-8c7f71bbc474@github.com>

> Hi Reviewers,
> 
> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on suggesion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29733/files
  - new: https://git.openjdk.org/jdk/pull/29733/files/9cc2d549..2e6dc352

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

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

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

From serb at openjdk.org  Mon Feb 23 05:03:33 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 05:03:33 GMT
Subject: RFR: 8378388: Add missing @Override annotations in
 "javax.print.attribute.standard" package part 1
Message-ID: <rBDZ_IPM2ArNr6sJJhRY92miSERYWXo1bGkbXmtlZOA=.99465c01-86b9-49a9-8a57-39a74e4d0fe6@github.com>

This patch adds missing `@Override` annotations to methods in the `javax.print.attribute.standard` package that override methods from a superclass or interface.

Since the package is large the fix has been split, this is the first part.
Only source annotations are added; there are no behavioral changes.

The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887.

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

Commit messages:
 - 8378388: Add missing @Override annotations in "javax.print.attribute.standard" package part 1

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

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

From prr at openjdk.org  Mon Feb 23 05:08:09 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 05:08:09 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled [v2]
In-Reply-To: <YLdhwdGeXIctXt6HOJYSudhDPKnvIykNBTri8gBxv-w=.f613e0f2-16e9-41aa-b4b3-eafdc705943d@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
 <YLdhwdGeXIctXt6HOJYSudhDPKnvIykNBTri8gBxv-w=.f613e0f2-16e9-41aa-b4b3-eafdc705943d@github.com>
Message-ID: <TyHFJRi7rfWazss9Ghz0NvGaV9bbE2yo4Jo6VmHiJjk=.d49cab45-6572-4ae0-a54a-a2ef89bea98f@github.com>

On Fri, 13 Feb 2026 01:48:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add headful keyword

@prsadhuk / @DamonGuy need a 2nd reviewer here

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

PR Comment: https://git.openjdk.org/jdk/pull/29563#issuecomment-3938137231

From dnguyen at openjdk.org  Mon Feb 23 05:08:09 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 23 Feb 2026 05:08:09 GMT
Subject: RFR: 8376253: [macOS] FileSystemView may not report system icons
 when -Xcheck:jni is enabled [v2]
In-Reply-To: <YLdhwdGeXIctXt6HOJYSudhDPKnvIykNBTri8gBxv-w=.f613e0f2-16e9-41aa-b4b3-eafdc705943d@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
 <YLdhwdGeXIctXt6HOJYSudhDPKnvIykNBTri8gBxv-w=.f613e0f2-16e9-41aa-b4b3-eafdc705943d@github.com>
Message-ID: <6SGL3QVdak1YQYtsw06VNHPvqhPVDZ2inmGyEefZEx4=.c77904e0-7f3d-46ab-bf6c-6cebb852ae73@github.com>

On Fri, 13 Feb 2026 01:48:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add headful keyword

LGTM. Built it and the provided test passes. Looks like it's also passing in CI for me at least.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29563#pullrequestreview-3839161881

From duke at openjdk.org  Mon Feb 23 09:07:34 2026
From: duke at openjdk.org (duke)
Date: Mon, 23 Feb 2026 09:07:34 GMT
Subject: RFR: 8377745: VoiceOver Identifies Hyperlink as Text [v2]
In-Reply-To: <vikiKuDi1QPsG_ovP_YQJqWZ7c4x2EEhbZ8f0tes4oU=.5a9705ac-4fd3-4efb-94bd-b8740c947195@github.com>
References: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
 <vikiKuDi1QPsG_ovP_YQJqWZ7c4x2EEhbZ8f0tes4oU=.5a9705ac-4fd3-4efb-94bd-b8740c947195@github.com>
Message-ID: <iU40mk5w-OxNZG0QRdUcshowsWYdd4APYks4ZOAkndg=.332cdfa8-64f0-4918-9273-a6bdcadd1160@github.com>

On Fri, 13 Feb 2026 22:15:31 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> ~~If we use `new AccessibleRole("AXLink") {}`, then VoiceOver reads this more like other native apps.~~
>> 
>> ~~There isn't a similar precedent in CAccessibility for creating custom AccessibleRoles, so I won't mind if this PR is declined. (But I don't know off the top of my head where else to inject code to get the desired result...)~~
>> 
>> This introduces a new LinkAccessibility.m file to help VoiceOver and Accessibility Inspector correctly identify AccessibleRole.HYPERLINK as "link"
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8377745: creating new LinkAccessibility
>    
>    This helps convert from AccessibleRole.HYPERLINK to the new LinkAccessibility.
>    
>    The new LinkAccessible still references `CommonTextAccessibility<NSAccessibilityStaticText>`.
>    
>    This (both the subject matter and the programming language) is outside of my area of expertise, but the unit test passes.
>    
>    This is based on this feedback:
>    https://github.com/openjdk/jdk/pull/29686#issuecomment-3899448303
>  - Revert "8377745: use custom "AXLink" AccessibleRole"
>    
>    This reverts commit d66355973918458352d15174a2cf21a177763c23.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/29686#issuecomment-3943492126

From psadhukhan at openjdk.org  Mon Feb 23 09:36:22 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Feb 2026 09:36:22 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane
In-Reply-To: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
Message-ID: <fw3xzo3X2lsvX8A94-L7Qea5mKk_N_oQTeYCqJM5DvQ=.6c56013f-eec3-4df4-96c2-d365ee6f5ea9@github.com>

On Sat, 21 Feb 2026 04:47:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from JEditorPane

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

> 1324: 
> 1325:     private static Hashtable<String, EditorKit> getKitRegistry() {
> 1326:         return hitRegistry;

I believe you meant to use "kitRegistry"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29855#discussion_r2839847788

From psadhukhan at openjdk.org  Mon Feb 23 09:49:25 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 23 Feb 2026 09:49:25 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes
In-Reply-To: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
Message-ID: <MKwyhObgA1wUYRBYF10j4oV-XZOSxw-abw-qy1y6lKI=.dc8c3252-bbcb-438d-9923-a9fc826939c5@github.com>

On Thu, 19 Feb 2026 23:20:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
> 
> One ToolTipManager test for the AppContext is removed.

src/java.desktop/share/classes/javax/swing/PopupFactory.java line 723:

> 721:          */
> 722:         private static List<LightWeightPopup> getLightWeightPopupCache() {
> 723:             synchronized (PopupFactory.class) {

I believe it should synchronize on LightWeightPopup class and not on PopupFactory?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2839901931

From dgredler at openjdk.org  Mon Feb 23 13:15:28 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 23 Feb 2026 13:15:28 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation
In-Reply-To: <8tU6fqIS0KwThGLVUCCSJiQROlPzoYvK3pbn8klkdaY=.aec7cae0-805d-4a00-9034-317c4f0901fc@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
 <8tU6fqIS0KwThGLVUCCSJiQROlPzoYvK3pbn8klkdaY=.aec7cae0-805d-4a00-9034-317c4f0901fc@github.com>
Message-ID: <i4eGCUnDhmCowxZ1XMLxi_ORjqJN1eUBoO2lsz7s8Fg=.6305067c-085e-4739-8963-d3ada7a299e2@github.com>

On Sun, 22 Feb 2026 20:00:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Another difference is handing invisible INVISIBLE_GLYPHS, which I assume works fine on macOS as is.

Yes, the test exercises this scenario because the new line and tab chars in the test text are mapped to invisible glyph IDs. However, it might not hurt to add an early check here to avoid entering native code entirely in this scenario -- although this should happen rarely, so I'm not sure how effective this will be as a mini-optimization. I'm happy to add this check though, if the consensus is that it's a good idea.

> The FileFontStrike.getGlyphMetrics( ) has a check if (glyphPtr != 0L) before calling StrikeCache.getGlyphXAdvance. Do not we need the same check in the new code?

It doesn't look like it to me, mainly because `CGGI_CreateNewGlyphInfoFrom` (see call sequence below) expects that malloc never fails. That's maybe a bit odd, but I think if we get NULL / 0 back as a pointer, we have problems elsewhere (in `CGGI_CreateNewGlyphInfoFrom`, not here).

Sequence: getGlyphImagePtr -> getGlyphImagePtrs -> getFilteredGlyphImagePtrs -> getGlyphImagePtrsNative -> Java_sun_font_CStrike_getGlyphImagePtrsNative -> CGGlyphImages_GetGlyphImagePtrs -> CGGI_CreateGlyphsAndScanForComplexities -> CGGI_CreateGlyphInfos -> **CGGI_CreateNewGlyphInfoFrom** /// OR /// CGGI_FillImagesForGlyphs -> CGGI_FillImagesForGlyphsWithSizedCanvas -> CGGI_CreateImageForUnicode -> **CGGI_CreateNewGlyphInfoFrom**

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

PR Comment: https://git.openjdk.org/jdk/pull/29726#issuecomment-3944715150

From aivanov at openjdk.org  Mon Feb 23 14:31:52 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Feb 2026 14:31:52 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect [v3]
In-Reply-To: <0QlU6uDg3-OI6fc3DMatPPGL6NGgZwksF3IIYZLIhL0=.fbafb7bf-8d46-40ba-864d-c74013e08fc7@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <ywB-j4gVf3KDwnvOY_XqvZOdbqu3glfXYZMFxf1mTXE=.77a96620-56a9-4bdc-8133-f351b479a7c7@github.com>
 <0QlU6uDg3-OI6fc3DMatPPGL6NGgZwksF3IIYZLIhL0=.fbafb7bf-8d46-40ba-864d-c74013e08fc7@github.com>
Message-ID: <oKd5KxSVDvqXARI5DEIbVZSz2zhRlrcIUtERGLSD--8=.f4a1e54d-6168-4aa6-9081-ce58f2dc9f9e@github.com>

On Mon, 23 Feb 2026 01:23:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > They do need to be aligned. Anything else is weird.
>
> It was aligned before this PR and so I closed this JBS as Not an Issue but it was reopened..

[JDK-8370945](https://bugs.openjdk.org/browse/JDK-8370945) was reopen to remove the space reserved for check mark or radio bullet where none is needed.

I agree with Phil, the icons should be aligned by default if there are both check marks / radio bullets and icons at the same time.

I think the icons should be rendered at the location of check marks / radio bullets if there are no menu items that have both, that is no `JCheckBoxMenuItem` or `JRadioButtonMenuItem` with an icon.

> Metal and Nimbus are platform independent so they can do their own things but Windows L&F need to do similar to what native application does?

Yet we failed to find [a native app that displays both](https://github.com/openjdk/jdk/pull/23324#discussion_r1935724542). It was the problem in https://github.com/openjdk/jdk/pull/23324. The menu in Windows Explorer that @tabata-d [referred to](https://github.com/openjdk/jdk/pull/29730#issuecomment-3919381079) is the one that [you'd used in the PR](https://github.com/openjdk/jdk/pull/23324#discussion_r1935744523) for the initial fix.

Later on, [Phil demonstrated](https://github.com/openjdk/jdk/pull/23324#issuecomment-2859773998) with a native Win32 app that the layout of Windows native menus doesn't reserve another column?for a check mark / radio bullet and for a menu icon?unless you specify both `hbmpChecked` and `hbmpUnchecked` as well as `hbmpItem`. *If only `hbmpItem` is specified, the icon is displayed where the check mark / bullet is displayed.*

Thus, your currently proposed fix produces a similar menu to that of Win32. But?

> > They do need to be aligned. Anything else is weird.

I still think we should align the icons in this case.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3945094779

From aivanov at openjdk.org  Mon Feb 23 15:23:41 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Feb 2026 15:23:41 GMT
Subject: RFR: 8370945: With Windows LAF,
 the location of a JMenuItem icon is incorrect
In-Reply-To: <5Nr7jWXEo5A_t1rIku6YmKWrg08unNsSUqmSqYlQSFA=.e8814758-cba1-4ca3-b40e-bfafcb6b704a@github.com>
References: <POZds-Yf6FBcDn0Dr5Ut4gCE6iiIoIuNCEIDtu2xE0A=.49183dea-e70e-4d74-9410-db752d9837b7@github.com>
 <5Nr7jWXEo5A_t1rIku6YmKWrg08unNsSUqmSqYlQSFA=.e8814758-cba1-4ca3-b40e-bfafcb6b704a@github.com>
Message-ID: <9IkO7xGDoiHq8y3rc7oOuqoGLBdjD50zVVaIjKSa_dI=.37172aaf-5bb5-45fc-830d-722e9e320456@github.com>

On Wed, 18 Feb 2026 07:15:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Windows L&F need to do similar to what native application does, if not in pixel-perfect way

We're way far from copying that Windows Explorer Menu to which everyone keeps referring?

The main issue I have with our current design is that it's *too crowded*: adding another column didn't increase the width of the menu. [I raised this concern](https://github.com/openjdk/jdk/pull/23324#discussion_r2175066908) in #23324, and it still persists today.

This is why I think the entire approach has to be re-worked. It'll take a lot of time and effort.

I submitted [JDK-8376828](https://bugs.openjdk.org/browse/JDK-8376828): *Improve JMenuItem layout in Windows L&F* with that in mind.

In #28889, [you said](https://github.com/openjdk/jdk/pull/28889#discussion_r2696785303):

> I am reusing the VistaMenuItemCheckIcon to render the RadioButtonMenuItem and CheckBoxMenuItem icons and *getting rid of the working/treatment made in that class (and rewriting) might result in more regressions which I am avoiding*

(Emphasis is mine.) Yet I don't think the current approach avoids regressions. Each tweak you make breaks something else?

Re-writing is *risky*, but I believe it'll pay off in the long run, with cleaner code that's easier to support.

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

PR Comment: https://git.openjdk.org/jdk/pull/29730#issuecomment-3945387069

From azvegint at openjdk.org  Mon Feb 23 16:12:23 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 23 Feb 2026 16:12:23 GMT
Subject: RFR: 8378202: Remove AppContext from XAWT classes
In-Reply-To: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
References: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
Message-ID: <_74JAZPI1lWihs_mNaujTOsiSJgSau6zsA5mh3Hx9x8=.0a625122-583b-4569-845a-5b3b38a63b67@github.com>

On Wed, 18 Feb 2026 22:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from XAWT.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29804#pullrequestreview-3842016094

From jwood at openjdk.org  Mon Feb 23 16:22:58 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Mon, 23 Feb 2026 16:22:58 GMT
Subject: Integrated: 8377745: VoiceOver Identifies Hyperlink as Text
In-Reply-To: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
References: <6kyItwC9sTxiSahKW_4i5i8l-LBe0a5PdQnTvD93CNw=.f94f0a19-ae39-4356-8402-7d8beea04274@github.com>
Message-ID: <PPXfO2niDPWzuJckWebP3gisP2dpixVms2ffDPlx8SY=.a7d974f5-501e-43bd-90bc-ba6cf1be9d98@github.com>

On Thu, 12 Feb 2026 08:32:43 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> ~~If we use `new AccessibleRole("AXLink") {}`, then VoiceOver reads this more like other native apps.~~
> 
> ~~There isn't a similar precedent in CAccessibility for creating custom AccessibleRoles, so I won't mind if this PR is declined. (But I don't know off the top of my head where else to inject code to get the desired result...)~~
> 
> This introduces a new LinkAccessibility.m file to help VoiceOver and Accessibility Inspector correctly identify AccessibleRole.HYPERLINK as "link"

This pull request has now been integrated.

Changeset: 66ba63a4
Author:    Jeremy Wood <jwood at openjdk.org>
Committer: Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66ba63a4e98bbea0d5a2c9b13c777c611d90a85a
Stats:     167 lines in 4 files changed: 161 ins; 0 del; 6 mod

8377745: VoiceOver Identifies Hyperlink as Text

Reviewed-by: kizune, dnguyen

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

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

From dmarkov at openjdk.org  Mon Feb 23 16:32:10 2026
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Mon, 23 Feb 2026 16:32:10 GMT
Subject: RFR: 8377924: Inconsistent parsing of XBM files after JDK-8361748
In-Reply-To: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
References: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
Message-ID: <DlyfBhCtw5aUfeznPM85hkjcsUwIv0mjfffe1SgJViw=.58369209-e297-4bc1-a693-565fbde5450a@github.com>

On Tue, 17 Feb 2026 21:41:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748 "Enforce limits on the size of an XBM image") and [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727 "New XBM images parser regression: only the first line of the bitmap array is parsed") changed how XBM files are parsed, and now some of the valid XBM images are parsed inconsistently. For example,
> 
> 
> #define ht 1
> #define th 8
> k[] = {0xAB}; 
> 
> 
> is parsed as image of size 1?8 instead of 8?1 after JDK-8361748.
> 
> The above problem is addressed by [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727). However, the code to differentiate between width and height differs from the original code that was used before [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748). Due to this difference,
> 
> 
> #define ht 1
> #define h 8 
> 
> 
> is rejected: Invalid values for width or height.
> 
> Previously, `-h` was a marker for width, and `-ht` was for height.
> 
> https://github.com/openjdk/jdk/blob/fc807d0914c4d8d2a174410a35acf3520ff4e60a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112
> 
> But [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727) uses `-th` for width and `-t` for height.
> 
> https://github.com/openjdk/jdk/blob/7f707ba8e746d859ac171d71ef8f731953a92e6a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L114-L118
> 
> For backward compatibility, we should revert to `-h` and `-ht`.

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29769#pullrequestreview-3842141992

From serb at openjdk.org  Mon Feb 23 17:54:52 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 17:54:52 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation
In-Reply-To: <i4eGCUnDhmCowxZ1XMLxi_ORjqJN1eUBoO2lsz7s8Fg=.6305067c-085e-4739-8963-d3ada7a299e2@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
 <8tU6fqIS0KwThGLVUCCSJiQROlPzoYvK3pbn8klkdaY=.aec7cae0-805d-4a00-9034-317c4f0901fc@github.com>
 <i4eGCUnDhmCowxZ1XMLxi_ORjqJN1eUBoO2lsz7s8Fg=.6305067c-085e-4739-8963-d3ada7a299e2@github.com>
Message-ID: <B97KFRAiLOoDAwH3WypoUtrMwia5DWVZCGe_d9rBl0U=.8f703a0d-7232-41e4-b0ac-025219abc4c1@github.com>

On Mon, 23 Feb 2026 13:12:24 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>Sequence: getGlyphImagePtr -> getGlyphImagePtrs -> getFilteredGlyphImagePtrs -> getGlyphImagePtrsNative -> Java_sun_font_CStrike_getGlyphImagePtrsNative -> CGGlyphImages_GetGlyphImagePtrs -> CGGI_CreateGlyphsAndScanForComplexities -> CGGI_CreateGlyphInfos -> CGGI_CreateNewGlyphInfoFrom /// OR /// CGGI_FillImagesForGlyphs -> CGGI_FillImagesForGlyphsWithSizedCanvas -> CGGI_CreateImageForUnicode -> CGGI_CreateNewGlyphInfoFrom

This is some objc code that may throw an NSException. It will be caught in Java_sun_font_CStrike_getGlyphImagePtrsNative by JNI_COCOA_ENTER / JNI_COCOA_EXIT.

And that assumption that malloc always succeed is suspicion.

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

PR Comment: https://git.openjdk.org/jdk/pull/29726#issuecomment-3946356155

From prr at openjdk.org  Mon Feb 23 18:25:02 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 18:25:02 GMT
Subject: Integrated: 8378202: Remove AppContext from XAWT classes
In-Reply-To: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
References: <Vx2Byp9znAkOM8b1O2l-_YU9FeO4mMe2l8OJAHvCaso=.d1773cdb-d6a0-4729-b8d5-8500a3e159d8@github.com>
Message-ID: <mQm3mLU5OZhTiht4k1ZyWNdX6RdwK8KWjgSmMIekyR0=.d075da50-8235-490a-bc8d-8a378dd7b60a@github.com>

On Wed, 18 Feb 2026 22:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from XAWT.

This pull request has now been integrated.

Changeset: 1cb8b6d1
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1cb8b6d1b579a91b71bc0a478044a04b84d12ae9
Stats:     44 lines in 4 files changed: 2 ins; 30 del; 12 mod

8378202: Remove AppContext from XAWT classes

Reviewed-by: serb, azvegint

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

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

From prr at openjdk.org  Mon Feb 23 18:38:47 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 18:38:47 GMT
Subject: Integrated: 8337853: Remove SunLayoutEngineKey and
 SunLayoutEngineFactory and its cache.
In-Reply-To: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
References: <1ER9ZS85S23Q09gi6h8Zql4QndbJ25Z-f-q8LNlBdUI=.1d376275-5ca3-4e52-adc7-71ff12ba11a8@github.com>
Message-ID: <mQ9H7BEHWAvxiTPO_4g_ZPYiCvrmPh1G1P7SbMkXtvY=.b2859fc1-27d9-4edd-9dad-1d3ec87142e8@github.com>

On Wed, 11 Feb 2026 20:42:50 GMT, Phil Race <prr at openjdk.org> wrote:

> For a long time I've looked at the unnecessary complexity around the code that manages "LayoutEngines' for OpenType font layout.
> 
> The code was written a very long time ago when it was supposed that you might have a layout engine that could do Arabic. An unrelated one for Devanagari. An unrelated one for Thai. An unrelated one that knew how to handle some special font format ...
> 
> It uses keys to look up these 'instances' thereby creating caches that prevent GC.
> It was the cause of this bug report that font instances created from streams that were being used by layout aren't being deleted.
> There is also the implication there's some 'state' to the engines, when in fact the methods that
> invoke the native code are static methods and no state is relevant. Instances of the native engine are created and discarded as we need them in each layout call. There's minimal overhead to this, and whatever there is, we've been living with for a long time, and if we *were* re-using them we'd have overhead to ensure there was only one thread using it .. which we don't have and don't want.
> 
> So this PR deletes various interfaces and classes with LayoutEngine in the name, keeping only SunLayoutEngine, and making all its methods static - most already were.
> And fixes one very definite problem with the GCing of created fonts.

This pull request has now been integrated.

Changeset: 569d18fb
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/569d18fbe51a036629337c38230ae4892365a228
Stats:     219 lines in 4 files changed: 3 ins; 195 del; 21 mod

8337853: Remove SunLayoutEngineKey and SunLayoutEngineFactory and its cache.

Reviewed-by: azvegint, dnguyen

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

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

From prr at openjdk.org  Mon Feb 23 18:42:53 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 18:42:53 GMT
Subject: Integrated: 8378197: Remove AppContext from
 sun/swing/plaf/DesktopProperty.java
In-Reply-To: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
References: <fA5eXrsl-mD5kfGTPc5ctMVP0ukAdFinJyBYJgQFB24=.14baa12e-2418-4729-9ca8-5436ebd0e426@github.com>
Message-ID: <IR21irP4YQorphvUyG6Yw5LJdJ7l1pFG8Z7LDH3NS50=.b6e67092-3388-473d-932e-594bd3774389@github.com>

On Wed, 18 Feb 2026 19:57:15 GMT, Phil Race <prr at openjdk.org> wrote:

> A straightforward removal of a per-AppContext flag which can now be static

This pull request has now been integrated.

Changeset: 74a07b74
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74a07b7487a8eed43e5514fb16336998e9b1ebc7
Stats:     27 lines in 1 file changed: 2 ins; 21 del; 4 mod

8378197: Remove AppContext from sun/swing/plaf/DesktopProperty.java

Reviewed-by: serb, kizune

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

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

From aivanov at openjdk.org  Mon Feb 23 19:12:36 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Feb 2026 19:12:36 GMT
Subject: Integrated: 8377924: Inconsistent parsing of XBM files after
 JDK-8361748
In-Reply-To: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
References: <3nbcWrveOIRavhs7tZShvimEfiyQPJ_BkXtJ0o3A-Ok=.64f2279f-1d26-49b2-8a45-708021ec14fe@github.com>
Message-ID: <i-_yUUOifNQQAEEVlw2JIeDS7d49VIiBsD4mfHGqkwM=.76d4ef75-0e94-4299-884d-301f1ab15cdc@github.com>

On Tue, 17 Feb 2026 21:41:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748 "Enforce limits on the size of an XBM image") and [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727 "New XBM images parser regression: only the first line of the bitmap array is parsed") changed how XBM files are parsed, and now some of the valid XBM images are parsed inconsistently. For example,
> 
> 
> #define ht 1
> #define th 8
> k[] = {0xAB}; 
> 
> 
> is parsed as image of size 1?8 instead of 8?1 after JDK-8361748.
> 
> The above problem is addressed by [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727). However, the code to differentiate between width and height differs from the original code that was used before [JDK-8361748](https://bugs.openjdk.org/browse/JDK-8361748). Due to this difference,
> 
> 
> #define ht 1
> #define h 8 
> 
> 
> is rejected: Invalid values for width or height.
> 
> Previously, `-h` was a marker for width, and `-ht` was for height.
> 
> https://github.com/openjdk/jdk/blob/fc807d0914c4d8d2a174410a35acf3520ff4e60a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L109-L112
> 
> But [JDK-8373727](https://bugs.openjdk.org/browse/JDK-8373727) uses `-th` for width and `-t` for height.
> 
> https://github.com/openjdk/jdk/blob/7f707ba8e746d859ac171d71ef8f731953a92e6a/src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java#L114-L118
> 
> For backward compatibility, we should revert to `-h` and `-ht`.

This pull request has now been integrated.

Changeset: 6b576235
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b576235b84f51e273da44158bfcadbb48f51baa
Stats:     162 lines in 12 files changed: 144 ins; 7 del; 11 mod

8377924: Inconsistent parsing of XBM files after JDK-8361748
8377826: Eliminate code duplication in XbmImageDecoder

Reviewed-by: dnguyen, prr, dmarkov

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

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

From serb at openjdk.org  Mon Feb 23 19:14:07 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 19:14:07 GMT
Subject: RFR: 6434110: Color constructor parameter name is misleading [v4]
In-Reply-To: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
Message-ID: <j1na8GRcPBHJiv7izpnwMmYMTEWro5tTOfr2L9P1lv4=.130e1412-081c-462f-9a5a-a0ed68db1a2b@github.com>

> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>  - rgba -> argb, since this is the format described in the spec
>  - hasalpha -> hasAlpha, to follow common naming conventions
> 
> Also adds a basic test for the constructor.

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-6434110
 - lists via "<ul>" is added
 - review feedback
 - 6434110: Color constructor parameter name is misleading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29734/files
  - new: https://git.openjdk.org/jdk/pull/29734/files/f12b4406..6c542211

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

  Stats: 486300 lines in 581 files changed: 243363 ins; 239200 del; 3737 mod
  Patch: https://git.openjdk.org/jdk/pull/29734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29734/head:pull/29734

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

From aivanov at openjdk.org  Mon Feb 23 19:35:25 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Feb 2026 19:35:25 GMT
Subject: RFR: 8378417: Printing All pages results in NPE for 1.1 PrintJob
In-Reply-To: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
References: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
Message-ID: <JY3tYdYa_QAWGDEoYEFJXtUJ-1qzFbnYBr2NtINBoS4=.57e22237-7c6e-4674-99c1-a06933266a15@github.com>

On Mon, 23 Feb 2026 02:23:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> After [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239):, Printing ALL pages results in NPE for 1.1 PrintJob because of lack of set pageranges citing
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Cannot invoke "javax.print.attribute.standard.PageRanges.getMembers()" because "range" is null
>         at java.desktop/sun.print.PrintJobDelegate.updateAttributes(PrintJobDelegate.java:529)
>         at java.desktop/sun.print.PrintJobDelegate.printDialog(PrintJobDelegate.java:424)
>         at java.desktop/sun.print.PrintJob2D.printDialog(PrintJob2D.java:65)
>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:644)
>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:629) 
> 
> A null check is now added as we are now removing PageRange attribute if not set..It works fine for PrinterJob but fails for 1.1 PrintJob as PrintJobDelegate.updateAttributes called in 1.1 PrintJob use pageRange variable without checking if it exists.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29874#pullrequestreview-3843103759

From prr at openjdk.org  Mon Feb 23 20:24:28 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 20:24:28 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v3]
In-Reply-To: <qIfA1Tb-MmxbHl34dvkGNrR3mSTrWbgVZXBFN0psvJk=.fdcb2f9b-70b1-47cb-977f-c7e45bcfddfd@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
 <lcutAFzitKhkZsf9RCVk30q5d8yEj7w3tJrUwzKXhwU=.2e714ec3-66b2-4247-a3b7-bfcafdb6c721@github.com>
 <qIfA1Tb-MmxbHl34dvkGNrR3mSTrWbgVZXBFN0psvJk=.fdcb2f9b-70b1-47cb-977f-c7e45bcfddfd@github.com>
Message-ID: <nkWZITpAUandNjwd8CrZeJClicwxQtXvv1Ina2FrlIU=.db2591f9-ce45-4e11-9a91-252ec01a055a@github.com>

On Wed, 18 Feb 2026 09:31:55 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16nw.c line 922:
>> 
>>> 920:           off += kw;
>>> 921: 
>>> 922:           sp += (kw - 1)*chan1;
>> 
>> Just to check: before the patch, the code read data from sp to set pXX, then increased sp. After the patch, the order is different. Is that correct?
>
> I also have same query.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2842897514

From prr at openjdk.org  Mon Feb 23 20:24:27 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 20:24:27 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v4]
In-Reply-To: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
Message-ID: <wGG7r4gMFM7JtNmDeMQwOhwZL4kU1Ehlr-E154VnVoY=.ab52e8e7-f019-4661-9bc8-cd905bf15495@github.com>

> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
> 
> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
> I did that and ran all our existing automated tests on our CI systems.

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

  8373626

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29257/files
  - new: https://git.openjdk.org/jdk/pull/29257/files/97dc5cba..7175aa42

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

  Stats: 46 lines in 3 files changed: 40 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29257/head:pull/29257

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

From prr at openjdk.org  Mon Feb 23 20:27:52 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 20:27:52 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v3]
In-Reply-To: <Khxns4tFJ9oJ8EQCnvFBljFV6a_lHzWaJr1cqdeUCIk=.bd54aa05-1715-4ae4-807b-170814124bc9@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
 <Khxns4tFJ9oJ8EQCnvFBljFV6a_lHzWaJr1cqdeUCIk=.bd54aa05-1715-4ae4-807b-170814124bc9@github.com>
Message-ID: <AdH6R2LMIe8kQ25PVMZWwv7UNrYstYPFYw0bSp1pyZY=.16d3161e-b0e6-4b1f-b576-ef565f4a6baa@github.com>

On Wed, 18 Feb 2026 09:04:50 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8373626
>
> src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16nw.c line 922:
> 
>> 920:           off += kw;
>> 921: 
>> 922:           p2 = sp[0]; p3 = sp[chan1]; p4 = sp[chan2];
> 
> Do we need to delete these lines? Since the values are getting copied individually for each conditions?

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2842909082

From prr at openjdk.org  Mon Feb 23 20:27:48 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 20:27:48 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v5]
In-Reply-To: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
Message-ID: <FzXHIQv5RI1OOFOPARquL3HB9-VkWViL-BjmxDS34I4=.42ccc740-efc6-4618-a4a1-512d25532002@github.com>

> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
> 
> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
> I did that and ran all our existing automated tests on our CI systems.

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

  8373626

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29257/files
  - new: https://git.openjdk.org/jdk/pull/29257/files/7175aa42..a78aeacd

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

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

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

From prr at openjdk.org  Mon Feb 23 20:45:29 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 20:45:29 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v3]
In-Reply-To: <Khxns4tFJ9oJ8EQCnvFBljFV6a_lHzWaJr1cqdeUCIk=.bd54aa05-1715-4ae4-807b-170814124bc9@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <svyJMvSAdoY43Rzbh1E_tocL5dWLX3KU0mjtqPP7i40=.469a2509-058b-4a4e-b672-fa28c2e30766@github.com>
 <Khxns4tFJ9oJ8EQCnvFBljFV6a_lHzWaJr1cqdeUCIk=.bd54aa05-1715-4ae4-807b-170814124bc9@github.com>
Message-ID: <0BaWu8DUAPfRUbOQ5EadAlCn-3PuJe4N5cTf18IZdNE=.8dae0b23-04e0-482c-9896-87619da8d33b@github.com>

On Wed, 18 Feb 2026 09:21:03 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8373626
>
> src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8nw.c line 923:
> 
>> 921:           off += kw;
>> 922: 
>> 923:           sp += (kw - 1)*chan1;
> 
> Do we need to move this change in address of `sp` to each conditions?

I fixed this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2842999940

From prr at openjdk.org  Mon Feb 23 20:53:50 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 20:53:50 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v2]
In-Reply-To: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
Message-ID: <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>

> Remove AppContext from JEditorPane

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

  8378377

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29855/files
  - new: https://git.openjdk.org/jdk/pull/29855/files/60e13535..c0cb0a30

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

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

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

From prr at openjdk.org  Mon Feb 23 20:53:52 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 20:53:52 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v2]
In-Reply-To: <fw3xzo3X2lsvX8A94-L7Qea5mKk_N_oQTeYCqJM5DvQ=.6c56013f-eec3-4df4-96c2-d365ee6f5ea9@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <fw3xzo3X2lsvX8A94-L7Qea5mKk_N_oQTeYCqJM5DvQ=.6c56013f-eec3-4df4-96c2-d365ee6f5ea9@github.com>
Message-ID: <Hmwum6d2lZoypuL8xkZ4DzGlnxfXc0Z36SW3GasU4Mg=.69fc93c1-2e03-40f5-a994-a6df06e3fc0f@github.com>

On Mon, 23 Feb 2026 09:33:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378377
>
> src/java.desktop/share/classes/javax/swing/JEditorPane.java line 1326:
> 
>> 1324: 
>> 1325:     private static Hashtable<String, EditorKit> getKitRegistry() {
>> 1326:         return hitRegistry;
> 
> I believe you meant to use "kitRegistry"

variable renamed to kitRegistry

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29855#discussion_r2843033375

From prr at openjdk.org  Mon Feb 23 21:33:24 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 21:33:24 GMT
Subject: RFR: 8378417: Printing All pages results in NPE for 1.1 PrintJob
In-Reply-To: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
References: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
Message-ID: <qiwxeK5fkJFpex2WBeo0Lxn_cTYZU_eEslcZx0VDDiE=.298e0f01-59af-4d72-bbd9-714bfc70bdc6@github.com>

On Mon, 23 Feb 2026 02:23:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> After [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239):, Printing ALL pages results in NPE for 1.1 PrintJob because of lack of set pageranges citing
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Cannot invoke "javax.print.attribute.standard.PageRanges.getMembers()" because "range" is null
>         at java.desktop/sun.print.PrintJobDelegate.updateAttributes(PrintJobDelegate.java:529)
>         at java.desktop/sun.print.PrintJobDelegate.printDialog(PrintJobDelegate.java:424)
>         at java.desktop/sun.print.PrintJob2D.printDialog(PrintJob2D.java:65)
>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:644)
>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:629) 
> 
> A null check is now added as we are now removing PageRange attribute if not set..It works fine for PrinterJob but fails for 1.1 PrintJob as PrintJobDelegate.updateAttributes called in 1.1 PrintJob use pageRange variable without checking if it exists.

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 529:

> 527: 
> 528:         PageRanges range = (PageRanges)attributes.get(PageRanges.class);
> 529:         if (range != null) {

I wonder if this is right ?
Surely if the PageRanges is not there any more, we should update the JobAttributes to a default range ?
This would leave whatever stale value is present.

test/jdk/java/awt/PrintJob/ScaledImagePrintingTest.java line 37:

> 35: /*
> 36:  * @test
> 37:  * @bug 4257962 8378417

What does this test have to do with PageRanges ?

How do I use this to see the problem ?

 I think we need a more appropriate test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29874#discussion_r2843173050
PR Review Comment: https://git.openjdk.org/jdk/pull/29874#discussion_r2843066673

From aivanov at openjdk.org  Mon Feb 23 21:45:23 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Feb 2026 21:45:23 GMT
Subject: RFR: 8378417: Printing All pages results in NPE for 1.1 PrintJob
In-Reply-To: <qiwxeK5fkJFpex2WBeo0Lxn_cTYZU_eEslcZx0VDDiE=.298e0f01-59af-4d72-bbd9-714bfc70bdc6@github.com>
References: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
 <qiwxeK5fkJFpex2WBeo0Lxn_cTYZU_eEslcZx0VDDiE=.298e0f01-59af-4d72-bbd9-714bfc70bdc6@github.com>
Message-ID: <iX4zbWFF38uP2zeKwbDVnmSsPtj40KLphZGEiZcFrDk=.77f716a4-ac87-4d30-9544-26cca69b6198@github.com>

On Mon, 23 Feb 2026 20:59:30 GMT, Phil Race <prr at openjdk.org> wrote:

> How do I use this to see the problem ?

This test does reproduce the problem.

I searched for the symptoms of this bugs because I saw a discussion about it, but I couldn't find anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29874#discussion_r2843230598

From aivanov at openjdk.org  Mon Feb 23 21:51:39 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Feb 2026 21:51:39 GMT
Subject: RFR: 8378417: Printing All pages results in NPE for 1.1 PrintJob
In-Reply-To: <qiwxeK5fkJFpex2WBeo0Lxn_cTYZU_eEslcZx0VDDiE=.298e0f01-59af-4d72-bbd9-714bfc70bdc6@github.com>
References: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
 <qiwxeK5fkJFpex2WBeo0Lxn_cTYZU_eEslcZx0VDDiE=.298e0f01-59af-4d72-bbd9-714bfc70bdc6@github.com>
Message-ID: <QfoZpRlmmWlC1BZsMKObAdlLlFfEF_hq6KHf31_MgQc=.aa77773b-1771-463d-ae2a-5521a8cb85bd@github.com>

On Mon, 23 Feb 2026 21:27:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> After [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239):, Printing ALL pages results in NPE for 1.1 PrintJob because of lack of set pageranges citing
>> 
>> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Cannot invoke "javax.print.attribute.standard.PageRanges.getMembers()" because "range" is null
>>         at java.desktop/sun.print.PrintJobDelegate.updateAttributes(PrintJobDelegate.java:529)
>>         at java.desktop/sun.print.PrintJobDelegate.printDialog(PrintJobDelegate.java:424)
>>         at java.desktop/sun.print.PrintJob2D.printDialog(PrintJob2D.java:65)
>>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:644)
>>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:629) 
>> 
>> A null check is now added as we are now removing PageRange attribute if not set..It works fine for PrinterJob but fails for 1.1 PrintJob as PrintJobDelegate.updateAttributes called in 1.1 PrintJob use pageRange variable without checking if it exists.
>
> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 529:
> 
>> 527: 
>> 528:         PageRanges range = (PageRanges)attributes.get(PageRanges.class);
>> 529:         if (range != null) {
> 
> I wonder if this is right ?
> Surely if the PageRanges is not there any more, we should update the JobAttributes to a default range ?
> This would leave whatever stale value is present.

I looked at the code review #29312 for [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239)? and wondered whether that code should rather ensure `PageRanges.class` attribute is present instead of removing it and the range to the default value.

https://github.com/openjdk/jdk/blob/6b576235b84f51e273da44158bfcadbb48f51baa/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1737-L1739

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29874#discussion_r2843246703

From prr at openjdk.org  Mon Feb 23 22:33:18 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 22:33:18 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v7]
In-Reply-To: <MonQN_x58T30JX78tfZ7HJeXdaRD1qLFV4tkZ46Bmrk=.879d0066-23e6-4637-8b74-5c1698931b96@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <OLFnr21zToRn9AdP1IZB1e5HZl-9PTWirAy4X-WeM_o=.9ff3bd33-69c9-4ff9-b359-d107fd476866@github.com>
 <MonQN_x58T30JX78tfZ7HJeXdaRD1qLFV4tkZ46Bmrk=.879d0066-23e6-4637-8b74-5c1698931b96@github.com>
Message-ID: <5-q03c7yPpXGnl4ROWmcOFy83ExH4Jt1R0a8zPBmddQ=.d6a4e7d9-e458-4c7c-a19e-72d11dfa922c@github.com>

On Mon, 23 Feb 2026 22:28:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8377568
>
> src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 571:
> 
>> 569:     }
>> 570: 
>> 571:     static final void checkNullArray(Object array, String name) {
> 
> Do we need this, or can it be replaced with Objects.requireNonNull? Alternatively, can we rely on implicit null checks when checking the size of the array? I think that would produce similar behavior to this method.

This was already raised and my response is that I want the custom message and also don't want to rely on implicit null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2843405368

From serb at openjdk.org  Mon Feb 23 22:33:17 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 22:33:17 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v7]
In-Reply-To: <OLFnr21zToRn9AdP1IZB1e5HZl-9PTWirAy4X-WeM_o=.9ff3bd33-69c9-4ff9-b359-d107fd476866@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <OLFnr21zToRn9AdP1IZB1e5HZl-9PTWirAy4X-WeM_o=.9ff3bd33-69c9-4ff9-b359-d107fd476866@github.com>
Message-ID: <MonQN_x58T30JX78tfZ7HJeXdaRD1qLFV4tkZ46Bmrk=.879d0066-23e6-4637-8b74-5c1698931b96@github.com>

On Fri, 20 Feb 2026 22:18:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
>> A new egression test for each of the constructor and getter/setter cases is supplied.
>> 
>> No existing regression tests fail with this change, and standard demos work.
>> 
>> Problems caused by these changes are most likely to occur if the client has a bug such that 
>> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
>> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
>> 
>> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
>> 
>> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8377568

src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 571:

> 569:     }
> 570: 
> 571:     static final void checkNullArray(Object array, String name) {

Do we need this, or can it be replaced with Objects.requireNonNull? Alternatively, can we rely on implicit null checks when checking the size of the array? I think that would produce similar behavior to this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2843397802

From serb at openjdk.org  Mon Feb 23 22:41:36 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 22:41:36 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager
In-Reply-To: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
Message-ID: <ItMgU8135yMyn3iypMN--xYWz3MxyoJR0dO0ecYWc7s=.f49c9324-554a-4ccb-bde6-d9040647c083@github.com>

On Sun, 22 Feb 2026 00:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from RepaintManager
> 
> Please review the CSR too.

src/java.desktop/share/classes/javax/swing/RepaintManager.java line 245:

> 243:      *          be used by an overridden version to return a different RepaintManager
> 244:      *          depending on the Component
> 245:      * @return the RepaintManager object

This spec looks broken as well, how this method could be "overridden"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2843434032

From serb at openjdk.org  Mon Feb 23 22:45:48 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 22:45:48 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager
In-Reply-To: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
Message-ID: <q3Ea--ResxxV3raKQHr3v5B9uHdpqChlk-VgYi-JdqQ=.d69e28ef-7def-4287-bc05-523805742ad3@github.com>

On Sun, 22 Feb 2026 00:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from RepaintManager
> 
> Please review the CSR too.

src/java.desktop/share/classes/javax/swing/RepaintManager.java line 259:

> 257:      * Returns the RepaintManager.
> 258:      */
> 259:     static RepaintManager currentManager() {

I think we should inline this method into currentManager(Component c) above and update all usages of currentManager(AppContext) to use the component instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2843447012

From serb at openjdk.org  Mon Feb 23 22:49:44 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 22:49:44 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v2]
In-Reply-To: <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>
Message-ID: <3uOw2GZulZdFYzLd8OLo0PQGpExnMIG99Oy04B5COeg=.986ea114-0eb5-4b31-a662-c13a6849beba@github.com>

On Mon, 23 Feb 2026 20:53:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from JEditorPane
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378377

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

> 1323:     private static final Hashtable<String, EditorKit> kitRegistry = new Hashtable<>(3);
> 1324: 
> 1325:     private static Hashtable<String, EditorKit> getKitRegistry() {

These getters seems unneeded anymore? the fields can be accessed in just a few methods directly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29855#discussion_r2843462992

From serb at openjdk.org  Mon Feb 23 22:51:39 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 22:51:39 GMT
Subject: RFR: 8378386: Remove AppContext from AWT ModalEventFilter.java
In-Reply-To: <fObg-UJKZJhnWUFIO6dQ-6flRUSWSy_A_dUSN7fIC_I=.b66ec145-014e-4079-ac4e-1d97f5b04938@github.com>
References: <fObg-UJKZJhnWUFIO6dQ-6flRUSWSy_A_dUSN7fIC_I=.b66ec145-014e-4079-ac4e-1d97f5b04938@github.com>
Message-ID: <cYCWTNJ5Fc7oxoA6HM3O_rKMq13KNy0-y7Xzy4iqp7E=.6abe20f2-a033-43fc-a3c5-882526aba5d6@github.com>

On Sat, 21 Feb 2026 20:32:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from java/awt/ModalEventFilter.java

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29859#pullrequestreview-3843931530

From serb at openjdk.org  Mon Feb 23 23:01:38 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 23:01:38 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v7]
In-Reply-To: <5-q03c7yPpXGnl4ROWmcOFy83ExH4Jt1R0a8zPBmddQ=.d6a4e7d9-e458-4c7c-a19e-72d11dfa922c@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <OLFnr21zToRn9AdP1IZB1e5HZl-9PTWirAy4X-WeM_o=.9ff3bd33-69c9-4ff9-b359-d107fd476866@github.com>
 <MonQN_x58T30JX78tfZ7HJeXdaRD1qLFV4tkZ46Bmrk=.879d0066-23e6-4637-8b74-5c1698931b96@github.com>
 <5-q03c7yPpXGnl4ROWmcOFy83ExH4Jt1R0a8zPBmddQ=.d6a4e7d9-e458-4c7c-a19e-72d11dfa922c@github.com>
Message-ID: <L4aNKcq6yrKRKjizQWYFPRwd-1JWcsOXG6Y1DHaJVEI=.88f5ccae-a3fd-486f-9df0-1f9e0bd22b08@github.com>

On Mon, 23 Feb 2026 22:30:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/image/DataBuffer.java line 571:
>> 
>>> 569:     }
>>> 570: 
>>> 571:     static final void checkNullArray(Object array, String name) {
>> 
>> Do we need this, or can it be replaced with Objects.requireNonNull? Alternatively, can we rely on implicit null checks when checking the size of the array? I think that would produce similar behavior to this method.
>
> This was already raised and my response is that I want the custom message and also don't want to rely on implicit null.

There is a requireNonNull version with custom message, why this new one is better than in Objects?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2843503858

From serb at openjdk.org  Mon Feb 23 23:04:32 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 23:04:32 GMT
Subject: RFR: 8378387: Remove AppContext from several macOS AWT classes
In-Reply-To: <hiSGCYboiSxd9IrLtN_RTbq2X4UDZckWv5Ma9UaK7E0=.723817db-d4a3-43a4-98f3-1e736d65005e@github.com>
References: <hiSGCYboiSxd9IrLtN_RTbq2X4UDZckWv5Ma9UaK7E0=.723817db-d4a3-43a4-98f3-1e736d65005e@github.com>
Message-ID: <-XfceygbJGZ8fjLBV25JMiu_9IzBMTBmDuFNQOOQorE=.9af7fd28-fef2-4772-a215-123187a85c1a@github.com>

On Sat, 21 Feb 2026 20:38:16 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from several LAWT classes.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29860#pullrequestreview-3843994909

From prr at openjdk.org  Mon Feb 23 23:10:17 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 23:10:17 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager
In-Reply-To: <ItMgU8135yMyn3iypMN--xYWz3MxyoJR0dO0ecYWc7s=.f49c9324-554a-4ccb-bde6-d9040647c083@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
 <ItMgU8135yMyn3iypMN--xYWz3MxyoJR0dO0ecYWc7s=.f49c9324-554a-4ccb-bde6-d9040647c083@github.com>
Message-ID: <T3Q1VDFcFVcIqUYLXCSC8hrXyvV9OQq6bq-b_5rg8Rg=.8058a772-82aa-4a8b-b8d4-a5047fb554a3@github.com>

On Mon, 23 Feb 2026 22:38:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Remove AppContext from RepaintManager
>> 
>> Please review the CSR too.
>
> src/java.desktop/share/classes/javax/swing/RepaintManager.java line 245:
> 
>> 243:      *          be used by an overridden version to return a different RepaintManager
>> 244:      *          depending on the Component
>> 245:      * @return the RepaintManager object
> 
> This spec looks broken as well, how this method could be "overridden"?

I don't think it can mean the method is overridden.
Probably  it means a hypothetical implementation of RepaintManager could return a per-component instance. 
Not sure I want to try to reword that as part of this change.

But I notice this also mentions "thread". I will fix that.

> src/java.desktop/share/classes/javax/swing/RepaintManager.java line 259:
> 
>> 257:      * Returns the RepaintManager.
>> 258:      */
>> 259:     static RepaintManager currentManager() {
> 
> I think we should inline this method into currentManager(Component c) above and update all usages of currentManager(AppContext) to use the component instead.

I think that's just the cases seen in this PR already - 4 of them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2843498103
PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2843531401

From prr at openjdk.org  Mon Feb 23 23:34:55 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 23:34:55 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v8]
In-Reply-To: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
Message-ID: <mxzX3fEnXlmIsbzwwbHOwIfFlGmeTIzn9N9H1-EsEz4=.3a23c212-6d56-4a78-aee8-b645b2c76b62@github.com>

> This fix updates DataBuffer subclasses to actually adhere to their stated specifications by rejecting certain invalid parameters for constructors and getters and setters.
> A new egression test for each of the constructor and getter/setter cases is supplied.
> 
> No existing regression tests fail with this change, and standard demos work.
> 
> Problems caused by these changes are most likely to occur if the client has a bug such that 
> - a client uses the constructors that accept an array and then supplies a "size" that is greater than the array.
> - a client uses the constructors that accept an array and then supplies a "size" that is less than the array and then uses getter/setters that are within the array but outside the range specified by size. 
> 
> Since very few clients (and just one case in the JDK that I found) even use these array constructors the changes are unlikely to make a difference to clients.
> 
> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8378116

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

  8377568

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29766/files
  - new: https://git.openjdk.org/jdk/pull/29766/files/587b6a7e..c406186f

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

  Stats: 56 lines in 7 files changed: 6 ins; 8 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/29766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29766/head:pull/29766

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

From prr at openjdk.org  Mon Feb 23 23:34:56 2026
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Feb 2026 23:34:56 GMT
Subject: RFR: 8377568: DataBuffer constructors and methods do not specify
 required exceptions [v7]
In-Reply-To: <L4aNKcq6yrKRKjizQWYFPRwd-1JWcsOXG6Y1DHaJVEI=.88f5ccae-a3fd-486f-9df0-1f9e0bd22b08@github.com>
References: <dZxanhwtGLp_uoL0nWx5Rv4mNeRolxm3DqjGl6YveNw=.d1a3d9f4-c3d2-495d-831d-a5336804138a@github.com>
 <OLFnr21zToRn9AdP1IZB1e5HZl-9PTWirAy4X-WeM_o=.9ff3bd33-69c9-4ff9-b359-d107fd476866@github.com>
 <MonQN_x58T30JX78tfZ7HJeXdaRD1qLFV4tkZ46Bmrk=.879d0066-23e6-4637-8b74-5c1698931b96@github.com>
 <5-q03c7yPpXGnl4ROWmcOFy83ExH4Jt1R0a8zPBmddQ=.d6a4e7d9-e458-4c7c-a19e-72d11dfa922c@github.com>
 <L4aNKcq6yrKRKjizQWYFPRwd-1JWcsOXG6Y1DHaJVEI=.88f5ccae-a3fd-486f-9df0-1f9e0bd22b08@github.com>
Message-ID: <idPmQa-KSYA629zn4xWDPGH8X9u2aDhskyiAicp8q5Q=.058bb6a0-df14-4af8-886c-5b43975aaa34@github.com>

On Mon, 23 Feb 2026 22:58:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This was already raised and my response is that I want the custom message and also don't want to rely on implicit null.
>
> There is a requireNonNull version with custom message, why this new one is better than in Objects?

Not sure it matters much. But I've updated to use O.rnn

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29766#discussion_r2843614036

From dnguyen at openjdk.org  Tue Feb 24 02:45:04 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Feb 2026 02:45:04 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v2]
In-Reply-To: <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>
Message-ID: <R2M9YMuhyYJbz-ZKqyQBcG3Udu9ZOOF-7vqp9L5TN4U=.f0166149-59cd-4bfc-b5d8-078c3775ddd0@github.com>

On Mon, 23 Feb 2026 20:53:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from JEditorPane
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378377

Looks fine to me now. There may be merit to removing `getKitRegistry` method but it's used a couple times throughout and would require additional changes as well.

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

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29855#pullrequestreview-3844712395

From psadhukhan at openjdk.org  Tue Feb 24 03:32:44 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 24 Feb 2026 03:32:44 GMT
Subject: RFR: 8378417: Printing All pages results in NPE for 1.1 PrintJob
 [v2]
In-Reply-To: <QfoZpRlmmWlC1BZsMKObAdlLlFfEF_hq6KHf31_MgQc=.aa77773b-1771-463d-ae2a-5521a8cb85bd@github.com>
References: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
 <qiwxeK5fkJFpex2WBeo0Lxn_cTYZU_eEslcZx0VDDiE=.298e0f01-59af-4d72-bbd9-714bfc70bdc6@github.com>
 <QfoZpRlmmWlC1BZsMKObAdlLlFfEF_hq6KHf31_MgQc=.aa77773b-1771-463d-ae2a-5521a8cb85bd@github.com>
Message-ID: <B3W_SkuXYezN4oThaArD3n_XR9WS0HP4QPVi90WCq48=.44ffca54-348e-44fa-b429-44ea5b517a7b@github.com>

On Mon, 23 Feb 2026 21:47:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 529:
>> 
>>> 527: 
>>> 528:         PageRanges range = (PageRanges)attributes.get(PageRanges.class);
>>> 529:         if (range != null) {
>> 
>> I wonder if this is right ?
>> Surely if the PageRanges is not there any more, we should update the JobAttributes to a default range ?
>> This would leave whatever stale value is present.
>
> I looked at the code review #29312 for [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239)? and wondered whether that code should rather ensure `PageRanges.class` attribute is present instead of removing it and the range to the default value.
> 
> https://github.com/openjdk/jdk/blob/6b576235b84f51e273da44158bfcadbb48f51baa/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1737-L1739

> I wonder if this is right ? Surely if the PageRanges is not there any more, we should update the JobAttributes to a default range ? This would leave whatever stale value is present.

Since null check is being frowned upon, I have modified [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239) fix to not remove PageRanges attribute and set it to default value incase native code doesn't set `isRangeSet` parameter via JNI.

The default value of PageRanges according to spec  
https://docs.oracle.com/en/java/javase/25/docs/api/java.desktop/javax/print/attribute/standard/PageRanges.html

`In other words, the default value for the PageRanges attribute is always {{1, Integer.MAX_VALUE}}. ` 

and having Pageable.UNKNOWN_NUMBER_OF_PAGES will cause IllegalArgumentException 
https://github.com/openjdk/jdk/blob/f25d429c8d6d099666aefd698ed14628cce5b1cf/src/java.desktop/share/classes/javax/print/attribute/standard/PageRanges.java#L193-L194


but kept setPageRanges value same as Pageable.UNKNOWN_NUMBER_OF_PAGES to honour its spec

https://github.com/openjdk/jdk/blob/f25d429c8d6d099666aefd698ed14628cce5b1cf/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L1847-L1858

Regarding test, since the problem is reproduced in 1.1 PrintJob by just selecting "ALL" in print dialog, which is the default selection, [and there is no need to verify actual print output] and since ScaledImagePrinting test uses default printdialog settings, it will reproduce the issue and it will also avoid another new manual printing test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29874#discussion_r2844282422

From psadhukhan at openjdk.org  Tue Feb 24 03:32:41 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 24 Feb 2026 03:32:41 GMT
Subject: RFR: 8378417: Printing All pages results in NPE for 1.1 PrintJob
 [v2]
In-Reply-To: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
References: <0N_xbPDmHITAGAUjI0_ST88obFMLDkNZ1hB93Z5N_yw=.2898ba0a-aaf1-4e6e-b662-c07e1cf9347a@github.com>
Message-ID: <8KAAmMsp2N3gOB8Hs7od-VGlaPKSVXLicoItxzRpkoc=.ddd6d87e-27b4-4cc3-a150-dfd3e0fdc3d6@github.com>

> After [JDK-8373239](https://bugs.openjdk.org/browse/JDK-8373239):, Printing ALL pages results in NPE for 1.1 PrintJob because of lack of set pageranges citing
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Cannot invoke "javax.print.attribute.standard.PageRanges.getMembers()" because "range" is null
>         at java.desktop/sun.print.PrintJobDelegate.updateAttributes(PrintJobDelegate.java:529)
>         at java.desktop/sun.print.PrintJobDelegate.printDialog(PrintJobDelegate.java:424)
>         at java.desktop/sun.print.PrintJob2D.printDialog(PrintJob2D.java:65)
>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:644)
>         at java.desktop/sun.awt.windows.WToolkit.getPrintJob(WToolkit.java:629) 
> 
> A null check is now added as we are now removing PageRange attribute if not set..It works fine for PrinterJob but fails for 1.1 PrintJob as PrintJobDelegate.updateAttributes called in 1.1 PrintJob use pageRange variable without checking if it exists.

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

  Set default value for PageRange

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29874/files
  - new: https://git.openjdk.org/jdk/pull/29874/files/f19e7c15..de297002

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

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

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

From psadhukhan at openjdk.org  Tue Feb 24 03:36:54 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 24 Feb 2026 03:36:54 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v2]
In-Reply-To: <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>
Message-ID: <wLljg7HHwift6n2NT9T9CTsGVvI8NtpgApkw4NIQEd8=.d31b2c35-d33f-4866-ba33-3ef19d8227b8@github.com>

On Mon, 23 Feb 2026 20:53:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from JEditorPane
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378377

LGTM

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29855#pullrequestreview-3844846412

From rkannathpari at openjdk.org  Tue Feb 24 03:46:45 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 24 Feb 2026 03:46:45 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v2]
In-Reply-To: <ZNK5fE14VqrWZPK4tE-ElXnPNhzPYFCXSWTeZhUGljQ=.b4f5809a-111e-4cfb-a683-4e4837c88b6a@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <-coMGul055zz-sujPn17jlqKtHZEqabO-OYIIYEn-vY=.92ad69d6-e0f8-4248-a7bf-f2614a183c87@github.com>
 <ZNK5fE14VqrWZPK4tE-ElXnPNhzPYFCXSWTeZhUGljQ=.b4f5809a-111e-4cfb-a683-4e4837c88b6a@github.com>
Message-ID: <BdJBcYYg2kAjm0A2_c0JWYA5lFAGWWaFl2jT5RdlyD8=.c8ee69f9-2f5e-41fd-9ff0-e8e28de979a0@github.com>

On Sun, 22 Feb 2026 00:30:31 GMT, Jean-No?l Rouvignac <duke at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright year
>
> src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 1614:
> 
>> 1612: 
>> 1613:         } catch (Throwable printError) {
>> 1614:             if (printError instanceof PrinterException) {
> 
> Suggestion:
> 
>         } catch (PrinterException e) {
>             throw e;
>         } catch (Throwable printError) {
>             throw (PrinterException)
>                     new PrinterException().initCause(printError.getCause());

Thank you @JnRouvignac, for you time and suggestion, I have updated based on your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29733#discussion_r2844322126

From jdv at openjdk.org  Tue Feb 24 04:08:45 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 24 Feb 2026 04:08:45 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v5]
In-Reply-To: <FzXHIQv5RI1OOFOPARquL3HB9-VkWViL-BjmxDS34I4=.42ccc740-efc6-4618-a4a1-512d25532002@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <FzXHIQv5RI1OOFOPARquL3HB9-VkWViL-BjmxDS34I4=.42ccc740-efc6-4618-a4a1-512d25532002@github.com>
Message-ID: <WA-Qyeti3jAnox1Ya1Wvg85ITyVNm_3bfa0cUeIcy08=.3b807352-2912-44ac-9d49-3ec2ceb2b428@github.com>

On Mon, 23 Feb 2026 20:27:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
>> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
>> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
>> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
>> 
>> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
>> I did that and ran all our existing automated tests on our CI systems.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8373626

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29257#pullrequestreview-3844921386

From psadhukhan at openjdk.org  Tue Feb 24 04:42:49 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 24 Feb 2026 04:42:49 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
Message-ID: <odqyvMVsv-Hg9NCC0hK7NcH0QiIRda4nBVYcNifY23Q=.94bef2e2-f964-4959-bb22-ff4134e5e181@github.com>

On Mon, 16 Feb 2026 10:43:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The FocusTraversalPolicy of a JOptionPane (JDialog) "reports" via `FocusTraversalPolicy.getInitialComponent`/`FocusTraversalPolicy.getFirstComponnent` that the focusable component passed to a JOptionPane, should get the initial focus. This however doesn't always happen, as the text field's FocusListener methods focusGained and focusLost are not invoked.
> Fix is made to honor the first focusable component of custom component (if present) and set the focus accordingly..
> This will cause the component's focusGained/focusLost method to get called.
> CI testing is ok..

So, how can we decide? we can either close this as "Wont Fix" or fix as per this PR as it is not causing any regression

> > So, how can we decide? we can either close this as "Wont Fix" or fix as per this PR as it is not causing any regression
> 
> You could also do some research into how this API is actually used. Since you already started changing that method, I assume you have an idea why the method parameter should be used instead of the fields, as suggested by this PR.

It is only called from one place
https://github.com/openjdk/jdk/blob/cb3a57ccede6709205e75c7eb2ff9998cb7a82d0/src/java.desktop/share/classes/javax/swing/JOptionPane.java#L2300-L2303
and as per OptionPaneUI spec it should request the component to have focus which I believe the author of this method intended for the passed component else there is no need to pass in the param 

https://github.com/openjdk/jdk/blob/cb3a57ccede6709205e75c7eb2ff9998cb7a82d0/src/java.desktop/share/classes/javax/swing/plaf/OptionPaneUI.java#L44-L49

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

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3948951430

From bylokhov at amazon.com  Tue Feb 24 06:00:02 2026
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Mon, 23 Feb 2026 22:00:02 -0800
Subject: [External] : Re: Issues similar to JDK-8359433
In-Reply-To: <FRSP281MB5667BBBD5B9922DF65956007ED6BA@FRSP281MB5667.DEUP281.PROD.OUTLOOK.COM>
References: <FRSP281MB5667BBBD5B9922DF65956007ED6BA@FRSP281MB5667.DEUP281.PROD.OUTLOOK.COM>
Message-ID: <58bc077f-d3d3-40f7-b949-5eb05413698e@amazon.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20260223/970ca855/attachment-0001.htm>

From psadhukhan at openjdk.org  Tue Feb 24 06:09:09 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 24 Feb 2026 06:09:09 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v3]
In-Reply-To: <lrUvNM0qPZXIkpRaeIJjcvkf8Pg5cIUBFTx1ZIU2PBY=.a03abaaa-f766-48b6-b8e5-8c7f71bbc474@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <lrUvNM0qPZXIkpRaeIJjcvkf8Pg5cIUBFTx1ZIU2PBY=.a03abaaa-f766-48b6-b8e5-8c7f71bbc474@github.com>
Message-ID: <FDH8rpxsjevPAI6b0h26SZaHz6QPSabe0S2tTD-EfVQ=.3dde2c41-b25d-4d83-b5f6-2aa57071d4cd@github.com>

On Mon, 23 Feb 2026 04:56:55 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on suggesion

test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java line 66:

> 64:                 "Test started. threadType='%s', exceptionType='%s'",
> 65:                 threadType, exceptionType));
> 66: 

I believe this test is passing without the fix...It would be better to have a test where you can throw a RTE forcefully and which would fail if it gets an exception other than PrinterException

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29733#discussion_r2844722689

From serb at openjdk.org  Tue Feb 24 06:30:35 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Feb 2026 06:30:35 GMT
Subject: RFR: 8378057: CAccessibility roleKey and
 AWTAccessor.AccessibleBundleAccessor are Redundant
In-Reply-To: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
References: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
Message-ID: <4s8TPH2rcJwsqzfsKGZMAQd7huFAjNLBDOXw5zSwZ8k=.740a6c74-6355-4897-8f9f-ebcfea806610@github.com>

On Sun, 22 Feb 2026 19:26:37 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> This PR proposes replacing the native `roleKey` method with the `AWTAccessor.AccessibleBundleAccessor`. They appear to do the same thing.
> 
> I ran all the existing jtreg tests in the javax/accessibility folder and observed no new regressions (tested on Mac).

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 1041:

> 1039:                     String roleStr = role == null ? null :
> 1040:                             AWTAccessor.getAccessibleBundleAccessor().getKey(role);
> 1041:                     if (role != null && ignoredRoles != null &&

this can be changed to roleStr != null?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29868#discussion_r2844805891

From jwood at openjdk.org  Tue Feb 24 06:44:20 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Tue, 24 Feb 2026 06:44:20 GMT
Subject: RFR: 8378057: CAccessibility roleKey and
 AWTAccessor.AccessibleBundleAccessor are Redundant [v2]
In-Reply-To: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
References: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
Message-ID: <cbyJybgFYp5T2v4-_tXBzRjVeaHIM8XGkRG_HC0KDaw=.bba881a8-5dcd-448c-aeef-b8b29fb0ed70@github.com>

> This PR proposes replacing the native `roleKey` method with the `AWTAccessor.AccessibleBundleAccessor`. They appear to do the same thing.
> 
> I ran all the existing jtreg tests in the javax/accessibility folder and observed no new regressions (tested on Mac).

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

  8378057: changing null check
  
  This is in response to:
  https://github.com/openjdk/jdk/pull/29868#discussion_r2844805891

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29868/files
  - new: https://git.openjdk.org/jdk/pull/29868/files/8c74bfcf..0f01ea62

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

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

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

From jwood at openjdk.org  Tue Feb 24 06:44:22 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Tue, 24 Feb 2026 06:44:22 GMT
Subject: RFR: 8378057: CAccessibility roleKey and
 AWTAccessor.AccessibleBundleAccessor are Redundant [v2]
In-Reply-To: <4s8TPH2rcJwsqzfsKGZMAQd7huFAjNLBDOXw5zSwZ8k=.740a6c74-6355-4897-8f9f-ebcfea806610@github.com>
References: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
 <4s8TPH2rcJwsqzfsKGZMAQd7huFAjNLBDOXw5zSwZ8k=.740a6c74-6355-4897-8f9f-ebcfea806610@github.com>
Message-ID: <f_USlKqmxmqcJ0J4mrrC0DXcmPbH7pBuZV4kt_q-YCQ=.e09fd46e-c2a1-4369-9ddc-fa63ab7523fb@github.com>

On Tue, 24 Feb 2026 06:28:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378057: changing null check
>>   
>>   This is in response to:
>>   https://github.com/openjdk/jdk/pull/29868#discussion_r2844805891
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 1041:
> 
>> 1039:                     String roleStr = role == null ? null :
>> 1040:                             AWTAccessor.getAccessibleBundleAccessor().getKey(role);
>> 1041:                     if (role != null && ignoredRoles != null &&
> 
> this can be changed to roleStr != null?

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29868#discussion_r2844862810

From tr at openjdk.org  Tue Feb 24 09:16:39 2026
From: tr at openjdk.org (Tejesh R)
Date: Tue, 24 Feb 2026 09:16:39 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F
In-Reply-To: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
Message-ID: <L5nL_Ew10nEFf09oZbnwN5ev4ee5tmdyX6xwLalPYLM=.9ee081fc-e249-49e4-9c09-bad862817482@github.com>

On Thu, 19 Feb 2026 02:52:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
> 
> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
> 
> Without fix
> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
> 
> With fix
> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />

The fix solves the issue, yet I feel this is not addressing the root of the issue. Did you find out exactly why mouse press is not captured in right half when text is 0 length ?

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

PR Review: https://git.openjdk.org/jdk/pull/29808#pullrequestreview-3846217901

From rkannathpari at openjdk.org  Tue Feb 24 10:32:10 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 24 Feb 2026 10:32:10 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v3]
In-Reply-To: <FDH8rpxsjevPAI6b0h26SZaHz6QPSabe0S2tTD-EfVQ=.3dde2c41-b25d-4d83-b5f6-2aa57071d4cd@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <lrUvNM0qPZXIkpRaeIJjcvkf8Pg5cIUBFTx1ZIU2PBY=.a03abaaa-f766-48b6-b8e5-8c7f71bbc474@github.com>
 <FDH8rpxsjevPAI6b0h26SZaHz6QPSabe0S2tTD-EfVQ=.3dde2c41-b25d-4d83-b5f6-2aa57071d4cd@github.com>
Message-ID: <WWgchxqlqWsNCyV_xjnzyQUfJFMpZHblP37G_sya2Ak=.ad76df0a-74a9-41d8-bea7-9519673f2d1d@github.com>

On Tue, 24 Feb 2026 06:06:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on suggesion
>
> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java line 66:
> 
>> 64:                 "Test started. threadType='%s', exceptionType='%s'",
>> 65:                 threadType, exceptionType));
>> 66: 
> 
> I believe this test is passing without the fix...It would be better to have a test where you can throw a RTE forcefully and which would fail if it gets an exception other than PrinterException

With out fix test throwing **Unexpected exception was thrown** for argument `MAIN RE`, please find the message. **MAIN/EDT RE** was skipped earlier for Windows and Linux. 


java.lang.RuntimeException: Exception from 'Printable.print'.
        at ExceptionFromPrintableIsIgnoredTest$2.print(ExceptionFromPrintableIsIgnoredTest.java:110)
        at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2214)
        at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1603)
        at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1433)
        at ExceptionFromPrintableIsIgnoredTest.runTest(ExceptionFromPrintableIsIgnoredTest.java:118)
        at ExceptionFromPrintableIsIgnoredTest.<init>(ExceptionFromPrintableIsIgnoredTest.java:70)
        at ExceptionFromPrintableIsIgnoredTest.main(ExceptionFromPrintableIsIgnoredTest.java:57)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:260)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
Exception in thread "main" java.lang.RuntimeException: Unexpected exception was thrown.
        at ExceptionFromPrintableIsIgnoredTest.<init>(ExceptionFromPrintableIsIgnoredTest.java:87)
        at ExceptionFromPrintableIsIgnoredTest.main(ExceptionFromPrintableIsIgnoredTest.java:57)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29733#discussion_r2845941263

From aivanov at openjdk.org  Tue Feb 24 15:59:20 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Feb 2026 15:59:20 GMT
Subject: RFR: 8378578: Add final to XbmColormap and XbmHints in XbmImageDecoder
Message-ID: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>

A trivial clean up for `XbmImageDecoder` that marks the fields `XbmColormap` and `XbmHints` with the `final` modifier. These fields are constants.

In addition to the above, improve the javadoc by using the `@snippet`. Otherwise, all the lines of the XBM snippet are combined into one line.

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

Commit messages:
 - 8378578: Add final to XbmColormap and XbmHints in XbmImageDecoder

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

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

From dmarkov at openjdk.org  Tue Feb 24 16:04:39 2026
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 24 Feb 2026 16:04:39 GMT
Subject: RFR: 8378578: Add final to XbmColormap and XbmHints in
 XbmImageDecoder
In-Reply-To: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
References: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
Message-ID: <xBdbWn4DVKQ0ovUFduCJ-SF98V0FVDKUIJXtbkh4T2k=.278006ca-10a3-4849-8f8c-824167f21dfd@github.com>

On Tue, 24 Feb 2026 15:50:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial clean up for `XbmImageDecoder` that marks the fields `XbmColormap` and `XbmHints` with the `final` modifier. These fields are constants.
> 
> In addition to the above, improve the javadoc by using the `@snippet`. Otherwise, all the lines of the XBM snippet are combined into one line.

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29896#pullrequestreview-3848931407

From aivanov at openjdk.org  Tue Feb 24 17:10:28 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Feb 2026 17:10:28 GMT
Subject: RFR: 8378585: Mark fields in MediaTracker final
Message-ID: <mdNPq4UU5GNn5zf9sO3wVnOx3XPEc8866CmVLqYiqos=.11d7ce0e-8ec3-4e3f-abf8-ac0501f78c65@github.com>

During the discussions in https://github.com/openjdk/jdk/pull/29433, I looked at the source code of `MediaTracker` and found several issues for cleaning up.

- The `target` field in `MediaTracker` is initialised in the constructor, it's never changed;
- The visibility of the `head` field in `MediaTracker` can be reduced to `private`;
- The `tracker` and `ID` fields in the `MediaEntry` class are never changed after being set in the constructor, therefore it's `final`;
- The `getID` method of `MediaEntry` should be `final`, subclasses shouldn't be able to change the returned id;
- The fields in `ImageMediaEntry`?`image`, `width` and `height`?can also be `final`.
- The `ImageMediaEntry` class itself is `final`.

Additionally, I added the `@Override` annotation to overridden methods.

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

Commit messages:
 - 8378585: Mark fields in MediaTracker final

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

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

From serb at openjdk.org  Tue Feb 24 17:18:38 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Feb 2026 17:18:38 GMT
Subject: RFR: 8378585: Mark fields in MediaTracker final
In-Reply-To: <mdNPq4UU5GNn5zf9sO3wVnOx3XPEc8866CmVLqYiqos=.11d7ce0e-8ec3-4e3f-abf8-ac0501f78c65@github.com>
References: <mdNPq4UU5GNn5zf9sO3wVnOx3XPEc8866CmVLqYiqos=.11d7ce0e-8ec3-4e3f-abf8-ac0501f78c65@github.com>
Message-ID: <ULq0hoPtOvS9lFqXlMSzcz3GFqroCsW0jhcLDYV2BNY=.7688661f-d458-401c-b536-4aa9779c831c@github.com>

On Tue, 24 Feb 2026 17:02:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> During the discussions in https://github.com/openjdk/jdk/pull/29433, I looked at the source code of `MediaTracker` and found several issues for cleaning up.
> 
> - The `target` field in `MediaTracker` is initialised in the constructor, it's never changed;
> - The visibility of the `head` field in `MediaTracker` can be reduced to `private`;
> - The `tracker` and `ID` fields in the `MediaEntry` class are never changed after being set in the constructor, therefore it's `final`;
> - The `getID` method of `MediaEntry` should be `final`, subclasses shouldn't be able to change the returned id;
> - The fields in `ImageMediaEntry`?`image`, `width` and `height`?can also be `final`.
> - The `ImageMediaEntry` class itself is `final`.
> 
> Additionally, I added the `@Override` annotation to overridden methods.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29899#pullrequestreview-3849388277

From aron.rahman at parcit.de  Tue Feb 24 11:49:03 2026
From: aron.rahman at parcit.de (Aron Rahman)
Date: Tue, 24 Feb 2026 11:49:03 +0000
Subject: [External] : AW: Issues similar to JDK-8359433
In-Reply-To: <58bc077f-d3d3-40f7-b949-5eb05413698e@amazon.com>
References: <FRSP281MB5667BBBD5B9922DF65956007ED6BA@FRSP281MB5667.DEUP281.PROD.OUTLOOK.COM>
 <58bc077f-d3d3-40f7-b949-5eb05413698e@amazon.com>
Message-ID: <FRSP281MB5667A61E3747FF18B2D79BB8ED74A@FRSP281MB5667.DEUP281.PROD.OUTLOOK.COM>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20260224/a47d937e/attachment-0001.htm>

From prr at openjdk.org  Tue Feb 24 18:17:46 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 18:17:46 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v3]
In-Reply-To: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
Message-ID: <U4dyRDXjzYtFqLLZiAQPCLxi3IDapS3F59U_GpxHyso=.1bf8b363-ed7a-40d5-afe7-2e37c4632260@github.com>

> Remove AppContext from JEditorPane

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

  8378377

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29855/files
  - new: https://git.openjdk.org/jdk/pull/29855/files/c0cb0a30..a29d2c66

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

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

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

From prr at openjdk.org  Tue Feb 24 18:17:50 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 18:17:50 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v2]
In-Reply-To: <3uOw2GZulZdFYzLd8OLo0PQGpExnMIG99Oy04B5COeg=.986ea114-0eb5-4b31-a662-c13a6849beba@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <pp-qAUJ-1yrX3RAepgEDPNDzkm1TY3fG3_sZU4V1Pcs=.952ebf2d-ef5e-41d2-988f-bcee66afcef5@github.com>
 <3uOw2GZulZdFYzLd8OLo0PQGpExnMIG99Oy04B5COeg=.986ea114-0eb5-4b31-a662-c13a6849beba@github.com>
Message-ID: <pFEv60HVvV0eAQQy5RIJdCs5tC51N-4ZF02xcL1qNe0=.f404ca7f-b6b7-4b76-a623-9f8d4c2679a8@github.com>

On Mon, 23 Feb 2026 22:47:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378377
>
> src/java.desktop/share/classes/javax/swing/JEditorPane.java line 1325:
> 
>> 1323:     private static final Hashtable<String, EditorKit> kitRegistry = new Hashtable<>(3);
>> 1324: 
>> 1325:     private static Hashtable<String, EditorKit> getKitRegistry() {
> 
> These getters seems unneeded anymore? the fields can be accessed in just a few methods directly?

Ok. I eliminated the getters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29855#discussion_r2848798033

From prr at openjdk.org  Tue Feb 24 18:36:02 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 18:36:02 GMT
Subject: RFR: 8376152: Test javax/sound/sampled/Clip/bug5070081.java timed out
 then completed
Message-ID: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>

I've run this test and it definitely needs a sound device.
So I've added the jtreg key for sound, so we can always run it where there's sound support.

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

Commit messages:
 - 8376152
 - 8376152

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

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

From prr at openjdk.org  Tue Feb 24 18:42:48 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 18:42:48 GMT
Subject: RFR: 8378585: Mark fields in MediaTracker final
In-Reply-To: <mdNPq4UU5GNn5zf9sO3wVnOx3XPEc8866CmVLqYiqos=.11d7ce0e-8ec3-4e3f-abf8-ac0501f78c65@github.com>
References: <mdNPq4UU5GNn5zf9sO3wVnOx3XPEc8866CmVLqYiqos=.11d7ce0e-8ec3-4e3f-abf8-ac0501f78c65@github.com>
Message-ID: <OZE4gU2YU548f-0PiDReSjRFU9SpYBAqRsHbyVmaqJA=.64706ae5-fa6a-42db-9817-99a42846d71b@github.com>

On Tue, 24 Feb 2026 17:02:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> During the discussions in https://github.com/openjdk/jdk/pull/29433, I looked at the source code of `MediaTracker` and found several issues for cleaning up.
> 
> - The `target` field in `MediaTracker` is initialised in the constructor, it's never changed;
> - The visibility of the `head` field in `MediaTracker` can be reduced to `private`;
> - The `tracker` and `ID` fields in the `MediaEntry` class are never changed after being set in the constructor, therefore it's `final`;
> - The `getID` method of `MediaEntry` should be `final`, subclasses shouldn't be able to change the returned id;
> - The fields in `ImageMediaEntry`?`image`, `width` and `height`?can also be `final`.
> - The `ImageMediaEntry` class itself is `final`.
> 
> Additionally, I added the `@Override` annotation to overridden methods.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29899#pullrequestreview-3849863492

From prr at openjdk.org  Tue Feb 24 18:53:00 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 18:53:00 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v2]
In-Reply-To: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
Message-ID: <qUiVTqkE7The9TZRhe6U9qYx38JeuQ_kiXc4jWaqNEs=.beecba63-f201-434d-aa04-310442510060@github.com>

> Remove AppContext from RepaintManager
> 
> Please review the CSR too.

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

  8378389

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29862/files
  - new: https://git.openjdk.org/jdk/pull/29862/files/ddd138cb..515dc6cb

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

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

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

From prr at openjdk.org  Tue Feb 24 18:53:03 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 18:53:03 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v2]
In-Reply-To: <T3Q1VDFcFVcIqUYLXCSC8hrXyvV9OQq6bq-b_5rg8Rg=.8058a772-82aa-4a8b-b8d4-a5047fb554a3@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
 <ItMgU8135yMyn3iypMN--xYWz3MxyoJR0dO0ecYWc7s=.f49c9324-554a-4ccb-bde6-d9040647c083@github.com>
 <T3Q1VDFcFVcIqUYLXCSC8hrXyvV9OQq6bq-b_5rg8Rg=.8058a772-82aa-4a8b-b8d4-a5047fb554a3@github.com>
Message-ID: <vlrzHooMwrUTkYeuoDKUSAU166VuTFavM_EYFTjlaFg=.e95dae95-98cf-477f-a747-26f7f99af050@github.com>

On Mon, 23 Feb 2026 22:57:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/RepaintManager.java line 245:
>> 
>>> 243:      *          be used by an overridden version to return a different RepaintManager
>>> 244:      *          depending on the Component
>>> 245:      * @return the RepaintManager object
>> 
>> This spec looks broken as well, how this method could be "overridden"?
>
> I don't think it can mean the method is overridden.
> Probably  it means a hypothetical implementation of RepaintManager could return a per-component instance. 
> Not sure I want to try to reword that as part of this change.
> 
> But I notice this also mentions "thread". I will fix that.

re-testing looks good. update pushed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2848955681

From serb at openjdk.org  Tue Feb 24 19:27:02 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Feb 2026 19:27:02 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v3]
In-Reply-To: <U4dyRDXjzYtFqLLZiAQPCLxi3IDapS3F59U_GpxHyso=.1bf8b363-ed7a-40d5-afe7-2e37c4632260@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <U4dyRDXjzYtFqLLZiAQPCLxi3IDapS3F59U_GpxHyso=.1bf8b363-ed7a-40d5-afe7-2e37c4632260@github.com>
Message-ID: <annycpCzJ4g_p0EHDKJU4H6vyGeKJUbI3kbJNhLC7RM=.faffd5e1-e461-4538-a3e8-eca695f78ba7@github.com>

On Tue, 24 Feb 2026 18:17:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from JEditorPane
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378377

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

> 1244:                 }
> 1245:                 k = (EditorKit) c.newInstance();
> 1246:                 kitRegistry.put(type, k);

Why this line is removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29855#discussion_r2849119243

From prr at openjdk.org  Tue Feb 24 19:31:25 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 19:31:25 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v2]
In-Reply-To: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
Message-ID: <Dky4ZYnNS2i9u1-J7i-4GTOJc8dJmL9RgYB5ov9l3X8=.725558d5-a1db-445a-83ff-4cc996fec048@github.com>

> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
> 
> One ToolTipManager test for the AppContext is removed.

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

  8378297

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29830/files
  - new: https://git.openjdk.org/jdk/pull/29830/files/2b813442..a4949913

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

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

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

From prr at openjdk.org  Tue Feb 24 19:31:27 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 19:31:27 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v2]
In-Reply-To: <MKwyhObgA1wUYRBYF10j4oV-XZOSxw-abw-qy1y6lKI=.dc8c3252-bbcb-438d-9923-a9fc826939c5@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <MKwyhObgA1wUYRBYF10j4oV-XZOSxw-abw-qy1y6lKI=.dc8c3252-bbcb-438d-9923-a9fc826939c5@github.com>
Message-ID: <HfTBu5Shd7iQuXT09CnsDIh1S0F_MHy9Dr9oolU9sHs=.de62cba6-595d-4b6b-b945-cb941224fd9e@github.com>

On Mon, 23 Feb 2026 09:46:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378297
>
> src/java.desktop/share/classes/javax/swing/PopupFactory.java line 723:
> 
>> 721:          */
>> 722:         private static List<LightWeightPopup> getLightWeightPopupCache() {
>> 723:             synchronized (PopupFactory.class) {
> 
> I believe it should synchronize on LightWeightPopup class and not on PopupFactory?

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2849133507

From serb at openjdk.org  Tue Feb 24 19:36:18 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Feb 2026 19:36:18 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v2]
In-Reply-To: <qUiVTqkE7The9TZRhe6U9qYx38JeuQ_kiXc4jWaqNEs=.beecba63-f201-434d-aa04-310442510060@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
 <qUiVTqkE7The9TZRhe6U9qYx38JeuQ_kiXc4jWaqNEs=.beecba63-f201-434d-aa04-310442510060@github.com>
Message-ID: <t6iZ9T9dE61xI5P3nlfofInlW3NcZBMjggMgo3kb_Gc=.baa2b831-3496-4e62-a45c-1e7a96724681@github.com>

On Tue, 24 Feb 2026 18:53:00 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from RepaintManager
>> 
>> Please review the CSR too.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378389

src/java.desktop/share/classes/javax/swing/RepaintManager.java line 261:

> 259:      */
> 260:     static RepaintManager currentManager(AppContext appContext) {
> 261:         RepaintManager rm = (RepaintManager)appContext.get(repaintManagerKey);

It is invisible in the diff but seems the repaintManagerKey field is not needed anymore?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2849160847

From serb at openjdk.org  Tue Feb 24 20:02:03 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Feb 2026 20:02:03 GMT
Subject: RFR: 8376152: Test javax/sound/sampled/Clip/bug5070081.java timed
 out then completed
In-Reply-To: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
References: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
Message-ID: <p3hJXreF-pr13IKO3OBK1c54c-neG7cg-tNOWd2axME=.0b9d3b90-a48f-4c1b-93f3-06e6aa7b9287@github.com>

On Tue, 24 Feb 2026 18:27:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I've run this test and it definitely needs a sound device.
> So I've added the jtreg key for sound, so we can always run it where there's sound support.

this test has a guard by LineUnavailableException/IllegalArgumentException --> the test is not applicable/
It is suspicion that it hangs when the report say "STATUS:Passed." What is the reason?

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

PR Comment: https://git.openjdk.org/jdk/pull/29901#issuecomment-3954411277

From serb at openjdk.org  Tue Feb 24 20:07:08 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 24 Feb 2026 20:07:08 GMT
Subject: RFR: 8378578: Add final to XbmColormap and XbmHints in
 XbmImageDecoder
In-Reply-To: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
References: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
Message-ID: <b1kq0INUF7ds7J15mnFQ7j1xBIVXLn-4sDArosj2xZo=.33df6fe9-0d0a-40e3-b0f4-5c7f42fd991a@github.com>

On Tue, 24 Feb 2026 15:50:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial clean up for `XbmImageDecoder` that marks the fields `XbmColormap` and `XbmHints` with the `final` modifier. These fields are constants.
> 
> In addition to the above, improve the javadoc by using the `@snippet`. Otherwise, all the lines of the XBM snippet are combined into one line.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29896#pullrequestreview-3850247367

From prr at openjdk.org  Tue Feb 24 20:10:09 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 20:10:09 GMT
Subject: RFR: 8378578: Add final to XbmColormap and XbmHints in
 XbmImageDecoder
In-Reply-To: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
References: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
Message-ID: <tn_7XzGIGHHdV_sNfHiPHUSzEq1EJbyan3U_5Z_wfN0=.f0106357-8de0-406b-9e92-54c2bcc41a86@github.com>

On Tue, 24 Feb 2026 15:50:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial clean up for `XbmImageDecoder` that marks the fields `XbmColormap` and `XbmHints` with the `final` modifier. These fields are constants.
> 
> In addition to the above, improve the javadoc by using the `@snippet`. Otherwise, all the lines of the XBM snippet are combined into one line.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29896#pullrequestreview-3850261504

From prr at openjdk.org  Tue Feb 24 20:12:27 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 20:12:27 GMT
Subject: RFR: 8378605: Remove AppContext from the Swing TimerQueue
 implementation
Message-ID: <hNbzVzZTAF-CceSIiP8XuOzOlYePbwXu6yP6Q1zy5X8=.30634a56-cbb2-4aed-9333-58fe9b07a52b@github.com>

Remove per-AppContext TimerQueue support. Just create one for the VM.
A test that expressly checked per-AppContext TimerQueue behaviour is removed.

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

Commit messages:
 - 8378605

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

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

From dnguyen at openjdk.org  Tue Feb 24 20:23:59 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Feb 2026 20:23:59 GMT
Subject: RFR: 8378387: Remove AppContext from several macOS AWT classes
In-Reply-To: <hiSGCYboiSxd9IrLtN_RTbq2X4UDZckWv5Ma9UaK7E0=.723817db-d4a3-43a4-98f3-1e736d65005e@github.com>
References: <hiSGCYboiSxd9IrLtN_RTbq2X4UDZckWv5Ma9UaK7E0=.723817db-d4a3-43a4-98f3-1e736d65005e@github.com>
Message-ID: <hrUxShExv-WodlNI0v2KZA7wzIogy15pPWBUYJDG7UU=.3b29ae7c-af89-42d7-a7bb-9997c50a950c@github.com>

On Sat, 21 Feb 2026 20:38:16 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from several LAWT classes.

Marked as reviewed by dnguyen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29860#pullrequestreview-3850321844

From dnguyen at openjdk.org  Tue Feb 24 20:40:03 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Feb 2026 20:40:03 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v2]
In-Reply-To: <Dky4ZYnNS2i9u1-J7i-4GTOJc8dJmL9RgYB5ov9l3X8=.725558d5-a1db-445a-83ff-4cc996fec048@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <Dky4ZYnNS2i9u1-J7i-4GTOJc8dJmL9RgYB5ov9l3X8=.725558d5-a1db-445a-83ff-4cc996fec048@github.com>
Message-ID: <03vNO_bFXczIF70L9gxd6iusL4muszXcDm3_-L3EfXk=.b4e1a09e-1aed-4463-9059-147e2c3e8ec7@github.com>

On Tue, 24 Feb 2026 19:31:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
>> 
>> One ToolTipManager test for the AppContext is removed.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378297

Changes requested by dnguyen (Reviewer).

Original issue I saw was due to my end. Deleted that change request comment after looking at this again and seeing it was correct in the `Files Changed`. Copied your changes again and it LGTM.

src/java.desktop/share/classes/javax/swing/JFrame.java line 752:

> 750: 
> 751:     private static boolean defaultLAFDecorated;
> 752:     /**

Suggestion:

    private static boolean defaultLAFDecorated;
    
/**


Nit but you have added a newline after similar `private static vars` for JDialog and JPopupMenu.

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

PR Review: https://git.openjdk.org/jdk/pull/29830#pullrequestreview-3850358168
Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29830#pullrequestreview-3850388210
PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2849411110

From prr at openjdk.org  Tue Feb 24 20:54:21 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 20:54:21 GMT
Subject: Integrated: 8378387: Remove AppContext from several macOS AWT classes
In-Reply-To: <hiSGCYboiSxd9IrLtN_RTbq2X4UDZckWv5Ma9UaK7E0=.723817db-d4a3-43a4-98f3-1e736d65005e@github.com>
References: <hiSGCYboiSxd9IrLtN_RTbq2X4UDZckWv5Ma9UaK7E0=.723817db-d4a3-43a4-98f3-1e736d65005e@github.com>
Message-ID: <qeoG8yTheBCnN62xYKXTZToBxpg5no_4bD9k0PY1sKM=.569996e7-d7b7-46e3-aba6-3a62e98b3987@github.com>

On Sat, 21 Feb 2026 20:38:16 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from several LAWT classes.

This pull request has now been integrated.

Changeset: 49158d35
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49158d354b0d31cb8821b9a35554fe46a388a036
Stats:     26 lines in 6 files changed: 0 ins; 9 del; 17 mod

8378387: Remove AppContext from several macOS AWT classes

Reviewed-by: serb, dnguyen

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

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

From prr at openjdk.org  Tue Feb 24 21:00:42 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 21:00:42 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v3]
In-Reply-To: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
Message-ID: <niRMjE01Hsxr14g4VpetWho706o1LDXo6ySWRlf_EiE=.a4b1c614-235f-495c-ada2-64635b6ed095@github.com>

> Remove AppContext from RepaintManager
> 
> Please review the CSR too.

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

  8378389

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29862/files
  - new: https://git.openjdk.org/jdk/pull/29862/files/515dc6cb..0be12b77

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

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

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

From prr at openjdk.org  Tue Feb 24 21:00:43 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Feb 2026 21:00:43 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v3]
In-Reply-To: <t6iZ9T9dE61xI5P3nlfofInlW3NcZBMjggMgo3kb_Gc=.baa2b831-3496-4e62-a45c-1e7a96724681@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
 <qUiVTqkE7The9TZRhe6U9qYx38JeuQ_kiXc4jWaqNEs=.beecba63-f201-434d-aa04-310442510060@github.com>
 <t6iZ9T9dE61xI5P3nlfofInlW3NcZBMjggMgo3kb_Gc=.baa2b831-3496-4e62-a45c-1e7a96724681@github.com>
Message-ID: <HiySbxGXgbg-DkJ_x_ifuZ5XK_L4xPmxx2vuZyHpKH0=.9a01e8f5-5349-4144-9528-6eb7efac556a@github.com>

On Tue, 24 Feb 2026 19:33:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378389
>
> src/java.desktop/share/classes/javax/swing/RepaintManager.java line 261:
> 
>> 259:      */
>> 260:     static RepaintManager currentManager(AppContext appContext) {
>> 261:         RepaintManager rm = (RepaintManager)appContext.get(repaintManagerKey);
> 
> It is invisible in the diff but seems the repaintManagerKey field is not needed anymore?

right not needed any more. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2849499516

From dnguyen at openjdk.org  Wed Feb 25 11:00:14 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Feb 2026 11:00:14 GMT
Subject: RFR: 8378578: Add final to XbmColormap and XbmHints in
 XbmImageDecoder
In-Reply-To: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
References: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
Message-ID: <WI1L4qL96hOLYiUNz5jNy32Dt-WQsXi16dHJq2rVpco=.06ba121c-b98c-410c-bfd2-cfc0090bf0d4@github.com>

On Tue, 24 Feb 2026 15:50:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial clean up for `XbmImageDecoder` that marks the fields `XbmColormap` and `XbmHints` with the `final` modifier. These fields are constants.
> 
> In addition to the above, improve the javadoc by using the `@snippet`. Otherwise, all the lines of the XBM snippet are combined into one line.

Marked as reviewed by dnguyen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29896#pullrequestreview-3850563072

From syan at openjdk.org  Wed Feb 25 11:00:22 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 25 Feb 2026 11:00:22 GMT
Subject: RFR: 8376152: Test javax/sound/sampled/Clip/bug5070081.java timed
 out then completed
In-Reply-To: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
References: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
Message-ID: <wxv3sbfws3cWDrL-zA6qnaKRYj_gyJO_DsJDOwFgwfA=.245fa3cf-d1ab-440f-8b3a-30ea80c7c7b4@github.com>

On Tue, 24 Feb 2026 18:27:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I've run this test and it definitely needs a sound device.
> So I've added the jtreg key for sound, so we can always run it where there's sound support.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/29901#pullrequestreview-3851708290

From jdv at openjdk.org  Wed Feb 25 11:04:50 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 25 Feb 2026 11:04:50 GMT
Subject: RFR: 8378623: Use unique font names in FormatCharAdvanceTest
Message-ID: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>

While working on [JDK-8373290](https://bugs.openjdk.org/browse/JDK-8373290), it is noticed that with FreeType update java/awt/font/TextLayout/FormatCharAdvanceTest.java is failing.

On more analysis it is found that this Test is not using appropriate FontMetrics under FontMetrics.stringWidth() and Font.getStringBounds("AB", frc) code path. Test continues to use Type1 FontMetrics for TTF font.

Freetype update just revealed this issue as "width" slightly changes between the Type1 and TTF font used in this test(This is happening because of hinting/rounding change in FreeType update). We are not seeing any change of Metrics for other Physical(Helvetica.ttf) or Logical(Dialog) fonts.

We have separate bug [JDK-8378622](https://bugs.openjdk.org/browse/JDK-8378622) to analyse and fix FontMetrics caching issue. We are updating FormatCharAdvanceTest to use unique "font name" for both Type1 and TTF font to pick valid FontMetrics and make this test work properly. Changing the font name will not affect the purpose of this test.

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

Commit messages:
 - 8378623: Use unique font names in FormatCharAdvanceTest

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

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

From prr at openjdk.org  Wed Feb 25 11:06:02 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 11:06:02 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v3]
In-Reply-To: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
Message-ID: <ZSnwtyHBIwNIKtcmGt8gdTDSyGbDjqOBDqob_GCt9Y8=.0aef9add-55a6-42d2-b43d-58ee1af79301@github.com>

> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
> 
> One ToolTipManager test for the AppContext is removed.

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

  8378297

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29830/files
  - new: https://git.openjdk.org/jdk/pull/29830/files/a4949913..9367a70f

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

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

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

From dnguyen at openjdk.org  Wed Feb 25 11:06:04 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Feb 2026 11:06:04 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v3]
In-Reply-To: <ZSnwtyHBIwNIKtcmGt8gdTDSyGbDjqOBDqob_GCt9Y8=.0aef9add-55a6-42d2-b43d-58ee1af79301@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <ZSnwtyHBIwNIKtcmGt8gdTDSyGbDjqOBDqob_GCt9Y8=.0aef9add-55a6-42d2-b43d-58ee1af79301@github.com>
Message-ID: <PPOPlZZk4CfZwiZGIcCebW5GN6CoenpZQmhqjxmvcDk=.a3eaa657-c7bc-4837-a338-9cf36578ee80@github.com>

On Tue, 24 Feb 2026 21:15:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
>> 
>> One ToolTipManager test for the AppContext is removed.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378297

Marked as reviewed by dnguyen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29830#pullrequestreview-3850560841

From psadhukhan at openjdk.org  Wed Feb 25 11:05:57 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Feb 2026 11:05:57 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
Message-ID: <In5x_9CVTougnOmTMLdIlyZ1wrNeRv2cnxMNIkC9vsM=.fb887deb-bb30-4cee-8a8e-d0d30d1db2a9@github.com>

On Thu, 19 Feb 2026 20:04:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
>> 
>> With this PR, I'm contributing the test to OpenJDK.
>> 
>> Without the fix for JDK-8297191, the test fails with the following error messages:
>> 
>> <details>
>> <summary>test log</summary>
>> 
>> 
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
>> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> 	at PageRangesAuto.main(PageRangesAuto.java:146)
>> 
>> </details>
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the first page of the rage in the filename

test/jdk/java/awt/print/PrinterJob/PageRangesAuto.java line 97:

> 95:         String fileName = pageRange == null
> 96:                           ? baseName + "-all.pdf"
> 97:                           : String.format("%s-%d-%d.pdf",

I believe `Destination` creates file in .prn or .ps format and not .pdf..
https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/print/attribute/standard/Destination.html

> A common use for this attribute will be applications which want to redirect output to a local disk file : eg."file:out.prn"

I am not able to open this file atleast in Windows as Acrobat fails to recognize the file type even though its pdf

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2850827650

From prr at openjdk.org  Wed Feb 25 11:06:15 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 11:06:15 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v2]
In-Reply-To: <03vNO_bFXczIF70L9gxd6iusL4muszXcDm3_-L3EfXk=.b4e1a09e-1aed-4463-9059-147e2c3e8ec7@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <Dky4ZYnNS2i9u1-J7i-4GTOJc8dJmL9RgYB5ov9l3X8=.725558d5-a1db-445a-83ff-4cc996fec048@github.com>
 <03vNO_bFXczIF70L9gxd6iusL4muszXcDm3_-L3EfXk=.b4e1a09e-1aed-4463-9059-147e2c3e8ec7@github.com>
Message-ID: <qdbG7HGnLFk9Nuna43OxuRWZDHPXb0WAWBpKScFYzhE=.64de7f8c-b31f-4e03-8adb-38247c42f1a8@github.com>

On Tue, 24 Feb 2026 20:34:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378297
>
> src/java.desktop/share/classes/javax/swing/JFrame.java line 752:
> 
>> 750: 
>> 751:     private static boolean defaultLAFDecorated;
>> 752:     /**
> 
> Suggestion:
> 
>     private static boolean defaultLAFDecorated;
>     
> /**
> 
> 
> Nit but you have added a newline after similar `private static vars` for JDialog and JPopupMenu.

added a spacing new line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2849512517

From prr at openjdk.org  Wed Feb 25 11:04:39 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 11:04:39 GMT
Subject: RFR: 8378607: GlyphLayout cache can prevent Fonts from being GC'd
Message-ID: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>

Update a cache in GlyphLayout.java to use a WeakHashMap
The maximum cache size is also reduced.
The intention is to allow Fonts loaded via Font.createFont() to be collected once the application drops references.

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

Commit messages:
 - 8378607

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

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

From jdv at openjdk.org  Wed Feb 25 11:04:39 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 25 Feb 2026 11:04:39 GMT
Subject: RFR: 8378607: GlyphLayout cache can prevent Fonts from being GC'd
In-Reply-To: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
References: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
Message-ID: <9vSvS-q4-1Og1dns0ThFAG89u3k5MLgMI4iCCcYxWrI=.f08884f1-6c18-4958-a02f-51cb7667820d@github.com>

On Wed, 25 Feb 2026 00:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Update a cache in GlyphLayout.java to use a WeakHashMap
> The maximum cache size is also reduced.
> The intention is to allow Fonts loaded via Font.createFont() to be collected once the application drops references.

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29904#pullrequestreview-3853269760

From duke at openjdk.org  Wed Feb 25 11:06:25 2026
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Wed, 25 Feb 2026 11:06:25 GMT
Subject: RFR: 8372952: Respect landscape orientation user selection on
 macOS and Linux [v2]
In-Reply-To: <1Ry15_1J9BKz3mANlXPpq2pBoLP_a9lPQ9Z9Qbi-2vU=.7eb835fb-b505-4d53-812b-c6b9055a8114@github.com>
References: <lb8GZRWbO4rnHCVFF8MQfgV3DIuOGIt4f49RRyhW8Ng=.7ce8594c-eef8-4a99-ab73-14ebf3130646@github.com>
 <L6epQJ_wv79hftjql8paFgsDF3zRzNRW6dX_f3-O8Aw=.5f6e8760-58b9-4e68-980f-1948f72a8c7a@github.com>
 <1Ry15_1J9BKz3mANlXPpq2pBoLP_a9lPQ9Z9Qbi-2vU=.7eb835fb-b505-4d53-812b-c6b9055a8114@github.com>
Message-ID: <VfNF0LeoOP7-scBuimTpXdaKWOyGCsyfV0Y_VWKXkEI=.d4dd55fa-8d90-4aab-9dcd-b3d5267244be@github.com>

On Mon, 16 Feb 2026 05:20:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I believe the same was fixed in [JDK-8295737](https://bugs.openjdk.org/browse/JDK-8295737)...That fix was also for macos. Did it regress?

It's not a regression. JDK-8295737 fixed a related issue on macOS but did not fix the bug on Linux. Also it does not select a paper explicitly on macOS. If a user chooses landscape-oriented paper, the printer may ignore user's choice and print with portrait-oriented paper. 
Let me amend the issue synopsis to avoid confusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29560#issuecomment-3957421804

From rkannathpari at openjdk.org  Wed Feb 25 11:08:27 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 25 Feb 2026 11:08:27 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v4]
In-Reply-To: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
Message-ID: <pxQhZj6jo0R-N_4ZZwYuWhgaWrYqlC69Ie8c5OGfFHA=.3b875927-162b-4a37-b9c0-2997f96adf89@github.com>

> Hi Reviewers,
> 
> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Test tag updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29733/files
  - new: https://git.openjdk.org/jdk/pull/29733/files/2e6dc352..d30a3aff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29733&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29733&range=02-03

  Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/29733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29733/head:pull/29733

PR: https://git.openjdk.org/jdk/pull/29733

From psadhukhan at openjdk.org  Wed Feb 25 11:08:34 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Feb 2026 11:08:34 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v3]
In-Reply-To: <lrUvNM0qPZXIkpRaeIJjcvkf8Pg5cIUBFTx1ZIU2PBY=.a03abaaa-f766-48b6-b8e5-8c7f71bbc474@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <lrUvNM0qPZXIkpRaeIJjcvkf8Pg5cIUBFTx1ZIU2PBY=.a03abaaa-f766-48b6-b8e5-8c7f71bbc474@github.com>
Message-ID: <OQQxiz2_J4t4AZ3_5KtYa5VhLk6GqYGiNrlSau9JCrQ=.9d180620-4e06-49df-9762-933c33a597cd@github.com>

On Mon, 23 Feb 2026 04:56:55 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on suggesion

test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java line 25:

> 23: 
> 24: /* @test
> 25:    @bug 8262731

you need to add this bugid and also align the tags

/*
 * @test
 * @bug
 * ....
 */

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29733#discussion_r2850748235

From psadhukhan at openjdk.org  Wed Feb 25 11:08:49 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Feb 2026 11:08:49 GMT
Subject: RFR: 6328248: JProgessBar doesn't show if printed on paper with
 PrintJob (1.1 Graphics API) [v7]
In-Reply-To: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
References: <cqI4UnWBdMgI58i2wzpCC77hW-rs6QpLADwmDDmBh98=.14a8d5fa-cd04-4361-9803-4452565ffe97@github.com>
Message-ID: <TViU7u67fDSGyqMqJ5JAniJ4IvPXRdCdMbxYMMX-TwI=.16e8002d-611d-411c-8919-38fd1cba8781@github.com>

> `JProgressBar` is not printed if JDK 1.1 printing API is used.
> JDK1.1 printing API `PrintJob ` doesn't support `Graphics2D`. 
> JProgressBar seems to require Graphics2D as `BasicProgressBarUI` needs Graphics2D to do
> `g2.setStroke(new BasicStroke(...))`
> 
> Fix is made to not rely on setStroke for non-Graphics2D printing case and also not to clip progress string
> Also, a null pagerange check is added for PrintJobDelegate as we reset PageRanges if range is not set so to prevent NPE when "All" is used in print dialog instead of "Pages from"

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove PageRange regression, fix Synth

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29752/files
  - new: https://git.openjdk.org/jdk/pull/29752/files/4b29eafc..99cc8a79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29752&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29752&range=05-06

  Stats: 23 lines in 3 files changed: 0 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/29752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29752/head:pull/29752

PR: https://git.openjdk.org/jdk/pull/29752

From psadhukhan at openjdk.org  Wed Feb 25 11:08:37 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Feb 2026 11:08:37 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v3]
In-Reply-To: <WWgchxqlqWsNCyV_xjnzyQUfJFMpZHblP37G_sya2Ak=.ad76df0a-74a9-41d8-bea7-9519673f2d1d@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <lrUvNM0qPZXIkpRaeIJjcvkf8Pg5cIUBFTx1ZIU2PBY=.a03abaaa-f766-48b6-b8e5-8c7f71bbc474@github.com>
 <FDH8rpxsjevPAI6b0h26SZaHz6QPSabe0S2tTD-EfVQ=.3dde2c41-b25d-4d83-b5f6-2aa57071d4cd@github.com>
 <WWgchxqlqWsNCyV_xjnzyQUfJFMpZHblP37G_sya2Ak=.ad76df0a-74a9-41d8-bea7-9519673f2d1d@github.com>
Message-ID: <e-34QLuzFLr0VLfl0NQqUMhVii3aVMkR7m74TfRioso=.ad50feb3-b0c2-4a64-85b6-4e9d45f9c7a8@github.com>

On Tue, 24 Feb 2026 10:28:55 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java line 66:
>> 
>>> 64:                 "Test started. threadType='%s', exceptionType='%s'",
>>> 65:                 threadType, exceptionType));
>>> 66: 
>> 
>> I believe this test is passing without the fix...It would be better to have a test where you can throw a RTE forcefully and which would fail if it gets an exception other than PrinterException
>
> With out fix test throwing **Unexpected exception was thrown** for argument `MAIN RE`, please find the message. **MAIN/EDT RE** was skipped earlier for Windows and Linux. 
> 
> 
> java.lang.RuntimeException: Exception from 'Printable.print'.
>         at ExceptionFromPrintableIsIgnoredTest$2.print(ExceptionFromPrintableIsIgnoredTest.java:110)
>         at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2214)
>         at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1603)
>         at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1433)
>         at ExceptionFromPrintableIsIgnoredTest.runTest(ExceptionFromPrintableIsIgnoredTest.java:118)
>         at ExceptionFromPrintableIsIgnoredTest.<init>(ExceptionFromPrintableIsIgnoredTest.java:70)
>         at ExceptionFromPrintableIsIgnoredTest.main(ExceptionFromPrintableIsIgnoredTest.java:57)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:260)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
>         at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
> Exception in thread "main" java.lang.RuntimeException: Unexpected exception was thrown.
>         at ExceptionFromPrintableIsIgnoredTest.<init>(ExceptionFromPrintableIsIgnoredTest.java:87)
>         at ExceptionFromPrintableIsIgnoredTest.main(ExceptionFromPrintableIsIgnoredTest.java:57)

Yes, I see..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29733#discussion_r2850743087

From duke at openjdk.org  Wed Feb 25 11:18:37 2026
From: duke at openjdk.org (duke)
Date: Wed, 25 Feb 2026 11:18:37 GMT
Subject: Withdrawn: 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: <oMQO-J60CO7fy7kkX7dirbAMxvM69TdOxrAN0m9uIpQ=.7488af13-68b2-4008-bc78-47b9dd80b840@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...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27682

From aivanov at openjdk.org  Wed Feb 25 11:36:01 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Feb 2026 11:36:01 GMT
Subject: Integrated: 8378578: Add final to XbmColormap and XbmHints in
 XbmImageDecoder
In-Reply-To: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
References: <jJzq7KEYaLUG_auDTZlEu631Cba3fNGWsq5hPmnmhcI=.b66a3ccd-2159-40e8-b2ec-13cc381de258@github.com>
Message-ID: <5IOvinqeZRraLjfe_SZAnN_E8ED_ipSj4qWdTVsOcQw=.c8dab5ac-05ee-4ea8-a00c-b0cc1a5d59bf@github.com>

On Tue, 24 Feb 2026 15:50:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial clean up for `XbmImageDecoder` that marks the fields `XbmColormap` and `XbmHints` with the `final` modifier. These fields are constants.
> 
> In addition to the above, improve the javadoc by using the `@snippet`. Otherwise, all the lines of the XBM snippet are combined into one line.

This pull request has now been integrated.

Changeset: 5386a72b
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5386a72bc2869f29ef3927768bd9d2273c6dac08
Stats:     9 lines in 1 file changed: 3 ins; 0 del; 6 mod

8378578: Add final to XbmColormap and XbmHints in XbmImageDecoder

Reviewed-by: dmarkov, serb, prr, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/29896

From aivanov at openjdk.org  Wed Feb 25 11:36:04 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Feb 2026 11:36:04 GMT
Subject: Integrated: 8378585: Mark fields in MediaTracker final
In-Reply-To: <mdNPq4UU5GNn5zf9sO3wVnOx3XPEc8866CmVLqYiqos=.11d7ce0e-8ec3-4e3f-abf8-ac0501f78c65@github.com>
References: <mdNPq4UU5GNn5zf9sO3wVnOx3XPEc8866CmVLqYiqos=.11d7ce0e-8ec3-4e3f-abf8-ac0501f78c65@github.com>
Message-ID: <ELOzYy3fGte3B3RCjH3PVEPy0rWjvhFG52r_FcbwKfs=.e3086e23-44a3-44e1-b4bf-12dd2b654b40@github.com>

On Tue, 24 Feb 2026 17:02:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> During the discussions in https://github.com/openjdk/jdk/pull/29433, I looked at the source code of `MediaTracker` and found several issues for cleaning up.
> 
> - The `target` field in `MediaTracker` is initialised in the constructor, it's never changed;
> - The visibility of the `head` field in `MediaTracker` can be reduced to `private`;
> - The `tracker` and `ID` fields in the `MediaEntry` class are never changed after being set in the constructor, therefore it's `final`;
> - The `getID` method of `MediaEntry` should be `final`, subclasses shouldn't be able to change the returned id;
> - The fields in `ImageMediaEntry`?`image`, `width` and `height`?can also be `final`.
> - The `ImageMediaEntry` class itself is `final`.
> 
> Additionally, I added the `@Override` annotation to overridden methods.

This pull request has now been integrated.

Changeset: 3e087d8e
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e087d8ebd8c2f860a168b223c5f049dc1c9c068
Stats:     14 lines in 1 file changed: 4 ins; 0 del; 10 mod

8378585: Mark fields in MediaTracker final

Reviewed-by: serb, prr

-------------

PR: https://git.openjdk.org/jdk/pull/29899

From aivanov at openjdk.org  Wed Feb 25 11:37:00 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Feb 2026 11:37:00 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <In5x_9CVTougnOmTMLdIlyZ1wrNeRv2cnxMNIkC9vsM=.fb887deb-bb30-4cee-8a8e-d0d30d1db2a9@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
 <In5x_9CVTougnOmTMLdIlyZ1wrNeRv2cnxMNIkC9vsM=.fb887deb-bb30-4cee-8a8e-d0d30d1db2a9@github.com>
Message-ID: <SRJPmuFluC2UBBBfxb7uVeaMiyfSZIA8-WUgc45tJsU=.15aad0d2-8edc-4f7f-a71e-bfb56dd28141@github.com>

On Wed, 25 Feb 2026 04:54:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the first page of the rage in the filename
>
> test/jdk/java/awt/print/PrinterJob/PageRangesAuto.java line 97:
> 
>> 95:         String fileName = pageRange == null
>> 96:                           ? baseName + "-all.pdf"
>> 97:                           : String.format("%s-%d-%d.pdf",
> 
> I believe `Destination` creates file in .prn or .ps format and not .pdf..
> https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/print/attribute/standard/Destination.html
> 
>> A common use for this attribute will be applications which want to redirect output to a local disk file : eg."file:out.prn"
> 
> I am not able to open this file atleast in Windows as Acrobat fails to recognize the file type even though its pdf

On macOS, it creates valid PDF files, all the files are viewable in the Preview utility.

On Windows, all these files open just fine in Firefox and Edge.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2852494527

From dgredler at openjdk.org  Wed Feb 25 12:04:38 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 25 Feb 2026 12:04:38 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation [v2]
In-Reply-To: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
Message-ID: <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>

> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
> 
> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
> 
> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
> 
> Tested on mac, Linux and Windows:
> - make test TEST="jtreg:test/jdk/java/awt/font"
> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"

Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:

  Add defensive check for null ptr

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29726/files
  - new: https://git.openjdk.org/jdk/pull/29726/files/8356ec87..600d7c44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29726&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29726&range=00-01

  Stats: 11 lines in 1 file changed: 3 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/29726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29726/head:pull/29726

PR: https://git.openjdk.org/jdk/pull/29726

From dgredler at openjdk.org  Wed Feb 25 12:04:40 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 25 Feb 2026 12:04:40 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation
In-Reply-To: <B97KFRAiLOoDAwH3WypoUtrMwia5DWVZCGe_d9rBl0U=.8f703a0d-7232-41e4-b0ac-025219abc4c1@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
 <8tU6fqIS0KwThGLVUCCSJiQROlPzoYvK3pbn8klkdaY=.aec7cae0-805d-4a00-9034-317c4f0901fc@github.com>
 <i4eGCUnDhmCowxZ1XMLxi_ORjqJN1eUBoO2lsz7s8Fg=.6305067c-085e-4739-8963-d3ada7a299e2@github.com>
 <B97KFRAiLOoDAwH3WypoUtrMwia5DWVZCGe_d9rBl0U=.8f703a0d-7232-41e4-b0ac-025219abc4c1@github.com>
Message-ID: <ekUh6Zon4HaDKc0ZrL26cmZ0pVRFElLoC_3vyC-52lQ=.27d8dc85-7044-4ab4-96e0-6e2855f03f33@github.com>

On Mon, 23 Feb 2026 17:51:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Another difference is handing invisible INVISIBLE_GLYPHS, which I assume works fine on macOS as is.
>> 
>> Yes, the test exercises this scenario because the new line and tab chars in the test text are mapped to invisible glyph IDs. However, it might not hurt to add an early check here to avoid entering native code entirely in this scenario -- although this should happen rarely, so I'm not sure how effective this will be as a mini-optimization. I'm happy to add this check though, if the consensus is that it's a good idea.
>> 
>>> The FileFontStrike.getGlyphMetrics( ) has a check if (glyphPtr != 0L) before calling StrikeCache.getGlyphXAdvance. Do not we need the same check in the new code?
>> 
>> It doesn't look like it to me, mainly because `CGGI_CreateNewGlyphInfoFrom` (see call sequence below) expects that malloc never fails. That's maybe a bit odd, but I think if we get NULL / 0 back as a pointer, we have problems elsewhere (in `CGGI_CreateNewGlyphInfoFrom`, not here).
>> 
>> Sequence: getGlyphImagePtr -> getGlyphImagePtrs -> getFilteredGlyphImagePtrs -> getGlyphImagePtrsNative -> Java_sun_font_CStrike_getGlyphImagePtrsNative -> CGGlyphImages_GetGlyphImagePtrs -> CGGI_CreateGlyphsAndScanForComplexities -> CGGI_CreateGlyphInfos -> **CGGI_CreateNewGlyphInfoFrom** /// OR /// CGGI_FillImagesForGlyphs -> CGGI_FillImagesForGlyphsWithSizedCanvas -> CGGI_CreateImageForUnicode -> **CGGI_CreateNewGlyphInfoFrom**
>
>>Sequence: getGlyphImagePtr -> getGlyphImagePtrs -> getFilteredGlyphImagePtrs -> getGlyphImagePtrsNative -> Java_sun_font_CStrike_getGlyphImagePtrsNative -> CGGlyphImages_GetGlyphImagePtrs -> CGGI_CreateGlyphsAndScanForComplexities -> CGGI_CreateGlyphInfos -> CGGI_CreateNewGlyphInfoFrom /// OR /// CGGI_FillImagesForGlyphs -> CGGI_FillImagesForGlyphsWithSizedCanvas -> CGGI_CreateImageForUnicode -> CGGI_CreateNewGlyphInfoFrom
> 
> This is some objc code that may throw an NSException. It will be caught in Java_sun_font_CStrike_getGlyphImagePtrsNative by JNI_COCOA_ENTER / JNI_COCOA_EXIT.
> 
> And that assumption that malloc always succeed is suspicion.

@mrserb I've created a separate issue [JDK-8378667](https://bugs.openjdk.org/browse/JDK-8378667) for the missing malloc failure check, and added a defensive null pointer check in the Java code being changed here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29726#issuecomment-3958791228

From aivanov at openjdk.org  Wed Feb 25 15:09:49 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Feb 2026 15:09:49 GMT
Subject: RFR: 8376152: Test javax/sound/sampled/Clip/bug5070081.java timed
 out then completed
In-Reply-To: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
References: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
Message-ID: <CnUoKsg0xjEYImDnEQAPl2yZ__tCzqaVxq9xB6qrxg0=.9715c195-cc8a-434c-9378-b147c3ea11bf@github.com>

On Tue, 24 Feb 2026 18:27:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I've run this test and it definitely needs a sound device.
> So I've added the jtreg key for sound, so we can always run it where there's sound support.

Marked as reviewed by aivanov (Reviewer).

Looks good except for a minor comment about the bug id.

test/jdk/javax/sound/sampled/Clip/bug5070081.java line 35:

> 33:  * @test
> 34:  * @key sound
> 35:  * @bug 5070081 8376152

No need to add 8376152, in my opinion. It's a test only change as opposed to product bugs, and we agreed to add only product bugs into the `@bug` jtreg tag.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29901#pullrequestreview-3854864716
PR Comment: https://git.openjdk.org/jdk/pull/29901#issuecomment-3959947725
PR Review Comment: https://git.openjdk.org/jdk/pull/29901#discussion_r2853602125

From jdv at openjdk.org  Wed Feb 25 16:53:53 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 25 Feb 2026 16:53:53 GMT
Subject: RFR: 8377526: Update Libpng to 1.6.55
Message-ID: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>

Upgrade libpng used for Splashscreen from 1.6.54 to 1.6.55 version.
Testing is green with this update.

-------------

Commit messages:
 - 8377526: Update Libpng to 1.6.55

Changes: https://git.openjdk.org/jdk/pull/29922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29922&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377526
  Stats: 32 lines in 8 files changed: 7 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/29922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29922/head:pull/29922

PR: https://git.openjdk.org/jdk/pull/29922

From azvegint at openjdk.org  Wed Feb 25 17:13:21 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 25 Feb 2026 17:13:21 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v3]
In-Reply-To: <ZSnwtyHBIwNIKtcmGt8gdTDSyGbDjqOBDqob_GCt9Y8=.0aef9add-55a6-42d2-b43d-58ee1af79301@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <ZSnwtyHBIwNIKtcmGt8gdTDSyGbDjqOBDqob_GCt9Y8=.0aef9add-55a6-42d2-b43d-58ee1af79301@github.com>
Message-ID: <qp-GYrYxBkRAMpGTn-9JZNia9gn4PD8l-OdErYnlYew=.20cb81db-a1ea-4d64-aa4a-812e6f084b95@github.com>

On Wed, 25 Feb 2026 11:06:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
>> 
>> One ToolTipManager test for the AppContext is removed.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378297

src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 1495:

> 1493:       */
> 1494:     static DebugGraphicsInfo info() {
> 1495:         synchronized (DebugGraphicsInfo.class) {

I suppose the DCL pattern could be used here to avoid the `synchronized` block on subsequent calls.

Same applies to other files, like `PopupFactory`, `SwingUtilities`, `ToolTipManager`

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 156:

> 154:     private static final boolean DEBUG =   false;  // show bad params, misc.
> 155: 
> 156:     private static boolean defaultLWPopupEnabled = true;

It looks like you forgot to remove `defaultLWPopupEnabledKey`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2854257597
PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2854242377

From azvegint at openjdk.org  Wed Feb 25 17:24:15 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 25 Feb 2026 17:24:15 GMT
Subject: RFR: 8377526: Update Libpng to 1.6.55
In-Reply-To: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
References: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
Message-ID: <1CKZBSmsl4w6xqhq8sogkhCqnOzW4irryv-fqQR9mQE=.56ef3310-a92b-4519-a7db-f102c5ea75f4@github.com>

On Wed, 25 Feb 2026 16:45:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Upgrade libpng used for Splashscreen from 1.6.54 to 1.6.55 version.
> Testing is green with this update.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29922#pullrequestreview-3855657667

From azvegint at openjdk.org  Wed Feb 25 17:25:17 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 25 Feb 2026 17:25:17 GMT
Subject: RFR: 8376152: Test javax/sound/sampled/Clip/bug5070081.java timed
 out then completed
In-Reply-To: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
References: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
Message-ID: <FWMPsCgF-nS_SmOM9vjDjzGE5AFyCpTOKk3RdUHyvLU=.1e35bfc9-07f6-4a38-a636-68102df0808a@github.com>

On Tue, 24 Feb 2026 18:27:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I've run this test and it definitely needs a sound device.
> So I've added the jtreg key for sound, so we can always run it where there's sound support.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29901#pullrequestreview-3855666843

From prr at openjdk.org  Wed Feb 25 17:34:51 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 17:34:51 GMT
Subject: RFR: 8377526: Update Libpng to 1.6.55
In-Reply-To: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
References: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
Message-ID: <pWaJboMNgOBKymamQ-NrbiTvH2jIsa_HxPPoU-vzWhY=.5200223f-8ce8-4f03-a56d-a27bbb0004c9@github.com>

On Wed, 25 Feb 2026 16:45:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Upgrade libpng used for Splashscreen from 1.6.54 to 1.6.55 version.
> Testing is green with this update.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29922#pullrequestreview-3855723876

From prr at openjdk.org  Wed Feb 25 17:40:50 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 17:40:50 GMT
Subject: Integrated: 8376152: Test javax/sound/sampled/Clip/bug5070081.java
 timed out then completed
In-Reply-To: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
References: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
Message-ID: <Ql0S7VveaojJV8IcKH2r6xjxt7ufi2iF9YWVIfOdk8A=.bc09b413-4489-49af-8282-723970ab1ccb@github.com>

On Tue, 24 Feb 2026 18:27:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I've run this test and it definitely needs a sound device.
> So I've added the jtreg key for sound, so we can always run it where there's sound support.

This pull request has now been integrated.

Changeset: 0ab8a85e
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ab8a85e87cb607c48a45900550998f0d36cf761
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8376152: Test javax/sound/sampled/Clip/bug5070081.java timed out then completed

Reviewed-by: syan, aivanov, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/29901

From prr at openjdk.org  Wed Feb 25 17:46:36 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 17:46:36 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation [v2]
In-Reply-To: <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
 <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
Message-ID: <hmiwrxFTUNk3ek1airO79uvERtHzwYfTF3ftprtuaKQ=.0db21016-a646-401d-b71c-5781d1343c52@github.com>

On Wed, 25 Feb 2026 12:04:38 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
>> 
>> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
>> 
>> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
>> 
>> Tested on mac, Linux and Windows:
>> - make test TEST="jtreg:test/jdk/java/awt/font"
>> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add defensive check for null ptr

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29726#pullrequestreview-3855795255

From prr at openjdk.org  Wed Feb 25 18:01:46 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 18:01:46 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v4]
In-Reply-To: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
Message-ID: <KyvCisU2pB_MuuSeSAYYi4No01jKP6pZRoz50zrClZU=.49a01087-d0ad-4e1f-8a7f-fe91ba0da1e6@github.com>

> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
> 
> One ToolTipManager test for the AppContext is removed.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8378297

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29830/files
  - new: https://git.openjdk.org/jdk/pull/29830/files/9367a70f..8d7b5e24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29830&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29830&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29830/head:pull/29830

PR: https://git.openjdk.org/jdk/pull/29830

From prr at openjdk.org  Wed Feb 25 18:01:48 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 18:01:48 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v3]
In-Reply-To: <qp-GYrYxBkRAMpGTn-9JZNia9gn4PD8l-OdErYnlYew=.20cb81db-a1ea-4d64-aa4a-812e6f084b95@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <ZSnwtyHBIwNIKtcmGt8gdTDSyGbDjqOBDqob_GCt9Y8=.0aef9add-55a6-42d2-b43d-58ee1af79301@github.com>
 <qp-GYrYxBkRAMpGTn-9JZNia9gn4PD8l-OdErYnlYew=.20cb81db-a1ea-4d64-aa4a-812e6f084b95@github.com>
Message-ID: <KUSkMNBHf7yUgd87CBwAkqb4HqXLOlQoBfVgZSPhjwI=.12a88120-afc8-4ac9-9f2e-ad48d34cbe57@github.com>

On Wed, 25 Feb 2026 17:02:56 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378297
>
> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 1495:
> 
>> 1493:       */
>> 1494:     static DebugGraphicsInfo info() {
>> 1495:         synchronized (DebugGraphicsInfo.class) {
> 
> I suppose the DCL pattern could be used here to avoid the `synchronized` block on subsequent calls.
> 
> Same applies to other files, like `PopupFactory`, `SwingUtilities`, `ToolTipManager`

I figured we are no worse off with this since as was pointed out in some other PR AppContext.get() (and put) synchronizes.
And none of these seem likely to be contended locks or performance critical.

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 156:
> 
>> 154:     private static final boolean DEBUG =   false;  // show bad params, misc.
>> 155: 
>> 156:     private static boolean defaultLWPopupEnabled = true;
> 
> It looks like you forgot to remove `defaultLWPopupEnabledKey`

oops. removing it now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2854528840
PR Review Comment: https://git.openjdk.org/jdk/pull/29830#discussion_r2854507784

From prr at openjdk.org  Wed Feb 25 18:06:15 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 18:06:15 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v4]
In-Reply-To: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
Message-ID: <Ieba1KirpO5_lrwZXXDw4mb2b_wIevOqmLEhCm7kdK0=.8903fe95-0053-42f2-bde8-006be6bffa0e@github.com>

> Remove AppContext from JEditorPane

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8378377

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29855/files
  - new: https://git.openjdk.org/jdk/pull/29855/files/a29d2c66..942505ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29855&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29855&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29855/head:pull/29855

PR: https://git.openjdk.org/jdk/pull/29855

From prr at openjdk.org  Wed Feb 25 18:06:17 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 18:06:17 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v4]
In-Reply-To: <annycpCzJ4g_p0EHDKJU4H6vyGeKJUbI3kbJNhLC7RM=.faffd5e1-e461-4538-a3e8-eca695f78ba7@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <U4dyRDXjzYtFqLLZiAQPCLxi3IDapS3F59U_GpxHyso=.1bf8b363-ed7a-40d5-afe7-2e37c4632260@github.com>
 <annycpCzJ4g_p0EHDKJU4H6vyGeKJUbI3kbJNhLC7RM=.faffd5e1-e461-4538-a3e8-eca695f78ba7@github.com>
Message-ID: <1nk_KCeekNcPc9DR9x0FZlg0P5CA0-4c67Ssip5Yf3A=.e13ebc4b-b167-4b2b-9ac0-b0d8db37be8f@github.com>

On Tue, 24 Feb 2026 19:24:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378377
>
> src/java.desktop/share/classes/javax/swing/JEditorPane.java line 1246:
> 
>> 1244:                 }
>> 1245:                 k = (EditorKit) c.newInstance();
>> 1246:                 kitRegistry.put(type, k);
> 
> Why this line is removed?

Obviously (?) an accident when doing the last update to remove the setters.
I've restored it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29855#discussion_r2854549940

From azvegint at openjdk.org  Wed Feb 25 18:28:08 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 25 Feb 2026 18:28:08 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v4]
In-Reply-To: <KyvCisU2pB_MuuSeSAYYi4No01jKP6pZRoz50zrClZU=.49a01087-d0ad-4e1f-8a7f-fe91ba0da1e6@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <KyvCisU2pB_MuuSeSAYYi4No01jKP6pZRoz50zrClZU=.49a01087-d0ad-4e1f-8a7f-fe91ba0da1e6@github.com>
Message-ID: <Yaj0nqdfY-oo_Z9kMngDNvVtxPDd6nyFjcwS5iKJWlM=.1089ea2a-ce42-427b-8b90-776c909b15b9@github.com>

On Wed, 25 Feb 2026 18:01:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
>> 
>> One ToolTipManager test for the AppContext is removed.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378297

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29830#pullrequestreview-3856046982

From dnguyen at openjdk.org  Wed Feb 25 18:37:22 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Feb 2026 18:37:22 GMT
Subject: RFR: 8378385: Remove AppContext from AWT Windows implementation
 classes
In-Reply-To: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
References: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
Message-ID: <ARb_JmFnzSMjOqrf73tp8zzKDYClqLGIyz4poFQHnlY=.e3c0f71f-0939-4338-92e3-e578db184b30@github.com>

On Sat, 21 Feb 2026 20:27:45 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove most uses of AppContext from Windows AWT classes.
> No existing tests fail with this change.

src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java line 605:

> 603:                                                       TextHitInfo.leading(caretPos),
> 604:                                                       TextHitInfo.leading(visiblePos));
> 605:         WToolkit.postEvent(WToolkit.targetToAppContext(source), event);

Does this not need to be updated similarly to WToolkit.postEvent(source, ...)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29858#discussion_r2854689329

From prr at openjdk.org  Wed Feb 25 18:43:09 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 18:43:09 GMT
Subject: RFR: 8378615: FFM Bound up call stub keeps JNI Global Ref to bound
 parameter
Message-ID: <9S-En1lUpRWfSoIng50p-DoAMFOdXIdPJ6QmKCnI1Nw=.bbeeac10-d8d3-4b2e-9785-7246b4f10d24@github.com>

This fixes a problem whereby because a bound up call stub method handle holds on to the bound argument using a JNI Global Ref, GC of that object is prevented until the method handle is freed.
In the font layout code this causes us to be unable to collect fonts which are used as the bound argument.
So this fix changes from using the bound arg to using the existing scoped value font.

-------------

Commit messages:
 - 8378615

Changes: https://git.openjdk.org/jdk/pull/29924/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378615
  Stats: 39 lines in 1 file changed: 10 ins; 23 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/29924.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29924/head:pull/29924

PR: https://git.openjdk.org/jdk/pull/29924

From prr at openjdk.org  Wed Feb 25 18:57:37 2026
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Feb 2026 18:57:37 GMT
Subject: RFR: 8378615: FFM Bound up call stub keeps JNI Global Ref to bound
 parameter
In-Reply-To: <9S-En1lUpRWfSoIng50p-DoAMFOdXIdPJ6QmKCnI1Nw=.bbeeac10-d8d3-4b2e-9785-7246b4f10d24@github.com>
References: <9S-En1lUpRWfSoIng50p-DoAMFOdXIdPJ6QmKCnI1Nw=.bbeeac10-d8d3-4b2e-9785-7246b4f10d24@github.com>
Message-ID: <YARkKT4pwzdtgL3sBYcF-qJS6F8NJEXxttHXvbRAK10=.c077afb3-e1aa-4c71-9ed2-0bd5078835ce@github.com>

On Wed, 25 Feb 2026 18:36:06 GMT, Phil Race <prr at openjdk.org> wrote:

> This fixes a problem whereby because a bound up call stub method handle holds on to the bound argument using a JNI Global Ref, GC of that object is prevented until the method handle is freed.
> In the font layout code this causes us to be unable to collect fonts which are used as the bound argument.
> So this fix changes from using the bound arg to using the existing scoped value font.

src/java.desktop/share/classes/sun/font/HBShaper.java line 214:

> 212:         Arena garena = Arena.global(); // creating stubs that exist until VM exit.
> 213: 
> 214:         get_table_data_fn_stub = getUpcallStub(garena,

In a future PR I'm thinking of migrating the lookups below to use this same fn since it should simplify those calls. Before this change the fn was specific to the bound arg case, but it no longer does that

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29924#discussion_r2854786625

From serb at openjdk.org  Wed Feb 25 19:38:28 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Feb 2026 19:38:28 GMT
Subject: RFR: 8377526: Update Libpng to 1.6.55
In-Reply-To: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
References: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
Message-ID: <xgJda9ouzT2M1XitRRpCRteqg4dmWFLTCqff48Y17DQ=.e5def9fd-9cb7-43aa-86a5-09f1cf01b459@github.com>

On Wed, 25 Feb 2026 16:45:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Upgrade libpng used for Splashscreen from 1.6.54 to 1.6.55 version.
> Testing is green with this update.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29922#pullrequestreview-3856440543

From serb at openjdk.org  Wed Feb 25 19:46:55 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Feb 2026 19:46:55 GMT
Subject: RFR: 8378605: Remove AppContext from the Swing TimerQueue
 implementation
In-Reply-To: <hNbzVzZTAF-CceSIiP8XuOzOlYePbwXu6yP6Q1zy5X8=.30634a56-cbb2-4aed-9333-58fe9b07a52b@github.com>
References: <hNbzVzZTAF-CceSIiP8XuOzOlYePbwXu6yP6Q1zy5X8=.30634a56-cbb2-4aed-9333-58fe9b07a52b@github.com>
Message-ID: <s7HNyB_E4IyCgysl6v0U2sLq2K3DrziBpMUOT4xV1hM=.7e3133bc-81eb-44a5-acba-ec1ec810c13a@github.com>

On Tue, 24 Feb 2026 20:05:25 GMT, Phil Race <prr at openjdk.org> wrote:

> A test that expressly checked per-AppContext TimerQueue behaviour is removed.

It might be useful to keep the test as a stress test; just remove the use of appcontext from it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29902#issuecomment-3961604494

From serb at openjdk.org  Wed Feb 25 19:47:57 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Feb 2026 19:47:57 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation [v2]
In-Reply-To: <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
 <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
Message-ID: <NNChjeZD-tDTXWcVkC_wf3UCgkePNtTw6sFNRkitq2k=.950a0a23-ba7b-40c2-b3b5-be0778a00766@github.com>

On Wed, 25 Feb 2026 12:04:38 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
>> 
>> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
>> 
>> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
>> 
>> Tested on mac, Linux and Windows:
>> - make test TEST="jtreg:test/jdk/java/awt/font"
>> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add defensive check for null ptr

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29726#pullrequestreview-3856493389

From serb at openjdk.org  Wed Feb 25 19:50:11 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Feb 2026 19:50:11 GMT
Subject: RFR: 8376152: Test javax/sound/sampled/Clip/bug5070081.java timed
 out then completed
In-Reply-To: <p3hJXreF-pr13IKO3OBK1c54c-neG7cg-tNOWd2axME=.0b9d3b90-a48f-4c1b-93f3-06e6aa7b9287@github.com>
References: <JNKxECvIg4Dwb0uCgHUPR5jTR_JkG8Rta1RbV7wQvEE=.778c56dc-09e3-481a-8336-43beac4f082e@github.com>
 <p3hJXreF-pr13IKO3OBK1c54c-neG7cg-tNOWd2axME=.0b9d3b90-a48f-4c1b-93f3-06e6aa7b9287@github.com>
Message-ID: <e4l84_JDiPlAwSD_Hk6zYl4nK5owg1SeVcCocbIteog=.064483ff-cfeb-4a7a-b0e8-094f49771736@github.com>

On Tue, 24 Feb 2026 19:59:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> this test has a guard by LineUnavailableException/IllegalArgumentException --> the test is not applicable/
>It is suspicion that it hangs when the report say "STATUS:Passed." What is the reason?

Nobody investigated that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29901#issuecomment-3961620364

From serb at openjdk.org  Wed Feb 25 19:57:10 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Feb 2026 19:57:10 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v5]
In-Reply-To: <FzXHIQv5RI1OOFOPARquL3HB9-VkWViL-BjmxDS34I4=.42ccc740-efc6-4618-a4a1-512d25532002@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <FzXHIQv5RI1OOFOPARquL3HB9-VkWViL-BjmxDS34I4=.42ccc740-efc6-4618-a4a1-512d25532002@github.com>
Message-ID: <dhV42PzNIS_wp25DFQaBUht36K_x1TXo17fQ7Ww3njs=.74c173f4-8a3c-4102-9942-09afa34d37fd@github.com>

On Mon, 23 Feb 2026 20:27:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
>> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
>> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
>> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
>> 
>> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
>> I did that and ran all our existing automated tests on our CI systems.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8373626

Changes requested by serb (Reviewer).

src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16nw.c line 1093:

> 1091: 
> 1092:             k0 = pk[0]; k1 = pk[1]; k2 = pk[2];
> 1093: 

`sp += (kw - 1)*chan1` is missing?
it exists in kw == 6,5,4,2,1 and only missing here for kw == 3

-------------

PR Review: https://git.openjdk.org/jdk/pull/29257#pullrequestreview-3856546242
PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2855103572

From serb at openjdk.org  Wed Feb 25 20:13:21 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Feb 2026 20:13:21 GMT
Subject: Integrated: 6434110: Color constructor parameter name is misleading
In-Reply-To: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
References: <1kkSChh30GYXT5F0Re66lxWlzvgUj09RMNLOHLH8rYI=.f2b08f46-e4c4-43a7-85d7-a4962f51b862@github.com>
Message-ID: <YHHwCJiKcZIMRQGoi3wuIJFTtJlGV1qqglGqnWJke7Y=.eaaa771e-738a-473e-81ff-52529017c52e@github.com>

On Mon, 16 Feb 2026 07:40:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Small cleanup: the parameter names in the Color(int, boolean) constructor have been renamed:
>  - rgba -> argb, since this is the format described in the spec
>  - hasalpha -> hasAlpha, to follow common naming conventions
> 
> Also adds a basic test for the constructor.

This pull request has now been integrated.

Changeset: 36d67ffd
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36d67ffd0188070d0fb087beffece15fea4ba956
Stats:     100 lines in 2 files changed: 77 ins; 0 del; 23 mod

6434110: Color constructor parameter name is misleading

Reviewed-by: prr, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/29734

From serb at openjdk.org  Wed Feb 25 20:54:52 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 25 Feb 2026 20:54:52 GMT
Subject: RFR: 8378201: [OGL] glXMakeContextCurrent() drops the buffers of the
 unbound drawable
Message-ID: <x3M-lK8T0-NdQ4UBJhpWFAd11mS-Vwj64P-Z3MOOrV4=.3fc2ab51-9cc7-4513-80d7-6ced4b6297e4@github.com>

The OGL pipeline on Linux passes raw X11 window id to GLX. This is allowed by the spec but is a deprecated compatibility path. Mesa has a [bug](https://gitlab.freedesktop.org/mesa/mesa/-/issues/1001) where glXMakeContextCurrent() drops the buffers of the previously bound drawable when switching to a different window, corrupting its content.

The fix creates GLXWindow objects via glXCreateWindow() and uses them instead of raw window id for all GLX calls. The question is where to store the GLXWindow. It could be stored in the java in XWindow and passed around, but that would pollute "shared xawt code" with OGL specific state even when OGL is not enabled. Instead, the GLXWindow is managed entirely on the native OGL side using a map keyed by the X window id. This keeps one GLXWindow per X window, creates it only when GLX surfaces are actually used, and uses reference counting so it is destroyed when the last surface releases it.

Also fixes [JDK-8369561](https://bugs.openjdk.org/browse/JDK-8369561) ? wrong pixel colors in DrawBitmaskImage on Linux, same root cause.

Two tests added:
- MultiWindowFillTest ? reproduces the bug: paints two windows different colors, switches context between them, verifies the first window's content survives
- FlipCoexistTest ? verifies that direct rendering and flip BufferStrategy coexist on the same window. This test will fail if the implementation creates a separate GLXWindow per Java OGL surface instead of sharing one per X window

-------------

Commit messages:
 - Update tests
 - 8378201: [OGL] glXMakeContextCurrent() drops the buffers of the unbound drawable

Changes: https://git.openjdk.org/jdk/pull/29886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378201
  Stats: 351 lines in 4 files changed: 346 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/29886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29886/head:pull/29886

PR: https://git.openjdk.org/jdk/pull/29886

From serb at openjdk.org  Thu Feb 26 01:06:02 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 26 Feb 2026 01:06:02 GMT
Subject: RFR: 6741930: JOptionPane doesn't honour Focus Traversal Policy
In-Reply-To: <odqyvMVsv-Hg9NCC0hK7NcH0QiIRda4nBVYcNifY23Q=.94bef2e2-f964-4959-bb22-ff4134e5e181@github.com>
References: <vILinJtY2qP0llY_VhqepAtejMDTSLQjZcBtDYZnBeI=.b69c9a4a-cf1f-4126-b21e-1bd8a634144f@github.com>
 <odqyvMVsv-Hg9NCC0hK7NcH0QiIRda4nBVYcNifY23Q=.94bef2e2-f964-4959-bb22-ff4134e5e181@github.com>
Message-ID: <obWPzHRTxWbqj3uRjLvHM--jW0xE2gqrSqcRxrzqvfQ=.a35714e6-3b34-4820-a0ef-2ca08dfed50b@github.com>

On Tue, 24 Feb 2026 04:40:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>It is only called from one place

This is our class, but above I meant the usage in the wild by applications.

> and as per OptionPaneUI spec it should request the component to have focus which I believe the author of this method intended for the passed component else there is no need to pass in the param

The author of OptionPaneUI appears to have expected that behavior. However, the specification for the subclass BasicOptionPaneUI overrides it. So the question is which specification should be followed, and if the code is changed, which specification should be updated accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29738#issuecomment-3963219431

From psadhukhan at openjdk.org  Thu Feb 26 02:54:22 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 02:54:22 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F [v2]
In-Reply-To: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
Message-ID: <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>

> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
> 
> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
> 
> Without fix
> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
> 
> With fix
> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Update preferredsize

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29808/files
  - new: https://git.openjdk.org/jdk/pull/29808/files/5306c5cc..b2f65c91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29808&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29808&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29808/head:pull/29808

PR: https://git.openjdk.org/jdk/pull/29808

From psadhukhan at openjdk.org  Thu Feb 26 02:54:24 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 02:54:24 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F
In-Reply-To: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
Message-ID: <jpnf68DcLUeZxays-598BrenHpUREs1ZLVOW8LlYGVA=.699a6027-6fa2-433c-8124-4035becfc305@github.com>

On Thu, 19 Feb 2026 02:52:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
> 
> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
> 
> Without fix
> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
> 
> With fix
> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />

When frame is made visible, the layouting is done and `BasicMenuItemUI.getPreferredMenuItemSize` called from `BasicMenuUI.getMaximumSize`, is called which does some calculations and returns menu width to 9 for zero text-length`JMenu`
 which is why popup is visible even when clicked on middle of system icon, which is of `16x16` size, for even zero-text-length JMenu but not at the right edge.
 For non-zero text's JMenu, `getPreferredMenuItemSize()` returns menu width to 15 so popup is visible when clicked on right edge of icon 
 Since the preferred width is getting updated while layouting if not specified initially, its better to set the preferred width upfront to image icon size
 so that whole icon area is activated for popup menu, so both left and right edge will work, therefore I have updated the PR accordingly..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29808#issuecomment-3963635107

From serb at openjdk.org  Thu Feb 26 02:56:30 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 26 Feb 2026 02:56:30 GMT
Subject: RFR: 8378377: Remove use of AppContext from JEditorPane [v4]
In-Reply-To: <Ieba1KirpO5_lrwZXXDw4mb2b_wIevOqmLEhCm7kdK0=.8903fe95-0053-42f2-bde8-006be6bffa0e@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
 <Ieba1KirpO5_lrwZXXDw4mb2b_wIevOqmLEhCm7kdK0=.8903fe95-0053-42f2-bde8-006be6bffa0e@github.com>
Message-ID: <rWAtZ-DLKmwnU5s4IGsTS5mdMZ8C27vLoufOLmzEgOk=.b58ef97a-f97d-47ea-a94a-1db2f19f74cf@github.com>

On Wed, 25 Feb 2026 18:06:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from JEditorPane
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378377

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29855#pullrequestreview-3858118526

From psadhukhan at openjdk.org  Thu Feb 26 03:08:22 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 03:08:22 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <SRJPmuFluC2UBBBfxb7uVeaMiyfSZIA8-WUgc45tJsU=.15aad0d2-8edc-4f7f-a71e-bfb56dd28141@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
 <In5x_9CVTougnOmTMLdIlyZ1wrNeRv2cnxMNIkC9vsM=.fb887deb-bb30-4cee-8a8e-d0d30d1db2a9@github.com>
 <SRJPmuFluC2UBBBfxb7uVeaMiyfSZIA8-WUgc45tJsU=.15aad0d2-8edc-4f7f-a71e-bfb56dd28141@github.com>
Message-ID: <u4MobpfV7c8Q0kOZLwJFD0HCVQimIqju2TTcbXBNGE8=.f5dcf6de-08b3-4a66-ad30-7b79ab17d1d9@github.com>

On Wed, 25 Feb 2026 11:30:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/PageRangesAuto.java line 97:
>> 
>>> 95:         String fileName = pageRange == null
>>> 96:                           ? baseName + "-all.pdf"
>>> 97:                           : String.format("%s-%d-%d.pdf",
>> 
>> I believe `Destination` creates file in .prn or .ps format and not .pdf..
>> https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/print/attribute/standard/Destination.html
>> 
>>> A common use for this attribute will be applications which want to redirect output to a local disk file : eg."file:out.prn"
>> 
>> I am not able to open this file atleast in Windows as Acrobat fails to recognize the file type even though its pdf
>
> On macOS, it creates valid PDF files, all the files are viewable in the Preview utility.
> 
> On Windows, all these files open just fine in Firefox and Edge.

I am not sure..It doesn't open for me in my Firefor or Edge too. The filetype being created it seems xpif which is not pdf

%-12345X at PJL JOB
@PJL XCPT <?xml version="1.0" encoding="UTF-8"?>
@PJL XCPT <!DOCTYPE xpif SYSTEM "xpif-v02082.dtd">
@PJL XCPT <xpif version="1.0" cpss-version="2.07" xml:lang="en-US">

Also, other printing tests which uses Destination class like
java/awt/print/Dialog/PrintDlgApp.java
java/awt/print/PrinterJob/DeviceScale.java
java/awt/print/PrinterJob/PrintAfterEndTest.java
java/awt/print/PrinterJob/PrintCrashTest.java
java/awt/print/PrinterJob/PrintNullString.java
java/awt/print/PrinterJob/PrintTextPane.java
java/awt/print/PrinterJob/PrintToFileTest.java
all uses .prn or .ps so maybe there's a reason to it..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2856640521

From psadhukhan at openjdk.org  Thu Feb 26 03:16:34 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 03:16:34 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v4]
In-Reply-To: <pxQhZj6jo0R-N_4ZZwYuWhgaWrYqlC69Ie8c5OGfFHA=.3b875927-162b-4a37-b9c0-2997f96adf89@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <pxQhZj6jo0R-N_4ZZwYuWhgaWrYqlC69Ie8c5OGfFHA=.3b875927-162b-4a37-b9c0-2997f96adf89@github.com>
Message-ID: <1M6IthTqstlz2brgyyHvnXuqgZ1nZWzYC9yDmFgbuKM=.4e1fb85a-f235-4d6b-814b-e1f9b0e0c052@github.com>

On Wed, 25 Feb 2026 11:08:27 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test tag updated

I am not sure if @headful tag is needed for this test..

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29733#pullrequestreview-3858172797

From psadhukhan at openjdk.org  Thu Feb 26 03:34:55 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 03:34:55 GMT
Subject: RFR: 8378623: Use unique font names in FormatCharAdvanceTest
In-Reply-To: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
References: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
Message-ID: <w6uP1Z72ucEUzw5EwmQwocHlnd0LcnypHZHx41E14l0=.9e119dc7-f62c-4b6f-ae3c-9d89a28f12b6@github.com>

On Wed, 25 Feb 2026 05:36:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> While working on [JDK-8373290](https://bugs.openjdk.org/browse/JDK-8373290), it is noticed that with FreeType update java/awt/font/TextLayout/FormatCharAdvanceTest.java is failing.
> 
> On more analysis it is found that this Test is not using appropriate FontMetrics under FontMetrics.stringWidth() and Font.getStringBounds("AB", frc) code path. Test continues to use Type1 FontMetrics for TTF font.
> 
> Freetype update just revealed this issue as "width" slightly changes between the Type1 and TTF font used in this test(This is happening because of hinting/rounding change in FreeType update). We are not seeing any change of Metrics for other Physical(Helvetica.ttf) or Logical(Dialog) fonts.
> 
> We have separate bug [JDK-8378622](https://bugs.openjdk.org/browse/JDK-8378622) to analyse and fix FontMetrics caching issue. We are updating FormatCharAdvanceTest to use unique "font name" for both Type1 and TTF font to pick valid FontMetrics and make this test work properly. Changing the font name will not affect the purpose of this test.

test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 8208377 6562489 8270265 8356803 8356812 4517298 8378623

we dont add test fix bugid to the tag, only product fix bugid

test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java line 132:

> 130:      * </pre>
> 131:      */
> 132:     private static final String TTF_BYTES = "AAEAAAANAIAAAwBQRkZUTbCUBjwAABcAAAAAHE9TLzKD7vqWAAABWAAAAGBjbWFw11zF/AAAAvwAAANSY3Z0IABEBREAAAZQAAAABGdhc3D//wADAAAW+AAAAAhnbHlmgVJ3qAAAB4gAAAnMaGVhZC1MmToAAADcAAAANmhoZWEIcgJiAAABFAAAACRobXR4L1UevAAAAbgAAAFEbG9jYb8EwZoAAAZUAAABNG1heHAA4ABCAAABOAAAACBuYW1lLzI4NgAAEVQAAAGtcG9zdBSfZd0AABMEAAAD8QABAAAAAQAAp/gvll8PPPUACwgAAAAAAOXDJ3QAAAAA5cMndABEAAACZAVVAAAACAACAAAAAAAAAAEAAAVVAAAAuAJYAAAAAAJkAAEAAAAAAAAAAAAAAAAAAAAJAAEAAACZAAgAAgAIAAIAAgAAAAEAAQAAAEAALgABAAEABAJXAZAABQAABTMFmQAAAR4FMwWZAAAD1wBmAhIAAAIABQMAAAAAAACAACADAgAAABECAKgAAAAAUGZFZACAAAn//wZm/mYAuAVVAAAAAAABAAAAAADIAMgAAAAgAAEC7ABEAAAAAAJYAGQCWABkAlgAZAJYAGQCWABkAjkAAAJYAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAG
 QAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAAAAFAAAAAwAAACwAAAAEAAAA7AABAAAAAAJMAAMAAQAAACwAAwAKAAAA7AAEAMAAAAAoACAABAAIAA0AIAA5AFoAegCFAK0GBQYcBt0HDwiRCOIYDiAPIC8gb/7///v//wAAAAkAIAAwAEEAYQCFAK0GAAYcBt0HDwiQCOIYDiALICggYP7///n//wAA/+f/2P/R/8v/wf+a+kj6Mvly+UH3wfdx6EbgSuAy4AIBcwAAAAEAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAMABAAFAAYAAgBzAHQAdQAMAAAAAAFgAAAAAAAAABwAAAAJAAAADAAAAAMAAAANAAAADQAAAAIAAAAgAAAAIAAAAAcAAAAwAAAAOQAAAAgAAABBAAAAWgAAABIAAABhAAAAegAAACwAAACFAAAAhQAAAEYAAACtAAAArQAAAEcAAAYAAAAGBQAAAEgAAAYcAAAGHAAAAE4AAAbdAAAG3QAAAE8AAAcPAAAHDwAAAFAAAAiQAAAIkQAAAFEAAAjiAAAI4gAAAFMAABgOAAAYDgAAAFQAACALAAAgDwAAAFUAACAoAAAgLwAAAFoAACBgAAAgbwAAAGIAAP7/AAD+/wAAAHIAAP/5AAD/+wAAAHMAARC9AAEQvQAAAHYAARDNAAEQzQAAAHcAATQwAAE0PwAAAHgAAbygAAG8owAAAIgAAdFzAAHRegAAAIwADgABAA4AAQAAAJQADgAgAA4AIQAAAJUADgB+AA4AfwAAAJcAAAEGAAABAAAAAAAAAAEDBAUGAgAAAAAAAAAAAAAAAAAAAAEAAAcAAAAAAAAAAAAAAAAAAAAICQoLDA0ODxARAAAAAAAAABITFBUWFxgZGhscHR4fICEiIyQlJicoKSorAAAAAAAALC0
 uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAURAAAALAAsADQAPABEAEwAVABUAFwAZABsAHQAfACEAIwAlACcAKQArAC0ALwAxADMANQA3ADkAOwA9AD8AQQBDAEUARwBJAEsATQBPAFEAUwBVAFcAWQBbAF0AYYBjgGWAZ4BpgGuAbYBvgHGAc4B1gHeAeYB7gH2Af4CBgIOAhYCHgImAi4CNgI+AkYCTgJWAl4CZgJuAnYCfgKGAo4ClgKeAqYCrgK2Ar4CxgLOAtYC3gLmAu4C9gL+AwYDDgMWAx4DJgMuAzYDPgNGA04DVgNeA2YDbgN2A34DhgOOA5YDngOmA64DtgO+A8YDzgPWA94D5gPuA/YD/gQGBA4EFgQeBCYELgQ2BD4ERgROBFYEXgRmBG4EdgR+BIYEjgSWBJ4EpgSuBLYEvgTGBM4E1gTeBOYAAgBEAAACZAVVAAMABwAusQEALzyyBwQA7TKxBgXcPLIDAgDtMgCxAwAvPLIFBADtMrIHBgH8PLIBAgDtMjMRIRElIREhRAIg/iQBmP5oBVX6q0QEzQAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYA
 LAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAAAAgBkAGQB9ADIAAMABwAANzUhFSE1IRVkAZD+cAGQZGRkZGT//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkA
 GQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP
 //AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAD//wBkAGQB9ADIEgYALAAA//8AZABkAfQAyBIGACwAAP//AGQAZAH0AMgSBgAsAAAAAAAOAK4AAQAAAAA
 AAAAAAAIAAQAAAAAAAQAHABMAAQAAAAAAAgAHACsAAQAAAAAAAwAjAHsAAQAAAAAABAAHAK8AAQAAAAAABQAPANcAAQAAAAAABgAHAPcAAwABBAkAAAAAAAAAAwABBAkAAQAOAAMAAwABBAkAAgAOABsAAwABBAkAAwBGADMAAwABBAkABAAOAJ8AAwABBAkABQAeALcAAwABBAkABgAOAOcAAAAAVABUAEYAVABlAHMAdAAAVFRGVGVzdAAAUgBlAGcAdQBsAGEAcgAAUmVndWxhcgAARgBvAG4AdABGAG8AcgBnAGUAIAAyAC4AMAAgADoAIABUAFQARgBUAGUAcwB0ACAAOgAgADIANAAtADIALQAyADAAMgA2AABGb250Rm9yZ2UgMi4wIDogVFRGVGVzdCA6IDI0LTItMjAyNgAAVABUAEYAVABlAHMAdAAAVFRGVGVzdAAAVgBlAHIAcwBpAG8AbgAgADAAMAAxAC4AMAAwADAAAFZlcnNpb24gMDAxLjAwMAAAVABUAEYAVABlAHMAdAAAVFRGVGVzdAAAAAAAAgAAAAAAAP9nAGYAAAAAAAAAAAAAAAAAAAAAAAAAAACZAAAAAQECAQMBBAEFAQYAAwATABQAFQAWABcAGAAZABoAGwAcACQAJQAmACcAKAApACoAKwAsAC0ALgAvADAAMQAyADMANAA1ADYANwA4ADkAOgA7ADwAPQBEAEUARgBHAEgASQBKAEsATABNAE4ATwBQAFEAUgBTAFQAVQBWAFcAWABZAFoAWwBcAF0BBwEIAQkBCgELAQwBDQEOAQ8BEAERARIBEwEUARUBFgEXARgBGQEaARsBHAEdAR4BHwEgASEBIgEjASQBJQEmAScBKAEpASoBKwEsAS0BLgEvATABMQEyATMBNAE1ATYBNwE4ATkBOgE7ATwBPQE+AT8BQAFBAUIBQwFEAUUBRgFHAUgBSQFKAUsBTAFNAU4BTwFQAVEBUgFT
 AVQBVQFWAVcBWAFZB3VuaTAwMEQHdW5pMDAwOQd1bmkwMDBBB3VuaTAwMEIHdW5pMDAwQwd1bmkwMDg1B3VuaTAwQUQHdW5pMDYwMAd1bmkwNjAxB3VuaTA2MDIHdW5pMDYwMwd1bmkwNjA0B3VuaTA2MDUHdW5pMDYxQwd1bmkwNkREB3VuaTA3MEYHdW5pMDg5MAd1bmkwODkxB3VuaTA4RTIHdW5pMTgwRQd1bmkyMDBCB3VuaTIwMEMHdW5pMjAwRAd1bmkyMDBFB3VuaTIwMEYHdW5pMjAyOAd1bmkyMDI5B3VuaTIwMkEHdW5pMjAyQgd1bmkyMDJDB3VuaTIwMkQHdW5pMjAyRQd1bmkyMDJGB3VuaTIwNjAHdW5pMjA2MQd1bmkyMDYyB3VuaTIwNjMHdW5pMjA2NAd1bmkyMDY1B3VuaTIwNjYHdW5pMjA2Nwd1bmkyMDY4B3VuaTIwNjkHdW5pMjA2QQd1bmkyMDZCB3VuaTIwNkMHdW5pMjA2RAd1bmkyMDZFB3VuaTIwNkYHdW5pRkVGRgd1bmlGRkY5B3VuaUZGRkEHdW5pRkZGQgZ1MTEwQkQGdTExMENEBnUxMzQzMAZ1MTM0MzEGdTEzNDMyBnUxMzQzMwZ1MTM0MzQGdTEzNDM1BnUxMzQzNgZ1MTM0MzcGdTEzNDM4BnUxMzQzOQZ1MTM0M0EGdTEzNDNCBnUxMzQzQwZ1MTM0M0QGdTEzNDNFBnUxMzQzRgZ1MUJDQTAGdTFCQ0ExBnUxQkNBMgZ1MUJDQTMGdTFEMTczBnUxRDE3NAZ1MUQxNzUGdTFEMTc2BnUxRDE3NwZ1MUQxNzgGdTFEMTc5BnUxRDE3QQZ1RTAwMDEGdUUwMDIwBnVFMDAyMQZ1RTAwN0UGdUUwMDdGAAAAAAAAAf//AAIAAAABAAAAAOUNt1MAAAAA5cMndAAAAADlwyd0";

Did you change the ttf bytes too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29910#discussion_r2856689644
PR Review Comment: https://git.openjdk.org/jdk/pull/29910#discussion_r2856692401

From jdv at openjdk.org  Thu Feb 26 03:35:01 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 26 Feb 2026 03:35:01 GMT
Subject: Integrated: 8377526: Update Libpng to 1.6.55
In-Reply-To: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
References: <TAsEqQh8mCO91Y_wm35QstAEH0RIIl0sIWy4sAxiSFU=.3828190d-87d2-4557-a014-769aa31a1457@github.com>
Message-ID: <u52sE52I8en0cxrY7wEcMD-2YgPEJhHjp-XV1l7jwm4=.d93fb25f-994b-4d26-8368-b49f69a49199@github.com>

On Wed, 25 Feb 2026 16:45:35 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Upgrade libpng used for Splashscreen from 1.6.54 to 1.6.55 version.
> Testing is green with this update.

This pull request has now been integrated.

Changeset: fd74232d
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd74232d5dc4c6bfbcddb82e1b2621289aa2f65a
Stats:     32 lines in 8 files changed: 7 ins; 0 del; 25 mod

8377526: Update Libpng to 1.6.55

Reviewed-by: azvegint, prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/29922

From rkannathpari at openjdk.org  Thu Feb 26 03:49:04 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 26 Feb 2026 03:49:04 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v5]
In-Reply-To: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
Message-ID: <f8LtYyNm0buNQ5VeZXwuH-XLhnBk8jgKZc4GU-dxeUU=.8d805088-8fe1-4e95-97b9-91f6c1ba1974@github.com>

> Hi Reviewers,
> 
> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
> 
> Please review and let me know your suggestions.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Removed headful tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29733/files
  - new: https://git.openjdk.org/jdk/pull/29733/files/d30a3aff..68d93f8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29733&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29733&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29733/head:pull/29733

PR: https://git.openjdk.org/jdk/pull/29733

From psadhukhan at openjdk.org  Thu Feb 26 03:52:06 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 03:52:06 GMT
Subject: RFR: 8378297: Remove AppContext from several Swing component and
 related classes [v4]
In-Reply-To: <KyvCisU2pB_MuuSeSAYYi4No01jKP6pZRoz50zrClZU=.49a01087-d0ad-4e1f-8a7f-fe91ba0da1e6@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
 <KyvCisU2pB_MuuSeSAYYi4No01jKP6pZRoz50zrClZU=.49a01087-d0ad-4e1f-8a7f-fe91ba0da1e6@github.com>
Message-ID: <TLaZNix9DYmYutAZAtK5YjJ9b37wamLmm2O4PsPYufQ=.ddfe8821-ba9f-40b1-ad7e-2f09bf0f507f@github.com>

On Wed, 25 Feb 2026 18:01:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
>> 
>> One ToolTipManager test for the AppContext is removed.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378297

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29830#pullrequestreview-3858239844

From psadhukhan at openjdk.org  Thu Feb 26 03:53:58 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 03:53:58 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v5]
In-Reply-To: <f8LtYyNm0buNQ5VeZXwuH-XLhnBk8jgKZc4GU-dxeUU=.8d805088-8fe1-4e95-97b9-91f6c1ba1974@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <f8LtYyNm0buNQ5VeZXwuH-XLhnBk8jgKZc4GU-dxeUU=.8d805088-8fe1-4e95-97b9-91f6c1ba1974@github.com>
Message-ID: <49eFMjQJBnr3ECTpjxcfd7Iqr6IseAQB7LZY44QndYE=.0a38109b-f67d-4f4d-a76c-a1059ab6c481@github.com>

On Thu, 26 Feb 2026 03:49:04 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed headful tag

I hope you have tested in CI

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29733#pullrequestreview-3858242557

From rkannathpari at openjdk.org  Thu Feb 26 03:59:07 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 26 Feb 2026 03:59:07 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v5]
In-Reply-To: <49eFMjQJBnr3ECTpjxcfd7Iqr6IseAQB7LZY44QndYE=.0a38109b-f67d-4f4d-a76c-a1059ab6c481@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <f8LtYyNm0buNQ5VeZXwuH-XLhnBk8jgKZc4GU-dxeUU=.8d805088-8fe1-4e95-97b9-91f6c1ba1974@github.com>
 <49eFMjQJBnr3ECTpjxcfd7Iqr6IseAQB7LZY44QndYE=.0a38109b-f67d-4f4d-a76c-a1059ab6c481@github.com>
Message-ID: <HTp6k4e7DPxCgyU3S3imV32SJs3oX2DOBNI1cWYgXjU=.b07cc5c2-fc26-4eee-8aa4-1906f0636ce5@github.com>

On Thu, 26 Feb 2026 03:51:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed headful tag
>
> I hope you have tested in CI

Hi @prsadhuk,

You are right there is no UI in this test other than printer settings. Intention of the test evaluate exception handling, observed similar tests runs in headless mode so I believe we are safe to remove @headful from the test. 

Updated

Regards,
Renjith.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29733#issuecomment-3963810319

From jdv at openjdk.org  Thu Feb 26 04:04:16 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 26 Feb 2026 04:04:16 GMT
Subject: RFR: 8378623: Use unique font names in FormatCharAdvanceTest [v2]
In-Reply-To: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
References: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
Message-ID: <iEZzS9uZEvPgx6osUa_P7UrcrdTErjWWLCsoKUcXrtg=.fb633d98-0bc3-4d56-99f6-6403aa8c82ab@github.com>

> While working on [JDK-8373290](https://bugs.openjdk.org/browse/JDK-8373290), it is noticed that with FreeType update java/awt/font/TextLayout/FormatCharAdvanceTest.java is failing.
> 
> On more analysis it is found that this Test is not using appropriate FontMetrics under FontMetrics.stringWidth() and Font.getStringBounds("AB", frc) code path. Test continues to use Type1 FontMetrics for TTF font.
> 
> Freetype update just revealed this issue as "width" slightly changes between the Type1 and TTF font used in this test(This is happening because of hinting/rounding change in FreeType update). We are not seeing any change of Metrics for other Physical(Helvetica.ttf) or Logical(Dialog) fonts.
> 
> We have separate bug [JDK-8378622](https://bugs.openjdk.org/browse/JDK-8378622) to analyse and fix FontMetrics caching issue. We are updating FormatCharAdvanceTest to use unique "font name" for both Type1 and TTF font to pick valid FontMetrics and make this test work properly. Changing the font name will not affect the purpose of this test.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Remove jtreg bugid

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29910/files
  - new: https://git.openjdk.org/jdk/pull/29910/files/cd6ee49a..e7a0ece0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29910&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29910&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29910.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29910/head:pull/29910

PR: https://git.openjdk.org/jdk/pull/29910

From jdv at openjdk.org  Thu Feb 26 04:08:52 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 26 Feb 2026 04:08:52 GMT
Subject: RFR: 8378623: Use unique font names in FormatCharAdvanceTest [v2]
In-Reply-To: <w6uP1Z72ucEUzw5EwmQwocHlnd0LcnypHZHx41E14l0=.9e119dc7-f62c-4b6f-ae3c-9d89a28f12b6@github.com>
References: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
 <w6uP1Z72ucEUzw5EwmQwocHlnd0LcnypHZHx41E14l0=.9e119dc7-f62c-4b6f-ae3c-9d89a28f12b6@github.com>
Message-ID: <pSfokZtukzES47GwhQZ0FcxEPamUfJKd-vsq-Xnd0UQ=.460e655a-0391-493c-a6b4-b93c1564a8ec@github.com>

On Thu, 26 Feb 2026 03:31:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove jtreg bugid
>
> test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java line 132:
> 
>> 130:      * </pre>
>> 131:      */
>> 132:     private static final String TTF_BYTES = "AAEAAAANAIAAAwBQRkZUTbCUBjwAABcAAAAAHE9TLzKD7vqWAAABWAAAAGBjbWFw11zF/AAAAvwAAANSY3Z0IABEBREAAAZQAAAABGdhc3D//wADAAAW+AAAAAhnbHlmgVJ3qAAAB4gAAAnMaGVhZC1MmToAAADcAAAANmhoZWEIcgJiAAABFAAAACRobXR4L1UevAAAAbgAAAFEbG9jYb8EwZoAAAZUAAABNG1heHAA4ABCAAABOAAAACBuYW1lLzI4NgAAEVQAAAGtcG9zdBSfZd0AABMEAAAD8QABAAAAAQAAp/gvll8PPPUACwgAAAAAAOXDJ3QAAAAA5cMndABEAAACZAVVAAAACAACAAAAAAAAAAEAAAVVAAAAuAJYAAAAAAJkAAEAAAAAAAAAAAAAAAAAAAAJAAEAAACZAAgAAgAIAAIAAgAAAAEAAQAAAEAALgABAAEABAJXAZAABQAABTMFmQAAAR4FMwWZAAAD1wBmAhIAAAIABQMAAAAAAACAACADAgAAABECAKgAAAAAUGZFZACAAAn//wZm/mYAuAVVAAAAAAABAAAAAADIAMgAAAAgAAEC7ABEAAAAAAJYAGQCWABkAlgAZAJYAGQCWABkAjkAAAJYAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkA
 GQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAZABkAGQAAAAFAAAAAwAAACwAAAAEAAAA7AABAAAAAAJMAAMAAQAAACwAAwAKAAAA7AAEAMAAAAAoACAABAAIAA0AIAA5AFoAegCFAK0GBQYcBt0HDwiRCOIYDiAPIC8gb/7///v//wAAAAkAIAAwAEEAYQCFAK0GAAYcBt0HDwiQCOIYDiALICggYP7///n//wAA/+f/2P/R/8v/wf+a+kj6Mvly+UH3wfdx6EbgSuAy4AIBcwAAAAEAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAMABAAFAAYAAgBzAHQAdQAMAAAAAAFgAAAAAAAAABwAAAAJAAAADAAAAAMAAAANAAAADQAAAAIAAAAgAAAAIAAAAAcAAAAwAAAAOQAAAAgAAABBAAAAWgAAABIAAABhAAAAegAAACwAAACFAAAAhQAAAEYAAACtAAAArQAAAEcAAAYAAAAGBQAAAEgAAAYcAAAGHAAAAE4AAAbdAAAG3QAAAE8AAAcPAAAHDwAAAFAAAAiQAAAIkQAAAFEAAAjiAAAI4gAAAFMAABgOAAAYDgAAAFQAACALAAAgDwAAAFUAACAoAAAgLwAAAFoAACBgAAAgbwAAAGIAAP7/AAD+/wAAAHIAAP/5AAD/+wAAAHMAARC9AAEQvQAAAHYAARDNAAEQzQAAAHcAATQwAAE0PwAAAHgAAbygAAG8owAAAIgAAdFzAAHRegAAAIwADgABAA4AAQAAAJQADgAgAA4AIQAAAJUADgB+AA4AfwAAAJcAAAEGAAABAAAAAAAAAAEDBAUGAgAAAAAAAAAAAAAAAAAAAAEAAAcAAAAAAAAAAAAAAAAAAAAICQoLDA0ODxARAAAAAAAAABITFBUWFxgZGhscHR4fICEiIyQlJicoKSorAAAAAAAALC
 0uLzAxMjM0NTY3ODk6Ozw9Pj9AQUJDREUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAURAAAALAAsADQAPABEAEwAVABUAFwAZABsAHQAfACEAIwAlACcAKQArAC0ALwAxADMANQA3ADkAOwA9AD8AQQBDAEUARwBJAEsATQBPAFEAUwBVAFcAWQBbAF0AYYBjgGWAZ4BpgGuAbYBvgHGAc4B1gHeAeYB7gH2Af4CBgIOAhYCHgImAi4C...

Yes. For both the fonts only Font name is updated to include some meaning instead of just using 'Test'.
Just updating one Font's family name and continue to keep another one as 'Test' is not uniform.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29910#discussion_r2856761050

From psadhukhan at openjdk.org  Thu Feb 26 04:13:19 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 04:13:19 GMT
Subject: RFR: 8378623: Use unique font names in FormatCharAdvanceTest [v2]
In-Reply-To: <iEZzS9uZEvPgx6osUa_P7UrcrdTErjWWLCsoKUcXrtg=.fb633d98-0bc3-4d56-99f6-6403aa8c82ab@github.com>
References: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
 <iEZzS9uZEvPgx6osUa_P7UrcrdTErjWWLCsoKUcXrtg=.fb633d98-0bc3-4d56-99f6-6403aa8c82ab@github.com>
Message-ID: <NGEYXJLj0qVmaC1UjyRFwHKD8_pCySe-ncASa0Fizyo=.0b93c784-be18-4c51-a90f-2e8899d1c857@github.com>

On Thu, 26 Feb 2026 04:04:16 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> While working on [JDK-8373290](https://bugs.openjdk.org/browse/JDK-8373290), it is noticed that with FreeType update java/awt/font/TextLayout/FormatCharAdvanceTest.java is failing.
>> 
>> On more analysis it is found that this Test is not using appropriate FontMetrics under FontMetrics.stringWidth() and Font.getStringBounds("AB", frc) code path. Test continues to use Type1 FontMetrics for TTF font.
>> 
>> Freetype update just revealed this issue as "width" slightly changes between the Type1 and TTF font used in this test(This is happening because of hinting/rounding change in FreeType update). We are not seeing any change of Metrics for other Physical(Helvetica.ttf) or Logical(Dialog) fonts.
>> 
>> We have separate bug [JDK-8378622](https://bugs.openjdk.org/browse/JDK-8378622) to analyse and fix FontMetrics caching issue. We are updating FormatCharAdvanceTest to use unique "font name" for both Type1 and TTF font to pick valid FontMetrics and make this test work properly. Changing the font name will not affect the purpose of this test.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jtreg bugid

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29910#pullrequestreview-3858279321

From psadhukhan at openjdk.org  Thu Feb 26 04:25:48 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Feb 2026 04:25:48 GMT
Subject: RFR: 8372952: Respect landscape orientation user selection on
 macOS and Linux [v2]
In-Reply-To: <VfNF0LeoOP7-scBuimTpXdaKWOyGCsyfV0Y_VWKXkEI=.d4dd55fa-8d90-4aab-9dcd-b3d5267244be@github.com>
References: <lb8GZRWbO4rnHCVFF8MQfgV3DIuOGIt4f49RRyhW8Ng=.7ce8594c-eef8-4a99-ab73-14ebf3130646@github.com>
 <L6epQJ_wv79hftjql8paFgsDF3zRzNRW6dX_f3-O8Aw=.5f6e8760-58b9-4e68-980f-1948f72a8c7a@github.com>
 <1Ry15_1J9BKz3mANlXPpq2pBoLP_a9lPQ9Z9Qbi-2vU=.7eb835fb-b505-4d53-812b-c6b9055a8114@github.com>
 <VfNF0LeoOP7-scBuimTpXdaKWOyGCsyfV0Y_VWKXkEI=.d4dd55fa-8d90-4aab-9dcd-b3d5267244be@github.com>
Message-ID: <sFySy8KQ3Ji023Y1KUDYrOIqLEx1pzqZUM8WY9dtn60=.f1b4360a-a319-4bdd-97e1-2e147168f724@github.com>

On Wed, 25 Feb 2026 07:43:33 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> It's not a regression. JDK-8295737 fixed a related issue on macOS but did not fix the bug on Linux. Also it does not select a paper explicitly on macOS. If a user chooses landscape-oriented paper, the printer may ignore user's choice and print with portrait-oriented paper. Let me amend the issue synopsis to avoid confusion.

You mention that the fix is for linux as well but it seems all the files fixed are for macos, except one where IllegalArgumentException is touched. I hope you have not missed adding PSPrinterJob fix to this..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29560#issuecomment-3963881777

From jdv at openjdk.org  Thu Feb 26 05:52:16 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 26 Feb 2026 05:52:16 GMT
Subject: Integrated: 8378623: Use unique font names in FormatCharAdvanceTest
In-Reply-To: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
References: <saT0XMSXwarGC_pyfMCxEkNNapvW4NlCaugXifz9k6c=.1d08b410-662e-46a3-8c1d-d6f00add50ba@github.com>
Message-ID: <tQKXI1SwdW9aNP1Z23whblMHmw25veA8pYpVRutXad4=.b2100285-b985-48bc-984e-c3dd2e701ab2@github.com>

On Wed, 25 Feb 2026 05:36:25 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> While working on [JDK-8373290](https://bugs.openjdk.org/browse/JDK-8373290), it is noticed that with FreeType update java/awt/font/TextLayout/FormatCharAdvanceTest.java is failing.
> 
> On more analysis it is found that this Test is not using appropriate FontMetrics under FontMetrics.stringWidth() and Font.getStringBounds("AB", frc) code path. Test continues to use Type1 FontMetrics for TTF font.
> 
> Freetype update just revealed this issue as "width" slightly changes between the Type1 and TTF font used in this test(This is happening because of hinting/rounding change in FreeType update). We are not seeing any change of Metrics for other Physical(Helvetica.ttf) or Logical(Dialog) fonts.
> 
> We have separate bug [JDK-8378622](https://bugs.openjdk.org/browse/JDK-8378622) to analyse and fix FontMetrics caching issue. We are updating FormatCharAdvanceTest to use unique "font name" for both Type1 and TTF font to pick valid FontMetrics and make this test work properly. Changing the font name will not affect the purpose of this test.

This pull request has now been integrated.

Changeset: d7c8000a
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7c8000a493e58c677fed2e04678bb56e70dffc4
Stats:     19 lines in 1 file changed: 5 ins; 0 del; 14 mod

8378623: Use unique font names in FormatCharAdvanceTest

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/29910

From duke at openjdk.org  Thu Feb 26 06:07:51 2026
From: duke at openjdk.org (duke)
Date: Thu, 26 Feb 2026 06:07:51 GMT
Subject: RFR: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print" [v5]
In-Reply-To: <f8LtYyNm0buNQ5VeZXwuH-XLhnBk8jgKZc4GU-dxeUU=.8d805088-8fe1-4e95-97b9-91f6c1ba1974@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
 <f8LtYyNm0buNQ5VeZXwuH-XLhnBk8jgKZc4GU-dxeUU=.8d805088-8fe1-4e95-97b9-91f6c1ba1974@github.com>
Message-ID: <m9XAsev38ZNcXUEc-2-xM2hnnBwcKBQ0uvrO7m3L9lk=.e70a2899-70f0-49f0-b424-13b226a02ab9@github.com>

On Thu, 26 Feb 2026 03:49:04 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
>> 
>> Please review and let me know your suggestions.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed headful tag

@Renjithkannath 
Your change (at version 68d93f8aa0d577ef9c252973b7934f4d08f4aa1f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29733#issuecomment-3964319603

From aivanov at openjdk.org  Thu Feb 26 09:27:29 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Feb 2026 09:27:29 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <u4MobpfV7c8Q0kOZLwJFD0HCVQimIqju2TTcbXBNGE8=.f5dcf6de-08b3-4a66-ad30-7b79ab17d1d9@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
 <In5x_9CVTougnOmTMLdIlyZ1wrNeRv2cnxMNIkC9vsM=.fb887deb-bb30-4cee-8a8e-d0d30d1db2a9@github.com>
 <SRJPmuFluC2UBBBfxb7uVeaMiyfSZIA8-WUgc45tJsU=.15aad0d2-8edc-4f7f-a71e-bfb56dd28141@github.com>
 <u4MobpfV7c8Q0kOZLwJFD0HCVQimIqju2TTcbXBNGE8=.f5dcf6de-08b3-4a66-ad30-7b79ab17d1d9@github.com>
Message-ID: <nmlftW5YCJWWPtWXVSCVreYQOc5OxNgzRJGX30J8jQU=.f8b7445f-65c6-4b63-a520-ce80141e06be@github.com>

On Thu, 26 Feb 2026 03:05:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On macOS, it creates valid PDF files, all the files are viewable in the Preview utility.
>> 
>> On Windows, all these files open just fine in Firefox and Edge.
>
> I am not sure..It doesn't open for me in my Firefor or Edge too. The filetype being created it seems xpif which is not pdf
> 
> %-12345X at PJL JOB
> @PJL XCPT <?xml version="1.0" encoding="UTF-8"?>
> @PJL XCPT <!DOCTYPE xpif SYSTEM "xpif-v02082.dtd">
> @PJL XCPT <xpif version="1.0" cpss-version="2.07" xml:lang="en-US">
> 
> Also, other printing tests which uses Destination class like
> java/awt/print/Dialog/PrintDlgApp.java
> java/awt/print/PrinterJob/DeviceScale.java
> java/awt/print/PrinterJob/PrintAfterEndTest.java
> java/awt/print/PrinterJob/PrintCrashTest.java
> java/awt/print/PrinterJob/PrintNullString.java
> java/awt/print/PrinterJob/PrintTextPane.java
> java/awt/print/PrinterJob/PrintToFileTest.java
> all uses .prn or .ps so maybe there's a reason to it..

Whatever! I can change the extension, if you insist?it's not the point of the test at all.

For me, the file inside starts with `%PDF-1.7`. How do I open `.prn` file? I remember I renamed `.prn` to `.pdf` quite a few times to view the result, and it always worked for me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2857922787

From dgredler at openjdk.org  Thu Feb 26 10:36:11 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 26 Feb 2026 10:36:11 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation [v2]
In-Reply-To: <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
 <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
Message-ID: <2Fa5eVTkGTX2cbkzRQYHK9INa9RBvfadgstrCpxscig=.724eee5a-8976-4bd6-bef8-7ccf5327d1ae@github.com>

On Wed, 25 Feb 2026 12:04:38 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
>> 
>> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
>> 
>> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
>> 
>> Tested on mac, Linux and Windows:
>> - make test TEST="jtreg:test/jdk/java/awt/font"
>> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add defensive check for null ptr

@prsadhuk We have two reviewers on this one now, but let me know if there's anything else that catches your eye. Otherwise I'll probably go ahead and integrate this PR on Monday.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29726#issuecomment-3965701407

From prr at openjdk.org  Thu Feb 26 16:26:14 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 16:26:14 GMT
Subject: Integrated: 8378377: Remove use of AppContext from JEditorPane
In-Reply-To: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
References: <pMixu3jl-7K6EPLc-Nsg3wEeyX0uuvJmmYXD8S-GRY8=.36ef218e-d2c9-4b4f-bfed-139959e8ba82@github.com>
Message-ID: <0OmSkcRPq7dmnSWZnY3wWu-oPB3o-RQ5OJc3RUED6RA=.71936e6c-57f1-457a-9854-86837d8ec43a@github.com>

On Sat, 21 Feb 2026 04:47:28 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from JEditorPane

This pull request has now been integrated.

Changeset: 71a1af7d
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71a1af7d0b4723c8ed740fc40ede75091ecf8c07
Stats:     83 lines in 1 file changed: 11 ins; 60 del; 12 mod

8378377: Remove use of AppContext from JEditorPane

Reviewed-by: serb, dnguyen, psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/29855

From prr at openjdk.org  Thu Feb 26 16:27:36 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 16:27:36 GMT
Subject: Integrated: 8378297: Remove AppContext from several Swing component
 and related classes
In-Reply-To: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
References: <6sOXuHp9kwkDdNlROhdVd2O6EXlivER49-CFxzVoWeM=.2b5e4812-c334-4e34-ab3b-2530faf2259a@github.com>
Message-ID: <9Q82-6URqTsO6OlaJNi8-hJ--cVgjlT5F_3O_i3tIWs=.d44822e6-f573-4e04-a8f3-1e001bb415f4@github.com>

On Thu, 19 Feb 2026 23:20:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext usage from several Swing classes that use it via  Swing utility (still used by other cases so can't remove that yet).
> 
> One ToolTipManager test for the AppContext is removed.

This pull request has now been integrated.

Changeset: fcc2a292
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcc2a2922fe0312758a9eef5f1ea371e5803bc8b
Stats:     215 lines in 8 files changed: 16 ins; 157 del; 42 mod

8378297: Remove AppContext from several Swing component and related classes

Reviewed-by: azvegint, psadhukhan, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/29830

From azvegint at openjdk.org  Thu Feb 26 18:25:54 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 26 Feb 2026 18:25:54 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v3]
In-Reply-To: <niRMjE01Hsxr14g4VpetWho706o1LDXo6ySWRlf_EiE=.a4b1c614-235f-495c-ada2-64635b6ed095@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
 <niRMjE01Hsxr14g4VpetWho706o1LDXo6ySWRlf_EiE=.a4b1c614-235f-495c-ada2-64635b6ed095@github.com>
Message-ID: <NQJccglSDss8vyeP7IW7FLAD7HCccP5mrmrlFhdkD0s=.a608ec56-9152-4b8c-b2f0-d058a2376ead@github.com>

On Tue, 24 Feb 2026 21:00:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from RepaintManager
>> 
>> Please review the CSR too.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378389

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29862#pullrequestreview-3862810057

From prr at openjdk.org  Thu Feb 26 19:12:14 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 19:12:14 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v6]
In-Reply-To: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
Message-ID: <Zlyf3YNG7a347lZzJxgZPg8YknLqCbZ97Rib-8zATn0=.af2d571c-d78d-4885-a62b-7616d1d8f2b6@github.com>

> Some of the medialib native functions implementing Convolve read data from arrays when it is not needed or used instead of reading just what is needed and used.
> This is detected as a read out of bounds. It is limited and hasn't been seen to result in any crashes without ASAN, and the OOB values that are read are never used so there's a very limited problem.
> The changes here make the mlib_ImageConv_*nw.c files match what happens in the mlib_ImageConv_*ext.c files which read just the data they need.
> The changes are fairly mechanical but there could be copy/paste errors for a reviewer to find.
> 
> Not easy to provide a test case, building with --enable-asan is needed and for me it works only on macOS.
> I did that and ran all our existing automated tests on our CI systems.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8373626

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29257/files
  - new: https://git.openjdk.org/jdk/pull/29257/files/a78aeacd..871008c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29257&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29257&range=04-05

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29257/head:pull/29257

PR: https://git.openjdk.org/jdk/pull/29257

From prr at openjdk.org  Thu Feb 26 19:12:17 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 19:12:17 GMT
Subject: RFR: 8373626: [asan] read past end of buffer in
 sun.awt.image.ImagingLib.convolveBI [v5]
In-Reply-To: <dhV42PzNIS_wp25DFQaBUht36K_x1TXo17fQ7Ww3njs=.74c173f4-8a3c-4102-9942-09afa34d37fd@github.com>
References: <V0T68dkjI_WPRKeofWvsMos5To1b5Lzhbhca4rXFuBg=.233a81a1-4208-44cf-83fb-af0f76ec6dfa@github.com>
 <FzXHIQv5RI1OOFOPARquL3HB9-VkWViL-BjmxDS34I4=.42ccc740-efc6-4618-a4a1-512d25532002@github.com>
 <dhV42PzNIS_wp25DFQaBUht36K_x1TXo17fQ7Ww3njs=.74c173f4-8a3c-4102-9942-09afa34d37fd@github.com>
Message-ID: <JMjB8LEcQXO3poiJc3hdNooueaoLXnFxyw-P-RwBO2g=.49dbb7a5-97de-47e9-bb62-0d01ad303cab@github.com>

On Wed, 25 Feb 2026 19:54:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8373626
>
> src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16nw.c line 1093:
> 
>> 1091: 
>> 1092:             k0 = pk[0]; k1 = pk[1]; k2 = pk[2];
>> 1093: 
> 
> `sp += (kw - 1)*chan1` is missing?
> it exists in kw == 6,5,4,2,1 and only missing here for kw == 3

fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29257#discussion_r2860826727

From prr at openjdk.org  Thu Feb 26 20:10:04 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 20:10:04 GMT
Subject: RFR: 8378385: Remove AppContext from AWT Windows implementation
 classes [v2]
In-Reply-To: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
References: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
Message-ID: <6LTjCvVkmLvMsYds6Lha5yn8M4SAGEL-c2cJuj5HF8I=.8e6ea72c-de4a-45fc-9499-d21b833dbc92@github.com>

> Remove most uses of AppContext from Windows AWT classes.
> No existing tests fail with this change.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8378385

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29858/files
  - new: https://git.openjdk.org/jdk/pull/29858/files/00de2084..729886d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29858&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29858&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29858.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29858/head:pull/29858

PR: https://git.openjdk.org/jdk/pull/29858

From prr at openjdk.org  Thu Feb 26 20:10:05 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 20:10:05 GMT
Subject: RFR: 8378385: Remove AppContext from AWT Windows implementation
 classes [v2]
In-Reply-To: <ARb_JmFnzSMjOqrf73tp8zzKDYClqLGIyz4poFQHnlY=.e3c0f71f-0939-4338-92e3-e578db184b30@github.com>
References: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
 <ARb_JmFnzSMjOqrf73tp8zzKDYClqLGIyz4poFQHnlY=.e3c0f71f-0939-4338-92e3-e578db184b30@github.com>
Message-ID: <oKwhhVJqiOWin6hhr_LqmHnmMWl1qZrWEmHqJQmE7V4=.8eb10bf7-7f7c-4488-b6f4-3f3b08d97fa0@github.com>

On Wed, 25 Feb 2026 18:33:28 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378385
>
> src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java line 605:
> 
>> 603:                                                       TextHitInfo.leading(caretPos),
>> 604:                                                       TextHitInfo.leading(visiblePos));
>> 605:         WToolkit.postEvent(WToolkit.targetToAppContext(source), event);
> 
> Does this also need to be updated similarly to WToolkit.postEvent(source, ...)?

Yes, I missed it. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29858#discussion_r2861060332

From dnguyen at openjdk.org  Thu Feb 26 20:24:41 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Feb 2026 20:24:41 GMT
Subject: RFR: 8378385: Remove AppContext from AWT Windows implementation
 classes [v2]
In-Reply-To: <6LTjCvVkmLvMsYds6Lha5yn8M4SAGEL-c2cJuj5HF8I=.8e6ea72c-de4a-45fc-9499-d21b833dbc92@github.com>
References: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
 <6LTjCvVkmLvMsYds6Lha5yn8M4SAGEL-c2cJuj5HF8I=.8e6ea72c-de4a-45fc-9499-d21b833dbc92@github.com>
Message-ID: <meFZnz-Ze_HSL5QXokM2MrjokubzvxEHtEsToxnqf4g=.a161c586-8a06-49ef-8f11-46b61b7899e4@github.com>

On Thu, 26 Feb 2026 20:10:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove most uses of AppContext from Windows AWT classes.
>> No existing tests fail with this change.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378385

Marked as reviewed by dnguyen (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29858#pullrequestreview-3863355242

From prr at openjdk.org  Thu Feb 26 20:33:28 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 20:33:28 GMT
Subject: Integrated: 8378385: Remove AppContext from AWT Windows implementation
 classes
In-Reply-To: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
References: <Q7eESZUTrR1fidq6y1gmjyLvUd-6B3WcpAfMKjwJwFM=.634fce76-8626-4f40-aa4d-0c165acef3a9@github.com>
Message-ID: <8GrqXvH2GjDfQR8QO3AqG1eWFlaGhdrEhqMbxq2yW1Q=.c77d7828-6a28-4d81-95e9-611d3f9e6d0b@github.com>

On Sat, 21 Feb 2026 20:27:45 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove most uses of AppContext from Windows AWT classes.
> No existing tests fail with this change.

This pull request has now been integrated.

Changeset: cd462a88
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd462a88c62fd07fe213f442fc3989c78313a274
Stats:     40 lines in 6 files changed: 0 ins; 26 del; 14 mod

8378385: Remove AppContext from AWT Windows implementation classes

Reviewed-by: dnguyen, serb

-------------

PR: https://git.openjdk.org/jdk/pull/29858

From prr at openjdk.org  Thu Feb 26 20:36:10 2026
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Feb 2026 20:36:10 GMT
Subject: RFR: 8378388: Add missing @Override annotations in
 "javax.print.attribute.standard" package part 1
In-Reply-To: <rBDZ_IPM2ArNr6sJJhRY92miSERYWXo1bGkbXmtlZOA=.99465c01-86b9-49a9-8a57-39a74e4d0fe6@github.com>
References: <rBDZ_IPM2ArNr6sJJhRY92miSERYWXo1bGkbXmtlZOA=.99465c01-86b9-49a9-8a57-39a74e4d0fe6@github.com>
Message-ID: <cVzMam2_1k8l0uB3C3QQ1Fx2AAOjA4w1j4ywaXmwrP8=.362347c4-c1ac-4fb9-951b-aad31aecebfc@github.com>

On Sun, 22 Feb 2026 00:32:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `javax.print.attribute.standard` package that override methods from a superclass or interface.
> 
> Since the package is large the fix has been split, this is the first part.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29861#pullrequestreview-3863402142

From dnguyen at openjdk.org  Thu Feb 26 21:16:24 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Feb 2026 21:16:24 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F [v2]
In-Reply-To: <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
 <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
Message-ID: <CZ0u1l0CTaWlSEZeP1Xc3w85VZuxv1hkCQBhbo-QLEE=.43b88634-027e-4f3f-91bc-ab2931a32e0d@github.com>

On Thu, 26 Feb 2026 02:54:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
>> 
>> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
>> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
>> 
>> Without fix
>> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
>> 
>> With fix
>> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update preferredsize

LGTM. Change makes sense and the area to click to open the menu looks good.

On a side note, does anyone else see an issue where resizing the Metal L&F window from the bottom-right corner gets the cursor stuck to the "resizing" visual state occasionally? It seems to occur randomly (with or without this PR's changes).

-------------

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29808#pullrequestreview-3863454003

From serb at openjdk.org  Fri Feb 27 00:55:18 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Feb 2026 00:55:18 GMT
Subject: Integrated: 8376253: [macOS] FileSystemView may not report system
 icons when -Xcheck:jni is enabled
In-Reply-To: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
References: <5OnjIcAUQIkUXdG8jiNurOqTuwplsKOgQwTHlMlLDYs=.49ea4ae2-2f16-4e69-9abe-8b7e95290ee9@github.com>
Message-ID: <BWNDB2fkBRsWJa3JNDztMJfBW8J9B0OhsGcmhWZetVo=.9954908c-a8e3-4e05-8c34-670ee14c1b33@github.com>

On Wed, 4 Feb 2026 09:05:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> ReleasePrimitiveArrayCritical is called with JNI_ABORT, which discards pixel data when the JVM copies the array. Changed to 0 to always copy back

This pull request has now been integrated.

Changeset: 538bebf7
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/538bebf76e812058145f7a3f5591cbf1c2f756c7
Stats:     95 lines in 2 files changed: 93 ins; 0 del; 2 mod

8376253: [macOS] FileSystemView may not report system icons when -Xcheck:jni is enabled

Reviewed-by: prr, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/29563

From serb at openjdk.org  Fri Feb 27 01:54:57 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Feb 2026 01:54:57 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v3]
In-Reply-To: <niRMjE01Hsxr14g4VpetWho706o1LDXo6ySWRlf_EiE=.a4b1c614-235f-495c-ada2-64635b6ed095@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
 <niRMjE01Hsxr14g4VpetWho706o1LDXo6ySWRlf_EiE=.a4b1c614-235f-495c-ada2-64635b6ed095@github.com>
Message-ID: <KgXAVAGPJMunrSjiEBL-wc-j6lLlNulrzNqLzzQdbN0=.3c8ad605-0baa-49ba-92d5-98b099e8fe4e@github.com>

On Tue, 24 Feb 2026 21:00:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from RepaintManager
>> 
>> Please review the CSR too.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378389

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29862#pullrequestreview-3864437799

From psadhukhan at openjdk.org  Fri Feb 27 03:12:20 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Feb 2026 03:12:20 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
Message-ID: <GY0ZkolYRfdnXeXDXN6chQ1k9mglRqXEoqlqn76rSdQ=.acaad5f8-2402-4965-9953-0d67413a69ad@github.com>

On Thu, 19 Feb 2026 20:04:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
>> 
>> With this PR, I'm contributing the test to OpenJDK.
>> 
>> Without the fix for JDK-8297191, the test fails with the following error messages:
>> 
>> <details>
>> <summary>test log</summary>
>> 
>> 
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
>> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> 	at PageRangesAuto.main(PageRangesAuto.java:146)
>> 
>> </details>
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the first page of the rage in the filename

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29660#pullrequestreview-3864606383

From psadhukhan at openjdk.org  Fri Feb 27 03:12:22 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Feb 2026 03:12:22 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <nmlftW5YCJWWPtWXVSCVreYQOc5OxNgzRJGX30J8jQU=.f8b7445f-65c6-4b63-a520-ce80141e06be@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
 <In5x_9CVTougnOmTMLdIlyZ1wrNeRv2cnxMNIkC9vsM=.fb887deb-bb30-4cee-8a8e-d0d30d1db2a9@github.com>
 <SRJPmuFluC2UBBBfxb7uVeaMiyfSZIA8-WUgc45tJsU=.15aad0d2-8edc-4f7f-a71e-bfb56dd28141@github.com>
 <u4MobpfV7c8Q0kOZLwJFD0HCVQimIqju2TTcbXBNGE8=.f5dcf6de-08b3-4a66-ad30-7b79ab17d1d9@github.com>
 <nmlftW5YCJWWPtWXVSCVreYQOc5OxNgzRJGX30J8jQU=.f8b7445f-65c6-4b63-a520-ce80141e06be@github.com>
Message-ID: <AJb9lOE-m8xaYHQ6JEcxCgi3wlCggIHwW4L10N9iRa4=.6559bdb0-e929-40fa-8e95-0c38d3c5d99f@github.com>

On Thu, 26 Feb 2026 09:24:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I am not sure..It doesn't open for me in my Firefor or Edge too. The filetype being created it seems xpif which is not pdf
>> 
>> %-12345X at PJL JOB
>> @PJL XCPT <?xml version="1.0" encoding="UTF-8"?>
>> @PJL XCPT <!DOCTYPE xpif SYSTEM "xpif-v02082.dtd">
>> @PJL XCPT <xpif version="1.0" cpss-version="2.07" xml:lang="en-US">
>> 
>> Also, other printing tests which uses Destination class like
>> java/awt/print/Dialog/PrintDlgApp.java
>> java/awt/print/PrinterJob/DeviceScale.java
>> java/awt/print/PrinterJob/PrintAfterEndTest.java
>> java/awt/print/PrinterJob/PrintCrashTest.java
>> java/awt/print/PrinterJob/PrintNullString.java
>> java/awt/print/PrinterJob/PrintTextPane.java
>> java/awt/print/PrinterJob/PrintToFileTest.java
>> all uses .prn or .ps so maybe there's a reason to it..
>
> Whatever! I can change the extension, if you insist?it's not the point of the test at all.
> 
> For me, the file inside starts with `%PDF-1.7`.
> 
> How do I open `.prn` file? I remember I renamed `.prn` to `.pdf` quite a few times to view the result, and it always worked for me.

It seems it depends on the printer creating the file and xpif is generated by Xerox printer which is what I am using.

Anyways, I am not insisting on any change...I was just trying to open the file to see if pageranges are printed ok

If the files are not point of the test, then I think it should be generated in special debugging case like what we do for saving image by passing "-save" as argument to test..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2862271324

From rkannathpari at openjdk.org  Fri Feb 27 03:19:39 2026
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 27 Feb 2026 03:19:39 GMT
Subject: Integrated: 8268675: RTE from "Printable.print" propagates through
 "PrinterJob.print"
In-Reply-To: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
References: <nb7uH54r5qXB-1wCcVGUzDZp87TE9bsgdaPPEejE8V4=.94c9e9e6-333b-4b76-99fb-03e97280ee64@github.com>
Message-ID: <u_2S9UboGL42XxOtRJKcIHsUuwc3dF1_VUpfyyiW9ec=.3ba463a1-34eb-4863-8f10-deba1365fd90@github.com>

On Mon, 16 Feb 2026 06:30:34 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Add a parser to convert other exception to "PrinterException" for resolving this issue. Updated existing test for covering 'Windows' and 'Linux' platform.
> 
> Please review and let me know your suggestions.

This pull request has now been integrated.

Changeset: 6daca7ef
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6daca7ef99b5333be9dd074ff848783807080884
Stats:     25 lines in 2 files changed: 6 ins; 8 del; 11 mod

8268675: RTE from "Printable.print" propagates through "PrinterJob.print"

Reviewed-by: psadhukhan, prr

-------------

PR: https://git.openjdk.org/jdk/pull/29733

From tr at openjdk.org  Fri Feb 27 04:59:21 2026
From: tr at openjdk.org (Tejesh R)
Date: Fri, 27 Feb 2026 04:59:21 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F [v2]
In-Reply-To: <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
 <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
Message-ID: <cC91-5iDqHEl00HSXmudwqbe7kxKS3hlenWXYecb_q0=.ca1d5a60-1704-4fbf-81ed-b4dbe6618bd1@github.com>

On Thu, 26 Feb 2026 02:54:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
>> 
>> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
>> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
>> 
>> Without fix
>> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
>> 
>> With fix
>> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update preferredsize

Fix looks good to me. Have you thought about making the test automatic, since it's only for Metal ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/29808#pullrequestreview-3864878219

From psadhukhan at openjdk.org  Fri Feb 27 05:02:17 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Feb 2026 05:02:17 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F [v2]
In-Reply-To: <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
 <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
Message-ID: <Z-mDlTIaY3PsJYdAzdkLo0CrWVDbUouaF-oJqLrb7F8=.a1259652-c41d-4eab-9329-3ad1fd9f184e@github.com>

On Thu, 26 Feb 2026 02:54:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
>> 
>> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
>> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
>> 
>> Without fix
>> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
>> 
>> With fix
>> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update preferredsize

No since the popup menu sanctity with "Restore", "Minimize" etc also can be checked if done manually

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29808#issuecomment-3970795810

From tr at openjdk.org  Fri Feb 27 06:13:32 2026
From: tr at openjdk.org (Tejesh R)
Date: Fri, 27 Feb 2026 06:13:32 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F [v2]
In-Reply-To: <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
 <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
Message-ID: <vJONfN17DVZ8oBC7B3MD9RpyF_JT_vWRgMqlo-kZKUs=.72068967-b441-4153-8903-d9afb3ec6eda@github.com>

On Thu, 26 Feb 2026 02:54:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
>> 
>> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
>> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
>> 
>> Without fix
>> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
>> 
>> With fix
>> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update preferredsize

Marked as reviewed by tr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29808#pullrequestreview-3865088727

From psadhukhan at openjdk.org  Fri Feb 27 06:13:33 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Feb 2026 06:13:33 GMT
Subject: RFR: 8078744: Right half of system menu icon on title bar does not
 activate when clicked in Metal L&F [v2]
In-Reply-To: <CZ0u1l0CTaWlSEZeP1Xc3w85VZuxv1hkCQBhbo-QLEE=.43b88634-027e-4f3f-91bc-ab2931a32e0d@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
 <79GNuayLiDyFxxIcUe-2k3sKDTyYQqdxs_UdnzJ0eLY=.d6c152ca-ff41-45c7-bcf9-0d243959fe2b@github.com>
 <CZ0u1l0CTaWlSEZeP1Xc3w85VZuxv1hkCQBhbo-QLEE=.43b88634-027e-4f3f-91bc-ab2931a32e0d@github.com>
Message-ID: <UvjSdvPEXP22RBGUx0EUXLsflsAm3YB9wf4TRXuH10M=.505b8efa-36c5-4684-8a3e-25445654ffde@github.com>

On Thu, 26 Feb 2026 20:46:01 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> does anyone else see an issue where resizing the Metal L&F window from the bottom-right corner gets the cursor stuck to the "resizing" visual state occasionally? It seems to occur randomly (with or without this PR's changes).

No, I did not see this issue any time in Windows..
but Java look and feel decorations has some unresolved issues, maybe this being one of them..Did you see this if you comment `setDefaultLookAndFeelDecorated(true)`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29808#issuecomment-3970989991

From psadhukhan at openjdk.org  Fri Feb 27 06:13:34 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Feb 2026 06:13:34 GMT
Subject: Integrated: 8078744: Right half of system menu icon on title bar does
 not activate when clicked in Metal L&F
In-Reply-To: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
References: <efc2apDrz-bzeyHZqh91nNzwjhr0cRXrEA6HfFUpfGw=.95cd1b46-e89a-493b-83eb-fc1beb909abd@github.com>
Message-ID: <1_usEeKDe1GO7AH-Rf0I35kLPlz_nvT00qfs39bw5rw=.054ce1d7-d0f2-4146-a4eb-668e1f2e1e87@github.com>

On Thu, 19 Feb 2026 02:52:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If JFrame's window decorations is provided by the Metal LookAndFeel then system menu icon (e.g., which shows Restore, Minimize, Maximize, and Close menu options when clicked) does not activate when clicked on the right edge of the icon
> 
> MetalTitlePane creates a JMenuBar with a system menu icon and a JMenu when clicked on it. This JMenu is created by
> `MetalTitlePane.createMenu`  in the title bar with an empty string and zero-width string doesn't cover the systemmenu icon to activate the menu when clicked on right edge of the icon. Changing the text of the JMenu to a non-zero width character properly sizes the menu button covering and activating the system menu icon even when clicked on right edge i.e anywhere in the icon.
> 
> Without fix
> <img width="246" height="127" alt="image" src="https://github.com/user-attachments/assets/f872bd95-ea15-4245-9c88-f06834804e9b" />
> 
> With fix
> <img width="190" height="134" alt="image" src="https://github.com/user-attachments/assets/f79e8e96-0c71-49e0-9501-5b3a12bbcd83" />

This pull request has now been integrated.

Changeset: 463b9e00
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/463b9e00ce9e348164d8a6eebe27808bb1e93162
Stats:     67 lines in 2 files changed: 66 ins; 0 del; 1 mod

8078744: Right half of system menu icon on title bar does not activate when clicked in Metal L&F

Reviewed-by: tr, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/29808

From tr at openjdk.org  Fri Feb 27 07:08:20 2026
From: tr at openjdk.org (Tejesh R)
Date: Fri, 27 Feb 2026 07:08:20 GMT
Subject: RFR: 8378607: GlyphLayout cache can prevent Fonts from being GC'd
In-Reply-To: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
References: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
Message-ID: <R8IriTP-UcBf9rdA4EzsjxZPq_MUlMaZaZCMRWiXJdI=.1d2e42bb-1702-423e-8a62-74e6e20c3925@github.com>

On Wed, 25 Feb 2026 00:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Update a cache in GlyphLayout.java to use a WeakHashMap
> The maximum cache size is also reduced.
> The intention is to allow Fonts loaded via Font.createFont() to be collected once the application drops references.

LGTM.

-------------

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29904#pullrequestreview-3865336387

From psadhukhan at openjdk.org  Fri Feb 27 07:30:26 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Feb 2026 07:30:26 GMT
Subject: RFR: 8377937: [macos] GlyphMetrics advance does not consider font
 rotation [v2]
In-Reply-To: <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
References: <22MNIwcPhgWFuAV3GkKDqaiqiSESTFMOtPQx7WjavVw=.40872df1-fc4b-42db-babb-fc7f21f7120f@github.com>
 <yTru6Ssh0dKzQYqmlYcvJIeOW0XD4oy8RZJy6tEObUA=.1309f59e-da96-4c48-a391-e915ae0348fc@github.com>
Message-ID: <5m_AWbCKOF_Aeqyiphr2o_nw6RSFuguBI3o6dvFHgrc=.6d925a8d-a354-4985-a621-3f7c039fbd26@github.com>

On Wed, 25 Feb 2026 12:04:38 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> On macOS, `GlyphMetrics` advance provides only the x-component of the advance, not the y-component. This is usually not an issue, since most text does not have any y-component advance. However, if the font is rotated, this does cause problems.
>> 
>> This bug was discovered during fixing of the manual test `java/awt/print/PrinterJob/PrintTextTest.java` (this test is intended to test printing, but this bug was actually causing the `GlyphVector`s on page 8 to be drawn incorrectly on screen, not just on paper).
>> 
>> `FileFontStrike.getGlyphMetrics( )` was helpful as a guide regarding the expected behavior of `CStrike.getGlyphMetrics( )`.
>> 
>> Tested on mac, Linux and Windows:
>> - make test TEST="jtreg:test/jdk/java/awt/font"
>> - make test TEST="jtreg:test/jdk/java/awt/Graphics2D/DrawString"
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add defensive check for null ptr

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29726#pullrequestreview-3865436939

From psadhukhan at openjdk.org  Fri Feb 27 07:45:23 2026
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 27 Feb 2026 07:45:23 GMT
Subject: RFR: 8378389: Remove AppContext from the Swing RepaintManager [v3]
In-Reply-To: <niRMjE01Hsxr14g4VpetWho706o1LDXo6ySWRlf_EiE=.a4b1c614-235f-495c-ada2-64635b6ed095@github.com>
References: <2MkLNUlMiX2p6V7ALIg5nQfw8GURFL0bZsPC2lY9DiI=.7e3eb5af-4f76-41bc-8dc2-922455a7b126@github.com>
 <niRMjE01Hsxr14g4VpetWho706o1LDXo6ySWRlf_EiE=.a4b1c614-235f-495c-ada2-64635b6ed095@github.com>
Message-ID: <n9ht9y7clmWPvvf4xwogB0StEnEaXiEk-c_Roy70gpY=.c183618a-f075-477e-8951-425826f60f00@github.com>

On Tue, 24 Feb 2026 21:00:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove AppContext from RepaintManager
>> 
>> Please review the CSR too.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378389

src/java.desktop/share/classes/sun/awt/SunToolkit.java line 1041:

> 1039:     }
> 1040: 
> 1041:     public static EventQueue getSystemEventQueueImplPP(AppContext appContext) {

Aren't we supposed to remove the AppContext from here too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29862#discussion_r2863000452

From duke at openjdk.org  Fri Feb 27 09:30:25 2026
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 27 Feb 2026 09:30:25 GMT
Subject: RFR: 8372952: Respect landscape orientation user selection on
 macOS and Linux [v2]
In-Reply-To: <sFySy8KQ3Ji023Y1KUDYrOIqLEx1pzqZUM8WY9dtn60=.f1b4360a-a319-4bdd-97e1-2e147168f724@github.com>
References: <lb8GZRWbO4rnHCVFF8MQfgV3DIuOGIt4f49RRyhW8Ng=.7ce8594c-eef8-4a99-ab73-14ebf3130646@github.com>
 <L6epQJ_wv79hftjql8paFgsDF3zRzNRW6dX_f3-O8Aw=.5f6e8760-58b9-4e68-980f-1948f72a8c7a@github.com>
 <1Ry15_1J9BKz3mANlXPpq2pBoLP_a9lPQ9Z9Qbi-2vU=.7eb835fb-b505-4d53-812b-c6b9055a8114@github.com>
 <VfNF0LeoOP7-scBuimTpXdaKWOyGCsyfV0Y_VWKXkEI=.d4dd55fa-8d90-4aab-9dcd-b3d5267244be@github.com>
 <sFySy8KQ3Ji023Y1KUDYrOIqLEx1pzqZUM8WY9dtn60=.f1b4360a-a319-4bdd-97e1-2e147168f724@github.com>
Message-ID: <0ZirABEUEJQ4EQjYZw2mob9WOra19ClbFJumlGKzRx8=.2c587284-9e2c-4bcd-ac77-8236fb6f0bef@github.com>

On Thu, 26 Feb 2026 04:23:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> You mention that the fix is for linux as well but it seems all the files fixed are for macos, except one where IllegalArgumentException is touched. I hope you have not missed adding PSPrinterJob fix to this..

Changes in the CustomMediaSize.java and CustomMediaSizeName.java affect macOS and Linux.
The PSPrinterJob.java does not require changes because the desired orientation of the print-stream pages is specified within the postscript document data and already implemented.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29560#issuecomment-3971787529

From dmarkov at openjdk.org  Fri Feb 27 10:07:35 2026
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Fri, 27 Feb 2026 10:07:35 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
Message-ID: <JHQ_Gyz6girIAvX8d_jWBKuT03HQ70Jbp5tqX-mgRxI=.1fee980d-4063-44de-8089-e1ad3b38c39f@github.com>

On Thu, 19 Feb 2026 20:04:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
>> 
>> With this PR, I'm contributing the test to OpenJDK.
>> 
>> Without the fix for JDK-8297191, the test fails with the following error messages:
>> 
>> <details>
>> <summary>test log</summary>
>> 
>> 
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
>> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> 	at PageRangesAuto.main(PageRangesAuto.java:146)
>> 
>> </details>
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the first page of the rage in the filename

I spent some time testing this on both macOS and Windows. Here are my observations:

- On macOS, the PDF files generated by the test open successfully in Preview as well as in browsers (Firefox/Chrome in my case).
- On Windows, the files generated by the test cannot be opened by browsers (Firefox/Edge) or by Adobe Reader.
- On Windows, the format of the generated output appears to depend on the system?s default printer settings?I observed different output file types after changing the default printer.

Overall, the test looks good to me. However, I agree with Prasanta that we should avoid generating .pdf files when the test passes to prevent confusion when interpreting results on Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29660#issuecomment-3971962375

From jdv at openjdk.org  Fri Feb 27 11:20:16 2026
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 27 Feb 2026 11:20:16 GMT
Subject: RFR: 8373290: Update FreeType to 2.14.1
Message-ID: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>

Update FreeType used for font rendering to latest 2.14.1 version.

Newly added files in upstream without which our build fails, so including them:
src/java.desktop/share/native/libfreetype/src/autofit/afadjust.c
src/java.desktop/share/native/libfreetype/src/autofit/afadjust.h

Below files were present in 2.13.2 upstream but our build worked fine without them. But with FreeType 2.14.1 our build fails without these files, so added them also:
src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.c
src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.h

Below files should have been removed in 2.13.2 update itself as they were removed from upstream. So deleted them now:
src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.c
src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.h

With this FreeType 2.14.1 update we saw [JDK-8378623](https://bugs.openjdk.org/browse/JDK-8378623) test issue which is already resolved.

While CI testing one more test(javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java) failure was observed only on Oracle Linux 10. After FreeType update the ratio of width calculated in this test is "1.3757962" in our Oracle Linux 10 machines and it is rounding off to "1.4" and not the "1.3" value as expected in this test. Taking the average ratio out of both width and height for a larger font will give result in values near to the ideal "1.3" ratio. After making this test more robust it passes on all versions of all platforms in our CI. javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java update is also included in this PR.

After above test updates, overall testing is green with FreeType 2.14.1 update.

-------------

Commit messages:
 - Fix whitespaces
 - Make HtmlFontSizeTest more robust
 - Merge remote-tracking branch 'upstream/master' into freetype
 - Update legal file
 - Merge remote-tracking branch 'upstream/master' into freetype
 - Revert test specific change
 - Use different size so that cached FM is not used
 - Merge remote-tracking branch 'upstream/master' into freetype
 - Remove TTF files
 - Add TTF files
 - ... and 1 more: https://git.openjdk.org/jdk/compare/82ff0255...fb326fa0

Changes: https://git.openjdk.org/jdk/pull/29954/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29954&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373290
  Stats: 10403 lines in 286 files changed: 5453 ins; 3071 del; 1879 mod
  Patch: https://git.openjdk.org/jdk/pull/29954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29954/head:pull/29954

PR: https://git.openjdk.org/jdk/pull/29954

From aivanov at openjdk.org  Fri Feb 27 12:45:21 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Feb 2026 12:45:21 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <AJb9lOE-m8xaYHQ6JEcxCgi3wlCggIHwW4L10N9iRa4=.6559bdb0-e929-40fa-8e95-0c38d3c5d99f@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
 <In5x_9CVTougnOmTMLdIlyZ1wrNeRv2cnxMNIkC9vsM=.fb887deb-bb30-4cee-8a8e-d0d30d1db2a9@github.com>
 <SRJPmuFluC2UBBBfxb7uVeaMiyfSZIA8-WUgc45tJsU=.15aad0d2-8edc-4f7f-a71e-bfb56dd28141@github.com>
 <u4MobpfV7c8Q0kOZLwJFD0HCVQimIqju2TTcbXBNGE8=.f5dcf6de-08b3-4a66-ad30-7b79ab17d1d9@github.com>
 <nmlftW5YCJWWPtWXVSCVreYQOc5OxNgzRJGX30J8jQU=.f8b7445f-65c6-4b63-a520-ce80141e06be@github.com>
 <AJb9lOE-m8xaYHQ6JEcxCgi3wlCggIHwW4L10N9iRa4=.6559bdb0-e929-40fa-8e95-0c38d3c5d99f@github.com>
Message-ID: <UjkAnbPHsPKKXGv8kMfrR5h58s-sLcXW6XuHPrjrHeQ=.cdd4af46-51fb-4fbb-9fee-33eb9a438abc@github.com>

On Fri, 27 Feb 2026 03:09:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Whatever! I can change the extension, if you insist?it's not the point of the test at all.
>> 
>> For me, the file inside starts with `%PDF-1.7`.
>> 
>> How do I open `.prn` file? I remember I renamed `.prn` to `.pdf` quite a few times to view the result, and it always worked for me.
>
> It seems it depends on the printer creating the file and xpif is generated by Xerox printer which is what I am using.
> 
> Anyways, I am not insisting on any change...I was just trying to open the file to see if pageranges are printed ok
> 
> If the files are not point of the test, then I think it should be generated in special debugging case like what we do for saving image by passing "-save" as argument to test..

It is not possible? Printing has to occur, yet there's no need to print pages on a real printer?printing to a file is enough.

The test could remove the produced file, but I see no reason to do so. Firstly, jtreg removes any files from the `scratch` directory; secondly, you can use the files to visually verify the range of printed pages? which could be invaluable if the test fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29660#discussion_r2864165620

From dgredler at openjdk.org  Fri Feb 27 13:14:20 2026
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 27 Feb 2026 13:14:20 GMT
Subject: RFR: 8378607: GlyphLayout cache can prevent Fonts from being GC'd
In-Reply-To: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
References: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
Message-ID: <hARVMzEFaM3-PToVWc4ZUME1qufh0C_EukSe-kk7V2M=.f70961cd-0e6b-4f5b-a39f-7fe0d8f6e221@github.com>

On Wed, 25 Feb 2026 00:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Update a cache in GlyphLayout.java to use a WeakHashMap
> The maximum cache size is also reduced.
> The intention is to allow Fonts loaded via Font.createFont() to be collected once the application drops references.

I'm not sure about the thread safety of `cacheRef`. Is there a reason that it's not declared final and initialized immediately in the declaration? It's inside of `SDCache`, so it wouldn't be initialized unless needed anyway (nested static class lazy init).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29904#issuecomment-3972890895

From aivanov at openjdk.org  Fri Feb 27 14:15:21 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Feb 2026 14:15:21 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <JHQ_Gyz6girIAvX8d_jWBKuT03HQ70Jbp5tqX-mgRxI=.1fee980d-4063-44de-8089-e1ad3b38c39f@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
 <JHQ_Gyz6girIAvX8d_jWBKuT03HQ70Jbp5tqX-mgRxI=.1fee980d-4063-44de-8089-e1ad3b38c39f@github.com>
Message-ID: <vey_jqgyuatsVzvLeCW1kzzBbfiNyRNErh7wh95VNX4=.658961b3-535c-4275-9966-f57f28c2016e@github.com>

On Fri, 27 Feb 2026 10:04:59 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Overall, the test looks good to me. However, I agree with Prasanta that we should avoid generating .pdf files when the test passes to prevent confusion when interpreting results on Windows.

@dmarkov20 What do you suggest then? Change the extension of the files to `.prn`? Anything else?

It's an automated test?if the test passes, its artifacts are removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29660#issuecomment-3973173109

From azvegint at openjdk.org  Fri Feb 27 15:10:07 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 27 Feb 2026 15:10:07 GMT
Subject: RFR: 8378388: Add missing @Override annotations in
 "javax.print.attribute.standard" package part 1
In-Reply-To: <rBDZ_IPM2ArNr6sJJhRY92miSERYWXo1bGkbXmtlZOA=.99465c01-86b9-49a9-8a57-39a74e4d0fe6@github.com>
References: <rBDZ_IPM2ArNr6sJJhRY92miSERYWXo1bGkbXmtlZOA=.99465c01-86b9-49a9-8a57-39a74e4d0fe6@github.com>
Message-ID: <_tLT8mocQcSXl_QYcWeg5RRa1jra4_8I2b7GyId1CgI=.96d3064a-a984-487e-9acd-66c96d2fa700@github.com>

On Sun, 22 Feb 2026 00:32:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `javax.print.attribute.standard` package that override methods from a superclass or interface.
> 
> Since the package is large the fix has been split, this is the first part.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29861#pullrequestreview-3867433346

From azvegint at openjdk.org  Fri Feb 27 15:30:19 2026
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 27 Feb 2026 15:30:19 GMT
Subject: RFR: 8373290: Update FreeType to 2.14.1
In-Reply-To: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
References: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
Message-ID: <Ic9LbWYsz-kvHBAv-TcqJRY03DfUJkMmEUu-Di21C44=.6bb0c521-9d42-4061-b824-fcf7fdbd5f62@github.com>

On Fri, 27 Feb 2026 11:01:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Update FreeType used for font rendering to latest 2.14.1 version.
> 
> Newly added files in upstream without which our build fails, so including them:
> src/java.desktop/share/native/libfreetype/src/autofit/afadjust.c
> src/java.desktop/share/native/libfreetype/src/autofit/afadjust.h
> 
> Below files were present in 2.13.2 upstream but our build worked fine without them. But with FreeType 2.14.1 our build fails without these files, so added them also:
> src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.c
> src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.h
> 
> Below files should have been removed in 2.13.2 update itself as they were removed from upstream. So deleted them now:
> src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.c
> src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.h
> 
> With this FreeType 2.14.1 update we saw [JDK-8378623](https://bugs.openjdk.org/browse/JDK-8378623) test issue which is already resolved.
> 
> While CI testing one more test(javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java) failure was observed only on Oracle Linux 10. After FreeType update the ratio of width calculated in this test is "1.3757962" in our Oracle Linux 10 machines and it is rounding off to "1.4" and not the "1.3" value as expected in this test. Taking the average ratio out of both width and height for a larger font will give result in values near to the ideal "1.3" ratio. After making this test more robust it passes on all versions of all platforms in our CI. javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java update is also included in this PR.
> 
> After above test updates, overall testing is green with FreeType 2.14.1 update.

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29954#pullrequestreview-3867553727

From dmarkov at openjdk.org  Fri Feb 27 16:54:22 2026
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Fri, 27 Feb 2026 16:54:22 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
Message-ID: <93yvzo413coBSszrCPnSAaNa2kBRJlf13ACpqHuVdvQ=.da201cd3-ce51-4710-8b4a-be6637635b38@github.com>

On Thu, 19 Feb 2026 20:04:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As I [mentioned](https://github.com/openjdk/jdk/pull/11266#issuecomment-3577688690) in #11266, I wrote an automatic test `PageRangesAuto.java` that verifies if page range is printed correctly. I used this test to validate the fix for [JDK-8297191](https://bugs.openjdk.org/browse/JDK-8297191) in addition to the existing one, `java/awt/print/PrinterJob/PageRanges.java`.
>> 
>> With this PR, I'm contributing the test to OpenJDK.
>> 
>> Without the fix for JDK-8297191, the test fails with the following error messages:
>> 
>> <details>
>> <summary>test log</summary>
>> 
>> 
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [10, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [2, 3]: {2}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [3, 6]: {4, 5}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [4, 7]: {6}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [7, 7]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [9, 10]: {}
>> java.lang.Error: Not all pages printed in PAGEABLE within the range [10, 10]: {}
>> Exception in thread "main" java.lang.RuntimeException: Errors detected: 12. -
>> java.lang.Error: Not all pages printed in PRINTABLE within the range [2, 3]: {2}
>> 	at PageRangesAuto.main(PageRangesAuto.java:146)
>> 
>> </details>
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the first page of the rage in the filename

Marked as reviewed by dmarkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29660#pullrequestreview-3867982196

From dmarkov at openjdk.org  Fri Feb 27 16:54:24 2026
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Fri, 27 Feb 2026 16:54:24 GMT
Subject: RFR: 8377602: Create automated test for PageRange [v2]
In-Reply-To: <vey_jqgyuatsVzvLeCW1kzzBbfiNyRNErh7wh95VNX4=.658961b3-535c-4275-9966-f57f28c2016e@github.com>
References: <lKpBQQyHlYB6E813AAa_x40AbwOBru7_LhqbLZSpDps=.072396bf-78c9-44f5-bf0d-dd1365d5f4ae@github.com>
 <0GB7cftp_FogRTDmKxt4yJSof-z1QCcOI9hTCA-fbaQ=.1e8d79bf-de19-4140-8111-a2e8b00816af@github.com>
 <JHQ_Gyz6girIAvX8d_jWBKuT03HQ70Jbp5tqX-mgRxI=.1fee980d-4063-44de-8089-e1ad3b38c39f@github.com>
 <vey_jqgyuatsVzvLeCW1kzzBbfiNyRNErh7wh95VNX4=.658961b3-535c-4275-9966-f57f28c2016e@github.com>
Message-ID: <W2sdrMgkpKJ-EIMJK1dRhVJ6zIewtI7fDO1rvtNIlk0=.07bb7894-5244-4f3b-9460-8f7a1c7170aa@github.com>

On Fri, 27 Feb 2026 14:13:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Overall, the test looks good to me. However, I agree with Prasanta that we should avoid generating .pdf files when the test passes to prevent confusion when interpreting results on Windows.
> 
> @dmarkov20 What do you suggest then? Change the extension of the files to `.prn`? Anything else?
> 
> It's an automated test?if the test passes, its artifacts are removed.

In that case, it's fine to leave it as it is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29660#issuecomment-3973979593

From dnguyen at openjdk.org  Fri Feb 27 17:51:23 2026
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Feb 2026 17:51:23 GMT
Subject: RFR: 8378386: Remove AppContext from AWT ModalEventFilter.java
In-Reply-To: <fObg-UJKZJhnWUFIO6dQ-6flRUSWSy_A_dUSN7fIC_I=.b66ec145-014e-4079-ac4e-1d97f5b04938@github.com>
References: <fObg-UJKZJhnWUFIO6dQ-6flRUSWSy_A_dUSN7fIC_I=.b66ec145-014e-4079-ac4e-1d97f5b04938@github.com>
Message-ID: <angtXe-Gq75pFQ4vJQSWKt8QaB3O5ExEKCg7vmTIasE=.55a4fcf8-35fa-42c0-99f3-d631fe7f8544@github.com>

On Sat, 21 Feb 2026 20:32:00 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove AppContext from java/awt/ModalEventFilter.java

Built and tested. LGTM.

-------------

Marked as reviewed by dnguyen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29859#pullrequestreview-3868241382

From serb at openjdk.org  Fri Feb 27 19:55:29 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Feb 2026 19:55:29 GMT
Subject: Integrated: 8378388: Add missing @Override annotations in
 "javax.print.attribute.standard" package part 1
In-Reply-To: <rBDZ_IPM2ArNr6sJJhRY92miSERYWXo1bGkbXmtlZOA=.99465c01-86b9-49a9-8a57-39a74e4d0fe6@github.com>
References: <rBDZ_IPM2ArNr6sJJhRY92miSERYWXo1bGkbXmtlZOA=.99465c01-86b9-49a9-8a57-39a74e4d0fe6@github.com>
Message-ID: <7fX7fSqEDc1X_7SIz5YJIChhlbKmb6YgAF52AC-yjqw=.322b0df6-c1d4-43d1-ba35-5a79f8633fa5@github.com>

On Sun, 22 Feb 2026 00:32:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `javax.print.attribute.standard` package that override methods from a superclass or interface.
> 
> Since the package is large the fix has been split, this is the first part.
> Only source annotations are added; there are no behavioral changes.
> 
> The previous patch for `com.sun.beans` can be found here: https://github.com/openjdk/jdk/pull/27887.

This pull request has now been integrated.

Changeset: 3144b572
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3144b572d33713cd3311352f0bbaac8b69408fe4
Stats:     142 lines in 33 files changed: 109 ins; 0 del; 33 mod

8378388: Add missing @Override annotations in "javax.print.attribute.standard" package part 1

Reviewed-by: prr, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/29861

From serb at openjdk.org  Fri Feb 27 21:08:34 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Feb 2026 21:08:34 GMT
Subject: RFR: 8378057: CAccessibility roleKey and
 AWTAccessor.AccessibleBundleAccessor are Redundant [v2]
In-Reply-To: <cbyJybgFYp5T2v4-_tXBzRjVeaHIM8XGkRG_HC0KDaw=.bba881a8-5dcd-448c-aeef-b8b29fb0ed70@github.com>
References: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
 <cbyJybgFYp5T2v4-_tXBzRjVeaHIM8XGkRG_HC0KDaw=.bba881a8-5dcd-448c-aeef-b8b29fb0ed70@github.com>
Message-ID: <vbKHVbHFDf-X77BlJOTZUBgAQB9nwUpr4Xx_9kwEk8g=.15978d72-7aef-4fdc-99e3-38adb52dd4bc@github.com>

On Tue, 24 Feb 2026 06:44:20 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> This PR proposes replacing the native `roleKey` method with the `AWTAccessor.AccessibleBundleAccessor`. They appear to do the same thing.
>> 
>> I ran all the existing jtreg tests in the javax/accessibility folder and observed no new regressions (tested on Mac).
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8378057: changing null check
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/29868#discussion_r2844805891

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 121:

> 119:             String roleStr = AWTAccessor.getAccessibleBundleAccessor().
> 120:                     getKey(nvRole);
> 121:             if (!ignoredRoles.contains(roleStr)) {

The change looks fine, but I?m wondering if we need the same null check here as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29868#discussion_r2866206079

From aivanov at openjdk.org  Fri Feb 27 21:10:04 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Feb 2026 21:10:04 GMT
Subject: RFR: 8378870: Remove sun.awt.AWTAccessor from imports in ImageIcon
Message-ID: <t8FUnfJL910OJOKrTPEg-nuBuNnva6LuUZ9AsxoSsPw=.5615fbd0-bab8-4132-aa85-417785689f04@github.com>

A trivial change that removes `sun.awt.AWTAccessor` from imports in `ImageIcon`. This import is a left-over after `AppContext` was removed in https://github.com/openjdk/jdk/pull/29433 for [JDK-8376420](https://bugs.openjdk.org/browse/JDK-8376420).

-------------

Commit messages:
 - 8378870: Remove sun.awt.AWTAccessor from imports in ImageIcon

Changes: https://git.openjdk.org/jdk/pull/29965/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29965&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378870
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29965/head:pull/29965

PR: https://git.openjdk.org/jdk/pull/29965

From serb at openjdk.org  Fri Feb 27 21:10:04 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Feb 2026 21:10:04 GMT
Subject: RFR: 8378870: Remove sun.awt.AWTAccessor from imports in ImageIcon
In-Reply-To: <t8FUnfJL910OJOKrTPEg-nuBuNnva6LuUZ9AsxoSsPw=.5615fbd0-bab8-4132-aa85-417785689f04@github.com>
References: <t8FUnfJL910OJOKrTPEg-nuBuNnva6LuUZ9AsxoSsPw=.5615fbd0-bab8-4132-aa85-417785689f04@github.com>
Message-ID: <wqE_BcYUExkGQMqmVF6E6f1Jprk8HMoDFYfV1tRnU1U=.269bad24-5bca-4179-af07-64093984b50c@github.com>

On Fri, 27 Feb 2026 21:02:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> A trivial change that removes `sun.awt.AWTAccessor` from imports in `ImageIcon`. This import is a left-over after `AppContext` was removed in https://github.com/openjdk/jdk/pull/29433 for [JDK-8376420](https://bugs.openjdk.org/browse/JDK-8376420).

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29965#pullrequestreview-3869085896

From aivanov at openjdk.org  Fri Feb 27 21:14:57 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Feb 2026 21:14:57 GMT
Subject: RFR: 8378872: Mark waitList in FetcherInfo final
Message-ID: <-jZFxMbqwPU5qz8U6WG-AkBfb71yCx18CiFWVt3luok=.209ad185-863b-45bd-9c82-7dd830883607@github.com>

The `FetcherInfo` class stores information for the `ImageFetcher` class. The `waitList` field of `FetcherInfo` is used in synchronised blocks, but it's not marked as `final`.

If the reference in `waitList` changes, it could break the synchronisation.

To avoid uncertainties, mark the `waitList` field final.

Additionally, the `fetchers` array should also be `final`, the reference is never changed.

-------------

Commit messages:
 - 8378872: Mark waitList in FetcherInfo final

Changes: https://git.openjdk.org/jdk/pull/29966/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29966&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378872
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29966.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29966/head:pull/29966

PR: https://git.openjdk.org/jdk/pull/29966

From aivanov at openjdk.org  Fri Feb 27 21:39:39 2026
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Feb 2026 21:39:39 GMT
Subject: RFR: 8374304: MultiResolutionSplashTest.java fails in CI:
 "Image with wrong resolution is used for splash screen!"
Message-ID: <7EaKOYpUyZ2G1mXLEwdGGPsGuKflJlaS8Gn4JZN50-4=.ab6fbc11-89d0-4f95-9ca0-a22cab67e912@github.com>

I added capturing a screenshot of the splash screen into the test, and I found that the splash screen is already closed when the screenshot is taken. I realised that I had changed the behaviour of the test with my screenshot code. The original test gets the color of the pixel on the screen before it calls `getScaleFactor` that displays a dialog, which results closing the splash screen.

https://github.com/openjdk/jdk/blob/e0b040a6c6713827033e9ba51c9ded920dd0203b/test/jdk/java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java#L110-L111

I analysed the code of the splash screen, and it never opens the images with decorations for 100% scale: `splash1 at 1x.png` or `splash1 at 100pct.png`.

To avoid any confusion, I modified the test code to ensure it never creates decorated files for 100%. If the scale factor of the main screen is 1.00, the second image remains with the default `@2x` decoration.

I also simplified the test. Now, `getScaleFactor` doesn't display a dialog, but reads the scale from `GraphicsEnvironment`. It did so anyway because the `Graphics` object passed to `paint` is an instance of `SunGraphics2D` in nearly all the cases.

The test always creates a screenshot of the splash screen and reads the color from the screenshot to determine whether the test fails or not.

The updated test is stable on all the platforms, I ran it many times, and the test never failed.

If the test ever fails again, we'll have the screenshot to analyse why.

-------------

Commit messages:
 - Revert to always saving screenshot of splash screen
 - Merge master
 - Use screen capture to get color from splash screen
 - Remove @modules java.desktop/sun.java2d and align colors
 - 8374304: MultiResolutionSplashTest.java fails in CI: "Image with wrong resolution is used for splash screen!"

Changes: https://git.openjdk.org/jdk/pull/29851/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29851&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374304
  Stats: 143 lines in 1 file changed: 47 ins; 60 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/29851.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29851/head:pull/29851

PR: https://git.openjdk.org/jdk/pull/29851

From prr at openjdk.org  Fri Feb 27 21:44:11 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 27 Feb 2026 21:44:11 GMT
Subject: RFR: 8378865: After fix for JDK-8378385 two tests are failing on
 windows
Message-ID: <lvO05FX7IK5GcwamPibUY_J17MNKK-gPvdvoDfwTppA=.7e233cb7-e82a-42e7-9caf-7300d5d7b885@github.com>

These 2 AppContext tests need to be removed.
They fail on Windows now AppContext support has been removed from some classes there.

-------------

Commit messages:
 - 8378865

Changes: https://git.openjdk.org/jdk/pull/29969/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29969&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8378865
  Stats: 252 lines in 2 files changed: 0 ins; 252 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29969/head:pull/29969

PR: https://git.openjdk.org/jdk/pull/29969

From jwood at openjdk.org  Fri Feb 27 21:50:27 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 27 Feb 2026 21:50:27 GMT
Subject: RFR: 8378057: CAccessibility roleKey and
 AWTAccessor.AccessibleBundleAccessor are Redundant [v3]
In-Reply-To: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
References: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
Message-ID: <G2U0_decYQMDIIPmhOMV8HsPBtTZ7akLxAR70m9fleE=.7824b8bf-0d6b-43fc-a22c-d2757f5196f2@github.com>

> This PR proposes replacing the native `roleKey` method with the `AWTAccessor.AccessibleBundleAccessor`. They appear to do the same thing.
> 
> I ran all the existing jtreg tests in the javax/accessibility folder and observed no new regressions (tested on Mac).

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8378057: changing null check
  
  This is in response to:
  https://github.com/openjdk/jdk/pull/29868/changes#r2866206079

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29868/files
  - new: https://git.openjdk.org/jdk/pull/29868/files/0f01ea62..f79ee5fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29868&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29868&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29868/head:pull/29868

PR: https://git.openjdk.org/jdk/pull/29868

From jwood at openjdk.org  Fri Feb 27 21:53:24 2026
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 27 Feb 2026 21:53:24 GMT
Subject: RFR: 8378057: CAccessibility roleKey and
 AWTAccessor.AccessibleBundleAccessor are Redundant [v2]
In-Reply-To: <vbKHVbHFDf-X77BlJOTZUBgAQB9nwUpr4Xx_9kwEk8g=.15978d72-7aef-4fdc-99e3-38adb52dd4bc@github.com>
References: <UpCvIQTI_2yGg4Wb0BxK6RlDv4qU-y5A_EfzHliQgy0=.8b4b30e8-6945-4efc-a6be-83c629de8603@github.com>
 <cbyJybgFYp5T2v4-_tXBzRjVeaHIM8XGkRG_HC0KDaw=.bba881a8-5dcd-448c-aeef-b8b29fb0ed70@github.com>
 <vbKHVbHFDf-X77BlJOTZUBgAQB9nwUpr4Xx_9kwEk8g=.15978d72-7aef-4fdc-99e3-38adb52dd4bc@github.com>
Message-ID: <_uryDkkKsvIk6j-NOfZAPVXXmPNti8yw20IbYgNgogk=.49381848-4d07-4543-8572-e7fb192734b1@github.com>

On Fri, 27 Feb 2026 21:05:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8378057: changing null check
>>   
>>   This is in response to:
>>   https://github.com/openjdk/jdk/pull/29868#discussion_r2844805891
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 121:
> 
>> 119:             String roleStr = AWTAccessor.getAccessibleBundleAccessor().
>> 120:                     getKey(nvRole);
>> 121:             if (!ignoredRoles.contains(roleStr)) {
> 
> The change looks fine, but I?m wondering if we need the same null check here as well.

I don't think we *need* it, but I added one just now since you asked about it.

Previously this invocation (at line 119) did not include a null check, and the other invocation (at line 1037) did.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29868#discussion_r2866345705

From kizune at openjdk.org  Fri Feb 27 22:12:24 2026
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 27 Feb 2026 22:12:24 GMT
Subject: RFR: 8378865: After fix for JDK-8378385 two tests are failing on
 windows
In-Reply-To: <lvO05FX7IK5GcwamPibUY_J17MNKK-gPvdvoDfwTppA=.7e233cb7-e82a-42e7-9caf-7300d5d7b885@github.com>
References: <lvO05FX7IK5GcwamPibUY_J17MNKK-gPvdvoDfwTppA=.7e233cb7-e82a-42e7-9caf-7300d5d7b885@github.com>
Message-ID: <MAtGWWbX7MJODsWC6M_LOyCsiSQySiU34rSTSY4bwLQ=.a09e1edd-2fbf-40d5-87aa-e946f9a04645@github.com>

On Fri, 27 Feb 2026 21:35:44 GMT, Phil Race <prr at openjdk.org> wrote:

> These 2 AppContext tests need to be removed.
> They fail on Windows now AppContext support has been removed from some classes there.

LGTM

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29969#pullrequestreview-3869324435

From prr at openjdk.org  Fri Feb 27 22:27:31 2026
From: prr at openjdk.org (Phil Race)
Date: Fri, 27 Feb 2026 22:27:31 GMT
Subject: Integrated: 8378865: After fix for JDK-8378385 two tests are failing
 on windows
In-Reply-To: <lvO05FX7IK5GcwamPibUY_J17MNKK-gPvdvoDfwTppA=.7e233cb7-e82a-42e7-9caf-7300d5d7b885@github.com>
References: <lvO05FX7IK5GcwamPibUY_J17MNKK-gPvdvoDfwTppA=.7e233cb7-e82a-42e7-9caf-7300d5d7b885@github.com>
Message-ID: <lDIR2JTTgkDpCe3BkraJxdOw5Mu4lgzCwrfLjUlMg68=.e27619a3-ff39-4325-83dd-973fa722b4b4@github.com>

On Fri, 27 Feb 2026 21:35:44 GMT, Phil Race <prr at openjdk.org> wrote:

> These 2 AppContext tests need to be removed.
> They fail on Windows now AppContext support has been removed from some classes there.

This pull request has now been integrated.

Changeset: b0318fee
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0318fee71926b424e770ff1c85add0d96cc85c0
Stats:     252 lines in 2 files changed: 0 ins; 252 del; 0 mod

8378865: After fix for JDK-8378385 two tests are failing on windows

Reviewed-by: kizune

-------------

PR: https://git.openjdk.org/jdk/pull/29969

From serb at openjdk.org  Sat Feb 28 21:16:18 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 28 Feb 2026 21:16:18 GMT
Subject: RFR: 8373290: Update FreeType to 2.14.1
In-Reply-To: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
References: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
Message-ID: <pYqhjv8qcV0PYpXxKBDKvQCBVaOy1_pqzTplEVrLxb4=.d7ed1411-8c71-40c6-aa83-5d3f13b1da73@github.com>

On Fri, 27 Feb 2026 11:01:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Update FreeType used for font rendering to latest 2.14.1 version.
> 
> Newly added files in upstream without which our build fails, so including them:
> src/java.desktop/share/native/libfreetype/src/autofit/afadjust.c
> src/java.desktop/share/native/libfreetype/src/autofit/afadjust.h
> 
> Below files were present in 2.13.2 upstream but our build worked fine without them. But with FreeType 2.14.1 our build fails without these files, so added them also:
> src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.c
> src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.h
> 
> Below files should have been removed in 2.13.2 update itself as they were removed from upstream. So deleted them now:
> src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.c
> src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.h
> 
> With this FreeType 2.14.1 update we saw [JDK-8378623](https://bugs.openjdk.org/browse/JDK-8378623) test issue which is already resolved.
> 
> While CI testing one more test(javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java) failure was observed only on Oracle Linux 10. After FreeType update the ratio of width calculated in this test is "1.3757962" in our Oracle Linux 10 machines and it is rounding off to "1.4" and not the "1.3" value as expected in this test. Taking the average ratio out of both width and height for a larger font will give result in values near to the ideal "1.3" ratio. After making this test more robust it passes on all versions of all platforms in our CI. javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java update is also included in this PR.
> 
> After above test updates, overall testing is green with FreeType 2.14.1 update.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29954#pullrequestreview-3870803842

From prr at openjdk.org  Sat Feb 28 21:43:17 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 28 Feb 2026 21:43:17 GMT
Subject: RFR: 8373290: Update FreeType to 2.14.1
In-Reply-To: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
References: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
Message-ID: <34WNaH8DUL4t1_Y-s8smW3gUKlCqbWch3tAEeBWK6k8=.d217ab7e-66cf-4c12-b0e9-b9632d8af1f0@github.com>

On Fri, 27 Feb 2026 11:01:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>Below files were present in 2.13.2 upstream but our build worked fine without them. But with FreeType 2.14.1 our build >fails without these files, so added them also:
>src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.c
>src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.h

That sounds wrong.
These should only be needed if FT_CONFIG_OPTION_USE_HARFBUZZ is defined.
And it isn't. 
All uses of the code in those files is protected by an ifdef .. unless upstream made a mistake somewhere.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29954#issuecomment-3977969231

From prr at openjdk.org  Sat Feb 28 22:00:20 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 28 Feb 2026 22:00:20 GMT
Subject: RFR: 8373290: Update FreeType to 2.14.1
In-Reply-To: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
References: <Bm52StZ_CwmWIZKQVXKNcZAabmL8O_niEVSWGHiLcLY=.d0642ac0-dafe-4396-b6b2-389da145200f@github.com>
Message-ID: <pWg-zY9qtYvHmQU6_UtyaFiUQF8TyB03iGI5xr2qzZ4=.a740804b-ad60-4b3f-a7bb-cc7b3263e24e@github.com>

On Fri, 27 Feb 2026 11:01:51 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Update FreeType used for font rendering to latest 2.14.1 version.
> 
> Newly added files in upstream without which our build fails, so including them:
> src/java.desktop/share/native/libfreetype/src/autofit/afadjust.c
> src/java.desktop/share/native/libfreetype/src/autofit/afadjust.h
> 
> Below files were present in 2.13.2 upstream but our build worked fine without them. But with FreeType 2.14.1 our build fails without these files, so added them also:
> src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.c
> src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.h
> 
> Below files should have been removed in 2.13.2 update itself as they were removed from upstream. So deleted them now:
> src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.c
> src/java.desktop/share/native/libfreetype/src/truetype/ttsubpix.h
> 
> With this FreeType 2.14.1 update we saw [JDK-8378623](https://bugs.openjdk.org/browse/JDK-8378623) test issue which is already resolved.
> 
> While CI testing one more test(javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java) failure was observed only on Oracle Linux 10. After FreeType update the ratio of width calculated in this test is "1.3757962" in our Oracle Linux 10 machines and it is rounding off to "1.4" and not the "1.3" value as expected in this test. Taking the average ratio out of both width and height for a larger font will give result in values near to the ideal "1.3" ratio. After making this test more robust it passes on all versions of all platforms in our CI. javax/swing/text/html/CSS/8231286/HtmlFontSizeTest.java update is also included in this PR.
> 
> After above test updates, overall testing is green with FreeType 2.14.1 update.

src/java.desktop/share/native/libfreetype/include/freetype/config/ftoption.h line 293:

> 291:    *   here with the configured one.
> 292:    */
> 293: /* #define FT_CONFIG_OPTION_USE_HARFBUZZ */

You have the define of FT_CONFIG_OPTION_USE_HARFBUZZ  still commented out (correct)

src/java.desktop/share/native/libfreetype/src/autofit/ft-hb.h line 28:

> 26: FT_BEGIN_HEADER
> 27: 
> 28: #ifdef FT_CONFIG_OPTION_USE_HARFBUZZ

And this file is only included if it is defined ... so you aren't using it. So this does not add up

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29954#discussion_r2867938847
PR Review Comment: https://git.openjdk.org/jdk/pull/29954#discussion_r2867940851

From prr at openjdk.org  Sat Feb 28 23:01:29 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 28 Feb 2026 23:01:29 GMT
Subject: RFR: 8378607: GlyphLayout cache can prevent Fonts from being GC'd
In-Reply-To: <hARVMzEFaM3-PToVWc4ZUME1qufh0C_EukSe-kk7V2M=.f70961cd-0e6b-4f5b-a39f-7fe0d8f6e221@github.com>
References: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
 <hARVMzEFaM3-PToVWc4ZUME1qufh0C_EukSe-kk7V2M=.f70961cd-0e6b-4f5b-a39f-7fe0d8f6e221@github.com>
Message-ID: <0jPBUkSSELqUDQhWCHlmCxhLPi0GLIW_x_UkmWXaAqY=.bf5c6794-ce39-44e5-954d-d266c05b7d0d@github.com>

On Fri, 27 Feb 2026 13:11:10 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> I'm not sure about the thread safety of `cacheRef`. Is there a reason that it's not declared final and initialized immediately in the declaration? It's inside of `SDCache`, so it wouldn't be initialized unless needed anyway (nested static class lazy init).

It can't be final. Because if it is cleared it will need to be re-created.
If 2 threads happen to create the CacheRef and one is dropped it should not matter.
My understanding is that reference assignments are atomic so that should be OK too.
All pre-existing anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29904#issuecomment-3978352359

From prr at openjdk.org  Sat Feb 28 23:01:31 2026
From: prr at openjdk.org (Phil Race)
Date: Sat, 28 Feb 2026 23:01:31 GMT
Subject: Integrated: 8378607: GlyphLayout cache can prevent Fonts from being
 GC'd
In-Reply-To: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
References: <D18u2V11U5aHrst57Cc1HFRhaYHL2wp3uhji1Au_wKw=.2640a788-21ca-4396-aa6f-cf8b74ca2d95@github.com>
Message-ID: <UOM6SK14a-0_z2bxsHwFzmHszFvSwNqSd4S1fUKuSsc=.16248982-4ad7-4a5d-8aba-cc123397767f@github.com>

On Wed, 25 Feb 2026 00:52:24 GMT, Phil Race <prr at openjdk.org> wrote:

> Update a cache in GlyphLayout.java to use a WeakHashMap
> The maximum cache size is also reduced.
> The intention is to allow Fonts loaded via Font.createFont() to be collected once the application drops references.

This pull request has now been integrated.

Changeset: f3d7ca33
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3d7ca33d797c3475a4c31d612e7ed8f71d1f5b0
Stats:     19 lines in 1 file changed: 5 ins; 7 del; 7 mod

8378607: GlyphLayout cache can prevent Fonts from being GC'd

Reviewed-by: jdv, tr

-------------

PR: https://git.openjdk.org/jdk/pull/29904