From duke at openjdk.org  Mon Dec  1 04:32:50 2025
From: duke at openjdk.org (duke)
Date: Mon, 1 Dec 2025 04:32:50 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v9]
In-Reply-To: <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
Message-ID: <DwsVSMms1g4RmUqd1x_ysCpevjI7f1-QF_y18VUodg4=.a8abc7fa-8548-4aaa-8604-00380b60b615@github.com>

On Wed, 26 Nov 2025 10:11:43 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
>> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt.
>
> Srinivas Mandalika has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Trigger the bot.
>  - Merge branch '8068378' of github.com:srmandal/jdk into 8068378
>  - Merge branch 'master' of github.com:openjdk/jdk into 8068378
>  - Added line after subsection name
>  - Merge master
>  - Fixed Typos
>  - Fixed whitepsace error.
>  - 8068378: Review feedback for instructions, missing break in switch case in Test.java
>  - Removed Merge Conflict from PL file.
>  - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update

@srmandal 
Your change (at version 2cdf3000092a22c22151650ea85bdae4bfb0d7a4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3594485249

From jdv at openjdk.org  Mon Dec  1 05:43:58 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 1 Dec 2025 05:43:58 GMT
Subject: Integrated: 8372534: Update Libpng to 1.6.51
In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
Message-ID: <-oMBQGb7A6HK_23xlpq31JXIlBhj1JljQ0RQxMrW9zE=.d03849f6-0b64-463c-9c1a-f49e37bcaab9@github.com>

On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version.

This pull request has now been integrated.

Changeset: c7a489db
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7a489db9e4a7d696623fc2155a5504d9d2adb0d
Stats:     638 lines in 21 files changed: 297 ins; 207 del; 134 mod

8372534: Update Libpng to 1.6.51

Reviewed-by: serb, azvegint, prr

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

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

From psadhukhan at openjdk.org  Mon Dec  1 06:49:27 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Dec 2025 06:49:27 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v2]
In-Reply-To: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
Message-ID: <6BPLOBxDfzOTcBjQXw4EtwT_e_w1WW5u8LDNEhea6do=.730efb55-3fb9-42a3-befb-2f9e1df4e043@github.com>

> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
> defined in the JTable (typically black on white) to be ignored.
> 
> The problem seems to stem from a call to
> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
> 
> CI run is ok..

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

  Automate test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28549/files
  - new: https://git.openjdk.org/jdk/pull/28549/files/8bbe478b..42004d7f

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

  Stats: 96 lines in 1 file changed: 53 ins; 5 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/28549.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28549/head:pull/28549

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

From psadhukhan at openjdk.org  Mon Dec  1 06:49:28 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Dec 2025 06:49:28 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v2]
In-Reply-To: <YuGmd-zOKZu7N0Cywk9fFsnALYq7Qv4TA28RKlxlcdQ=.750144e9-1374-42ae-a054-afaf7e7a7365@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <YuGmd-zOKZu7N0Cywk9fFsnALYq7Qv4TA28RKlxlcdQ=.750144e9-1374-42ae-a054-afaf7e7a7365@github.com>
Message-ID: <JwiRpDIg1KT0fcOfNvABRue-ZDXkFS2jUybrIwnPsZw=.34476ae0-1560-4aca-b18f-9f5387885e38@github.com>

On Fri, 28 Nov 2025 07:26:28 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Automate test
>
> test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java line 62:
> 
>> 60:     static JFrame createTestUI() {
>> 61:       String[][] rowData = { {"1-1","1-2","1-3"},
>> 62:                              {"2-1","2-2","2-3"},
> 
> I guess the test could be automated.
> 
> e.g. if we leave the central cell blank:
> 
> Suggestion:
> 
>                              {"2-1","","2-3"},
> 
> We can safely retrieve the pixel color from the center of the cell and check it against the white color
> 
> 
> Rectangle tableRect = table.getCellRect(1, 1, true);
> Point tableOnScreen = table.getLocationOnScreen();
> 
> Point p = new Point(
>         tableOnScreen.x + tableRect.x + tableRect.width / 2,
>         tableOnScreen.y + tableRect.y + tableRect.height / 2
> );
> 
> Color pixelColor = robot.getPixelColor(p.x, p.y);
> // ... color check

Thanks for the suggestion.
Test automated and color check before/after serialization/desrialization added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2575810667

From azvegint at openjdk.org  Mon Dec  1 07:26:50 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 1 Dec 2025 07:26:50 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v2]
In-Reply-To: <6BPLOBxDfzOTcBjQXw4EtwT_e_w1WW5u8LDNEhea6do=.730efb55-3fb9-42a3-befb-2f9e1df4e043@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <6BPLOBxDfzOTcBjQXw4EtwT_e_w1WW5u8LDNEhea6do=.730efb55-3fb9-42a3-befb-2f9e1df4e043@github.com>
Message-ID: <LSsastDicyIS3VMfFQH-e3baPVU8U9Qv1FqN_30_4ZM=.9feb1ce9-7da6-4a4f-9e3e-424c0b6cbda3@github.com>

On Mon, 1 Dec 2025 06:49:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
>> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
>> defined in the JTable (typically black on white) to be ignored.
>> 
>> The problem seems to stem from a call to
>> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
>> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
>> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
>> 
>> CI run is ok..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Automate test

test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java line 72:

> 70:                 table.setDefaultRenderer(table.getColumnClass(1), tcr);
> 71: 
> 72:                 // If this try block is removed, table text remains black on white.

This comment is too far away from the try-catch block after the test update.

test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java line 101:

> 99:                     System.out.println("deserialized renderer fg " + fg + " bg " + bg);
> 100:                     if (!(fg == destcr.getForeground()) || !(bg == destcr.getBackground())) {
> 101:                         throw new RuntimeException("Desrialized foreground and background color not same");

Suggestion:

                        throw new RuntimeException("Deserialized foreground and background color not same");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2575913375
PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2575910014

From psadhukhan at openjdk.org  Mon Dec  1 07:31:49 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Dec 2025 07:31:49 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v3]
In-Reply-To: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
Message-ID: <auUFh3fJO9tSkraoeKAoGwLP8Y3_N8mtjaggsadJKK8=.a04322c8-1768-4ca5-9aa1-ad0268998cb1@github.com>

> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
> defined in the JTable (typically black on white) to be ignored.
> 
> The problem seems to stem from a call to
> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
> 
> CI run is ok..

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

  test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28549/files
  - new: https://git.openjdk.org/jdk/pull/28549/files/42004d7f..b0f6314a

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

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

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

From azvegint at openjdk.org  Mon Dec  1 07:31:52 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 1 Dec 2025 07:31:52 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v2]
In-Reply-To: <6BPLOBxDfzOTcBjQXw4EtwT_e_w1WW5u8LDNEhea6do=.730efb55-3fb9-42a3-befb-2f9e1df4e043@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <6BPLOBxDfzOTcBjQXw4EtwT_e_w1WW5u8LDNEhea6do=.730efb55-3fb9-42a3-befb-2f9e1df4e043@github.com>
Message-ID: <vi01yXHc8fyznZAU1fJIjVkz_ZZgVXPDKGf014RPAeg=.b28e9f29-80b6-4e22-b32b-3ea12737cf68@github.com>

On Mon, 1 Dec 2025 06:49:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
>> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
>> defined in the JTable (typically black on white) to be ignored.
>> 
>> The problem seems to stem from a call to
>> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
>> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
>> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
>> 
>> CI run is ok..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Automate test

test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java line 103:

> 101:                         throw new RuntimeException("Desrialized foreground and background color not same");
> 102:                     }
> 103:                 } catch (IOException | ClassNotFoundException e) {}

Shouldn't we re throw those exceptions? (considering them as a failure)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2575926223

From psadhukhan at openjdk.org  Mon Dec  1 07:41:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Dec 2025 07:41:10 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
Message-ID: <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>

> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
> defined in the JTable (typically black on white) to be ignored.
> 
> The problem seems to stem from a call to
> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
> 
> CI run is ok..

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

  Rethrow Exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28549/files
  - new: https://git.openjdk.org/jdk/pull/28549/files/b0f6314a..f4766c74

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

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

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

From azvegint at openjdk.org  Mon Dec  1 07:41:10 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 1 Dec 2025 07:41:10 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
Message-ID: <I4D3T9uJ1lV20MPgDllmFb_NuTt9dRmnIUbFZf_CNXw=.fd4aca57-25ec-4fa0-a527-ba9b12802b1f@github.com>

On Mon, 1 Dec 2025 07:38:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
>> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
>> defined in the JTable (typically black on white) to be ignored.
>> 
>> The problem seems to stem from a call to
>> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
>> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
>> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
>> 
>> CI run is ok..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rethrow Exception

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28549#pullrequestreview-3523561172

From psadhukhan at openjdk.org  Mon Dec  1 07:41:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Dec 2025 07:41:12 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v2]
In-Reply-To: <vi01yXHc8fyznZAU1fJIjVkz_ZZgVXPDKGf014RPAeg=.b28e9f29-80b6-4e22-b32b-3ea12737cf68@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <6BPLOBxDfzOTcBjQXw4EtwT_e_w1WW5u8LDNEhea6do=.730efb55-3fb9-42a3-befb-2f9e1df4e043@github.com>
 <vi01yXHc8fyznZAU1fJIjVkz_ZZgVXPDKGf014RPAeg=.b28e9f29-80b6-4e22-b32b-3ea12737cf68@github.com>
Message-ID: <OOIEbCvFnIhMGSHdLDQAwAuCBvxq4ivJgOT1WF-U5H4=.32bb0205-b49d-4169-864e-8bd146264940@github.com>

On Mon, 1 Dec 2025 07:27:38 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Automate test
>
> test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java line 103:
> 
>> 101:                         throw new RuntimeException("Desrialized foreground and background color not same");
>> 102:                     }
>> 103:                 } catch (IOException | ClassNotFoundException e) {}
> 
> Shouldn't we re throw those exceptions? (considering them as a failure)

usually in other test they just do printStackTrace but we can rethrow...Updated..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2575945628

From psadhukhan at openjdk.org  Mon Dec  1 09:16:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Dec 2025 09:16:19 GMT
Subject: RFR: 4459231: Focus of JTabbedPane(with Scrollable tablayout) changes
 on change in LookAndFeel
Message-ID: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>

On changing LookAndFeel of JTabbedPane, it resets the focus of the child tabs to starting child tab.
That is, if a JTabbedPane has say 10 tabs and we select the 10th tab and then we change the L&F, the focus is shifted to Tab0 even though the selected tab is still at 10th tab.

This is because when we switch L&F, `installUI ` will reset the `focusIndex ` 
https://github.com/openjdk/jdk/blob/3481252ced7c06c44154ceccc56b12cfd9a490c3/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L285-L290

which needs to set the proper focus by calling `scrollRectToVisible ` to selected tab which is done in this fix.

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

Commit messages:
 - jcheck
 - jcheck
 - 4459231: Focus of JTabbedPane(with Scrollable tablayout) changes on change in LookAndFeel

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

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

From psadhukhan at openjdk.org  Mon Dec  1 09:46:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Dec 2025 09:46:35 GMT
Subject: RFR: 4459231: Focus of JTabbedPane(with Scrollable tablayout)
 changes on change in LookAndFeel [v2]
In-Reply-To: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
References: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
Message-ID: <fS4_Ed5-x7BXBAcq2sNWYr7ZacfIAE_fDtsJS-fqhfg=.1a062315-560f-4ab9-9b11-2d09290b27c5@github.com>

> On changing LookAndFeel of JTabbedPane, it resets the focus of the child tabs to starting child tab.
> That is, if a JTabbedPane has say 10 tabs and we select the 10th tab and then we change the L&F, the focus is shifted to Tab0 even though the selected tab is still at 10th tab.
> 
> This is because when we switch L&F, `installUI ` will reset the `focusIndex ` 
> https://github.com/openjdk/jdk/blob/3481252ced7c06c44154ceccc56b12cfd9a490c3/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L285-L290
> 
> which needs to set the proper focus by calling `scrollRectToVisible ` to selected tab which is done in this fix.

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

  test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28571/files
  - new: https://git.openjdk.org/jdk/pull/28571/files/c9ec06b6..f110cc52

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

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

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

From abaya at openjdk.org  Mon Dec  1 16:33:07 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 1 Dec 2025 16:33:07 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended during
 loss of window focus
Message-ID: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>

**Analysis :** 
The issue is that on Win32, if the window is not active, we dont receive mouse events because we release the capture
 So the problem is the following:
We start selecting text from the right to the extreme left.
Then we switch to another window( the window lose focus ), and we release the mouse
But when we return to the window, the caret drag is still active and does not stop. as the window did not recieved the mouse release event

**Proposed fix:**
In the Caret class, we added a logic to ignore the drag if the focus was lost due to window switching unless a new mouse press happens 

**Test:**
TextSelectionFocusLoss:

- OK with the fix on all platforms.

- NOK without the fix on Windows.

In the test, I was going to add a dummy frame in a separate process to ensure there was another app to switch to. However, this seems unnecessary, as we always have an additional app; at least the one responsible for starting the test.

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

Commit messages:
 - Add Test
 - Add fix

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

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

From prr at openjdk.org  Mon Dec  1 19:24:48 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Dec 2025 19:24:48 GMT
Subject: RFR: 8371647: 7 Integer overflows in mlib_malloc of mlib_sys.c:85
In-Reply-To: <VfxHInsB1JC5f-zbnGtPEOMnLqg30tMCJtnJApj61qk=.70e68cdf-7ea4-4043-95c3-3fdcb3d9f448@github.com>
References: <VfxHInsB1JC5f-zbnGtPEOMnLqg30tMCJtnJApj61qk=.70e68cdf-7ea4-4043-95c3-3fdcb3d9f448@github.com>
Message-ID: <ipjRAzO0pCYRyLWXPwgXr2oOhK-B-Cb2U_0-eV1YN-o=.a777cf75-08c8-418f-aa2a-428306fe3f1c@github.com>

On Fri, 28 Nov 2025 22:02:09 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> There is a possible overflow when using `mlib_alloc()`. For example, `mlib_alloc(sizeof(mlib_s32) * (m * n))` may overflow if m and n are greater than 46430, since this would be greater than the max value for a signed 32 bit integer. I have added `SAFE_TO_ADD` and `SAFE_TO_MULT` in an attempt to amend this issue. CI testing shows all green.

src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16ext.c line 271:

> 269:     if (!SAFE_TO_MULT(bsize, (mlib_s32)sizeof(FTYPE))) return MLIB_FAILURE;
> 270: 
> 271:     pbuff = mlib_malloc(sizeof(FTYPE)*bsize);

If mlib_malloc ends up in 
void *__mlib_malloc(mlib_u32 size); 
which I think it must do, because I can't find anything else,
then that accepts an unsigned 32 bit int, which makes sense because malloc accepts a size_t which is unsigned.

Note that sizeof() returns size_t too, so the multiplication result should be promoted to unsigned in the existing code, and preserved when passed as an arg.

But SAFE_TO_MULT will return a failure on overflow of signed arithmetic.  So I think we need something different here so we don't reject cases which are actually OK. ie in at least cases like this, we want to detect overflow of 32 bit unsigned, not 32 bit signed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28560#discussion_r2578328918

From prr at openjdk.org  Mon Dec  1 20:40:53 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Dec 2025 20:40:53 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v9]
In-Reply-To: <YGsbYqlr21ahivZy8FFsTGvEcfRtSnJCjVTBR1KjXMo=.dfd7c836-8162-4757-8006-bbc5c64f61fd@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <YGsbYqlr21ahivZy8FFsTGvEcfRtSnJCjVTBR1KjXMo=.dfd7c836-8162-4757-8006-bbc5c64f61fd@github.com>
Message-ID: <UH6T-w8gnp0GJTLuz3tM4nit7Ga-6xZ6LYjjtRcfV1Q=.c257e158-dada-4bd1-b5dc-9c243ca71d25@github.com>

On Thu, 27 Nov 2025 02:41:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc clarification for 0 value

src/java.desktop/share/classes/javax/swing/JList.java line 2510:

> 2508:      * @param direction less or equal to zero to scroll up/back,
> 2509:      *                  greater than zero for down/forward
> 2510:      * @return the "unit" increment for scrolling in the specified direction;

I don't think all of this should be in the @return statement.
I think it should just say
@return the non-negative "unit" increment for scrolling in the specified direction.

And the explanatory text should be in the body of the doc and be (something like) this, after the very first sentence of the existing doc.
"The scrolling distance returned will be positive, unless scrolling for the specified parameters is already at its furthest extent, in which case it will return zero".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2578566037

From kurt at openjdk.org  Mon Dec  1 21:52:02 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Mon, 1 Dec 2025 21:52:02 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng
In-Reply-To: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
Message-ID: <o5gICq7OYdK3s6ChPK8aCyz9XDWr0DmiAWvnLC8rE68=.7cadebc0-98b3-4f13-a511-409069151d3c@github.com>

On Fri, 14 Nov 2025 14:48:14 GMT, Kurt Miller <kurt at openjdk.org> wrote:

> When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64:
> 
> `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]`
> 
> This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX.

Could someone from client review this PR please? It would be helpful to the future bsd-port integration to correct this. Thank you

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

PR Comment: https://git.openjdk.org/jdk/pull/28324#issuecomment-3599107891

From serb at openjdk.org  Tue Dec  2 01:00:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 01:00:47 GMT
Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size
 information [v2]
In-Reply-To: <EC58IbcGSq5qD_8oNBcaZ9b7ONdxr5Cb1Lwot4rqpNY=.5f3490bd-e2c6-41a5-aec7-6f18e1cf630d@github.com>
References: <cqrDtybBDmrqGYE3w6I_O4jaqEVacVc7mBpHtGWozRo=.9612cb00-b220-4490-b062-28b1159ff2be@github.com>
 <EC58IbcGSq5qD_8oNBcaZ9b7ONdxr5Cb1Lwot4rqpNY=.5f3490bd-e2c6-41a5-aec7-6f18e1cf630d@github.com>
Message-ID: <glBCbtuupnVWh_tfO6pqs3BNbZ08VcMRACaWMhwBGiY=.39ec6f22-9aea-4148-9aad-b11463fb551e@github.com>

On Thu, 13 Nov 2025 05:22:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated.
>> Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. 
>> CI testing is ok..
>> 
>> Before fix
>> <img width="142" height="146" alt="image" src="https://github.com/user-attachments/assets/95d43e47-122a-4ca4-8a3f-f4bf5c1d3f43" />
>> 
>> After fix
>> <img width="145" height="125" alt="image" src="https://github.com/user-attachments/assets/068b5988-119c-4b99-be27-1ef5d52a28a2" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test formatting

Ok lets see how it will work.

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

Marked as reviewed by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28258#pullrequestreview-3527675007

From psadhukhan at openjdk.org  Tue Dec  2 02:50:21 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 2 Dec 2025 02:50:21 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v10]
In-Reply-To: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
Message-ID: <pcPZoGbLpgMMAPVkZ7zsFBEsq0QWh6r3gNLV2x9JVY0=.d3e15d47-b2a7-4254-9335-1ac83e7fff58@github.com>

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

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

  javadoc clarify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26500/files
  - new: https://git.openjdk.org/jdk/pull/26500/files/691ab9c3..a75e9905

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

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

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

From psadhukhan at openjdk.org  Tue Dec  2 02:58:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 2 Dec 2025 02:58:52 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v10]
In-Reply-To: <UH6T-w8gnp0GJTLuz3tM4nit7Ga-6xZ6LYjjtRcfV1Q=.c257e158-dada-4bd1-b5dc-9c243ca71d25@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <YGsbYqlr21ahivZy8FFsTGvEcfRtSnJCjVTBR1KjXMo=.dfd7c836-8162-4757-8006-bbc5c64f61fd@github.com>
 <UH6T-w8gnp0GJTLuz3tM4nit7Ga-6xZ6LYjjtRcfV1Q=.c257e158-dada-4bd1-b5dc-9c243ca71d25@github.com>
Message-ID: <yLhN-SMoosPZ4NoLLWKvvsv_bfUmueTvk7IjgVkBQY0=.b961c0a1-1d5b-43e4-adeb-eb1a8520a2cf@github.com>

On Mon, 1 Dec 2025 20:38:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc clarify
>
> src/java.desktop/share/classes/javax/swing/JList.java line 2510:
> 
>> 2508:      * @param direction less or equal to zero to scroll up/back,
>> 2509:      *                  greater than zero for down/forward
>> 2510:      * @return the "unit" increment for scrolling in the specified direction;
> 
> I don't think all of this should be in the @return statement.
> I think it should just say
> @return the non-negative "unit" increment for scrolling in the specified direction.
> 
> And the explanatory text should be in the body of the doc and be (something like) this, after the very first sentence of the existing doc.
> "The scrolling distance returned will be positive, unless scrolling for the specified parameters is already at its furthest extent, in which case it will return zero".

OK updated both PR and CSR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2579410773

From smandalika at openjdk.org  Tue Dec  2 08:25:49 2025
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Tue, 2 Dec 2025 08:25:49 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v9]
In-Reply-To: <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
Message-ID: <VdgH7VBgtuNuKjs41c7ELJ5TYOQCegSxI-pdrkE3LwQ=.b7af25eb-5bea-4345-bd45-1904637ca0ba@github.com>

On Wed, 26 Nov 2025 10:11:43 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
>> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt.
>
> Srinivas Mandalika has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Trigger the bot.
>  - Merge branch '8068378' of github.com:srmandal/jdk into 8068378
>  - Merge branch 'master' of github.com:openjdk/jdk into 8068378
>  - Added line after subsection name
>  - Merge master
>  - Fixed Typos
>  - Fixed whitepsace error.
>  - 8068378: Review feedback for instructions, missing break in switch case in Test.java
>  - Removed Merge Conflict from PL file.
>  - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update

Can someone please sponsor this request.

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

PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3600802071

From prr at openjdk.org  Tue Dec  2 18:20:26 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Dec 2025 18:20:26 GMT
Subject: Integrated: 6185110: Undefined behaviour of SampleModel for width,
 height < 0
In-Reply-To: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
References: <xWgspVkC3UsPVMZ9tvyV5DuG4CPSmAk2gkaPgoztMpk=.d3899355-bd00-44ea-86ba-a46f8bae2001@github.com>
Message-ID: <dRgqd1Er3fJHXvUDrd6FtdWu0eO3flSp3F38uuFZrp4=.ddd654f6-3bc6-4349-ac94-2a6922d4b447@github.com>

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

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

This pull request has now been integrated.

Changeset: ac0e6af8
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac0e6af8f90ba77375b2841a5c8aa05743884a1e
Stats:     822 lines in 6 files changed: 372 ins; 206 del; 244 mod

6185110: Undefined behaviour of SampleModel for width, height < 0

Reviewed-by: psadhukhan

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

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

From kizune at openjdk.org  Tue Dec  2 20:11:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 2 Dec 2025 20:11:11 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
Message-ID: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>

Perform null check before requesting information for the popup component and return nil if component is no longer exists.

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

Commit messages:
 - 8372757: MacOS, Accessibility: Crash in [MenuAccessibility accessibilityChildren] after JDK-8341311

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

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

From serb at openjdk.org  Tue Dec  2 20:12:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 20:12:20 GMT
Subject: Integrated: 8369618: Remove outdated reference to JDK 1.1 in the spec
 of BufferedImage.TYPE_INT_ARGB
In-Reply-To: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>
References: <iwISPQf0LAgNqcS6r5Zj3raY-zlh6fdFk_-WoZccRGg=.68280700-a629-4ff5-9f84-e6be67c71dd2@github.com>
Message-ID: <udRVc1JyvrAisphLOSXe7EpEYiG0XY-lzykODCQIxyI=.62873aff-c3f7-4f1d-83f3-f3520215d4c2@github.com>

On Sun, 12 Oct 2025 01:40:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 5a60e22b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a60e22bc415b3335cbb6a63873b1b44ff2bf9d0
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

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

Reviewed-by: azvegint, kizune, prr

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

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

From prr at openjdk.org  Tue Dec  2 20:16:51 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Dec 2025 20:16:51 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v10]
In-Reply-To: <pcPZoGbLpgMMAPVkZ7zsFBEsq0QWh6r3gNLV2x9JVY0=.d3e15d47-b2a7-4254-9335-1ac83e7fff58@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <pcPZoGbLpgMMAPVkZ7zsFBEsq0QWh6r3gNLV2x9JVY0=.d3e15d47-b2a7-4254-9335-1ac83e7fff58@github.com>
Message-ID: <P4PcWoIc3ZkyzsFXmDRKV5qczwXQn1QpWbW6GULgyLo=.ef2a8807-09b3-4d5f-b2b4-0cc632ada3a7@github.com>

On Tue, 2 Dec 2025 02:50:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc clarify

src/java.desktop/share/classes/javax/swing/JList.java line 2501:

> 2499:      * row (for vertical scrolling) or column (for horizontal scrolling).
> 2500:      * The scrolling distance returned will be positive,
> 2501:      * unless scrolling location for the specified parameters is already

my suggestion was "unless scrolling for".
you changed it to "unless scrolling location for"
I don't think adding the word location here is correct in the overall context of the sentence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2582651737

From serb at openjdk.org  Tue Dec  2 21:05:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 21:05:21 GMT
Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data
 is null [v2]
In-Reply-To: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com>
References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com>
Message-ID: <JlSIBpJJB5x2xhOPpOfrjqR5AUnFA5dGfBfdvxM6swE=.ac0eb124-ac3d-4f78-95e9-452fdae922f6@github.com>

> This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously.
> 
> Rationale:
>  - Since an NPE was already thrown before, this does not introduce a behavior change
>  - Throwing NPE on null is the common pattern used across the codebase, including in the affected package
> 
> Additional notes:
> The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed.
> 
> It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown.

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-8371501
 - 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28249/files
  - new: https://git.openjdk.org/jdk/pull/28249/files/b0a02731..49b5e2de

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

  Stats: 98777 lines in 1529 files changed: 62872 ins; 25756 del; 10149 mod
  Patch: https://git.openjdk.org/jdk/pull/28249.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28249/head:pull/28249

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

From serb at openjdk.org  Tue Dec  2 21:05:22 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 21:05:22 GMT
Subject: RFR: 8371501: Change IAE to NPE in java.awt.image.Kernel when data
 is null [v2]
In-Reply-To: <b7yET98j6iUlKTzKmwendWua3ywtqv1Hf1NZcr_Q15M=.732f778b-612e-49a6-8da1-f1b4b9ef7fc9@github.com>
References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com>
 <b7yET98j6iUlKTzKmwendWua3ywtqv1Hf1NZcr_Q15M=.732f778b-612e-49a6-8da1-f1b4b9ef7fc9@github.com>
Message-ID: <U6cCUSx2ya91ddQVlyA-bwKA63lB1BX0J0yAKmKCn9c=.31deeb14-3b3e-434a-9a58-519ad385a006@github.com>

On Tue, 25 Nov 2025 09:26:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8371501
>>  - 8371501: Change IAE to NPE in java.awt.image.Kernel when data is null
>
> test/jdk/java/awt/image/ConvolveOp/KernelInitialisationTest.java line 49:
> 
>> 47:             System.err.println("Expected: " + expected);
>> 48:             System.err.println("Actual: " + actual);
>> 49:             throw new RuntimeException("Test failed");
> 
> Does it make sense to include the class names in the error message too? It helps analysing the failure, you know the reason without opening the log file.

I agree it might be useful, but it?s not that critical. I?ll follow that pattern in the next tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28249#discussion_r2582756816

From serb at openjdk.org  Tue Dec  2 21:05:24 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 21:05:24 GMT
Subject: Integrated: 8371501: Change IAE to NPE in java.awt.image.Kernel when
 data is null
In-Reply-To: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com>
References: <0bU-D8sNFOFCEtIwSv6d0b75uIO9mkK24qtA_guTS1U=.8f40f71b-249d-4f84-ad73-af2b66e1f52a@github.com>
Message-ID: <iEE0ZuK5usuHIqiUAXQeK8YOW_oHHzVrn8veRvKR3mw=.0a3a001a-2c25-4ece-9d70-f12d1aaff9c3@github.com>

On Wed, 12 Nov 2025 02:54:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is an update to the patch integrated in https://github.com/openjdk/jdk/pull/28127. It changes the exception from IllegalArgumentException back to NullPointerException, which was thrown previously.
> 
> Rationale:
>  - Since an NPE was already thrown before, this does not introduce a behavior change
>  - Throwing NPE on null is the common pattern used across the codebase, including in the affected package
> 
> Additional notes:
> The patch uses the idiomatic way to check parameters for null via Objects.requireNonNull(). I am not sure whether this code path is performance critical. The use of >> 1 instead of / 2 suggests that performance might matter. If this code is performance sensitive, we can remove the Objects.requireNonNull() call, because even without it the resulting NPE would still clearly show which variable was null when its field was accessed.
> 
> It is also possible to remove the use of multiplyExact(). We can simply multiply width/height as long values and compare the result with the data length. In case of overflow, the existing ?Data array too small? exception would still be thrown.

This pull request has now been integrated.

Changeset: 37cd8d6c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37cd8d6ca0bc4638d81e9a3c1e0bc785861ffbef
Stats:     41 lines in 2 files changed: 18 ins; 6 del; 17 mod

8371501: Change IAE to NPE in java.awt.image.Kernel when data is null

Reviewed-by: prr, azvegint, aivanov

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

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

From serb at openjdk.org  Tue Dec  2 22:03:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 22:03:29 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
Message-ID: <8cgrWb3qyr5nvra-fNH8C2AahJ97_l-WaurLDQCWIFk=.bbe450dc-15d0-4933-b53c-d280a5d8e300@github.com>

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

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

But that means the content of the resulting image will be cut without any notification to the application. Is that more useful than throwing an exception?

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

PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3604112653

From serb at openjdk.org  Tue Dec  2 22:03:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Dec 2025 22:03:33 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
Message-ID: <fvStbhSPJyp2QSrW4yIXXpzvEC3kFakXyzz-8X3AV8c=.b36ced5b-807f-4420-9c35-4d64eb2c0c84@github.com>

On Mon, 1 Dec 2025 07:41:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
>> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
>> defined in the JTable (typically black on white) to be ignored.
>> 
>> The problem seems to stem from a call to
>> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
>> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
>> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
>> 
>> CI run is ok..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rethrow Exception

src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java line 381:

> 379:     /**
> 380:      * See readObject() and writeObject() in JComponent for more
> 381:      * information about serialization in Swing.

Is there some useful information in the JComponent about why we implemented writeObject this way? I guess this implementation mimics what we have in ?DefaultTableCellRenderer.updateUI().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28549#discussion_r2582847725

From prr at openjdk.org  Tue Dec  2 22:14:39 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Dec 2025 22:14:39 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <8cgrWb3qyr5nvra-fNH8C2AahJ97_l-WaurLDQCWIFk=.bbe450dc-15d0-4933-b53c-d280a5d8e300@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <8cgrWb3qyr5nvra-fNH8C2AahJ97_l-WaurLDQCWIFk=.bbe450dc-15d0-4933-b53c-d280a5d8e300@github.com>
Message-ID: <z0Fmr8R_quQ7yhMIc1piMN49v2Lk2P9WSLmYyMUvmPM=.8af112ee-40ec-4f64-80c3-9168c7744a41@github.com>

On Tue, 2 Dec 2025 21:49:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > So some inconsistency but I think it is a user-friendly trade-off.
> 
> But that means the content of the resulting image will be cut without any notification to the application. Is that more useful than throwing an exception?

Yes, I think it is or I wouldn't be proposing it.
Take the evidence of the bug report where the exception is clearly unexpected and difficult to predict and could have bad consequences.
Also an app can supply the dest, which unless they are re-using the exact same destination from a previous call or the results of createCompatibleDestImage.

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

PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3604176242

From azvegint at openjdk.org  Wed Dec  3 00:25:19 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 3 Dec 2025 00:25:19 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling are
 broken on XWayland GNOME >= 47 after JDK-8351907
Message-ID: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>

The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:

https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529

> Trying to click any mouse additional button raises an exception like the following:
>
> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
java.lang.IllegalArgumentException: Nonexistent button 6
        at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
        at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
        at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
        at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
        at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
        at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
        at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
        at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
        at java.base/java.lang.Thread.run(Thread.java:1583)

This changeset simply reverses the check, returning it to its original state.

The actual check for the supported mouse buttons for the robot is maintained here.

https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371

https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214

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

Commit messages:
 - 8372756: Mouse additional buttons and horizontal scrolling are broken on XWayland GNOME >= 47 after JDK-835190

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

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

From azvegint at openjdk.org  Wed Dec  3 00:25:20 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 3 Dec 2025 00:25:20 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
Message-ID: <0GtWQDGGXVgekWH-swmOgmY2y1hxEOMpgFxcSeRDXGk=.46c0774e-655a-4956-9050-c37781d9257a@github.com>

On Wed, 3 Dec 2025 00:04:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529
> 
>> Trying to click any mouse additional button raises an exception like the following:
>>
>> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
> java.lang.IllegalArgumentException: Nonexistent button 6
>         at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
>         at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
>         at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
>         at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> This changeset simply reverses the check, returning it to its original state.
> 
> The actual check for the supported mouse buttons for the robot is maintained here.
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214

src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java line 1530:

> 1528:                 //If we have 3 physical buttons and a wheel, we report 3 buttons.
> 1529:                 //If we have 1,2,3 physical buttons, we report it as is i.e. 1,2 or 3 respectively.
> 1530:                 if (numberOfButtons >= 5) {

Suggestion:

                if (numberOfButtons > 5) {

It actually should be `>5`, without it the `numberOfButtons == 5` in `else if` branch is always false.

I want to put the fix to 26, so I intentionally left it as it was before because it had been tested for years. Once we agree on that, I'll file an issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28621#discussion_r2583185136

From serb at openjdk.org  Wed Dec  3 00:57:11 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 3 Dec 2025 00:57:11 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <z0Fmr8R_quQ7yhMIc1piMN49v2Lk2P9WSLmYyMUvmPM=.8af112ee-40ec-4f64-80c3-9168c7744a41@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <8cgrWb3qyr5nvra-fNH8C2AahJ97_l-WaurLDQCWIFk=.bbe450dc-15d0-4933-b53c-d280a5d8e300@github.com>
 <z0Fmr8R_quQ7yhMIc1piMN49v2Lk2P9WSLmYyMUvmPM=.8af112ee-40ec-4f64-80c3-9168c7744a41@github.com>
Message-ID: <HWqUzUhaDV4SNtDhH2VduzeLtPEKBD5F0qKGZzd8OPU=.6670fae2-c972-4060-bc91-eb66735ca04e@github.com>

On Tue, 2 Dec 2025 22:11:52 GMT, Phil Race <prr at openjdk.org> wrote:

> Take the evidence of the bug report where the exception is clearly unexpected and difficult to predict and could have bad consequences.

In the bug description, it?s unclear whether the phrase ?exception unexpected? means that an exception is unexpected, or that the type of the exception is ?unexpected?. For example, if the transform is set to scale the image by a value near MAX_INT(AffineTransform.getScaleInstance(Integer.MAX_VALUE, 1)), is it really good thing to return an image of the original size with "corrupted" content? In what cases it might be useful?

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

PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3604564680

From psadhukhan at openjdk.org  Wed Dec  3 01:31:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Dec 2025 01:31:35 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v11]
In-Reply-To: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
Message-ID: <LS2W6JDDdRCLGeh8Yen-6wh-ifkdiae-82UpK-wYKFs=.e823fba4-acd6-4710-9f5e-a11511bd32c6@github.com>

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

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

  doc fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26500/files
  - new: https://git.openjdk.org/jdk/pull/26500/files/a75e9905..7d6cde15

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

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

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

From psadhukhan at openjdk.org  Wed Dec  3 01:31:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Dec 2025 01:31:38 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v10]
In-Reply-To: <P4PcWoIc3ZkyzsFXmDRKV5qczwXQn1QpWbW6GULgyLo=.ef2a8807-09b3-4d5f-b2b4-0cc632ada3a7@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <pcPZoGbLpgMMAPVkZ7zsFBEsq0QWh6r3gNLV2x9JVY0=.d3e15d47-b2a7-4254-9335-1ac83e7fff58@github.com>
 <P4PcWoIc3ZkyzsFXmDRKV5qczwXQn1QpWbW6GULgyLo=.ef2a8807-09b3-4d5f-b2b4-0cc632ada3a7@github.com>
Message-ID: <4X8WdMpIwdkQCnlMJ1VkXgisEiOzWop4swxGAiqfzhk=.be9645ab-1d1e-4db6-83ae-b77e385ec4a4@github.com>

On Tue, 2 Dec 2025 20:14:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc clarify
>
> src/java.desktop/share/classes/javax/swing/JList.java line 2501:
> 
>> 2499:      * row (for vertical scrolling) or column (for horizontal scrolling).
>> 2500:      * The scrolling distance returned will be positive,
>> 2501:      * unless scrolling location for the specified parameters is already
> 
> my suggestion was "unless scrolling for".
> you changed it to "unless scrolling location for"
> I don't think adding the word location here is correct in the overall context of the sentence.

ok..removed location..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2583327196

From prr at openjdk.org  Wed Dec  3 01:35:14 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 01:35:14 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear [v2]
In-Reply-To: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
Message-ID: <84lpLmioVJac7JSDLsLWL_5biTsy2VxfNmZFehNc0E8=.894889dc-2a80-4c46-89cb-c14b14226d53@github.com>

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

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

  4690476

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27707/files
  - new: https://git.openjdk.org/jdk/pull/27707/files/65ae972a..94804448

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

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

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

From prr at openjdk.org  Wed Dec  3 01:36:52 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 01:36:52 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <HWqUzUhaDV4SNtDhH2VduzeLtPEKBD5F0qKGZzd8OPU=.6670fae2-c972-4060-bc91-eb66735ca04e@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <8cgrWb3qyr5nvra-fNH8C2AahJ97_l-WaurLDQCWIFk=.bbe450dc-15d0-4933-b53c-d280a5d8e300@github.com>
 <z0Fmr8R_quQ7yhMIc1piMN49v2Lk2P9WSLmYyMUvmPM=.8af112ee-40ec-4f64-80c3-9168c7744a41@github.com>
 <HWqUzUhaDV4SNtDhH2VduzeLtPEKBD5F0qKGZzd8OPU=.6670fae2-c972-4060-bc91-eb66735ca04e@github.com>
Message-ID: <35esq3Juhfmt4G_aZCpfZME0L1Llax1Fa6z3yci7kDE=.a6037fd4-f7af-4071-930e-931fdf221f62@github.com>

On Wed, 3 Dec 2025 00:54:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Take the evidence of the bug report where the exception is clearly unexpected and difficult to predict and could have bad consequences.
> 
> In the bug description, it?s unclear whether the phrase ?exception unexpected? means that an exception is unexpected, or that the type of the exception is ?unexpected?. For example, if the transform is set to scale the image by a value near MAX_INT(AffineTransform.getScaleInstance(Integer.MAX_VALUE, 1)), is it really good thing to return an image of the original size with "corrupted" content? In what cases it might be useful?

There isn't corrupted content, it is partial content in the case of an image that is too large.
And this seems far more useful and friendly than the exception.
What you are raising is no more than what I called out in the description at the very beginning of this PR some 2 months ago.

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

PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3604654072

From prr at openjdk.org  Wed Dec  3 01:36:53 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 01:36:53 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
Message-ID: <kG38_0pwGzz6zK34Zd3AmptgUJ7aDmMTkWFSLWb9CO4=.f56a44ba-1b7b-4126-b4b7-9b2532f524d5@github.com>

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

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

I've updated the PR with 'may' changed to 'will' per CSR discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3604655459

From prr at openjdk.org  Wed Dec  3 01:37:45 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 01:37:45 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v11]
In-Reply-To: <LS2W6JDDdRCLGeh8Yen-6wh-ifkdiae-82UpK-wYKFs=.e823fba4-acd6-4710-9f5e-a11511bd32c6@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <LS2W6JDDdRCLGeh8Yen-6wh-ifkdiae-82UpK-wYKFs=.e823fba4-acd6-4710-9f5e-a11511bd32c6@github.com>
Message-ID: <GeciqViX_VQ_AJV_EZzcIhUToEIv13C-C_yhFKQK_lA=.97535f48-5274-4058-900a-8dd46ef86859@github.com>

On Wed, 3 Dec 2025 01:31:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc fix

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26500#pullrequestreview-3532806214

From serb at openjdk.org  Wed Dec  3 02:37:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 3 Dec 2025 02:37:57 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <35esq3Juhfmt4G_aZCpfZME0L1Llax1Fa6z3yci7kDE=.a6037fd4-f7af-4071-930e-931fdf221f62@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <8cgrWb3qyr5nvra-fNH8C2AahJ97_l-WaurLDQCWIFk=.bbe450dc-15d0-4933-b53c-d280a5d8e300@github.com>
 <z0Fmr8R_quQ7yhMIc1piMN49v2Lk2P9WSLmYyMUvmPM=.8af112ee-40ec-4f64-80c3-9168c7744a41@github.com>
 <HWqUzUhaDV4SNtDhH2VduzeLtPEKBD5F0qKGZzd8OPU=.6670fae2-c972-4060-bc91-eb66735ca04e@github.com>
 <35esq3Juhfmt4G_aZCpfZME0L1Llax1Fa6z3yci7kDE=.a6037fd4-f7af-4071-930e-931fdf221f62@github.com>
Message-ID: <t1C6vWSmauqWGpHNzQ4A_zKKnD9wwqu1B7lCbf0yihg=.0afec42c-1846-458a-a7e7-cf12a48c5a7f@github.com>

On Wed, 3 Dec 2025 01:33:24 GMT, Phil Race <prr at openjdk.org> wrote:

> There isn't corrupted content, it is partial content in the case of an image that is too large.

ok, up to you.

But still Imagine: you are the app developer and you want to transform the image and then render it on the screen at a specific position. When the filtered image is returned how are you supposed to render it if its size is too small? You cannot simply scale it up, because the content has been partially cut and is no longer complete. So instead of checking the parameters or catch an exception the app will need to always check the size of the returned image, no?

ps. I still believe the partition content is incorrect and corrupted, because the app expects a larger image that can be rendered or saved later. In this case, we should fail fast and notify the app that the result is unexpected.

Or alternatively, we could return the largest image we can create, since anything larger cannot be stored or rendered anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3604788170

From psadhukhan at openjdk.org  Wed Dec  3 02:47:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Dec 2025 02:47:58 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear [v2]
In-Reply-To: <84lpLmioVJac7JSDLsLWL_5biTsy2VxfNmZFehNc0E8=.894889dc-2a80-4c46-89cb-c14b14226d53@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <84lpLmioVJac7JSDLsLWL_5biTsy2VxfNmZFehNc0E8=.894889dc-2a80-4c46-89cb-c14b14226d53@github.com>
Message-ID: <Uy9OVqk_jqTNUld48izvJqRBnxe_SS-z0p0hcXcGVSY=.94f1c783-a949-46fb-81e9-006f89ad3579@github.com>

On Wed, 3 Dec 2025 01:35:14 GMT, Phil Race <prr at openjdk.org> wrote:

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

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27707#pullrequestreview-3532952370

From psadhukhan at openjdk.org  Wed Dec  3 02:49:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Dec 2025 02:49:10 GMT
Subject: Integrated: 8364146: JList getScrollableUnitIncrement return 0
In-Reply-To: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
Message-ID: <ZOkvpuapsM7NhQ0QvmL_vTP4n1IMNDgvOzcAT9D72l8=.fbf5b8c4-8169-49f7-be2a-6955a1fe4b0f@github.com>

On Mon, 28 Jul 2025 09:14:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 530493fe
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/530493fed4066b1efcf3ec22253b110495767eca
Stats:     95 lines in 2 files changed: 91 ins; 0 del; 4 mod

8364146: JList getScrollableUnitIncrement return 0

Reviewed-by: prr, tr

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

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

From psadhukhan at openjdk.org  Wed Dec  3 03:44:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Dec 2025 03:44:58 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
Message-ID: <3K1qH5GiIXsc2zagw7B17NprNpb5rUL5GIE_RnKWtQY=.0011d74d-4dc3-4ac7-bf7e-eae14f7c69bb@github.com>

On Tue, 2 Dec 2025 20:03:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Perform null check before requesting information for the popup component and return nil if component is no longer exists.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m line 71:

> 69:                                                              fAccessible, fComponent);
> 70: 
> 71:     if (axComponent == nil) {

Dont we need to call `CHECK_EXCEPTION()` as we were calling JNI?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28614#discussion_r2583518096

From azvegint at openjdk.org  Wed Dec  3 05:23:18 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 3 Dec 2025 05:23:18 GMT
Subject: RFR: 8372977: unnecessary gthread-2.0 loading
Message-ID: <VmgorIq4lta0RwuCSPvX-q4Uxo98rJAlig_0Z0X5pX0=.1ca88596-a72f-4903-a1c5-ad14b5193230@github.com>

Actual usage of the gthread-2.0 was removed with GTK2 support in [JDK-8329471](https://bugs.openjdk.org/browse/JDK-8329471).
But there are some leftovers, we are still loading it with GTK3, even though it was never used when it was added in [JDK-8164321](https://bugs.openjdk.org/browse/JDK-8164321).

It wasn't an issue before, but some modern systems (e.g. openSUSE 16) don't provide the library.
Because of this, we are unable to load GTK, which leads to Robot functionality requiring the Screencast or Remote Desktop API on Wayland not working.

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

Commit messages:
 - remove GThreadFunctions
 - 8372977: unnecessary gthread-2.0 loading

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

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

From jdv at openjdk.org  Wed Dec  3 05:47:58 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 3 Dec 2025 05:47:58 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng
In-Reply-To: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
Message-ID: <Rc6r29-tG6ngZpVQXBqX_LRXUsITAvl6pKhY8-jEdYI=.3b118d63-4eca-4e9b-8533-3b1a6e31103f@github.com>

On Fri, 14 Nov 2025 14:48:14 GMT, Kurt Miller <kurt at openjdk.org> wrote:

> When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64:
> 
> `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]`
> 
> This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX.

Code change looks good to me. There is only one minor input about updating a comment. 
I have given full client test run with this change.

make/modules/java.desktop/lib/ClientLibraries.gmk line 167:

> 165:   ifeq ($(USE_EXTERNAL_LIBPNG), false)
> 166:     LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> 167:     LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0

I think we can move these flags which are not specific to any OS/Architecture to src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h itself. But it should be handled in follow-up task not under this bug. Filed https://bugs.openjdk.org/browse/JDK-8372979 for the same.

make/modules/java.desktop/lib/ClientLibraries.gmk line 174:

> 172:     endif
> 173: 
> 174:     # The external libpng submitted in the jdk is a reduced version

I think this comment should start with "The libpng bundled with jdk". Mentioning "external" at this level doesn't seem right. Since we are touching this part we can update the comment.

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

PR Review: https://git.openjdk.org/jdk/pull/28324#pullrequestreview-3533249426
PR Review Comment: https://git.openjdk.org/jdk/pull/28324#discussion_r2583689158
PR Review Comment: https://git.openjdk.org/jdk/pull/28324#discussion_r2583697212

From serb at openjdk.org  Wed Dec  3 07:47:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 3 Dec 2025 07:47:46 GMT
Subject: RFR: 8372974: Add missing @Override annotations in
 "com.sun.java.swing.plaf.gtk" package
Message-ID: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>

This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.gtk` 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.

BTW, does anybody know why the gtk l&f is located in the shared code? Possibly we could move it to the unix folder, similar to how the windows l&f was moved to the windows folder in https://bugs.openjdk.org/browse/JDK-8189656 ?

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

Commit messages:
 - gtkover

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

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

From duke at openjdk.org  Wed Dec  3 08:57:47 2025
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 3 Dec 2025 08:57:47 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
Message-ID: <u8_rH_L2wLmOmLVYBNnuzjhK6Il0-b-BQ4uTSCA9VNQ=.ddab1e4d-bf2d-400d-a43e-a87661078519@github.com>

On Tue, 2 Dec 2025 20:03:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Perform null check before requesting information for the popup component and return nil if component is no longer exists.

Hello! JetBrains has actually proposed its own version of the fix, could you take a look please? https://github.com/openjdk/jdk/pull/28599

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

PR Comment: https://git.openjdk.org/jdk/pull/28614#issuecomment-3605743046

From psadhukhan at openjdk.org  Wed Dec  3 10:13:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Dec 2025 10:13:52 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
Message-ID: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>

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

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

Commit messages:
 - 6441373: Editing JTable is not Serializable

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

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

From abaya at openjdk.org  Wed Dec  3 10:46:26 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 3 Dec 2025 10:46:26 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v2]
In-Reply-To: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
Message-ID: <QX3vrV9R1Dw5pR89Q5XclvvXz-yujIQxVmM4aBILVXw=.f0be4eaf-135e-4c52-881a-a2dad7699582@github.com>

> **Analysis :** 
> The issue is that on Win32, if the window is not active, we dont receive mouse events because we release the capture
>  So the problem is the following:
> We start selecting text from the right to the extreme left.
> Then we switch to another window( the window lose focus ), and we release the mouse
> But when we return to the window, the caret drag is still active and does not stop. as the window did not recieved the mouse release event
> 
> **Proposed fix:**
> In the Caret class, we added a logic to ignore the drag if the focus was lost due to window switching unless a new mouse press happens

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

  Remove Extra line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28582/files
  - new: https://git.openjdk.org/jdk/pull/28582/files/e7deabc6..0d4722dc

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

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

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

From abaya at openjdk.org  Wed Dec  3 10:56:24 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 3 Dec 2025 10:56:24 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v3]
In-Reply-To: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
Message-ID: <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>

> **Analysis :** 
> The issue is that on Win32, if the window is not active, we dont receive mouse events because we release the capture
>  So the problem is the following:
> We start selecting text from the right to the extreme left.
> Then we switch to another window( the window lose focus ), and we release the mouse
> But when we return to the window, the caret drag is still active and does not stop. as the window did not recieved the mouse release event
> 
> **Proposed fix:**
> In the Caret class, we added a logic to ignore the drag if the focus was lost due to window switching unless a new mouse press happens

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

  The issue occurs only on Wnidows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28582/files
  - new: https://git.openjdk.org/jdk/pull/28582/files/0d4722dc..da7ce5ef

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

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

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

From duke at openjdk.org  Wed Dec  3 11:33:33 2025
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 3 Dec 2025 11:33:33 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
Message-ID: <3Le4vpUkvedx5BWXGqrc_j_s80O0vAUoyKb2seYTHWg=.20a658a7-8a02-414f-ba1d-83e19e92d3d6@github.com>

On Wed, 3 Dec 2025 00:04:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529
> 
>> Trying to click any mouse additional button raises an exception like the following:
>>
>> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
> java.lang.IllegalArgumentException: Nonexistent button 6
>         at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
>         at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
>         at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
>         at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> This changeset simply reverses the check, returning it to its original state.
> 
> The actual check for the supported mouse buttons for the robot is maintained here.
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214

Looks good for me

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

Marked as reviewed by OnePatchGuy at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/28621#pullrequestreview-3534617031

From duke at openjdk.org  Wed Dec  3 11:33:35 2025
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 3 Dec 2025 11:33:35 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <0GtWQDGGXVgekWH-swmOgmY2y1hxEOMpgFxcSeRDXGk=.46c0774e-655a-4956-9050-c37781d9257a@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
 <0GtWQDGGXVgekWH-swmOgmY2y1hxEOMpgFxcSeRDXGk=.46c0774e-655a-4956-9050-c37781d9257a@github.com>
Message-ID: <PksMFw0WRuSJabj3yF86tkfFEbvLvBISf63omqyKLnA=.07e4e8dc-53ae-4b72-bb3d-0245bc6545ed@github.com>

On Wed, 3 Dec 2025 00:12:47 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:
>> 
>> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529
>> 
>>> Trying to click any mouse additional button raises an exception like the following:
>>>
>>> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
>> java.lang.IllegalArgumentException: Nonexistent button 6
>>         at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
>>         at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
>>         at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
>>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
>>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
>>         at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
>>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
>>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
>>         at java.base/java.lang.Thread.run(Thread.java:1583)
>> 
>> This changeset simply reverses the check, returning it to its original state.
>> 
>> The actual check for the supported mouse buttons for the robot is maintained here.
>> 
>> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371
>> 
>> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214
>
> src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java line 1530:
> 
>> 1528:                 //If we have 3 physical buttons and a wheel, we report 3 buttons.
>> 1529:                 //If we have 1,2,3 physical buttons, we report it as is i.e. 1,2 or 3 respectively.
>> 1530:                 if (numberOfButtons >= 5) {
> 
> Suggestion:
> 
>                 if (numberOfButtons > 5) {
> 
> It actually should be `>5`, without it the `numberOfButtons == 5` in `else if` branch is always false.
> 
> I want to put the fix to 26, so I intentionally left it as it was before because it had been tested for years. Once we agree on that, I'll file an issue.

BTW, buttons 6 and 7 nowadays are used for horizontal scrolling on X11: when you either do one of the following:
* a horizontal scrolling gesture on a touchpad
* use a secondary mouse wheel (e.g. like on Logitech MX Master 3S/4)

X11 generates a ButtonPress event with the button set to 6 or 7 (depending on the scrolling direction). AWT then subtracts 2 (to take into account the primary wheel) and generates a MouseEvent with the button set to 4 or 5. In the ideal world it obviously should have been MouseWheelEvent exactly how it's done for the primary wheel. However IDK if it'd be a good change for OpenJDK due to the compatibility/legacy reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28621#discussion_r2584742505

From kurt at openjdk.org  Wed Dec  3 15:50:00 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Wed, 3 Dec 2025 15:50:00 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng [v2]
In-Reply-To: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
Message-ID: <t3-4CAIOHBWnoYOrALBYMp18_ZFp5rUBXr1NxSYF_ks=.bec12af7-b6d0-432d-8d6b-e8452be82f4b@github.com>

> When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64:
> 
> `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]`
> 
> This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX.

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

  Clarify comment per code review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28324/files
  - new: https://git.openjdk.org/jdk/pull/28324/files/a7c9813f..50061a1d

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

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

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

From kurt at openjdk.org  Wed Dec  3 15:50:02 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Wed, 3 Dec 2025 15:50:02 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng [v2]
In-Reply-To: <Rc6r29-tG6ngZpVQXBqX_LRXUsITAvl6pKhY8-jEdYI=.3b118d63-4eca-4e9b-8533-3b1a6e31103f@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
 <Rc6r29-tG6ngZpVQXBqX_LRXUsITAvl6pKhY8-jEdYI=.3b118d63-4eca-4e9b-8533-3b1a6e31103f@github.com>
Message-ID: <UfP0C6UQCOynuHMron_4NxyS-ycgh9ncLzcBbGidNg4=.f30b753b-f649-49cf-8be0-ad9311442170@github.com>

On Wed, 3 Dec 2025 05:41:27 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Kurt Miller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify comment per code review
>
> make/modules/java.desktop/lib/ClientLibraries.gmk line 174:
> 
>> 172:     endif
>> 173: 
>> 174:     # The external libpng submitted in the jdk is a reduced version
> 
> I think this comment should start with "The libpng bundled with jdk". Mentioning "external" at this level doesn't seem right. Since we are touching this part we can update the comment.

That is more clear for sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28324#discussion_r2585649096

From kurt at openjdk.org  Wed Dec  3 16:01:39 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Wed, 3 Dec 2025 16:01:39 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng [v2]
In-Reply-To: <Rc6r29-tG6ngZpVQXBqX_LRXUsITAvl6pKhY8-jEdYI=.3b118d63-4eca-4e9b-8533-3b1a6e31103f@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
 <Rc6r29-tG6ngZpVQXBqX_LRXUsITAvl6pKhY8-jEdYI=.3b118d63-4eca-4e9b-8533-3b1a6e31103f@github.com>
Message-ID: <uzYcrt5bymusemTsF9saI-K8-bqY9uLh9x4kL1n3usM=.881f1dca-3dc2-4562-8f98-3f4f4294b753@github.com>

On Wed, 3 Dec 2025 05:36:16 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Kurt Miller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify comment per code review
>
> make/modules/java.desktop/lib/ClientLibraries.gmk line 167:
> 
>> 165:   ifeq ($(USE_EXTERNAL_LIBPNG), false)
>> 166:     LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
>> 167:     LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> 
> I think we can move these flags which are not specific to any OS/Architecture to src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h itself. But it should be handled in follow-up task not under this bug. Filed https://bugs.openjdk.org/browse/JDK-8372979 for the same.

@jayathirthrao Thank you for the review.

The internal PNG defines are treated inconsistently. MMX is x86,  PNG_ARM is arm/aarch64 but they are not behind CpuArch conditionals while the others are behind OS + CpuArch conditionals. All of these defines appear to be well scoped and likely don't conflict with each other for internal png. I suspect they all can be defined without OS + CpuArch conditionals for the internal png case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28324#discussion_r2585698160

From jdv at openjdk.org  Wed Dec  3 16:31:43 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 3 Dec 2025 16:31:43 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng [v2]
In-Reply-To: <t3-4CAIOHBWnoYOrALBYMp18_ZFp5rUBXr1NxSYF_ks=.bec12af7-b6d0-432d-8d6b-e8452be82f4b@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
 <t3-4CAIOHBWnoYOrALBYMp18_ZFp5rUBXr1NxSYF_ks=.bec12af7-b6d0-432d-8d6b-e8452be82f4b@github.com>
Message-ID: <tT3i9NPEW4JQNCW77V06nC8S5hVycwvys1BPMcq1Q9o=.2017c9dc-a4d6-4072-8226-08b7b26e8097@github.com>

On Wed, 3 Dec 2025 15:50:00 GMT, Kurt Miller <kurt at openjdk.org> wrote:

>> When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64:
>> 
>> `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]`
>> 
>> This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX.
>
> Kurt Miller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comment per code review

Client testing is also green.

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28324#pullrequestreview-3535924619

From jdv at openjdk.org  Wed Dec  3 16:31:46 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 3 Dec 2025 16:31:46 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng [v2]
In-Reply-To: <uzYcrt5bymusemTsF9saI-K8-bqY9uLh9x4kL1n3usM=.881f1dca-3dc2-4562-8f98-3f4f4294b753@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
 <Rc6r29-tG6ngZpVQXBqX_LRXUsITAvl6pKhY8-jEdYI=.3b118d63-4eca-4e9b-8533-3b1a6e31103f@github.com>
 <uzYcrt5bymusemTsF9saI-K8-bqY9uLh9x4kL1n3usM=.881f1dca-3dc2-4562-8f98-3f4f4294b753@github.com>
Message-ID: <yurzs12r5Rt10yFxMoUqkMsNgUqPyWATOJ7joztU5Ho=.e5b80843-a743-47d1-bfb0-416aa0c6b824@github.com>

On Wed, 3 Dec 2025 15:58:28 GMT, Kurt Miller <kurt at openjdk.org> wrote:

>> make/modules/java.desktop/lib/ClientLibraries.gmk line 167:
>> 
>>> 165:   ifeq ($(USE_EXTERNAL_LIBPNG), false)
>>> 166:     LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
>>> 167:     LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
>> 
>> I think we can move these flags which are not specific to any OS/Architecture to src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h itself. But it should be handled in follow-up task not under this bug. Filed https://bugs.openjdk.org/browse/JDK-8372979 for the same.
>
> @jayathirthrao Thank you for the review.
> 
> The internal PNG defines are treated inconsistently. MMX is x86,  PNG_ARM is arm/aarch64 but they are not behind CpuArch conditionals while the others are behind OS + CpuArch conditionals. All of these defines appear to be well scoped and likely don't conflict with each other for internal png. I suspect they all can be defined without OS + CpuArch conditionals for the internal png case.

Thanks for the info. We need to make sure changing things in src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h doesn't break things and it also needs good amount of testing. So this will be taken up in follow-up task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28324#discussion_r2585814360

From prr at openjdk.org  Wed Dec  3 17:13:15 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 17:13:15 GMT
Subject: RFR: 8372977: unnecessary gthread-2.0 loading
In-Reply-To: <VmgorIq4lta0RwuCSPvX-q4Uxo98rJAlig_0Z0X5pX0=.1ca88596-a72f-4903-a1c5-ad14b5193230@github.com>
References: <VmgorIq4lta0RwuCSPvX-q4Uxo98rJAlig_0Z0X5pX0=.1ca88596-a72f-4903-a1c5-ad14b5193230@github.com>
Message-ID: <OcoRjADdH0MPCRKOBTmPsPn0GMGGcRe62xP3sd8yeLE=.b26ec069-ed66-4aa4-9190-a72360c416f0@github.com>

On Wed, 3 Dec 2025 05:15:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Actual usage of the gthread-2.0 was removed with GTK2 support in [JDK-8329471](https://bugs.openjdk.org/browse/JDK-8329471).
> But there are some leftovers, we are still loading it with GTK3, even though it was never used when it was added in [JDK-8164321](https://bugs.openjdk.org/browse/JDK-8164321).
> 
> It wasn't an issue before, but some modern systems (e.g. openSUSE 16) don't provide the library.
> Because of this, we are unable to load GTK, which leads to Robot functionality requiring the Screencast or Remote Desktop API on Wayland not working.

Marked as reviewed by prr (Reviewer).

I see that testing looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/28625#pullrequestreview-3536103006
PR Comment: https://git.openjdk.org/jdk/pull/28625#issuecomment-3607898920

From prr at openjdk.org  Wed Dec  3 18:23:52 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 18:23:52 GMT
Subject: RFR: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear [v2]
In-Reply-To: <84lpLmioVJac7JSDLsLWL_5biTsy2VxfNmZFehNc0E8=.894889dc-2a80-4c46-89cb-c14b14226d53@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
 <84lpLmioVJac7JSDLsLWL_5biTsy2VxfNmZFehNc0E8=.894889dc-2a80-4c46-89cb-c14b14226d53@github.com>
Message-ID: <NlWG5kp4s13hn6GQkCFkvJTZ8ga34_CEA0Bva_5yvNg=.91e7336e-dbcf-48a8-b945-9fc17dcd5e6a@github.com>

On Wed, 3 Dec 2025 01:35:14 GMT, Phil Race <prr at openjdk.org> wrote:

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

I had thought about "the largest" image but that would be limited by memory as well, so variable and difficult to explain.

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

PR Comment: https://git.openjdk.org/jdk/pull/27707#issuecomment-3608195693

From prr at openjdk.org  Wed Dec  3 18:23:54 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 18:23:54 GMT
Subject: Integrated: 4690476: NegativeArraySizeException from AffineTransformOp
 with shear
In-Reply-To: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
References: <SWkG8sjzpGBUmOLbfmhc8m8h01t62iTsS1dyjk3dnMw=.f423ae24-3909-4f27-b0b0-aa605f99a295@github.com>
Message-ID: <yKcaiJEHGkC8lK2KWlc3Zg05jPU2-XKCgaaUAvAuhRo=.7670e6e0-8b2f-4108-a801-07e4c3e838cf@github.com>

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

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

This pull request has now been integrated.

Changeset: aff25f13
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aff25f135af20ec89c7a68f2a0a0ede7eb1491a6
Stats:     141 lines in 2 files changed: 131 ins; 1 del; 9 mod

4690476: NegativeArraySizeException from AffineTransformOp with shear

Reviewed-by: psadhukhan, jdv

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

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

From erikj at openjdk.org  Wed Dec  3 18:31:28 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 Dec 2025 18:31:28 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng [v2]
In-Reply-To: <t3-4CAIOHBWnoYOrALBYMp18_ZFp5rUBXr1NxSYF_ks=.bec12af7-b6d0-432d-8d6b-e8452be82f4b@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
 <t3-4CAIOHBWnoYOrALBYMp18_ZFp5rUBXr1NxSYF_ks=.bec12af7-b6d0-432d-8d6b-e8452be82f4b@github.com>
Message-ID: <SXhgTjSooO2ZcivOHoM2zjKEpcF1KhbeY4jkTnYGFyg=.d0b79353-853b-4f3a-a8ef-c5dfd2c731fe@github.com>

On Wed, 3 Dec 2025 15:50:00 GMT, Kurt Miller <kurt at openjdk.org> wrote:

>> When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64:
>> 
>> `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]`
>> 
>> This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX.
>
> Kurt Miller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comment per code review

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28324#pullrequestreview-3536379873

From kizune at openjdk.org  Wed Dec  3 19:48:25 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 19:48:25 GMT
Subject: RFR: 8372977: unnecessary gthread-2.0 loading
In-Reply-To: <VmgorIq4lta0RwuCSPvX-q4Uxo98rJAlig_0Z0X5pX0=.1ca88596-a72f-4903-a1c5-ad14b5193230@github.com>
References: <VmgorIq4lta0RwuCSPvX-q4Uxo98rJAlig_0Z0X5pX0=.1ca88596-a72f-4903-a1c5-ad14b5193230@github.com>
Message-ID: <CAhC03tQu8AcTtCduL1nDz2jGNMdROgQfkNFbOTCfaM=.a90b0a38-9911-4bf0-93be-47acd8e68d73@github.com>

On Wed, 3 Dec 2025 05:15:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Actual usage of the gthread-2.0 was removed with GTK2 support in [JDK-8329471](https://bugs.openjdk.org/browse/JDK-8329471).
> But there are some leftovers, we are still loading it with GTK3, even though it was never used when it was added in [JDK-8164321](https://bugs.openjdk.org/browse/JDK-8164321).
> 
> It wasn't an issue before, but some modern systems (e.g. openSUSE 16) don't provide the library.
> Because of this, we are unable to load GTK, which leads to Robot functionality requiring the Screencast or Remote Desktop API on Wayland not working.

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28625#pullrequestreview-3536657795

From duke at openjdk.org  Wed Dec  3 19:49:27 2025
From: duke at openjdk.org (duke)
Date: Wed, 3 Dec 2025 19:49:27 GMT
Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors
 with external libpng [v2]
In-Reply-To: <t3-4CAIOHBWnoYOrALBYMp18_ZFp5rUBXr1NxSYF_ks=.bec12af7-b6d0-432d-8d6b-e8452be82f4b@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
 <t3-4CAIOHBWnoYOrALBYMp18_ZFp5rUBXr1NxSYF_ks=.bec12af7-b6d0-432d-8d6b-e8452be82f4b@github.com>
Message-ID: <8caBWJ6ftNIvDBwzAP8MbszLQ1t98qJ6Tmz8EktWrZQ=.9d08c9ea-e487-4d4a-b8dc-b76d660d3406@github.com>

On Wed, 3 Dec 2025 15:50:00 GMT, Kurt Miller <kurt at openjdk.org> wrote:

>> When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64:
>> 
>> `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]`
>> 
>> This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX.
>
> Kurt Miller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify comment per code review

@bsdkurt 
Your change (at version 50061a1d1a45ec56b9356eb78d93b6962cc43521) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28324#issuecomment-3608563317

From azvegint at openjdk.org  Wed Dec  3 20:06:39 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 3 Dec 2025 20:06:39 GMT
Subject: Integrated: 8372977: unnecessary gthread-2.0 loading
In-Reply-To: <VmgorIq4lta0RwuCSPvX-q4Uxo98rJAlig_0Z0X5pX0=.1ca88596-a72f-4903-a1c5-ad14b5193230@github.com>
References: <VmgorIq4lta0RwuCSPvX-q4Uxo98rJAlig_0Z0X5pX0=.1ca88596-a72f-4903-a1c5-ad14b5193230@github.com>
Message-ID: <HErE5L7J-WuUdQZ-H7cPdMknaHaeya4U3fkS4L8E848=.8c4a7d7c-272c-4e81-8176-8faa563fea53@github.com>

On Wed, 3 Dec 2025 05:15:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Actual usage of the gthread-2.0 was removed with GTK2 support in [JDK-8329471](https://bugs.openjdk.org/browse/JDK-8329471).
> But there are some leftovers, we are still loading it with GTK3, even though it was never used when it was added in [JDK-8164321](https://bugs.openjdk.org/browse/JDK-8164321).
> 
> It wasn't an issue before, but some modern systems (e.g. openSUSE 16) don't provide the library.
> Because of this, we are unable to load GTK, which leads to Robot functionality requiring the Screencast or Remote Desktop API on Wayland not working.

This pull request has now been integrated.

Changeset: 5ea2b640
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ea2b6402114d34465b2ad9e476ab8e36ddeea06
Stats:     27 lines in 2 files changed: 0 ins; 27 del; 0 mod

8372977: unnecessary gthread-2.0 loading

Reviewed-by: prr, kizune

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

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

From prr at openjdk.org  Wed Dec  3 20:12:13 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 20:12:13 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
Message-ID: <W5C23AIXNuuRATAWBRQbF91T2vSRM-vl5ttdc4iUfeU=.eb700386-dc06-4c7f-a0e7-9008de663009@github.com>

On Wed, 3 Dec 2025 00:04:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529
> 
>> Trying to click any mouse additional button raises an exception like the following:
>>
>> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
> java.lang.IllegalArgumentException: Nonexistent button 6
>         at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
>         at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
>         at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
>         at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> This changeset simply reverses the check, returning it to its original state.
> 
> The actual check for the supported mouse buttons for the robot is maintained here.
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214

Why was this change needed 6 months ago, but harmful now ?
I mean there must have been a reason for this specific part of that earlier change.

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

PR Comment: https://git.openjdk.org/jdk/pull/28621#issuecomment-3608639901

From azvegint at openjdk.org  Wed Dec  3 20:17:17 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 3 Dec 2025 20:17:17 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <W5C23AIXNuuRATAWBRQbF91T2vSRM-vl5ttdc4iUfeU=.eb700386-dc06-4c7f-a0e7-9008de663009@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
 <W5C23AIXNuuRATAWBRQbF91T2vSRM-vl5ttdc4iUfeU=.eb700386-dc06-4c7f-a0e7-9008de663009@github.com>
Message-ID: <MqE0s_PBBCv_IiWmykjjU2Mv7o2RFeeu45rpMx5-sOw=.6fb721bf-2253-4dec-8961-f1842cc7b1e2@github.com>

On Wed, 3 Dec 2025 20:09:16 GMT, Phil Race <prr at openjdk.org> wrote:

> Why was this change needed 6 months ago, but harmful now ? I mean there must have been a reason for this specific part of that earlier change.

It was my mistake to try to limit the number of buttons we can emulate with the robot. But this check was already in the robot itself.

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

PR Comment: https://git.openjdk.org/jdk/pull/28621#issuecomment-3608661608

From dnguyen at openjdk.org  Wed Dec  3 20:33:13 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 3 Dec 2025 20:33:13 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests
Message-ID: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>

There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.

This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.

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

Commit messages:
 - Initial commit

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

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

From thomas at devoogdt.com  Wed Dec  3 20:47:57 2025
From: thomas at devoogdt.com (Thomas Devoogdt)
Date: Wed, 3 Dec 2025 21:47:57 +0100
Subject: [OpenJDK][Headless] Allow compilation without X11
In-Reply-To: <CACXRmJgJpVkkYUpy3k1w+BxKUvcT7e=-NBOWctQL=MJj95oUpQ@mail.gmail.com>
References: <CACXRmJgkeuzLF_2URU9LsdVLRbuOdbGNEOFyPaMkD7EgLNh40A@mail.gmail.com>
 <CACXRmJgJpVkkYUpy3k1w+BxKUvcT7e=-NBOWctQL=MJj95oUpQ@mail.gmail.com>
Message-ID: <CACXRmJgvHAvAqyNyJWLuw6mdiVAqrmAar1iEu4Sd3O-qWmYyag@mail.gmail.com>

Hi,


Anyone out there?


Kind regards,

Thomas Devoogdt

Op wo 26 nov 2025, 10:39 schreef Thomas Devoogdt <thomas at devoogdt.com>:

> Hi all,
>
>
> I'm trying to compile OpenJDK in headless mode without the required
> X11 libraries.
> This becomes more common in embedded systems, where e.g. no head is used
> at all,
> or where e.g. only wayland is available.
>
> For this, I proposed a patch in buildroot, see
>
> https://patchwork.ozlabs.org/project/buildroot/patch/20251115154030.1746780-1-thomas at devoogdt.com/
> .
> Buildroots policy is to upstream any custom patch when applicable, for
> which I created
> https://github.com/openjdk/jdk/pull/28310.
>
> The first question, is there any interest to support compilation
> without X11 in headless mode?
> If yes, who can create a formal "issue" and pick this up as my "sponsor"?
>
> If this PR gets merged, is there any interest to backport this to the
> relevant LTS
> distributions? Buildroot ships JDK with the somewhat outdated versions
> 17 and 21?
>
>
> Kind regards,
>
> Thomas Devoogdt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251203/a6171b52/attachment-0001.htm>

From prr at openjdk.org  Wed Dec  3 20:50:10 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 20:50:10 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
Message-ID: <SUzFBqg4gTSOvofAJemvikQGZnzBvxjlqr9QRzHPS5M=.07310cbc-f9b0-4579-bc7c-366731d0bcc4@github.com>

On Wed, 3 Dec 2025 00:04:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529
> 
>> Trying to click any mouse additional button raises an exception like the following:
>>
>> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
> java.lang.IllegalArgumentException: Nonexistent button 6
>         at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
>         at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
>         at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
>         at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> This changeset simply reverses the check, returning it to its original state.
> 
> The actual check for the supported mouse buttons for the robot is maintained here.
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28621#pullrequestreview-3536867326

From dnguyen at openjdk.org  Wed Dec  3 20:55:25 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 3 Dec 2025 20:55:25 GMT
Subject: RFR: 8042054: JTree.updateUI uses out-of-date item size
 information [v2]
In-Reply-To: <EC58IbcGSq5qD_8oNBcaZ9b7ONdxr5Cb1Lwot4rqpNY=.5f3490bd-e2c6-41a5-aec7-6f18e1cf630d@github.com>
References: <cqrDtybBDmrqGYE3w6I_O4jaqEVacVc7mBpHtGWozRo=.9612cb00-b220-4490-b062-28b1159ff2be@github.com>
 <EC58IbcGSq5qD_8oNBcaZ9b7ONdxr5Cb1Lwot4rqpNY=.5f3490bd-e2c6-41a5-aec7-6f18e1cf630d@github.com>
Message-ID: <cr8cmtA43AWeWbrE00rCX00F9x4oEk5LdERvN6ooif4=.19a514cd-adbf-463b-85ce-b410a9d17e3a@github.com>

On Thu, 13 Nov 2025 05:22:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated.
>> Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. 
>> CI testing is ok..
>> 
>> Before fix
>> <img width="142" height="146" alt="image" src="https://github.com/user-attachments/assets/95d43e47-122a-4ca4-8a3f-f4bf5c1d3f43" />
>> 
>> After fix
>> <img width="145" height="125" alt="image" src="https://github.com/user-attachments/assets/068b5988-119c-4b99-be27-1ef5d52a28a2" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test formatting

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28258#pullrequestreview-3536885139

From kizune at openjdk.org  Wed Dec  3 21:05:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:05:11 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <3K1qH5GiIXsc2zagw7B17NprNpb5rUL5GIE_RnKWtQY=.0011d74d-4dc3-4ac7-bf7e-eae14f7c69bb@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <3K1qH5GiIXsc2zagw7B17NprNpb5rUL5GIE_RnKWtQY=.0011d74d-4dc3-4ac7-bf7e-eae14f7c69bb@github.com>
Message-ID: <u-4cshPwfgdE8hhW4d1eulynjZ2lWgTDkuz5zCs54o4=.d47f3e8a-8ffa-4c34-bcaf-27a36115a977@github.com>

On Wed, 3 Dec 2025 03:41:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Perform null check before requesting information for the popup component and return nil if component is no longer exists.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m line 71:
> 
>> 69:                                                              fAccessible, fComponent);
>> 70: 
>> 71:     if (axComponent == nil) {
> 
> Dont we need to call `CHECK_EXCEPTION()` as we were calling JNI?

Sure, adding check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28614#discussion_r2586601233

From kizune at openjdk.org  Wed Dec  3 21:09:50 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:09:50 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
Message-ID: <S2AQGYjmYXUDFwALQ1zLfEzhI5Uo1aheImHpv6UHU_Q=.bce4b7db-ea60-4ac6-9677-82ef998fd340@github.com>

On Tue, 2 Dec 2025 20:03:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Perform null check before requesting information for the popup component and return nil if component is no longer exists.

> Hello! JetBrains has actually proposed its own version of the fix, could you take a look please? #28599

Hi! The fix you are pointing to is marked as pending OCA approval. I know it is a technicality but i am bound by this technicality and can not even look at the code they propose before that mark is cleared - because if their fix differs and i modify my fix in the way that it will look as their fix - it means i'm borrowed code from not approved source. I know that fix that i am proposing works - i tested it with the scenario JetBrains suggested in the bug description. It crashes without the fix and it works with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28614#issuecomment-3608841680

From kizune at openjdk.org  Wed Dec  3 21:14:57 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:14:57 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311 [v2]
In-Reply-To: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
Message-ID: <X5u7zlknQfhrkF02AVKTlYION70h3ZvCIJB9WG__RoU=.c974ce9e-ac23-45a4-9933-5dad6981e610@github.com>

> Perform null check before requesting information for the popup component and return nil if component is no longer exists.

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

  Adding exception check after calling java method from native.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28614/files
  - new: https://git.openjdk.org/jdk/pull/28614/files/017547d2..b1434f51

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

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

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

From azvegint at openjdk.org  Wed Dec  3 21:36:56 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 3 Dec 2025 21:36:56 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311 [v2]
In-Reply-To: <X5u7zlknQfhrkF02AVKTlYION70h3ZvCIJB9WG__RoU=.c974ce9e-ac23-45a4-9933-5dad6981e610@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <X5u7zlknQfhrkF02AVKTlYION70h3ZvCIJB9WG__RoU=.c974ce9e-ac23-45a4-9933-5dad6981e610@github.com>
Message-ID: <Df8hebyiedxDjrz-kEvmQQVgzIG2niLbLq93100NWP4=.005e599c-364c-4a4a-aab9-374b26ac8d89@github.com>

On Wed, 3 Dec 2025 21:14:57 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Perform null check before requesting information for the popup component and return nil if component is no longer exists.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding exception check after calling java method from native.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28614#pullrequestreview-3537014131

From kizune at openjdk.org  Wed Dec  3 21:38:47 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:38:47 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v3]
In-Reply-To: <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
 <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>
Message-ID: <YO3v68h0PvD2pO5exO4ogTvE8z_kxnni5QNj1AxDqPs=.dadd9029-ab08-44b3-80dd-c5d6ab4e8a8f@github.com>

On Wed, 3 Dec 2025 10:56:24 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> **Analysis :** 
>> The issue is that on Win32, if the window is not active, we dont receive mouse events because we release the capture
>>  So the problem is the following:
>> We start selecting text from the right to the extreme left.
>> Then we switch to another window( the window lose focus ), and we release the mouse
>> But when we return to the window, the caret drag is still active and does not stop. as the window did not recieved the mouse release event
>> 
>> **Proposed fix:**
>> In the Caret class, we added a logic to ignore the drag if the focus was lost due to window switching unless a new mouse press happens
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The issue occurs only on Wnidows

test/jdk/javax/swing/JTextField/TextSelectionFocusLoss/TextSelectionFocusLoss.java line 72:

> 70:             robot.delay(500);
> 71: 
> 72:             Point location = textField.getLocationOnScreen();

These calls are still need to happen on EDT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28582#discussion_r2586688264

From kizune at openjdk.org  Wed Dec  3 21:40:38 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:40:38 GMT
Subject: RFR: 4459231: Focus of JTabbedPane(with Scrollable tablayout)
 changes on change in LookAndFeel [v2]
In-Reply-To: <fS4_Ed5-x7BXBAcq2sNWYr7ZacfIAE_fDtsJS-fqhfg=.1a062315-560f-4ab9-9b11-2d09290b27c5@github.com>
References: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
 <fS4_Ed5-x7BXBAcq2sNWYr7ZacfIAE_fDtsJS-fqhfg=.1a062315-560f-4ab9-9b11-2d09290b27c5@github.com>
Message-ID: <3abjy6k_oK2C4y0Eg_jwFT293N7_3tr0dpB0y0ZGmhs=.0f36b64d-b989-47a5-8a41-f47a17887b46@github.com>

On Mon, 1 Dec 2025 09:46:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On changing LookAndFeel of JTabbedPane, it resets the focus of the child tabs to starting child tab.
>> That is, if a JTabbedPane has say 10 tabs and we select the 10th tab and then we change the L&F, the focus is shifted to Tab0 even though the selected tab is still at 10th tab.
>> 
>> This is because when we switch L&F, `installUI ` will reset the `focusIndex ` 
>> https://github.com/openjdk/jdk/blob/3481252ced7c06c44154ceccc56b12cfd9a490c3/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L285-L290
>> 
>> which needs to set the proper focus by calling `scrollRectToVisible ` to selected tab which is done in this fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28571#pullrequestreview-3537030091

From kizune at openjdk.org  Wed Dec  3 21:43:25 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:43:25 GMT
Subject: RFR: 6223700: XP L&F: Non-TopLevel JMenu's painting error
In-Reply-To: <7szJgbTU8E_MWUDB2koWP4tDiP8nqiaYZ41cDrbRo3o=.9f3341d5-a9bb-48b8-8052-a706adfe7165@github.com>
References: <7szJgbTU8E_MWUDB2koWP4tDiP8nqiaYZ41cDrbRo3o=.9f3341d5-a9bb-48b8-8052-a706adfe7165@github.com>
Message-ID: <pK0xOImJm4sGvrEESlwY598avc6sxNNvmFy5pfs7G0I=.57b53f20-bd73-4749-878f-4bd509145ad0@github.com>

On Fri, 28 Nov 2025 08:50:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that non-TopLevel JMenu's get repainted when the mouse exits the item. If the popup menu is still visible to the right, repainting the JMenu causes the selection background to be repainted over the top of the popup, even though the popup is supposed to appear above the JMenu.
> 
> The problem is caused by the mouse handling code in the protected inner class `WindowsMenuUI.WindowsMouseInputHandler.` The `mouseEntered` and `mouseExited` handlers set the RollOver property and the JMenu gets repainted. However, setting the RollOver property is only necessary for top-level JMenus. Non-TopLevel JMenu menu items such as these get painted by the super class BasicMenuItemUI which uses isSelected() rather than isRollOver() to determine whether the selection background color should be used.
> 
> Fix is to use the repainting only for TopLevel Menu in `mouseExited`, the same way it is being done for `mouseEntered`

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28551#pullrequestreview-3537041554

From dnguyen at openjdk.org  Wed Dec  3 21:45:56 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 3 Dec 2025 21:45:56 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v2]
In-Reply-To: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
Message-ID: <EuGQl4L1yElxktIP8geV3BdgaAAMI2rX61nhtc9E8Ss=.7ed846f8-af61-4d6f-9891-6c0697172f33@github.com>

> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
> 
> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.

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

  Fix curly brace issue when moving code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28646/files
  - new: https://git.openjdk.org/jdk/pull/28646/files/865dc7a2..a493bce6

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

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

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

From kizune at openjdk.org  Wed Dec  3 21:46:21 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:46:21 GMT
Subject: RFR: 5107379: Component orientation in JOptionPane is not proper
 in Motif L&F.
In-Reply-To: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
References: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
Message-ID: <IcyFeO_u2MRVyVjISMzr9BkkgfGT0PKK4za8PY-Y8UU=.2f47992f-f181-4c03-bd38-ffc66a6914e8@github.com>

On Thu, 27 Nov 2025 12:32:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is icon in JOptionPane is not aligned as per the Component Orientation in Motif LookAndFeel.
> It seems only the buttons are aligned as per component orientation whereas the icon is not.
> 
> It is because the icon is drawn at "West" constraint whereas it should be drawn at beginning of line as done in BasicOptionPaneUI to ensure component orientation is honoured.

Looks reasonable.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28532#pullrequestreview-3537049552

From kizune at openjdk.org  Wed Dec  3 21:55:22 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 3 Dec 2025 21:55:22 GMT
Subject: RFR: 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: <s45JapMdZUgxvKPxO-SvjKZ5sglqzYDzponbTn9hgsU=.9ea6ea8b-517a-4f80-b3e5-b3ff01b778d5@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..

test/jdk/javax/swing/JTable/EditingJTableNotSerializable.java line 65:

> 63:                 tce.stopCellEditing();
> 64:                 System.out.println("Serializing non-editing JTable");
> 65:                 serialize(jt);

Can you please add the code that tries to deserialize the new object from the serialized form? Just to be sure that there is nothing that will be broken in the process of serialization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2586733195

From duke at openjdk.org  Wed Dec  3 22:50:57 2025
From: duke at openjdk.org (Dmitry Drobotov)
Date: Wed, 3 Dec 2025 22:50:57 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
Message-ID: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>

This PR fixes the crash that was happening if either `axComponent` or `currentElement` had null values, by returning `nil` early instead of doing null dereference. Additionally, I've added missing `CHECK_EXCEPTION()` after the JNI call and a clean-up of `axComponent` variable, but these 2 changes are unrelated to the crash.

#### More details about the crash
It reproduced in IntelliJ IDEA when using one of accessibility tools (such as VoiceOver, Voice Control, Zoom, Full Keyboard Access) and interacting with combo boxes that had popups based on `JPopupMenu`. The first interaction with the popup was good, but if there was a GC run before the next popup opening, it would crash on open.

What happened was that right before the crash, in `MenuAccessibility` at the point of calling 
``` 
jobject axComponent = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getCurrentAccessiblePopupMenu, fAccessible, fComponent); 

Both `fAccessible` and `fComponent` are not null. But on the Java side, in `CAccessibility.getCurrentAccessiblePopupMenu(Accessible a, Component c)`, `c` would be null. `fComponent` is created by `NewWeakGlobalRef`, so this scenario is possible. 

This results in `axComponent` being `NULL`, and then `currentElement` will also have `nil` value. 

After that, when calling `[CommonComponentAccessibility childrenOfParent:currentElement]`, in the line `if (parent->fAccessible == NULL) return nil;`, `parent` is `nil`, so it crashes.

Returning `nil` in `accessibilityChildren` is acceptable and would make VoiceOver say "menu (0 items)", but otherwise it will work with menu items normally.

There is another issue that we even end up in the state when `fComponent` peer is not updated after GC, or that `MenuAccessibility` is not recreated after that. But I haven't investigated that yet and not sure why exactly it happens. I believe for now it's good enough to add these checks on `accessibilityChildren` level.

#### Testing

I wasn't able to come up with a test case using simple Swing components that would capture this regression. It's very likely that the reason it was reproducing in IntelliJ was related to our custom components or other parts of our setup, and it's hard to pinpoint the specific cause. I did check `TestPopupMenuChildCount` and there were no changes to VoiceOver announcements. I also couldn't reproduce the crash in IntelliJ when using the OpenJDK build with the fix.

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

Commit messages:
 - 8372757: MacOS, Accessibility: Crash in [MenuAccessibility accessibilityChildren] after JDK-8341311

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

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

From duke at openjdk.org  Wed Dec  3 22:50:58 2025
From: duke at openjdk.org (Nikita Provotorov)
Date: Wed, 3 Dec 2025 22:50:58 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
References: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
Message-ID: <Ifp-IN88pEF_opG5tUN9GIbgFQu2P-euahzou7877iE=.1e76290c-bff4-4e91-827b-67d552b1e5ed@github.com>

On Tue, 2 Dec 2025 11:06:32 GMT, Dmitry Drobotov <duke at openjdk.org> wrote:

> This PR fixes the crash that was happening if either `axComponent` or `currentElement` had null values, by returning `nil` early instead of doing null dereference. Additionally, I've added missing `CHECK_EXCEPTION()` after the JNI call and a clean-up of `axComponent` variable, but these 2 changes are unrelated to the crash.
> 
> #### More details about the crash
> It reproduced in IntelliJ IDEA when using one of accessibility tools (such as VoiceOver, Voice Control, Zoom, Full Keyboard Access) and interacting with combo boxes that had popups based on `JPopupMenu`. The first interaction with the popup was good, but if there was a GC run before the next popup opening, it would crash on open.
> 
> What happened was that right before the crash, in `MenuAccessibility` at the point of calling 
> ``` 
> jobject axComponent = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getCurrentAccessiblePopupMenu, fAccessible, fComponent); 
> 
> Both `fAccessible` and `fComponent` are not null. But on the Java side, in `CAccessibility.getCurrentAccessiblePopupMenu(Accessible a, Component c)`, `c` would be null. `fComponent` is created by `NewWeakGlobalRef`, so this scenario is possible. 
> 
> This results in `axComponent` being `NULL`, and then `currentElement` will also have `nil` value. 
> 
> After that, when calling `[CommonComponentAccessibility childrenOfParent:currentElement]`, in the line `if (parent->fAccessible == NULL) return nil;`, `parent` is `nil`, so it crashes.
> 
> Returning `nil` in `accessibilityChildren` is acceptable and would make VoiceOver say "menu (0 items)", but otherwise it will work with menu items normally.
> 
> There is another issue that we even end up in the state when `fComponent` peer is not updated after GC, or that `MenuAccessibility` is not recreated after that. But I haven't investigated that yet and not sure why exactly it happens. I believe for now it's good enough to add these checks on `accessibilityChildren` level.
> 
> #### Testing
> 
> I wasn't able to come up with a test case using simple Swing components that would capture this regression. It's very likely that the reason it was reproducing in IntelliJ was related to our custom components or other parts of our setup, and it's hard to pinpoint the specific cause. I did check `TestPopupMenuChildCount` and there were no changes to VoiceOver announcements. I also couldn't reproduce the crash in IntelliJ when using the OpenJDK build with the fix.

Looks good in my opinion

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

Marked as reviewed by OnePatchGuy at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/28599#pullrequestreview-3529754915

From avu at openjdk.org  Wed Dec  3 22:50:59 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 3 Dec 2025 22:50:59 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
References: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
Message-ID: <BeukW9GURlVmpdWGyPYC0vpYvFZJEfYAthwPXEN69tc=.166ddf08-4f60-4aab-a786-8275931e572f@github.com>

On Tue, 2 Dec 2025 11:06:32 GMT, Dmitry Drobotov <duke at openjdk.org> wrote:

> This PR fixes the crash that was happening if either `axComponent` or `currentElement` had null values, by returning `nil` early instead of doing null dereference. Additionally, I've added missing `CHECK_EXCEPTION()` after the JNI call and a clean-up of `axComponent` variable, but these 2 changes are unrelated to the crash.
> 
> #### More details about the crash
> It reproduced in IntelliJ IDEA when using one of accessibility tools (such as VoiceOver, Voice Control, Zoom, Full Keyboard Access) and interacting with combo boxes that had popups based on `JPopupMenu`. The first interaction with the popup was good, but if there was a GC run before the next popup opening, it would crash on open.
> 
> What happened was that right before the crash, in `MenuAccessibility` at the point of calling 
> ``` 
> jobject axComponent = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getCurrentAccessiblePopupMenu, fAccessible, fComponent); 
> 
> Both `fAccessible` and `fComponent` are not null. But on the Java side, in `CAccessibility.getCurrentAccessiblePopupMenu(Accessible a, Component c)`, `c` would be null. `fComponent` is created by `NewWeakGlobalRef`, so this scenario is possible. 
> 
> This results in `axComponent` being `NULL`, and then `currentElement` will also have `nil` value. 
> 
> After that, when calling `[CommonComponentAccessibility childrenOfParent:currentElement]`, in the line `if (parent->fAccessible == NULL) return nil;`, `parent` is `nil`, so it crashes.
> 
> Returning `nil` in `accessibilityChildren` is acceptable and would make VoiceOver say "menu (0 items)", but otherwise it will work with menu items normally.
> 
> There is another issue that we even end up in the state when `fComponent` peer is not updated after GC, or that `MenuAccessibility` is not recreated after that. But I haven't investigated that yet and not sure why exactly it happens. I believe for now it's good enough to add these checks on `accessibilityChildren` level.
> 
> #### Testing
> 
> I wasn't able to come up with a test case using simple Swing components that would capture this regression. It's very likely that the reason it was reproducing in IntelliJ was related to our custom components or other parts of our setup, and it's hard to pinpoint the specific cause. I did check `TestPopupMenuChildCount` and there were no changes to VoiceOver announcements. I also couldn't reproduce the crash in IntelliJ when using the OpenJDK build with the fix.

LGTM

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

Marked as reviewed by avu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28599#pullrequestreview-3534705325

From prr at openjdk.org  Wed Dec  3 23:11:13 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 23:11:13 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException [v2]
In-Reply-To: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
Message-ID: <T8pXhE--4RUw4rBi5SxehCrT53LoNJpAf4UjVcc5fws=.be357c47-afd3-48ab-8708-9e6c37addf81@github.com>

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

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

  4617681

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27640/files
  - new: https://git.openjdk.org/jdk/pull/27640/files/8a3d18ee..7fb58b90

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

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

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

From prr at openjdk.org  Wed Dec  3 23:11:21 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 23:11:21 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException [v2]
In-Reply-To: <DCxcwDmeXC0h3thcOd_d6Tm7seK54lF6X5mPrqEmYTs=.a4e32b45-6e50-498f-9d89-31ae4fc3eb5b@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DCxcwDmeXC0h3thcOd_d6Tm7seK54lF6X5mPrqEmYTs=.a4e32b45-6e50-498f-9d89-31ae4fc3eb5b@github.com>
Message-ID: <s22L7eP_f_yc9PDDzW0a9cZtZaVC37--kaFxd91K9L0=.f0d309b4-42a8-4a0d-9cf0-c2e9f928bd9e@github.com>

On Wed, 26 Nov 2025 16:22:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4617681
>
> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 292:
> 
>> 290:      * image types.  The {@code ColorSpace} for the image is the
>> 291:      * default sRGB space.
>> 292:      * {@code BufferedImage} is a type that supports only one tile.
> 
> Suggestion:
> 
>     * default sRGB space.
>     * <p>
>     * {@code BufferedImage} is a type that supports only one tile.
> 
> To start a new paragraph? I think it would improve readability.

I did this but not on the line you suggested.

> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 297:
> 
>> 295:      * Java primitive arrays so the number of samples that can be
>> 296:      * stored are limited by the maximum size of a Java array.
>> 297:      * This is at most {@code Integer.MAX_VALUE}.
> 
> Shouldn't the sentence "This is at most?", be linked to the previous sentence with a comma. *This* refers to *the maximum size of a Java array*, it could be not as clear when these closely related sentences are split into two separate sentences.

I think this is OK as it is.

> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 299:
> 
>> 297:      * This is at most {@code Integer.MAX_VALUE}.
>> 298:      * The number of samples per-pixel for an {@code imageType} affect
>> 299:      * the maximum. For example if an image format uses bytes to store
> 
> Suggestion:
> 
>      * the maximum. For example, if an image format uses bytes to store
> 
> 
> A comma after ?for example?.

done

> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 303:
> 
>> 301:      * it will only be able to hold one fourth as many pixels as an image
>> 302:      * that uses an int to store all four samples.
>> 303:      * For example {@code TYPE_4BYTE_ABGR} may use 4 bytes to store a pixel
> 
> Suggestion:
> 
>      * For example, {@code TYPE_4BYTE_ABGR} may use 4 bytes to store a pixel

done

> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 307:
> 
>> 305:      * So the maximum number of pixels in a {@code BufferedImage} is
>> 306:      * format dependent.
>> 307:      * @param width     width of the created image
> 
> Suggestion:
> 
>      * format dependent.
>      *
>      * @param width     width of the created image
> 
> I'd add a blank line here to visually separate the description from the parameter list.

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2586890082
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2586890550
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2586890854
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2586891063
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2586891538

From prr at openjdk.org  Wed Dec  3 23:21:05 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 3 Dec 2025 23:21:05 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException [v2]
In-Reply-To: <fwNdozcqM0SPY3haxhA1QY5v2Mr-HtHbYC7_WETIcEU=.8cca2e94-3cff-4470-a448-6c01592ae5a7@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
 <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
 <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>
 <wMpTpnaJHLjU0uGkpJVezk7RzyOpHw00jEw4sjNuAwk=.b781b494-f0dd-47fc-963c-7d0ae8986b9e@github.com>
 <NePpLGkb2s4dS5QduAB1YxuN_r-aw7aXtj4R_cLdLa0=.a4acabec-c823-4133-a004-7b3312ba94f2@github.com>
 <USEIFtwOrc2HFrPENJlA_IjHYNG5i_y6R2-nU6mu8VU=.782491fc-69e6-4759-87c7-4933e6299add@github.com>
 <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@github.com>
 <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com>
 <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com>
 <N3Nmz5i24w3sym5e-1U_uISBNFG3RPfjq7Q
 tITrc7mM=.0d2f3a96-5636-4262-9379-7ede1f578ac9@github.com>
 <XnkZwiPmoXerE6aSdAwExYt7vB1BOEuSBiFA0zzfWYs=.10a51f8f-98a2-48a5-a718-67e63f401db2@github.com>
 <jeyZbBeDympQWrQjFb-4QSfZbROEepCWHB6apO1jeNA=.8cc70ea9-7d25-4b70-bf0f-a67d23edbee2@github.com>
 <HDPrpGjSgy5nLVB3vvvNXIGY-nH10XU49y6CuEWY_bo=.b48b6a3d-fb05-4225-995a-139d2828c86d@github.com>
 <fwNdozcqM0SPY3haxhA1QY5v2Mr-HtHbYC7_WETIcEU=.8cca2e94-3cff-4470-a448-6c01592ae5a7@github.com>
Message-ID: <hbniIitNtT9Iy5Pu6mc-9w247HYwoCxE_Tqm8JwDcI0=.3e503284-0c2d-49cb-816a-8c0e8e871d1d@github.com>

On Mon, 24 Nov 2025 22:50:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The spec update in question only applies to the pre-defined types.
>> I see no circumstance in which we'd ever modify the implementation of these.
>> 
>> I actually tried this (meaning BandedSampleModel) months ago now, for the 3BYTE_BGR case which is the one of those  with the biggest current constraint. ie. I changed the implementation of that case and found that printing, Image I/O and IIRC at least one
>> other thing I can't remember now assumed the current implementation.
>> They'd need to be re-worked first. I don't see this ever happening.
>> If internal code makes assumption, external code likely does too.
>> 
>> If we did add a new pre-defined type that can exceed these limits because it used a banded raster, then as part
>> of adding that, updating the spec for this case would be part of that. And that could never be backported anyway.
>
>> If we did add a new pre-defined type that can exceed these limits because it used a banded r
> 
> I agree with this. It will be hard to reimplement, but maybe we can still hint that this behavior depends on the implementation rather than specifying it strictly in the documentation?

It does not say that something like TYPE_4_BYTE_ABGR absolutely cannot use bands.
It just points out that if you use a smaller data buffer type you can store less data *in a DataBuffer* than with a larger one,
with the end result being more of a limitation on the image size.

This result just scales with the number of bands used.

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

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

From serb at openjdk.org  Thu Dec  4 00:45:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 4 Dec 2025 00:45:01 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <S2AQGYjmYXUDFwALQ1zLfEzhI5Uo1aheImHpv6UHU_Q=.bce4b7db-ea60-4ac6-9677-82ef998fd340@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <S2AQGYjmYXUDFwALQ1zLfEzhI5Uo1aheImHpv6UHU_Q=.bce4b7db-ea60-4ac6-9677-82ef998fd340@github.com>
Message-ID: <TojQ0Eg1enfyyTHQ9fhStf_ZSHRD-1nVwFsI7YJRG9A=.eab048ac-9262-44b5-9fb2-5b9def6181b1@github.com>

On Wed, 3 Dec 2025 21:07:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>Hi! The fix you are pointing to is marked as pending OCA approval.

The oca tag is deleted from that PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28614#issuecomment-3609419555

From serb at openjdk.org  Thu Dec  4 00:58:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 4 Dec 2025 00:58:56 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException [v2]
In-Reply-To: <hbniIitNtT9Iy5Pu6mc-9w247HYwoCxE_Tqm8JwDcI0=.3e503284-0c2d-49cb-816a-8c0e8e871d1d@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DC7eFeLflBv14pBhbvkDIi5vin4zy1ttGxZ1exgB_rA=.bb31e390-7fe4-4383-89b9-b2e9e9b9c5e4@github.com>
 <szKMY2pDhqcPmdW0pzHvbaPG4PAXpiROhuYLQRg5doQ=.21b46e4b-b44b-40f5-8e8a-dbe790a1882f@github.com>
 <wsbqtlqyKUnM4DQYhzeZf14db-MGb8_xozT8g-N8eZ8=.2d59f7fb-579a-48a6-864e-5669978fee60@github.com>
 <wMpTpnaJHLjU0uGkpJVezk7RzyOpHw00jEw4sjNuAwk=.b781b494-f0dd-47fc-963c-7d0ae8986b9e@github.com>
 <NePpLGkb2s4dS5QduAB1YxuN_r-aw7aXtj4R_cLdLa0=.a4acabec-c823-4133-a004-7b3312ba94f2@github.com>
 <USEIFtwOrc2HFrPENJlA_IjHYNG5i_y6R2-nU6mu8VU=.782491fc-69e6-4759-87c7-4933e6299add@github.com>
 <oLH8yl_O-yFPRTBQR8jwBqWL6OVsVTZUMpU2JVwYbgc=.3e355056-8cf4-43f1-bebd-3e99a3460cfe@github.com>
 <3_us2zAmdVS-gGC-7urjNFd3nOxDsl5n-3aAxli9kn0=.f6460486-5438-41f4-bafe-6d96254f30a8@github.com>
 <2ixIN5XwoxTtCHsXs5w6o2cxjjsCRoaFuVmBfbq0bkg=.81ad927c-0cc4-4810-af04-85114d960ba5@github.com>
 <N3Nmz5i24w3sym5e-1U_uISBNFG3RPfjq7Q
 tITrc7mM=.0d2f3a96-5636-4262-9379-7ede1f578ac9@github.com>
 <XnkZwiPmoXerE6aSdAwExYt7vB1BOEuSBiFA0zzfWYs=.10a51f8f-98a2-48a5-a718-67e63f401db2@github.com>
 <jeyZbBeDympQWrQjFb-4QSfZbROEepCWHB6apO1jeNA=.8cc70ea9-7d25-4b70-bf0f-a67d23edbee2@github.com>
 <HDPrpGjSgy5nLVB3vvvNXIGY-nH10XU49y6CuEWY_bo=.b48b6a3d-fb05-4225-995a-139d2828c86d@github.com>
 <fwNdozcqM0SPY3haxhA1QY5v2Mr-HtHbYC7_WETIcEU=.8cca2e94-3cff-4470-a448-6c01592ae5a7@github.com>
 <hbniIitNtT9Iy5Pu6mc-9w247HYwoCxE_Tqm8JwDcI0=.3e503284-0c2d-49cb-816a-8c0e8e871d1d@github.com>
Message-ID: <Nr7UMZ3GglCS1GVzXRurlzdR8XCgCwaMqrOliYjQKFA=.3f03cf5e-f113-4552-88cc-b3abedbb98cf@github.com>

On Wed, 3 Dec 2025 23:18:39 GMT, Phil Race <prr at openjdk.org> wrote:

>It does not say that something like TYPE_4_BYTE_ABGR absolutely cannot use bands.
>It just points out that if you use a smaller data buffer type you can store less data in a DataBuffer than with a larger one,

But it does not account for the possibility of splitting the image across bands not-by-sample, but-per-parts-of-the image. The DataBuffer specification allows this, but the new specification introduced by this patch documents the internal implementation and blocks that possibility.

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

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

From psadhukhan at openjdk.org  Thu Dec  4 01:56:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Dec 2025 01:56:59 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <s45JapMdZUgxvKPxO-SvjKZ5sglqzYDzponbTn9hgsU=.9ea6ea8b-517a-4f80-b3e5-b3ff01b778d5@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <s45JapMdZUgxvKPxO-SvjKZ5sglqzYDzponbTn9hgsU=.9ea6ea8b-517a-4f80-b3e5-b3ff01b778d5@github.com>
Message-ID: <eiS9tZjE3eUp_gT_OJFevjizwj9JID1hPGDbDnDvWcg=.c2b4e907-0e98-43d8-9718-59cdd9dad917@github.com>

On Wed, 3 Dec 2025 21:53:06 GMT, Alexander Zuev <kizune 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..
>
> test/jdk/javax/swing/JTable/EditingJTableNotSerializable.java line 65:
> 
>> 63:                 tce.stopCellEditing();
>> 64:                 System.out.println("Serializing non-editing JTable");
>> 65:                 serialize(jt);
> 
> Can you please add the code that tries to deserialize the new object from the serialized form? Just to be sure that there is nothing that will be broken in the process of serialization.

The test does that too deserialize after serialize in `serialize` method...actually the method is a misnomer but I kept it as it is from reproducer..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2587154103

From psadhukhan at openjdk.org  Thu Dec  4 02:11:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Dec 2025 02:11:56 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311 [v2]
In-Reply-To: <X5u7zlknQfhrkF02AVKTlYION70h3ZvCIJB9WG__RoU=.c974ce9e-ac23-45a4-9933-5dad6981e610@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <X5u7zlknQfhrkF02AVKTlYION70h3ZvCIJB9WG__RoU=.c974ce9e-ac23-45a4-9933-5dad6981e610@github.com>
Message-ID: <xxWHKi4tuQoJoa0idfaJCwlBOCTQseYGnfPrarJmacM=.4e7187db-e546-4ba1-b9e4-32007c96cfbf@github.com>

On Wed, 3 Dec 2025 21:14:57 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Perform null check before requesting information for the popup component and return nil if component is no longer exists.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding exception check after calling java method from native.

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28614#pullrequestreview-3537609019

From psadhukhan at openjdk.org  Thu Dec  4 02:11:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Dec 2025 02:11:58 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311 [v2]
In-Reply-To: <u-4cshPwfgdE8hhW4d1eulynjZ2lWgTDkuz5zCs54o4=.d47f3e8a-8ffa-4c34-bcaf-27a36115a977@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <3K1qH5GiIXsc2zagw7B17NprNpb5rUL5GIE_RnKWtQY=.0011d74d-4dc3-4ac7-bf7e-eae14f7c69bb@github.com>
 <u-4cshPwfgdE8hhW4d1eulynjZ2lWgTDkuz5zCs54o4=.d47f3e8a-8ffa-4c34-bcaf-27a36115a977@github.com>
Message-ID: <JQhtwj13eHd7AjEogEo-PANz00jtvT6SdZmVRL3gpbU=.17311956-6c97-41ee-8c1d-713f2c7af859@github.com>

On Wed, 3 Dec 2025 21:02:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m line 71:
>> 
>>> 69:                                                              fAccessible, fComponent);
>>> 70: 
>>> 71:     if (axComponent == nil) {
>> 
>> Dont we need to call `CHECK_EXCEPTION()` as we were calling JNI?
>
> Sure, adding check.

I might be wrong as CAccessibility already catches the exception it seems but no harm checking I guess

https://github.com/openjdk/jdk/blob/04c0f8d359a3f450ac2070c6d41834145d9c75f7/src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java#L131-L136

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28614#discussion_r2587182186

From azvegint at openjdk.org  Thu Dec  4 02:19:07 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 4 Dec 2025 02:19:07 GMT
Subject: Integrated: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
Message-ID: <4EeuQmj8TXKbFNYKpxaX_b8Fz7OhyPlK7pl-6yYC9qU=.26e2166c-cc57-4b76-be70-eea5393ccd00@github.com>

On Wed, 3 Dec 2025 00:04:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529
> 
>> Trying to click any mouse additional button raises an exception like the following:
>>
>> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
> java.lang.IllegalArgumentException: Nonexistent button 6
>         at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
>         at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
>         at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
>         at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> This changeset simply reverses the check, returning it to its original state.
> 
> The actual check for the supported mouse buttons for the robot is maintained here.
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214

This pull request has now been integrated.

Changeset: db2cd1a4
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db2cd1a4e0ee7b72339e7ee3c0286dc04fc5adbf
Stats:     23 lines in 1 file changed: 7 ins; 14 del; 2 mod

8372756: Mouse additional buttons and horizontal scrolling are broken on XWayland GNOME >= 47 after JDK-8351907

Reviewed-by: prr

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

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

From kizune at openjdk.org  Thu Dec  4 03:08:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 4 Dec 2025 03:08:56 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <TojQ0Eg1enfyyTHQ9fhStf_ZSHRD-1nVwFsI7YJRG9A=.eab048ac-9262-44b5-9fb2-5b9def6181b1@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <S2AQGYjmYXUDFwALQ1zLfEzhI5Uo1aheImHpv6UHU_Q=.bce4b7db-ea60-4ac6-9677-82ef998fd340@github.com>
 <TojQ0Eg1enfyyTHQ9fhStf_ZSHRD-1nVwFsI7YJRG9A=.eab048ac-9262-44b5-9fb2-5b9def6181b1@github.com>
Message-ID: <V10_mgIuF4wKwC4v3yRh6ATAPemTBO2qWYGbSIxyAO4=.6e3ddb4a-cf1b-4c19-8682-fa57abf06083@github.com>

On Thu, 4 Dec 2025 00:42:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Hi! The fix you are pointing to is marked as pending OCA approval.
> 
> The oca tag is deleted from that PR.

I see. The difference is not substantial (the second check is not required since passing nil will not break the logic - we will return nil anyways just a bit later and releasing of the java object in my testing caused crash by itself in quick repeated invocations of popup without closing previous popup) so i'm going to integrate the fix. And since we both came to pretty much the same fix i will add cret=dit to this PR for the author of JetBrains version of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/28614#issuecomment-3609840459

From kizune at openjdk.org  Thu Dec  4 03:26:08 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 4 Dec 2025 03:26:08 GMT
Subject: Integrated: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
Message-ID: <ABei4eVOQ8zDyG59asmVCo_SH-151Qs5NZ0TZVHBpIY=.1a361c54-41a4-470f-b196-69ef1df4c352@github.com>

On Tue, 2 Dec 2025 20:03:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Perform null check before requesting information for the popup component and return nil if component is no longer exists.

This pull request has now been integrated.

Changeset: 019df4d8
Author:    Dmitry Drobotov <dmitry.drobotov at jetbrains.com>
Committer: Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/019df4d89c8a0fe2b27c6ec074499445ae45bc3f
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8372757: MacOS, Accessibility: Crash in [MenuAccessibility accessibilityChildren] after JDK-8341311

Reviewed-by: azvegint, psadhukhan

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

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

From psadhukhan at openjdk.org  Thu Dec  4 05:23:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Dec 2025 05:23:59 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v3]
In-Reply-To: <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
 <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>
Message-ID: <O7KO8J7KCiCYi-fhN5hRwed9xx3cnNj0OZTo1aI3lhc=.3eb9c232-4366-4adc-a5af-ac4d693c61b3@github.com>

On Wed, 3 Dec 2025 10:56:24 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> **Analysis :** 
>> The issue is that on Win32, if the window is not active, we dont receive mouse events because we release the capture
>>  So the problem is the following:
>> We start selecting text from the right to the extreme left.
>> Then we switch to another window( the window lose focus ), and we release the mouse
>> But when we return to the window, the caret drag is still active and does not stop. as the window did not recieved the mouse release event
>> 
>> **Proposed fix:**
>> In the Caret class, we added a logic to ignore the drag if the focus was lost due to window switching unless a new mouse press happens
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The issue occurs only on Wnidows

src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 551:

> 549:         if (SwingUtilities.isLeftMouseButton(e)) {
> 550:             lastClickMillis = e.getWhen();
> 551:             dragActive = true;

should we set `dragActive ` here? it's just mousePressed, in which case all mousePress event will have dragActive set.
I guess it should be set in `mouseDragged` and reset in `mouseReleased`, no?

test/jdk/javax/swing/JTextField/TextSelectionFocusLoss/TextSelectionFocusLoss.java line 38:

> 36:  * @test
> 37:  * @key headful
> 38:  * @requires (os.family == "windows")

even if it happens only on windows, since this is automated test, no point restricting for other platforms where it should pass automatically...atleast it will catch any regression in future if it happens otherwise later..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28582#discussion_r2587602822
PR Review Comment: https://git.openjdk.org/jdk/pull/28582#discussion_r2587602126

From kizune at openjdk.org  Thu Dec  4 10:04:00 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 4 Dec 2025 10:04:00 GMT
Subject: RFR: 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: <DaLlhpFlmGHSgtmkwJPY3MoPkf2IkX2tbRDvYgZnFMY=.2616db2f-b48d-428e-8bf2-37b1679ba02c@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..

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28627#pullrequestreview-3539076832

From kizune at openjdk.org  Thu Dec  4 10:04:03 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 4 Dec 2025 10:04:03 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <eiS9tZjE3eUp_gT_OJFevjizwj9JID1hPGDbDnDvWcg=.c2b4e907-0e98-43d8-9718-59cdd9dad917@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <s45JapMdZUgxvKPxO-SvjKZ5sglqzYDzponbTn9hgsU=.9ea6ea8b-517a-4f80-b3e5-b3ff01b778d5@github.com>
 <eiS9tZjE3eUp_gT_OJFevjizwj9JID1hPGDbDnDvWcg=.c2b4e907-0e98-43d8-9718-59cdd9dad917@github.com>
Message-ID: <xJkoffGMt9q92GLS8yNLTEsQ8WkL9Im-5pxsIBBg0BM=.8702b29b-778a-4efd-b756-2184bcb6f3ed@github.com>

On Thu, 4 Dec 2025 01:54:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JTable/EditingJTableNotSerializable.java line 65:
>> 
>>> 63:                 tce.stopCellEditing();
>>> 64:                 System.out.println("Serializing non-editing JTable");
>>> 65:                 serialize(jt);
>> 
>> Can you please add the code that tries to deserialize the new object from the serialized form? Just to be sure that there is nothing that will be broken in the process of serialization.
>
> The test does that too deserialize after serialize in `serialize` method...actually the method is a misnomer but I kept it as it is from reproducer..

Ah, ok, i missed that instruction. Looks good then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2588346879

From duke at openjdk.org  Thu Dec  4 11:38:09 2025
From: duke at openjdk.org (Nikita Provotorov)
Date: Thu, 4 Dec 2025 11:38:09 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311 [v2]
In-Reply-To: <X5u7zlknQfhrkF02AVKTlYION70h3ZvCIJB9WG__RoU=.c974ce9e-ac23-45a4-9933-5dad6981e610@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <X5u7zlknQfhrkF02AVKTlYION70h3ZvCIJB9WG__RoU=.c974ce9e-ac23-45a4-9933-5dad6981e610@github.com>
Message-ID: <L1421o2D9sm82kc-W9MmoLdouyBU7cjiSTWH3cd18a4=.232d12ea-c38b-4334-a466-f14d3b1dc4af@github.com>

On Wed, 3 Dec 2025 21:14:57 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Perform null check before requesting information for the popup component and return nil if component is no longer exists.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding exception check after calling java method from native.

Hello! https://github.com/openjdk/jdk/pull/28599 also had `DeleteLocalRef`, shouldn't it have been added as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/28614#issuecomment-3611725948

From duke at openjdk.org  Thu Dec  4 12:00:14 2025
From: duke at openjdk.org (Nikita Provotorov)
Date: Thu, 4 Dec 2025 12:00:14 GMT
Subject: RFR: 8372756: Mouse additional buttons and horizontal scrolling
 are broken on XWayland GNOME >= 47 after JDK-8351907
In-Reply-To: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
References: <xy6kPPtC1r-Y4Mn29zCAJRKUJ2MECm7by01lwbUAkwE=.1bae0a17-00df-41b7-9999-6bd4b7c159b5@github.com>
Message-ID: <bz7pE2CkYkEye3SxnYpXa4D1kHWZFBTsiv4IYUyG1h8=.d008c863-656f-4d72-a941-6b6b1e83cbe3@github.com>

On Wed, 3 Dec 2025 00:04:43 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The #25265 change introduced an artificial restriction that is actually unnecessary and harmful:
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java#L1526-L1529
> 
>> Trying to click any mouse additional button raises an exception like the following:
>>
>> WARN - sun.awt.X11.XToolkit - Exception on Toolkit thread
> java.lang.IllegalArgumentException: Nonexistent button 6
>         at java.desktop/java.awt.event.MouseEvent.<init>(MouseEvent.java:774)
>         at java.desktop/sun.awt.X11.XWindow.handleButtonPressRelease(XWindow.java:765)
>         at java.desktop/sun.awt.X11.XContentWindow.handleButtonPressRelease(XContentWindow.java:45)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1206)
>         at java.desktop/sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1178)
>         at java.desktop/sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:939)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:1086)
>         at java.desktop/sun.awt.X11.XToolkit.run(XToolkit.java:968)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> This changeset simply reverses the check, returning it to its original state.
> 
> The actual check for the supported mouse buttons for the robot is maintained here.
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L367-L371
> 
> https://github.com/openjdk/jdk/blob/f5e4cd7f0d12fd21399b192b32a5c9abfe8a3564/src/java.desktop/share/classes/java/awt/Robot.java#L208-L214

Can you please backport it to all branches where 8351907 is present?

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

PR Comment: https://git.openjdk.org/jdk/pull/28621#issuecomment-3611842693

From duke at openjdk.org  Thu Dec  4 12:30:01 2025
From: duke at openjdk.org (Dmitry Drobotov)
Date: Thu, 4 Dec 2025 12:30:01 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <V10_mgIuF4wKwC4v3yRh6ATAPemTBO2qWYGbSIxyAO4=.6e3ddb4a-cf1b-4c19-8682-fa57abf06083@github.com>
References: <c3Ooajf5E_uRw-tOjnNG8pZv2qTuKSU62xjUoCP3rpw=.affa1b9c-4f2a-468c-a6cb-4ae0d05e9cf6@github.com>
 <S2AQGYjmYXUDFwALQ1zLfEzhI5Uo1aheImHpv6UHU_Q=.bce4b7db-ea60-4ac6-9677-82ef998fd340@github.com>
 <TojQ0Eg1enfyyTHQ9fhStf_ZSHRD-1nVwFsI7YJRG9A=.eab048ac-9262-44b5-9fb2-5b9def6181b1@github.com>
 <V10_mgIuF4wKwC4v3yRh6ATAPemTBO2qWYGbSIxyAO4=.6e3ddb4a-cf1b-4c19-8682-fa57abf06083@github.com>
Message-ID: <KDp-hW-HSszQA1u0u0LfriESXz-nafA5Wn4PibbtnAc=.70769c0f-94ba-42c5-a63e-c4467ee45b73@github.com>

On Thu, 4 Dec 2025 03:05:48 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>>>Hi! The fix you are pointing to is marked as pending OCA approval.
>> 
>> The oca tag is deleted from that PR.
>
>> > Hi! The fix you are pointing to is marked as pending OCA approval.
>> 
>> The oca tag is deleted from that PR.
> 
> I see. The difference is not substantial (the second check is not required since passing nil will not break the logic - we will return nil anyways just a bit later and releasing of the java object in my testing caused crash by itself in quick repeated invocations of popup without closing previous popup) so i'm going to integrate the fix. And since we both came to pretty much the same fix i will add credit to this PR for the author of JetBrains version of the fix.

Thanks @azuev-java. I can clarify that I had the second check

    if (currentElement == nil) {
        return nil;
    }

because `nil` is one of the possible return values of `[CommonComponentAccessibility createWithAccessible...]`. Even though normally it shouldn't be returned there, I wanted to be safe for any possible edge cases. 

Regarding the crash with `DeleteLocalRef`, could you please elaborate on that? What was the crash stack trace? I can't reproduce it myself, and by reading the code I don't see how deleting the reference to `axComponent` could affect anything outside `accessibilityChildren`. From what I understand, all calls to `accessibilityChildren` will be sequential on the same AppKit thread, so I'm also not sure how having multiple instances of popups could affect it.

But indeed it's enough to only add the check for `axComponent == nil` to prevent the crash, so the main issue is fixed, and these are less important points.

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

PR Comment: https://git.openjdk.org/jdk/pull/28614#issuecomment-3611999493

From asemenov at openjdk.org  Thu Dec  4 12:34:43 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 4 Dec 2025 12:34:43 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
References: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
Message-ID: <EGUvJUMk1gYmw8MJaTkregR30J6KVKN5pJJHt3wC5R4=.e0738969-925d-402a-bf84-62a5e9a2664f@github.com>

On Tue, 2 Dec 2025 11:06:32 GMT, Dmitry Drobotov <duke at openjdk.org> wrote:

> This PR fixes the crash that was happening if either `axComponent` or `currentElement` had null values, by returning `nil` early instead of doing null dereference. Additionally, I've added missing `CHECK_EXCEPTION()` after the JNI call and a clean-up of `axComponent` variable, but these 2 changes are unrelated to the crash.
> 
> #### More details about the crash
> It reproduced in IntelliJ IDEA when using one of accessibility tools (such as VoiceOver, Voice Control, Zoom, Full Keyboard Access) and interacting with combo boxes that had popups based on `JPopupMenu`. The first interaction with the popup was good, but if there was a GC run before the next popup opening, it would crash on open.
> 
> What happened was that right before the crash, in `MenuAccessibility` at the point of calling 
> ``` 
> jobject axComponent = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getCurrentAccessiblePopupMenu, fAccessible, fComponent); 
> 
> Both `fAccessible` and `fComponent` are not null. But on the Java side, in `CAccessibility.getCurrentAccessiblePopupMenu(Accessible a, Component c)`, `c` would be null. `fComponent` is created by `NewWeakGlobalRef`, so this scenario is possible. 
> 
> This results in `axComponent` being `NULL`, and then `currentElement` will also have `nil` value. 
> 
> After that, when calling `[CommonComponentAccessibility childrenOfParent:currentElement]`, in the line `if (parent->fAccessible == NULL) return nil;`, `parent` is `nil`, so it crashes.
> 
> Returning `nil` in `accessibilityChildren` is acceptable and would make VoiceOver say "menu (0 items)", but otherwise it will work with menu items normally.
> 
> There is another issue that we even end up in the state when `fComponent` peer is not updated after GC, or that `MenuAccessibility` is not recreated after that. But I haven't investigated that yet and not sure why exactly it happens. I believe for now it's good enough to add these checks on `accessibilityChildren` level.
> 
> #### Testing
> 
> I wasn't able to come up with a test case using simple Swing components that would capture this regression. It's very likely that the reason it was reproducing in IntelliJ was related to our custom components or other parts of our setup, and it's hard to pinpoint the specific cause. I did check `TestPopupMenuChildCount` and there were no changes to VoiceOver announcements. I also couldn't reproduce the crash in IntelliJ when using the OpenJDK build with the fix.

LGTM

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

Marked as reviewed by asemenov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28599#pullrequestreview-3539790332

From duke at openjdk.org  Thu Dec  4 12:38:47 2025
From: duke at openjdk.org (Dmitry Drobotov)
Date: Thu, 4 Dec 2025 12:38:47 GMT
Subject: RFR: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
References: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
Message-ID: <pMAuNBSjT1Wpy8bOvX22r1HOoMEhYu1s7nBasiz9Ovw=.8edd44c7-8325-4edc-a5fa-bf1a59b95225@github.com>

On Tue, 2 Dec 2025 11:06:32 GMT, Dmitry Drobotov <duke at openjdk.org> wrote:

> This PR fixes the crash that was happening if either `axComponent` or `currentElement` had null values, by returning `nil` early instead of doing null dereference. Additionally, I've added missing `CHECK_EXCEPTION()` after the JNI call and a clean-up of `axComponent` variable, but these 2 changes are unrelated to the crash.
> 
> #### More details about the crash
> It reproduced in IntelliJ IDEA when using one of accessibility tools (such as VoiceOver, Voice Control, Zoom, Full Keyboard Access) and interacting with combo boxes that had popups based on `JPopupMenu`. The first interaction with the popup was good, but if there was a GC run before the next popup opening, it would crash on open.
> 
> What happened was that right before the crash, in `MenuAccessibility` at the point of calling 
> ``` 
> jobject axComponent = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getCurrentAccessiblePopupMenu, fAccessible, fComponent); 
> 
> Both `fAccessible` and `fComponent` are not null. But on the Java side, in `CAccessibility.getCurrentAccessiblePopupMenu(Accessible a, Component c)`, `c` would be null. `fComponent` is created by `NewWeakGlobalRef`, so this scenario is possible. 
> 
> This results in `axComponent` being `NULL`, and then `currentElement` will also have `nil` value. 
> 
> After that, when calling `[CommonComponentAccessibility childrenOfParent:currentElement]`, in the line `if (parent->fAccessible == NULL) return nil;`, `parent` is `nil`, so it crashes.
> 
> Returning `nil` in `accessibilityChildren` is acceptable and would make VoiceOver say "menu (0 items)", but otherwise it will work with menu items normally.
> 
> There is another issue that we even end up in the state when `fComponent` peer is not updated after GC, or that `MenuAccessibility` is not recreated after that. But I haven't investigated that yet and not sure why exactly it happens. I believe for now it's good enough to add these checks on `accessibilityChildren` level.
> 
> #### Testing
> 
> I wasn't able to come up with a test case using simple Swing components that would capture this regression. It's very likely that the reason it was reproducing in IntelliJ was related to our custom components or other parts of our setup, and it's hard to pinpoint the specific cause. I did check `TestPopupMenuChildCount` and there were no changes to VoiceOver announcements. I also couldn't reproduce the crash in IntelliJ when using the OpenJDK build with the fix.

Closing in favor of #28614, which is already integrated. If there will be follow-ups I think they can be done in separate PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/28599#issuecomment-3612042302

From duke at openjdk.org  Thu Dec  4 12:38:48 2025
From: duke at openjdk.org (Dmitry Drobotov)
Date: Thu, 4 Dec 2025 12:38:48 GMT
Subject: Withdrawn: 8372757: MacOS, Accessibility: Crash in [MenuAccessibility
 accessibilityChildren] after JDK-8341311
In-Reply-To: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
References: <LCcqgXzq7XK4yAaS9nt_5k_jwnBVJYg9zinYs7mmeG8=.e7f246b2-cb0d-4d45-8307-7c9023cd68a1@github.com>
Message-ID: <y_bdkczwf6bDGTcYqXZAolBKsylAKVpO9Mw5rqaP4K8=.5b984adb-fe0b-4147-ae70-02a1a521898e@github.com>

On Tue, 2 Dec 2025 11:06:32 GMT, Dmitry Drobotov <duke at openjdk.org> wrote:

> This PR fixes the crash that was happening if either `axComponent` or `currentElement` had null values, by returning `nil` early instead of doing null dereference. Additionally, I've added missing `CHECK_EXCEPTION()` after the JNI call and a clean-up of `axComponent` variable, but these 2 changes are unrelated to the crash.
> 
> #### More details about the crash
> It reproduced in IntelliJ IDEA when using one of accessibility tools (such as VoiceOver, Voice Control, Zoom, Full Keyboard Access) and interacting with combo boxes that had popups based on `JPopupMenu`. The first interaction with the popup was good, but if there was a GC run before the next popup opening, it would crash on open.
> 
> What happened was that right before the crash, in `MenuAccessibility` at the point of calling 
> ``` 
> jobject axComponent = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getCurrentAccessiblePopupMenu, fAccessible, fComponent); 
> 
> Both `fAccessible` and `fComponent` are not null. But on the Java side, in `CAccessibility.getCurrentAccessiblePopupMenu(Accessible a, Component c)`, `c` would be null. `fComponent` is created by `NewWeakGlobalRef`, so this scenario is possible. 
> 
> This results in `axComponent` being `NULL`, and then `currentElement` will also have `nil` value. 
> 
> After that, when calling `[CommonComponentAccessibility childrenOfParent:currentElement]`, in the line `if (parent->fAccessible == NULL) return nil;`, `parent` is `nil`, so it crashes.
> 
> Returning `nil` in `accessibilityChildren` is acceptable and would make VoiceOver say "menu (0 items)", but otherwise it will work with menu items normally.
> 
> There is another issue that we even end up in the state when `fComponent` peer is not updated after GC, or that `MenuAccessibility` is not recreated after that. But I haven't investigated that yet and not sure why exactly it happens. I believe for now it's good enough to add these checks on `accessibilityChildren` level.
> 
> #### Testing
> 
> I wasn't able to come up with a test case using simple Swing components that would capture this regression. It's very likely that the reason it was reproducing in IntelliJ was related to our custom components or other parts of our setup, and it's hard to pinpoint the specific cause. I did check `TestPopupMenuChildCount` and there were no changes to VoiceOver announcements. I also couldn't reproduce the crash in IntelliJ when using the OpenJDK build with the fix.

This pull request has been closed without being integrated.

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

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

From abaya at openjdk.org  Thu Dec  4 13:49:49 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 4 Dec 2025 13:49:49 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v4]
In-Reply-To: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
Message-ID: <-Z94MIDezwoho_frqXBWqRbI_d5nomTwcYoB9lyv8Mo=.ff0b27ae-58ed-4680-a9c7-bb8b298140e1@github.com>

> **Analysis :** 
> The issue is that on Win32, if the window is not active, we dont receive mouse events because we release the capture
>  So the problem is the following:
> We start selecting text from the right to the extreme left.
> Then we switch to another window( the window lose focus ), and we release the mouse
> But when we return to the window, the caret drag is still active and does not stop. as the window did not recieved the mouse release event
> 
> **Proposed fix:**
> In the Caret class, we added a logic to ignore the drag if the focus was lost due to window switching unless a new mouse press happens

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

  Test on all pfatforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28582/files
  - new: https://git.openjdk.org/jdk/pull/28582/files/da7ce5ef..1488e2dc

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

  Stats: 29 lines in 1 file changed: 18 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28582/head:pull/28582

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

From abaya at openjdk.org  Thu Dec  4 13:49:51 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 4 Dec 2025 13:49:51 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v3]
In-Reply-To: <O7KO8J7KCiCYi-fhN5hRwed9xx3cnNj0OZTo1aI3lhc=.3eb9c232-4366-4adc-a5af-ac4d693c61b3@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
 <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>
 <O7KO8J7KCiCYi-fhN5hRwed9xx3cnNj0OZTo1aI3lhc=.3eb9c232-4366-4adc-a5af-ac4d693c61b3@github.com>
Message-ID: <cR7qAVUOxYZk8pOeooeSXHkWBhCSU5zLXXz9oNLoPcI=.39b632f1-fafc-45c9-a2a6-7d57420860ed@github.com>

On Thu, 4 Dec 2025 05:21:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The issue occurs only on Wnidows
>
> test/jdk/javax/swing/JTextField/TextSelectionFocusLoss/TextSelectionFocusLoss.java line 38:
> 
>> 36:  * @test
>> 37:  * @key headful
>> 38:  * @requires (os.family == "windows")
> 
> even if it happens only on windows, since this is automated test, no point restricting for other platforms where it should pass automatically...atleast it will catch any regression in future if it happens otherwise later..

Done.
Test links on all platforms on the ticket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28582#discussion_r2589158257

From abaya at openjdk.org  Thu Dec  4 13:49:53 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 4 Dec 2025 13:49:53 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v3]
In-Reply-To: <YO3v68h0PvD2pO5exO4ogTvE8z_kxnni5QNj1AxDqPs=.dadd9029-ab08-44b3-80dd-c5d6ab4e8a8f@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
 <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>
 <YO3v68h0PvD2pO5exO4ogTvE8z_kxnni5QNj1AxDqPs=.dadd9029-ab08-44b3-80dd-c5d6ab4e8a8f@github.com>
Message-ID: <de_10Lp5lEITpE3Zub2Eg2UoOqGG0egYkg071KftBjM=.1a8fa938-e598-4a18-8e31-923a2d83fec9@github.com>

On Wed, 3 Dec 2025 21:36:00 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The issue occurs only on Wnidows
>
> test/jdk/javax/swing/JTextField/TextSelectionFocusLoss/TextSelectionFocusLoss.java line 72:
> 
>> 70:             robot.delay(500);
>> 71: 
>> 72:             Point location = textField.getLocationOnScreen();
> 
> These calls are still need to happen on EDT.

OKay, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28582#discussion_r2589155001

From abaya at openjdk.org  Thu Dec  4 14:05:02 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 4 Dec 2025 14:05:02 GMT
Subject: RFR: 8319880: JTextField text selection doesn't stop if ended
 during loss of window focus [v3]
In-Reply-To: <O7KO8J7KCiCYi-fhN5hRwed9xx3cnNj0OZTo1aI3lhc=.3eb9c232-4366-4adc-a5af-ac4d693c61b3@github.com>
References: <8C7JlJLvlLU7h1xLroYjh-Ry5ozMVkeVPdoe4sAuRZo=.57f0780b-a58d-45ff-bd75-2881301c4b56@github.com>
 <Bn4Gwy5lRFM3CXTP3Jka1tRWwxvuWWKDixPheBIqTHU=.7f48e667-a76b-4aef-921a-cb6b721bf9ad@github.com>
 <O7KO8J7KCiCYi-fhN5hRwed9xx3cnNj0OZTo1aI3lhc=.3eb9c232-4366-4adc-a5af-ac4d693c61b3@github.com>
Message-ID: <Dhst2DSG7arOYxkdnNHSYN6RmHY3Mnjkm0DKUcOffrk=.89ba1bb4-6300-4364-842d-ed2e2c918062@github.com>

On Thu, 4 Dec 2025 05:21:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The issue occurs only on Wnidows
>
> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 551:
> 
>> 549:         if (SwingUtilities.isLeftMouseButton(e)) {
>> 550:             lastClickMillis = e.getWhen();
>> 551:             dragActive = true;
> 
> should we set `dragActive ` here? it's just mousePressed, in which case all mousePress event will have dragActive set.
> I guess it should be set in `mouseDragged` and reset in `mouseReleased`, no?

The issue is that when we start selecting text and then switch to another window, our window loses focus. After losing focus, we no longer receive mouse events. So when we release the mouse button in the other window and then switch back, our window thinks the drag is still happening because it never received the mouse-release event.

To fix this, we added logic to stop the drag as soon as we lose focus. And when we regain focus, since we don?t know whether the mouse was released or not, we require a new mouse-press before allowing dragging again. We also added logic to ignore outdated drag events: any drag event that happened before the last mouse-press is considered outdated and is ignored.

So now the behavior matches what we see in native apps like Notepad. @aivanov-jdk asked to check how a native Windows app behaves in this situation and to make our behavior consistent with that.
 
This logic does not affect the behavior on macOS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28582#discussion_r2589211078

From kurt at openjdk.org  Thu Dec  4 17:02:47 2025
From: kurt at openjdk.org (Kurt Miller)
Date: Thu, 4 Dec 2025 17:02:47 GMT
Subject: Integrated: 8371914: PNG defines in CFLAGS can cause compilation
 errors with external libpng
In-Reply-To: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
References: <iszOlGorT5q31zUFkIXQS2AUVhAAhs8RTz4zY6m7nAM=.401b34fa-9381-431f-8b71-4d2af5262c70@github.com>
Message-ID: <AFHUYi7gu26MBprhyNcPV1QPCgrx7ipn9VYKM-cBTDQ=.1ca3cd1e-d050-4e8a-9e17-c4b66d73887d@github.com>

On Fri, 14 Nov 2025 14:48:14 GMT, Kurt Miller <kurt at openjdk.org> wrote:

> When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64:
> 
> `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]`
> 
> This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX.

This pull request has now been integrated.

Changeset: 45dcc0e7
Author:    Kurt Miller <kurt at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45dcc0e7e26b8130236c5ba80edb54fa530dab57
Stats:     37 lines in 1 file changed: 18 ins; 18 del; 1 mod

8371914: PNG defines in CFLAGS can cause compilation errors with external libpng

Reviewed-by: erikj, jdv

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

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

From prr at openjdk.org  Thu Dec  4 18:57:45 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Dec 2025 18:57:45 GMT
Subject: RFR: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
Message-ID: <5J3eGpEl8WQ9_GBvViYOvUk0IBmnnpVyxwxN0YdSYg4=.427eb68c-0383-4c43-a779-e87cf1d2c780@github.com>

As per the bug description, we are seeing this test fail intermittently after a change and we need to problem list it until we can root cause and fix.

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

Commit messages:
 - 8373099

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

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

From aivanov at openjdk.org  Thu Dec  4 19:37:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 4 Dec 2025 19:37:58 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException [v2]
In-Reply-To: <s22L7eP_f_yc9PDDzW0a9cZtZaVC37--kaFxd91K9L0=.f0d309b4-42a8-4a0d-9cf0-c2e9f928bd9e@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <DCxcwDmeXC0h3thcOd_d6Tm7seK54lF6X5mPrqEmYTs=.a4e32b45-6e50-498f-9d89-31ae4fc3eb5b@github.com>
 <s22L7eP_f_yc9PDDzW0a9cZtZaVC37--kaFxd91K9L0=.f0d309b4-42a8-4a0d-9cf0-c2e9f928bd9e@github.com>
Message-ID: <X_Ry4NE-1WI1lUEKlNjApRJgguY9qO7PjWnDamdVpcI=.d7a68d29-cc62-42c7-a20a-4c3eaab1e416@github.com>

On Wed, 3 Dec 2025 23:06:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 292:
>> 
>>> 290:      * image types.  The {@code ColorSpace} for the image is the
>>> 291:      * default sRGB space.
>>> 292:      * {@code BufferedImage} is a type that supports only one tile.
>> 
>> Suggestion:
>> 
>>     * default sRGB space.
>>     * <p>
>>     * {@code BufferedImage} is a type that supports only one tile.
>> 
>> To start a new paragraph? I think it would improve readability.
>
> I did this but not on the line you suggested.

The `<p>` tag is exactly where I suggested to add it.

(I broke the alignment and ??default sRGB space? is a modified line.)

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

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

From dholmes at openjdk.org  Thu Dec  4 19:46:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 19:46:28 GMT
Subject: RFR: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
In-Reply-To: <5J3eGpEl8WQ9_GBvViYOvUk0IBmnnpVyxwxN0YdSYg4=.427eb68c-0383-4c43-a779-e87cf1d2c780@github.com>
References: <5J3eGpEl8WQ9_GBvViYOvUk0IBmnnpVyxwxN0YdSYg4=.427eb68c-0383-4c43-a779-e87cf1d2c780@github.com>
Message-ID: <oosppOAxxrUUZ3gltQIa_2GMJanLO3Az9eOH01YLKfs=.a2ed0656-8d78-4316-9e5a-e7f80d48df84@github.com>

On Thu, 4 Dec 2025 18:38:14 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug description, we are seeing this test fail intermittently after a change and we need to problem list it until we can root cause and fix.

Thanks for taking care of this.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28663#pullrequestreview-3541796292

From aivanov at openjdk.org  Thu Dec  4 20:15:38 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 4 Dec 2025 20:15:38 GMT
Subject: RFR: 4617681: constructor of BufferedImage throws unexpected
 IllegalArgumentException [v2]
In-Reply-To: <T8pXhE--4RUw4rBi5SxehCrT53LoNJpAf4UjVcc5fws=.be357c47-afd3-48ab-8708-9e6c37addf81@github.com>
References: <qdqL731jHbn4BphsRytLVmTykawYdPpkbH35QzfYlVQ=.efcbd8e2-9429-4d3f-ad30-dfd28c178ff6@github.com>
 <T8pXhE--4RUw4rBi5SxehCrT53LoNJpAf4UjVcc5fws=.be357c47-afd3-48ab-8708-9e6c37addf81@github.com>
Message-ID: <9QKz7EhJlB3o5tVQRSs5ZrAsw8ANdhMU049TIhraDrI=.0a401050-46a0-4ff1-83ec-3f87b24823de@github.com>

On Wed, 3 Dec 2025 23:11:13 GMT, Phil Race <prr at openjdk.org> wrote:

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

Changes requested by aivanov (Reviewer).

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

> 295:      * A {@code DataBuffer} is a container for one or more banks of
> 296:      * Java primitive arrays so the number of samples that can be
> 297:      * stored are limited by the maximum size of a Java array.

Suggestion:

     * A {@code DataBuffer} is a container for one or more banks of
     * Java primitive arrays, so the number of samples that can be
     * stored is limited by the maximum size of a Java array.


A comma before _?so?_ improves readability by separating the dependent clause.

?*the number* of samples ? is,? the verb should be singular, isn't it?

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

> 298:      * This is at most {@code Integer.MAX_VALUE}.
> 299:      * The number of samples per-pixel for an {@code imageType} affect
> 300:      * the maximum. For example, if an image format uses bytes to store

Suggestion:

     * The number of samples per-pixel for an {@code imageType} affects
     * the maximum. For example, if an image format uses bytes to store


?The number ? affects???

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

> 338:         if (width <= 0 || height <= 0) {
> 339:             throw new IllegalArgumentException(
> 340:                      "width " + width + " height " + height + " must both be > 0");

Suggestion:

                     "width " + width + "and height " + height + " must both be > 0");

width *and* height?

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

> 600:              throw new IllegalArgumentException(
> 601:                       "width " + width + " height " + height + " overflow int");
> 602:          }

Does it make sense to move these checks into a separate method to avoid duplicating code at lines 338?346?

https://github.com/openjdk/jdk/blob/7fb58b903bb747000d40318030db27187de75e98/src/java.desktop/share/classes/java/awt/image/BufferedImage.java#L338-L346

`spp` can be passed as a parameter to the helper method in the above case, or the value of 1 in this case.

Using one method to validate the parameters will ensure the messages are consistent. Currently, the asterisk `*` is _still_ missing at line 601 whereas it's _now_ present at line 345.

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

> 672:      *          {@code raster} is incompatible with {@code cm}
> 673:      * @throws IllegalArgumentException if
> 674:      *          {@code raster}, {@code minX} or {@code minY} is not zero

Suggestion:

     * @throws IllegalArgumentException if
     *          {@code raster.minX} or {@code raster.minY} is not zero


The code verifies the values of `minX` and `minY` of the `raster`.

I didn't figure out the correct way in [my previous comment](https://github.com/openjdk/jdk/pull/27640#discussion_r2565722017).

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

PR Review: https://git.openjdk.org/jdk/pull/27640#pullrequestreview-3541788311
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2590346664
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2590350836
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2590406998
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2590390135
PR Review Comment: https://git.openjdk.org/jdk/pull/27640#discussion_r2590378771

From prr at openjdk.org  Thu Dec  4 20:20:32 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Dec 2025 20:20:32 GMT
Subject: Integrated: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
In-Reply-To: <5J3eGpEl8WQ9_GBvViYOvUk0IBmnnpVyxwxN0YdSYg4=.427eb68c-0383-4c43-a779-e87cf1d2c780@github.com>
References: <5J3eGpEl8WQ9_GBvViYOvUk0IBmnnpVyxwxN0YdSYg4=.427eb68c-0383-4c43-a779-e87cf1d2c780@github.com>
Message-ID: <-kEExye-cBgFDAc1jWlNN9LL_EfoZ0cmiqF0k62-3pQ=.6dca5919-e8f4-4265-9b50-d247c4fd6eaa@github.com>

On Thu, 4 Dec 2025 18:38:14 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug description, we are seeing this test fail intermittently after a change and we need to problem list it until we can root cause and fix.

This pull request has now been integrated.

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

8373099: Problem list intermittently failing test sun/awt/image/bug8038000.java

Reviewed-by: dholmes

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

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

From dholmes at openjdk.org  Thu Dec  4 21:40:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 21:40:09 GMT
Subject: [jdk26] RFR: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
Message-ID: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>

Hi all,

This pull request contains a backport of commit [8e653d39](https://github.com/openjdk/jdk/commit/8e653d394e45180e16714124ed6584f912eb5cba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Phil Race on 4 Dec 2025 and was reviewed by David Holmes.

Thanks!

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

Commit messages:
 - Backport 8e653d394e45180e16714124ed6584f912eb5cba

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

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

From kvn at openjdk.org  Thu Dec  4 21:40:10 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Dec 2025 21:40:10 GMT
Subject: [jdk26] RFR: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
In-Reply-To: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>
References: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>
Message-ID: <gIQ5C-T3bZx7CFiX-PhHZaFPE4BpzAbZ-BoheJLC3cE=.6938e355-07d9-41a1-878f-150f409a089f@github.com>

On Thu, 4 Dec 2025 21:28:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e653d39](https://github.com/openjdk/jdk/commit/8e653d394e45180e16714124ed6584f912eb5cba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Phil Race on 4 Dec 2025 and was reviewed by David Holmes.
> 
> Thanks!

Marked as reviewed by kvn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28667#pullrequestreview-3542189529

From prr at openjdk.org  Thu Dec  4 21:42:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Dec 2025 21:42:54 GMT
Subject: [jdk26] RFR: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
In-Reply-To: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>
References: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>
Message-ID: <Me-fUlapBccMae8aVYiEj-qE6RS5l2LwA_OfTVybMRE=.312462ae-f660-4003-9dca-ee8c277b11b7@github.com>

On Thu, 4 Dec 2025 21:28:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e653d39](https://github.com/openjdk/jdk/commit/8e653d394e45180e16714124ed6584f912eb5cba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Phil Race on 4 Dec 2025 and was reviewed by David Holmes.
> 
> Thanks!

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28667#pullrequestreview-3542208487

From dholmes at openjdk.org  Thu Dec  4 22:01:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 22:01:34 GMT
Subject: [jdk26] RFR: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
In-Reply-To: <gIQ5C-T3bZx7CFiX-PhHZaFPE4BpzAbZ-BoheJLC3cE=.6938e355-07d9-41a1-878f-150f409a089f@github.com>
References: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>
 <gIQ5C-T3bZx7CFiX-PhHZaFPE4BpzAbZ-BoheJLC3cE=.6938e355-07d9-41a1-878f-150f409a089f@github.com>
Message-ID: <kQjCe0QLEqF--4XhRDM7iQOP2-O_0BmAfwz0cvasKbQ=.ca7bf5ac-adc9-40f7-8130-02f426414389@github.com>

On Thu, 4 Dec 2025 21:34:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [8e653d39](https://github.com/openjdk/jdk/commit/8e653d394e45180e16714124ed6584f912eb5cba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Phil Race on 4 Dec 2025 and was reviewed by David Holmes.
>> 
>> Thanks!
>
> Marked as reviewed by kvn (Reviewer).

Thanks for the reviews @vnkozlov and @prrace !

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

PR Comment: https://git.openjdk.org/jdk/pull/28667#issuecomment-3614489167

From dholmes at openjdk.org  Thu Dec  4 22:04:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 Dec 2025 22:04:41 GMT
Subject: [jdk26] Integrated: 8373099: Problem list intermittently failing test
 sun/awt/image/bug8038000.java
In-Reply-To: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>
References: <Ganc-Z85TaTCzilfLk7akNnWdYTBrVEWZGNLHrrXRis=.64ee9e4e-c8af-45c2-ac2e-8d7be6535a7f@github.com>
Message-ID: <jLitCnz-bsk4seR5jPsYx5Q9CGaQFOAIo-0OvBg3R0w=.a7e99fdd-13cd-4a1f-9b3e-12a9e4a6a547@github.com>

On Thu, 4 Dec 2025 21:28:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [8e653d39](https://github.com/openjdk/jdk/commit/8e653d394e45180e16714124ed6584f912eb5cba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Phil Race on 4 Dec 2025 and was reviewed by David Holmes.
> 
> Thanks!

This pull request has now been integrated.

Changeset: de686f8a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de686f8a383d3e146abfb3e937d0179322e7cade
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8373099: Problem list intermittently failing test sun/awt/image/bug8038000.java

Reviewed-by: kvn, prr
Backport-of: 8e653d394e45180e16714124ed6584f912eb5cba

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

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

From serb at openjdk.org  Thu Dec  4 23:35:08 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 4 Dec 2025 23:35:08 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
Message-ID: <dWpwGtn6TvD5c0VdDxwdVnTOkVw3gLaYjjITJsznNbY=.6cecb7a2-0145-435e-afad-410d63a6029c@github.com>

On Thu, 6 Feb 2025 14:03:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The splashscreen lib is currently built with LOW optimization.
>> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
>> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
>> 
>> current settings (LOW optimization) :
>> ---------------------------------------------------
>> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
>> 
>> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> 
>> new settings (SIZE optimization) :
>> --------------------------------------------------
>> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
>> 
>> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> On Linux aarch64 only the debuginfo shrinks but the lib stays abo...
>
> I think this looks good, but someone from client should probably also weigh in.

@erikj79 @MBaesken I wonder, is it possible to switch this parameter via configuration or something? Or is the only way to tweak the OPT level for the library by modifying the makefile? I tried using with-extra-cflags, but it seems to be appended before OPT, so it?s ignored.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-3614732683

From erikj at openjdk.org  Thu Dec  4 23:43:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 4 Dec 2025 23:43:18 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
Message-ID: <OklntItFWK39fMIHK_-yUjyrkuwXRzTQZpEuQo1mluc=.55ee277c-c9a8-4584-b781-682fb9f9ad7f@github.com>

On Thu, 6 Feb 2025 14:03:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The splashscreen lib is currently built with LOW optimization.
>> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
>> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
>> 
>> current settings (LOW optimization) :
>> ---------------------------------------------------
>> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
>> 
>> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
>> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> 
>> new settings (SIZE optimization) :
>> --------------------------------------------------
>> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
>> 
>> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
>> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
>> 
>> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
>> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
>> 
>> On Linux aarch64 only the debuginfo shrinks but the lib stays abo...
>
> I think this looks good, but someone from client should probably also weigh in.

> @erikj79 @MBaesken I wonder, is it possible to switch this parameter via configuration or something? Or is the only way to tweak the OPT level for the library by modifying the makefile? I tried using with-extra-cflags, but it seems to be appended before OPT, so it?s ignored.

We do not support changing optimization levels through configure or make arguments. You need to edit makefiles for each individual library.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-3614748589

From serb at openjdk.org  Fri Dec  5 00:03:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 5 Dec 2025 00:03:03 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: <cvgJS_iWaWwvWZzJIdh-ZcayJIB-bDghKi3dwCQxaLc=.70ef9601-fa8f-45d8-ad55-226e41a68da5@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <uVgMcy7gR7CkOAW7roSvTUbtZws5c62YPEuDKFdxu2w=.64b1f219-f6f1-4bc2-87fd-3ce2a946f340@github.com>
 <qf-5r_MLqzrO8SgfWIHH4Gj4aw8FyCVvhZI_mWCBQ_0=.6b4b864b-409f-42f7-9759-1ae1fd55c398@github.com>
 <Q0gXAzDo8zPlzceEMLzA0Qu82VaW6vPHZ_Z-dQKXWRI=.c5411dc2-728c-49db-8a7c-bec5e6eefcd3@github.com>
 <cvgJS_iWaWwvWZzJIdh-ZcayJIB-bDghKi3dwCQxaLc=.70ef9601-fa8f-45d8-ad55-226e41a68da5@github.com>
Message-ID: <9M7wUIoPHmHhIuq_ogQVrmE731WXZBi1qWKo4aq4haI=.a7cb7dac-5475-49e6-9647-50c69c58736a@github.com>

On Thu, 27 Nov 2025 04:24:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>Hmm, I didn't create this with the idea of backporting it in mind. Should I do that?

Not necessarily the one where you do refactoring, only the part for the missing ?no omit frame pointer? option. It can be done separately to simplify the backport.

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3614783229

From serb at openjdk.org  Fri Dec  5 00:07:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 5 Dec 2025 00:07:09 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <OklntItFWK39fMIHK_-yUjyrkuwXRzTQZpEuQo1mluc=.55ee277c-c9a8-4584-b781-682fb9f9ad7f@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
 <OklntItFWK39fMIHK_-yUjyrkuwXRzTQZpEuQo1mluc=.55ee277c-c9a8-4584-b781-682fb9f9ad7f@github.com>
Message-ID: <F7cgxfajKBlpq5jGX0ivOuELUJcewBv8hUBtNjpuak4=.3b591d35-b3d2-402b-bcff-1b30ae53b451@github.com>

On Thu, 4 Dec 2025 23:40:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>We do not support changing optimization levels through configure or make arguments. You need to edit makefiles for each individual library.

Are there any blockers to setting a global default that would override the optimization level for all libraries(if set)? For example, making everything build with ?size optimized? flags by default. This could be useful when producing different bundles optimized for different use cases, while still using the same source code.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-3614791053

From psadhukhan at openjdk.org  Fri Dec  5 03:12:49 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 5 Dec 2025 03:12:49 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps
Message-ID: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>

`SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as argument to `uiInputMap`/`uiActionMap`

https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828

If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.

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

Commit messages:
 - Test fix
 - Test fix
 - 6726690: SwingUtilities.replaceUI*Map() methods do not remove previously installed maps

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

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

From psadhukhan at openjdk.org  Fri Dec  5 03:34:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 5 Dec 2025 03:34:17 GMT
Subject: Integrated: 8042054: JTree.updateUI uses out-of-date item size
 information
In-Reply-To: <cqrDtybBDmrqGYE3w6I_O4jaqEVacVc7mBpHtGWozRo=.9612cb00-b220-4490-b062-28b1159ff2be@github.com>
References: <cqrDtybBDmrqGYE3w6I_O4jaqEVacVc7mBpHtGWozRo=.9612cb00-b220-4490-b062-28b1159ff2be@github.com>
Message-ID: <rkPj6Mq1Ab5NXXrN2LXRbVoKzpx6R4BZdVkLkUIaPvA=.d3e88501-2270-4620-987f-bd978f58ae61@github.com>

On Wed, 12 Nov 2025 07:56:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `JTree.updateUI` calculate item sizes from the cell renderer, but it doesn't call `updateUI `on the cell renderer until afterwards. This leads to incorrect size calculation, which is observed when we switch from one L&F to another where it is seen that all tree items are slightly too cramped, with too little space between rows and text are abbreviated.
> Fix is to ensure `JTree.updateUI` update the cell renderer before updating the UI. 
> CI testing is ok..
> 
> Before fix
> <img width="142" height="146" alt="image" src="https://github.com/user-attachments/assets/95d43e47-122a-4ca4-8a3f-f4bf5c1d3f43" />
> 
> After fix
> <img width="145" height="125" alt="image" src="https://github.com/user-attachments/assets/068b5988-119c-4b99-be27-1ef5d52a28a2" />

This pull request has now been integrated.

Changeset: 674cc3ee
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/674cc3eeca77f1f2a6d937b1df5c5cd8a13c2d31
Stats:     101 lines in 2 files changed: 98 ins; 2 del; 1 mod

8042054: JTree.updateUI uses out-of-date item size information

Reviewed-by: dnguyen, serb

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

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

From mbaesken at openjdk.org  Fri Dec  5 07:50:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 5 Dec 2025 07:50:30 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <F7cgxfajKBlpq5jGX0ivOuELUJcewBv8hUBtNjpuak4=.3b591d35-b3d2-402b-bcff-1b30ae53b451@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
 <2_lf6_ks-tFekeOeBQ9OTd9CB_ejCX5qRCEpCZhhCd8=.5ff2b541-e1bd-47d3-b838-95d608d0a39e@github.com>
 <OklntItFWK39fMIHK_-yUjyrkuwXRzTQZpEuQo1mluc=.55ee277c-c9a8-4584-b781-682fb9f9ad7f@github.com>
 <F7cgxfajKBlpq5jGX0ivOuELUJcewBv8hUBtNjpuak4=.3b591d35-b3d2-402b-bcff-1b30ae53b451@github.com>
Message-ID: <67_aZThHK6eI8SAfrEhnddTUmF4TgHiBPdCgTi_M-bU=.bc79dc3c-f675-437b-81b7-8dcbceef9ca1@github.com>

On Fri, 5 Dec 2025 00:04:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > We do not support changing optimization levels through configure or make arguments. You need to edit makefiles for each individual library.
> 
> Are there any blockers to setting a global default that would override the optimization level for all libraries(if set)? For example, making everything build with ?size optimized? flags by default. This could be useful when producing different bundles optimized for different use cases, while still using the same source code.

For libjvm we have the 'jvm feature'  `opt-size`  (probably you know about it?) ;  I think we should have something similar for the other native libs too.  But afaik it is not (yet) supported with an easy configure flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-3615674228

From mbaesken at openjdk.org  Fri Dec  5 08:15:12 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 5 Dec 2025 08:15:12 GMT
Subject: RFR: 8349378: Build splashscreen lib with SIZE optimization
In-Reply-To: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
References: <Vlw3No_8IpmkSUQsSzq_w_3_SklCjCd9k7AY7-EpQUU=.f89b832d-9c73-417d-8779-004b6d60968b@github.com>
Message-ID: <DFD0u5YQulI96SkfbfTu3RtL8JLwBo5FKapyD9HYeWQ=.11d055cd-3c1d-438a-8f55-bd927d4931fb@github.com>

On Thu, 6 Feb 2025 13:52:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The splashscreen lib is currently built with LOW optimization.
> This might be fine because it is not very performance critical  (and LOW is not really low when looking at the opt-flags used).
> But building it with SIZE optimization makes it 10-20 % smaller on some platforms which helps to reduce image size.
> 
> current settings (LOW optimization) :
> ---------------------------------------------------
> 2.5M /aix_ppc64/jdk-opt/images/jdk/lib/libsplashscreen.so  (not split debuginfo file on AIX currently)
> 
> 468K /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.6M /macosaarch64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 388K /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosintel64/jdk-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 368K /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_aarch64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.8M /linux_alpine_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 500K /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_ppc64le/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 364K /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.so
> 1.7M /linux_x86_64/jdk-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> 
> new settings (SIZE optimization) :
> --------------------------------------------------
> 2.1M /aix_ppc64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so    (not split debuginfo file on AIX currently)
> 
> 404K /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.5M /macosaarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 316K /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib
> 1.4M /macosintel64/jdk-dev-opt/images/jdk/lib/libsplashscreen.dylib.dSYM
> 
> 372K /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_aarch64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.5M /linux_alpine_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 376K /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_ppc64le/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 304K /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.so
> 1.4M /linux_x86_64/jdk-dev-opt/images/jdk/lib/libsplashscreen.debuginfo
> 
> On Linux aarch64 only the debuginfo shrinks but the lib stays about the same in size. Maybe -Os does not work as well on this platform.
> Other UNIX pl...

See also https://wiki.openjdk.org/display/Build/Native+library+optimization+level+research  where I compared some time ago different OPT-levels and how they influenced the binary size .
For some libs like LIBJDWP there is room for improvement by setting SIZE instead of LOW ; but not all people like this as a default , so having a configure setting for this might be a good idea - gives more flexibility .

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

PR Comment: https://git.openjdk.org/jdk/pull/23493#issuecomment-3615743401

From thomas.stuefe at gmail.com  Fri Dec  5 11:34:26 2025
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 5 Dec 2025 12:34:26 +0100
Subject: [OpenJDK][Headless] Allow compilation without X11
In-Reply-To: <CACXRmJgvHAvAqyNyJWLuw6mdiVAqrmAar1iEu4Sd3O-qWmYyag@mail.gmail.com>
References: <CACXRmJgkeuzLF_2URU9LsdVLRbuOdbGNEOFyPaMkD7EgLNh40A@mail.gmail.com>
 <CACXRmJgJpVkkYUpy3k1w+BxKUvcT7e=-NBOWctQL=MJj95oUpQ@mail.gmail.com>
 <CACXRmJgvHAvAqyNyJWLuw6mdiVAqrmAar1iEu4Sd3O-qWmYyag@mail.gmail.com>
Message-ID: <CAA-vtUycq-ap78GD4zdE8w+UZJcDuBWJO5FbdxQpD1-4ego_Ag@mail.gmail.com>

This makes sense to me. Thank you for your patch. I am not a GUI nor a Make
person; Adding Magnus for feedback.

On Wed, Dec 3, 2025 at 9:49?PM Thomas Devoogdt <thomas at devoogdt.com> wrote:

> Hi,
>
>
> Anyone out there?
>
>
> Kind regards,
>
> Thomas Devoogdt
>
> Op wo 26 nov 2025, 10:39 schreef Thomas Devoogdt <thomas at devoogdt.com>:
>
>> Hi all,
>>
>>
>> I'm trying to compile OpenJDK in headless mode without the required
>> X11 libraries.
>> This becomes more common in embedded systems, where e.g. no head is used
>> at all,
>> or where e.g. only wayland is available.
>>
>> For this, I proposed a patch in buildroot, see
>>
>> https://patchwork.ozlabs.org/project/buildroot/patch/20251115154030.1746780-1-thomas at devoogdt.com/
>> .
>> Buildroots policy is to upstream any custom patch when applicable, for
>> which I created
>> https://github.com/openjdk/jdk/pull/28310.
>>
>> The first question, is there any interest to support compilation
>> without X11 in headless mode?
>> If yes, who can create a formal "issue" and pick this up as my "sponsor"?
>>
>> If this PR gets merged, is there any interest to backport this to the
>> relevant LTS
>> distributions? Buildroot ships JDK with the somewhat outdated versions
>> 17 and 21?
>>
>>
>> Kind regards,
>>
>> Thomas Devoogdt
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251205/cf25068e/attachment-0001.htm>

From serb at openjdk.org  Sat Dec  6 01:28:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 6 Dec 2025 01:28:59 GMT
Subject: RFR: 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: <KfvoTbFqZjEB7J9w1CUYCBSSEry4jjZ809A1pS3LjWM=.2f3f96bd-f62f-43e9-a34c-1f78a0fb4649@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..

the goal of CellEditorRemover was to call the cancelCellEditing on focus lost, how all this will work after deserialisation? when this cancelCellEditing() will be called if editorRemover==null?

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3619123669

From psadhukhan at openjdk.org  Sun Dec  7 06:52:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 7 Dec 2025 06:52:57 GMT
Subject: RFR: 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: <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@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..

Firstly, `cancelCellEditing()` is dependant on CellEditor being non-null since everywhere it is called via `getCellEditor().cancelCellEditing()` and `cellEditor` is transient which does not participate in serialization 
https://github.com/openjdk/jdk/blob/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87/src/java.desktop/share/classes/javax/swing/JTable.java#L408
and 
secondly, `editorRemover` is  PropertyChangeListener object and in other places in jdk like
https://github.com/openjdk/jdk/blob/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87/src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java#L1436
https://github.com/openjdk/jdk/blob/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87/src/java.desktop/share/classes/javax/swing/JFileChooser.java#L281
it also doesn't participate in serialization so have done the same

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3621727944

From duke at openjdk.org  Mon Dec  8 02:30:28 2025
From: duke at openjdk.org (wb-zjp846396)
Date: Mon, 8 Dec 2025 02:30:28 GMT
Subject: RFR: 8372651: Remove unreachable code in
 sun.awt.geom.AreaOp::calculate
Message-ID: <okgf1Zxa-wzLYg3WlbjoILhXQQkrNM8Vw3y3aYnTC-4=.f44508ca-2760-4da0-8be8-d16c56c2708f@github.com>

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.

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

Commit messages:
 - src/java.desktop: Remove unused code

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

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

From azvegint at openjdk.org  Mon Dec  8 10:56:57 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 8 Dec 2025 10:56:57 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v2]
In-Reply-To: <EuGQl4L1yElxktIP8geV3BdgaAAMI2rX61nhtc9E8Ss=.7ed846f8-af61-4d6f-9891-6c0697172f33@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <EuGQl4L1yElxktIP8geV3BdgaAAMI2rX61nhtc9E8Ss=.7ed846f8-af61-4d6f-9891-6c0697172f33@github.com>
Message-ID: <NIqegaw0kwaaiMcqYN-2Eq1NC91z8all3hp-uGjvtYY=.c91ff986-07fe-4e98-a008-86753f847782@github.com>

On Wed, 3 Dec 2025 21:45:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
>> 
>> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix curly brace issue when moving code

test/jdk/java/awt/Frame/FrameVisualTest.java line 95:

> 93:                     });
> 94:                     Rectangle rect = new Rectangle(p, d);
> 95:                     BufferedImage img = robot.createScreenCapture(rect);

https://github.com/openjdk/jdk/pull/26871#discussion_r2298835087 is still valid for the updated test.

On Ubuntu, a batch of windows opens in one place, so only the top window in the stack is checked.

<img width="157" height="144" alt="Image" src="https://github.com/user-attachments/assets/769e72e3-70f5-4cd3-970d-1385724b6b92" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2598129828

From azvegint at openjdk.org  Mon Dec  8 11:08:05 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 8 Dec 2025 11:08:05 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps
In-Reply-To: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
Message-ID: <gw9x0dqcAZV1WI-XGJt8EWZSx5fc26JQeU8OKzee-W0=.4da0c16f-44eb-4f17-8ecf-e1f8d327287e@github.com>

On Fri, 5 Dec 2025 03:01:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
> 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
> 
> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.

src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1825:

> 1823:             map = parent;
> 1824:         }
> 1825:         if (map != null && uiInputMap == null) {

Line 1826 seems to be unreachable, as we have `while (map != null) {` before in the same method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2598163851

From dgredler at openjdk.org  Mon Dec  8 12:57:03 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Mon, 8 Dec 2025 12:57:03 GMT
Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses
 font transform
In-Reply-To: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
References: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
Message-ID: <OnAQTt4p7D2z2NZHmmrzmYQmf-GMhrp-Ych4MnOpvyI=.83fbb369-0603-4e4a-8df9-7c37032b1ce9@github.com>

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

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

This PR was opened a few months ago, but I'm having trouble getting a second review. Does anybody have some bandwidth? Thanks!

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

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

From psadhukhan at openjdk.org  Mon Dec  8 13:18:50 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 8 Dec 2025 13:18:50 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v2]
In-Reply-To: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
Message-ID: <yokv7qpBbUCtDycI7BYMsov8AZJctl__xdzuthFoMz8=.10a03be6-8c62-427e-8e90-4db7af2c8633@github.com>

> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
> 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
> 
> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Redundant code remove
 - Redundant code remove

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28671/files
  - new: https://git.openjdk.org/jdk/pull/28671/files/63a5ac1c..847b6ba9

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

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

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

From psadhukhan at openjdk.org  Mon Dec  8 13:18:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 8 Dec 2025 13:18:52 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v2]
In-Reply-To: <gw9x0dqcAZV1WI-XGJt8EWZSx5fc26JQeU8OKzee-W0=.4da0c16f-44eb-4f17-8ecf-e1f8d327287e@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <gw9x0dqcAZV1WI-XGJt8EWZSx5fc26JQeU8OKzee-W0=.4da0c16f-44eb-4f17-8ecf-e1f8d327287e@github.com>
Message-ID: <KXFUIVeS3k-rCtN9PNxq5eSrtUlRCeuQdcwcZeeE35Q=.acae9454-a492-4540-a43a-d07868fc4f15@github.com>

On Mon, 8 Dec 2025 11:00:14 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Redundant code remove
>>  - Redundant code remove
>
> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1825:
> 
>> 1823:             map = parent;
>> 1824:         }
>> 1825:         if (map != null && uiInputMap == null) {
> 
> Line 1826 seems to be unreachable, as we have `while (map != null) {` before in the same method.

you are right..removed..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2598597114

From azvegint at openjdk.org  Mon Dec  8 14:15:08 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 8 Dec 2025 14:15:08 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: <Z0GDci-Eu44FdO_lTkeUC5IG1RS7xn9yglNUXWVyiEI=.ca0fd5a7-630a-4dd5-9558-2e63743ec1c2@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.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28528#pullrequestreview-3552284688

From azvegint at openjdk.org  Mon Dec  8 14:57:26 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 8 Dec 2025 14:57:26 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v2]
In-Reply-To: <yokv7qpBbUCtDycI7BYMsov8AZJctl__xdzuthFoMz8=.10a03be6-8c62-427e-8e90-4db7af2c8633@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <yokv7qpBbUCtDycI7BYMsov8AZJctl__xdzuthFoMz8=.10a03be6-8c62-427e-8e90-4db7af2c8633@github.com>
Message-ID: <ZIq03n_FnOE0bfJeu4PhU-vLblFD7c71dZFzoQULxoc=.2ef621ca-6595-4520-b1a2-cc8c60743cc7@github.com>

On Mon, 8 Dec 2025 13:18:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
>> 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
>> 
>> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
>> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Redundant code remove
>  - Redundant code remove

src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1820:

> 1818:                 if (uiInputMap == null) {
> 1819:                     map.clear();
> 1820:                 }

What if `if (parent == null || (parent instanceof UIResource)) {` is false and `uiInputMap == null`?
Should we also clear the map?

test/jdk/javax/swing/SwingUtilities/UIMapTest.java line 51:

> 49: 
> 50:         // Add the map
> 51:         SwingUtilities.replaceUIInputMap(button, JComponent.WHEN_IN_FOCUSED_WINDOW, map);

Although the fix changes both `replaceUIInputMap` and `replaceUIActionMap`, only `replaceUIInputMap` is tested.

test/jdk/javax/swing/SwingUtilities/UIMapTest.java line 58:

> 56:         // Show the frame
> 57:         JFrame frame = new JFrame("UIMapTest");
> 58:         frame.add(button);

Do we really need this?

Suggestion:



In its current state, the test will fail on headless systems because the test does not have the `@key headful`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2598937878
PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2598935925
PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2598928391

From dnguyen at openjdk.org  Mon Dec  8 17:20:03 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 8 Dec 2025 17:20:03 GMT
Subject: RFR: 6223700: XP L&F: Non-TopLevel JMenu's painting error
In-Reply-To: <7szJgbTU8E_MWUDB2koWP4tDiP8nqiaYZ41cDrbRo3o=.9f3341d5-a9bb-48b8-8052-a706adfe7165@github.com>
References: <7szJgbTU8E_MWUDB2koWP4tDiP8nqiaYZ41cDrbRo3o=.9f3341d5-a9bb-48b8-8052-a706adfe7165@github.com>
Message-ID: <sl6ZOqkugcLUCAl1CYrZxQfdOKckEEN3fAXmU8OVg_Y=.00492341-5e92-41a8-9742-0d54300881ff@github.com>

On Fri, 28 Nov 2025 08:50:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that non-TopLevel JMenu's get repainted when the mouse exits the item. If the popup menu is still visible to the right, repainting the JMenu causes the selection background to be repainted over the top of the popup, even though the popup is supposed to appear above the JMenu.
> 
> The problem is caused by the mouse handling code in the protected inner class `WindowsMenuUI.WindowsMouseInputHandler.` The `mouseEntered` and `mouseExited` handlers set the RollOver property and the JMenu gets repainted. However, setting the RollOver property is only necessary for top-level JMenus. Non-TopLevel JMenu menu items such as these get painted by the super class BasicMenuItemUI which uses isSelected() rather than isRollOver() to determine whether the selection background color should be used.
> 
> Fix is to use the repainting only for TopLevel Menu in `mouseExited`, the same way it is being done for `mouseEntered`

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28551#pullrequestreview-3553161804

From psadhukhan at openjdk.org  Tue Dec  9 00:36:21 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 00:36:21 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v3]
In-Reply-To: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
Message-ID: <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>

> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
> 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
> 
> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.

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

  Fix update...ActionMap test added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28671/files
  - new: https://git.openjdk.org/jdk/pull/28671/files/847b6ba9..85028272

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

  Stats: 46 lines in 2 files changed: 34 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28671/head:pull/28671

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

From psadhukhan at openjdk.org  Tue Dec  9 00:36:24 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 00:36:24 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v2]
In-Reply-To: <ZIq03n_FnOE0bfJeu4PhU-vLblFD7c71dZFzoQULxoc=.2ef621ca-6595-4520-b1a2-cc8c60743cc7@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <yokv7qpBbUCtDycI7BYMsov8AZJctl__xdzuthFoMz8=.10a03be6-8c62-427e-8e90-4db7af2c8633@github.com>
 <ZIq03n_FnOE0bfJeu4PhU-vLblFD7c71dZFzoQULxoc=.2ef621ca-6595-4520-b1a2-cc8c60743cc7@github.com>
Message-ID: <zeo5u7RgPYkNEmlNhnxvn3ret8fiAr7bEcj1lKsRGzo=.75d0b500-8547-47af-9f61-955fb46d3daa@github.com>

On Mon, 8 Dec 2025 14:53:03 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Redundant code remove
>>  - Redundant code remove
>
> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1820:
> 
>> 1818:                 if (uiInputMap == null) {
>> 1819:                     map.clear();
>> 1820:                 }
> 
> What if `if (parent == null || (parent instanceof UIResource)) {` is false and `uiInputMap == null`?
> Should we also clear the map?

Addressed..

> test/jdk/javax/swing/SwingUtilities/UIMapTest.java line 51:
> 
>> 49: 
>> 50:         // Add the map
>> 51:         SwingUtilities.replaceUIInputMap(button, JComponent.WHEN_IN_FOCUSED_WINDOW, map);
> 
> Although the fix changes both `replaceUIInputMap` and `replaceUIActionMap`, only `replaceUIInputMap` is tested.

ActionMap test added

> test/jdk/javax/swing/SwingUtilities/UIMapTest.java line 58:
> 
>> 56:         // Show the frame
>> 57:         JFrame frame = new JFrame("UIMapTest");
>> 58:         frame.add(button);
> 
> Do we really need this?
> 
> Suggestion:
> 
> 
> 
> In its current state, the test will fail on headless systems because the test does not have the `@key headful`.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2600629412
PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2600630154
PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2600630441

From psadhukhan at openjdk.org  Tue Dec  9 00:38:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 00:38:10 GMT
Subject: Integrated: 6223700: XP L&F: Non-TopLevel JMenu's painting error
In-Reply-To: <7szJgbTU8E_MWUDB2koWP4tDiP8nqiaYZ41cDrbRo3o=.9f3341d5-a9bb-48b8-8052-a706adfe7165@github.com>
References: <7szJgbTU8E_MWUDB2koWP4tDiP8nqiaYZ41cDrbRo3o=.9f3341d5-a9bb-48b8-8052-a706adfe7165@github.com>
Message-ID: <E4FZv41TDjCV_CXfr-eGkL6Dfui-l3-sO9GmFX_3z88=.682bf0c5-bfa6-49b2-a5e6-31c3a62240eb@github.com>

On Fri, 28 Nov 2025 08:50:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that non-TopLevel JMenu's get repainted when the mouse exits the item. If the popup menu is still visible to the right, repainting the JMenu causes the selection background to be repainted over the top of the popup, even though the popup is supposed to appear above the JMenu.
> 
> The problem is caused by the mouse handling code in the protected inner class `WindowsMenuUI.WindowsMouseInputHandler.` The `mouseEntered` and `mouseExited` handlers set the RollOver property and the JMenu gets repainted. However, setting the RollOver property is only necessary for top-level JMenus. Non-TopLevel JMenu menu items such as these get painted by the super class BasicMenuItemUI which uses isSelected() rather than isRollOver() to determine whether the selection background color should be used.
> 
> Fix is to use the repainting only for TopLevel Menu in `mouseExited`, the same way it is being done for `mouseEntered`

This pull request has now been integrated.

Changeset: c03d445a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c03d445a8ccfced5a59da680c37587f1024f3eca
Stats:     83 lines in 2 files changed: 82 ins; 0 del; 1 mod

6223700: XP L&F: Non-TopLevel JMenu's painting error

Reviewed-by: kizune, dnguyen

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

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

From prr at openjdk.org  Tue Dec  9 00:39:12 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Dec 2025 00:39:12 GMT
Subject: RFR: 8372554: Test windows-x64-cmp-baseline failed due to differences
 with splashscreen object file
Message-ID: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>

This backs out a specific part of the change from https://bugs.openjdk.org/browse/JDK-8370438
which causes the windows-x64-cmp-baseline build to fail every time.

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

Commit messages:
 - 8372554

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

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

From serb at openjdk.org  Tue Dec  9 00:45:53 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Dec 2025 00:45:53 GMT
Subject: RFR: 8372554: Test windows-x64-cmp-baseline failed due to
 differences with splashscreen object file
In-Reply-To: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
References: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
Message-ID: <oNHSvZmtOo5HESCHJzU_xGb9x9Yzck9ik6y-g-1SFTU=.3924ebe8-52e2-4839-838c-6c5f508e5b8f@github.com>

On Tue, 9 Dec 2025 00:32:15 GMT, Phil Race <prr at openjdk.org> wrote:

> This backs out a specific part of the change from https://bugs.openjdk.org/browse/JDK-8370438
> which causes the windows-x64-cmp-baseline build to fail every time.

What is the purpose of the ?windows-x64-cmp-baseline? task, and how is it affected by the change in question? Why was the decision made to revert the change instead of fixing the task? Was there something wrong with that optimization?

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

PR Comment: https://git.openjdk.org/jdk/pull/28712#issuecomment-3629679772

From serb at openjdk.org  Tue Dec  9 00:52:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Dec 2025 00:52:54 GMT
Subject: RFR: 8372554: Test windows-x64-cmp-baseline failed due to
 differences with splashscreen object file
In-Reply-To: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
References: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
Message-ID: <Ib8aND4ZlUpCkKnMHDD2lS4vzC9hS13vr-N7iWng_9A=.39a42adc-5d3f-4d8d-991b-36901d227126@github.com>

On Tue, 9 Dec 2025 00:32:15 GMT, Phil Race <prr at openjdk.org> wrote:

> This backs out a specific part of the change from https://bugs.openjdk.org/browse/JDK-8370438
> which causes the windows-x64-cmp-baseline build to fail every time.

This might be related? https://github.com/openjdk/jdk/pull/28676

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

PR Comment: https://git.openjdk.org/jdk/pull/28712#issuecomment-3629705659

From dholmes at openjdk.org  Tue Dec  9 00:58:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Dec 2025 00:58:54 GMT
Subject: RFR: 8372554: Test windows-x64-cmp-baseline failed due to
 differences with splashscreen object file
In-Reply-To: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
References: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
Message-ID: <swqxnqdxyP2fYl3Lqr8ZIcl7xEbYxMKJVw4TxYn6O3w=.154249c4-5f09-45db-a783-84f177916e24@github.com>

On Tue, 9 Dec 2025 00:32:15 GMT, Phil Race <prr at openjdk.org> wrote:

> This backs out a specific part of the change from https://bugs.openjdk.org/browse/JDK-8370438
> which causes the windows-x64-cmp-baseline build to fail every time.

Seems trivially fine to me. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28712#pullrequestreview-3554780602

From prr at openjdk.org  Tue Dec  9 01:04:06 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Dec 2025 01:04:06 GMT
Subject: Integrated: 8372554: Test windows-x64-cmp-baseline failed due to
 differences with splashscreen object file
In-Reply-To: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
References: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
Message-ID: <q7g4ThG9sU919BdJ2SPjWmRTdnisb3m7mLZjo0_OkKo=.16fc69e1-cd33-4c3a-8603-c19380525958@github.com>

On Tue, 9 Dec 2025 00:32:15 GMT, Phil Race <prr at openjdk.org> wrote:

> This backs out a specific part of the change from https://bugs.openjdk.org/browse/JDK-8370438
> which causes the windows-x64-cmp-baseline build to fail every time.

This pull request has now been integrated.

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

8372554: Test windows-x64-cmp-baseline failed due to differences with splashscreen object file

Reviewed-by: dholmes

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

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

From prr at openjdk.org  Tue Dec  9 01:08:07 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Dec 2025 01:08:07 GMT
Subject: RFR: 8372554: Test windows-x64-cmp-baseline failed due to
 differences with splashscreen object file
In-Reply-To: <oNHSvZmtOo5HESCHJzU_xGb9x9Yzck9ik6y-g-1SFTU=.3924ebe8-52e2-4839-838c-6c5f508e5b8f@github.com>
References: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
 <oNHSvZmtOo5HESCHJzU_xGb9x9Yzck9ik6y-g-1SFTU=.3924ebe8-52e2-4839-838c-6c5f508e5b8f@github.com>
Message-ID: <ovMdGMh57zqdRkC7et162euR6hyjSUNJG5775Jq0ZHs=.b83fa0c8-5edd-41bb-8031-61b6c264cd74@github.com>

On Tue, 9 Dec 2025 00:43:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> What is the purpose of the ?windows-x64-cmp-baseline? task, and how is it affected by the change in question? Why was the decision made to revert the change instead of fixing the task? Was there something wrong with that optimization?

SFAIU it checks if builds are reproducible. You can go look for yourself. There's nothing wrong with the "build test/task", the problem is that LTO isn't creating builds that pass on windows x64 and it fails every time.
Could be a windows compiler issue, but that isn't going to get fixed soon. This partial back out is the answer.

Next, if it is important, (which it doesn't seem to be), It is up to whoever wants this LTO option to justify it and make sure everything passes before re-enabling it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28712#issuecomment-3629739005

From serb at openjdk.org  Tue Dec  9 01:15:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Dec 2025 01:15:01 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
Message-ID: <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>

On Sun, 7 Dec 2025 06:49:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> it also doesn't participate in serialization so have done the same

I see. Then please add a check to the test to verify that after serialization the cell is always in a "non-editable" state, regardless of whether it was editable before serialisation. In this case, we don?t need to handle resetting it with the editorRemover.

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3629754341

From psadhukhan at openjdk.org  Tue Dec  9 01:40:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 01:40:16 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
Message-ID: <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>

On Tue, 9 Dec 2025 01:12:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > it also doesn't participate in serialization so have done the same
> 
> I see. Then please add a check to the test to verify that after serialization the cell is always in a "non-editable" state, regardless of whether it was editable before serialisation. In this case, we don?t need to handle resetting it with the editorRemover.

ok check added..

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3629806066

From psadhukhan at openjdk.org  Tue Dec  9 01:40:14 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 01:40:14 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v2]
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: <7fp_Omtbb0hAQki5yv10cDB2UcrT4-utIZnLN353S5Q=.02153eed-7419-44b5-a1ca-e80ab643f1a2@github.com>

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

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

  Editing check added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28627/files
  - new: https://git.openjdk.org/jdk/pull/28627/files/2e73a54e..8fdcf57d

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

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

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

From serb at openjdk.org  Tue Dec  9 01:49:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Dec 2025 01:49:05 GMT
Subject: RFR: 8372554: Test windows-x64-cmp-baseline failed due to
 differences with splashscreen object file
In-Reply-To: <ovMdGMh57zqdRkC7et162euR6hyjSUNJG5775Jq0ZHs=.b83fa0c8-5edd-41bb-8031-61b6c264cd74@github.com>
References: <ECFKkF7DlaD0k5ueiaz9ix8UlxC-RjrjYzNH5hiYXew=.e2238f80-cea9-4030-a6e0-72f904d239c1@github.com>
 <oNHSvZmtOo5HESCHJzU_xGb9x9Yzck9ik6y-g-1SFTU=.3924ebe8-52e2-4839-838c-6c5f508e5b8f@github.com>
 <ovMdGMh57zqdRkC7et162euR6hyjSUNJG5775Jq0ZHs=.b83fa0c8-5edd-41bb-8031-61b6c264cd74@github.com>
Message-ID: <RGb2HYdRpe6NO3inQ6Fy0iJui-IgA4r_gXgwx5X8HjA=.127b204a-da7e-4c62-ac95-7d71e167416a@github.com>

On Tue, 9 Dec 2025 01:04:55 GMT, Phil Race <prr at openjdk.org> wrote:

> SFAIU it checks if builds are reproducible. You can go look for yourself.

Does that task use "make COMPARE_BUILD" or call "compare.sh", or do something else? Was only the windows build affected?

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

PR Comment: https://git.openjdk.org/jdk/pull/28712#issuecomment-3629826864

From serb at openjdk.org  Tue Dec  9 03:30:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Dec 2025 03:30:57 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
Message-ID: <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>

On Tue, 9 Dec 2025 01:36:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> ok check added..

One question about the change in GenericEditor: if all editor-related fields in JTable are transient, then why do we still get an error saying that GenericEditor cannot be serialized? Where does the reference to it come from? Possibly from some listeners, if yes then at what point we clear that references?

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3630078033

From psadhukhan at openjdk.org  Tue Dec  9 03:49:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 03:49:55 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
Message-ID: <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>

On Tue, 9 Dec 2025 03:28:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > ok check added..
> 
> One question about the change in GenericEditor: if all editor-related fields in JTable are transient, then why do we still get an error saying that GenericEditor cannot be serialized? Where does the reference to it come from? Possibly from some listeners, if yes then at what point we clear that references?

GenericEditor extends DefaultCellEditor which extends AbstractCellEditor which is Serializable so I guess by default that class becomes Serializable but in JTable other things are pointing to the fact editing should not be serialized so we have made the field in GenericEditor transient.

/** If editing, the <code>Component</code> that is handling the editing. */
    protected transient Component       editorComp;

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3630124437

From serb at openjdk.org  Tue Dec  9 03:55:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Dec 2025 03:55:56 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
Message-ID: <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>

On Tue, 9 Dec 2025 03:47:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> GenericEditor extends DefaultCellEditor which extends AbstractCellEditor which is Serializable so I guess by default that class becomes Serializable but in JTable other things are pointing to the fact editing should not be serialized so we have made the field in GenericEditor transient.

It is not serialized by "default", it is only serialized if it is referenced from somewhere. In our case, it is referenced from somewhere inside JTable, which we tried to serialize.

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3630136727

From psadhukhan at openjdk.org  Tue Dec  9 03:59:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 03:59:56 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
Message-ID: <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>

On Tue, 9 Dec 2025 03:52:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > GenericEditor extends DefaultCellEditor which extends AbstractCellEditor which is Serializable so I guess by default that class becomes Serializable but in JTable other things are pointing to the fact editing should not be serialized so we have made the field in GenericEditor transient.
> 
> It is not serialized by "default", it is only serialized if it is referenced from somewhere. In our case, it is referenced from somewhere inside JTable, which we tried to serialize.

GenericEditor is instantiated from JTable contstuctor
JTable->initializeLocalVars->createDefaultEditors->new GenericEditor()
so when JTable gets serialized in writeObject it calls `s.defaultWriteObject()` which tried to serialize this class by default which it can't so we got an exception..

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3630144892

From serb at openjdk.org  Tue Dec  9 05:10:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 9 Dec 2025 05:10:58 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
Message-ID: <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>

On Tue, 9 Dec 2025 03:57:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>GenericEditor is instantiated from JTable contstuctor
JTable->initializeLocalVars->createDefaultEditors->new GenericEditor()
so when JTable gets serialized in writeObject it calls s.defaultWriteObject() which tried to serialize this class by default which it can't so we got an exception..

It does not matter that we created this object; it is only serialized if it is referenced by the JTable we are serializing or by other objects that are referenced by the JTable.

All references to the editor are marked as transient, so the GenericEditor should not be stored by the JTable. After deserialization, it should be restored by calling readObject() ? createDefaultEditors().

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3630342909

From psadhukhan at openjdk.org  Tue Dec  9 05:17:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 05:17:54 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
Message-ID: <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>

On Tue, 9 Dec 2025 05:08:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > GenericEditor is instantiated from JTable contstuctor
> > JTable->initializeLocalVars->createDefaultEditors->new GenericEditor()
> > so when JTable gets serialized in writeObject it calls s.defaultWriteObject() which tried to serialize this class by default which it can't so we got an exception..
> 
> It does not matter that we created this object; it is only serialized if it is referenced by the JTable we are serializing or by other objects that are referenced by the JTable.
> 
> All references to the editor are marked as transient, so the GenericEditor should not be stored by the JTable. After deserialization, it should be restored by calling readObject() ? createDefaultEditors().

I dont understand what you are trying to say. WHen JTable is serialized, writeObject also tries to serialize inner GenericEditor class (which is by default Serializable) which it fails to do..I dont see any other way of it being serialized..

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3630359746

From smandalika at openjdk.org  Tue Dec  9 05:57:01 2025
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Tue, 9 Dec 2025 05:57:01 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v9]
In-Reply-To: <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
Message-ID: <tjB5ks7s9SIc7GRtLjDSvUZye-iA4SpgZC2BarH0-NM=.f1b6fe29-841d-4cf8-b33c-9d147056a493@github.com>

On Wed, 26 Nov 2025 10:11:43 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
>> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt.
>
> Srinivas Mandalika has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Trigger the bot.
>  - Merge branch '8068378' of github.com:srmandal/jdk into 8068378
>  - Merge branch 'master' of github.com:openjdk/jdk into 8068378
>  - Added line after subsection name
>  - Merge master
>  - Fixed Typos
>  - Fixed whitepsace error.
>  - 8068378: Review feedback for instructions, missing break in switch case in Test.java
>  - Removed Merge Conflict from PL file.
>  - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update

Hello. This MR has been reviewed and is now complete. Can somebody sponsor it, so it can be integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3630469194

From tr at openjdk.org  Tue Dec  9 05:59:58 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 9 Dec 2025 05:59:58 GMT
Subject: RFR: 5107379: Component orientation in JOptionPane is not proper
 in Motif L&F.
In-Reply-To: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
References: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
Message-ID: <Nx7VxWfSS0zPWh6WNXMBnJVL-C5oVk3f2uTBY0Mmutk=.5a55355f-12c5-4eca-bc40-1f86566940c0@github.com>

On Thu, 27 Nov 2025 12:32:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is icon in JOptionPane is not aligned as per the Component Orientation in Motif LookAndFeel.
> It seems only the buttons are aligned as per component orientation whereas the icon is not.
> 
> It is because the icon is drawn at "West" constraint whereas it should be drawn at beginning of line as done in BasicOptionPaneUI to ensure component orientation is honoured.

test/jdk/javax/swing/plaf/motif/TestIconRTL.java line 35:

> 33: import java.awt.ComponentOrientation;
> 34: import java.util.HashMap;
> 35: import java.util.Map;

Unused imports.

test/jdk/javax/swing/plaf/motif/TestIconRTL.java line 44:

> 42: import javax.swing.SwingUtilities;
> 43: import javax.swing.UIManager;
> 44: import javax.swing.UnsupportedLookAndFeelException;

Unused import.

test/jdk/javax/swing/plaf/motif/TestIconRTL.java line 53:

> 51:     static final String INSTRUCTIONS = """
> 52:         A JOptionPane is shown in Motif LookAndFeel.
> 53:         Test with LTR and RTL Orientation

Adding the instructions on where to change the Orientation would bring more clarity. Since user can change from Menubar, it would be better to add that note.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28532#discussion_r2601206300
PR Review Comment: https://git.openjdk.org/jdk/pull/28532#discussion_r2601205756
PR Review Comment: https://git.openjdk.org/jdk/pull/28532#discussion_r2601204508

From psadhukhan at openjdk.org  Tue Dec  9 06:11:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 06:11:16 GMT
Subject: RFR: 5107379: Component orientation in JOptionPane is not proper
 in Motif L&F. [v2]
In-Reply-To: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
References: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
Message-ID: <EQsMsWXpLEjZSwUY67pX9Z3EUOn_PLmuuK4EV5F4YfM=.197c1844-884a-497a-90bc-fe5bdd804f49@github.com>

> Issue is icon in JOptionPane is not aligned as per the Component Orientation in Motif LookAndFeel.
> It seems only the buttons are aligned as per component orientation whereas the icon is not.
> 
> It is because the icon is drawn at "West" constraint whereas it should be drawn at beginning of line as done in BasicOptionPaneUI to ensure component orientation is honoured.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28532/files
  - new: https://git.openjdk.org/jdk/pull/28532/files/52c2dd16..b825d01a

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

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

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

From psadhukhan at openjdk.org  Tue Dec  9 06:11:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 06:11:19 GMT
Subject: RFR: 5107379: Component orientation in JOptionPane is not proper
 in Motif L&F. [v2]
In-Reply-To: <Nx7VxWfSS0zPWh6WNXMBnJVL-C5oVk3f2uTBY0Mmutk=.5a55355f-12c5-4eca-bc40-1f86566940c0@github.com>
References: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
 <Nx7VxWfSS0zPWh6WNXMBnJVL-C5oVk3f2uTBY0Mmutk=.5a55355f-12c5-4eca-bc40-1f86566940c0@github.com>
Message-ID: <GAezTZrWCzgdqG8Epk1ZhPbmjMhaZlZKWA8xsZzjhtU=.30beac5b-7385-4cdc-a203-ade6bb19f824@github.com>

On Tue, 9 Dec 2025 05:57:14 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fix
>
> test/jdk/javax/swing/plaf/motif/TestIconRTL.java line 35:
> 
>> 33: import java.awt.ComponentOrientation;
>> 34: import java.util.HashMap;
>> 35: import java.util.Map;
> 
> Unused imports.

fixed

> test/jdk/javax/swing/plaf/motif/TestIconRTL.java line 44:
> 
>> 42: import javax.swing.SwingUtilities;
>> 43: import javax.swing.UIManager;
>> 44: import javax.swing.UnsupportedLookAndFeelException;
> 
> Unused import.

fixed

> test/jdk/javax/swing/plaf/motif/TestIconRTL.java line 53:
> 
>> 51:     static final String INSTRUCTIONS = """
>> 52:         A JOptionPane is shown in Motif LookAndFeel.
>> 53:         Test with LTR and RTL Orientation
> 
> Adding the instructions on where to change the Orientation would bring more clarity. Since user can change from Menubar, it would be better to add that note.

ok added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28532#discussion_r2601224916
PR Review Comment: https://git.openjdk.org/jdk/pull/28532#discussion_r2601224697
PR Review Comment: https://git.openjdk.org/jdk/pull/28532#discussion_r2601224575

From psadhukhan at openjdk.org  Tue Dec  9 06:17:23 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 06:17:23 GMT
Subject: RFR: 5107379: Component orientation in JOptionPane is not proper
 in Motif L&F. [v3]
In-Reply-To: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
References: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
Message-ID: <g-Y-rPYZpcls6LtwZJhhZ2XZMQhH3uAdratEvF46uag=.6d236aa9-91bc-401c-9598-6060ae17add3@github.com>

> Issue is icon in JOptionPane is not aligned as per the Component Orientation in Motif LookAndFeel.
> It seems only the buttons are aligned as per component orientation whereas the icon is not.
> 
> It is because the icon is drawn at "West" constraint whereas it should be drawn at beginning of line as done in BasicOptionPaneUI to ensure component orientation is honoured.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28532/files
  - new: https://git.openjdk.org/jdk/pull/28532/files/b825d01a..ade6de66

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

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

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

From tr at openjdk.org  Tue Dec  9 07:40:58 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 9 Dec 2025 07:40:58 GMT
Subject: RFR: 5107379: Component orientation in JOptionPane is not proper
 in Motif L&F. [v3]
In-Reply-To: <g-Y-rPYZpcls6LtwZJhhZ2XZMQhH3uAdratEvF46uag=.6d236aa9-91bc-401c-9598-6060ae17add3@github.com>
References: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
 <g-Y-rPYZpcls6LtwZJhhZ2XZMQhH3uAdratEvF46uag=.6d236aa9-91bc-401c-9598-6060ae17add3@github.com>
Message-ID: <eG2J00TVTXL3ye7s8ZaBczeSIje_YhqcBJk6a4Y77pY=.22337660-d367-4e36-84c6-2362436f8029@github.com>

On Tue, 9 Dec 2025 06:17:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is icon in JOptionPane is not aligned as per the Component Orientation in Motif LookAndFeel.
>> It seems only the buttons are aligned as per component orientation whereas the icon is not.
>> 
>> It is because the icon is drawn at "West" constraint whereas it should be drawn at beginning of line as done in BasicOptionPaneUI to ensure component orientation is honoured.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28532#pullrequestreview-3555923358

From psadhukhan at openjdk.org  Tue Dec  9 07:44:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 07:44:10 GMT
Subject: Integrated: 5107379: Component orientation in JOptionPane is not
 proper in Motif L&F.
In-Reply-To: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
References: <AN0poCwjW13XTId5piJBTDtvWoqQUrIi-ZD3Nj3f2dY=.dd19fb88-c6c6-450d-b08a-a033fa92b66b@github.com>
Message-ID: <lNEDwslYPR9CqtP_YHM_N_jdPhX0yG-xxFjIJUhSurE=.4efa27ce-7ee7-4567-b008-170c4829d701@github.com>

On Thu, 27 Nov 2025 12:32:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is icon in JOptionPane is not aligned as per the Component Orientation in Motif LookAndFeel.
> It seems only the buttons are aligned as per component orientation whereas the icon is not.
> 
> It is because the icon is drawn at "West" constraint whereas it should be drawn at beginning of line as done in BasicOptionPaneUI to ensure component orientation is honoured.

This pull request has now been integrated.

Changeset: cba09cd1
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cba09cd10d4e4482852a317786242836419c313b
Stats:     122 lines in 2 files changed: 120 ins; 0 del; 2 mod

5107379: Component orientation in JOptionPane is not proper in Motif L&F.

Reviewed-by: tr, kizune

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

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

From azvegint at openjdk.org  Tue Dec  9 09:06:03 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 9 Dec 2025 09:06:03 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v3]
In-Reply-To: <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
Message-ID: <wSswtjYH7s2xnUPzXpAcFs2y24Mo6rtYfGE6CByUCNE=.4208fa36-0f45-48e5-9e44-309d04e5a2d7@github.com>

On Tue, 9 Dec 2025 00:36:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
>> 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
>> 
>> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
>> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix update...ActionMap test added

I assume that testing looks good on all platforms.

src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1839:

> 1837:     public static void replaceUIActionMap(JComponent component,
> 1838:                                           ActionMap uiActionMap) {
> 1839:         ActionMap map = component.getActionMap((uiActionMap != null));

Another approach would be to nullify the map.
In this case we don't modify the previously stored map. If a user stores a link to it, they can reuse it later. 

Suggestion:

if (uiActionMap == null) {
    component.setActionMap(null);
    return;
}

ActionMap map = component.getActionMap(true);

However, this will also require updating the JComponent code to reset the flags.

https://github.com/openjdk/jdk/blob/cba09cd10d4e4482852a317786242836419c313b/src/java.desktop/share/classes/javax/swing/JComponent.java#L2524-L2527


It may be worth considering this option.

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28671#pullrequestreview-3556234129
PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2601704720

From tr at openjdk.org  Tue Dec  9 09:47:08 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 9 Dec 2025 09:47:08 GMT
Subject: RFR: 4459231: Focus of JTabbedPane(with Scrollable tablayout)
 changes on change in LookAndFeel [v2]
In-Reply-To: <fS4_Ed5-x7BXBAcq2sNWYr7ZacfIAE_fDtsJS-fqhfg=.1a062315-560f-4ab9-9b11-2d09290b27c5@github.com>
References: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
 <fS4_Ed5-x7BXBAcq2sNWYr7ZacfIAE_fDtsJS-fqhfg=.1a062315-560f-4ab9-9b11-2d09290b27c5@github.com>
Message-ID: <zZsay3jmKRh8Xc7RtgQNuJgjwE4KiZ3_Hp3RU1dPSWI=.f2aece81-a4f9-43b1-9318-98edcac06bea@github.com>

On Mon, 1 Dec 2025 09:46:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On changing LookAndFeel of JTabbedPane, it resets the focus of the child tabs to starting child tab.
>> That is, if a JTabbedPane has say 10 tabs and we select the 10th tab and then we change the L&F, the focus is shifted to Tab0 even though the selected tab is still at 10th tab.
>> 
>> This is because when we switch L&F, `installUI ` will reset the `focusIndex ` 
>> https://github.com/openjdk/jdk/blob/3481252ced7c06c44154ceccc56b12cfd9a490c3/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L285-L290
>> 
>> which needs to set the proper focus by calling `scrollRectToVisible ` to selected tab which is done in this fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

test/jdk/javax/swing/JTabbedPane/TabbedPaneBugWithLNF.java line 27:

> 25:  * @test
> 26:  * @bug 4459231
> 27:  * @summary Verifies getBaseline causes NPE for Nimbus L&F

Summary is different, please update the summary.

test/jdk/javax/swing/JTabbedPane/TabbedPaneBugWithLNF.java line 46:

> 44:     private static JTabbedPane tabPane;
> 45:     private static JButton testBtn;
> 46:     private String labelOfCurrentJBtn = null;

`labelOfCurrentJBtn ` is unused.

test/jdk/javax/swing/JTabbedPane/TabbedPaneBugWithLNF.java line 109:

> 107:         return frame;
> 108:     }
> 109: }

I don't see any empty line here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28571#discussion_r2601789679
PR Review Comment: https://git.openjdk.org/jdk/pull/28571#discussion_r2601846046
PR Review Comment: https://git.openjdk.org/jdk/pull/28571#discussion_r2601855141

From psadhukhan at openjdk.org  Tue Dec  9 09:58:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 09:58:55 GMT
Subject: RFR: 4459231: Focus of JTabbedPane(with Scrollable tablayout)
 changes on change in LookAndFeel [v3]
In-Reply-To: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
References: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
Message-ID: <jrT5IgSeWGel87vgD92gRS1DmyBdQT1oM7QuXiV4X6g=.b8e70471-f5f9-4b8e-b4d2-94e2906a72ea@github.com>

> On changing LookAndFeel of JTabbedPane, it resets the focus of the child tabs to starting child tab.
> That is, if a JTabbedPane has say 10 tabs and we select the 10th tab and then we change the L&F, the focus is shifted to Tab0 even though the selected tab is still at 10th tab.
> 
> This is because when we switch L&F, `installUI ` will reset the `focusIndex ` 
> https://github.com/openjdk/jdk/blob/3481252ced7c06c44154ceccc56b12cfd9a490c3/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L285-L290
> 
> which needs to set the proper focus by calling `scrollRectToVisible ` to selected tab which is done in this fix.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28571/files
  - new: https://git.openjdk.org/jdk/pull/28571/files/f110cc52..f4c0db8b

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

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

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

From psadhukhan at openjdk.org  Tue Dec  9 09:59:02 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 09:59:02 GMT
Subject: RFR: 4459231: Focus of JTabbedPane(with Scrollable tablayout)
 changes on change in LookAndFeel [v2]
In-Reply-To: <zZsay3jmKRh8Xc7RtgQNuJgjwE4KiZ3_Hp3RU1dPSWI=.f2aece81-a4f9-43b1-9318-98edcac06bea@github.com>
References: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
 <fS4_Ed5-x7BXBAcq2sNWYr7ZacfIAE_fDtsJS-fqhfg=.1a062315-560f-4ab9-9b11-2d09290b27c5@github.com>
 <zZsay3jmKRh8Xc7RtgQNuJgjwE4KiZ3_Hp3RU1dPSWI=.f2aece81-a4f9-43b1-9318-98edcac06bea@github.com>
Message-ID: <ZDbimtwPegRTFrlndoVdEhkloWghclNRWvA2eDXcnhM=.6e244369-c0a7-4939-8649-a5d44886b5d9@github.com>

On Tue, 9 Dec 2025 09:28:29 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test fix
>
> test/jdk/javax/swing/JTabbedPane/TabbedPaneBugWithLNF.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 4459231
>> 27:  * @summary Verifies getBaseline causes NPE for Nimbus L&F
> 
> Summary is different, please update the summary.

fixed

> test/jdk/javax/swing/JTabbedPane/TabbedPaneBugWithLNF.java line 46:
> 
>> 44:     private static JTabbedPane tabPane;
>> 45:     private static JButton testBtn;
>> 46:     private String labelOfCurrentJBtn = null;
> 
> `labelOfCurrentJBtn ` is unused.

removed

> test/jdk/javax/swing/JTabbedPane/TabbedPaneBugWithLNF.java line 109:
> 
>> 107:         return frame;
>> 108:     }
>> 109: }
> 
> I don't see any empty line here.

added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28571#discussion_r2601895390
PR Review Comment: https://git.openjdk.org/jdk/pull/28571#discussion_r2601895795
PR Review Comment: https://git.openjdk.org/jdk/pull/28571#discussion_r2601896260

From tr at openjdk.org  Tue Dec  9 10:02:25 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 9 Dec 2025 10:02:25 GMT
Subject: RFR: 4459231: Focus of JTabbedPane(with Scrollable tablayout)
 changes on change in LookAndFeel [v3]
In-Reply-To: <jrT5IgSeWGel87vgD92gRS1DmyBdQT1oM7QuXiV4X6g=.b8e70471-f5f9-4b8e-b4d2-94e2906a72ea@github.com>
References: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
 <jrT5IgSeWGel87vgD92gRS1DmyBdQT1oM7QuXiV4X6g=.b8e70471-f5f9-4b8e-b4d2-94e2906a72ea@github.com>
Message-ID: <ls2RJiE_JgQzl4IbCWD_eYe5_P1kIu2Wf3EA8jskidQ=.fb4e7429-e48c-4991-91bf-641bd8ccff7b@github.com>

On Tue, 9 Dec 2025 09:58:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> On changing LookAndFeel of JTabbedPane, it resets the focus of the child tabs to starting child tab.
>> That is, if a JTabbedPane has say 10 tabs and we select the 10th tab and then we change the L&F, the focus is shifted to Tab0 even though the selected tab is still at 10th tab.
>> 
>> This is because when we switch L&F, `installUI ` will reset the `focusIndex ` 
>> https://github.com/openjdk/jdk/blob/3481252ced7c06c44154ceccc56b12cfd9a490c3/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L285-L290
>> 
>> which needs to set the proper focus by calling `scrollRectToVisible ` to selected tab which is done in this fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

LGTM.

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28571#pullrequestreview-3556495454

From psadhukhan at openjdk.org  Tue Dec  9 10:05:23 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 10:05:23 GMT
Subject: Integrated: 4459231: Focus of JTabbedPane(with Scrollable tablayout)
 changes on change in LookAndFeel
In-Reply-To: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
References: <nJrhEyVstE1Ow0mimzwf9HAhRJw_C67j2fGL12i4MG0=.5766cafb-2d7c-4457-bd3c-4e30f8b5a7ed@github.com>
Message-ID: <KVCzFBzKxb60kgmMH6MYdUhHfSjwMrWXbsqCsUB526g=.33c473eb-00cd-4c5e-9888-2f4d9b7a49d6@github.com>

On Mon, 1 Dec 2025 08:55:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> On changing LookAndFeel of JTabbedPane, it resets the focus of the child tabs to starting child tab.
> That is, if a JTabbedPane has say 10 tabs and we select the 10th tab and then we change the L&F, the focus is shifted to Tab0 even though the selected tab is still at 10th tab.
> 
> This is because when we switch L&F, `installUI ` will reset the `focusIndex ` 
> https://github.com/openjdk/jdk/blob/3481252ced7c06c44154ceccc56b12cfd9a490c3/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L285-L290
> 
> which needs to set the proper focus by calling `scrollRectToVisible ` to selected tab which is done in this fix.

This pull request has now been integrated.

Changeset: 1f49edd9
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f49edd9783ed4579d989d6939ee75e926f0716a
Stats:     120 lines in 2 files changed: 120 ins; 0 del; 0 mod

4459231: Focus of JTabbedPane(with Scrollable tablayout) changes on change in LookAndFeel

Reviewed-by: tr, kizune

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

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

From psadhukhan at openjdk.org  Tue Dec  9 10:09:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Dec 2025 10:09:38 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v3]
In-Reply-To: <wSswtjYH7s2xnUPzXpAcFs2y24Mo6rtYfGE6CByUCNE=.4208fa36-0f45-48e5-9e44-309d04e5a2d7@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
 <wSswtjYH7s2xnUPzXpAcFs2y24Mo6rtYfGE6CByUCNE=.4208fa36-0f45-48e5-9e44-309d04e5a2d7@github.com>
Message-ID: <ywBcqBJ9OHqLzmsMQaamSaneMiR_7ncLSBL9LxgnxU0=.2f9e9429-bea5-459b-b96a-bf63f089dd28@github.com>

On Tue, 9 Dec 2025 09:03:09 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix update...ActionMap test added
>
> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1839:
> 
>> 1837:     public static void replaceUIActionMap(JComponent component,
>> 1838:                                           ActionMap uiActionMap) {
>> 1839:         ActionMap map = component.getActionMap((uiActionMap != null));
> 
> Another approach would be to nullify the map.
> In this case we don't modify the previously stored map. If a user stores a link to it, they can reuse it later. 
> 
> Suggestion:
> 
> if (uiActionMap == null) {
>     component.setActionMap(null);
>     return;
> }
> 
> ActionMap map = component.getActionMap(true);
> 
> However, this will also require updating the JComponent code to reset the flags.
> 
> https://github.com/openjdk/jdk/blob/cba09cd10d4e4482852a317786242836419c313b/src/java.desktop/share/classes/javax/swing/JComponent.java#L2524-L2527
> 
> 
> It may be worth considering this option.

I had tried with nullify by using setInputMap(null) initially but there was some CI issue with some tests with that approach so I followed this and with this, the fix is contained in this class.

.JComponent's flag set/reset method is private so any change there possibly would have needed CSR so I guess this is good for this issue..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2601937606

From azvegint at openjdk.org  Tue Dec  9 11:45:56 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 9 Dec 2025 11:45:56 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v3]
In-Reply-To: <ywBcqBJ9OHqLzmsMQaamSaneMiR_7ncLSBL9LxgnxU0=.2f9e9429-bea5-459b-b96a-bf63f089dd28@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
 <wSswtjYH7s2xnUPzXpAcFs2y24Mo6rtYfGE6CByUCNE=.4208fa36-0f45-48e5-9e44-309d04e5a2d7@github.com>
 <ywBcqBJ9OHqLzmsMQaamSaneMiR_7ncLSBL9LxgnxU0=.2f9e9429-bea5-459b-b96a-bf63f089dd28@github.com>
Message-ID: <7ojEiv6w3tuQ81PU713eBB7Tmd_w92E4El-PwUxtqGM=.c5c66434-93e4-4893-9353-0588950956ae@github.com>

On Tue, 9 Dec 2025 10:05:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> JComponent's flag set/reset method is private so any change there possibly would have needed CSR so I guess this is good for this issue..

or just change the implementation without changing the specification

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28671#discussion_r2602291963

From dgredler at openjdk.org  Tue Dec  9 17:26:45 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 9 Dec 2025 17:26:45 GMT
Subject: RFR: 8167268: StandardGlyphVector.getGlyphMetrics creates metrics
 with erroneous bounds for characters with no outline (e.g.,
 the space character ' ') [v2]
In-Reply-To: <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
 <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
Message-ID: <HLP7CASwE-hiKGobOU7oHnM9pvcVlNNt9k72hmsDT4s=.d6f24ca8-d40b-419c-99dd-cae14045288e@github.com>

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

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

This PR was also opened a few months ago, but I'm having trouble getting a second review. Does anybody have some bandwidth to review?

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

PR Comment: https://git.openjdk.org/jdk/pull/27580#issuecomment-3626838141

From duke at openjdk.org  Tue Dec  9 17:33:12 2025
From: duke at openjdk.org (Christian Heilmann)
Date: Tue, 9 Dec 2025 17:33:12 GMT
Subject: RFR: 8297191: [macos] Printing a page range with starting page > 1
 results in missing pages [v5]
In-Reply-To: <XXsDwblgu8lRugk2zjP1v9dwNhqHX8PaE871-YNKgnA=.8fec3ea9-ecdc-4926-834e-93a0c0888a11@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <XXsDwblgu8lRugk2zjP1v9dwNhqHX8PaE871-YNKgnA=.8fec3ea9-ecdc-4926-834e-93a0c0888a11@github.com>
Message-ID: <iMBcGseNc0FD2b0FDHWOXL0L81hJ_9IQSezpJkwJgZM=.a99d4ca0-a8ed-400b-82c8-5706fab78cbb@github.com>

On Wed, 26 Nov 2025 16:25:04 GMT, Christian Heilmann <duke at openjdk.org> wrote:

>> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
>> 
>> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.
>
> Christian Heilmann has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'pr/8297191' of https://github.com/christianheilmann/jdk into pr/11266
>  - added 8297191 to @bug

I run on macOS Tahoe 26.1 on an MacBook Air M3 all tests containing PageRanges:


make test TEST="jtreg:test/jdk/java/awt/print/Dialog/DestinationTest.java jtreg:test/jdk/java/awt/print/PrinterJob/DlgAttrsBug.java jtreg:test/jdk/java/awt/print/PrinterJob/PageRanges.java jtreg:test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java jtreg:test/jdk/javax/print/attribute/PageRangesException.java jtreg:test/jdk/java/awt/print/PrinterJob/PrintAttributeUpdateTest.java jtreg:test/jdk/java/awt/print/PrinterJob/PrintDlgPageable.java jtreg:test/jdk/java/awt/PrintJob/SaveDialogTitleTest.java jtreg:test/jdk/javax/print/attribute/ServiceDlgPageRangeTest.java jtreg:test/jdk/javax/print/attribute/SidesPageRangesTest.java" JTREG="MANUAL=true"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
   jtreg:test/jdk/java/awt/print/Dialog/DestinationTest.java
                                                         1     1     0     0     0   
   jtreg:test/jdk/java/awt/print/PrinterJob/DlgAttrsBug.java
                                                         1     1     0     0     0   
   jtreg:test/jdk/java/awt/print/PrinterJob/PageRanges.java
                                                         1     1     0     0     0   
   jtreg:test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java
                                                         1     1     0     0     0   
   jtreg:test/jdk/java/awt/print/PrinterJob/PrintAttributeUpdateTest.java
                                                         1     1     0     0     0   
   jtreg:test/jdk/java/awt/print/PrinterJob/PrintDlgPageable.java
                                                         1     1     0     0     0   
   jtreg:test/jdk/java/awt/PrintJob/SaveDialogTitleTest.java
>>                                                       1     0     0     1     0 <<
   jtreg:test/jdk/javax/print/attribute/ServiceDlgPageRangeTest.java
                                                         1     1     0     0     0   
==============================
TEST FAILURE


make test TEST="jtreg:test/jdk/java/awt/print/PrinterJob/PageRanges.java jtreg:test/jdk/javax/print/attribute/SidesPageRangesTest.java"

==============================
TEST FAILURE

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP   
   jtreg:test/jdk/javax/print/attribute/PageRangesException.java
                                                         1     1     0     0     0   
   jtreg:test/jdk/javax/print/attribute/SidesPageRangesTest.java
                                                         1     1     0     0     0   
==============================
TEST SUCCESS



I don't know the command on how to run the SaveDialogTitleTest successfully.
All other tests containing PageRanges were run successfully.

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

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3607291463

From serb at openjdk.org  Wed Dec 10 02:39:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 02:39:40 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
 <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
Message-ID: <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRRI0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>

On Tue, 9 Dec 2025 05:15:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>I dont understand what you are trying to say. WHen JTable is serialized, writeObject also tries to serialize inner GenericEditor class (which is by default Serializable) which it fails to do..I dont see any other way of it being serialized..

writeObject only cares about the objects we pass to it, not the static inner classes. The fact that changing the constructor field helps indicates that an instance of the GenericEditor class still exists and is being referenced somewhere.

What is the full stack trace of the exception?

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3635104026

From psadhukhan at openjdk.org  Wed Dec 10 03:41:24 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Dec 2025 03:41:24 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRRI0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
 <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
 <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRR
 I0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>
Message-ID: <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>

On Wed, 10 Dec 2025 02:36:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I dont understand what you are trying to say. WHen JTable is serialized, writeObject also tries to serialize inner GenericEditor class (which is by default Serializable) which it fails to do..I dont see any other way of it being serialized..
> 
> writeObject only cares about the objects we pass to it, not the static inner classes. The fact that changing the constructor field helps indicates that an instance of the GenericEditor class still exists and is being referenced somewhere.
> 
> What is the full stack trace of the exception?


Caused by: java.io.NotSerializableException: java.lang.reflect.Constructor
        at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1087)
        at java.base/java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1453)
        at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1410)
        at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
        at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
        at java.base/java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1453)
        at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1410)
        at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
        at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
        at java.base/java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:327)
        at java.desktop/javax.swing.event.EventListenerList.writeObject(EventListenerList.java:286)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at java.base/java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:946)
        at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1397)
        at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
        at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
        at java.base/java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1453)
        at java.base/java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:414)
        at java.desktop/javax.swing.JComponent.writeObject(JComponent.java:5632)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at java.base/java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:946)
        at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1397)
        at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
        at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
        at java.base/java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1262)
        at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1077)
        at java.base/java.io.ObjectOutputStream$PutFieldImpl.writeFields(ObjectOutputStream.java:1597)
        at java.base/java.io.ObjectOutputStream.writeFields(ObjectOutputStream.java:455)
        at java.desktop/java.awt.Container.writeObject(Container.java:3686)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at java.base/java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:946)
        at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1397)
        at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
        at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
        at java.base/java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:327)
        at EditingJTableNotSerializable.serialize(EditingJTableNotSerializable.java:45)
        at EditingJTableNotSerializable.lambda$main$0(EditingJTableNotSerializable.java:60)
        ... 9 more


It seems `JTable.editCellAt()` calls `getCellEditor()` which calls `getDefaultEditor()` which returns` javax.swing.JTable$GenericEditor` object which is then used to add a `cellEditorListener ` creating a JTable reference for the listener by calling
`
editor.addCellEditorListener(this);`

and it is not removed unless `removeEditor()` is called which is not in this case..
Not sure if this is what holding the reference and causing GenericEditor to get serialized?

SInce `readObject()` again creates a GenericEditor via `createDefaultEditors()` the same editor and therefore this listener will not be used after serialization..
Probably we should remove this listener when we enter serialization for editing JTable but it seems it throws exception before calling `JTable.writeObject` so we cannot remove the listener there..so I think present fix is good enough to make it not serialized..

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3635217678

From tr at openjdk.org  Wed Dec 10 04:30:24 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Dec 2025 04:30:24 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v3]
In-Reply-To: <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
Message-ID: <qVYOKZMtYQPM2mwO0GGQBV4llfgsSjQ8i-F1AdUekF4=.2f37c8fe-23e4-406f-88d5-19387ddb1d9b@github.com>

On Tue, 9 Dec 2025 00:36:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
>> 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
>> 
>> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
>> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix update...ActionMap test added

LGTM

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28671#pullrequestreview-3560651683

From psadhukhan at openjdk.org  Wed Dec 10 04:34:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Dec 2025 04:34:35 GMT
Subject: Integrated: 6726690: SwingUtilities.replaceUI*Map() methods do not
 remove previously installed maps
In-Reply-To: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
Message-ID: <eskclPwVLVazpuQqFMIu-qX--UwyEontPgEvX4jFu4o=.c897fb17-cb2d-4d59-a6b3-90020f13b1c1@github.com>

On Fri, 5 Dec 2025 03:01:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
> 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
> 
> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.

This pull request has now been integrated.

Changeset: 1bbbce75
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bbbce75c5e68429c2a32519eb3c36d964dcdf57
Stats:     96 lines in 2 files changed: 96 ins; 0 del; 0 mod

6726690: SwingUtilities.replaceUI*Map() methods do not remove previously installed maps

Reviewed-by: azvegint, tr

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

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

From serb at openjdk.org  Wed Dec 10 05:35:24 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 05:35:24 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
 <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
 <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRR
 I0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>
 <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>
Message-ID: <ig0A14yeXH1FZ_EJpU1SbOD4Up6ujWP0fqcSGne-boI=.b242e0c0-504f-42ac-8105-7f9eb924242f@github.com>

On Wed, 10 Dec 2025 03:38:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>Probably we should remove this listener when we enter serialization for editing JTable but it seems it throws exception before calling JTable.writeObject so we cannot remove the listener there..so I think present fix is good enough to make it not serialized..

You made the field of that object non-serializable, but the GenericEditor object itself is still serializable. After deserialization, we end up with a leaked GenericEditor instance whose "constructor" field is null. If we serialize the object multiple times, we may end up with multiple GenericEditor instances.

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3635463722

From psadhukhan at openjdk.org  Wed Dec 10 05:41:23 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Dec 2025 05:41:23 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <ig0A14yeXH1FZ_EJpU1SbOD4Up6ujWP0fqcSGne-boI=.b242e0c0-504f-42ac-8105-7f9eb924242f@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
 <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
 <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRR
 I0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>
 <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>
 <ig0A14yeXH1FZ_EJpU1SbOD4Up6ujWP0fqcSGne-boI=.b242e0c0-504f-42ac-8105-7f9eb924242f@github.com>
Message-ID: <pP127MWTGQT0_5DRiRRNmjmIEjZyaWP-NUsmPKjIBHY=.b64db23b-0639-4d7d-8a04-b59b813e8a17@github.com>

On Wed, 10 Dec 2025 05:33:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Probably we should remove this listener when we enter serialization for editing JTable but it seems it throws exception before calling JTable.writeObject so we cannot remove the listener there..so I think present fix is good enough to make it not serialized..
> 
> You made the field of that object non-serializable, but the GenericEditor object itself is still serializable. After deserialization, we end up with a leaked GenericEditor instance whose "constructor" field is null. If we serialize the object multiple times, we may end up with multiple GenericEditor instances.

ok..you are telling the problem but there is no discernible solution to it..we need to remove the editor only during serialization but writeObject is not getting called..any solution you have in mind..

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3635474599

From serb at openjdk.org  Wed Dec 10 06:37:23 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 06:37:23 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <pP127MWTGQT0_5DRiRRNmjmIEjZyaWP-NUsmPKjIBHY=.b64db23b-0639-4d7d-8a04-b59b813e8a17@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
 <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
 <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRR
 I0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>
 <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>
 <ig0A14yeXH1FZ_EJpU1SbOD4Up6ujWP0fqcSGne-boI=.b242e0c0-504f-42ac-8105-7f9eb924242f@github.com>
 <pP127MWTGQT0_5DRiRRNmjmIEjZyaWP-NUsmPKjIBHY=.b64db23b-0639-4d7d-8a04-b59b813e8a17@github.com>
Message-ID: <dHrJGbskFguKZ_UZbWByPIJRq_CjMGWq2P5AkqUQLK4=.6adb849c-da2e-483e-97af-75ead3318a68@github.com>

On Wed, 10 Dec 2025 05:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>ok..you are telling the problem but there is no discernible solution to it..we need to remove the editor only during serialization but writeObject is not getting called..any solution you have in mind..

Did you check that this actually correct? by deleting that listener in some test code?

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3635609728

From mbaesken at openjdk.org  Wed Dec 10 13:41:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Dec 2025 13:41:38 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
Message-ID: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>

[JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

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

Commit messages:
 - JDK-8373388

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

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

From erikj at openjdk.org  Wed Dec 10 14:07:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 Dec 2025 14:07:56 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <Y6uRrEZokjj_06u_pyx2CUcZYenwf-uzko7aaHN8D6A=.6c5722b2-2381-41ff-8c70-1f94fbeb8089@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28746#pullrequestreview-3562713414

From psadhukhan at openjdk.org  Wed Dec 10 14:22:22 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Dec 2025 14:22:22 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v3]
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: <M2HoCgtoNW0FFuwIy5eAQI9bJ2QVi0TbAGfbIQzISao=.48bdcc54-ff69-4ede-a8d8-6452c765a9ad@github.com>

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

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

  Prevent GenericEditor serialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28627/files
  - new: https://git.openjdk.org/jdk/pull/28627/files/8fdcf57d..504606d4

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

  Stats: 57 lines in 2 files changed: 40 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28627/head:pull/28627

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

From psadhukhan at openjdk.org  Wed Dec 10 14:22:23 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Dec 2025 14:22:23 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
 <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
 <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRR
 I0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>
 <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>
Message-ID: <jUBvcq1eKdQKdHtcY6HhplZA8-bojrWKDAft6nW4gl4=.6dfe2475-626c-49c1-9ff7-98aad1e8fdac@github.com>

On Wed, 10 Dec 2025 03:38:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > I dont understand what you are trying to say. WHen JTable is serialized, writeObject also tries to serialize inner GenericEditor class (which is by default Serializable) which it fails to do..I dont see any other way of it being serialized..
> > 
> > 
> > writeObject only cares about the objects we pass to it, not the static inner classes. The fact that changing the constructor field helps indicates that an instance of the GenericEditor class still exists and is being referenced somewhere.
> > What is the full stack trace of the exception?
> 
> ```
> Caused by: java.io.NotSerializableException: java.lang.reflect.Constructor
>         at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1087)
>         at java.base/java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1453)
>         at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1410)
>         at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
>         at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
>         at java.base/java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1453)
>         at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1410)
>         at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
>         at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
>         at java.base/java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:327)
>         at java.desktop/javax.swing.event.EventListenerList.writeObject(EventListenerList.java:286)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at java.base/java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:946)
>         at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1397)
>         at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
>         at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
>         at java.base/java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1453)
>         at java.base/java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:414)
>         at java.desktop/javax.swing.JComponent.writeObject(JComponent.java:5632)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at java.base/java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:946)
>         at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1397)
>         at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
>         at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
>         at java.base/java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1262)
>         at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1077)
>         at java.base/java.io.ObjectOutputStream$PutFieldImpl.writeFields(ObjectOutputStream.java:1597)
>         at java.base/java.io.ObjectOutputStream.writeFields(ObjectOutputStream.java:455)
>         at java.desktop/java.awt.Container.writeObject(Container.java:3686)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at java.base/java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:946)
>         at java.base/java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1397)
>         at java.base/java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1319)
>         at java.base/java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
>         at java.base/java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:327)
>         at EditingJTableNotSerializable.serialize(EditingJTableNotSerializable.java:45)
>         at EditingJTableNotSerializable.lambda$main$0(EditingJTableNotSerializable.java:60)
>         ... 9 more
> ```
> 
> It seems `JTable.editCellAt()` calls `getCellEditor()` which calls `getDefaultEditor()` which returns` javax.swing.JTable$GenericEditor` object which is then used to add a `cellEditorListener ` creating a JTable reference for the listener by calling ` editor.addCellEditorListener(this);`
> 
> and it is not removed unless `removeEditor()` is called which is not in this case.. Not sure if this is what holding the reference and causing GenericEditor to get serialized?
> 
> SInce `readObject()` again creates a GenericEditor via `createDefaultEditors()` the same editor and therefore this listener will not be used after serialization.. Probably we should remove this listener when we enter serialization for editing JTable but it seems it throws exception before calling `JTable.writeObject` so we cannot remove the listener there..so I think present fix is good enough to make it not serialized..

Fixed GenericEditor serialization

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3637309995

From prr at openjdk.org  Wed Dec 10 17:21:32 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Dec 2025 17:21:32 GMT
Subject: RFR: 8334549: [Sound] Test timed out:
 javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
Message-ID: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>

This sound test appears to need the sound key which is needed so that it can be filtered (in or out) depending on whether sound resources / devices are available in a test environment.

This sound test passes (as tested many times) when run in such an environment, so I here add the key.

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

Commit messages:
 - 8334549

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

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

From serb at openjdk.org  Wed Dec 10 17:42:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 17:42:47 GMT
Subject: RFR: 8334549: [Sound] Test timed out:
 javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
In-Reply-To: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
References: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
Message-ID: <9e-rMMcdVfOgmyP792BSoIU4RylHCNGva4XXqAG8g94=.2b1512ff-8c6c-4fe9-9c83-cc541e45926a@github.com>

On Wed, 10 Dec 2025 17:15:00 GMT, Phil Race <prr at openjdk.org> wrote:

> This sound test appears to need the sound key which is needed so that it can be filtered (in or out) depending on whether sound resources / devices are available in a test environment.
> 
> This sound test passes (as tested many times) when run in such an environment, so I here add the key.

What is the exception that caused it to fail when no hardware is present on the system? This test was expected to verify that invalid parameters were passed to the method and that it should throw an IllegalArgumentException. Therefore, it should work both with and without audio devices.

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

PR Comment: https://git.openjdk.org/jdk/pull/28752#issuecomment-3638238006

From serb at openjdk.org  Wed Dec 10 18:13:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 18:13:58 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <l2PfGyWhzgdXP9ENWl8KMz13oli85FnIS5j_a5YcU4s=.82032da5-dd0a-4a3d-9224-ba8cf4739b4e@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

Don?t we need to wait until https://github.com/openjdk/jdk/pull/28676 is fixed?

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

PR Comment: https://git.openjdk.org/jdk/pull/28746#issuecomment-3638249484

From serb at openjdk.org  Wed Dec 10 18:14:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 18:14:01 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable
In-Reply-To: <jUBvcq1eKdQKdHtcY6HhplZA8-bojrWKDAft6nW4gl4=.6dfe2475-626c-49c1-9ff7-98aad1e8fdac@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <Wx_p_ED4UiOHsLEiP3gj2sy5VBHdo8-prEnwreSA33w=.e4c1d4da-e5a1-42c4-a4ab-86c8d6724f4e@github.com>
 <En9RnvBi2shwlSuBJy40eUWdTeKuuJPoLk1zJnzCd80=.c8fa95ba-1cd4-4081-bb5e-2cb44823a57e@github.com>
 <LwiFhq_2IGQVzp5unUeqskpgeuKIQobwR0bVPGBZkdQ=.c4ac1fae-24be-416b-b607-ad2d47b03670@github.com>
 <ElMZDzhF7p5pqoI5hsOM3DHi_ZWHQBjsspKTyLUHyfI=.6e62c740-2682-442e-8254-7a41110d402e@github.com>
 <4z33mjoWb9KUJK8W6T9lUvql5AEpqHc-kiX05Wwuzts=.f4f49826-e514-4cb3-9310-0b5a07a2275d@github.com>
 <vO5tClkbv2IkndtFxvV68qFM5aueTuK2uHJI-cM3G94=.82509ee7-1c48-4ed2-846c-1dee21856e24@github.com>
 <b_brsMIcpwWpRQq9ThFFPZQcej5y6b0U1gTLfL9GYKw=.8872ae14-0cb4-41bb-9ffc-56a605aaa289@github.com>
 <FaK_omk0tKmoJk6ZLuUkNQ0a2GMuYaWaZJ6DX0Q_Ijw=.418611e6-c5ca-4453-8399-1e0bb6bc0be7@github.com>
 <hN46chYEbw1A1T6U2xil0Sw_8nyrU-OL87dG67wFMLE=.928007a9-0a75-4e1a-9579-8f50b644b484@github.com>
 <u_wBV41KG6x3SKufrAlSqJLLplfMDOl9gRR
 I0ckOR18=.56693782-ce29-4c23-aedc-2ef2b28da392@github.com>
 <wAh3--kZvMxCCRpEbyvmuQHuGdtsjdT38WAAEFXl8EA=.d1633e1d-333c-4b60-9861-d6cb0c5ac8fe@github.com>
 <jUBvcq1eKdQKdHtcY6HhplZA8-bojrWKDAft6nW4gl4=.6dfe2475-626c-49c1-9ff7-98aad1e8fdac@github.com>
Message-ID: <pvIgxSAs5iP8NmCF0dNroAj8FtRv2zZwhsuv5L2hPHk=.438625b8-a8e0-4e16-a8b2-bd26a514e4d3@github.com>

On Wed, 10 Dec 2025 14:19:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>CellEditor listener removed to fix GenericEditor instance leakage during serialization

I'm confused. the patch either need to mark everything as transient and remove all references to the editor so that the code related to the editor does not get serialized, or we need to fix GenericEditor so that it can be serialized, but then it must be used correctly after deserialization.

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3638318638

From prr at openjdk.org  Wed Dec 10 18:14:01 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Dec 2025 18:14:01 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <9pnHoz75EZSdvg9K9xYhdElxZabVk_34qB877xxAmdg=.69ebe4c6-3919-418c-b6f0-3f2581f22dc2@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

Why was it enabled in the first place ?

Do not integrate this without my review/approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/28746#issuecomment-3638275604
PR Comment: https://git.openjdk.org/jdk/pull/28746#issuecomment-3638279475

From aivanov at openjdk.org  Wed Dec 10 18:13:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 10 Dec 2025 18:13:58 GMT
Subject: RFR: 8334549: [Sound] Test timed out:
 javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
In-Reply-To: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
References: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
Message-ID: <G4P03tzawiL0fELudzjdvXOjgKvdFrbNFlwGjeg5Ys0=.d1de77db-a4fb-4ea6-ace6-1190e2a4942f@github.com>

On Wed, 10 Dec 2025 17:15:00 GMT, Phil Race <prr at openjdk.org> wrote:

> This sound test appears to need the sound key which is needed so that it can be filtered (in or out) depending on whether sound resources / devices are available in a test environment.
> 
> This sound test passes (as tested many times) when run in such an environment, so I here add the key.

Looks good to me.

Shall we bump the copyright year?

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28752#pullrequestreview-3563776577

From serb at openjdk.org  Wed Dec 10 18:14:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 18:14:01 GMT
Subject: RFR: 8334549: [Sound] Test timed out:
 javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
In-Reply-To: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
References: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
Message-ID: <uQagtr4QOIKu5HYsv3fX9k4pJw5PgjQdCE5ULU5kDE0=.92aae8f6-09b9-4f22-a0f6-b8f0ba4993db@github.com>

On Wed, 10 Dec 2025 17:15:00 GMT, Phil Race <prr at openjdk.org> wrote:

> This sound test appears to need the sound key which is needed so that it can be filtered (in or out) depending on whether sound resources / devices are available in a test environment.
> 
> This sound test passes (as tested many times) when run in such an environment, so I here add the key.

Is it fails on the same environment mentioned here https://github.com/openjdk/jdk/pull/28382? As said in that PR, if it really hangs that looks like a product bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/28752#issuecomment-3638252898

From prr at openjdk.org  Wed Dec 10 18:14:28 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Dec 2025 18:14:28 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v3]
In-Reply-To: <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
Message-ID: <YBJDW_rvRzBsHmYEqe_tqBlH9IhbsBpdS8pQtucrrck=.7441cff0-fd5c-42e8-9736-b9160f3820eb@github.com>

On Tue, 9 Dec 2025 00:36:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> `SwingUtilities.replaceUIInputMap()` and `SwingUtilities.replaceUIActionMap()` do not actually remove previously installed maps as their Javadoc indicates if `null` is passed as `uiInputMap`/`uiActionMap`
>> 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1802-L1803
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/SwingUtilities.java#L1827-L1828
>> 
>> If the passed  `uiInputMap`/`uiActionMap` is null, `JComponent` actually doesn't create a fresh map and returns the previously installed map 
>> https://github.com/openjdk/jdk/blob/7e91d34f3e83b4c39d6ce5de34373d7d74d54512/src/java.desktop/share/classes/javax/swing/JComponent.java#L2586-L2595
>> which is in contradiction to the `replaceUI*Map` spec so `SwingUtilities `needs to clear the previously installed map which is being done in this fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix update...ActionMap test added

This change worries me. How was it tested ?
I see MANY places (dozens and dozens) that Swing internally passes null to these calls.
The behaviour of these is now changed. 
@prsadhuk please explain how this is a safe change and if you examined all of the usages of this with null ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28671#issuecomment-3638305053

From dnguyen at openjdk.org  Wed Dec 10 20:02:34 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 10 Dec 2025 20:02:34 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
Message-ID: <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>

> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
> 
> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.

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

  Space out batches of frames

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28646/files
  - new: https://git.openjdk.org/jdk/pull/28646/files/a493bce6..7f623fc7

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

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

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

From dnguyen at openjdk.org  Wed Dec 10 20:02:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 10 Dec 2025 20:02:36 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v2]
In-Reply-To: <NIqegaw0kwaaiMcqYN-2Eq1NC91z8all3hp-uGjvtYY=.c91ff986-07fe-4e98-a008-86753f847782@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <EuGQl4L1yElxktIP8geV3BdgaAAMI2rX61nhtc9E8Ss=.7ed846f8-af61-4d6f-9891-6c0697172f33@github.com>
 <NIqegaw0kwaaiMcqYN-2Eq1NC91z8all3hp-uGjvtYY=.c91ff986-07fe-4e98-a008-86753f847782@github.com>
Message-ID: <6D0UIrWHvDAOSYOnI2ohlzXxQrAv3YClF0hFFZ6us_w=.4a3d829c-2df0-432c-a9f7-cfb13f5ae8db@github.com>

On Mon, 8 Dec 2025 10:53:56 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix curly brace issue when moving code
>
> test/jdk/java/awt/Frame/FrameVisualTest.java line 95:
> 
>> 93:                     });
>> 94:                     Rectangle rect = new Rectangle(p, d);
>> 95:                     BufferedImage img = robot.createScreenCapture(rect);
> 
> https://github.com/openjdk/jdk/pull/26871#discussion_r2298835087 is still valid for the updated test.
> 
> On Ubuntu, a batch of windows opens in one place, so only the top window in the stack is checked.
> 
> <img width="157" height="144" alt="Image" src="https://github.com/user-attachments/assets/769e72e3-70f5-4cd3-970d-1385724b6b92" />

Thanks for the reminder. I have updated this to now put the frames side-by-side. I did 2 rows of 10 frames, so batches of 20. Tested this on my local Ubuntu VM and it looks like it's spaced correctly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2608031964

From prr at openjdk.org  Wed Dec 10 20:39:08 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Dec 2025 20:39:08 GMT
Subject: RFR: 8372974: Add missing @Override annotations in
 "com.sun.java.swing.plaf.gtk" package
In-Reply-To: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>
References: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>
Message-ID: <U4fBFcaFeU2-uUhvv9a5L8uuqTlS7hXRxwTJurTHT6Q=.454ca704-e69a-4678-8cf3-591021ab74a6@github.com>

On Wed, 3 Dec 2025 04:39:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.gtk` 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.
> 
> BTW, does anybody know why the gtk l&f is located in the shared code? Possibly we could move it to the unix folder, similar to how the windows l&f was moved to the windows folder in https://bugs.openjdk.org/browse/JDK-8189656 ?

Marked as reviewed by prr (Reviewer).

> BTW, does anybody know why the gtk l&f is located in the shared code?

My guess is that it is because motif is also located in shared, and it was the 'successor' to motif which was considered a multi-platform L&F because CDE/Motif was for multiple OSes.

I don't know if GTK L&F can be created/used/run except where the theming engine is available. 
Possibly in the very beginning it could have been.

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

PR Review: https://git.openjdk.org/jdk/pull/28624#pullrequestreview-3564376573
PR Comment: https://git.openjdk.org/jdk/pull/28624#issuecomment-3638868096

From kizune at openjdk.org  Wed Dec 10 20:57:54 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 10 Dec 2025 20:57:54 GMT
Subject: RFR: 8334549: [Sound] Test timed out:
 javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
In-Reply-To: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
References: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
Message-ID: <kaWH3OP7bW30qBAvYxRaFf4sBN3lE9RcX94LuTfvfiE=.576d41b6-61f0-462e-8440-c784f8dbb13e@github.com>

On Wed, 10 Dec 2025 17:15:00 GMT, Phil Race <prr at openjdk.org> wrote:

> This sound test appears to need the sound key which is needed so that it can be filtered (in or out) depending on whether sound resources / devices are available in a test environment.
> 
> This sound test passes (as tested many times) when run in such an environment, so I here add the key.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28752#pullrequestreview-3564441628

From prr at openjdk.org  Wed Dec 10 21:11:32 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Dec 2025 21:11:32 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
Message-ID: <4bRVcmYLAqpKf068J8MZ3yuarePql4rcatXvM10ck38=.31753089-9003-408b-96f0-edc4c6acf999@github.com>

On Mon, 1 Dec 2025 07:41:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
>> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
>> defined in the JTable (typically black on white) to be ignored.
>> 
>> The problem seems to stem from a call to
>> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
>> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
>> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
>> 
>> CI run is ok..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rethrow Exception

How/why does null restore the JTable-specified colors ? I don't see anything about null in the spec.
And what have people been doing the last 25 years if serializing a JTable "broke" its rendering ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28549#issuecomment-3638968217

From dholmes at openjdk.org  Wed Dec 10 21:18:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Dec 2025 21:18:53 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <UzR3fyUyKyAnViybad9ehiD3Q1FDkxmhMpvZJP-Ssfs=.0d34e30e-4ff7-4096-915b-90a6f8937cd9@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28746#pullrequestreview-3564511810

From prr at openjdk.org  Wed Dec 10 21:23:41 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Dec 2025 21:23:41 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: <tVoQiBXvzO3n0IJg8t-t7V1Kup6oDPJIWPHofOCOkRg=.1a6e716f-6759-40ea-853d-453c75671a86@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.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28528#pullrequestreview-3564527025

From prr at openjdk.org  Wed Dec 10 21:43:49 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Dec 2025 21:43:49 GMT
Subject: Integrated: 8334549: [Sound] Test timed out:
 javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
In-Reply-To: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
References: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
Message-ID: <5mLQpU1_AtgvJ8a47xWuZKQNEPpcslzLBnNXZERE400=.050d816c-767f-4a4f-a77d-4d9c287f7fe2@github.com>

On Wed, 10 Dec 2025 17:15:00 GMT, Phil Race <prr at openjdk.org> wrote:

> This sound test appears to need the sound key which is needed so that it can be filtered (in or out) depending on whether sound resources / devices are available in a test environment.
> 
> This sound test passes (as tested many times) when run in such an environment, so I here add the key.

This pull request has now been integrated.

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

8334549: [Sound] Test timed out: javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java

Reviewed-by: aivanov, kizune

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

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

From serb at openjdk.org  Wed Dec 10 21:50:06 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 21:50:06 GMT
Subject: RFR: 8372974: Add missing @Override annotations in
 "com.sun.java.swing.plaf.gtk" package
In-Reply-To: <U4fBFcaFeU2-uUhvv9a5L8uuqTlS7hXRxwTJurTHT6Q=.454ca704-e69a-4678-8cf3-591021ab74a6@github.com>
References: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>
 <U4fBFcaFeU2-uUhvv9a5L8uuqTlS7hXRxwTJurTHT6Q=.454ca704-e69a-4678-8cf3-591021ab74a6@github.com>
Message-ID: <b_0Eb-xQ3Oh9ItgAODKyGCUQk5T3dZtvBc9ETY9x66I=.edd77c4c-449c-4ccb-a5e8-4ba2238b974a@github.com>

On Wed, 10 Dec 2025 20:36:55 GMT, Phil Race <prr at openjdk.org> wrote:

>I don't know if GTK L&F can be created/used/run except where the theming engine is available.
Possibly in the very beginning it could have been.

Probably it worked on macOS when XToolkit was still supported on that platform, but now it seems we can safely move it out of the shared code.

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

PR Comment: https://git.openjdk.org/jdk/pull/28624#issuecomment-3639097229

From serb at openjdk.org  Wed Dec 10 21:54:43 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 10 Dec 2025 21:54:43 GMT
Subject: RFR: 8334549: [Sound] Test timed out:
 javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
In-Reply-To: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
References: <z5qQb5JHu44xU6YDqxk2pl-zda6eVLZSrtXnvH6z9is=.f36e1112-2103-425b-9eba-247e2a63b252@github.com>
Message-ID: <jg10WbJZWFOn7Z4mfAznEE1EELdHQufhUxgCooahYws=.5ed3aa37-a0c2-42d5-954a-2d45ac335161@github.com>

On Wed, 10 Dec 2025 17:15:00 GMT, Phil Race <prr at openjdk.org> wrote:

> This sound test appears to need the sound key which is needed so that it can be filtered (in or out) depending on whether sound resources / devices are available in a test environment.
> 
> This sound test passes (as tested many times) when run in such an environment, so I here add the key.

Is the hang considered not a product bug, or is the bug simply being ignored?

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

PR Comment: https://git.openjdk.org/jdk/pull/28752#issuecomment-3639110123

From prr at openjdk.org  Thu Dec 11 01:03:32 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 01:03:32 GMT
Subject: RFR: 8167268: StandardGlyphVector.getGlyphMetrics creates metrics
 with erroneous bounds for characters with no outline (e.g.,
 the space character ' ') [v2]
In-Reply-To: <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
 <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
Message-ID: <Vr0_LWvS6pSx-o4VH2Sv83_vDFr5-6Nc13eMD00gVmo=.94620613-79d8-461e-9b42-1e0243066fd7@github.com>

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

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

I don't know how I overlooked this bug report all this time.

I've run all our tests and looks good. Approved.

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

Marked as reviewed by prr (Reviewer).

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

From jwaters at openjdk.org  Thu Dec 11 04:23:22 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 11 Dec 2025 04:23:22 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v4]
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <mvIFT2i9hbnO-551N2dHNp6XPaDs4hBZSQ6oXVvfkH8=.b7abfd4c-5228-47d5-8ce5-f350f87d1706@github.com>

> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
> 
> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
> - -flto is set to $(JOBS) instead of auto to better match what the user requested
> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into patch-16
 - Revert recent changes to ClientLibraries.gmk
 - Revert recent changes to CompileJvm.gmk
 - Revert recent changes to Flags.gmk
 - Revert recent changes to NativeCompilation.gmk
 - Revert recent changes to spec.gmk.template
 - Revert recent changes to flags-ldflags.m4
 - Revert recent changes to flags-cflags.m4
 - Remove no longer needed warning disable in JvmFeatures.gmk
 - Merge branch 'master' into patch-16
 - ... and 12 more: https://git.openjdk.org/jdk/compare/74dca863...550f951d

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

Changes: https://git.openjdk.org/jdk/pull/22464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=03
  Stats: 60 lines in 8 files changed: 11 ins; 45 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464

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

From psadhukhan at openjdk.org  Thu Dec 11 04:26:32 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 11 Dec 2025 04:26:32 GMT
Subject: RFR: 6726690: SwingUtilities.replaceUI*Map() methods do not remove
 previously installed maps [v3]
In-Reply-To: <YBJDW_rvRzBsHmYEqe_tqBlH9IhbsBpdS8pQtucrrck=.7441cff0-fd5c-42e8-9736-b9160f3820eb@github.com>
References: <sXWWwguoxzIVj7k5CN1OKZfXP3cI5-SenuoJPNCvhO8=.06f3d386-09ed-4af5-8ffc-bb0d8ee7ee78@github.com>
 <hxnB5n8-dc8xPTivzVq8Cg48rsSspiTNYn2kMCOHMys=.7554d518-25ee-4df5-98f4-01657cf44648@github.com>
 <YBJDW_rvRzBsHmYEqe_tqBlH9IhbsBpdS8pQtucrrck=.7441cff0-fd5c-42e8-9736-b9160f3820eb@github.com>
Message-ID: <o_UG_rbYHK2oQlOJMWgebIpSZsLWOhjyqb5OZ7v5l3o=.5f65ae1c-de02-43c6-be20-6122817eb9bc@github.com>

On Wed, 10 Dec 2025 17:56:22 GMT, Phil Race <prr at openjdk.org> wrote:

> This change worries me. How was it tested ? I see MANY places (dozens and dozens) that Swing internally passes null to these calls. The behaviour of these is now changed. @prsadhuk please explain how this is a safe change and if you examined all of the usages of this with null ?

In all cases, Swing passes null to these calls in `uninstallKeyboardActions` during `uninstallUI` that is, during L&F change and it doesn't check if the map is removed or not, even though spec mandates it should. It would have seen the issue if uninstall* APIs  had tried to use the same map
 but map is reloaded and replaced by calling these methods in `installUI` so it was never problematic.
I dont know why this spec violation is never caught, apart from this bug, even by JCK test.

I have tested with all clientlibs test in CI along with SwingSet2 with L&F change and keyboard navigation works ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/28671#issuecomment-3640036120

From psadhukhan at openjdk.org  Thu Dec 11 04:27:23 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 11 Dec 2025 04:27:23 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <4bRVcmYLAqpKf068J8MZ3yuarePql4rcatXvM10ck38=.31753089-9003-408b-96f0-edc4c6acf999@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
 <4bRVcmYLAqpKf068J8MZ3yuarePql4rcatXvM10ck38=.31753089-9003-408b-96f0-edc4c6acf999@github.com>
Message-ID: <FPsM4IcqptoDEgFTMo7dTPptjAX4q6cGxiJKjO3ojMo=.c49ee558-dab6-4fee-9840-7fcf58a5673b@github.com>

On Wed, 10 Dec 2025 21:08:47 GMT, Phil Race <prr at openjdk.org> wrote:

> How/why does null restore the JTable-specified colors ? I don't see anything about null in the spec. And what have people been doing the last 25 years if serializing a JTable "broke" its rendering ?

Specifying null would cause `unselectedForeground` and `unselectedBackground` to be null
https://github.com/openjdk/jdk/blob/74dca863c2e61c13884c3454b8da7be125235970/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L146-L148

 so it will fallback to table assigned foreground and background color 

https://github.com/openjdk/jdk/blob/74dca863c2e61c13884c3454b8da7be125235970/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L215-L217
https://github.com/openjdk/jdk/blob/74dca863c2e61c13884c3454b8da7be125235970/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L224-L226

Also, as is mentioned in the review https://github.com/openjdk/jdk/pull/28549#discussion_r2570711017 discerning gray with white can be difficult and not hugely different so maybe people have lived with it

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

PR Comment: https://git.openjdk.org/jdk/pull/28549#issuecomment-3640038716

From psadhukhan at openjdk.org  Thu Dec 11 04:45:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 11 Dec 2025 04:45:41 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v4]
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: <fqsITOV_7KIrM2OcpDpv9afL9pJruGqH4A3rP5T_KyI=.7b976108-77d8-4403-8875-27c694ea0fb9@github.com>

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

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

  GenericEditor serialization fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28627/files
  - new: https://git.openjdk.org/jdk/pull/28627/files/504606d4..9f788115

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

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

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

From psadhukhan at openjdk.org  Thu Dec 11 04:45:43 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 11 Dec 2025 04:45:43 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v3]
In-Reply-To: <M2HoCgtoNW0FFuwIy5eAQI9bJ2QVi0TbAGfbIQzISao=.48bdcc54-ff69-4ede-a8d8-6452c765a9ad@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <M2HoCgtoNW0FFuwIy5eAQI9bJ2QVi0TbAGfbIQzISao=.48bdcc54-ff69-4ede-a8d8-6452c765a9ad@github.com>
Message-ID: <JYVaL3pE3qQDwRj0eHqujosbXFETawi16U7Ol-73zUU=.143d62da-3ae3-4bc9-b9b1-3b1b4b69819d@github.com>

On Wed, 10 Dec 2025 14:22:22 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..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent GenericEditor serialization

GenericEditor serialization fixed

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3640085871

From serb at openjdk.org  Thu Dec 11 07:47:24 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 11 Dec 2025 07:47:24 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v3]
In-Reply-To: <JYVaL3pE3qQDwRj0eHqujosbXFETawi16U7Ol-73zUU=.143d62da-3ae3-4bc9-b9b1-3b1b4b69819d@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <M2HoCgtoNW0FFuwIy5eAQI9bJ2QVi0TbAGfbIQzISao=.48bdcc54-ff69-4ede-a8d8-6452c765a9ad@github.com>
 <JYVaL3pE3qQDwRj0eHqujosbXFETawi16U7Ol-73zUU=.143d62da-3ae3-4bc9-b9b1-3b1b4b69819d@github.com>
Message-ID: <jNBuf-GIT27tFEN12er1eBLuyoLjV7_kzA6FTygjf_g=.fcd478e7-d7ad-471f-8113-c74caf1b1852@github.com>

On Thu, 11 Dec 2025 04:42:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> GenericEditor serialization fixed

I guess that empty writeObject/readObject methods will behave the same as making all fields transient: the reference that triggered the serialization will point to a newly deserialized object, but all fields will be null.
Does calling super.stopCellEditing() affect the behavior in any way? It bypasses the stopCellEditing implementation in GenericEditor, and the text entered in the editor will be lost.

I tried modifying the test to check whether the JTable remains functional, and it appears to be broken:


    Object[][] data = new Object[][]{ new Object[]{ 1,2,3,4,5}};
    Object[] names = new Object[]{ 1,2,3,4,5};
    JTable jt = new JTable(data, names);

    while(true) {
        jt.editCellAt(0,3);
        JTable newjt = serialize(jt);
        // another bug:
        // the editorRemover from the original jt is leaked in KeyboardFocusManager
        // so clean it here to avoid memory leak during the loop
        // otherwise the OOm is occur, we should clear that somehow
        jt.removeEditor();
        jt = newjt;
        // leak of the GenericEditor/JTextField, the number will grow over time and will cause OOM
        // and it is not possible to clean it after deserialisation we do not have a refs to it
        System.out.println("Count: " + jt.getComponentCount());
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3640656855

From mbaesken at openjdk.org  Thu Dec 11 08:30:27 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Dec 2025 08:30:27 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <S45Clg-_VURZM2sZaHGm1x4cF1ypYL7vb4uVYhx6DtQ=.271b94e1-3bb1-4e17-991c-ad81c37213b8@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

> Don?t we need to wait until #28676 is fixed?

We can wait for 8372759, no problem. ( But this issue showed up only in some special environments anyway. )

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

PR Comment: https://git.openjdk.org/jdk/pull/28746#issuecomment-3640796254

From mbaesken at openjdk.org  Thu Dec 11 08:43:26 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 11 Dec 2025 08:43:26 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <9pnHoz75EZSdvg9K9xYhdElxZabVk_34qB877xxAmdg=.69ebe4c6-3919-418c-b6f0-3f2581f22dc2@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
 <9pnHoz75EZSdvg9K9xYhdElxZabVk_34qB877xxAmdg=.69ebe4c6-3919-418c-b6f0-3f2581f22dc2@github.com>
Message-ID: <c4dWyrhCRy1CXYtHy69irOtY4Q05R-xXlrtEicqTfn4=.a5137225-0d0a-4121-be2c-3fdeed5581f0@github.com>

On Wed, 10 Dec 2025 17:48:07 GMT, Phil Race <prr at openjdk.org> wrote:

> Why was it enabled in the first place ?

At least we could identify and fix 2 bugs with enabling this (and those 2 bugs were in for 5+ years) .
If you prefer to have some 'opt-in' switch via configure for lto in the same way we have it for libjvm , we can of course discuss this and introduce it.
If your question is about 'why for libsplashscreen' , because we see some good lib size - benefits for this lib (there were some measurements by @mserb for this   https://github.com/openjdk/jdk/pull/27976#issuecomment-3568427441   ) .

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

PR Comment: https://git.openjdk.org/jdk/pull/28746#issuecomment-3640841237

From dgredler at openjdk.org  Thu Dec 11 13:53:09 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 11 Dec 2025 13:53:09 GMT
Subject: RFR: 8167268: StandardGlyphVector.getGlyphMetrics creates metrics
 with erroneous bounds for characters with no outline (e.g.,
 the space character ' ') [v2]
In-Reply-To: <Vr0_LWvS6pSx-o4VH2Sv83_vDFr5-6Nc13eMD00gVmo=.94620613-79d8-461e-9b42-1e0243066fd7@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
 <Qo9_OxFni4Po0CE0z-fwUd5xUPh9CiFlsSJKzHp8uA8=.f41911ec-9c0f-448b-82fb-de2567ed2997@github.com>
 <Vr0_LWvS6pSx-o4VH2Sv83_vDFr5-6Nc13eMD00gVmo=.94620613-79d8-461e-9b42-1e0243066fd7@github.com>
Message-ID: <d1sBKK9YIYCpdnZqAOvd8H1cSzTblK0C9KRg7mlLD_Y=.ee3f2e06-80a3-41ce-9bce-b2087accaa8b@github.com>

On Thu, 11 Dec 2025 01:00:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Split long line
>
> I don't know how I overlooked this bug report all this time.
> 
> I've run all our tests and looks good. Approved.

@prrace Thanks! PR #27544 is in the same boat, if you still have some review bandwidth.

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

PR Comment: https://git.openjdk.org/jdk/pull/27580#issuecomment-3642028277

From dgredler at openjdk.org  Thu Dec 11 13:56:20 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 11 Dec 2025 13:56:20 GMT
Subject: Integrated: 8167268: StandardGlyphVector.getGlyphMetrics creates
 metrics with erroneous bounds for characters with no outline (e.g.,
 the space character ' ')
In-Reply-To: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
References: <5ByvfoSYjN0rek4eEOaZIhSkoaDnNMAO7jiCiO0U7Yk=.6b551db8-0733-46c3-b97b-aed5754eb9a2@github.com>
Message-ID: <0BkT3D-plon8tVA9FAK6jaAoMSgOoT3nhmCKAJRNxp0=.11da9e9c-990d-4120-94e3-3b83695e034b@github.com>

On Tue, 30 Sep 2025 14:26:34 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: e1d1d53c
Author:    Daniel Gredler <dgredler at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1d1d53cd1211b64d1fef03583a23056908b3482
Stats:     80 lines in 2 files changed: 74 ins; 0 del; 6 mod

8167268: StandardGlyphVector.getGlyphMetrics creates metrics with erroneous bounds for characters with no outline (e.g., the space character ' ')

Reviewed-by: serb, prr

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

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

From aivanov at openjdk.org  Thu Dec 11 18:51:44 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Dec 2025 18:51:44 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
Message-ID: <vi10QJSjvS2-fwQM4_RvoHryV_UiV1ImS9zkRlJlGVM=.032355cf-1244-4575-9174-f74e0490058d@github.com>

On Thu, 25 Sep 2025 14:05:11 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Removes uncessary import and adds blank lines between import blocks
>  - Makes inherited method final
>  - Removes unnecessary URL
>  - Fixes a typo
>  - Removes unncessary boolean variable, line and import
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Cleans up code for move visibility
>  - Cleans up code and adds missed import
>  - ... and 56 more: https://git.openjdk.org/jdk/compare/98b872f3...59a937ac

A few more formatting suggestions.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 97:

> 95: 
> 96:     @Override
> 97:     protected final boolean isMultiFramesTest(){

Suggestion:

    protected final boolean isMultiFramesTest() {

Space between the closing parenthesis and the opening brace.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 139:

> 137: 
> 138:     @Override
> 139:     protected void cleanup(){

Suggestion:

    protected void cleanup() {

test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 69:

> 67:             frame.setVisible(false);
> 68:         }
> 69:         frame = new JFrame("Mixing : Dropdown Overlapping test");

Should the old frame be disposed of instead of just hidden?

Is it even possible that `frame` is not `null`?

test/jdk/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java line 65:

> 63:     }
> 64:     private String testSeq;
> 65:     private final static String checkSeq = "010000101";

Suggestion:

    private static final String checkSeq = "010000101";

Sort modifiers? (Not required.)

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3568531235
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2611453185
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2611461395
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2611646793
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2611674866

From aivanov at openjdk.org  Thu Dec 11 18:51:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Dec 2025 18:51:45 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <vi10QJSjvS2-fwQM4_RvoHryV_UiV1ImS9zkRlJlGVM=.032355cf-1244-4575-9174-f74e0490058d@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <vi10QJSjvS2-fwQM4_RvoHryV_UiV1ImS9zkRlJlGVM=.032355cf-1244-4575-9174-f74e0490058d@github.com>
Message-ID: <Ynyb-PLdignEOif_AAA-Dw2jQoU7jqtgDT7BOTxdrKE=.449295ba-9d22-4e7d-84e3-3e9f259feab5@github.com>

On Thu, 11 Dec 2025 18:32:06 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Removes uncessary import and adds blank lines between import blocks
>>  - Makes inherited method final
>>  - Removes unnecessary URL
>>  - Fixes a typo
>>  - Removes unncessary boolean variable, line and import
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Cleans up code for move visibility
>>  - Cleans up code and adds missed import
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/98b872f3...59a937ac
>
> test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 69:
> 
>> 67:             frame.setVisible(false);
>> 68:         }
>> 69:         frame = new JFrame("Mixing : Dropdown Overlapping test");
> 
> Should the old frame be disposed of instead of just hidden?
> 
> Is it even possible that `frame` is not `null`?

This is a question for further refactoring? No need to address it now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2611694210

From aivanov at openjdk.org  Thu Dec 11 18:58:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Dec 2025 18:58:14 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
Message-ID: <gVImOc5cH_NAHbxQ_Ja7QOwouMe0ZscYBQd-pis4OAk=.d1d3aa97-98bc-4d43-8c15-f3a84c92e430@github.com>

On Thu, 25 Sep 2025 14:05:11 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Removes uncessary import and adds blank lines between import blocks
>  - Makes inherited method final
>  - Removes unnecessary URL
>  - Fixes a typo
>  - Removes unncessary boolean variable, line and import
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Cleans up code for move visibility
>  - Cleans up code and adds missed import
>  - ... and 56 more: https://git.openjdk.org/jdk/compare/bd42f725...59a937ac

There's a conflict in `ProblemList.txt`:


- java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801 windows-all
+ java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801,8357360 windows-all,linux-all

- java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java 8294264 windows-x64
+ java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java 8370584 windows-x64


If the failures of `OpaqueOverlapping.java` is resolved by this change, then both [JDK-8294264](https://bugs.openjdk.org/browse/JDK-8294264) and [JDK-8370584](https://bugs.openjdk.org/browse/JDK-8370584) need to be closed (as duplicate of this one, [JDK-8158801](https://bugs.openjdk.org/browse/JDK-8158801)).

If `JTableInGlassPaneOverlapping.java` still fails on Linux even with this change, then `JTableInGlassPaneOverlapping.java` needs to stay in the problem list referencing [JDK-8357360](https://bugs.openjdk.org/browse/JDK-8357360).

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3643342751

From serb at openjdk.org  Thu Dec 11 19:02:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 11 Dec 2025 19:02:33 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <hkR9FsjPFlVnNBvEK_BsYAxpYgs5eAArMEyXV_WxMp4=.c4ea396d-d55b-4884-89c2-88de01463648@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28746#pullrequestreview-3568886592

From prr at openjdk.org  Thu Dec 11 19:51:41 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 19:51:41 GMT
Subject: RFR: 8368702: [macosx] Printing text with composite fonts loses
 font transform
In-Reply-To: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
References: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
Message-ID: <5CkokQstR0ckyi1fnu4zMvgz2X7aM7pKGy__ec0Tv-Q=.39e2984e-03d3-4e3a-962a-310181322696@github.com>

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

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

I've run the test with and without the fix. Looks good.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27544#pullrequestreview-3569054039

From dgredler at openjdk.org  Thu Dec 11 20:18:49 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 11 Dec 2025 20:18:49 GMT
Subject: Integrated: 8368702: [macosx] Printing text with composite fonts loses
 font transform
In-Reply-To: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
References: <DqoiHemPIXmqUpsaqsl9YzqcbLNpucFHyLyLmk6FZ8k=.01fd5501-cbce-4fe3-a33a-00c6a2335e20@github.com>
Message-ID: <cxpAP1sbl9_4p1Op3eRPkLWQm4yEznaIoyF_6cYv1YY=.b408dbf6-bc23-49ed-8b86-1641250908bd@github.com>

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

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

This pull request has now been integrated.

Changeset: 431dcf84
Author:    Daniel Gredler <dgredler at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/431dcf84e9754c743105380ca69af647b57193bc
Stats:     10 lines in 2 files changed: 6 ins; 0 del; 4 mod

8368702: [macosx] Printing text with composite fonts loses font transform

Reviewed-by: psadhukhan, prr

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

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

From prr at openjdk.org  Thu Dec 11 20:22:55 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 20:22:55 GMT
Subject: RFR: 7067310: 3 tests from closed/javax/sound/sampled caused BSOD on
 win 7 x86
Message-ID: <R0CjhaqHKz4NzAsyzMQQSRi20GKjbI0fke0BL3jV55E=.18b8b50d-435f-43bb-83e0-1e85e074d96b@github.com>

I am de-problem listing several sound tests.
These tests pass over and over again on all platforms when run on JDK 27 in an environment that supports sound.
I'm seeing no failures at all.
There are multiple bug IDs used to problem list these tests but only one can be the 'main' bug ID.
I've picked the oldest for that, and will "add" some of the additional issues.
In a few cases they happen to be non-public bugs for the accidental reason that someone added some internal information I can't delete, so you won't be able to see those bug ids, but there's nothing special about them and I'll close them as dups of  7067310

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

Commit messages:
 - 7067310

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

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

From prr at openjdk.org  Thu Dec 11 20:22:56 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 20:22:56 GMT
Subject: RFR: 7067310: 3 tests from closed/javax/sound/sampled caused BSOD
 on win 7 x86
In-Reply-To: <R0CjhaqHKz4NzAsyzMQQSRi20GKjbI0fke0BL3jV55E=.18b8b50d-435f-43bb-83e0-1e85e074d96b@github.com>
References: <R0CjhaqHKz4NzAsyzMQQSRi20GKjbI0fke0BL3jV55E=.18b8b50d-435f-43bb-83e0-1e85e074d96b@github.com>
Message-ID: <edciGpI4hNnKLS_7Wcil7Lh1KCT4ltd_2qTujoAp0v4=.b38c84f6-48db-4336-bb51-d4b629bafd72@github.com>

On Thu, 11 Dec 2025 20:14:22 GMT, Phil Race <prr at openjdk.org> wrote:

> I am de-problem listing several sound tests.
> These tests pass over and over again on all platforms when run on JDK 27 in an environment that supports sound.
> I'm seeing no failures at all.
> There are multiple bug IDs used to problem list these tests but only one can be the 'main' bug ID.
> I've picked the oldest for that, and will "add" some of the additional issues.
> In a few cases they happen to be non-public bugs for the accidental reason that someone added some internal information I can't delete, so you won't be able to see those bug ids, but there's nothing special about them and I'll close them as dups of  7067310

test/jdk/ProblemList.txt line 644:

> 642: # jdk_sound
> 643: 
> 644: javax/sound/sampled/Clip/Drain/ClipDrain.java          7062792 generic-all

This test still fails so I can't remove it from the problem list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28774#discussion_r2611937621

From serb at openjdk.org  Thu Dec 11 20:36:26 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 11 Dec 2025 20:36:26 GMT
Subject: Integrated: 8371657: [macosx] Programmatically selecting/deselecting
 List item triggers an ItemEvent
In-Reply-To: <qaSav2oSlolKlrrmFCV72Knyg6I-D_dRMOXp-VpQNl8=.67d93c58-407a-43bd-b0bf-66348b43cc41@github.com>
References: <qaSav2oSlolKlrrmFCV72Knyg6I-D_dRMOXp-VpQNl8=.67d93c58-407a-43bd-b0bf-66348b43cc41@github.com>
Message-ID: <kGzF-syK7v1zCkX-5KlUHkg7pz2on9gV4eL5FzcGfp4=.6ef3322f-55bb-45f3-a831-fad9efa34e6d@github.com>

On Tue, 11 Nov 2025 22:21:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> When I was working on [JDK-8369327](https://bugs.openjdk.org/browse/JDK-8369327) I got a suggestion to update the code that disables unnecessary events:
> https://github.com/openjdk/jdk/pull/27682#discussion_r2487686109
> 
> After checking that code more closely, I found that it does not work in all cases. The checks were first added in [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456). It looks like only the case for the select method was fixed. Other cases still cause unnecessary events, and even more events happen when trying to add multi selection mode: https://github.com/openjdk/jdk/pull/27682#issuecomment-3487434403
> 
> So I made a new bug for this issue and fixed it separately.
> 
> The [spec](https://github.com/openjdk/jdk/blob/8531fa146be1da5e96c0f23091882a27c67d7893/src/java.desktop/share/classes/java/awt/List.java#L899):
> 
>   * Adds the specified item listener to receive item events from
>   * this list.  Item events are sent in response to user input, but not
>   * in response to calls to {@code select} or {@code deselect}.
> 
> 
> The new test checks most of the methods in the `java.awt.List` class. It passes on linux/windows, confirming that the same behavior is implemented in other toolkits (unfortunately on linux it is not stable enough so I had to problemlist it due to [JDK-8201307](https://bugs.openjdk.org/browse/JDK-8201307)). The test only checks for programmatic changes to the list. I am sure that if I change it to test mix of programmatic/user changes it will fail. I will work on that in a follow up bug.
> 
> @aivanov-jdk @azvegint please take a look

This pull request has now been integrated.

Changeset: 66d7b0ce
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66d7b0ce8f8414c3d5fd3476b65152b9f2a9a587
Stats:     215 lines in 3 files changed: 202 ins; 0 del; 13 mod

8371657: [macosx] Programmatically selecting/deselecting List item triggers an ItemEvent

Reviewed-by: aivanov, azvegint, dnguyen, tr

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

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

From prr at openjdk.org  Thu Dec 11 21:01:43 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 21:01:43 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v3]
In-Reply-To: <PU25-GhkDgozmFpcKe7UMoCEDCLRZwAHFYz28n_ppp8=.bc6b5885-80e6-4871-85d8-046e4aa28066@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <PU25-GhkDgozmFpcKe7UMoCEDCLRZwAHFYz28n_ppp8=.bc6b5885-80e6-4871-85d8-046e4aa28066@github.com>
Message-ID: <4mPIir7nLbChdT1EmbHL0CkuIgW69-En1TDQmF0IeVE=.a2565f2e-1953-4a12-bb7b-65b0db10be56@github.com>

On Mon, 3 Nov 2025 16:05:42 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
>> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt.
>
> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8068378: Review feedback for instructions, missing break in switch case in Test.java

test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 64:

> 62:         "3.Press the button on Window (1) & Window (2) \n" +
> 63:         "Verification step:\n" +
> 64:         "\tIf Modality is 'Non-modal'or 'Modeless', Button is presseed \n" +

Can we please fix all mis-spellings of pressed (you have presseed - ie with "ee" in multiple cases) ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2612044908

From aivanov at openjdk.org  Thu Dec 11 21:13:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Dec 2025 21:13:58 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v18]
In-Reply-To: <f98wRo4E-Yx4AvMFOzq_Gycl5HZYehgzumytphz7BR0=.716a9711-bc7d-4c7e-8f80-cec0d9218c0c@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <f98wRo4E-Yx4AvMFOzq_Gycl5HZYehgzumytphz7BR0=.716a9711-bc7d-4c7e-8f80-cec0d9218c0c@github.com>
Message-ID: <WHKz-RLjG5BYTB2mxm0aRlNVOAjUvG5d7OcQocl4zWI=.af663504-9638-43ed-a619-f6dcb1a3ca98@github.com>

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

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 45:

> 43: 
> 44: 
> 45: import javax.swing.JFrame;

Imports look inconsistent.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 135:

> 133:         });
> 134:         if (testResize) {
> 135:             wasLWClicked = false;

Suggestion:

        if (!testResize) {
            return true;


Invert the condition. We did this in #25971, it removes additional indentation and makes the code clearer.

You probably want to move this condition above the focus latch.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 157:

> 155:             } catch (InvocationTargetException ex) {
> 156:                 fail(ex.getMessage());
> 157:             }

Suggestion:

            } catch (InterruptedException | InvocationTargetException ex) {
                fail(ex.getMessage());
            }

Merge them together.

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

> 69: 
> 70: 
> 71:         cb = new JComboBox(petStrings);

Suggestion:

        frame.setVisible(true);

        cb = new JComboBox(petStrings);

One blank between code sections is enough.

test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 77:

> 75:         frame.setSize(200, 200);
> 76:         frame.setLocationRelativeTo(null);
> 77:         frame.setVisible(true);

There are calls to `setLocationRelativeTo(null)` and `setVisible(true)` in the bottom of the method.

test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 80:

> 78:                 lwClicked = true;
> 79:                 frame.setVisible(false);
> 80:             }

Why is it needed to hide the frame now? It wasn't hidden previously.

test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java line 74:

> 72:         sp1 = new JScrollPane(p);
> 73:         currentAwtControl.setForeground(Color.white);
> 74:         currentAwtControl.setBackground(Color.white);

Suggestion:

        currentAwtControl.setForeground(Color.WHITE);
        currentAwtControl.setBackground(Color.WHITE);

Let's use upper-case *constants*.

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

> 80:     private static int frameBorderCounter() {
> 81: 
> 82:         String JAVA_HOME = System.getProperty("java.home");

Please don't add redundant blank lines at the very start of a method.

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.

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

> 104:     private static String readInputStream(InputStream is) throws IOException {
> 105: 
> 106:         byte[] buffer = new byte[4096];

Remove this redundant line.

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

> 120:         borderShift = frameBorderCounter();
> 121:         borderShift =
> 122:                 Math.abs(borderShift) == 1 ? borderShift : (borderShift / 2);

I'd leave it as is, or, if you prefer updating, rather reformat it like this:


Suggestion:

        borderShift = Math.abs(borderShift) == 1
                      ? borderShift
                      : (borderShift / 2);

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

> 169:             public void run() {
> 170: 
> 171:                 lLoc = frame.getLocationOnScreen();

Remove this redundant blank line?

However, many `Runnable`s have a blank line right after the `run()` method declaration. In this case, I'd follow this style for consistency.

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

> 183:             public void run() {
> 184: 
> 185:                 Point btnLoc = jbutton.getLocationOnScreen();

My preference would be to have only one of these blank lines.

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

> 255:     public static void main(String args[]) throws Exception {
> 256: 
> 257:         try {

Suggestion:

public static void main(String args[]) throws Exception {
        try {

A blank line at the start of a method is redundant.

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

> 309:     public static synchronized void pass() {
> 310: 
> 311:         System.out.println("The test passed.");

All these added blank lines are redundant.

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

> 347: 
> 348:         System.out.println("Comparing color: " + color + " with reference " +
> 349:                 "color: " + refColor);

Suggestion:

    private static boolean isAlmostEqualColor(Color color, Color refColor) {
        System.out.println("Comparing color: " + color + " with reference " +
                "color: " + refColor);

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

> 354:                                 TOLERANCE_MACOSX &&
> 355:                         Math.abs(color.getBlue() - refColor.getBlue()) <
> 356:                                 TOLERANCE_MACOSX;

Suggestion:

        return color.equals(refColor)
               || (Math.abs(color.getRed() - refColor.getRed()) < TOLERANCE_MACOSX
                   && Math.abs(color.getGreen() - refColor.getGreen()) < TOLERANCE_MACOSX
                   && Math.abs(color.getBlue() - refColor.getBlue()) < TOLERANCE_MACOSX);

I strongly prefer this style of wrapping: wrapping before a binary operator makes it clear that it's a continuation; parentheses explicitly group comparison of color components.

I would not wrap the lines with `< TOLERANCE_MACOSX` although they don't fit 80-column limit. Wrapping doesn't help parsing the expression.

You can shorten `TOLERANCE_MACOSX` to `TOLERANCE`. Yet the current name suggests the tolerance is in effect only on macOS.

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

> 359:     static class TestPassedException extends RuntimeException {
> 360: 
> 361:     }

I see no reason to add a blank line inside the declaration of the `TestPassedException` class.

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

> 385:         return !(component == null ||
> 386:                 (component instanceof java.awt.Scrollbar) ||
> 387:                 (isMac && (component instanceof java.awt.Button)));

Suggestion:

        return !(component instanceof java.awt.Scrollbar)
               && (!isMac || (!(component instanceof java.awt.Button)));

The expression can be simplified further.

`java.awt.Scrollbar` is already imported, so `Scrollbar` can safely be used. I'm for importing `java.awt.Button` and using unqualified `Button` in the expression.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 171:

> 169:         } else {
> 170:             latch.countDown();
> 171:         }

`latch` isn't declared in this scope.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 173:

> 171:         }
> 172:         try {
> 173:             boolean await = latch.await(1, TimeUnit.SECONDS);

`latch` isn't declared in this scope.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 187:

> 185:                     throw new RuntimeException(
> 186:                             "Ancestor frame didn't receive focus");
> 187:                 }

Indentation is wrong.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 199:

> 197: 
> 198: 
> 199:         return wasLWClicked;

One blank line seems enough between code sections.

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

PR Review: https://git.openjdk.org/jdk/pull/26625#pullrequestreview-3569053278
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611877977
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611867427
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611872778
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611876184
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611881799
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611885553
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611903091
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611909297
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2612020583
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611919078
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611924803
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611929707
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611933903
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611940143
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611942003
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611943663
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611965281
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611945982
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611979119
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611999199
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2612003424
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2611987770
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2612005602

From prr at openjdk.org  Thu Dec 11 21:36:40 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 21:36:40 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
Message-ID: <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>

On Wed, 10 Dec 2025 20:02:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
>> 
>> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Space out batches of frames

test/jdk/java/awt/Frame/FrameVisualTest.java line 67:

> 65:         System.out.println("frames.length: " + frames.length);
> 66: 
> 67:         // Iterate through gcs in batches of 20

maybe we could have a var for this ? Perhaps even allow it to be set as a program arg even if you default to 20.
Also wouldn't one at a time be the most stable ?
Finally, is it even necessary to test ALL of them ? Isn't it sufficient to test 30-40 and call it a day ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2612141387

From prr at openjdk.org  Thu Dec 11 21:41:45 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 21:41:45 GMT
Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect
 in RTL orientation [v2]
In-Reply-To: <7m34qGlFammbS9KJZMP-5YE7tM7l2zyz7mntUC4cm60=.7a530988-b17f-4d44-be1e-72a1c442dd35@github.com>
References: <H4jHyJn_mn2NZPUezEEY0UKdWbRil7gKMxG43YCcXeM=.57b8650d-1882-42d2-a01e-e7643225c22b@github.com>
 <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com>
 <7m34qGlFammbS9KJZMP-5YE7tM7l2zyz7mntUC4cm60=.7a530988-b17f-4d44-be1e-72a1c442dd35@github.com>
Message-ID: <rza-hBpbV_1mucZTT1yMLsCOdZRUjPUt3Bf7SmnDF-8=.67fb1b2a-4cb2-4efb-8a4a-af431eedd87f@github.com>

On Wed, 12 Nov 2025 10:02:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Also, there is a closed test ManualBug6458123.java where the alignment seems to be wrong

What was the resolution to this comment ? It isn't clear to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/28210#issuecomment-3643891615

From prr at openjdk.org  Thu Dec 11 21:44:15 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 21:44:15 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
Message-ID: <_A087izN3OyIS4VP78rSuZZwtY05ZheqW98mHxkKjw4=.7eb84090-d0aa-488b-a8d1-6fca78446d31@github.com>

On Thu, 25 Sep 2025 14:05:11 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Removes uncessary import and adds blank lines between import blocks
>  - Makes inherited method final
>  - Removes unnecessary URL
>  - Fixes a typo
>  - Removes unncessary boolean variable, line and import
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Cleans up code for move visibility
>  - Cleans up code and adds missed import
>  - ... and 56 more: https://git.openjdk.org/jdk/compare/21e61636...59a937ac

So other than a very few, very minor formatting issues, and the problem list conflict, what is between this going from under review to being integrated ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3643899971

From prr at openjdk.org  Thu Dec 11 21:47:39 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 21:47:39 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
Message-ID: <OIEyF2DgN_wgNEQKgDf9fFxxshEKkVriKA-w9R2A4UE=.9a3b0382-8850-4b0f-9a35-818612ff8a9d@github.com>

On Mon, 1 Dec 2025 07:41:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or subclasses, is serialized, 
>> the colors used to render cells in the JTable subsequent to the call to `writeObject()`
>>  are forced to the default colors for `DefaultTableCellRenderer`'s immediate base class, JLabel, causing the colors
>> defined in the JTable (typically black on white) to be ignored.
>> 
>> The problem seems to stem from a call to
>> `installUI `in the `writeObject()` method of `JLabel`, `DefaultTableCellRenderer`'s base class.
>>  This causes the `setForeground` and `setBackground` methods to be invoked with specific colors, which turn out to be JLabel's defaults.
>> Invoking these methods subsequently with parameters of null restores normal operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()`
>> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162
>> 
>> CI run is ok..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rethrow Exception

> > How/why does null restore the JTable-specified colors ? I don't see anything about null in the spec. And what have people been doing the last 25 years if serializing a JTable "broke" its rendering ?
> 
> Specifying null would cause `unselectedForeground` and `unselectedBackground` to be null
> 
> 
> 
> so it will fallback to table assigned foreground and background color
> 

So how do people know that ? Reading the source and trial and error don't count as ways to know.

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

PR Comment: https://git.openjdk.org/jdk/pull/28549#issuecomment-3643911298

From aivanov at openjdk.org  Thu Dec 11 21:50:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Dec 2025 21:50:47 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
Message-ID: <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>

On Thu, 25 Sep 2025 14:05:11 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Removes uncessary import and adds blank lines between import blocks
>  - Makes inherited method final
>  - Removes unnecessary URL
>  - Fixes a typo
>  - Removes unncessary boolean variable, line and import
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Cleans up code for move visibility
>  - Cleans up code and adds missed import
>  - ... and 56 more: https://git.openjdk.org/jdk/compare/1388fb12...59a937ac

I believe this one is ready to be integrated now. Unfortunately, I couldn't find the time to re-review it earlier, it always slipped.

I'm also running the tests with merged master to ensure the tests removed from the PL don't fail.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3643921872

From kizune at openjdk.org  Thu Dec 11 21:56:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 11 Dec 2025 21:56:52 GMT
Subject: RFR: 8371508: [macos] In Aqua LaF menu items layout is incorrect
 in RTL orientation [v2]
In-Reply-To: <rza-hBpbV_1mucZTT1yMLsCOdZRUjPUt3Bf7SmnDF-8=.67fb1b2a-4cb2-4efb-8a4a-af431eedd87f@github.com>
References: <H4jHyJn_mn2NZPUezEEY0UKdWbRil7gKMxG43YCcXeM=.57b8650d-1882-42d2-a01e-e7643225c22b@github.com>
 <7lU-DpazJjVmfcY_pN7Y1-nV8_5zajs40JoWzXwe2cE=.f87c6c0f-049c-4f70-8d0e-a285880d4e25@github.com>
 <7m34qGlFammbS9KJZMP-5YE7tM7l2zyz7mntUC4cm60=.7a530988-b17f-4d44-be1e-72a1c442dd35@github.com>
 <rza-hBpbV_1mucZTT1yMLsCOdZRUjPUt3Bf7SmnDF-8=.67fb1b2a-4cb2-4efb-8a4a-af431eedd87f@github.com>
Message-ID: <wLP7JRX-8u1g_48byiVrKvuAVxHPjbo5lW6gSSwbfp8=.d6fc8052-be9d-44c3-a9aa-363ff04cbc73@github.com>

On Thu, 11 Dec 2025 21:38:55 GMT, Phil Race <prr at openjdk.org> wrote:

> > Also, there is a closed test ManualBug6458123.java where the alignment seems to be wrong
> 
> What was the resolution to this comment ? It isn't clear to me.

There are cases in this test that are not covered by the existing fix. In essence - there are two ways to influence the text position setHorizontalAlignment and setHorizontalTextPosition. The fix is working with default text alignment with different text positions but adding custom text alignments AND custom text positions confuses the current logic and we get undesirable results so i'm working to see what can be done here.

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

PR Comment: https://git.openjdk.org/jdk/pull/28210#issuecomment-3643939671

From prr at openjdk.org  Thu Dec 11 21:57:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 21:57:01 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box
In-Reply-To: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
Message-ID: <FvgAR78u6ITrtw6cLoemfpzMlvD0d1hjKOvJGbxFSPI=.6c0bfb96-dfaa-47a6-84ce-540cf5775628@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.

Ok. Let's proceed with the CSR for this.
I noted that there is a TCK failure. I think (from reading the failure log) that it is likely that the test expected looser bounds and so some point would be contained in the bounds, so I hope it is a simple matter for the JCK team to update the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3643939146

From prr at openjdk.org  Thu Dec 11 22:45:43 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Dec 2025 22:45:43 GMT
Subject: RFR: 8372592: Adjust logger usage in java2d tests
Message-ID: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>

We had a previous mysterious failure that looks like it was due to a logger being gc'd.
To prevent that update all the marlin tests to use a logger stored in a static.
The 'final' modifier probably isn't necessary for this but is harmless, I'm doing the minimum here
so I don't want to go change log -> LOG everywhere just because its now final.

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

Commit messages:
 - 8372592

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

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

From kizune at openjdk.org  Thu Dec 11 23:15:31 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 11 Dec 2025 23:15:31 GMT
Subject: RFR: 8372592: Adjust logger usage in java2d tests
In-Reply-To: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
References: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
Message-ID: <DJ0xwC20RNTDIaQ-UZLKMiAchnKlF4NRUrOQoOTKN60=.670ccec2-46d2-4465-8ea4-99ee7af5790b@github.com>

On Thu, 11 Dec 2025 22:37:56 GMT, Phil Race <prr at openjdk.org> wrote:

> We had a previous mysterious failure that looks like it was due to a logger being gc'd.
> To prevent that update all the marlin tests to use a logger stored in a static.
> The 'final' modifier probably isn't necessary for this but is harmless, I'm doing the minimum here
> so I don't want to go change log -> LOG everywhere just because its now final.

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28778#pullrequestreview-3569652211

From dnguyen at openjdk.org  Thu Dec 11 23:31:47 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Dec 2025 23:31:47 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v4]
In-Reply-To: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
Message-ID: <tYp6e3eJQbbbif5E5yrr043aMlM-PgDwszM9g5ttCw8=.ef1cebdf-0d79-4462-842c-a727e9cf1e5f@github.com>

> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
> 
> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.

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

  Test one frame at a time and limit number of gcs.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28646/files
  - new: https://git.openjdk.org/jdk/pull/28646/files/7f623fc7..f0e7302a

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

  Stats: 62 lines in 1 file changed: 8 ins; 20 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/28646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28646/head:pull/28646

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

From dnguyen at openjdk.org  Thu Dec 11 23:31:58 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Dec 2025 23:31:58 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
 <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>
Message-ID: <XdxNWejtFTQ90z1yyMywnv2NZ5oL77Cbd_-egZkrTLo=.79ce9e2b-2c5a-420e-af58-96857e1fbeb4@github.com>

On Thu, 11 Dec 2025 21:33:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Space out batches of frames
>
> test/jdk/java/awt/Frame/FrameVisualTest.java line 67:
> 
>> 65:         System.out.println("frames.length: " + frames.length);
>> 66: 
>> 67:         // Iterate through gcs in batches of 20
> 
> maybe we could have a var for this ? Perhaps even allow it to be set as a program arg even if you default to 20.
> Also wouldn't one at a time be the most stable ?
> Finally, is it even necessary to test ALL of them ? Isn't it sufficient to test 30-40 and call it a day ?

Good point. I have switched to a single frame at a time and have created a new final var to limit the number of frames to test (30). When testing, the balance of stability and testing duration felt reasonable. The test still creates, tests, and disposes multiple frames on Ubuntu, and the test still passes testing after the changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2612385452

From psadhukhan at openjdk.org  Fri Dec 12 01:29:18 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 01:29:18 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <OIEyF2DgN_wgNEQKgDf9fFxxshEKkVriKA-w9R2A4UE=.9a3b0382-8850-4b0f-9a35-818612ff8a9d@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
 <OIEyF2DgN_wgNEQKgDf9fFxxshEKkVriKA-w9R2A4UE=.9a3b0382-8850-4b0f-9a35-818612ff8a9d@github.com>
Message-ID: <pYXhmhcWsxxWy9IODCkNmoRaYmv2bU0Wi1Ee8VuzUnE=.c7ed5904-6502-4cb7-b013-9366284e626f@github.com>

On Thu, 11 Dec 2025 21:44:46 GMT, Phil Race <prr at openjdk.org> wrote:

> > > How/why does null restore the JTable-specified colors ? I don't see anything about null in the spec. And what have people been doing the last 25 years if serializing a JTable "broke" its rendering ?
> > 
> > 
> > Specifying null would cause `unselectedForeground` and `unselectedBackground` to be null
> > so it will fallback to table assigned foreground and background color
> 
> So how do people know that ? Reading the source and trial and error don't count as ways to know.

Its implementation detail, not sure why people need to know upfront...
Are you thinking of user who will extend DefaultTableCellRenderer and provide its own implementation...
In that case, do you want me to add some spec wording to DefaultTableCellRenderer?

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

PR Comment: https://git.openjdk.org/jdk/pull/28549#issuecomment-3644507013

From psadhukhan at openjdk.org  Fri Dec 12 03:15:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 03:15:52 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v4]
In-Reply-To: <fqsITOV_7KIrM2OcpDpv9afL9pJruGqH4A3rP5T_KyI=.7b976108-77d8-4403-8875-27c694ea0fb9@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <fqsITOV_7KIrM2OcpDpv9afL9pJruGqH4A3rP5T_KyI=.7b976108-77d8-4403-8875-27c694ea0fb9@github.com>
Message-ID: <5_mcRFksoxLrx1UUcFJ2dl11LbfG06nUUK09VkaLghY=.6b6f25c3-1ebe-4dc1-8853-ed28646b6a84@github.com>

On Thu, 11 Dec 2025 04:45:41 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..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GenericEditor serialization fix

So, as I see it is mentioned
`an instance of a static nested class (which is in this case GenericEditor) would be serialized along with the outer class instance is if the outer class instance holds an explicit reference to an instance of that static nested class as one of its fields`,
but no such explicit reference exists as far I can see.
The stacktrace shows the exception comes from 
 `at java.desktop/javax.swing.event.EventListenerList.writeObject(EventListenerList.java:286)`
but even making `EventListenerList `transient in `AbstractCellEditor `and `RowSorter `which are referenced in JTable, doesn't help

Also, as per this stackoverflow https://stackoverflow.com/questions/19282817/why-do-jtables-make-tablemodels-non-serializable-when-rendered
it is told "when you add a TableModelListener to an AbstractTableModel implementation, another listener is added in addition to the one you added, of type javax.swing.event.TableModelListener which isn't serializable" but I could not see how and also  following the same "workaround" of removing TableModelListener before serialization and adding it back, doesn't help
so if anyone has any idea of how to find the reference which is causing GenericEditor to be serialized, please let me know

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3644723007

From psadhukhan at openjdk.org  Fri Dec 12 03:46:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 03:46:54 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v4]
In-Reply-To: <5_mcRFksoxLrx1UUcFJ2dl11LbfG06nUUK09VkaLghY=.6b6f25c3-1ebe-4dc1-8853-ed28646b6a84@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <fqsITOV_7KIrM2OcpDpv9afL9pJruGqH4A3rP5T_KyI=.7b976108-77d8-4403-8875-27c694ea0fb9@github.com>
 <5_mcRFksoxLrx1UUcFJ2dl11LbfG06nUUK09VkaLghY=.6b6f25c3-1ebe-4dc1-8853-ed28646b6a84@github.com>
Message-ID: <sZ5EtBfCXNrVXIN-tizq5oEq7Hqi0SITJVD8VtIj4Kg=.4b7f7561-77a8-4217-9d1a-e8a53a98781e@github.com>

On Fri, 12 Dec 2025 03:13:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> So, as I see it is mentioned `an instance of a static nested class (which is in this case GenericEditor) would be serialized along with the outer class instance is if the outer class instance holds an explicit reference to an instance of that static nested class as one of its fields`, but no such explicit reference exists as far I can see. The stacktrace shows the exception comes from `at java.desktop/javax.swing.event.EventListenerList.writeObject(EventListenerList.java:286)` but even making `EventListenerList `transient in `AbstractCellEditor `and `RowSorter `which are referenced in JTable, doesn't help
> 
> Also, as per this stackoverflow https://stackoverflow.com/questions/19282817/why-do-jtables-make-tablemodels-non-serializable-when-rendered it is told "when you add a TableModelListener to an AbstractTableModel implementation, another listener is added in addition to the one you added, of type javax.swing.event.TableModelListener which isn't serializable" but I could not see how and also following the same "workaround" of removing TableModelListener before serialization and adding it back, doesn't help so if anyone has any idea of how to find the reference which is causing GenericEditor to be serialized, please let me know

It seems only if we make JComponent's EventListenerList transient


/** A list of event listeners for this component. */
    protected transient EventListenerList listenerList = new EventListenerList();

only then, the GenericEditor class is not getting serialized..

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3644779282

From psadhukhan at openjdk.org  Fri Dec 12 04:23:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 04:23:54 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v3]
In-Reply-To: <4mPIir7nLbChdT1EmbHL0CkuIgW69-En1TDQmF0IeVE=.a2565f2e-1953-4a12-bb7b-65b0db10be56@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <PU25-GhkDgozmFpcKe7UMoCEDCLRZwAHFYz28n_ppp8=.bc6b5885-80e6-4871-85d8-046e4aa28066@github.com>
 <4mPIir7nLbChdT1EmbHL0CkuIgW69-En1TDQmF0IeVE=.a2565f2e-1953-4a12-bb7b-65b0db10be56@github.com>
Message-ID: <MdlAcufqp9eH7uWNKJyPTFp8SgKPejZdBD-IzHS4plc=.35727133-b050-4e64-b1ba-988ee8dff954@github.com>

On Thu, 11 Dec 2025 20:58:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8068378: Review feedback for instructions, missing break in switch case in Test.java
>
> test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 64:
> 
>> 62:         "3.Press the button on Window (1) & Window (2) \n" +
>> 63:         "Verification step:\n" +
>> 64:         "\tIf Modality is 'Non-modal'or 'Modeless', Button is presseed \n" +
> 
> Can we please fix all mis-spellings of pressed (you have presseed - ie with "ee" in multiple cases) ?

I guess I had commented on it and is now resolved https://github.com/openjdk/jdk/pull/27139#discussion_r2536937973
Probably you are looking at wrong version of the file..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2612875102

From jpai at openjdk.org  Fri Dec 12 05:32:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Dec 2025 05:32:31 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
Message-ID: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>

Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?

As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.

tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

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

Commit messages:
 - replace deprecated -verify with -Xverify:all

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

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

From smandalika at openjdk.org  Fri Dec 12 05:39:53 2025
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Fri, 12 Dec 2025 05:39:53 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v3]
In-Reply-To: <MdlAcufqp9eH7uWNKJyPTFp8SgKPejZdBD-IzHS4plc=.35727133-b050-4e64-b1ba-988ee8dff954@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <PU25-GhkDgozmFpcKe7UMoCEDCLRZwAHFYz28n_ppp8=.bc6b5885-80e6-4871-85d8-046e4aa28066@github.com>
 <4mPIir7nLbChdT1EmbHL0CkuIgW69-En1TDQmF0IeVE=.a2565f2e-1953-4a12-bb7b-65b0db10be56@github.com>
 <MdlAcufqp9eH7uWNKJyPTFp8SgKPejZdBD-IzHS4plc=.35727133-b050-4e64-b1ba-988ee8dff954@github.com>
Message-ID: <4bOVvTSwAU4E0gPPN34DiFc3xRxOy_BBLOHxcKJGC1I=.99186bce-1c08-4360-a453-ee30819e90ea@github.com>

On Fri, 12 Dec 2025 04:20:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java line 64:
>> 
>>> 62:         "3.Press the button on Window (1) & Window (2) \n" +
>>> 63:         "Verification step:\n" +
>>> 64:         "\tIf Modality is 'Non-modal'or 'Modeless', Button is presseed \n" +
>> 
>> Can we please fix all mis-spellings of pressed (you have presseed - ie with "ee" in multiple cases) ?
>
> I guess I had commented on it and is now resolved https://github.com/openjdk/jdk/pull/27139#discussion_r2536937973
> Probably you are looking at wrong version of the file..

Yes, that is correct. I have confirmed this by searching for the misspelled string "presseed" and see no instance of it in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2612987177

From tr at openjdk.org  Fri Dec 12 05:41:54 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Dec 2025 05:41:54 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights
In-Reply-To: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
Message-ID: <bQYAkFazaqhUgmCFBguuy3mZBCh_zV1rgFRCVEDBcjQ=.7af14f5a-9b2c-477b-820f-ef9c40f312ac@github.com>

On Thu, 27 Nov 2025 09:53:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using `JTable.setRowHeight(row, height).` 
> The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it
> `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed.
> 
> The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is.
> Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event
> 
> No other issue observed with CI with this fix..

test/jdk/javax/swing/JTable/TestRowHeightWithColIdentifier.java line 29:

> 27:  * @summary Verifies DefaultTableModel.setColumnIdentifiers() doesn't
> 28:  *          clear JTable Row Heights
> 29:  * @run main TestRowHeightWithColIdentifier

This test can be headless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28529#discussion_r2612990682

From psadhukhan at openjdk.org  Fri Dec 12 05:56:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 05:56:38 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights [v2]
In-Reply-To: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
Message-ID: <lLkoARo9wFZ45AhY5jniKLRNwvNx_mL7fdHXG8bTgL4=.77dc4301-6aed-4456-8404-7dbc5ba645aa@github.com>

> Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using `JTable.setRowHeight(row, height).` 
> The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it
> `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed.
> 
> The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is.
> Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event
> 
> No other issue observed with CI with this fix..

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

  Test headless

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28529/files
  - new: https://git.openjdk.org/jdk/pull/28529/files/e5b4f158..0e33270a

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

  Stats: 51 lines in 1 file changed: 1 ins; 32 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/28529.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28529/head:pull/28529

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

From psadhukhan at openjdk.org  Fri Dec 12 05:56:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 05:56:38 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights [v2]
In-Reply-To: <bQYAkFazaqhUgmCFBguuy3mZBCh_zV1rgFRCVEDBcjQ=.7af14f5a-9b2c-477b-820f-ef9c40f312ac@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
 <bQYAkFazaqhUgmCFBguuy3mZBCh_zV1rgFRCVEDBcjQ=.7af14f5a-9b2c-477b-820f-ef9c40f312ac@github.com>
Message-ID: <o_oaAcft76-lwLZX80gV3sPKop1YzIRcKYLZyVw4vHM=.a1e788f0-1e24-48eb-84b1-8ac71250b1bc@github.com>

On Fri, 12 Dec 2025 05:39:05 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test headless
>
> test/jdk/javax/swing/JTable/TestRowHeightWithColIdentifier.java line 29:
> 
>> 27:  * @summary Verifies DefaultTableModel.setColumnIdentifiers() doesn't
>> 28:  *          clear JTable Row Heights
>> 29:  * @run main TestRowHeightWithColIdentifier
> 
> This test can be headless.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28529#discussion_r2613010252

From serb at openjdk.org  Fri Dec 12 06:11:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Dec 2025 06:11:55 GMT
Subject: RFR: 8372592: Adjust logger usage in java2d tests
In-Reply-To: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
References: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
Message-ID: <EFuEScsF7MYmc6UC_n2WTQBWVPblEqWWYfRTow2b5nk=.ce1c8d28-8a9d-482e-9cda-61f8a2559abb@github.com>

On Thu, 11 Dec 2025 22:37:56 GMT, Phil Race <prr at openjdk.org> wrote:

> We had a previous mysterious failure that looks like it was due to a logger being gc'd.
> To prevent that update all the marlin tests to use a logger stored in a static.
> The 'final' modifier probably isn't necessary for this but is harmless, I'm doing the minimum here
> so I don't want to go change log -> LOG everywhere just because its now final.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28778#pullrequestreview-3570446000

From serb at openjdk.org  Fri Dec 12 06:13:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Dec 2025 06:13:52 GMT
Subject: RFR: 7067310: 3 tests from closed/javax/sound/sampled caused BSOD
 on win 7 x86
In-Reply-To: <R0CjhaqHKz4NzAsyzMQQSRi20GKjbI0fke0BL3jV55E=.18b8b50d-435f-43bb-83e0-1e85e074d96b@github.com>
References: <R0CjhaqHKz4NzAsyzMQQSRi20GKjbI0fke0BL3jV55E=.18b8b50d-435f-43bb-83e0-1e85e074d96b@github.com>
Message-ID: <Csvg0PyOn6ScLQ19lQY14TsCgStMRGiImu-jM7wnnQo=.e968bcc7-6e8d-4d1b-8123-90df4cd072a1@github.com>

On Thu, 11 Dec 2025 20:14:22 GMT, Phil Race <prr at openjdk.org> wrote:

> I am de-problem listing several sound tests.
> These tests pass over and over again on all platforms when run on JDK 27 in an environment that supports sound.
> I'm seeing no failures at all.
> There are multiple bug IDs used to problem list these tests but only one can be the 'main' bug ID.
> I've picked the oldest for that, and will "add" some of the additional issues.
> In a few cases they happen to be non-public bugs for the accidental reason that someone added some internal information I can't delete, so you won't be able to see those bug ids, but there's nothing special about them and I'll close them as dups of  7067310

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28774#pullrequestreview-3570450688

From azvegint at openjdk.org  Fri Dec 12 07:32:52 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 12 Dec 2025 07:32:52 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <XdxNWejtFTQ90z1yyMywnv2NZ5oL77Cbd_-egZkrTLo=.79ce9e2b-2c5a-420e-af58-96857e1fbeb4@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
 <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>
 <XdxNWejtFTQ90z1yyMywnv2NZ5oL77Cbd_-egZkrTLo=.79ce9e2b-2c5a-420e-af58-96857e1fbeb4@github.com>
Message-ID: <V_kVEHiV116kHNIyBsmxvPYdVdGyMTxxd5uHBBe0kCo=.de17b44d-c807-4784-9c66-047df879d212@github.com>

On Thu, 11 Dec 2025 23:29:15 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> I have switched to a single frame at a time 

This makes the test much slower. On my machine, the execution time is::
- ~33s with the one at a time version
- ~10s for version with all gcs in batches of 20 
 
Few notes on placing several frames:
<img width="1012" height="222" alt="image" src="https://github.com/user-attachments/assets/98820fd5-5c9e-4f9c-b2d4-a87681a56cb6" />
- If they are close enough, they can cast shadows on each other.
- If the auto-hide dock is disabled, the dock can overlap frames.  The dock auto-hide is enabled on the CI, but it would be better if it could be moved away from the screen border.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2613216465

From tr at openjdk.org  Fri Dec 12 07:34:00 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Dec 2025 07:34:00 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights [v2]
In-Reply-To: <lLkoARo9wFZ45AhY5jniKLRNwvNx_mL7fdHXG8bTgL4=.77dc4301-6aed-4456-8404-7dbc5ba645aa@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
 <lLkoARo9wFZ45AhY5jniKLRNwvNx_mL7fdHXG8bTgL4=.77dc4301-6aed-4456-8404-7dbc5ba645aa@github.com>
Message-ID: <lQZA5mewakPaxQiKaji0wclSOmM-jnSUyZQ16qvnD-8=.b0005c1e-b904-484c-80f8-b0f688a4a2c0@github.com>

On Fri, 12 Dec 2025 05:56:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using `JTable.setRowHeight(row, height).` 
>> The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it
>> `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed.
>> 
>> The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is.
>> Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event
>> 
>> No other issue observed with CI with this fix..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test headless

test/jdk/javax/swing/JTable/TestRowHeightWithColIdentifier.java line 41:

> 39:     private static JTable table;
> 40:     private static volatile int oldRowHeight;
> 41:     private static volatile int curRowHeight;

All these declarations can be moved inside now.

test/jdk/javax/swing/JTable/TestRowHeightWithColIdentifier.java line 60:

> 58:             model.setColumnIdentifiers(new Object[] {"Check", "it out!"});
> 59:             for (int row = 0; row < table.getRowCount(); row++) {
> 60:                 System.out.println("AFter table rowHeight " + table.getRowHeight(row));

Suggestion:

                System.out.println("After table rowHeight " + table.getRowHeight(row));

test/jdk/javax/swing/JTable/TestRowHeightWithColIdentifier.java line 64:

> 62:             curRowHeight = table.getRowHeight(0);
> 63:             if (curRowHeight != oldRowHeight) {
> 64:                 throw new RuntimeException("DefaultTableModel.setColumnIdentifiers() Clears JTable Row Heights");

Suggestion:

                throw new RuntimeException("DefaultTableModel.setColumnIdentifiers() Clears JTable Row Height");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28529#discussion_r2613219134
PR Review Comment: https://git.openjdk.org/jdk/pull/28529#discussion_r2613220592
PR Review Comment: https://git.openjdk.org/jdk/pull/28529#discussion_r2613221422

From psadhukhan at openjdk.org  Fri Dec 12 07:46:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 07:46:01 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights [v3]
In-Reply-To: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
Message-ID: <KYsRchS9UMt57J99IlZnyBHHsHW2iBKqvh7b2xleImo=.e07455b4-cee3-4623-a1e9-6a9e27ddd7d9@github.com>

> Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using `JTable.setRowHeight(row, height).` 
> The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it
> `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed.
> 
> The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is.
> Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event
> 
> No other issue observed with CI with this fix..

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28529/files
  - new: https://git.openjdk.org/jdk/pull/28529/files/0e33270a..d2109262

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

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

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

From tr at openjdk.org  Fri Dec 12 07:46:01 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Dec 2025 07:46:01 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights [v3]
In-Reply-To: <KYsRchS9UMt57J99IlZnyBHHsHW2iBKqvh7b2xleImo=.e07455b4-cee3-4623-a1e9-6a9e27ddd7d9@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
 <KYsRchS9UMt57J99IlZnyBHHsHW2iBKqvh7b2xleImo=.e07455b4-cee3-4623-a1e9-6a9e27ddd7d9@github.com>
Message-ID: <TvbIxGc-deIIaquJhfADwN7VzYbZ4QfMUBpOCbaPGE4=.9aaa04e1-f046-4847-a1dd-b6f0620ea95e@github.com>

On Fri, 12 Dec 2025 07:40:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using `JTable.setRowHeight(row, height).` 
>> The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it
>> `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed.
>> 
>> The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is.
>> Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event
>> 
>> No other issue observed with CI with this fix..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28529#pullrequestreview-3570677894

From psadhukhan at openjdk.org  Fri Dec 12 07:46:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 07:46:04 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights [v2]
In-Reply-To: <lQZA5mewakPaxQiKaji0wclSOmM-jnSUyZQ16qvnD-8=.b0005c1e-b904-484c-80f8-b0f688a4a2c0@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
 <lLkoARo9wFZ45AhY5jniKLRNwvNx_mL7fdHXG8bTgL4=.77dc4301-6aed-4456-8404-7dbc5ba645aa@github.com>
 <lQZA5mewakPaxQiKaji0wclSOmM-jnSUyZQ16qvnD-8=.b0005c1e-b904-484c-80f8-b0f688a4a2c0@github.com>
Message-ID: <YcQ_JBCjj-SjCZsFrPVd3Qj1syEhwrwD14dekyOsuKY=.30b0bebf-df7a-4730-8266-19dbab08c61b@github.com>

On Fri, 12 Dec 2025 07:30:42 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test headless
>
> test/jdk/javax/swing/JTable/TestRowHeightWithColIdentifier.java line 41:
> 
>> 39:     private static JTable table;
>> 40:     private static volatile int oldRowHeight;
>> 41:     private static volatile int curRowHeight;
> 
> All these declarations can be moved inside now.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28529#discussion_r2613230958

From tr at openjdk.org  Fri Dec 12 07:52:57 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Dec 2025 07:52:57 GMT
Subject: RFR: 6681958: Maximization state of JInternalFrames is corrupted
 by WindowsDesktopManager
In-Reply-To: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
References: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
Message-ID: <6SDInkCsT9fCdeShU_lO-y1yCZyw5Pk2FP17PgYs7ZI=.d09bbaeb-74e8-49b2-b4f5-c4170c470885@github.com>

On Wed, 26 Nov 2025 06:57:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with `setMaximum(true)` then after opening the second internal frame the new internal frame is opened as non-maximized
> 
> The fix makes sure the 2nd internal frame remains maximised if it is set with maximized attrbute, that is
> If the current frame is maximized, transfer that attribute to the frame being activated. 
> which is also mentioned in this comment 
> https://github.com/openjdk/jdk/blob/46ee8d550e42f756dd04fa67ed549c93b632df77/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L70-L71
>  
> This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects
> When a frame is maximized and then minimized, the next frame should NOT be maximized.
> 
> It still honours that fix as the test mentioned in JDK-5036083 works as expected as mentioned above along with fixing the present issue..

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java line 88:

> 86:                                 // else remain non-maximised
> 87:                                 if (f.isIcon()) {
> 88:                                     f.setIcon(false);

Before the fix, setIcon was set to `false` if frame is maximized, now its set to `false` if frame is not maximized. Won't this cause any issue ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28502#discussion_r2613263461

From psadhukhan at openjdk.org  Fri Dec 12 07:56:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 07:56:51 GMT
Subject: RFR: 6681958: Maximization state of JInternalFrames is corrupted
 by WindowsDesktopManager
In-Reply-To: <6SDInkCsT9fCdeShU_lO-y1yCZyw5Pk2FP17PgYs7ZI=.d09bbaeb-74e8-49b2-b4f5-c4170c470885@github.com>
References: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
 <6SDInkCsT9fCdeShU_lO-y1yCZyw5Pk2FP17PgYs7ZI=.d09bbaeb-74e8-49b2-b4f5-c4170c470885@github.com>
Message-ID: <-1PoI_O-nB1mtx8yfPRY9ES0pu1bqUWgm5otT4dZGvk=.cf79b99d-93a4-4a24-80da-0271ddb5c8b7@github.com>

On Fri, 12 Dec 2025 07:49:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with `setMaximum(true)` then after opening the second internal frame the new internal frame is opened as non-maximized
>> 
>> The fix makes sure the 2nd internal frame remains maximised if it is set with maximized attrbute, that is
>> If the current frame is maximized, transfer that attribute to the frame being activated. 
>> which is also mentioned in this comment 
>> https://github.com/openjdk/jdk/blob/46ee8d550e42f756dd04fa67ed549c93b632df77/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L70-L71
>>  
>> This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects
>> When a frame is maximized and then minimized, the next frame should NOT be maximized.
>> 
>> It still honours that fix as the test mentioned in JDK-5036083 works as expected as mentioned above along with fixing the present issue..
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java line 88:
> 
>> 86:                                 // else remain non-maximised
>> 87:                                 if (f.isIcon()) {
>> 88:                                     f.setIcon(false);
> 
> Before the fix, setIcon was set to `false` if frame is maximized, now its set to `false` if frame is not maximized. Won't this cause any issue ?

In the else-block which is basically f.isMaximum() case, so frame is maximised and uniconified..its the same before the fix too..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28502#discussion_r2613274052

From psadhukhan at openjdk.org  Fri Dec 12 08:12:29 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 08:12:29 GMT
Subject: RFR: 6681958: Maximization state of JInternalFrames is corrupted
 by WindowsDesktopManager [v2]
In-Reply-To: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
References: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
Message-ID: <Nl_9U72qWg1BU_DAvwzUDRLSOu0535go3E6D05JoEGg=.311b66c8-12e9-4ac7-8337-09fa7c7c4887@github.com>

> Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with `setMaximum(true)` then after opening the second internal frame the new internal frame is opened as non-maximized
> 
> The fix makes sure the 2nd internal frame remains maximised if it is set with maximized attrbute, that is
> If the current frame is maximized, transfer that attribute to the frame being activated. 
> which is also mentioned in this comment 
> https://github.com/openjdk/jdk/blob/46ee8d550e42f756dd04fa67ed549c93b632df77/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L70-L71
>  
> This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects
> When a frame is maximized and then minimized, the next frame should NOT be maximized.
> 
> It still honours that fix as the test mentioned in JDK-5036083 works as expected as mentioned above along with fixing the present issue..

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28502/files
  - new: https://git.openjdk.org/jdk/pull/28502/files/54aa3b61..c6cdaaff

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

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

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

From lbourges at openjdk.org  Fri Dec 12 08:16:54 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 12 Dec 2025 08:16:54 GMT
Subject: RFR: 8372592: Adjust logger usage in java2d tests
In-Reply-To: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
References: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
Message-ID: <dEZoxVhyIRppa61edRF7kyYMF4AXrrUyXcxTvWJpJP8=.7dc1b906-9b40-460e-a688-fb3de2a3bebe@github.com>

On Thu, 11 Dec 2025 22:37:56 GMT, Phil Race <prr at openjdk.org> wrote:

> We had a previous mysterious failure that looks like it was due to a logger being gc'd.
> To prevent that update all the marlin tests to use a logger stored in a static.
> The 'final' modifier probably isn't necessary for this but is harmless, I'm doing the minimum here
> so I don't want to go change log -> LOG everywhere just because its now final.

LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/28778#issuecomment-3645405245

From tr at openjdk.org  Fri Dec 12 08:21:51 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Dec 2025 08:21:51 GMT
Subject: RFR: 6681958: Maximization state of JInternalFrames is corrupted
 by WindowsDesktopManager [v2]
In-Reply-To: <Nl_9U72qWg1BU_DAvwzUDRLSOu0535go3E6D05JoEGg=.311b66c8-12e9-4ac7-8337-09fa7c7c4887@github.com>
References: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
 <Nl_9U72qWg1BU_DAvwzUDRLSOu0535go3E6D05JoEGg=.311b66c8-12e9-4ac7-8337-09fa7c7c4887@github.com>
Message-ID: <-CDtMzJKLKB4_1bP6PWSCmKCzgU11Ep-vVhblzgDg7Y=.668dae44-8331-49bb-b6ee-5d072faa271c@github.com>

On Fri, 12 Dec 2025 08:12:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with `setMaximum(true)` then after opening the second internal frame the new internal frame is opened as non-maximized
>> 
>> The fix makes sure the 2nd internal frame remains maximised if it is set with maximized attrbute, that is
>> If the current frame is maximized, transfer that attribute to the frame being activated. 
>> which is also mentioned in this comment 
>> https://github.com/openjdk/jdk/blob/46ee8d550e42f756dd04fa67ed549c93b632df77/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L70-L71
>>  
>> This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects
>> When a frame is maximized and then minimized, the next frame should NOT be maximized.
>> 
>> It still honours that fix as the test mentioned in JDK-5036083 works as expected as mentioned above along with fixing the present issue..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

LGTM

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28502#pullrequestreview-3570805105

From psadhukhan at openjdk.org  Fri Dec 12 09:35:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Dec 2025 09:35:00 GMT
Subject: RFR: 8372592: Adjust logger usage in java2d tests
In-Reply-To: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
References: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
Message-ID: <b-KSxgCDC8iamFOJgds5I5Jx97Li8KELrW7ymXXVTBY=.d49c8c51-05a9-4bc5-a4f4-f086e6fe7bde@github.com>

On Thu, 11 Dec 2025 22:37:56 GMT, Phil Race <prr at openjdk.org> wrote:

> We had a previous mysterious failure that looks like it was due to a logger being gc'd.
> To prevent that update all the marlin tests to use a logger stored in a static.
> The 'final' modifier probably isn't necessary for this but is harmless, I'm doing the minimum here
> so I don't want to go change log -> LOG everywhere just because its now final.

test/jdk/sun/java2d/marlin/CrashNaNTest.java line 57:

> 55:     static final boolean SAVE_IMAGE = false;
> 56: 
> 57:     // initialize j.u.l Looger:

looger -> logger

test/jdk/sun/java2d/marlin/CrashPaintTest.java line 56:

> 54:     static final boolean SAVE_IMAGE = false;
> 55: 
> 56:     // initialize j.u.l Looger:

same

test/jdk/sun/java2d/marlin/TextClipErrorTest.java line 64:

> 62:     static final boolean SERIALIZE = false;
> 63: 
> 64:     // initialize j.u.l Looger:

same

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28778#discussion_r2613548458
PR Review Comment: https://git.openjdk.org/jdk/pull/28778#discussion_r2613549049
PR Review Comment: https://git.openjdk.org/jdk/pull/28778#discussion_r2613549369

From duke at openjdk.org  Fri Dec 12 12:49:25 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 12 Dec 2025 12:49:25 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
Message-ID: <02wlgzkNgFv-7myPxnmltIMQ7pyn8SBv-PjNmB99yZk=.39131289-4886-4be5-a0bc-eb8b48252788@github.com>

On Thu, 11 Dec 2025 21:47:57 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Removes uncessary import and adds blank lines between import blocks
>>  - Makes inherited method final
>>  - Removes unnecessary URL
>>  - Fixes a typo
>>  - Removes unncessary boolean variable, line and import
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Cleans up code for move visibility
>>  - Cleans up code and adds missed import
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/2d4a1200...59a937ac
>
> I believe this one is ready to be integrated now. Unfortunately, I couldn't find the time to re-review it earlier, it always slipped.
> 
> I'm also running the tests with merged master to ensure the tests removed from the PL don't fail.

@aivanov-jdk  I have run testing after merging my PR branch with master and I can see that the two tests fails. I think it is safe to problem list these two tests:  ava/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java and java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java.

I will run testing on the other tests that are removed from Problem list to make sure we they pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3646346373

From rriggs at openjdk.org  Fri Dec 12 15:00:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Dec 2025 15:00:39 GMT
Subject: RFR: 8372592: Adjust logger usage in java2d tests
In-Reply-To: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
References: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
Message-ID: <oG0TLcweYtR04ZEA4oeTgD5iAmZeAGCPaR_2_tkXlYA=.3a854fa2-0c46-4184-b9c6-162c5f2792e5@github.com>

On Thu, 11 Dec 2025 22:37:56 GMT, Phil Race <prr at openjdk.org> wrote:

> We had a previous mysterious failure that looks like it was due to a logger being gc'd.
> To prevent that update all the marlin tests to use a logger stored in a static.
> The 'final' modifier probably isn't necessary for this but is harmless, I'm doing the minimum here
> so I don't want to go change log -> LOG everywhere just because its now final.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28778#pullrequestreview-3572169763

From duke at openjdk.org  Fri Dec 12 15:06:25 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 12 Dec 2025 15:06:25 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v45]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <ktmGp4UeQQUiYiGZSVM17wopyEg9KlhQ3azFi1oIksA=.abbe420d-227f-4e04-9d14-43a1c9bb8b46@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Merge branch 'master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Removes uncessary import and adds blank lines between import blocks
 - Makes inherited method final
 - Removes unnecessary URL
 - Fixes a typo
 - Removes unncessary boolean variable, line and import
 - Merge branch 'openjdk:master' into jdk-8158801
 - Cleans up code for move visibility
 - ... and 57 more: https://git.openjdk.org/jdk/compare/a99f340e...109c8f00

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

Changes: https://git.openjdk.org/jdk/pull/25971/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=44
  Stats: 202 lines in 14 files changed: 96 ins; 71 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Fri Dec 12 15:10:23 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 12 Dec 2025 15:10:23 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
Message-ID: <hqxWDNKAkwlvYHQ20g-NxxMb7Kow9MSI7rhOrjSvZtQ=.3a9a7c6d-7190-44e7-9918-6b109b66d1b4@github.com>

On Thu, 11 Dec 2025 21:47:57 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Removes uncessary import and adds blank lines between import blocks
>>  - Makes inherited method final
>>  - Removes unnecessary URL
>>  - Fixes a typo
>>  - Removes unncessary boolean variable, line and import
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Cleans up code for move visibility
>>  - Cleans up code and adds missed import
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/bfddd85d...59a937ac
>
> I believe this one is ready to be integrated now. Unfortunately, I couldn't find the time to re-review it earlier, it always slipped.
> 
> I'm also running the tests with merged master to ensure the tests removed from the PL don't fail.

@aivanov-jdk I continue to see failures for tests: java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java and java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java. I have resolved conflict by keeping these two tests in problem list.

I will fix formatting with a commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3646889168

From duke at openjdk.org  Fri Dec 12 15:28:06 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 12 Dec 2025 15:28:06 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v46]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <GCwFz1zIFKn4NR5ojQs_vlHKwnJamSPIEeq1uxzVIg8=.f2cb546e-e738-4a0d-9997-e43de7fbe31c@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Updates fomatting of source code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/109c8f00..b730e9d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=44-45

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

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

From duke at openjdk.org  Fri Dec 12 15:28:16 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 12 Dec 2025 15:28:16 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <vi10QJSjvS2-fwQM4_RvoHryV_UiV1ImS9zkRlJlGVM=.032355cf-1244-4575-9174-f74e0490058d@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <vi10QJSjvS2-fwQM4_RvoHryV_UiV1ImS9zkRlJlGVM=.032355cf-1244-4575-9174-f74e0490058d@github.com>
Message-ID: <pej7N80n2qT9ztWo5xDAYfZPhvW3aS9YSEVMU8Cr5r0=.abcf79e6-407b-44f5-b35d-cac75aaa8b0b@github.com>

On Thu, 11 Dec 2025 17:27:34 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Removes uncessary import and adds blank lines between import blocks
>>  - Makes inherited method final
>>  - Removes unnecessary URL
>>  - Fixes a typo
>>  - Removes unncessary boolean variable, line and import
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Cleans up code for move visibility
>>  - Cleans up code and adds missed import
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/d5a7c439...59a937ac
>
> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 97:
> 
>> 95: 
>> 96:     @Override
>> 97:     protected final boolean isMultiFramesTest(){
> 
> Suggestion:
> 
>     protected final boolean isMultiFramesTest() {
> 
> Space between the closing parenthesis and the opening brace.

Done!

> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 139:
> 
>> 137: 
>> 138:     @Override
>> 139:     protected void cleanup(){
> 
> Suggestion:
> 
>     protected void cleanup() {

Done.

> test/jdk/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java line 65:
> 
>> 63:     }
>> 64:     private String testSeq;
>> 65:     private final static String checkSeq = "010000101";
> 
> Suggestion:
> 
>     private static final String checkSeq = "010000101";
> 
> Sort modifiers? (Not required.)

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2614608912
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2614607956
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2614609912

From duke at openjdk.org  Fri Dec 12 15:33:48 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 12 Dec 2025 15:33:48 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
Message-ID: <6Wk39pFDFChTEc_F87WrZFKkgegZ2jvUotdDYMa1q8M=.c126446f-0364-44d9-9b2a-e4d47de30a42@github.com>

On Thu, 11 Dec 2025 21:47:57 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Removes uncessary import and adds blank lines between import blocks
>>  - Makes inherited method final
>>  - Removes unnecessary URL
>>  - Fixes a typo
>>  - Removes unncessary boolean variable, line and import
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Cleans up code for move visibility
>>  - Cleans up code and adds missed import
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/72db65cf...59a937ac
>
> I believe this one is ready to be integrated now. Unfortunately, I couldn't find the time to re-review it earlier, it always slipped.
> 
> I'm also running the tests with merged master to ensure the tests removed from the PL don't fail.

@aivanov-jdk  I have resolved conflicts and updated formatting as requested.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3647015384

From duke at openjdk.org  Fri Dec 12 15:33:51 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 12 Dec 2025 15:33:51 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <Ynyb-PLdignEOif_AAA-Dw2jQoU7jqtgDT7BOTxdrKE=.449295ba-9d22-4e7d-84e3-3e9f259feab5@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <vi10QJSjvS2-fwQM4_RvoHryV_UiV1ImS9zkRlJlGVM=.032355cf-1244-4575-9174-f74e0490058d@github.com>
 <Ynyb-PLdignEOif_AAA-Dw2jQoU7jqtgDT7BOTxdrKE=.449295ba-9d22-4e7d-84e3-3e9f259feab5@github.com>
Message-ID: <VyplNYC8f3QMd1nqNgkoMhUyJR_0YQmjj2_eAnDaoNo=.7d8b174d-6a29-411c-91bd-47e1434d6a71@github.com>

On Thu, 11 Dec 2025 18:48:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 69:
>> 
>>> 67:             frame.setVisible(false);
>>> 68:         }
>>> 69:         frame = new JFrame("Mixing : Dropdown Overlapping test");
>> 
>> Should the old frame be disposed of instead of just hidden?
>> 
>> Is it even possible that `frame` is not `null`?
>
> This is a question for further refactoring? No need to address it now.

Since this test fails anyway (It seems to fail mainly in Windows 11, I have not seen it failing on Windows Server 2025)   I will have a look at it when working on bug [JDK-8370584](https://bugs.openjdk.org/browse/JDK-8370584)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2614630627

From serb at openjdk.org  Fri Dec 12 16:43:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 12 Dec 2025 16:43:51 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <dLFHhbJxKDGiXeA2U9AkwMLcEtZ12IHmnhKzWVml5_E=.d595bfe5-e47a-49bc-b17a-ad6a5eab43bd@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3572713212

From dnguyen at openjdk.org  Fri Dec 12 17:21:55 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 12 Dec 2025 17:21:55 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <V_kVEHiV116kHNIyBsmxvPYdVdGyMTxxd5uHBBe0kCo=.de17b44d-c807-4784-9c66-047df879d212@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
 <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>
 <XdxNWejtFTQ90z1yyMywnv2NZ5oL77Cbd_-egZkrTLo=.79ce9e2b-2c5a-420e-af58-96857e1fbeb4@github.com>
 <V_kVEHiV116kHNIyBsmxvPYdVdGyMTxxd5uHBBe0kCo=.de17b44d-c807-4784-9c66-047df879d212@github.com>
Message-ID: <IYFtRfgNWo3i3t_MXfJ2hltYgi4l-sjv9DFm39rJxhM=.444252cb-443f-4ce5-92e8-f5ea5a9d50bc@github.com>

On Fri, 12 Dec 2025 07:29:58 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Good point. I have switched to a single frame at a time and have created a new final var to limit the number of frames to test (30). When testing, the balance of stability and testing duration felt reasonable. The test still creates, tests, and disposes multiple frames on Ubuntu, and the test still passes testing after the changes.
>
>> I have switched to a single frame at a time 
> 
> This makes the test much slower. On my machine, the execution time is::
> - ~33s with the one at a time version
> - ~10s for version with all gcs in batches of 20 
>  
> Few notes on placing several frames:
> <img width="1012" height="222" alt="image" src="https://github.com/user-attachments/assets/98820fd5-5c9e-4f9c-b2d4-a87681a56cb6" />
> - If they are close enough, they can cast shadows on each other.
> - If the auto-hide dock is disabled, the dock can overlap frames.  The dock auto-hide is enabled on the CI, but it would be better if it could be moved away from the screen border.

Is 33 seconds unreasonable for the test? I figured since the upper-limit of frame tests is set to 30, this 33 seconds would be the longest the test would run for. Also, the test only has 1 gc for other OS's so only 1 frame is tested for that. This avoids the shadow issue as well as creates a more stable test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2615010816

From prr at openjdk.org  Fri Dec 12 18:04:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:04:54 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <dIONKF2kQv5hpJlIwjLhfFnH4Z48OTth3gOeGk7e7zQ=.93ebdbef-716a-4014-bc62-627fd764bb2e@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3573006281

From prr at openjdk.org  Fri Dec 12 18:07:04 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:07:04 GMT
Subject: Integrated: 8372592: Adjust logger usage in java2d tests
In-Reply-To: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
References: <1Qp7xSFobJuufea1-yJqN56opmp49jKv7Z3-jbms2JM=.bf66c2e5-fbe4-4e94-a453-eb910434ca36@github.com>
Message-ID: <otMlFx792pk9voQ60jptk9KezsxMPVJx8brIQ8socyQ=.7befda87-9dcc-4aaa-a311-fbb0ad378889@github.com>

On Thu, 11 Dec 2025 22:37:56 GMT, Phil Race <prr at openjdk.org> wrote:

> We had a previous mysterious failure that looks like it was due to a logger being gc'd.
> To prevent that update all the marlin tests to use a logger stored in a static.
> The 'final' modifier probably isn't necessary for this but is harmless, I'm doing the minimum here
> so I don't want to go change log -> LOG everywhere just because its now final.

This pull request has now been integrated.

Changeset: e65e0686
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e65e06867e7a841c7edce0625f856b8bc2888893
Stats:     19 lines in 4 files changed: 11 ins; 8 del; 0 mod

8372592: Adjust logger usage in java2d tests

Reviewed-by: kizune, serb, rriggs

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

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

From prr at openjdk.org  Fri Dec 12 18:09:02 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:09:02 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v4]
In-Reply-To: <tYp6e3eJQbbbif5E5yrr043aMlM-PgDwszM9g5ttCw8=.ef1cebdf-0d79-4462-842c-a727e9cf1e5f@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <tYp6e3eJQbbbif5E5yrr043aMlM-PgDwszM9g5ttCw8=.ef1cebdf-0d79-4462-842c-a727e9cf1e5f@github.com>
Message-ID: <FZq9SBq1B-W7oQa86QNAu1JGZzv6jALbs7fdhMGTW78=.ea2859a7-028b-4aa9-ba45-f57ca12d77d9@github.com>

On Thu, 11 Dec 2025 23:31:47 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
>> 
>> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test one frame at a time and limit number of gcs.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28646#pullrequestreview-3573017723

From prr at openjdk.org  Fri Dec 12 18:09:03 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:09:03 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <IYFtRfgNWo3i3t_MXfJ2hltYgi4l-sjv9DFm39rJxhM=.444252cb-443f-4ce5-92e8-f5ea5a9d50bc@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
 <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>
 <XdxNWejtFTQ90z1yyMywnv2NZ5oL77Cbd_-egZkrTLo=.79ce9e2b-2c5a-420e-af58-96857e1fbeb4@github.com>
 <V_kVEHiV116kHNIyBsmxvPYdVdGyMTxxd5uHBBe0kCo=.de17b44d-c807-4784-9c66-047df879d212@github.com>
 <IYFtRfgNWo3i3t_MXfJ2hltYgi4l-sjv9DFm39rJxhM=.444252cb-443f-4ce5-92e8-f5ea5a9d50bc@github.com>
Message-ID: <xhsR-KfiRPnqSb2pOHbHHBihzeQ6UKZYAabSjFVusWs=.ba59715d-1acc-46dd-90ae-b29a5a210c21@github.com>

On Fri, 12 Dec 2025 17:18:49 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>>> I have switched to a single frame at a time 
>> 
>> This makes the test much slower. On my machine, the execution time is::
>> - ~33s with the one at a time version
>> - ~10s for version with all gcs in batches of 20 
>>  
>> Few notes on placing several frames:
>> <img width="1012" height="222" alt="image" src="https://github.com/user-attachments/assets/98820fd5-5c9e-4f9c-b2d4-a87681a56cb6" />
>> - If they are close enough, they can cast shadows on each other.
>> - If the auto-hide dock is disabled, the dock can overlap frames.  The dock auto-hide is enabled on the CI, but it would be better if it could be moved away from the screen border.
>
> Is 33 seconds unreasonable for the test? I figured since the upper-limit of frame tests is set to 30, this 33 seconds would be the longest the test would run for. Also, the test only has 1 gc for other OS's so only 1 frame is tested for that. This avoids the shadow issue as well as creates a more stable test.

I will take stability at the cost of some extra time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2615132807

From prr at openjdk.org  Fri Dec 12 18:09:59 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:09:59 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v9]
In-Reply-To: <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <2DBu36zE3beU_knxnBljTntowN7bsFyUcWat7xFAttI=.ca3be83f-c872-481d-b666-a0689183ee10@github.com>
Message-ID: <UQ2cPh_wEPJ3oRfXj7IPGPEoFZC_ophny6lzkAnHs1Y=.06a4779c-a611-4d3a-b159-98547619d220@github.com>

On Wed, 26 Nov 2025 10:11:43 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
>> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt.
>
> Srinivas Mandalika has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Trigger the bot.
>  - Merge branch '8068378' of github.com:srmandal/jdk into 8068378
>  - Merge branch 'master' of github.com:openjdk/jdk into 8068378
>  - Added line after subsection name
>  - Merge master
>  - Fixed Typos
>  - Fixed whitepsace error.
>  - 8068378: Review feedback for instructions, missing break in switch case in Test.java
>  - Removed Merge Conflict from PL file.
>  - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27139#pullrequestreview-3573020344

From prr at openjdk.org  Fri Dec 12 18:10:05 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:10:05 GMT
Subject: Integrated: 7067310: 3 tests from closed/javax/sound/sampled caused
 BSOD on win 7 x86
In-Reply-To: <R0CjhaqHKz4NzAsyzMQQSRi20GKjbI0fke0BL3jV55E=.18b8b50d-435f-43bb-83e0-1e85e074d96b@github.com>
References: <R0CjhaqHKz4NzAsyzMQQSRi20GKjbI0fke0BL3jV55E=.18b8b50d-435f-43bb-83e0-1e85e074d96b@github.com>
Message-ID: <iHmDyCIksXozR3lhHpr05NPyKeDF2QmHYZDAR5m7oJY=.8e24936d-6093-4e49-8537-c05af6c9bde9@github.com>

On Thu, 11 Dec 2025 20:14:22 GMT, Phil Race <prr at openjdk.org> wrote:

> I am de-problem listing several sound tests.
> These tests pass over and over again on all platforms when run on JDK 27 in an environment that supports sound.
> I'm seeing no failures at all.
> There are multiple bug IDs used to problem list these tests but only one can be the 'main' bug ID.
> I've picked the oldest for that, and will "add" some of the additional issues.
> In a few cases they happen to be non-public bugs for the accidental reason that someone added some internal information I can't delete, so you won't be able to see those bug ids, but there's nothing special about them and I'll close them as dups of  7067310

This pull request has now been integrated.

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

7067310: 3 tests from closed/javax/sound/sampled caused BSOD on win 7 x86
8307574: ClipIsRunningAfterStop.java failed with "../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed."
8308395: javax/sound/sampled/Clip/ClipFlushCrash.java timed out

Reviewed-by: serb

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

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

From prr at openjdk.org  Fri Dec 12 18:10:01 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:10:01 GMT
Subject: RFR: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update [v3]
In-Reply-To: <4bOVvTSwAU4E0gPPN34DiFc3xRxOy_BBLOHxcKJGC1I=.99186bce-1c08-4360-a453-ee30819e90ea@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
 <PU25-GhkDgozmFpcKe7UMoCEDCLRZwAHFYz28n_ppp8=.bc6b5885-80e6-4871-85d8-046e4aa28066@github.com>
 <4mPIir7nLbChdT1EmbHL0CkuIgW69-En1TDQmF0IeVE=.a2565f2e-1953-4a12-bb7b-65b0db10be56@github.com>
 <MdlAcufqp9eH7uWNKJyPTFp8SgKPejZdBD-IzHS4plc=.35727133-b050-4e64-b1ba-988ee8dff954@github.com>
 <4bOVvTSwAU4E0gPPN34DiFc3xRxOy_BBLOHxcKJGC1I=.99186bce-1c08-4360-a453-ee30819e90ea@github.com>
Message-ID: <Q5oFaLEbryXI_3iVFvxJBls81Ozbsz-Zk87_xSNIj0o=.c9c9d77a-1392-4abc-8ec1-02f9c255f028@github.com>

On Fri, 12 Dec 2025 05:36:51 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

>> I guess I had commented on it and is now resolved https://github.com/openjdk/jdk/pull/27139#discussion_r2536937973
>> Probably you are looking at wrong version of the file..
>
> Yes, that is correct. I have confirmed this by searching for the misspelled string "presseed" and see no instance of it in the code.

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27139#discussion_r2615134836

From smandalika at openjdk.org  Fri Dec 12 18:13:03 2025
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Fri, 12 Dec 2025 18:13:03 GMT
Subject: Integrated: 8068378: [TEST_BUG]The
 java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to
 update
In-Reply-To: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
References: <MlfiNS4AjaxT1WxqQX7rj6Cmbw8yPSQKwjWEEJliqQo=.0d23e710-9698-4974-b3e0-0d66a0189464@github.com>
Message-ID: <YGSM_9KZOevMZVop9V2gwxV4OsxOokXh0rDgjjiYyNo=.db601d71-01c4-4943-b044-54a3c18c8fd7@github.com>

On Mon, 8 Sep 2025 09:44:30 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
> Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt.

This pull request has now been integrated.

Changeset: 6e2ab841
Author:    Srinivas Mandalika <smandalika at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e2ab84154e7cc11a31026c588a7dc3ceb446cc2
Stats:     36 lines in 3 files changed: 1 ins; 6 del; 29 mod

8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update

Reviewed-by: psadhukhan, prr

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

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

From prr at openjdk.org  Fri Dec 12 18:24:28 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:24:28 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
Message-ID: <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>

On Thu, 11 Dec 2025 21:47:57 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 66 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Removes uncessary import and adds blank lines between import blocks
>>  - Makes inherited method final
>>  - Removes unnecessary URL
>>  - Fixes a typo
>>  - Removes unncessary boolean variable, line and import
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Cleans up code for move visibility
>>  - Cleans up code and adds missed import
>>  - ... and 56 more: https://git.openjdk.org/jdk/compare/49dc78b1...59a937ac
>
> I believe this one is ready to be integrated now. Unfortunately, I couldn't find the time to re-review it earlier, it always slipped.
> 
> I'm also running the tests with merged master to ensure the tests removed from the PL don't fail.

> @aivanov-jdk I continue to see failures for tests: java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java and java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java. I have resolved conflict by keeping these two tests in problem list.
> 
> I will fix formatting with a commit.

But that means that although you're resolving this bug it is still used in the problem list

java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801,8357360 windows-all,linux-all

That line needs to be updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3647632382

From prr at openjdk.org  Fri Dec 12 18:45:51 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Dec 2025 18:45:51 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <Fhp0BzM4naDywjnlwpCLPZoSSj_OjLCylwD5LgzwRTI=.e82d6c71-b92f-40bb-ab4c-8b45a5fd0b7c@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

Marked as reviewed by prr (Reviewer).

> > Why was it enabled in the first place ?
> If your question is about 'why for libsplashscreen' , because we see some good lib size - benefits for this lib (there were some measurements by @mserb for this [#27976 (comment)](https://github.com/openjdk/jdk/pull/27976#issuecomment-3568427441) ) .

Yes, my question was  why splash screen out of all the libraries in the JDK.
I guess a size reduction is good, but I've no idea if it helps performance.
Note that on Linux, IIRC,  the system gif/png/jpeg libs may be used by the build, and in such a case
I doubt there's much "size" left to reduce.

I've re-tested the comparison build and it passed. So I'll approve, just for this one library.

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

PR Review: https://git.openjdk.org/jdk/pull/28746#pullrequestreview-3573133409
PR Comment: https://git.openjdk.org/jdk/pull/28746#issuecomment-3647698972

From mbaesken at openjdk.org  Fri Dec 12 19:00:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 12 Dec 2025 19:00:04 GMT
Subject: RFR: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <ha1tSXepXPOspUfbuf5B4mBq_mGUcq68SQ2nkJvUvQ4=.5b675e12-1e23-48ea-97a4-11bccffe47ec@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/28746#issuecomment-3647751532

From mbaesken at openjdk.org  Fri Dec 12 19:00:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 12 Dec 2025 19:00:05 GMT
Subject: Integrated: 8373388: Reenable LTO for libsplashscreen
In-Reply-To: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
References: <I8qjIgC4PbUNlVYGNhLkAiLebVbMvLAS3y8KjaO9sow=.8a626e46-b578-4314-b4dd-ccdbef602973@github.com>
Message-ID: <p-0bAPmom1fcMj-u4N5lWartQg0xgChW3T2oT56r3Hc=.a4e5bc9b-f82d-4558-9b42-324ca12f298a@github.com>

On Wed, 10 Dec 2025 13:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> [JDK-8372554](https://bugs.openjdk.org/browse/JDK-8372554) disabled LTO for libsplashscreen to fix an issue with the comparison build. It turns out the failure was caused by extra files that LTO produced and which were included in the image. Now that [JDK-8373255](https://bugs.openjdk.org/browse/JDK-8373255) has fixed that we should be able to reenable LTO again.

This pull request has now been integrated.

Changeset: 4e9525ef
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e9525ef3619b02e905f16b89261b82c70830f3a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8373388: Reenable LTO for libsplashscreen

Reviewed-by: erikj, dholmes, serb, prr

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

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

From dgredler at openjdk.org  Sat Dec 13 00:41:08 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Sat, 13 Dec 2025 00:41:08 GMT
Subject: RFR: 6562639: Wrong pixel bounds from TextLayout with white font
Message-ID: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com>

One of the possible code paths for `TextLayout.getPixelBounds(...)` actually draws the text on a `Graphics2D` and checks the image pixels afterwards. The text is drawn over a white background, so if the user sets the font's foreground color to white then the text pixels cannot be detected (white on white).

This PR fixes the issue by removing the code that sets the background to white, leaving the background as the default ARGB color (0 = transparent black). This does not cause a new problem for users who might set their font foreground color to transparent black, because transparent font foreground colors always return an empty bounds anyway (by virtue of being transparent).

The updated code should also be slightly faster since it's doing less work, though I haven't run any performance tests.

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

Commit messages:
 - Fix test on mac
 - Fix pixel bounds calculation for white text

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

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

From prr at openjdk.org  Sat Dec 13 19:26:22 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 13 Dec 2025 19:26:22 GMT
Subject: RFR: 8373632: Some sound tests failing in CI due to lack of sound key
Message-ID: <a8heS56mFIcCxLJ1jmHArMOmbpe3x6ZuloLeHHyyT5w=.ba7e3a94-1c61-4c5e-8a8d-8ae1723ac59f@github.com>

This adds the sound keyword to 4 jtreg tests which are failing in CI. Because they don't have the sound key they can get run on a system without permissions and this causes a hang on macOS 26 (a macOS bug which will be fixed in a future macOS update). 3 of the tests are new failures because I didn't add the keyword when de-problem listing them - I should have.
The other is one I saw fail when re-running all the sound tests but it passes now (in another 40+runs) with the sound key added.

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

Commit messages:
 - 8373632

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

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

From iris at openjdk.org  Sat Dec 13 19:54:50 2025
From: iris at openjdk.org (Iris Clark)
Date: Sat, 13 Dec 2025 19:54:50 GMT
Subject: RFR: 8373632: Some sound tests failing in CI due to lack of sound
 key
In-Reply-To: <a8heS56mFIcCxLJ1jmHArMOmbpe3x6ZuloLeHHyyT5w=.ba7e3a94-1c61-4c5e-8a8d-8ae1723ac59f@github.com>
References: <a8heS56mFIcCxLJ1jmHArMOmbpe3x6ZuloLeHHyyT5w=.ba7e3a94-1c61-4c5e-8a8d-8ae1723ac59f@github.com>
Message-ID: <RhKFYSn5fk1C_hLsuc4Q2VP4Bl6OqALZmVHo2Z7FVCA=.4a163401-bc0e-41da-8a7a-9ef192d5d0bb@github.com>

On Sat, 13 Dec 2025 19:19:59 GMT, Phil Race <prr at openjdk.org> wrote:

> This adds the sound keyword to 4 jtreg tests which are failing in CI. Because they don't have the sound key they can get run on a system without permissions and this causes a hang on macOS 26 (a macOS bug which will be fixed in a future macOS update). 3 of the tests are new failures because I didn't add the keyword when de-problem listing them - I should have.
> The other is one I saw fail when re-running all the sound tests but it passes now (in another 40+runs) with the sound key added.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28813#pullrequestreview-3574537192

From prr at openjdk.org  Sat Dec 13 22:46:04 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 13 Dec 2025 22:46:04 GMT
Subject: Integrated: 8373632: Some sound tests failing in CI due to lack of
 sound key
In-Reply-To: <a8heS56mFIcCxLJ1jmHArMOmbpe3x6ZuloLeHHyyT5w=.ba7e3a94-1c61-4c5e-8a8d-8ae1723ac59f@github.com>
References: <a8heS56mFIcCxLJ1jmHArMOmbpe3x6ZuloLeHHyyT5w=.ba7e3a94-1c61-4c5e-8a8d-8ae1723ac59f@github.com>
Message-ID: <Ud3ZSxxNk3QUnJO662blfys_c4iFnlS3GgNHqxRPB-A=.d54145be-fe7c-4ae0-b43e-49e460af21e9@github.com>

On Sat, 13 Dec 2025 19:19:59 GMT, Phil Race <prr at openjdk.org> wrote:

> This adds the sound keyword to 4 jtreg tests which are failing in CI. Because they don't have the sound key they can get run on a system without permissions and this causes a hang on macOS 26 (a macOS bug which will be fixed in a future macOS update). 3 of the tests are new failures because I didn't add the keyword when de-problem listing them - I should have.
> The other is one I saw fail when re-running all the sound tests but it passes now (in another 40+runs) with the sound key added.

This pull request has now been integrated.

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

8373632: Some sound tests failing in CI due to lack of sound key

Reviewed-by: iris

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

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

From serb at openjdk.org  Mon Dec 15 00:22:18 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 15 Dec 2025 00:22:18 GMT
Subject: RFR: 8372974: Add missing @Override annotations in
 "com.sun.java.swing.plaf.gtk" package [v2]
In-Reply-To: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>
References: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>
Message-ID: <4xb-7g5WPLJxU9IBL3Vo8zjd34nQr-WOkzV6O8nSs1s=.7463d3ee-4b84-4dc1-b8e5-d9a066eec3d6@github.com>

> This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.gtk` 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.
> 
> BTW, does anybody know why the gtk l&f is located in the shared code? Possibly we could move it to the unix folder, similar to how the windows l&f was moved to the windows folder in https://bugs.openjdk.org/browse/JDK-8189656 ?

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28624/files
  - new: https://git.openjdk.org/jdk/pull/28624/files/604699c9..ee5c2ebc

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

  Stats: 47241 lines in 779 files changed: 31241 ins; 11897 del; 4103 mod
  Patch: https://git.openjdk.org/jdk/pull/28624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28624/head:pull/28624

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

From kizune at openjdk.org  Mon Dec 15 03:34:53 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 15 Dec 2025 03:34:53 GMT
Subject: RFR: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights [v3]
In-Reply-To: <KYsRchS9UMt57J99IlZnyBHHsHW2iBKqvh7b2xleImo=.e07455b4-cee3-4623-a1e9-6a9e27ddd7d9@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
 <KYsRchS9UMt57J99IlZnyBHHsHW2iBKqvh7b2xleImo=.e07455b4-cee3-4623-a1e9-6a9e27ddd7d9@github.com>
Message-ID: <1XpM7qW7ptEAU0VwKP12zuDGz4XnE9IcIbQxrtgd608=.06da3571-4a79-42ae-986c-3e556fe6af5f@github.com>

On Fri, 12 Dec 2025 07:46:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using `JTable.setRowHeight(row, height).` 
>> The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it
>> `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed.
>> 
>> The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is.
>> Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event
>> 
>> No other issue observed with CI with this fix..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28529#pullrequestreview-3576254799

From kizune at openjdk.org  Mon Dec 15 03:35:55 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 15 Dec 2025 03:35:55 GMT
Subject: RFR: 6681958: Maximization state of JInternalFrames is corrupted
 by WindowsDesktopManager [v2]
In-Reply-To: <Nl_9U72qWg1BU_DAvwzUDRLSOu0535go3E6D05JoEGg=.311b66c8-12e9-4ac7-8337-09fa7c7c4887@github.com>
References: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
 <Nl_9U72qWg1BU_DAvwzUDRLSOu0535go3E6D05JoEGg=.311b66c8-12e9-4ac7-8337-09fa7c7c4887@github.com>
Message-ID: <4FuElQAKl9DaVdss2YrX2iY_VL94-tZMQ3-g7pnXx_g=.e23e704a-5263-44b3-a46f-abc6dfd1f0a1@github.com>

On Fri, 12 Dec 2025 08:12:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with `setMaximum(true)` then after opening the second internal frame the new internal frame is opened as non-maximized
>> 
>> The fix makes sure the 2nd internal frame remains maximised if it is set with maximized attrbute, that is
>> If the current frame is maximized, transfer that attribute to the frame being activated. 
>> which is also mentioned in this comment 
>> https://github.com/openjdk/jdk/blob/46ee8d550e42f756dd04fa67ed549c93b632df77/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L70-L71
>>  
>> This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects
>> When a frame is maximized and then minimized, the next frame should NOT be maximized.
>> 
>> It still honours that fix as the test mentioned in JDK-5036083 works as expected as mentioned above along with fixing the present issue..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

Looks reasonable.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28502#pullrequestreview-3576256087

From psadhukhan at openjdk.org  Mon Dec 15 04:49:05 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 15 Dec 2025 04:49:05 GMT
Subject: Integrated: 6292135: DefaultTableModel.setColumnIdentifiers() Clears
 JTable Row Heights
In-Reply-To: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
References: <hSzPCPkLsMRu4O8Bs1WUSpEWrYG7LHE63v0iBjMZt70=.b741fcd1-1ea9-4295-8ad8-85cdec5a55f7@github.com>
Message-ID: <Chrd7bIs-I4JGeQlT71de_NH0W0hbMmm8uMSoJPXOdc=.5b8fa396-b327-481e-bd36-1097a2d9dac1@github.com>

On Thu, 27 Nov 2025 09:53:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Calling `DefaultTableModel.setColumnIdentifiers()` resizes the row height of the table to default row height (16) even if the row height is changed to something other than the default using `JTable.setRowHeight(row, height).` 
> The spec of `DefaultTableModel.setColumnIdentifiers()` https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/table/DefaultTableModel.html#setColumnIdentifiers(java.lang.Object[]) says that it
> `replaces the column identifiers in the model`, that is, the header field of the column is changed to the passed identifier and nowhere it is mentioned that row height would be changed.
> 
> The issue happens because calling `DefaultTableModel.setColumnIdentifiers()` results in the firing of a `TableModelEvent` with HEADER_ROW event and JTable resets the `rowModel` for it irrespective of what the event is.
> Fix is to not reset the `rowModel` to keep the set rowHeight intact for HEADER_ROW event
> 
> No other issue observed with CI with this fix..

This pull request has now been integrated.

Changeset: 5edeb71e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5edeb71e3b148d52962c46180c92ebfeda018f67
Stats:     66 lines in 2 files changed: 64 ins; 2 del; 0 mod

6292135: DefaultTableModel.setColumnIdentifiers() Clears JTable Row Heights

Reviewed-by: tr, kizune

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

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

From psadhukhan at openjdk.org  Mon Dec 15 04:55:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 15 Dec 2025 04:55:07 GMT
Subject: Integrated: 6681958: Maximization state of JInternalFrames is
 corrupted by WindowsDesktopManager
In-Reply-To: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
References: <gDjir5Ky2h56IKMKgRUVXJcUQZsfvg-NrZlDpRUSxkY=.dc28db20-d767-44fc-9596-09aaa2d5935e@github.com>
Message-ID: <t703QLvJrVEoZvObXfBgTdPq3-LgE13OgAOL5Jktvfw=.3e88a57f-4237-4276-8150-24ed8d7eab90@github.com>

On Wed, 26 Nov 2025 06:57:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with `setMaximum(true)` then after opening the second internal frame the new internal frame is opened as non-maximized
> 
> The fix makes sure the 2nd internal frame remains maximised if it is set with maximized attrbute, that is
> If the current frame is maximized, transfer that attribute to the frame being activated. 
> which is also mentioned in this comment 
> https://github.com/openjdk/jdk/blob/46ee8d550e42f756dd04fa67ed549c93b632df77/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L70-L71
>  
> This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects
> When a frame is maximized and then minimized, the next frame should NOT be maximized.
> 
> It still honours that fix as the test mentioned in JDK-5036083 works as expected as mentioned above along with fixing the present issue..

This pull request has now been integrated.

Changeset: 0e7bc6b0
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e7bc6b0928bd860c665ead26d2237055c0c9d27
Stats:     109 lines in 2 files changed: 105 ins; 2 del; 2 mod

6681958: Maximization state of JInternalFrames is corrupted by WindowsDesktopManager

Reviewed-by: tr, kizune

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

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

From dholmes at openjdk.org  Mon Dec 15 06:15:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 06:15:57 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <J9g0D_uX8SeC9oRyLsL1rs2jTr-NpGNfGniwkI4zxfk=.eb573b68-d75e-45a9-a027-fd8779c0d46b@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

LGTM

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3576551694

From psadhukhan at openjdk.org  Mon Dec 15 06:26:36 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 15 Dec 2025 06:26:36 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v5]
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: <qil5OSNzscIg9rDKBn9x4HANeoHzo50Is2lpC2mWz2U=.9c8040fd-26b8-45ff-8aa7-1c4adccd3362@github.com>

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

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

  First step: Stop cell editing and remove reference

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28627/files
  - new: https://git.openjdk.org/jdk/pull/28627/files/9f788115..292e252c

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

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

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

From psadhukhan at openjdk.org  Mon Dec 15 06:26:37 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 15 Dec 2025 06:26:37 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v4]
In-Reply-To: <fqsITOV_7KIrM2OcpDpv9afL9pJruGqH4A3rP5T_KyI=.7b976108-77d8-4403-8875-27c694ea0fb9@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <fqsITOV_7KIrM2OcpDpv9afL9pJruGqH4A3rP5T_KyI=.7b976108-77d8-4403-8875-27c694ea0fb9@github.com>
Message-ID: <I8B_bmWEyCVD9jdSkxkODp3W-e2IVtlpyiF3ao9C79E=.bcbd4953-8bba-4e91-a3b8-571b25c65882@github.com>

On Thu, 11 Dec 2025 04:45:41 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..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GenericEditor serialization fix

As I found, the `GenericEditor `is instantiated and stored as `Object `class in `defaultEditorsByColumnClass `field. So, it seems when `ObjectOutputStream.writeObject` is called, `GenericEditor `is getting serialized as it implements Serializable. `defaultEditorsByColumnClass `is transient so that field will be skipped when the parent JTable object is serialized however, the items stored inside the Hashtable are still objects that exist in memory. The issue is that the standard Java serialization mechanism might still find and serialize the GenericEditor instances through other, less obvious references that Swing creates i.e The transient keyword hides your initial map reference, but doesn't prevent the object from being serialized if reached via other paths.`
defaultEditorsByColumnClass`  uses a `UIDefaults.LazyValue`. This lazy value doesn't create the GenericEditor immediately; it stores a function (a lambda expression) that creates one when `createValue(t)` is called.
The key point is that JTable or the Swing look-and-feel code eventually calls this lazy value to get the actual GenericEditor instance when it needs a default editor. The created GenericEditor instance is then likely stored in an another internal, non-transient field within the JTable or a related UI delegate object.
When you serialize a JTable, Swing's serialization process involves
    JTable itself implements Serializable.
    It has an internal field for a tableHeader.
    It has a ui field (the UI delegate, e.g., BasicTableUI), which also manages aspects of the table's appearance and behavior, including editors.

When we initialize the JTable and it prepares its default editors, it creates instances of those editors. The JTable keeps a strong, non-transient reference to the actual GenericEditor instance via its internal machinery (likely through the TableCellEditor storage mechanism).
Even if  the custom hashtable reference is transient, the built-in Swing fields that now hold the reference to the GenericEditor instance are not transient and participate in the standard serialization process

I tried having GenericEditor implement Externalizable to have control of the GenericEditor serialization process so that GenericEditor doesn't participate in the serialization process and override writeExternal, readExternal. 
Also, readObject() seems to install UI again which is done anyway in writeObject (as is usually done for other classes) which is also removed. 
Also, In writeObject(), cell editing is stopped as all editor related fields are transient but something still retains the reference to JTextField..

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3653588080

From serb at openjdk.org  Mon Dec 15 07:42:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 15 Dec 2025 07:42:02 GMT
Subject: Integrated: 8372974: Add missing @Override annotations in
 "com.sun.java.swing.plaf.gtk" package
In-Reply-To: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>
References: <DVytI_ARua4nOfud-yzuF1Dabex-6N8pj-mTKBi7foU=.cc6f1ef1-9603-4a46-bbe2-94ed7683c7b7@github.com>
Message-ID: <rm85fNxRwxxaC6W60tQQWK7ftorSHqzyyoHz76Ddd0E=.59a49309-e8bd-4f56-842e-745265c23e0f@github.com>

On Wed, 3 Dec 2025 04:39:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch adds missing `@Override` annotations to methods in the `com.sun.java.swing.plaf.gtk` 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.
> 
> BTW, does anybody know why the gtk l&f is located in the shared code? Possibly we could move it to the unix folder, similar to how the windows l&f was moved to the windows folder in https://bugs.openjdk.org/browse/JDK-8189656 ?

This pull request has now been integrated.

Changeset: 01adf28c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01adf28c946580751f7c041b13c987f477a6289a
Stats:     198 lines in 9 files changed: 190 ins; 0 del; 8 mod

8372974: Add missing @Override annotations in "com.sun.java.swing.plaf.gtk" package

Reviewed-by: prr

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

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

From psadhukhan at openjdk.org  Mon Dec 15 08:54:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 15 Dec 2025 08:54:58 GMT
Subject: RFR: 4337898: Serializing DefaultTableCellRenderer changes colors
 [v4]
In-Reply-To: <pYXhmhcWsxxWy9IODCkNmoRaYmv2bU0Wi1Ee8VuzUnE=.c7ed5904-6502-4cb7-b013-9366284e626f@github.com>
References: <7RPOHaLbFxCEgnFqBg5HFXrU1t6gx3CsiiqwbRKN3VQ=.3213266e-8746-4bdf-a4a4-0d3ea7969087@github.com>
 <J8zkZeiUGeCS62k8C6NRacDaGAn8IeIFL7O1G9vNFpk=.46e89f0a-4dda-4448-b48a-23171f4aa9a4@github.com>
 <OIEyF2DgN_wgNEQKgDf9fFxxshEKkVriKA-w9R2A4UE=.9a3b0382-8850-4b0f-9a35-818612ff8a9d@github.com>
 <pYXhmhcWsxxWy9IODCkNmoRaYmv2bU0Wi1Ee8VuzUnE=.c7ed5904-6502-4cb7-b013-9366284e626f@github.com>
Message-ID: <eFrTIGjAenrWPh8_5KcYNuikESfMOMTP7f8PkNp9O2M=.70166b4e-1529-4233-807b-17f91210365d@github.com>

On Fri, 12 Dec 2025 01:26:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > How/why does null restore the JTable-specified colors ? I don't see anything about null in the spec. And what have people been doing the last 25 years if serializing a JTable "broke" its rendering ?
> > > 
> > > 
> > > Specifying null would cause `unselectedForeground` and `unselectedBackground` to be null
> > > so it will fallback to table assigned foreground and background color
> > 
> > 
> > So how do people know that ? Reading the source and trial and error don't count as ways to know.
> 
> Its implementation detail, not sure why people need to know upfront... Are you thinking of user who will extend DefaultTableCellRenderer and provide its own implementation... In that case, do you want me to add some spec wording to DefaultTableCellRenderer?

@prrace Will this wordings be sufficient?


     /**
      * See readObject() and writeObject() in JComponent for more
      * information about serialization in Swing.
+     * Setting foreground and background color to null will restore
+     * the foreground and background color to JTable cell's set
+     * foreground and background color
      */
     @Serial
     private void writeObject(ObjectOutputStream s) throws IOException {

Will it need a CSR? Please let me know soon for me to work on it..

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

PR Comment: https://git.openjdk.org/jdk/pull/28549#issuecomment-3654486494

From duke at openjdk.org  Mon Dec 15 09:50:07 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 15 Dec 2025 09:50:07 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
Message-ID: <p0wQRsFAcJgxBpqj0Rz2nEqobJtpNj_ktI-IN59PNyw=.a05aede9-a592-4109-8fd1-96709b687a00@github.com>

On Fri, 12 Dec 2025 18:21:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> I believe this one is ready to be integrated now. Unfortunately, I couldn't find the time to re-review it earlier, it always slipped.
>> 
>> I'm also running the tests with merged master to ensure the tests removed from the PL don't fail.
>
>> @aivanov-jdk I continue to see failures for tests: java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java and java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java. I have resolved conflict by keeping these two tests in problem list.
>> 
>> I will fix formatting with a commit.
> 
> But that means that although you're resolving this bug it is still used in the problem list
> 
> java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801,8357360 windows-all,linux-all
> 
> That line needs to be updated.
> 
> 8357360 is about a linux failure.
> Where are you seeing it fail still ? If it is only on Linux you can just remove 8158801 from that line (and the windows-all entry)
> Otherwise you'll need to use a different bug ID for windows (a new one perhaps)
> 
> Ah, I believe I found your test job and it is a Linux-only failure, so that line needs to become
> java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8357360 linux-all

@prrace I have just tested java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java  on linux, macos and windows and it has failed on both linux and Windows. I has passed on macos. 

I think based on this, it will be safe to keep test java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java problem listed for linux and windows, if this is ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3654723241

From azvegint at openjdk.org  Mon Dec 15 11:54:43 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 15 Dec 2025 11:54:43 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v4]
In-Reply-To: <tYp6e3eJQbbbif5E5yrr043aMlM-PgDwszM9g5ttCw8=.ef1cebdf-0d79-4462-842c-a727e9cf1e5f@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <tYp6e3eJQbbbif5E5yrr043aMlM-PgDwszM9g5ttCw8=.ef1cebdf-0d79-4462-842c-a727e9cf1e5f@github.com>
Message-ID: <YIv3tRA6T-2nBfXAkLTWTU2rhI9wl-NVlcwZE_Mq_g4=.1e7eba28-8f7a-4741-9cb9-0c925e0bc9b1@github.com>

On Thu, 11 Dec 2025 23:31:47 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
>> 
>> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test one frame at a time and limit number of gcs.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28646#pullrequestreview-3577767371

From azvegint at openjdk.org  Mon Dec 15 11:54:45 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 15 Dec 2025 11:54:45 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <xhsR-KfiRPnqSb2pOHbHHBihzeQ6UKZYAabSjFVusWs=.ba59715d-1acc-46dd-90ae-b29a5a210c21@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
 <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>
 <XdxNWejtFTQ90z1yyMywnv2NZ5oL77Cbd_-egZkrTLo=.79ce9e2b-2c5a-420e-af58-96857e1fbeb4@github.com>
 <V_kVEHiV116kHNIyBsmxvPYdVdGyMTxxd5uHBBe0kCo=.de17b44d-c807-4784-9c66-047df879d212@github.com>
 <IYFtRfgNWo3i3t_MXfJ2hltYgi4l-sjv9DFm39rJxhM=.444252cb-443f-4ce5-92e8-f5ea5a9d50bc@github.com>
 <xhsR-KfiRPnqSb2pOHbHHBihzeQ6UKZYAabSjFVusWs=.ba59715d-1acc-46dd-90ae-b29a5a210c21@github.com>
Message-ID: <i4yarByrvg8beX2ntEQjg0-305SZpySm2hRGI3UKM4I=.36b67fcb-cbe8-4cb5-98d9-a5abb4394e27@github.com>

On Fri, 12 Dec 2025 18:06:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> Is 33 seconds unreasonable for the test? I figured since the upper-limit of frame tests is set to 30, this 33 seconds would be the longest the test would run for. Also, the test only has 1 gc for other OS's so only 1 frame is tested for that. This avoids the shadow issue as well as creates a more stable test.
>
> I will take stability at the cost of some extra time.

> Is 33 seconds unreasonable for the test? I figured since the upper-limit of frame tests is set to 30, this 33 seconds would be the longest the test would run for. Also, the test only has 1 gc for other OS's so only 1 frame is tested for that. 

In CI it may be even slower, and we can achieve the same results in a third of the time with showing several windows at once. This can cumulatively save a lot of CI time over many runs. We can still apply the same upper limit to the frame count of frame tests, and this may make it even faster.

> This avoids the shadow issue as well as creates a more stable test.

This can be mitigated simply by adding spacing between the frames.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2619095403

From jpai at openjdk.org  Mon Dec 15 14:00:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Dec 2025 14:00:18 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <46VBWrTZlAboGapEvJ7jcOc6G_-fLBTrLVvtRxWsJeA=.31442313-8f57-4bb8-91e4-02f9b8706063@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

Thank you all for the reviews. There's one javac related test file update in this PR, so I'll need someone from compiler area to review this too, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/28780#issuecomment-3655782579

From psadhukhan at openjdk.org  Mon Dec 15 14:05:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 15 Dec 2025 14:05:51 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v6]
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: <_9Q5OkPMg1rZw43ZdtNoA8PXacFcJ4ZuK-9qG5Bv4Y0=.26e7ce1a-499e-4806-9288-6184cf9a3e5e@github.com>

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

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

  Leakage fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28627/files
  - new: https://git.openjdk.org/jdk/pull/28627/files/292e252c..57f55306

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

  Stats: 49 lines in 2 files changed: 9 ins; 25 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28627/head:pull/28627

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

From psadhukhan at openjdk.org  Mon Dec 15 14:08:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 15 Dec 2025 14:08:39 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v6]
In-Reply-To: <_9Q5OkPMg1rZw43ZdtNoA8PXacFcJ4ZuK-9qG5Bv4Y0=.26e7ce1a-499e-4806-9288-6184cf9a3e5e@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <_9Q5OkPMg1rZw43ZdtNoA8PXacFcJ4ZuK-9qG5Bv4Y0=.26e7ce1a-499e-4806-9288-6184cf9a3e5e@github.com>
Message-ID: <Om-kpL-UGYx7cqAOwKhKR9YodUgRRUz3R2Vvcc6uBlQ=.7c2704ec-83e1-4634-809a-1a46c7809c27@github.com>

On Mon, 15 Dec 2025 14: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..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Leakage fix

Leakage observation was red herring.
It seems the JTable instance we are inspecting after the read operation is potentially being observed in a test context where the Swing EDT hasn't fully processed all cleanup events yet so when the test is fixed to use EDT properly, it doesn't show the leak and shows componentCount as 2 which is `JTextField ` created in `createDefaultEditors` and `CellRendererPane` created in `installUI`


 public static void main(String[] args) throws Exception {
        StringBuilder str = new StringBuilder();
        testSerializeEditingTable(str);
        testSerializeNonEditingTable(str);
        if (str.length() != 0) {
            throw new RuntimeException(str.toString());
        }
    }

private static JTable jt;
    private static void testSerializeEditingTable(StringBuilder str) {
        try {
            Object[][] data = new Object[][]{ new Object[]{ 1,2,3,4,5}};
            Object[] names = new Object[]{ 1,2,3,4,5};
            while(true) {
                SwingUtilities.invokeAndWait(() -> {
                    jt = new JTable(data, names);
                    jt.editCellAt(0,3);
                });
                System.out.println("Serializing editing JTable");
                JTable newjt = serialize(jt);
                jt = newjt;
                // leak of the GenericEditor/JTextField, the number will grow over time and will cause OOM
                // and it is not possible to clean it after deserialisation we do not have a refs to it
                System.out.println("Count: " + jt.getComponentCount());
            }
        } catch (Exception e) {
            str.append("Failed serializing editing table " + e);
        }

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3655820373

From prr at openjdk.org  Mon Dec 15 19:26:05 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 15 Dec 2025 19:26:05 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
Message-ID: <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>

On Fri, 12 Dec 2025 18:21:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> I believe this one is ready to be integrated now. Unfortunately, I couldn't find the time to re-review it earlier, it always slipped.
>> 
>> I'm also running the tests with merged master to ensure the tests removed from the PL don't fail.
>
>> @aivanov-jdk I continue to see failures for tests: java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java and java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java. I have resolved conflict by keeping these two tests in problem list.
>> 
>> I will fix formatting with a commit.
> 
> But that means that although you're resolving this bug it is still used in the problem list
> 
> java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801,8357360 windows-all,linux-all
> 
> That line needs to be updated.
> 
> 8357360 is about a linux failure.
> Where are you seeing it fail still ? If it is only on Linux you can just remove 8158801 from that line (and the windows-all entry)
> Otherwise you'll need to use a different bug ID for windows (a new one perhaps)
> 
> Ah, I believe I found your test job and it is a Linux-only failure, so that line needs to become
> java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8357360 linux-all

> @prrace I have just tested java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java on linux, macos and windows and it has failed on both linux and Windows. I has passed on macos.
> 
> I think based on this, it will be safe to keep test java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java problem listed for linux and windows, if this is ok.

You've missed part of my point. You cannot use a closed/resolved bug in the problem list, so you must remove 8158801.
At which point what bug will be responsible for the windows problem listing ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3657224066

From duke at openjdk.org  Mon Dec 15 21:10:00 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 15 Dec 2025 21:10:00 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v47]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Removes bug 8158801 from problem list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/b730e9d7..76655589

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=45-46

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

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

From duke at openjdk.org  Mon Dec 15 21:10:03 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 15 Dec 2025 21:10:03 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
 <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>
Message-ID: <Q-QiSVUXPVURYpbBiGbVH-YvL7xCAkihLGWA8OFmziA=.5de3cd0f-c108-405e-89f9-5dd5a356a6b3@github.com>

On Mon, 15 Dec 2025 19:23:24 GMT, Phil Race <prr at openjdk.org> wrote:

>>> @aivanov-jdk I continue to see failures for tests: java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java and java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java. I have resolved conflict by keeping these two tests in problem list.
>>> 
>>> I will fix formatting with a commit.
>> 
>> But that means that although you're resolving this bug it is still used in the problem list
>> 
>> java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8158801,8357360 windows-all,linux-all
>> 
>> That line needs to be updated.
>> 
>> 8357360 is about a linux failure.
>> Where are you seeing it fail still ? If it is only on Linux you can just remove 8158801 from that line (and the windows-all entry)
>> Otherwise you'll need to use a different bug ID for windows (a new one perhaps)
>> 
>> Ah, I believe I found your test job and it is a Linux-only failure, so that line needs to become
>> java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java 8357360 linux-all
>
>> @prrace I have just tested java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java on linux, macos and windows and it has failed on both linux and Windows. I has passed on macos.
>> 
>> I think based on this, it will be safe to keep test java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java problem listed for linux and windows, if this is ok.
> 
> You've missed part of my point. You cannot use a closed/resolved bug in the problem list, so you must remove 8158801.
> At which point what bug will be responsible for the windows problem listing ?

@prrace I understand your point now. Basically, the test java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java used to pass before the final merge (Which included 3 months of commits on master branch), it looks like some change was made and it has stopped test java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java from passing on windows. 

I will remove, bug 8158801 from problem list. 

To cover for failures on Windows, I think we can create an new bug , or we can add Windows platform to existing bug JDK-8357360 (Which is linux only currently). Please advise what would be the best way to sort this out. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3657594760

From aivanov at openjdk.org  Mon Dec 15 21:29:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 15 Dec 2025 21:29:00 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <Q-QiSVUXPVURYpbBiGbVH-YvL7xCAkihLGWA8OFmziA=.5de3cd0f-c108-405e-89f9-5dd5a356a6b3@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
 <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>
 <Q-QiSVUXPVURYpbBiGbVH-YvL7xCAkihLGWA8OFmziA=.5de3cd0f-c108-405e-89f9-5dd5a356a6b3@github.com>
Message-ID: <JYDOeZMEFiUrASC_LRLZP-F1wj37C4_Ky2gZ2T2pisk=.dd34f069-02d7-41b2-bf5c-bb1eb7265968@github.com>

On Mon, 15 Dec 2025 21:03:39 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> To cover for failures on Windows, I think we can create an new bug , or we can add Windows platform to existing bug JDK-8357360 (Which is linux only currently).

If the current failure on Windows is similar to the failures on Linux, add Windows to the existing bug, [JDK-8357360]([JDK-8357360](https://bugs.openjdk.org/browse/JDK-8357360)). If you think it's different enough from the failure on Linux, submit a new bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3657676119

From aivanov at openjdk.org  Mon Dec 15 22:07:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 15 Dec 2025 22:07:31 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v47]
In-Reply-To: <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
Message-ID: <qZwHG0-JenwchdSqk39ptWsYIHpY9BTTa_S-kC6WBXk=.caefa922-842b-42e9-987e-1d4158047412@github.com>

On Mon, 15 Dec 2025 21:10:00 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes bug 8158801 from problem list

I'll wait for the decision which bugid to use in the problem list for `JTableInGlassPaneOverlapping.java`. Otherwise, it looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3580371244

From dnguyen at openjdk.org  Mon Dec 15 22:42:08 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 15 Dec 2025 22:42:08 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests [v3]
In-Reply-To: <i4yarByrvg8beX2ntEQjg0-305SZpySm2hRGI3UKM4I=.36b67fcb-cbe8-4cb5-98d9-a5abb4394e27@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
 <1hU3RRKvpQ8hRogg-wbmGgjL6n1qyj6RwK9VghEjMBQ=.49b69e1d-8845-4e86-92bd-209abb37310e@github.com>
 <iu4xCePytQ5oGpoDQgFzCvVqXdBAbc54tFHtakapa4g=.4ccadcb6-2dbf-40b4-baa7-c4f0279848c2@github.com>
 <XdxNWejtFTQ90z1yyMywnv2NZ5oL77Cbd_-egZkrTLo=.79ce9e2b-2c5a-420e-af58-96857e1fbeb4@github.com>
 <V_kVEHiV116kHNIyBsmxvPYdVdGyMTxxd5uHBBe0kCo=.de17b44d-c807-4784-9c66-047df879d212@github.com>
 <IYFtRfgNWo3i3t_MXfJ2hltYgi4l-sjv9DFm39rJxhM=.444252cb-443f-4ce5-92e8-f5ea5a9d50bc@github.com>
 <xhsR-KfiRPnqSb2pOHbHHBihzeQ6UKZYAabSjFVusWs=.ba59715d-1acc-46dd-90ae-b29a5a210c21@github.com>
 <i4yarByrvg8beX2ntEQjg0-305SZpySm2hRGI3UKM4I=.36b67fcb-cbe8-4cb5-98d9-a5abb4394e27@github.com>
Message-ID: <9GX-Vq6eA3FqohzAnzyZunEakLVwMxLtYOMZ3FzFesg=.2d556fcd-085c-405e-92e0-3ed31054fa90@github.com>

On Mon, 15 Dec 2025 11:51:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> I will take stability at the cost of some extra time.
>
>> Is 33 seconds unreasonable for the test? I figured since the upper-limit of frame tests is set to 30, this 33 seconds would be the longest the test would run for. Also, the test only has 1 gc for other OS's so only 1 frame is tested for that. 
> 
> In CI it may be even slower, and we can achieve the same results in a third of the time with showing several windows at once. This can cumulatively save a lot of CI time over many runs. We can still apply the same upper limit to the frame count of frame tests, and this may make it even faster.
> 
>> This avoids the shadow issue as well as creates a more stable test.
> 
> This can be mitigated simply by adding spacing between the frames.

I suppose if this is problematic, I can change it back. But right now it looks OK and the code implementation is cleaner and easier to read this way. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28646#discussion_r2621087877

From dnguyen at openjdk.org  Mon Dec 15 22:42:10 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 15 Dec 2025 22:42:10 GMT
Subject: Integrated: 8360160: ubuntu-22-04 machine is failing client tests
In-Reply-To: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
References: <dc-y3QMCU2lb8zVLuB_8zun6b0Vkvgzr-1y7qm_fRLk=.e58e5a59-3b1e-4e0c-83e9-5e473daffdee@github.com>
Message-ID: <p1rpP8IBsmwwuiMoC3zS1zKUwuA_FSDRaD_gA7xL6sk=.0fbe0d05-ed84-497e-8434-90264939fd25@github.com>

On Wed, 3 Dec 2025 20:25:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> There was a prior PR that attempted to fix this issue, but it was found that [JDK-8280987](https://bugs.openjdk.org/browse/JDK-8280987) was the more reasonable cause. The issue was caused by Ubuntu instances having a large amount of graphics configurations, hence a large amount of concurrent frames being open and tested on at a time. As such, the newly suggested fix was to instead break apart the test into batches.
> 
> This change creates and disposes of the test frames in batches of 20, up to the number of GC's identified. The original problem was recreated when testing on Ubuntu 24.04, and I have re-tested this with the updated test on the same device, and it passes. When debugging, 140 GC's were identified and all 140 frames were created and disposed of. Also tested this on macOS 15 and the test also passes. CI looks good as well.

This pull request has now been integrated.

Changeset: 317788ff
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/317788ff12ee231bd3c9e8f1a0c9b38c8dad3feb
Stats:     57 lines in 1 file changed: 25 ins; 16 del; 16 mod

8360160: ubuntu-22-04 machine is failing client tests

Reviewed-by: prr, azvegint

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

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

From serb at openjdk.org  Tue Dec 16 01:00:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 16 Dec 2025 01:00:00 GMT
Subject: RFR: 6441373: Editing JTable is not Serializable [v6]
In-Reply-To: <Om-kpL-UGYx7cqAOwKhKR9YodUgRRUz3R2Vvcc6uBlQ=.7c2704ec-83e1-4634-809a-1a46c7809c27@github.com>
References: <sKcw_G51_dVD8zUbg2bw0KTqurXe0sDVuBaIA14F4X8=.df382cd6-b0f4-4497-88b8-3c7f22d8ba5f@github.com>
 <_9Q5OkPMg1rZw43ZdtNoA8PXacFcJ4ZuK-9qG5Bv4Y0=.26e7ce1a-499e-4806-9288-6184cf9a3e5e@github.com>
 <Om-kpL-UGYx7cqAOwKhKR9YodUgRRUz3R2Vvcc6uBlQ=.7c2704ec-83e1-4634-809a-1a46c7809c27@github.com>
Message-ID: <VYJhmShBcX-qBLNnrx6irfbPuxWchCcKNt8r-hfQ4MI=.edf20bcc-6360-4c75-bd34-4debee2bf225@github.com>

On Mon, 15 Dec 2025 14:06:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Leakage observation was red herring. It seems the JTable instance we are inspecting after the read operation is potentially being observed in a test context where the Swing EDT hasn't fully processed all cleanup events yet so when the test is fixed to use EDT properly, it doesn't show the leak and shows componentCount as 2.

I doubt that there is any cleanup logic in JTable. At first glance, your test is different: it creates a new JTable on each iteration and then serializes it. In my test, I always serialize the object that was previously deserialized, which is why getComponentCount() shows the accumulated count.

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

PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3658235132

From fferrari at openjdk.org  Tue Dec 16 03:55:05 2025
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 16 Dec 2025 03:55:05 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image [v2]
In-Reply-To: <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
 <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
Message-ID: <ZNzseKdS8V0U8T4bLyPB7f0fxu8UjgNIdKFkxUgVSlI=.9a24f5c8-48c9-459d-978a-55ce996d1296@github.com>

On Fri, 25 Jul 2025 23:58:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> XBM (X Bitmap) images are small one-bit deep images that were developed as a simple uncompressed format that could easily be included in C source files as include files.
>> 
>> Format of XBM image:
>> 
>> 
>>  #define width w
>>  #define height h
>>  static char foo_bits[] = {
>>  0xnn,0xnn,0xnn,0xnn,0xnn, .......
>>  0xnn,0xnn,0xnn,0xnn, .........
>>  0xnn,0xnn,0xnn,0xnn};
>> 
>> 
>> The first two #defines statements specify the width and height of the bitmap in pixels followed by hex byte array which represent pixel data itself.
>> 
>> The current implementation allows an arbitrarily large XBM which is not a valid use case for any XBM.
>> Also it doesn't validate that the provided byte array is sufficient to populate the specified WxH. Since these are small one-bit mono images a reasonable size limit is set to `MAX_XBM_SIZE = 16384 bytes`. It can be set to a larger limit if someone thinks it is necessary.
>> 
>> The XBMDecoder's produceImage() has outdated logic, it has been restructured by adding more efficient parser logic and better error handling checks.
>
> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename
>  - test summary

@honkar-jdk: just wanted to let you now about [JDK-8373727: New XBM images parser regression: only the first line of the bitmap array is parsed](https://bugs.openjdk.org/browse/JDK-8373727).

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

PR Comment: https://git.openjdk.org/jdk/pull/26488#issuecomment-3658609937

From duke at openjdk.org  Tue Dec 16 07:30:03 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 16 Dec 2025 07:30:03 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <JYDOeZMEFiUrASC_LRLZP-F1wj37C4_Ky2gZ2T2pisk=.dd34f069-02d7-41b2-bf5c-bb1eb7265968@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
 <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>
 <Q-QiSVUXPVURYpbBiGbVH-YvL7xCAkihLGWA8OFmziA=.5de3cd0f-c108-405e-89f9-5dd5a356a6b3@github.com>
 <JYDOeZMEFiUrASC_LRLZP-F1wj37C4_Ky2gZ2T2pisk=.dd34f069-02d7-41b2-bf5c-bb1eb7265968@github.com>
Message-ID: <Q-lVigfUpr_yoYXqobOBICW1TVy_I2E8xAE-flMmwoE=.112bba37-3427-4da0-867b-f73457c00bfd@github.com>

On Mon, 15 Dec 2025 21:25:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @prrace I understand your point now. Basically, the test java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java used to pass before the final merge (Which included 3 months of commits on master branch), it looks like some change was made and it has stopped test java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java from passing on windows. 
>> 
>> I will remove, bug 8158801 from problem list. 
>> 
>> To cover for failures on Windows, I think we can create an new bug , or we can add Windows platform to existing bug JDK-8357360 (Which is linux only currently). Please advise what would be the best way to sort this out. Thanks
>
>> To cover for failures on Windows, I think we can create an new bug , or we can add Windows platform to existing bug JDK-8357360 (Which is linux only currently).
> 
> If the current failure on Windows is similar to the failures on Linux, add Windows to the existing bug, [JDK-8357360]([JDK-8357360](https://bugs.openjdk.org/browse/JDK-8357360)). If you think it's different enough from the failure on Linux, submit a new bug.

@aivanov-jdk both tests fails with this exception: java.lang.RuntimeException: The LW component did not pass pixel color check and is overlapped. I will add Windows platform to bug JDK-8357360

@aivanov-jdk Bug JDK-8357360 updated with Windows platform.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3659179469
PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3659185813

From jlahoda at openjdk.org  Tue Dec 16 09:41:02 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 16 Dec 2025 09:41:02 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <mND81SeJD0rx1JpIkRlAF0AWM_18A9zWocHp1m2p8mM=.ae703d0b-c4f0-4031-85e6-dc3a1b6fac5b@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

Marked as reviewed by jlahoda (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28780#pullrequestreview-3582185635

From jpai at openjdk.org  Tue Dec 16 10:11:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Dec 2025 10:11:29 GMT
Subject: RFR: 8373561: Replace usages of -verify java launcher option with
 -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <xc3LJt283Sa0HMtRthM4cSKCktbRyYWnyAvlEd1DNsg=.8b558b26-0de6-4489-b5a3-c187d953aa21@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

Thank you Jan for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28780#issuecomment-3659757169

From jpai at openjdk.org  Tue Dec 16 10:11:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Dec 2025 10:11:30 GMT
Subject: Integrated: 8373561: Replace usages of -verify java launcher option
 with -Xverify:all JVM option
In-Reply-To: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
References: <TBDrz_wg4VXyU1Xww9u1e0hxSf6g1-4M-GFBK_Pf4eI=.a03fdd5a-29e4-4194-b693-aac613bb5e82@github.com>
Message-ID: <jGggtvRUtQFu_SsFsj1KrTiBzwk7eeO8YrCy2sfcrbA=.64d97293-06fb-4fc0-acaa-6b1da979e225@github.com>

On Fri, 12 Dec 2025 05:22:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which replaces the usages of the deprecated "-verify" java launcher option with "-Xverify:all"?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8373561, the `-verify` `java` launcher option was deprecated for removal in Java 24 and will be removed in some upcoming release. The commit in this PR replaces its usage in tests with the `-Xverify:all` JVM option.
> 
> tier1, tier2 and tier3 testing with these changes passed without any related issues. The `test/jdk/javax/swing/JFileChooser/6520101/bug6520101.java` test, that's updated in this PR, was individually run in our CI and that too passed on all headful platforms.

This pull request has now been integrated.

Changeset: 41d28c18
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41d28c1838bcd7a69f78c9799b449af2a33c11c3
Stats:     10 lines in 5 files changed: 0 ins; 0 del; 10 mod

8373561: Replace usages of -verify java launcher option with -Xverify:all JVM option

Reviewed-by: serb, prr, dholmes, jlahoda

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

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

From prr at openjdk.org  Tue Dec 16 17:28:53 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 16 Dec 2025 17:28:53 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v47]
In-Reply-To: <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
Message-ID: <2Ush0FAvU_uS4-Tr-Z4NWiJiHfIFY21Wm8pfv_QVIS4=.5de58714-0dde-4c6d-ace2-e61d04bf58a2@github.com>

On Mon, 15 Dec 2025 21:10:00 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes bug 8158801 from problem list

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3584194655

From aivanov at openjdk.org  Tue Dec 16 17:41:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 16 Dec 2025 17:41:35 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v47]
In-Reply-To: <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
Message-ID: <y8CmmhqaDrteVgPQIYsXDraTpEWlhL1q4wXrimV_2l4=.82e4949a-8dd0-4728-9237-530d519518e5@github.com>

On Mon, 15 Dec 2025 21:10:00 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes bug 8158801 from problem list

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3584244018

From aivanov at openjdk.org  Tue Dec 16 17:55:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 16 Dec 2025 17:55:47 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <Q-lVigfUpr_yoYXqobOBICW1TVy_I2E8xAE-flMmwoE=.112bba37-3427-4da0-867b-f73457c00bfd@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
 <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>
 <Q-QiSVUXPVURYpbBiGbVH-YvL7xCAkihLGWA8OFmziA=.5de3cd0f-c108-405e-89f9-5dd5a356a6b3@github.com>
 <JYDOeZMEFiUrASC_LRLZP-F1wj37C4_Ky2gZ2T2pisk=.dd34f069-02d7-41b2-bf5c-bb1eb7265968@github.com>
 <Q-lVigfUpr_yoYXqobOBICW1TVy_I2E8xAE-flMmwoE=.112bba37-3427-4da0-867b-f73457c00bfd@github.com>
Message-ID: <QB24Ui9zUBmx6dhRg2MFqRn7Q6-Jey0iNhnhnytmEFU=.fa58779a-496e-4340-8b30-9b3cdab2e717@github.com>

On Tue, 16 Dec 2025 07:27:10 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>>> To cover for failures on Windows, I think we can create an new bug , or we can add Windows platform to existing bug JDK-8357360 (Which is linux only currently).
>> 
>> If the current failure on Windows is similar to the failures on Linux, add Windows to the existing bug, [JDK-8357360]([JDK-8357360](https://bugs.openjdk.org/browse/JDK-8357360)). If you think it's different enough from the failure on Linux, submit a new bug.
>
> @aivanov-jdk Bug JDK-8357360 updated with Windows platform.

@kboulanou I added the test log of the failure on Windows from your jobs. The failure on Windows seems to be different: it fails on the first component, **Testing Button**.
On Linux, the test fails at **Testing EmbeddedFrame** after a long run of passing components.

It seems to me, these two failures of `java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java` are *different*.

When I run `JTableInGlassPaneOverlapping.java` locally, it passes for me on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3661731205

From duke at openjdk.org  Tue Dec 16 18:49:24 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 18:49:24 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v47]
In-Reply-To: <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <X3f1I5jLqQu2idh24e5lrSunKMEz9zG8L9A5y_JKYGU=.3495d251-0eb0-4f93-adea-7bde3048285c@github.com>
Message-ID: <oK4hX6Jp8IBLwbOdp3UobbwrblQb_6eVOnJB6lAHFd8=.39af0b96-b878-4ced-aeca-4e2538908dd5@github.com>

On Mon, 15 Dec 2025 21:10:00 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes bug 8158801 from problem list

@kboulanou 
Your change (at version 7665558981d87a1d55f6cd99345d7ad18d8553c1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3661916606

From duke at openjdk.org  Tue Dec 16 18:49:25 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 16 Dec 2025 18:49:25 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <QB24Ui9zUBmx6dhRg2MFqRn7Q6-Jey0iNhnhnytmEFU=.fa58779a-496e-4340-8b30-9b3cdab2e717@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
 <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>
 <Q-QiSVUXPVURYpbBiGbVH-YvL7xCAkihLGWA8OFmziA=.5de3cd0f-c108-405e-89f9-5dd5a356a6b3@github.com>
 <JYDOeZMEFiUrASC_LRLZP-F1wj37C4_Ky2gZ2T2pisk=.dd34f069-02d7-41b2-bf5c-bb1eb7265968@github.com>
 <Q-lVigfUpr_yoYXqobOBICW1TVy_I2E8xAE-flMmwoE=.112bba37-3427-4da0-867b-f73457c00bfd@github.com>
 <QB24Ui9zUBmx6dhRg2MFqRn7Q6-Jey0iNhnhnytmEFU=.fa58779a-496e-4340-8b30-9b3cdab2e717@github.com>
Message-ID: <2fNzMN3hXx_297ogyv9Zx99_2UTS-muUFA4wQdksTt8=.880da699-5fb1-424d-8579-1f583b02a570@github.com>

On Tue, 16 Dec 2025 17:52:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk Bug JDK-8357360 updated with Windows platform.
>
> @kboulanou I added the test log of the failure on Windows from your jobs. The failure on Windows seems to be different: it fails on the first component, **Testing Button**.
> On Linux, the test fails at **Testing EmbeddedFrame** after a long run of passing components.
> 
> It seems to me, these two failures of `java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java` are *different*.
> 
> When I run `JTableInGlassPaneOverlapping.java` locally, it passes for me on Windows.

@aivanov-jdk Should I create a different bug for Windows ? I will spend some time on this issue and get back to you. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3661920220

From aivanov at openjdk.org  Tue Dec 16 20:41:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 16 Dec 2025 20:41:32 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v44]
In-Reply-To: <QB24Ui9zUBmx6dhRg2MFqRn7Q6-Jey0iNhnhnytmEFU=.fa58779a-496e-4340-8b30-9b3cdab2e717@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <vWgVWU4dxHdGt5pAHsJON54rJOB5nEKs85vyNzKJLT8=.843426ef-703d-453f-b42c-87e6873589e6@github.com>
 <1KeIIy1UXPlfhAcc8vb_zjqOlOvY1RclykZG5zPTHHg=.a095e166-d946-48bf-89bb-c53dfedf51fa@github.com>
 <Ev27ZS4bMpLvgAHc3mQpt-CH2R9O749sX1DLLl1RHME=.b8bafcf4-0a6b-4787-87e1-dc417f08a9a7@github.com>
 <4Gmys4sQHMaUrxC-YmvK9TLCRzTU4Si7oDlG2ySnMJY=.d6e55ba6-7f69-4661-8481-b3592bfd4c0f@github.com>
 <Q-QiSVUXPVURYpbBiGbVH-YvL7xCAkihLGWA8OFmziA=.5de3cd0f-c108-405e-89f9-5dd5a356a6b3@github.com>
 <JYDOeZMEFiUrASC_LRLZP-F1wj37C4_Ky2gZ2T2pisk=.dd34f069-02d7-41b2-bf5c-bb1eb7265968@github.com>
 <Q-lVigfUpr_yoYXqobOBICW1TVy_I2E8xAE-flMmwoE=.112bba37-3427-4da0-867b-f73457c00bfd@github.com>
 <QB24Ui9zUBmx6dhRg2MFqRn7Q6-Jey0iNhnhnytmEFU=.fa58779a-496e-4340-8b30-9b3cdab2e717@github.com>
Message-ID: <OQH-ilWrB3rOjcZw9685TGKyCRYhw_RnJGbs3trkbtE=.a35fc9d6-e594-4c8e-8753-8e2bf1d46841@github.com>

On Tue, 16 Dec 2025 17:52:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk Bug JDK-8357360 updated with Windows platform.
>
> @kboulanou I added the test log of the failure on Windows from your jobs. The failure on Windows seems to be different: it fails on the first component, **Testing Button**.
> On Linux, the test fails at **Testing EmbeddedFrame** after a long run of passing components.
> 
> It seems to me, these two failures of `java/awt/Mixing/AWT_Mixing/JTableInGlassPaneOverlapping.java` are *different*.
> 
> When I run `JTableInGlassPaneOverlapping.java` locally, it passes for me on Windows.

> @aivanov-jdk Should I create a different bug for Windows ? I will spend some time on this issue and get back to you. Thanks

I haven't looked deeply into it, but since the test log is significantly different the root cause for failures on Windows and Linux could be different. If you're able to figure it out right now, I suggest submitting a new bug (if it's the case, that new bugid needs to be added to the problem list); otherwise, defer it till someone works [JDK-8357360](https://bugs.openjdk.org/browse/JDK-8357360).

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3662285701

From duke at openjdk.org  Tue Dec 16 20:41:34 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 16 Dec 2025 20:41:34 GMT
Subject: Integrated: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <_aC2U83LVUXqYozxVt5L-X4MgsuC0BPtdeirMxGTz_A=.9585afdc-812e-4c7f-80e8-19d62ef56aa6@github.com>

On Wed, 25 Jun 2025 08:12:25 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

This pull request has now been integrated.

Changeset: d02abfe7
Author:    Khalid Boulanouare <khalid.boulanouare at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d02abfe765a1e67c5e37f3450aa5a0d8fb97a208
Stats:     204 lines in 14 files changed: 96 ins; 71 del; 37 mod

8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick

Reviewed-by: aivanov, prr, psadhukhan

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

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

From dgredler at openjdk.org  Tue Dec 16 23:19:24 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 16 Dec 2025 23:19:24 GMT
Subject: RFR: 6517125: FontStrike.getGlyphVectorOutline() not used
Message-ID: <OQ__uIyLLfCzjjgIoayCD6c0gEJ9GKRcHWaDQ0ajSCo=.28b46bea-49f8-4e92-9e0c-7099000af5d9@github.com>

This method is not used and can be deleted from the entire `FontStrike` class hierarchy. There was some discussion in 2007 about re-enabling if there were performance benefits, but 20 years have passed and no performance issues have emerged. In fact, the macOS OpenJDK never implemented this method.

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

Commit messages:
 - Delete FontStrike.getGlyphVectorOutline(...)

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

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

From duke at openjdk.org  Wed Dec 17 09:58:41 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 17 Dec 2025 09:58:41 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v19]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <b6bXrb76c3ypuK_qiOSNS2InAajA_69zglBsDcTLHUg=.c4e14327-be0a-4c89-be99-f5cf02c92f79@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 104 commits:

 - Merge with master
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Removes uncessary import and adds blank lines between import blocks
 - Makes inherited method final
 - Removes unnecessary URL
 - Fixes a typo
 - Removes unncessary boolean variable, line and import
 - Merge branch 'openjdk:master' into jdk-8158801
 - ... and 94 more: https://git.openjdk.org/jdk/compare/fc76403b...5baf47b2

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

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=18
  Stats: 146 lines in 9 files changed: 129 ins; 3 del; 14 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 Dec 17 10:56:23 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 17 Dec 2025 10:56:23 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v20]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <ao-B6Iw7YEHu8en61oqXqxlG7QQWz02wxJuQQQ8SqSc=.ee552bfa-fa15-43b7-b589-4264775dd732@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 minor conflict origin compilation issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/5baf47b2..f83159ac

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

  Stats: 5 lines in 2 files changed: 2 ins; 2 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 psadhukhan at openjdk.org  Thu Dec 18 03:09:32 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 18 Dec 2025 03:09:32 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses background
 painting with border painting
Message-ID: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>

[JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue

The JDK-8224261 is hereby backed out

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

Commit messages:
 - jcheck
 - 8373946: Synth ProgressBarUI implementation confuses background painting with border painting

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

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

From psadhukhan at openjdk.org  Thu Dec 18 03:42:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 18 Dec 2025 03:42:06 GMT
Subject: RFR: 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java
 failed because The test case automatically fails when clicking any
 items in the =?UTF-8?B?4oCcTm90aGluZ+KAnQ==?= menu in all four windows
 (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
Message-ID: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com>

When user selects any menu item from "No nothing". the following exception happens because PassFailJFrame logArea is not created

java.lang.NullPointerException: Cannot invoke "javax.swing.JTextArea.append(String)" because "PassFailJFrame.logArea" is null
at PassFailJFrame.lambda$log$0(PassFailJFrame.java:1353)
at PassFailJFrame.invokeOnEDT(PassFailJFrame.java:570)
at PassFailJFrame.invokeOnEDTUncheckedException(PassFailJFrame.java:584)
at PassFailJFrame.log(PassFailJFrame.java:1353)
at MenuItemTestHelper.lambda$createNoNothingMenu$0(MenuItemTestHelper.java:118) 


Fix is to create log area

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

Commit messages:
 - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test

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

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

From psadhukhan at openjdk.org  Thu Dec 18 07:50:29 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 18 Dec 2025 07:50:29 GMT
Subject: RFR: 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java
 fails because the check icons are not aligned properly as expected
Message-ID: <GpSv6WiinB_ZK1A4HFSP_fpcdDjGn8KHr_JQyenQhbM=.400739ab-9e6b-4a2c-945d-76440dd04831@github.com>

Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon

Before fix

<img width="425" height="646" alt="image" src="https://github.com/user-attachments/assets/6aac649d-b099-4e11-ba9a-83c623034287" />

After fix

<img width="430" height="641" alt="image" src="https://github.com/user-attachments/assets/e0ea7e3e-d6cb-44a6-aa4f-78435f85d6fb" />

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

Commit messages:
 - 8373650: Test javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check icons are not aligned properly as expected

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

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

From jwaters at openjdk.org  Thu Dec 18 10:09:46 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Dec 2025 10:09:46 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v6]
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <9d-P0_nfPLTsL56a1PsIzJc4vOSOh92FLzwFVYlgsFw=.739db1c3-f580-4698-ab27-06a036ab77df@github.com>

> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
> 
> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
> - -flto is set to $(JOBS) instead of auto to better match what the user requested
> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least

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

  Revert LINK_TIME_OPTIMIZATION in ClientLibraries.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22464/files
  - new: https://git.openjdk.org/jdk/pull/22464/files/fbe79af6..3e6c0650

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

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

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

From vdyakov at openjdk.org  Thu Dec 18 16:29:29 2025
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Thu, 18 Dec 2025 16:29:29 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting
In-Reply-To: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
Message-ID: <k3C6qN_4iUdQuuS4pKIU-bcjgB3aXcr_-KzpFcYCCtY=.652d298b-4cd6-40ec-bc46-d7444479cffc@github.com>

On Thu, 18 Dec 2025 02:57:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
> 
> The JDK-8224261 is hereby backed out

@azuev @prrace  please review for @prsadhuk

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

PR Comment: https://git.openjdk.org/jdk/pull/28885#issuecomment-3671096172

From mbaesken at openjdk.org  Thu Dec 18 16:43:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 18 Dec 2025 16:43:41 GMT
Subject: RFR: 8373984: Check for macos 11 in CGraphicsDevice.m can be removed
Message-ID: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>

After we switched to minimum version macOS 11 with [JDK-8317970](https://bugs.openjdk.org/browse/JDK-8317970) a while ago, the check in java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m can be removed.

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

Commit messages:
 - JDK-8373984

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

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

From prr at openjdk.org  Thu Dec 18 19:25:12 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 18 Dec 2025 19:25:12 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting
In-Reply-To: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
Message-ID: <PR9JYLX02CS6mpYPn8fqYnn3qTmyUo0mKGqx_JhXqW8=.37b7fc67-37e0-42ee-9c9b-73e39df9df10@github.com>

On Thu, 18 Dec 2025 02:57:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
> 
> The JDK-8224261 is hereby backed out

test/jdk/javax/swing/plaf/synth/TestSynthProgressBarBorder.java line 45:

> 43: import javax.swing.UIManager;
> 44: 
> 45: public class TestSynthProgressBarBorder {

I would rename this to be specifically about Nimbus.
GTK L&F is a synth L&F and its rendering is controlled by how GTK renders, so it may display a background the same as the parent container.

test/jdk/javax/swing/plaf/synth/TestSynthProgressBarBorder.java line 54:

> 52:         Please check if 50% progress is rendered in the progress bar
> 53:         and rest 50% is rendered as blank bar
> 54:         with Nimbus default background color.

Hmm.
First I think Nimbus uses gradients, not solid colors.
2nd you are basically asking the tester to verify something they don't know. I read this and wonder "what is that default background, how do I know if it is right" ? 
Since the bug *specific to Nimbus* is that YOU know Nimbus paints a visually distinctive background is just to ask the tester to verify that.

Although I believe this could actually be automated. You just need to verify that if you set the value to 0, then it passes if any pixel in the progress bar is different than the pixels of the parent container - which you can make a solid color I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28885#discussion_r2632355779
PR Review Comment: https://git.openjdk.org/jdk/pull/28885#discussion_r2632365681

From prr at openjdk.org  Thu Dec 18 19:32:25 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 18 Dec 2025 19:32:25 GMT
Subject: RFR: 8373984: Check for macos 11 in CGraphicsDevice.m can be
 removed
In-Reply-To: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
References: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
Message-ID: <M4AuW572l2aK3Ge75VLN54KtzwkFN7tNAM4uE4mqU1s=.a315da7c-9980-44ab-8f1a-c6da0d7d812b@github.com>

On Thu, 18 Dec 2025 16:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After we switched to minimum version macOS 11 with [JDK-8317970](https://bugs.openjdk.org/browse/JDK-8317970) a while ago, the check in java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m can be removed.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28901#pullrequestreview-3594715575

From kizune at openjdk.org  Thu Dec 18 20:15:17 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 18 Dec 2025 20:15:17 GMT
Subject: RFR: 8373984: Check for macos 11 in CGraphicsDevice.m can be
 removed
In-Reply-To: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
References: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
Message-ID: <HqEM9v-rF7fTX0hegiY7hENwJAhvFODbTJ1Z0m1rqno=.0a60ca01-1418-42f5-96cd-a61e163822c9@github.com>

On Thu, 18 Dec 2025 16:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After we switched to minimum version macOS 11 with [JDK-8317970](https://bugs.openjdk.org/browse/JDK-8317970) a while ago, the check in java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m can be removed.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28901#pullrequestreview-3594868517

From serb at openjdk.org  Thu Dec 18 21:00:16 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 18 Dec 2025 21:00:16 GMT
Subject: RFR: 8373847: Test
 javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test
 case automatically fails when clicking any items in the
 =?UTF-8?B?4oCcTm90aGluZ+KAnQ==?= menu in all four windows (Left-to-right)-Menu
 Item Test and (Right-to-left)-Menu Item Test
In-Reply-To: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com>
References: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com>
Message-ID: <vIOA2oGJ1-MlhxtR9u9oKJzcWQxTLlfOThhDmcYWdj4=.7ce4325a-3cde-479c-b215-5640f3e29291@github.com>

On Thu, 18 Dec 2025 03:32:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When user selects any menu item from "No nothing". the following exception happens because PassFailJFrame logArea is not created
> 
> java.lang.NullPointerException: Cannot invoke "javax.swing.JTextArea.append(String)" because "PassFailJFrame.logArea" is null
> at PassFailJFrame.lambda$log$0(PassFailJFrame.java:1353)
> at PassFailJFrame.invokeOnEDT(PassFailJFrame.java:570)
> at PassFailJFrame.invokeOnEDTUncheckedException(PassFailJFrame.java:584)
> at PassFailJFrame.log(PassFailJFrame.java:1353)
> at MenuItemTestHelper.lambda$createNoNothingMenu$0(MenuItemTestHelper.java:118) 
> 
> 
> Fix is to create log area

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28887#pullrequestreview-3595012645

From psadhukhan at openjdk.org  Fri Dec 19 01:36:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 19 Dec 2025 01:36:41 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting [v2]
In-Reply-To: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
Message-ID: <l_dHGGhNYAmvcXMm1A6YTMqWHtKZOk2wnrUyezSl0zU=.a1563195-ef12-4431-bf40-a401dc5c83ce@github.com>

> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
> 
> The JDK-8224261 is hereby backed out

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

  Test rename fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28885/files
  - new: https://git.openjdk.org/jdk/pull/28885/files/96fb13ad..a85d579d

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

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

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

From psadhukhan at openjdk.org  Fri Dec 19 01:36:44 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 19 Dec 2025 01:36:44 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting [v2]
In-Reply-To: <PR9JYLX02CS6mpYPn8fqYnn3qTmyUo0mKGqx_JhXqW8=.37b7fc67-37e0-42ee-9c9b-73e39df9df10@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
 <PR9JYLX02CS6mpYPn8fqYnn3qTmyUo0mKGqx_JhXqW8=.37b7fc67-37e0-42ee-9c9b-73e39df9df10@github.com>
Message-ID: <2b7ns8YMd1s8RvB1iH24Umnm4i6kAUTYQ9b5utz93vg=.4bfa2b45-e617-4289-b935-24d4be3770cb@github.com>

On Thu, 18 Dec 2025 19:19:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test rename fix
>
> test/jdk/javax/swing/plaf/synth/TestSynthProgressBarBorder.java line 45:
> 
>> 43: import javax.swing.UIManager;
>> 44: 
>> 45: public class TestSynthProgressBarBorder {
> 
> I would rename this to be specifically about Nimbus.
> GTK L&F is a synth L&F and its rendering is controlled by how GTK renders, so it may display a background the same as the parent container.

ok updated..

> test/jdk/javax/swing/plaf/synth/TestSynthProgressBarBorder.java line 54:
> 
>> 52:         Please check if 50% progress is rendered in the progress bar
>> 53:         and rest 50% is rendered as blank bar
>> 54:         with Nimbus default background color.
> 
> Hmm.
> First I think Nimbus uses gradients, not solid colors.
> 2nd you are basically asking the tester to verify something they don't know. I read this and wonder "what is that default background, how do I know if it is right" ? 
> Since the bug *specific to Nimbus* is that YOU know Nimbus paints a visually distinctive background is just to ask the tester to verify that.
> 
> Although I believe this could actually be automated. You just need to verify that if you set the value to 0, then it passes if any pixel in the progress bar is different than the pixels of the parent container - which you can make a solid color I think.

There are basically 2 checks that we are doing. One is at 50% time to check if no background is done and another at 0%..
It could be automated but since we need to push it soon I made it manual.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28885#discussion_r2633246052
PR Review Comment: https://git.openjdk.org/jdk/pull/28885#discussion_r2633250902

From psadhukhan at openjdk.org  Fri Dec 19 04:51:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 19 Dec 2025 04:51:41 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting [v3]
In-Reply-To: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
Message-ID: <APPQJ3dinbOBMAZimIhsbOAiZdxzdyINN9AAhWVn174=.7949085f-a37e-41e6-8b5d-b4acf7afc73b@github.com>

> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
> 
> The JDK-8224261 is hereby backed out

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

  AUtomate test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28885/files
  - new: https://git.openjdk.org/jdk/pull/28885/files/a85d579d..6d742afb

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

  Stats: 91 lines in 1 file changed: 37 ins; 19 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/28885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28885/head:pull/28885

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

From mbaesken at openjdk.org  Fri Dec 19 14:37:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Dec 2025 14:37:58 GMT
Subject: RFR: 8373984: Check for macos 11 in CGraphicsDevice.m can be
 removed
In-Reply-To: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
References: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
Message-ID: <AIMJc5mN3M1Zy_JWhOBtRSgweJ3aUmTygfmqKOwZmS4=.310d2260-fe29-4ce4-bae1-fd34832f3a8c@github.com>

On Thu, 18 Dec 2025 16:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After we switched to minimum version macOS 11 with [JDK-8317970](https://bugs.openjdk.org/browse/JDK-8317970) a while ago, the check in java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m can be removed.

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/28901#issuecomment-3675302549

From mbaesken at openjdk.org  Fri Dec 19 14:41:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 Dec 2025 14:41:18 GMT
Subject: Integrated: 8373984: Check for macos 11 in CGraphicsDevice.m can be
 removed
In-Reply-To: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
References: <8V0kN8ua_-NEwxumIk3tj6kA8Dk8KmyZasG2x221Uao=.bec09234-25d6-44a0-ab28-a31f9373f85d@github.com>
Message-ID: <d3do5IT1FH1jd0Q360e5XpSZHeVvoGWlIwmUHu1mMFI=.567d0d0f-c62c-4c21-a78b-59c0a983e713@github.com>

On Thu, 18 Dec 2025 16:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After we switched to minimum version macOS 11 with [JDK-8317970](https://bugs.openjdk.org/browse/JDK-8317970) a while ago, the check in java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m can be removed.

This pull request has now been integrated.

Changeset: 6c9999ca
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c9999ca8d0722bfb3a945dd4bea666eb4a028cc
Stats:     13 lines in 1 file changed: 4 ins; 6 del; 3 mod

8373984: Check for macos 11 in CGraphicsDevice.m can be removed

Reviewed-by: prr, kizune

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

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

From prr at openjdk.org  Fri Dec 19 17:57:19 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Dec 2025 17:57:19 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting [v3]
In-Reply-To: <APPQJ3dinbOBMAZimIhsbOAiZdxzdyINN9AAhWVn174=.7949085f-a37e-41e6-8b5d-b4acf7afc73b@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
 <APPQJ3dinbOBMAZimIhsbOAiZdxzdyINN9AAhWVn174=.7949085f-a37e-41e6-8b5d-b4acf7afc73b@github.com>
Message-ID: <QbE18cJv1WYblac7LGY1N8QQ6yXbpe8vAltNLUO8Zuc=.8ffd2082-b6d5-4e34-b138-264ea6e94a34@github.com>

On Fri, 19 Dec 2025 04:51:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
>> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
>> 
>> The JDK-8224261 is hereby backed out
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AUtomate test

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28885#pullrequestreview-3599520445

From prr at openjdk.org  Fri Dec 19 18:42:49 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Dec 2025 18:42:49 GMT
Subject: RFR: 6517125: FontStrike.getGlyphVectorOutline() not used
In-Reply-To: <OQ__uIyLLfCzjjgIoayCD6c0gEJ9GKRcHWaDQ0ajSCo=.28b46bea-49f8-4e92-9e0c-7099000af5d9@github.com>
References: <OQ__uIyLLfCzjjgIoayCD6c0gEJ9GKRcHWaDQ0ajSCo=.28b46bea-49f8-4e92-9e0c-7099000af5d9@github.com>
Message-ID: <uwgJ14I5jfjhJ0yRlFOrH3sRAfdZLEbmNo_gGQ2vAKo=.e006030f-8065-4c6b-89b4-4b8e72079c8e@github.com>

On Tue, 16 Dec 2025 23:11:19 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> This method is not used and can be deleted from the entire `FontStrike` class hierarchy. There was some discussion in 2007 about re-enabling if there were performance benefits, but 20 years have passed and no performance issues have emerged. In fact, the macOS OpenJDK never implemented this method.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28856#pullrequestreview-3599634285

From kizune at openjdk.org  Fri Dec 19 20:07:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 19 Dec 2025 20:07:56 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting [v3]
In-Reply-To: <APPQJ3dinbOBMAZimIhsbOAiZdxzdyINN9AAhWVn174=.7949085f-a37e-41e6-8b5d-b4acf7afc73b@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
 <APPQJ3dinbOBMAZimIhsbOAiZdxzdyINN9AAhWVn174=.7949085f-a37e-41e6-8b5d-b4acf7afc73b@github.com>
Message-ID: <4k5jg8ZMfhH08D-_unrTzev9GKuZfDG7RYrvLlyDdCE=.6539b682-0b91-4efb-9066-07db7ce5c811@github.com>

On Fri, 19 Dec 2025 04:51:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
>> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
>> 
>> The JDK-8224261 is hereby backed out
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AUtomate test

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28885#pullrequestreview-3599914288

From serb at openjdk.org  Fri Dec 19 20:24:10 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 19 Dec 2025 20:24:10 GMT
Subject: RFR: 8373967: [macos] User interactions with List do not trigger
 ItemEvent after programmatic change
Message-ID: <XH1WLODEyM40iYMQlMEkYaCj1qpvKf1EPXla_B-XOVM=.2c49126b-fc34-47e3-8328-a398eb84835b@github.com>

The fix in LWListPeer introduced by [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456) was intended to suppress ItemEvents for programmatic changes to a List, while still allowing events generated by user interaction.

The implementation unconditionally bypasses the listener logic:
https://hg.openjdk.org/jdk7u/jdk7u-osx/jdk/rev/dfa991721457
Unfortunately that logic also updates the cached selection state. As a result, when the application select something programmatically, the cached state is not updated.

The change move out the `oldSelectedIndices = source.getSelectedIndices();` from the `!isSkipStateChangedEvent()` condition, plus some cleanup.

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

Commit messages:
 - 8373967: [macos] User interactions with List do not trigger ItemEvent after programmatic change

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

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

From prr at openjdk.org  Fri Dec 19 22:08:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Dec 2025 22:08:54 GMT
Subject: RFR: 6562639: Wrong pixel bounds from TextLayout with white font
In-Reply-To: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com>
References: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com>
Message-ID: <7RtyeUpv9LcE9Uac1R-LAe5Ig9xqGHmXCQdm1rAbsN0=.af93c4a7-ad38-443c-a814-409f81459e47@github.com>

On Sat, 13 Dec 2025 00:33:30 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> One of the possible code paths for `TextLayout.getPixelBounds(...)` actually draws the text on a `Graphics2D` and checks the image pixels afterwards. The text is drawn over a white background, so if the user sets the font's foreground color to white then the text pixels cannot be detected (white on white).
> 
> This PR fixes the issue by removing the code that sets the background to white, leaving the background as the default ARGB color (0 = transparent black). This does not cause a new problem for users who might set their font foreground color to transparent black, because transparent font foreground colors always return an empty bounds anyway (by virtue of being transparent).
> 
> The updated code should also be slightly faster since it's doing less work, though I haven't run any performance tests.

all our existing normal tests passed, as well as the new one.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28809#pullrequestreview-3600283604

From azvegint at openjdk.org  Sat Dec 20 04:11:21 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 20 Dec 2025 04:11:21 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI,
 but not locally
Message-ID: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>

This is a test stabilization changeset for intermittent failures in the CI for Wayland.
I made minimal changes where applicable. There was no goal to refactor all affected tests.

* `test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java`
 Without the added delay, the `stateChanged` variable could be overwritten by a previous `mouseMoveAndPressOnChoice` call.
* `test/jdk/java/awt/Focus/ClearLwQueueBreakTest/ClearLwQueueBreakTest.java`
The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8198618
* `test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java` 
The test made many setSize calls within a single `invokeAndWait` block and immediately checked the sizes. This works on the X11 server, but the XWayland implementation appears to be different. The `ConfigureNotify` with the correct sizes arrives later, but the test doesn't wait for it. Therefore, it was refactored.
* test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
The test may still fail intermittently in the CI, but an additional delay after `setVisible` won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529
* `test/jdk/java/awt/LightweightComponent/LightWeightTabFocus/LightWeightTabFocus.java`
mouse button was not released causing subsequent test failures.
* `test/jdk/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java`
details are in the test's comment.
 
This doesn't solve all the intermittent test issues related to Wayland (sometimes not even on Wayland).
Some of the tests described in the bug report are no longer reproducible. I will file new issues for future failures.
I also tested that it does not break other platforms testing as well.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/28939/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28939&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346154
  Stats: 90 lines in 6 files changed: 46 ins; 9 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/28939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28939/head:pull/28939

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

From azvegint at openjdk.org  Sat Dec 20 04:22:55 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 20 Dec 2025 04:22:55 GMT
Subject: RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting [v3]
In-Reply-To: <APPQJ3dinbOBMAZimIhsbOAiZdxzdyINN9AAhWVn174=.7949085f-a37e-41e6-8b5d-b4acf7afc73b@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
 <APPQJ3dinbOBMAZimIhsbOAiZdxzdyINN9AAhWVn174=.7949085f-a37e-41e6-8b5d-b4acf7afc73b@github.com>
Message-ID: <t-UL6CSK0jH3s7uuzTDgsPbDLnD42eEUHe_P1DF5KCo=.a673ff15-e8df-47c3-9903-19f92928da3a@github.com>

On Fri, 19 Dec 2025 04:51:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
>> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
>> 
>> The JDK-8224261 is hereby backed out
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AUtomate test

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28885#pullrequestreview-3600701408

From duke at openjdk.org  Sat Dec 20 07:59:54 2025
From: duke at openjdk.org (khanbilal732)
Date: Sat, 20 Dec 2025 07:59:54 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI, 
 but not locally
In-Reply-To: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
Message-ID: <3qhBRPObJ38z0sqfC-L330OfTOEoNEL9dFjRJL_sD8A=.48a249b3-3a49-4950-b01b-f2d9fcfd5736@github.com>

On Sat, 20 Dec 2025 03:31:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is a test stabilization changeset for intermittent failures in the CI for Wayland.
> I made minimal changes where applicable. There was no goal to refactor all affected tests.
> 
> * `test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java`
>  Without the added delay, the `stateChanged` variable could be overwritten by a previous `mouseMoveAndPressOnChoice` call.
> * `test/jdk/java/awt/Focus/ClearLwQueueBreakTest/ClearLwQueueBreakTest.java`
> The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8198618
> * `test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java` 
> The test made many setSize calls within a single `invokeAndWait` block and immediately checked the sizes. This works on the X11 server, but the XWayland implementation appears to be different. The `ConfigureNotify` with the correct sizes arrives later, but the test doesn't wait for it. Therefore, it was refactored.
> * test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
> The test may still fail intermittently in the CI, but an additional delay after `setVisible` won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529
> * `test/jdk/java/awt/LightweightComponent/LightWeightTabFocus/LightWeightTabFocus.java`
> mouse button was not released causing subsequent test failures.
> * `test/jdk/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java`
> details are in the test's comment.
>  
> This doesn't solve all the intermittent test issues related to Wayland (sometimes not even on Wayland).
> Some of the tests described in the bug report are no longer reproducible. I will file new issues for future failures.
> I also tested that it does not break other platforms testing as well.

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/28939#pullrequestreview-3600847508
PR Review: https://git.openjdk.org/jdk/pull/28939#pullrequestreview-3600847560
PR Review: https://git.openjdk.org/jdk/pull/28939#pullrequestreview-3600848965

From duke at openjdk.org  Sat Dec 20 08:33:51 2025
From: duke at openjdk.org (khanbilal732)
Date: Sat, 20 Dec 2025 08:33:51 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI, 
 but not locally
In-Reply-To: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
Message-ID: <IDP6dyjXbXSGHPOSUpqvZKZhoLayrzUpkm87jljxEnk=.3642f9ed-ea4d-4e4d-bbc4-d01416da2ffe@github.com>

On Sat, 20 Dec 2025 03:31:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is a test stabilization changeset for intermittent failures in the CI for Wayland.
> I made minimal changes where applicable. There was no goal to refactor all affected tests.
> 
> * `test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java`
>  Without the added delay, the `stateChanged` variable could be overwritten by a previous `mouseMoveAndPressOnChoice` call.
> * `test/jdk/java/awt/Focus/ClearLwQueueBreakTest/ClearLwQueueBreakTest.java`
> The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8198618
> * `test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java` 
> The test made many setSize calls within a single `invokeAndWait` block and immediately checked the sizes. This works on the X11 server, but the XWayland implementation appears to be different. The `ConfigureNotify` with the correct sizes arrives later, but the test doesn't wait for it. Therefore, it was refactored.
> * test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
> The test may still fail intermittently in the CI, but an additional delay after `setVisible` won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529
> * `test/jdk/java/awt/LightweightComponent/LightWeightTabFocus/LightWeightTabFocus.java`
> mouse button was not released causing subsequent test failures.
> * `test/jdk/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java`
> details are in the test's comment.
>  
> This doesn't solve all the intermittent test issues related to Wayland (sometimes not even on Wayland).
> Some of the tests described in the bug report are no longer reproducible. I will file new issues for future failures.
> I also tested that it does not break other platforms testing as well.

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/28939#pullrequestreview-3600877505

From serb at openjdk.org  Sun Dec 21 04:14:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 21 Dec 2025 04:14:58 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI, 
 but not locally
In-Reply-To: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
Message-ID: <74M2BDgqYTcGbGlHUX27dG4kqa22DOFZXyIhQNlr8KY=.8c4ec621-5c21-4f83-b192-5c467df034cb@github.com>

On Sat, 20 Dec 2025 03:31:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is a test stabilization changeset for intermittent failures in the CI for Wayland.
> I made minimal changes where applicable. There was no goal to refactor all affected tests.
> 
> * `test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java`
>  Without the added delay, the `stateChanged` variable could be overwritten by a previous `mouseMoveAndPressOnChoice` call.
> * `test/jdk/java/awt/Focus/ClearLwQueueBreakTest/ClearLwQueueBreakTest.java`
> The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8198618
> * `test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java` 
> The test made many setSize calls within a single `invokeAndWait` block and immediately checked the sizes. This works on the X11 server, but the XWayland implementation appears to be different. The `ConfigureNotify` with the correct sizes arrives later, but the test doesn't wait for it. Therefore, it was refactored.
> * test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
> The test may still fail intermittently in the CI, but an additional delay after `setVisible` won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529
> * `test/jdk/java/awt/LightweightComponent/LightWeightTabFocus/LightWeightTabFocus.java`
> mouse button was not released causing subsequent test failures.
> * `test/jdk/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java`
> details are in the test's comment.
>  
> This doesn't solve all the intermittent test issues related to Wayland (sometimes not even on Wayland).
> Some of the tests described in the bug report are no longer reproducible. I will file new issues for future failures.
> I also tested that it does not break other platforms testing as well.

Marked as reviewed by serb (Reviewer).

test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java line 92:

> 90:         frame.setVisible(true);
> 91:         Util.waitForIdle(robot);
> 92:         robot.delay(1000);

Isn?t it suspicious that it is not possible to show the frame quickly? I mean, 1 second is quite a long time. Is there any possibility to improve this on the toolkit side?

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

PR Review: https://git.openjdk.org/jdk/pull/28939#pullrequestreview-3601457053
PR Review Comment: https://git.openjdk.org/jdk/pull/28939#discussion_r2637532162

From psadhukhan at openjdk.org  Sun Dec 21 05:28:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 21 Dec 2025 05:28:12 GMT
Subject: Integrated: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting
In-Reply-To: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
References: <S81Xlx0pbKbpAuiwIWBVLji-Gfi2D-OHP7Lzj5GPc5o=.079200af-7c1e-4667-8c94-0eefae96612e@github.com>
Message-ID: <lV2a1SAYtKULLHAiJJf06hvAd5tHtlMLyoug3Mty3kc=.058c6e84-2406-4619-80a3-3d5480dafff9@github.com>

On Thu, 18 Dec 2025 02:57:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> [JDK-8224261](https://bugs.openjdk.org/browse/JDK-8224261) fix controls background painting by checking if border is painted or not. This is wrong as background should always be painted else background will not be painted if border is not there
> JProgressBar.setBorderPainted spec says " Some look and feels might not implement painted borders; they will ignore this property." so not painting border is ok but not painting background is an issue
> 
> The JDK-8224261 is hereby backed out

This pull request has now been integrated.

Changeset: fe5911c7
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe5911c7695283cb76b3d95877138b0b15bc0ba4
Stats:     237 lines in 3 files changed: 123 ins; 110 del; 4 mod

8373946: Synth ProgressBarUI implementation confuses background painting with border painting

Reviewed-by: prr, kizune, azvegint

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

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

From psadhukhan at openjdk.org  Sun Dec 21 05:39:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 21 Dec 2025 05:39:42 GMT
Subject: [jdk26] RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting
Message-ID: <tRNJ5XYe9PTcZFtSPh7JRBPzfD-OLSQ2a-rtK4ZMFxo=.54d320ea-1269-4421-a717-e3e584a2aea9@github.com>

8373946: Synth ProgressBarUI implementation confuses background painting with border painting

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

Commit messages:
 - Backport fe5911c7695283cb76b3d95877138b0b15bc0ba4

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

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

From prr at openjdk.org  Sun Dec 21 17:51:53 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 21 Dec 2025 17:51:53 GMT
Subject: [jdk26] RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting
In-Reply-To: <tRNJ5XYe9PTcZFtSPh7JRBPzfD-OLSQ2a-rtK4ZMFxo=.54d320ea-1269-4421-a717-e3e584a2aea9@github.com>
References: <tRNJ5XYe9PTcZFtSPh7JRBPzfD-OLSQ2a-rtK4ZMFxo=.54d320ea-1269-4421-a717-e3e584a2aea9@github.com>
Message-ID: <8Eov4va8la37_MiqYNuts5DkmAjwAkzHcwg_l3jOcmw=.69ed5acc-37c7-4bca-87e0-289ddf279161@github.com>

On Sun, 21 Dec 2025 05:31:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> 8373946: Synth ProgressBarUI implementation confuses background painting with border painting

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28941#pullrequestreview-3601857259

From prr at openjdk.org  Sun Dec 21 18:13:02 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 21 Dec 2025 18:13:02 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI, 
 but not locally
In-Reply-To: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
Message-ID: <sJvs_sdvDk6olg2S1VWOAtlMmw4RK3XAKSvSfTm59lo=.dc6e5c6e-3967-49bf-a22c-a375569c6aef@github.com>

On Sat, 20 Dec 2025 03:31:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is a test stabilization changeset for intermittent failures in the CI for Wayland.
> I made minimal changes where applicable. There was no goal to refactor all affected tests.
> 
> * `test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java`
>  Without the added delay, the `stateChanged` variable could be overwritten by a previous `mouseMoveAndPressOnChoice` call.
> * `test/jdk/java/awt/Focus/ClearLwQueueBreakTest/ClearLwQueueBreakTest.java`
> The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8198618
> * `test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java` 
> The test made many setSize calls within a single `invokeAndWait` block and immediately checked the sizes. This works on the X11 server, but the XWayland implementation appears to be different. The `ConfigureNotify` with the correct sizes arrives later, but the test doesn't wait for it. Therefore, it was refactored.
> * test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
> The test may still fail intermittently in the CI, but an additional delay after `setVisible` won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529
> * `test/jdk/java/awt/LightweightComponent/LightWeightTabFocus/LightWeightTabFocus.java`
> mouse button was not released causing subsequent test failures.
> * `test/jdk/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java`
> details are in the test's comment.
>  
> This doesn't solve all the intermittent test issues related to Wayland (sometimes not even on Wayland).
> Some of the tests described in the bug report are no longer reproducible. I will file new issues for future failures.
> I also tested that it does not break other platforms testing as well.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28939#pullrequestreview-3601876470

From psadhukhan at openjdk.org  Mon Dec 22 01:26:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 22 Dec 2025 01:26:03 GMT
Subject: [jdk26] Integrated: 8373946: Synth ProgressBarUI implementation
 confuses background painting with border painting
In-Reply-To: <tRNJ5XYe9PTcZFtSPh7JRBPzfD-OLSQ2a-rtK4ZMFxo=.54d320ea-1269-4421-a717-e3e584a2aea9@github.com>
References: <tRNJ5XYe9PTcZFtSPh7JRBPzfD-OLSQ2a-rtK4ZMFxo=.54d320ea-1269-4421-a717-e3e584a2aea9@github.com>
Message-ID: <Vd0ULAk7Jhu8QQu3OSCsQ-rQ49FaKfzjbKaOW4M04Wk=.b34d9bc8-2b90-4a0d-b315-2933d4e70b67@github.com>

On Sun, 21 Dec 2025 05:31:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> 8373946: Synth ProgressBarUI implementation confuses background painting with border painting

This pull request has now been integrated.

Changeset: d5dde3fc
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5dde3fc90914e375213ee6cd4ec21ed01f34346
Stats:     237 lines in 3 files changed: 123 ins; 110 del; 4 mod

8373946: Synth ProgressBarUI implementation confuses background painting with border painting

Reviewed-by: prr
Backport-of: fe5911c7695283cb76b3d95877138b0b15bc0ba4

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

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

From psadhukhan at openjdk.org  Mon Dec 22 02:04:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 22 Dec 2025 02:04:38 GMT
Subject: [jdk25] RFR: 8373946: Synth ProgressBarUI implementation confuses
 background painting with border painting
Message-ID: <Q2SeaVv57AKqQSalwg9Ja8YyMg7XbMKwU9len1_xJKw=.ec04e4f9-db2a-471e-90a6-2601c5a0bb46@github.com>

8373946: Synth ProgressBarUI implementation confuses background painting with border painting

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

Commit messages:
 - Backport fe5911c7695283cb76b3d95877138b0b15bc0ba4

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

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

From psadhukhan at openjdk.org  Mon Dec 22 02:12:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 22 Dec 2025 02:12:10 GMT
Subject: [jdk25] Withdrawn: 8373946: Synth ProgressBarUI implementation
 confuses background painting with border painting
In-Reply-To: <Q2SeaVv57AKqQSalwg9Ja8YyMg7XbMKwU9len1_xJKw=.ec04e4f9-db2a-471e-90a6-2601c5a0bb46@github.com>
References: <Q2SeaVv57AKqQSalwg9Ja8YyMg7XbMKwU9len1_xJKw=.ec04e4f9-db2a-471e-90a6-2601c5a0bb46@github.com>
Message-ID: <9j9aO0OwKcvZjMeHk5E40cABPO7mTutknaCbrfliyI0=.c36127c2-247d-4ae2-8f81-bc40304fb0d0@github.com>

On Mon, 22 Dec 2025 01:55:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> 8373946: Synth ProgressBarUI implementation confuses background painting with border painting

This pull request has been closed without being integrated.

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

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

From azvegint at openjdk.org  Mon Dec 22 02:39:04 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 02:39:04 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI, 
 but not locally
In-Reply-To: <74M2BDgqYTcGbGlHUX27dG4kqa22DOFZXyIhQNlr8KY=.8c4ec621-5c21-4f83-b192-5c467df034cb@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
 <74M2BDgqYTcGbGlHUX27dG4kqa22DOFZXyIhQNlr8KY=.8c4ec621-5c21-4f83-b192-5c467df034cb@github.com>
Message-ID: <afqwyD5hg6Aqc639quRBuuTg0hN83SJNXJFRFP8vtMo=.ad34fc58-39db-4c57-8797-ed2e9d270eab@github.com>

On Sun, 21 Dec 2025 04:11:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Isn?t it suspicious that it is not possible to show the frame quickly? I mean, 1 second is quite a long time. Is there any possibility to improve this on the toolkit side?

This is just a precaution, and bringing it to a standard format for our tests `setVisible` / `waitForIdle` / `delay`.
Whether it's 1000 ms or 500 ms doesn't change anything for the test; it can still fail intermittently.

> test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28939#discussion_r2638427442

From azvegint at openjdk.org  Mon Dec 22 02:39:06 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 02:39:06 GMT
Subject: Integrated: 8346154: [XWayland] Some tests fail intermittently in the
 CI, but not locally
In-Reply-To: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
Message-ID: <hXO6C6pxvBAwfeA4J-WlbGZieiiTPMWF-3lDaR015UY=.d1d5fef3-2b24-4bc7-9793-23840fe9a73f@github.com>

On Sat, 20 Dec 2025 03:31:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is a test stabilization changeset for intermittent failures in the CI for Wayland.
> I made minimal changes where applicable. There was no goal to refactor all affected tests.
> 
> * `test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java`
>  Without the added delay, the `stateChanged` variable could be overwritten by a previous `mouseMoveAndPressOnChoice` call.
> * `test/jdk/java/awt/Focus/ClearLwQueueBreakTest/ClearLwQueueBreakTest.java`
> The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8198618
> * `test/jdk/java/awt/Frame/FrameSetMinimumSizeTest.java` 
> The test made many setSize calls within a single `invokeAndWait` block and immediately checked the sizes. This works on the X11 server, but the XWayland implementation appears to be different. The `ConfigureNotify` with the correct sizes arrives later, but the test doesn't wait for it. Therefore, it was refactored.
> * test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
> The test may still fail intermittently in the CI, but an additional delay after `setVisible` won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529
> * `test/jdk/java/awt/LightweightComponent/LightWeightTabFocus/LightWeightTabFocus.java`
> mouse button was not released causing subsequent test failures.
> * `test/jdk/java/awt/Modal/ToFront/DialogToFrontModeless1Test.java`
> details are in the test's comment.
>  
> This doesn't solve all the intermittent test issues related to Wayland (sometimes not even on Wayland).
> Some of the tests described in the bug report are no longer reproducible. I will file new issues for future failures.
> I also tested that it does not break other platforms testing as well.

This pull request has now been integrated.

Changeset: 9435d5b8
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9435d5b89ca08595f0f2f8d029c00bc6d1f30104
Stats:     90 lines in 6 files changed: 46 ins; 9 del; 35 mod

8346154: [XWayland] Some tests fail intermittently in the CI, but not locally

Reviewed-by: serb, prr

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

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

From dnguyen at openjdk.org  Mon Dec 22 05:27:09 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 05:27:09 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp
Message-ID: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>

This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.

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

Commit messages:
 - Initial commit

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

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

From dnguyen at openjdk.org  Mon Dec 22 05:36:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 05:36:54 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp
Message-ID: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>

This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.

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

Commit messages:
 - Initial commit

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

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

From azvegint at openjdk.org  Mon Dec 22 12:51:05 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 12:51:05 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp
In-Reply-To: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
Message-ID: <wKXwwo172_y6nuZVO_dfGtxpGOiyJydPhvkQKM7zCiM=.b71b6ab6-612b-4e05-901a-9ccee1aac137@github.com>

On Mon, 22 Dec 2025 05:30:11 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.

src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 101:

> 99: 
> 100:     fprintf(logfile, "%s", tmpbuf);
> 101:     fprintf(logfile, "\n");

Suggestion:

    fprintf(logfile, "%s\n", tmpbuf);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2639781528

From azvegint at openjdk.org  Mon Dec 22 14:34:02 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 14:34:02 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp
In-Reply-To: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
Message-ID: <XU6wzJgMj8cylyYAY3ff-fafdTVN1mdJHlneFHBnULE=.ba1dfc65-9e3c-4767-8b95-8a067db8344f@github.com>

On Mon, 22 Dec 2025 05:18:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.

src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 231:

> 229:                 char str[100] = "assistive_technologies=com.sun.java.accessibility.AccessBridge\n";
> 230:                 strcat_s(str, "screen_magnifier_present=true\n");
> 231:                 fprintf(origFile, "%s", str);

Why do we need the `str` buffer at all?

Shouldn't `fprintf` be enough?


fprintf(origFile,
    "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
    "screen_magnifier_present=true\n");

src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 321:

> 319:     strcat_s(outputString, versionString);
> 320:     strcat_s(outputString, "\njabswitch enables or disables the Java Access Bridge.\n");
> 321:     printf("%s", outputString);

Same for the `outputString`


printf(
    "jabswitch %s\n"
    "jabswitch enables or disables the Java Access Bridge.\n",
    versionString
);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2640052922
PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2640065588

From djgredler at gmail.com  Mon Dec 22 15:37:11 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Mon, 22 Dec 2025 16:37:11 +0100
Subject: Backwards compatibility question (FontRenderContext)
Message-ID: <CAPA+ug7La9vgPvZEr1KzCKJuiyXRQeR9fy7CLd-15B+FNqGygw@mail.gmail.com>

Hi guys,

The `FontRenderContext` class does not have any setters for the data which
it carries, so from a public API perspective it is immutable. However, the
private instance variables are not declared final. I was thinking about
raising a small PR to make the instance variables final, to more clearly
indicate the immutability of the class. Is this considered a
backwards-compatible change? Or is it considered non-backwards-compatible,
since users can technically use reflection to fiddle with the class
internals (and since final will soon more definitely mean final)?

Take care,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251222/659491f2/attachment.htm>

From serb at openjdk.org  Mon Dec 22 18:06:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 22 Dec 2025 18:06:57 GMT
Subject: RFR: 8373650: Test
 javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check
 icons are not aligned properly as expected
In-Reply-To: <GpSv6WiinB_ZK1A4HFSP_fpcdDjGn8KHr_JQyenQhbM=.400739ab-9e6b-4a2c-945d-76440dd04831@github.com>
References: <GpSv6WiinB_ZK1A4HFSP_fpcdDjGn8KHr_JQyenQhbM=.400739ab-9e6b-4a2c-945d-76440dd04831@github.com>
Message-ID: <nPbTfYbyAnRpVx9Bie5sFtDvB0IFxWIPI9ib6-cQ94U=.a6c4e1d5-ac79-4df7-9842-ac0377c2b77e@github.com>

On Thu, 18 Dec 2025 07:34:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>Check/radiobutton icon are not aligned properly in RTL.

What is the proper alignment in this context? The ?After fix? image shows that the icons still jump left and right.

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

PR Comment: https://git.openjdk.org/jdk/pull/28889#issuecomment-3683241819

From azvegint at openjdk.org  Mon Dec 22 18:53:51 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 18:53:51 GMT
Subject: RFR: 8373967: [macos] User interactions with List do not trigger
 ItemEvent after programmatic change
In-Reply-To: <XH1WLODEyM40iYMQlMEkYaCj1qpvKf1EPXla_B-XOVM=.2c49126b-fc34-47e3-8328-a398eb84835b@github.com>
References: <XH1WLODEyM40iYMQlMEkYaCj1qpvKf1EPXla_B-XOVM=.2c49126b-fc34-47e3-8328-a398eb84835b@github.com>
Message-ID: <-t4F25ihxTwxYab1u-zfj_Kvjc1VlSRHIYO0mwDmuEo=.39ea75cf-b814-40b8-bb27-d62a1a701123@github.com>

On Thu, 18 Dec 2025 08:25:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix in LWListPeer introduced by [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456) was intended to suppress ItemEvents for programmatic changes to a List, while still allowing events generated by user interaction.
> 
> The implementation unconditionally bypasses the listener logic:
> https://hg.openjdk.org/jdk7u/jdk7u-osx/jdk/rev/dfa991721457
> Unfortunately that logic also updates the cached selection state. As a result, when the application select something programmatically, the cached state is not updated.
> 
> The change move out the `oldSelectedIndices = source.getSelectedIndices();` from the `!isSkipStateChangedEvent()` condition, plus some cleanup.

LGTM.
I've also verified that CI testing looks good on all platforms.

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28890#pullrequestreview-3605316595

From dnguyen at openjdk.org  Mon Dec 22 20:34:53 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 20:34:53 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
Message-ID: <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>

> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.

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

  Combine fprintf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28950/files
  - new: https://git.openjdk.org/jdk/pull/28950/files/f6e89614..7ff146b4

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

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

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

From dnguyen at openjdk.org  Mon Dec 22 20:34:57 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 20:34:57 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <wKXwwo172_y6nuZVO_dfGtxpGOiyJydPhvkQKM7zCiM=.b71b6ab6-612b-4e05-901a-9ccee1aac137@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <wKXwwo172_y6nuZVO_dfGtxpGOiyJydPhvkQKM7zCiM=.b71b6ab6-612b-4e05-901a-9ccee1aac137@github.com>
Message-ID: <t0FnSIERNR8sXmfXTrsGphEgzAKiH6YdhEbNYsV5Q0g=.a6746825-ff42-4cdf-aff4-af6d77a60b61@github.com>

On Mon, 22 Dec 2025 12:48:07 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Combine fprintf
>
> src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 101:
> 
>> 99: 
>> 100:     fprintf(logfile, "%s", tmpbuf);
>> 101:     fprintf(logfile, "\n");
> 
> Suggestion:
> 
>     fprintf(logfile, "%s\n", tmpbuf);

Updated, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2641152237

From dnguyen at openjdk.org  Mon Dec 22 20:48:38 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 20:48:38 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <XU6wzJgMj8cylyYAY3ff-fafdTVN1mdJHlneFHBnULE=.ba1dfc65-9e3c-4767-8b95-8a067db8344f@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <XU6wzJgMj8cylyYAY3ff-fafdTVN1mdJHlneFHBnULE=.ba1dfc65-9e3c-4767-8b95-8a067db8344f@github.com>
Message-ID: <xbJoJ1jRGbVny4ATUPUeFDYFSNZ-TtXM3YIYuiIi0Ks=.123fd316-e97a-4cc8-8a2a-65a228339578@github.com>

On Mon, 22 Dec 2025 14:25:46 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update printf
>
> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 231:
> 
>> 229:                 char str[100] = "assistive_technologies=com.sun.java.accessibility.AccessBridge\n";
>> 230:                 strcat_s(str, "screen_magnifier_present=true\n");
>> 231:                 fprintf(origFile, "%s", str);
> 
> Why do we need the `str` buffer at all?
> 
> Shouldn't `fprintf` be enough?
> 
> 
> fprintf(origFile,
>     "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
>     "screen_magnifier_present=true\n");

Updated, thanks!

> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 321:
> 
>> 319:     strcat_s(outputString, versionString);
>> 320:     strcat_s(outputString, "\njabswitch enables or disables the Java Access Bridge.\n");
>> 321:     printf("%s", outputString);
> 
> Same for the `outputString`
> 
> 
> printf(
>     "jabswitch %s\n"
>     "jabswitch enables or disables the Java Access Bridge.\n",
>     versionString
> );

I have also updated this. I was initially skeptical of the implications of replacing the vars entirely, but now I agree that this replacement should be safer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641189410
PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641191643

From dnguyen at openjdk.org  Mon Dec 22 20:48:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 20:48:36 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
Message-ID: <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>

> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.

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

  Update printf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28949/files
  - new: https://git.openjdk.org/jdk/pull/28949/files/3b1f27c2..b4bef299

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

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

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

From azvegint at openjdk.org  Mon Dec 22 21:33:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 21:33:53 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
Message-ID: <S4Tkn612QpO3au1MsAkKBLlPEhqPXyq_VU29eIlUWEM=.d55a3034-69e8-4325-9506-6a03453606c7@github.com>

On Mon, 22 Dec 2025 20:34:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Combine fprintf

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3605813677

From azvegint at openjdk.org  Mon Dec 22 21:36:07 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 21:36:07 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
Message-ID: <m0UHwImUNUbmXITAhao5BbdaocLbVDSs1QJ_4v8wDkE=.cdf095bb-5397-43bd-a000-06993e2e5892@github.com>

On Mon, 22 Dec 2025 20:48:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update printf

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28949#pullrequestreview-3605822543

From prr at openjdk.org  Mon Dec 22 21:41:20 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 Dec 2025 21:41:20 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
Message-ID: <YNEwAy7sOc291SAlE9XgM4OlkDnO1FOzN_NhMkahDeQ=.52d859be-c371-49f9-ae9b-3955bf5d5f28@github.com>

On Mon, 22 Dec 2025 20:48:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update printf

src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 231:

> 229:                 fprintf(origFile,
> 230:                     "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
> 231:                     "screen_magnifier_present=true\n");

I don't think it is what Alexander meant.
I think he meant it should look like
fprintf(origfile, "%s",
"assistive_technologies=com.sun.java.accessibility.AccessBridge\n"screen_magnifier_present=true\n");

I am not sure doing the above would even resolve the complaint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641321297

From dnguyen at openjdk.org  Mon Dec 22 21:53:56 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 21:53:56 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <YNEwAy7sOc291SAlE9XgM4OlkDnO1FOzN_NhMkahDeQ=.52d859be-c371-49f9-ae9b-3955bf5d5f28@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
 <YNEwAy7sOc291SAlE9XgM4OlkDnO1FOzN_NhMkahDeQ=.52d859be-c371-49f9-ae9b-3955bf5d5f28@github.com>
Message-ID: <Y2O2WJfh5xolapUM-8bZx2DrSx3BuTNe1-HihqF14P8=.14ef6d08-607a-497b-b58e-c76f647eef2e@github.com>

On Mon, 22 Dec 2025 21:38:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update printf
>
> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 231:
> 
>> 229:                 fprintf(origFile,
>> 230:                     "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
>> 231:                     "screen_magnifier_present=true\n");
> 
> I don't think it is what Alexander meant.
> I am not sure doing the above  would even resolve the complaint because there's still no format string.
> 
> I think he meant it should look like
> fprintf(origfile, "%s",
> "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"screen_magnifier_present=true\n");
> or
> fprintf(origfile, "%s",
> "assistive_technologies=com.sun.java.accessibility.AccessBridge\n" "screen_magnifier_present=true\n");
> if you really want to use the automatic concatenation, but I had to check to be sure it would work so ..

I see your point. I'll leave it as separated again just in case the string literal is updated with anything that can be misinterpreted as a specifier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641344380

From dnguyen at openjdk.org  Mon Dec 22 22:10:49 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 22:10:49 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v3]
In-Reply-To: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
Message-ID: <BtpEy3jZc3n1QM0HHZIyvgwDnrEpP6cX7q5aXVXMGx8=.b6ac5ffb-39aa-4605-b6c9-b6fcaed9b755@github.com>

> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.

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

  Revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28949/files
  - new: https://git.openjdk.org/jdk/pull/28949/files/b4bef299..ebbafcfb

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

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

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

From serb at openjdk.org  Mon Dec 22 22:14:12 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 22 Dec 2025 22:14:12 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI, 
 but not locally
In-Reply-To: <afqwyD5hg6Aqc639quRBuuTg0hN83SJNXJFRFP8vtMo=.ad34fc58-39db-4c57-8797-ed2e9d270eab@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
 <74M2BDgqYTcGbGlHUX27dG4kqa22DOFZXyIhQNlr8KY=.8c4ec621-5c21-4f83-b192-5c467df034cb@github.com>
 <afqwyD5hg6Aqc639quRBuuTg0hN83SJNXJFRFP8vtMo=.ad34fc58-39db-4c57-8797-ed2e9d270eab@github.com>
Message-ID: <ZfTEygudkl0ikkapPWR90wq0lnTVppuON11xoGJkGm0=.44df5d56-1280-4e51-b335-f90b4783cf04@github.com>

On Mon, 22 Dec 2025 02:34:14 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java line 92:
>> 
>>> 90:         frame.setVisible(true);
>>> 91:         Util.waitForIdle(robot);
>>> 92:         robot.delay(1000);
>> 
>> Isn?t it suspicious that it is not possible to show the frame quickly? I mean, 1 second is quite a long time. Is there any possibility to improve this on the toolkit side?
>
>> Isn?t it suspicious that it is not possible to show the frame quickly? I mean, 1 second is quite a long time. Is there any possibility to improve this on the toolkit side?
> 
> This is just a precaution, and bringing it to a standard format for our tests `setVisible` / `waitForIdle` / `delay`.
> Whether it's 1000 ms or 500 ms doesn't change anything for the test; it can still fail intermittently.
> 
>> test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java
> The test may still fail intermittently in the CI, but an additional delay after setVisible won't cause any problems / https://bugs.openjdk.org/browse/JDK-8257529

but it passed before on x11, correct? so it mighte be usefull to investigate why we need this delay now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28939#discussion_r2641393074

From azvegint at openjdk.org  Mon Dec 22 22:53:52 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 22 Dec 2025 22:53:52 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <Y2O2WJfh5xolapUM-8bZx2DrSx3BuTNe1-HihqF14P8=.14ef6d08-607a-497b-b58e-c76f647eef2e@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
 <YNEwAy7sOc291SAlE9XgM4OlkDnO1FOzN_NhMkahDeQ=.52d859be-c371-49f9-ae9b-3955bf5d5f28@github.com>
 <Y2O2WJfh5xolapUM-8bZx2DrSx3BuTNe1-HihqF14P8=.14ef6d08-607a-497b-b58e-c76f647eef2e@github.com>
Message-ID: <TmjeU4yXdWqWZMgUTqLfwvF5fEsZW0Ouk23YTaRe1ps=.ff694569-44a9-4a49-b5b3-4532d67a02ac@github.com>

On Mon, 22 Dec 2025 21:50:35 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 231:
>> 
>>> 229:                 fprintf(origFile,
>>> 230:                     "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
>>> 231:                     "screen_magnifier_present=true\n");
>> 
>> I don't think it is what Alexander meant.
>> I am not sure doing the above  would even resolve the complaint because there's still no format string.
>> 
>> I think he meant it should look like
>> fprintf(origfile, "%s",
>> "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"screen_magnifier_present=true\n");
>> or
>> fprintf(origfile, "%s",
>> "assistive_technologies=com.sun.java.accessibility.AccessBridge\n" "screen_magnifier_present=true\n");
>> if you really want to use the automatic concatenation, but I had to check to be sure it would work so ..
>
> I see your point. I'll leave it as separated again just in case the string literal is updated with anything that can be misinterpreted as a specifier.

> I don't think it is what Alexander meant.

Damon understood me correctly. That's what I meant.
https://github.com/openjdk/jdk/pull/28949#discussion_r2640052922

> I am not sure doing the above would even resolve the complaint because there's still no format string.

It should.

before:
```c++
fprintf(origFile, str); // using `str` variable as format string > parfait complains

after:

```c++
  fprintf(origFile,
      "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
      "screen_magnifier_present=true\n"); 

Here, we provide a format string(without the format specifiers), not the variable.
It's essentially identical to the code on line 301, `printf("Unable to get version info.\n");`, parfait didn't complain about that line.

> if you really want to use the automatic concatenation, but I had to check to be sure it would work so ..

It is in the standard, so I don't see any reason not to use it:
https://en.cppreference.com/w/cpp/language/string_literal.html#Concatenation

So, in my opinion, the variable str is unnecessary here.

---
>  just in case the string literal is updated with anything that can be misinterpreted as a specifier.

I suppose it should be detected during the review process for such a change. Currently, there are no format specifiers being used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641462741

From prr at openjdk.org  Mon Dec 22 23:10:51 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 Dec 2025 23:10:51 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <TmjeU4yXdWqWZMgUTqLfwvF5fEsZW0Ouk23YTaRe1ps=.ff694569-44a9-4a49-b5b3-4532d67a02ac@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
 <YNEwAy7sOc291SAlE9XgM4OlkDnO1FOzN_NhMkahDeQ=.52d859be-c371-49f9-ae9b-3955bf5d5f28@github.com>
 <Y2O2WJfh5xolapUM-8bZx2DrSx3BuTNe1-HihqF14P8=.14ef6d08-607a-497b-b58e-c76f647eef2e@github.com>
 <TmjeU4yXdWqWZMgUTqLfwvF5fEsZW0Ouk23YTaRe1ps=.ff694569-44a9-4a49-b5b3-4532d67a02ac@github.com>
Message-ID: <7xNOIYABaZvWqNy8LfzChQKMejENC121yinBCVsAL4U=.6b17d297-9c3e-4bef-a57f-d9015772f9b3@github.com>

On Mon, 22 Dec 2025 22:51:30 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> I see your point. I'll leave it as separated again just in case the string literal is updated with anything that can be misinterpreted as a specifier.
>
>> I don't think it is what Alexander meant.
> 
> Damon understood me correctly. That's what I meant.
> https://github.com/openjdk/jdk/pull/28949#discussion_r2640052922
> 
>> I am not sure doing the above would even resolve the complaint because there's still no format string.
> 
> It should.
> 
> before:
> ```c++
> fprintf(origFile, str); // using `str` variable as format string > parfait complains
> 
> after:
> 
> ```c++
>   fprintf(origFile,
>       "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
>       "screen_magnifier_present=true\n"); 
> 
> Here, we provide a format string(without the format specifiers), not the variable.
> It's essentially identical to the code on line 301, `printf("Unable to get version info.\n");`, parfait didn't complain about that line.
> 
>> if you really want to use the automatic concatenation, but I had to check to be sure it would work so ..
> 
> It is in the standard, so I don't see any reason not to use it:
> https://en.cppreference.com/w/cpp/language/string_literal.html#Concatenation
> 
> So, in my opinion, the variable str is unnecessary here.
> 
> ---
>>  just in case the string literal is updated with anything that can be misinterpreted as a specifier.
> 
> I suppose it should be detected during the review process for such a change. Currently, there are no format specifiers being used.

OK fair enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641483735

From prr at openjdk.org  Mon Dec 22 23:10:54 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 Dec 2025 23:10:54 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v3]
In-Reply-To: <BtpEy3jZc3n1QM0HHZIyvgwDnrEpP6cX7q5aXVXMGx8=.b6ac5ffb-39aa-4605-b6c9-b6fcaed9b755@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <BtpEy3jZc3n1QM0HHZIyvgwDnrEpP6cX7q5aXVXMGx8=.b6ac5ffb-39aa-4605-b6c9-b6fcaed9b755@github.com>
Message-ID: <g9e8X1kkKTt2IbRaFqVUSC3fh6A-wRP850zie_n595o=.32373ff1-98be-4c81-a274-edbf3f85a625@github.com>

On Mon, 22 Dec 2025 22:10:49 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert

src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 231:

> 229:                 char str[100] = "assistive_technologies=com.sun.java.accessibility.AccessBridge\n";
> 230:                 strcat_s(str, "screen_magnifier_present=true\n");
> 231:                 fprintf(origFile, "%s", str);

That isn't what I meant either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641485387

From philip.race at oracle.com  Mon Dec 22 23:22:02 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 22 Dec 2025 15:22:02 -0800
Subject: Backwards compatibility question (FontRenderContext)
In-Reply-To: <CAPA+ug7La9vgPvZEr1KzCKJuiyXRQeR9fy7CLd-15B+FNqGygw@mail.gmail.com>
References: <CAPA+ug7La9vgPvZEr1KzCKJuiyXRQeR9fy7CLd-15B+FNqGygw@mail.gmail.com>
Message-ID: <76edf258-8774-4e45-abdd-60f31a39375d@oracle.com>

Anyone doing that would be on their own. So also if it causes any tests 
to fail I'd be surprised.
I wasn't sure how much constructor code reorganisation would be needed 
but it doesn't look too bad.

-phil.

On 12/22/25 7:37 AM, Daniel Gredler wrote:
> Hi guys,
>
> The `FontRenderContext` class does not have any setters for the data 
> which it carries, so from a public API perspective it is immutable. 
> However, the private instance variables are not declared final. I was 
> thinking about raising a small PR to make the instance variables 
> final, to more clearly indicate the immutability of the class. Is this 
> considered a backwards-compatible change? Or is it considered 
> non-backwards-compatible, since users can technically use reflection 
> to fiddle with the class internals (and since final will soon more 
> definitely mean final)?
>
> Take care,
>
> Daniel
>
>


From dnguyen at openjdk.org  Mon Dec 22 23:36:30 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 23:36:30 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v4]
In-Reply-To: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
Message-ID: <N9gV7qdwsHQBDi5b68BJW5tFgNdFAvv9kXgw-mj_DKA=.a509a1d7-76d6-482e-80a1-cea51280d4cf@github.com>

> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.

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

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28949/files
  - new: https://git.openjdk.org/jdk/pull/28949/files/ebbafcfb..e17b09aa

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

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

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

From dnguyen at openjdk.org  Mon Dec 22 23:36:32 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Dec 2025 23:36:32 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v3]
In-Reply-To: <g9e8X1kkKTt2IbRaFqVUSC3fh6A-wRP850zie_n595o=.32373ff1-98be-4c81-a274-edbf3f85a625@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <BtpEy3jZc3n1QM0HHZIyvgwDnrEpP6cX7q5aXVXMGx8=.b6ac5ffb-39aa-4605-b6c9-b6fcaed9b755@github.com>
 <g9e8X1kkKTt2IbRaFqVUSC3fh6A-wRP850zie_n595o=.32373ff1-98be-4c81-a274-edbf3f85a625@github.com>
Message-ID: <2SXwro0Stn69I7JMGauYICaTwlIJh5O01p5HY6DYSmM=.18bbd332-7563-4973-b405-e715ab011ced@github.com>

On Mon, 22 Dec 2025 23:08:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert
>
> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 231:
> 
>> 229:                 char str[100] = "assistive_technologies=com.sun.java.accessibility.AccessBridge\n";
>> 230:                 strcat_s(str, "screen_magnifier_present=true\n");
>> 231:                 fprintf(origFile, "%s", str);
> 
> That isn't what I meant either.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2641517861

From azvegint at openjdk.org  Tue Dec 23 04:28:11 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 23 Dec 2025 04:28:11 GMT
Subject: RFR: 8346154: [XWayland] Some tests fail intermittently in the CI, 
 but not locally
In-Reply-To: <ZfTEygudkl0ikkapPWR90wq0lnTVppuON11xoGJkGm0=.44df5d56-1280-4e51-b335-f90b4783cf04@github.com>
References: <pnb9QMxehtZ58P6F5HFNd3QvO3POWPGOKAc3Sel-AvM=.6ed68df1-596f-481e-b6a7-7436899a3d9f@github.com>
 <74M2BDgqYTcGbGlHUX27dG4kqa22DOFZXyIhQNlr8KY=.8c4ec621-5c21-4f83-b192-5c467df034cb@github.com>
 <afqwyD5hg6Aqc639quRBuuTg0hN83SJNXJFRFP8vtMo=.ad34fc58-39db-4c57-8797-ed2e9d270eab@github.com>
 <ZfTEygudkl0ikkapPWR90wq0lnTVppuON11xoGJkGm0=.44df5d56-1280-4e51-b335-f90b4783cf04@github.com>
Message-ID: <WdOgj9G_K2CrNtjsnUU5MdJJG2FzBxl4uGnNYwXsp7E=.3ad5a32a-5fc4-49fa-a6ab-f604bac631d0@github.com>

On Mon, 22 Dec 2025 22:11:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> but it passed before on x11, correct? 

Most of the time, but not always, there are several CI failure reports on X11, but they don't happen as frequently as they do on XWayland.

> so it mighte be usefull to investigate why we need this delay now.

This delay does not help the test fail less frequently:

>This is just a precaution, and bringing it to a standard format for our tests setVisible / waitForIdle / delay.
Whether it's 1000 ms or 500 ms doesn't change anything for the test; it can still fail intermittently.

It is a real issue that can easily be reproduced on XWayland, [JBS comment](https://bugs.openjdk.org/browse/JDK-8257529?focusedId=14842868&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14842868):
> It is more easily reproduced on Ubuntu/XWayland using the modified ButtonActionKeyTest attached.
> 
> Can also be reproduced manually without the robot interactions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28939#discussion_r2641883830

From djgredler at gmail.com  Tue Dec 23 09:54:32 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Tue, 23 Dec 2025 10:54:32 +0100
Subject: Backwards compatibility question (FontRenderContext)
In-Reply-To: <76edf258-8774-4e45-abdd-60f31a39375d@oracle.com>
References: <CAPA+ug7La9vgPvZEr1KzCKJuiyXRQeR9fy7CLd-15B+FNqGygw@mail.gmail.com>
 <76edf258-8774-4e45-abdd-60f31a39375d@oracle.com>
Message-ID: <CAPA+ug7Qj0kx2u4UJCQXULFLPD+LTTwcuH_6kS3iwBj=YtsB_g@mail.gmail.com>

Understood -- thanks!

Daniel



On Tue, Dec 23, 2025 at 12:22?AM Philip Race <philip.race at oracle.com> wrote:

> Anyone doing that would be on their own. So also if it causes any tests
> to fail I'd be surprised.
> I wasn't sure how much constructor code reorganisation would be needed
> but it doesn't look too bad.
>
> -phil.
>
> On 12/22/25 7:37 AM, Daniel Gredler wrote:
> > Hi guys,
> >
> > The `FontRenderContext` class does not have any setters for the data
> > which it carries, so from a public API perspective it is immutable.
> > However, the private instance variables are not declared final. I was
> > thinking about raising a small PR to make the instance variables
> > final, to more clearly indicate the immutability of the class. Is this
> > considered a backwards-compatible change? Or is it considered
> > non-backwards-compatible, since users can technically use reflection
> > to fiddle with the class internals (and since final will soon more
> > definitely mean final)?
> >
> > Take care,
> >
> > Daniel
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251223/33a00bde/attachment.htm>

From aivanov at openjdk.org  Tue Dec 23 17:23:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 17:23:10 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v4]
In-Reply-To: <N9gV7qdwsHQBDi5b68BJW5tFgNdFAvv9kXgw-mj_DKA=.a509a1d7-76d6-482e-80a1-cea51280d4cf@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <N9gV7qdwsHQBDi5b68BJW5tFgNdFAvv9kXgw-mj_DKA=.a509a1d7-76d6-482e-80a1-cea51280d4cf@github.com>
Message-ID: <P2fCq6z0of5G1dg5K3WxujEc-jsryn12oPKeELyCC9Q=.28a4543d-fa76-48b7-ac70-22108b04ebe2@github.com>

On Mon, 22 Dec 2025 23:36:30 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Changes requested by aivanov (Reviewer).

src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 1:

> 1: /*

You should update the copyright year.

src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 321:

> 319:         "jabswitch enables or disables the Java Access Bridge.\n",
> 320:         versionString
> 321:     );

If `versionString` isn't used for anything else, we can remove the `versionString` variable and the call to `sprintf_s` and put the arguments to print the version string directly into the `printf` call.

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

PR Review: https://git.openjdk.org/jdk/pull/28949#pullrequestreview-3608777582
PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2643836065
PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2643832334

From aivanov at openjdk.org  Tue Dec 23 17:23:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 17:23:12 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <7xNOIYABaZvWqNy8LfzChQKMejENC121yinBCVsAL4U=.6b17d297-9c3e-4bef-a57f-d9015772f9b3@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
 <YNEwAy7sOc291SAlE9XgM4OlkDnO1FOzN_NhMkahDeQ=.52d859be-c371-49f9-ae9b-3955bf5d5f28@github.com>
 <Y2O2WJfh5xolapUM-8bZx2DrSx3BuTNe1-HihqF14P8=.14ef6d08-607a-497b-b58e-c76f647eef2e@github.com>
 <TmjeU4yXdWqWZMgUTqLfwvF5fEsZW0Ouk23YTaRe1ps=.ff694569-44a9-4a49-b5b3-4532d67a02ac@github.com>
 <7xNOIYABaZvWqNy8LfzChQKMejENC121yinBCVsAL4U=.6b17d297-9c3e-4bef-a57f-d9015772f9b3@github.com>
Message-ID: <Yps7xqVD3-Gp9kgra8pxq_1lvYOapfhqyp2R0o5Cisw=.77642bbf-c775-4e10-b06b-1af88238283a@github.com>

On Mon, 22 Dec 2025 23:07:19 GMT, Phil Race <prr at openjdk.org> wrote:

>>> I don't think it is what Alexander meant.
>> 
>> Damon understood me correctly. That's what I meant.
>> https://github.com/openjdk/jdk/pull/28949#discussion_r2640052922
>> 
>>> I am not sure doing the above would even resolve the complaint because there's still no format string.
>> 
>> It should.
>> 
>> before:
>> ```c++
>> fprintf(origFile, str); // using `str` variable as format string > parfait complains
>> 
>> after:
>> 
>> ```c++
>>   fprintf(origFile,
>>       "assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
>>       "screen_magnifier_present=true\n"); 
>> 
>> Here, we provide a format string(without the format specifiers), not the variable.
>> It's essentially identical to the code on line 301, `printf("Unable to get version info.\n");`, parfait didn't complain about that line.
>> 
>>> if you really want to use the automatic concatenation, but I had to check to be sure it would work so ..
>> 
>> It is in the standard, so I don't see any reason not to use it:
>> https://en.cppreference.com/w/cpp/language/string_literal.html#Concatenation
>> 
>> So, in my opinion, the variable str is unnecessary here.
>> 
>> ---
>>>  just in case the string literal is updated with anything that can be misinterpreted as a specifier.
>> 
>> I suppose it should be detected during the review process for such a change. Currently, there are no format specifiers being used.
>
> OK fair enough.

Why can't we use [`fputs`](https://en.cppreference.com/w/c/io/fputs.html)?


                fputs("assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
                      "screen_magnifier_present=true\n",
                      origFile);

No format strings avoid any possible ambiguity and it's much faster as the string is output verbatim without any additional logic to parse a format string and to process the arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2643826617

From aivanov at openjdk.org  Tue Dec 23 17:28:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 17:28:56 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
Message-ID: <1VpCU5D8AKiimzA0ZQXoKjKfVp0X1SAUmc0o5PRF01k=.7e44088f-8946-424c-998c-386254c63484@github.com>

On Mon, 22 Dec 2025 20:34:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Combine fprintf

Changes requested by aivanov (Reviewer).

src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 1:

> 1: /*

Bump the copyright year.

src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 100:

> 98:     vsnprintf(tmpbuf, sizeof(tmpbuf), msg, argprt);
> 99: 
> 100:     fprintf(logfile, "%s\n", tmpbuf);

Why can't we use [`fputs`](https://en.cppreference.com/w/c/io/fputs.html) and avoid all the format string logic and ambiguity altogether?

Alternatively, *use `vfprintf` directly* instead of first formatting the arguments into a temporary buffer with `vsnprintf` and then sending the result to the output.

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

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3608795656
PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2643847378
PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2643839745

From aivanov at openjdk.org  Tue Dec 23 17:35:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 17:35:02 GMT
Subject: RFR: 8373847: Test
 javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test
 case automatically fails when clicking any items in the
 =?UTF-8?B?4oCcTm90aGluZ+KAnQ==?= menu in all four windows (Left-to-right)-Menu
 Item Test and (Right-to-left)-Menu Item Test
In-Reply-To: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com>
References: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com>
Message-ID: <9BQG5kCpRVv5ef6uX4YJOp3D0RBM8l30_2AVkoalF-Y=.b2cdc9c3-30c6-4767-8efc-b1121e1b9eef@github.com>

On Thu, 18 Dec 2025 03:32:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When user selects any menu item from "No nothing". the following exception happens because PassFailJFrame logArea is not created
> 
> java.lang.NullPointerException: Cannot invoke "javax.swing.JTextArea.append(String)" because "PassFailJFrame.logArea" is null
> at PassFailJFrame.lambda$log$0(PassFailJFrame.java:1353)
> at PassFailJFrame.invokeOnEDT(PassFailJFrame.java:570)
> at PassFailJFrame.invokeOnEDTUncheckedException(PassFailJFrame.java:584)
> at PassFailJFrame.log(PassFailJFrame.java:1353)
> at MenuItemTestHelper.lambda$createNoNothingMenu$0(MenuItemTestHelper.java:118) 
> 
> 
> Fix is to create log area

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28887#pullrequestreview-3608821136

From serb at openjdk.org  Tue Dec 23 18:40:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 23 Dec 2025 18:40:03 GMT
Subject: Integrated: 8373967: [macos] User interactions with List do not
 trigger ItemEvent after programmatic change
In-Reply-To: <XH1WLODEyM40iYMQlMEkYaCj1qpvKf1EPXla_B-XOVM=.2c49126b-fc34-47e3-8328-a398eb84835b@github.com>
References: <XH1WLODEyM40iYMQlMEkYaCj1qpvKf1EPXla_B-XOVM=.2c49126b-fc34-47e3-8328-a398eb84835b@github.com>
Message-ID: <xCetqmDbDHf0mlXOZixENAjpH6coSytuLnmrTid8LMc=.460751b4-a610-409d-bc53-9e9afe5480dd@github.com>

On Thu, 18 Dec 2025 08:25:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix in LWListPeer introduced by [JDK-7125456](https://bugs.openjdk.org/browse/JDK-7125456) was intended to suppress ItemEvents for programmatic changes to a List, while still allowing events generated by user interaction.
> 
> The implementation unconditionally bypasses the listener logic:
> https://hg.openjdk.org/jdk7u/jdk7u-osx/jdk/rev/dfa991721457
> Unfortunately that logic also updates the cached selection state. As a result, when the application select something programmatically, the cached state is not updated.
> 
> The change move out the `oldSelectedIndices = source.getSelectedIndices();` from the `!isSkipStateChangedEvent()` condition, plus some cleanup.

This pull request has now been integrated.

Changeset: be2ac088
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be2ac088e86f2be59f26997003cd02bad16672a0
Stats:     135 lines in 2 files changed: 121 ins; 5 del; 9 mod

8373967: [macos] User interactions with List do not trigger ItemEvent after programmatic change

Reviewed-by: azvegint

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

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

From prr at openjdk.org  Tue Dec 23 19:57:06 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 23 Dec 2025 19:57:06 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
Message-ID: <2s90cFYDdRCitM5jbG9CnZbIaQRpJM7N0b-Jd7DFXNo=.7857dc55-1cc5-4f4b-894b-ec7ceda0e0be@github.com>

On Mon, 22 Dec 2025 20:34:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Combine fprintf

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3609177036

From prr at openjdk.org  Tue Dec 23 19:57:09 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 23 Dec 2025 19:57:09 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <1VpCU5D8AKiimzA0ZQXoKjKfVp0X1SAUmc0o5PRF01k=.7e44088f-8946-424c-998c-386254c63484@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
 <1VpCU5D8AKiimzA0ZQXoKjKfVp0X1SAUmc0o5PRF01k=.7e44088f-8946-424c-998c-386254c63484@github.com>
Message-ID: <spX3_yH-Ry9QhHoPc7GQWlt4DYVx7HkqqDUHZREqxZY=.56212e6f-40c3-488b-bc82-bafaa3994c35@github.com>

On Tue, 23 Dec 2025 17:22:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Combine fprintf
>
> src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 100:
> 
>> 98:     vsnprintf(tmpbuf, sizeof(tmpbuf), msg, argprt);
>> 99: 
>> 100:     fprintf(logfile, "%s\n", tmpbuf);
> 
> Why can't we use [`fputs`](https://en.cppreference.com/w/c/io/fputs.html) and avoid all the format string logic and ambiguity altogether?
> 
> Alternatively, *use `vfprintf` directly* instead of first formatting the arguments into a temporary buffer with `vsnprintf` and then sending the result to the output.

A similar pattern is used elsewhere in this file. And I don't want this fix to become a reworking of this code, because that isn't a goal here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644143842

From dnguyen at openjdk.org  Tue Dec 23 20:02:11 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 23 Dec 2025 20:02:11 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v3]
In-Reply-To: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
Message-ID: <G9xeSuLEwvx_Mlq7mz_58Z0Ou-67xFogwDWZ787Iv3k=.805a3785-a48a-4dc2-a717-ff41b215d95f@github.com>

> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.

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

  fputs and copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28950/files
  - new: https://git.openjdk.org/jdk/pull/28950/files/7ff146b4..092940fe

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

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

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

From dnguyen at openjdk.org  Tue Dec 23 20:02:12 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 23 Dec 2025 20:02:12 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <spX3_yH-Ry9QhHoPc7GQWlt4DYVx7HkqqDUHZREqxZY=.56212e6f-40c3-488b-bc82-bafaa3994c35@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
 <1VpCU5D8AKiimzA0ZQXoKjKfVp0X1SAUmc0o5PRF01k=.7e44088f-8946-424c-998c-386254c63484@github.com>
 <spX3_yH-Ry9QhHoPc7GQWlt4DYVx7HkqqDUHZREqxZY=.56212e6f-40c3-488b-bc82-bafaa3994c35@github.com>
Message-ID: <SESiXNUFzhoA-4cL-eSUHFOjgNWqIJQXL5ALMrQJ3T4=.08daf7e9-76b3-4aca-9d94-927287d09259@github.com>

On Tue, 23 Dec 2025 19:54:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 100:
>> 
>>> 98:     vsnprintf(tmpbuf, sizeof(tmpbuf), msg, argprt);
>>> 99: 
>>> 100:     fprintf(logfile, "%s\n", tmpbuf);
>> 
>> Why can't we use [`fputs`](https://en.cppreference.com/w/c/io/fputs.html) and avoid all the format string logic and ambiguity altogether?
>> 
>> Alternatively, *use `vfprintf` directly* instead of first formatting the arguments into a temporary buffer with `vsnprintf` and then sending the result to the output.
>
> A similar pattern is used elsewhere in this file. And I don't want this fix to become a reworking of this code, because that isn't a goal here.

After reading about fputs, I think this is best. Like you mentioned, no ambiguity since it does not use specifiers. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644149850

From dnguyen at openjdk.org  Tue Dec 23 20:04:36 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 23 Dec 2025 20:04:36 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v5]
In-Reply-To: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
Message-ID: <tAERLG8NmXyKpdhmqlRqee_auv_WvQR5JZiASvNKRVY=.85c90c82-939a-4c40-9015-4a90349521c1@github.com>

> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28949/files
  - new: https://git.openjdk.org/jdk/pull/28949/files/e17b09aa..2cc83b24

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

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

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

From aivanov at openjdk.org  Tue Dec 23 20:14:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 20:14:53 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <SESiXNUFzhoA-4cL-eSUHFOjgNWqIJQXL5ALMrQJ3T4=.08daf7e9-76b3-4aca-9d94-927287d09259@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
 <1VpCU5D8AKiimzA0ZQXoKjKfVp0X1SAUmc0o5PRF01k=.7e44088f-8946-424c-998c-386254c63484@github.com>
 <spX3_yH-Ry9QhHoPc7GQWlt4DYVx7HkqqDUHZREqxZY=.56212e6f-40c3-488b-bc82-bafaa3994c35@github.com>
 <SESiXNUFzhoA-4cL-eSUHFOjgNWqIJQXL5ALMrQJ3T4=.08daf7e9-76b3-4aca-9d94-927287d09259@github.com>
Message-ID: <tt3eglbvi_eclcOF8iaqdFu2dGlB1L1_yb2DjRRSbtg=.14c31ac7-9a97-40d3-8cd0-a43007e3ca67@github.com>

On Tue, 23 Dec 2025 19:58:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> A similar pattern is used elsewhere in this file. And I don't want this fix to become a reworking of this code, because that isn't a goal here.
>
> After reading about fputs, I think this is best. Like you mentioned, no ambiguity since it does not use specifiers. Updated.

> A similar pattern is used elsewhere in this file. And I don't want this fix to become a reworking of this code, because that isn't a goal here.

Indeed, it is.

I agree it's better to keep the code consistent.

At the same time, I think it's worth submitting a bug to simplify usages like that, `fputs` works perfectly for strings that doesn't require any formatting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644171856

From prr at openjdk.org  Tue Dec 23 20:30:52 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 23 Dec 2025 20:30:52 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v3]
In-Reply-To: <G9xeSuLEwvx_Mlq7mz_58Z0Ou-67xFogwDWZ787Iv3k=.805a3785-a48a-4dc2-a717-ff41b215d95f@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <G9xeSuLEwvx_Mlq7mz_58Z0Ou-67xFogwDWZ787Iv3k=.805a3785-a48a-4dc2-a717-ff41b215d95f@github.com>
Message-ID: <IDL8g5UyPdCXq3Rf60nHvJFDDZs_IWtDseQDync2igQ=.7123b6c0-640b-4565-aa67-140e73404613@github.com>

On Tue, 23 Dec 2025 20:02:11 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fputs and copyright

Marked as reviewed by prr (Reviewer).

wait where's the \n gone ?

Changes requested by prr (Reviewer).

src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 100:

> 98:     vsnprintf(tmpbuf, sizeof(tmpbuf), msg, argprt);
> 99: 
> 100:     fputs(tmpbuf, logfile);

unless I'm missing something you'd need to add a 2nd fputs for the newline or go back to fprintf like before the latest comment.

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

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3609240326
Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3609242082
PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3609251549
PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644198603

From aivanov at openjdk.org  Tue Dec 23 20:30:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 20:30:53 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v3]
In-Reply-To: <G9xeSuLEwvx_Mlq7mz_58Z0Ou-67xFogwDWZ787Iv3k=.805a3785-a48a-4dc2-a717-ff41b215d95f@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <G9xeSuLEwvx_Mlq7mz_58Z0Ou-67xFogwDWZ787Iv3k=.805a3785-a48a-4dc2-a717-ff41b215d95f@github.com>
Message-ID: <39bxoG3HSpug5r0GJELF-hLDyk7MLG_nc4VvUHX1I74=.1ec0a38d-bff8-4edd-87c1-ba2d6dbc0df6@github.com>

On Tue, 23 Dec 2025 20:02:11 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fputs and copyright

Changes requested by aivanov (Reviewer).

src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 100:

> 98:     vsnprintf(tmpbuf, sizeof(tmpbuf), msg, argprt);
> 99: 
> 100:     fputs(tmpbuf, logfile);

Since `fputs` doesn't add a line break automatically, you have to add it explicitly.


    fputs(tmpbuf, logfile);
    fputs("\n", logfile);

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

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3609245483
PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644193662

From prr at openjdk.org  Tue Dec 23 20:30:56 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 23 Dec 2025 20:30:56 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v2]
In-Reply-To: <tt3eglbvi_eclcOF8iaqdFu2dGlB1L1_yb2DjRRSbtg=.14c31ac7-9a97-40d3-8cd0-a43007e3ca67@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <3AOoXcjhaA4FSTUrWhWDyS5wS2rHFeQa9DeQmxCcbrA=.ca6ab357-01fc-4711-a90f-82a3e1117c5d@github.com>
 <1VpCU5D8AKiimzA0ZQXoKjKfVp0X1SAUmc0o5PRF01k=.7e44088f-8946-424c-998c-386254c63484@github.com>
 <spX3_yH-Ry9QhHoPc7GQWlt4DYVx7HkqqDUHZREqxZY=.56212e6f-40c3-488b-bc82-bafaa3994c35@github.com>
 <SESiXNUFzhoA-4cL-eSUHFOjgNWqIJQXL5ALMrQJ3T4=.08daf7e9-76b3-4aca-9d94-927287d09259@github.com>
 <tt3eglbvi_eclcOF8iaqdFu2dGlB1L1_yb2DjRRSbtg=.14c31ac7-9a97-40d3-8cd0-a43007e3ca67@github.com>
Message-ID: <DEgSCJhWXAwHrwgJuaMSrAVUhTd8pweNVyLJ7pLmSMQ=.864fe625-5ac1-4545-8202-228de8cdc20f@github.com>

On Tue, 23 Dec 2025 20:10:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> After reading about fputs, I think this is best. Like you mentioned, no ambiguity since it does not use specifiers. Updated.
>
>> A similar pattern is used elsewhere in this file. And I don't want this fix to become a reworking of this code, because that isn't a goal here.
> 
> Indeed, it is.
> 
> I agree it's better to keep the code consistent.
> 
> At the same time, I think it's worth submitting a bug to simplify usages like that, `fputs` works perfectly for strings that don't require formatting.

Since Damon already made the change and its just one line I'm fine to keep it but not go looking for more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644188965

From aivanov at openjdk.org  Tue Dec 23 20:35:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 20:35:57 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v5]
In-Reply-To: <tAERLG8NmXyKpdhmqlRqee_auv_WvQR5JZiASvNKRVY=.85c90c82-939a-4c40-9015-4a90349521c1@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <tAERLG8NmXyKpdhmqlRqee_auv_WvQR5JZiASvNKRVY=.85c90c82-939a-4c40-9015-4a90349521c1@github.com>
Message-ID: <b11GAony74baezyHVbeuhjx1mqXoL79uiZbBo5XttgA=.093f08e1-b557-47a6-9d5d-0939f8923b0a@github.com>

On Tue, 23 Dec 2025 20:04:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28949#pullrequestreview-3609265295

From aivanov at openjdk.org  Tue Dec 23 20:35:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 20:35:59 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v2]
In-Reply-To: <Yps7xqVD3-Gp9kgra8pxq_1lvYOapfhqyp2R0o5Cisw=.77642bbf-c775-4e10-b06b-1af88238283a@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <Q3TDDxXmL_DTp3E6dAV_nne_7-8wwNKZ9nKj9UtXHjI=.d95b05d9-554f-44b2-8eaf-1be8b65ac79a@github.com>
 <YNEwAy7sOc291SAlE9XgM4OlkDnO1FOzN_NhMkahDeQ=.52d859be-c371-49f9-ae9b-3955bf5d5f28@github.com>
 <Y2O2WJfh5xolapUM-8bZx2DrSx3BuTNe1-HihqF14P8=.14ef6d08-607a-497b-b58e-c76f647eef2e@github.com>
 <TmjeU4yXdWqWZMgUTqLfwvF5fEsZW0Ouk23YTaRe1ps=.ff694569-44a9-4a49-b5b3-4532d67a02ac@github.com>
 <7xNOIYABaZvWqNy8LfzChQKMejENC121yinBCVsAL4U=.6b17d297-9c3e-4bef-a57f-d9015772f9b3@github.com>
 <Yps7xqVD3-Gp9kgra8pxq_1lvYOapfhqyp2R0o5Cisw=.77642bbf-c775-4e10-b06b-1af88238283a@github.com>
Message-ID: <7BwKFP8hF4rJ-3ZVVxuTpiduYu3GjWflcswnp5yCkCs=.08aab2c8-305c-42ba-8891-d2e15d52002e@github.com>

On Tue, 23 Dec 2025 17:15:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> OK fair enough.
>
> Why can't we use [`fputs`](https://en.cppreference.com/w/c/io/fputs.html)?
> 
> 
>                 fputs("assistive_technologies=com.sun.java.accessibility.AccessBridge\n"
>                       "screen_magnifier_present=true\n",
>                       origFile);
> 
> No format strings avoid any possible ambiguity and it's much faster as the string is output verbatim without any additional logic to parse a format string and to process the arguments.

I guess [the same comment](https://github.com/openjdk/jdk/pull/28950#discussion_r2644143842) applies here:

> A similar pattern is used elsewhere in this file. And I don't want this fix to become a reworking of this code, because that isn't a goal here.

Thus, `fprintf` is fine.

Similarly, it could be worth cleaning up the code to simplify the logic by not using *formatted output* where it's not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28949#discussion_r2644209140

From dnguyen at openjdk.org  Tue Dec 23 20:40:21 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 23 Dec 2025 20:40:21 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v4]
In-Reply-To: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
Message-ID: <hemznILeymBnT5ftya_jtqWZ1EljlA7fcK85PzZY84w=.dcebb785-7e2d-48f9-acc8-541083ab58e7@github.com>

> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.

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

  fprintf with newline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28950/files
  - new: https://git.openjdk.org/jdk/pull/28950/files/092940fe..90396f2b

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

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

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

From aivanov at openjdk.org  Tue Dec 23 20:40:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 20:40:22 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v4]
In-Reply-To: <hemznILeymBnT5ftya_jtqWZ1EljlA7fcK85PzZY84w=.dcebb785-7e2d-48f9-acc8-541083ab58e7@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <hemznILeymBnT5ftya_jtqWZ1EljlA7fcK85PzZY84w=.dcebb785-7e2d-48f9-acc8-541083ab58e7@github.com>
Message-ID: <52ORF2wW8gYxpha_YIWOU2ZAvxkOhEa3Xj9xej3rB60=.d6158bd3-bb0b-4a91-960c-f6b44433ca64@github.com>

On Tue, 23 Dec 2025 20:37:02 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fprintf with newline

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3609268795

From dnguyen at openjdk.org  Tue Dec 23 20:40:24 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 23 Dec 2025 20:40:24 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v3]
In-Reply-To: <IDL8g5UyPdCXq3Rf60nHvJFDDZs_IWtDseQDync2igQ=.7123b6c0-640b-4565-aa67-140e73404613@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <G9xeSuLEwvx_Mlq7mz_58Z0Ou-67xFogwDWZ787Iv3k=.805a3785-a48a-4dc2-a717-ff41b215d95f@github.com>
 <IDL8g5UyPdCXq3Rf60nHvJFDDZs_IWtDseQDync2igQ=.7123b6c0-640b-4565-aa67-140e73404613@github.com>
Message-ID: <WR-QPp1VK8WYwjyw8N4NDPWKUxWE0fxfcztqEIogBco=.970d4c70-66f6-4fac-9822-5cfdab7b67da@github.com>

On Tue, 23 Dec 2025 20:26:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fputs and copyright
>
> src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 100:
> 
>> 98:     vsnprintf(tmpbuf, sizeof(tmpbuf), msg, argprt);
>> 99: 
>> 100:     fputs(tmpbuf, logfile);
> 
> unless I'm missing something you'd need to add a 2nd fputs for the newline or go back to fprintf like before the latest comment.

I have gone back to `fprintf` for consistency as you mentioned above. Newline is included. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644208484

From dnguyen at openjdk.org  Tue Dec 23 20:40:27 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 23 Dec 2025 20:40:27 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v3]
In-Reply-To: <39bxoG3HSpug5r0GJELF-hLDyk7MLG_nc4VvUHX1I74=.1ec0a38d-bff8-4edd-87c1-ba2d6dbc0df6@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <G9xeSuLEwvx_Mlq7mz_58Z0Ou-67xFogwDWZ787Iv3k=.805a3785-a48a-4dc2-a717-ff41b215d95f@github.com>
 <39bxoG3HSpug5r0GJELF-hLDyk7MLG_nc4VvUHX1I74=.1ec0a38d-bff8-4edd-87c1-ba2d6dbc0df6@github.com>
Message-ID: <Ywxxq_TZ-sX5bJ0qh1U2DOR-gFlx4ZfR_xrEPL_oMMI=.e57a33c8-3250-4fb0-bd34-b134e09c79ac@github.com>

On Tue, 23 Dec 2025 20:23:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fputs and copyright
>
> src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp line 100:
> 
>> 98:     vsnprintf(tmpbuf, sizeof(tmpbuf), msg, argprt);
>> 99: 
>> 100:     fputs(tmpbuf, logfile);
> 
> Since `fputs` doesn't add a line break automatically, you have to add it explicitly.
> 
> 
>     fputs(tmpbuf, logfile);
>     fputs("\n", logfile);

Thanks for catching this too!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28950#discussion_r2644208958

From aivanov at openjdk.org  Tue Dec 23 20:55:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 20:55:29 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v20]
In-Reply-To: <ao-B6Iw7YEHu8en61oqXqxlG7QQWz02wxJuQQQ8SqSc=.ee552bfa-fa15-43b7-b589-4264775dd732@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <ao-B6Iw7YEHu8en61oqXqxlG7QQWz02wxJuQQQ8SqSc=.ee552bfa-fa15-43b7-b589-4264775dd732@github.com>
Message-ID: <42GjYBfTGWi40wsVVHrzggZNp0HaD9oKmRMVyzJMdAI=.51f19a43-9500-43a6-beef-004354ae335d@github.com>

On Wed, 17 Dec 2025 10:56:23 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:
> 
>   Fixes minor conflict origin compilation issue

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 189:

> 187:             } catch (InterruptedException e) {
> 188:                 throw new RuntimeException(e);
> 189:             }

This indented block is exact duplicate of the block above.

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

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

From aivanov at openjdk.org  Tue Dec 23 20:59:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Dec 2025 20:59:03 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v20]
In-Reply-To: <ao-B6Iw7YEHu8en61oqXqxlG7QQWz02wxJuQQQ8SqSc=.ee552bfa-fa15-43b7-b589-4264775dd732@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <ao-B6Iw7YEHu8en61oqXqxlG7QQWz02wxJuQQQ8SqSc=.ee552bfa-fa15-43b7-b589-4264775dd732@github.com>
Message-ID: <EAb1eY3g0aPtPGEagBVWx3Jpey10x10SoWv_AFoV6iY=.5883957e-2026-434b-8e70-4e71a03e690e@github.com>

On Wed, 17 Dec 2025 10:56:23 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:
> 
>   Fixes minor conflict origin compilation issue

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

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

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

From prr at openjdk.org  Tue Dec 23 21:33:53 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 23 Dec 2025 21:33:53 GMT
Subject: RFR: 8373475: Unintentional format string in logString of
 AccessInfo.cpp [v4]
In-Reply-To: <hemznILeymBnT5ftya_jtqWZ1EljlA7fcK85PzZY84w=.dcebb785-7e2d-48f9-acc8-541083ab58e7@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
 <hemznILeymBnT5ftya_jtqWZ1EljlA7fcK85PzZY84w=.dcebb785-7e2d-48f9-acc8-541083ab58e7@github.com>
Message-ID: <a2AeblnZiBPp-ZZpe5uuJEIfKYl-reMVazmyCPpc41I=.4aec11d7-a98d-42ce-813f-470b45f82f4a@github.com>

On Tue, 23 Dec 2025 20:40:21 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fprintf with newline

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28950#pullrequestreview-3609391501

From prr at openjdk.org  Tue Dec 23 22:36:52 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 23 Dec 2025 22:36:52 GMT
Subject: RFR: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp [v5]
In-Reply-To: <tAERLG8NmXyKpdhmqlRqee_auv_WvQR5JZiASvNKRVY=.85c90c82-939a-4c40-9015-4a90349521c1@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
 <tAERLG8NmXyKpdhmqlRqee_auv_WvQR5JZiASvNKRVY=.85c90c82-939a-4c40-9015-4a90349521c1@github.com>
Message-ID: <kLe0vamdlEGuDQhUaFvf-h0bxhQk16_DAuphNJnD_Uo=.57d4d929-6e71-4a26-bf64-1f272919f532@github.com>

On Tue, 23 Dec 2025 20:04:36 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28949#pullrequestreview-3609491776

From serb at openjdk.org  Tue Dec 23 23:46:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 23 Dec 2025 23:46:20 GMT
Subject: RFR: 8374310: Update copyright year to 2025 for client-libs in files
 where it was missed
Message-ID: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>

The copyright year in client-area files updated in 2025 has been bumped to 2025.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
`

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

Commit messages:
 - 8374310: Update copyright year to 2025 for client-libs in files where it was missed

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

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

From dnguyen at openjdk.org  Wed Dec 24 00:08:15 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 24 Dec 2025 00:08:15 GMT
Subject: Integrated: 8373475: Unintentional format string in logString of
 AccessInfo.cpp
In-Reply-To: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
References: <-gJZLL6uiHpwo43ddCJKd1AGjkSqXoab-T01fxNnN5Q=.37c6d871-d9ec-4056-a56b-d2cd839f93bf@github.com>
Message-ID: <ilIs2buu57Hzv5c1DN4ZtKJlZ7bfRAzoKtPA1LaMXZ4=.a38346a9-69af-423f-b92a-07a4448080af@github.com>

On Mon, 22 Dec 2025 05:30:11 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This update is to fix the potential issue where tmpbuf can be read as a format argument for `fprintf`. I have added a specifier here to avoid this issue since the string from tmpbuf is not guaranteed to not cause issues. This update should make this print more reliable and safe to use.

This pull request has now been integrated.

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

8373475: Unintentional format string in logString of AccessInfo.cpp

Reviewed-by: aivanov, prr, azvegint

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

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

From dnguyen at openjdk.org  Wed Dec 24 00:08:15 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 24 Dec 2025 00:08:15 GMT
Subject: Integrated: 8373474: 2 Unintentional format string defect groups in
 jabswitch.cpp
In-Reply-To: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
References: <0AqdL_6JFx54qLNSeVvO19rX7Ir12C1anx9rwEAQNg8=.9385bc18-1fad-4799-a2cd-856eae72aa45@github.com>
Message-ID: <GgCZwUylW8f4DxwgRlZ9vRJkxDGPRX1pHdefmWoGAGs=.f7be6fd3-194a-4fd4-b159-9b60a8e79c4c@github.com>

On Mon, 22 Dec 2025 05:18:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is not currently causing any problems, but I am adding specifiers to explicitly print these strings. This is to avoid any issues down the line where changes to the lines building the string can cause any accidental formatting. Overall, this should be a harmless update and improves the stability and reliability of printing these strings.

This pull request has now been integrated.

Changeset: 72e1e157
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72e1e15779c3d7846f267c0dfd98191b99a55548
Stats:     9 lines in 1 file changed: 0 ins; 0 del; 9 mod

8373474: 2 Unintentional format string defect groups in jabswitch.cpp

Reviewed-by: aivanov, prr, azvegint

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

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

From dnguyen at openjdk.org  Wed Dec 24 01:53:07 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 24 Dec 2025 01:53:07 GMT
Subject: RFR: 8373847: Test
 javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test
 case automatically fails when clicking any items in the
 =?UTF-8?B?4oCcTm90aGluZ+KAnQ==?= menu in all four windows (Left-to-right)-Menu
 Item Test and (Right-to-left)-Menu Item Test
In-Reply-To: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com>
References: <8vHbWPbMWKh65Jn3GJkBum39hNQYmedfV7AbtVojmAw=.0ba484fa-2762-44a7-93c0-6dca2a7211c3@github.com>
Message-ID: <RP5huj1EDp6H6lu_-VwAL8h8atOYmiT7YY3nI7FgKPc=.396a748a-a067-44e8-ba0c-6f7296d0de9d@github.com>

On Thu, 18 Dec 2025 03:32:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When user selects any menu item from "No nothing". the following exception happens because PassFailJFrame logArea is not created
> 
> java.lang.NullPointerException: Cannot invoke "javax.swing.JTextArea.append(String)" because "PassFailJFrame.logArea" is null
> at PassFailJFrame.lambda$log$0(PassFailJFrame.java:1353)
> at PassFailJFrame.invokeOnEDT(PassFailJFrame.java:570)
> at PassFailJFrame.invokeOnEDTUncheckedException(PassFailJFrame.java:584)
> at PassFailJFrame.log(PassFailJFrame.java:1353)
> at MenuItemTestHelper.lambda$createNoNothingMenu$0(MenuItemTestHelper.java:118) 
> 
> 
> Fix is to create log area

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28887#pullrequestreview-3609702749

From dnguyen at openjdk.org  Wed Dec 24 01:54:53 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 24 Dec 2025 01:54:53 GMT
Subject: RFR: 8373650: Test
 javax/swing/JMenuItem/6458123/ManualBug6458123.java fails because the check
 icons are not aligned properly as expected
In-Reply-To: <GpSv6WiinB_ZK1A4HFSP_fpcdDjGn8KHr_JQyenQhbM=.400739ab-9e6b-4a2c-945d-76440dd04831@github.com>
References: <GpSv6WiinB_ZK1A4HFSP_fpcdDjGn8KHr_JQyenQhbM=.400739ab-9e6b-4a2c-945d-76440dd04831@github.com>
Message-ID: <EHw7jBQCqAq6YfpRalYPiitINXHLB5xpDJmJ3X4fep8=.436e5157-bff5-4eac-bdb5-7d8a16910268@github.com>

On Thu, 18 Dec 2025 07:34:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Check/radiobutton icon are not aligned properly in RTL. `WindowsMenuItemUI `uses `MenuItemLayoutHelper.layoutMenuItem` to do the layout which calls `doRTLColumnLayout `which calculates x positions in `calcXPositionsRTL `and then again aligns in `alignRects`. However, since in Windows historically radiobutton/check icon was not drawn or drawn below the menuitem image icon (since image icon and check icon was drawn in the same layout space and not separately) the aligned x position of check icons returned from `MenuItemLayoutHelper` was not correct but since `MenuItemLayoutHelper` alignment is used in other L&Fs also so we need to realign it in windows specific class i.e in WindowsIconFactory in paintIcon
> 
> Before fix
> 
> <img width="425" height="646" alt="image" src="https://github.com/user-attachments/assets/6aac649d-b099-4e11-ba9a-83c623034287" />
> 
> After fix
> 
> <img width="430" height="641" alt="image" src="https://github.com/user-attachments/assets/e0ea7e3e-d6cb-44a6-aa4f-78435f85d6fb" />

Any reason why the "After fix" image also has the "Radio button" dot misaligned still?

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

PR Review: https://git.openjdk.org/jdk/pull/28889#pullrequestreview-3609707091

From wanghaomin at openjdk.org  Wed Dec 24 03:11:26 2025
From: wanghaomin at openjdk.org (Wang Haomin)
Date: Wed, 24 Dec 2025 03:11:26 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
Message-ID: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>

A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
The problem has been solved after the following modifications.


diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
index f273065a6df..b76cb8dc4e3 100644
--- a/make/modules/java.desktop/lib/ClientLibraries.gmk
+++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
@@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
 
   ifeq ($(USE_EXTERNAL_LIBPNG), false)
     LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
-    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
+    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
       -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
 
     ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

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

Commit messages:
 - 8374321: Fix undefined reference to 'png_init_filter_functions_lsx' after 8371914

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

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

From jiefu at openjdk.org  Wed Dec 24 03:26:51 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 24 Dec 2025 03:26:51 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <32hT7VKpjFIjwEqKBty4ElfTfCZcVVVppAWqwj5Qe9s=.f8777ddb-adc0-4d19-9fa4-c2e2217e0da5@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

Looks reasonable to me.

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28974#pullrequestreview-3609817701

From duke at openjdk.org  Wed Dec 24 03:45:50 2025
From: duke at openjdk.org (duke)
Date: Wed, 24 Dec 2025 03:45:50 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <r_zz7ZhBzbgcpnNK6wHDLm4rDBo2c5eSSU343U3X3LQ=.879558bb-629a-4019-ac3a-c4d056ed1dbe@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

@haominw 
Your change (at version 2955304378524f5520fc746b48d8bd5fd2db7afb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28974#issuecomment-3688564845

From wanghaomin at openjdk.org  Wed Dec 24 03:49:03 2025
From: wanghaomin at openjdk.org (Wang Haomin)
Date: Wed, 24 Dec 2025 03:49:03 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <32hT7VKpjFIjwEqKBty4ElfTfCZcVVVppAWqwj5Qe9s=.f8777ddb-adc0-4d19-9fa4-c2e2217e0da5@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
 <32hT7VKpjFIjwEqKBty4ElfTfCZcVVVppAWqwj5Qe9s=.f8777ddb-adc0-4d19-9fa4-c2e2217e0da5@github.com>
Message-ID: <MFckTGAi7cj7Rkoe_okVqUHeVan_8k3h6iH3-S60rBs=.abe16378-74a2-4002-be1a-aaab61eed336@github.com>

On Wed, 24 Dec 2025 03:22:42 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
>> The problem has been solved after the following modifications.
>> 
>> 
>> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
>> index f273065a6df..b76cb8dc4e3 100644
>> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
>> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
>> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>>  
>>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
>> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
>> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>>  
>>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)
>
> Looks reasonable to me.

@DamonFool Thanks. Jiege, Could you sponsor it?

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

PR Comment: https://git.openjdk.org/jdk/pull/28974#issuecomment-3688568599

From serb at openjdk.org  Wed Dec 24 04:10:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 04:10:49 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <xPSNBOIAjRAEeeRdx0cdtgnXumUisrOZJ3S-NWBahN4=.f4c9b28c-54dd-41b5-9495-6742385a267c@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

Please wait until GA completion.

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

PR Comment: https://git.openjdk.org/jdk/pull/28974#issuecomment-3688597513

From jdv at openjdk.org  Wed Dec 24 07:30:52 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 24 Dec 2025 07:30:52 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <mVIBummFpDYaJPpXg2vFfRXpmikhuNzGGLRivLmbJd0=.f19c98c3-79ce-484d-9c2f-429d35cc5d2f@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

Please re-submit failing github actions.

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

PR Comment: https://git.openjdk.org/jdk/pull/28974#issuecomment-3688935712

From jdv at openjdk.org  Wed Dec 24 07:34:51 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 24 Dec 2025 07:34:51 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <0tz8ugEfxyNR5yRFhFSd4bqNpvV5eEIWggRo1o-LwCo=.d9a59965-0bd8-4f76-8f36-6d07dbaa278b@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

I am checking for our CI builds with this change. Once they are green will approve.

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

PR Comment: https://git.openjdk.org/jdk/pull/28974#issuecomment-3688941185

From serb at openjdk.org  Wed Dec 24 07:34:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 07:34:52 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <f7aYzq06vmtHqnw5f-aDDNBFA5NP6ZUI9MnbAi3nU-M=.73c22935-2d52-4af1-a913-6879c0769e4c@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

linux-x64 seems a common issue right now across all PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/28974#issuecomment-3688943845

From jdv at openjdk.org  Wed Dec 24 08:31:00 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 24 Dec 2025 08:31:00 GMT
Subject: RFR: 8374310: Update copyright year to 2025 for client-libs in
 files where it was missed
In-Reply-To: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
References: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
Message-ID: <yoD7DIfGGzKhyS6B6RrPYG5jmlziZ5nIUmuSEIyE3iQ=.1997dd66-2eac-4c4e-ad7e-a984feed9ade@github.com>

On Tue, 23 Dec 2025 22:47:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in client-area files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
> `

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28969#pullrequestreview-3610289018

From jdv at openjdk.org  Wed Dec 24 09:00:55 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 24 Dec 2025 09:00:55 GMT
Subject: RFR: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <LmMRvMCdCcdGFrLorAIFBT9NUx9K5U1NFnZ3jqWcR9M=.a277b53e-2c6c-47c7-89fb-05718c0d0deb@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28974#pullrequestreview-3610365967

From wanghaomin at openjdk.org  Wed Dec 24 09:10:03 2025
From: wanghaomin at openjdk.org (Wang Haomin)
Date: Wed, 24 Dec 2025 09:10:03 GMT
Subject: Integrated: 8374321: Fix undefined reference to
 'png_init_filter_functions_lsx' after 8371914
In-Reply-To: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
References: <mtPkJZbrwwq3LgE02Kfsxr8DydmYXqcTtUU5rX36t0I=.b2d989fd-e9a9-46f8-82a5-5ad9222ba380@github.com>
Message-ID: <117i6ma91H4iPePuvWH_1PedttVWRd7Nup72L7HGFUA=.2a2fdabc-6792-4c5f-921d-b6ee8d91322a@github.com>

On Wed, 24 Dec 2025 03:03:13 GMT, Wang Haomin <wanghaomin at openjdk.org> wrote:

> A simple mistake caused `undefined reference to 'png_init_filter_functions_lsx'`.
> The problem has been solved after the following modifications.
> 
> 
> diff --git a/make/modules/java.desktop/lib/ClientLibraries.gmk b/make/modules/java.desktop/lib/ClientLibraries.gmk
> index f273065a6df..b76cb8dc4e3 100644
> --- a/make/modules/java.desktop/lib/ClientLibraries.gmk
> +++ b/make/modules/java.desktop/lib/ClientLibraries.gmk
> @@ -164,7 +164,7 @@ ifeq ($(ENABLE_HEADLESS_ONLY), false)
>  
>    ifeq ($(USE_EXTERNAL_LIBPNG), false)
>      LIBSPLASHSCREEN_HEADER_DIRS += libsplashscreen/libpng
> -    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0
> +    LIBSPLASHSCREEN_CFLAGS += -DPNG_NO_MMX_CODE -DPNG_ARM_NEON_OPT=0 \
>        -DPNG_ARM_NEON_IMPLEMENTATION=0 -DPNG_LOONGARCH_LSX_OPT=0
>  
>      ifeq ($(call isTargetOs, linux)+$(call isTargetCpuArch, ppc), true+true)

This pull request has now been integrated.

Changeset: 4a0f7e42
Author:    Wang Haomin <wanghaomin at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a0f7e4294d2ccc2d2bf460bea87b342fe934d03
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8374321: Fix undefined reference to 'png_init_filter_functions_lsx' after 8371914

Reviewed-by: jiefu, jdv

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

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

From dgredler at openjdk.org  Wed Dec 24 12:26:04 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 24 Dec 2025 12:26:04 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
Message-ID: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>

Instances of FontRenderContext are immutable, but its instance variables are not declared final.

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

Commit messages:
 - Make FontRenderContext instance variables final

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

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

From dgredler at openjdk.org  Wed Dec 24 15:12:51 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 24 Dec 2025 15:12:51 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
In-Reply-To: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
Message-ID: <vrN3SbqOFRgioyjkElsEPGyRy1qLVBhCE4te8tgCiqU=.9421e471-c43e-45e6-bc7f-ade413e7f6e3@github.com>

On Wed, 24 Dec 2025 12:17:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Instances of FontRenderContext are immutable, but its instance variables are not declared final.

Note: I'm not sure why these instance variables are marked `transient`, since `FontRenderContext` is not serializable. I've left it as-is, but if reviewers want `transient` removed, just let me know.

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

PR Comment: https://git.openjdk.org/jdk/pull/28981#issuecomment-3690055409

From aivanov at openjdk.org  Wed Dec 24 16:33:18 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 24 Dec 2025 16:33:18 GMT
Subject: RFR: 8374310: Update copyright year to 2025 for client-libs in
 files where it was missed
In-Reply-To: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
References: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
Message-ID: <01H0rRIxetr3wciX_EjSows7a0tPIRV6Y1pNUAdwr5E=.65aa9657-d2de-4f8c-a0e2-c0747efd6fc1@github.com>

On Tue, 23 Dec 2025 22:47:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in client-area files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
> `

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28969#pullrequestreview-3611328977

From aivanov at openjdk.org  Wed Dec 24 16:45:25 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 24 Dec 2025 16:45:25 GMT
Subject: RFR: 8374345: Restore the original copyright year in
 ExtremeFontSizeTest.java
Message-ID: <354mBPdrDe7rq4tf6q_GadyIMpboM99CS9_RcHL0_9s=.6b1f7fc2-80c5-469b-ae8a-e12af4dc60f2@github.com>

The copyright year in `test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java` was replaced from 2024 to 2025 instead of adding 2025 by [JDK-8357672](https://bugs.openjdk.org/browse/JDK-8357672).

Restore the original year in the copyright header.

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

Commit messages:
 - 8374345: Restore the original copyright year in ExtremeFontSizeTest.java

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

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

From prr at openjdk.org  Wed Dec 24 20:56:49 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 24 Dec 2025 20:56:49 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
In-Reply-To: <vrN3SbqOFRgioyjkElsEPGyRy1qLVBhCE4te8tgCiqU=.9421e471-c43e-45e6-bc7f-ade413e7f6e3@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
 <vrN3SbqOFRgioyjkElsEPGyRy1qLVBhCE4te8tgCiqU=.9421e471-c43e-45e6-bc7f-ade413e7f6e3@github.com>
Message-ID: <RTCiG0KV9J4NNkMti0S3rtaZeLWuwJknzbZXJTbXF_E=.646b0ed5-bbb0-45dd-b346-663dc277b86f@github.com>

On Wed, 24 Dec 2025 15:09:02 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Note: I'm not sure why these instance variables are marked `transient`, since `FontRenderContext` is not serializable. I've left it as-is, but if reviewers want `transient` removed, just let me know.

I noticed that when I looked yesterday. The only thing I could think of is that since the class is subclassable, it purposefully prevents anyone from creating a serializable subclass reliant on the superclass.
I'd prefer to leave it, as some investigation would be prudent and it really doesn't matter.

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

PR Comment: https://git.openjdk.org/jdk/pull/28981#issuecomment-3690484362

From prr at openjdk.org  Wed Dec 24 20:56:51 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 24 Dec 2025 20:56:51 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
In-Reply-To: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
Message-ID: <51Az60Y_4T-Asl7elxwjf62l4N1pNUuhKN9kfs06qYQ=.cf5ca108-f830-47ce-9237-17fa818bd892@github.com>

On Wed, 24 Dec 2025 12:17:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Instances of FontRenderContext are immutable, but its instance variables are not declared final.

The patch looks a lot like what I did yesterday so I expect it'll be fine but I'm going to run our tests before approving.

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

PR Comment: https://git.openjdk.org/jdk/pull/28981#issuecomment-3690485600

From prr at openjdk.org  Thu Dec 25 00:02:59 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Dec 2025 00:02:59 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
In-Reply-To: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
Message-ID: <UxCOrW7AispaGvmf12nFWsoO3Y7tOeUxgFLBKkJKdNY=.49a15ba1-a4cb-4f86-80ce-537ae3bc5ad9@github.com>

On Wed, 24 Dec 2025 12:17:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Instances of FontRenderContext are immutable, but its instance variables are not declared final.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28981#pullrequestreview-3611679926

From serb at openjdk.org  Thu Dec 25 01:29:08 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 01:29:08 GMT
Subject: Integrated: 8374310: Update copyright year to 2025 for client-libs in
 files where it was missed
In-Reply-To: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
References: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
Message-ID: <qUFZkKRYr5XML0dkWvfcOBcrNQLEOsKaYqkPWRW1Shk=.0e821234-aa50-4963-8bbe-4c370afb2e89@github.com>

On Tue, 23 Dec 2025 22:47:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in client-area files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
> `

This pull request has now been integrated.

Changeset: 73a8629c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73a8629c5b52b678febcc9d339e01ebcc5277909
Stats:     565 lines in 565 files changed: 0 ins; 0 del; 565 mod

8374310: Update copyright year to 2025 for client-libs in files where it was missed

Reviewed-by: jdv, aivanov

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

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

From serb at openjdk.org  Thu Dec 25 03:48:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 03:48:54 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
In-Reply-To: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
Message-ID: <iMPnoUv9lHI83yukUoYSfuw2hKGoS9BE0zUJiBMD-V4=.b19f478a-452e-44b1-800e-ca1c6905874b@github.com>

On Wed, 24 Dec 2025 12:17:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Instances of FontRenderContext are immutable, but its instance variables are not declared final.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28981#pullrequestreview-3611803987

From serb at openjdk.org  Thu Dec 25 05:36:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 05:36:49 GMT
Subject: RFR: 8374345: Restore the original copyright year in
 ExtremeFontSizeTest.java
In-Reply-To: <354mBPdrDe7rq4tf6q_GadyIMpboM99CS9_RcHL0_9s=.6b1f7fc2-80c5-469b-ae8a-e12af4dc60f2@github.com>
References: <354mBPdrDe7rq4tf6q_GadyIMpboM99CS9_RcHL0_9s=.6b1f7fc2-80c5-469b-ae8a-e12af4dc60f2@github.com>
Message-ID: <g4xGhYgs34aLqzO6aTSbGxT_E2ypDdYkD61kni0jbuo=.f3ea3359-8bae-4ab0-a749-872a730bda8e@github.com>

On Wed, 24 Dec 2025 16:38:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The copyright year in `test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java` was replaced from 2024 to 2025 instead of adding 2025 by [JDK-8357672](https://bugs.openjdk.org/browse/JDK-8357672).
> 
> Restore the original year in the copyright header.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28983#pullrequestreview-3611870852

From serb at openjdk.org  Thu Dec 25 05:39:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 05:39:03 GMT
Subject: RFR: 6517125: FontStrike.getGlyphVectorOutline() not used
In-Reply-To: <OQ__uIyLLfCzjjgIoayCD6c0gEJ9GKRcHWaDQ0ajSCo=.28b46bea-49f8-4e92-9e0c-7099000af5d9@github.com>
References: <OQ__uIyLLfCzjjgIoayCD6c0gEJ9GKRcHWaDQ0ajSCo=.28b46bea-49f8-4e92-9e0c-7099000af5d9@github.com>
Message-ID: <rnZoYsgtgj50q_2NQ8ar2KbW-wI1SzopRLIaJv8bczE=.34064fd0-1466-4eda-850a-b9d065dae656@github.com>

On Tue, 16 Dec 2025 23:11:19 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> This method is not used and can be deleted from the entire `FontStrike` class hierarchy. There was some discussion in 2007 about re-enabling if there were performance benefits, but 20 years have passed and no performance issues have emerged. In fact, the macOS OpenJDK never implemented this method.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28856#pullrequestreview-3611872693

From syan at openjdk.org  Thu Dec 25 06:35:00 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 25 Dec 2025 06:35:00 GMT
Subject: RFR: 8374345: Restore the original copyright year in
 ExtremeFontSizeTest.java
In-Reply-To: <354mBPdrDe7rq4tf6q_GadyIMpboM99CS9_RcHL0_9s=.6b1f7fc2-80c5-469b-ae8a-e12af4dc60f2@github.com>
References: <354mBPdrDe7rq4tf6q_GadyIMpboM99CS9_RcHL0_9s=.6b1f7fc2-80c5-469b-ae8a-e12af4dc60f2@github.com>
Message-ID: <nF3m7s8Kug7gAwgrMs_ZCYPjMpTlutV5rAWW8TTuNPI=.8be8b370-485e-48df-8b7d-19638cd76189@github.com>

On Wed, 24 Dec 2025 16:38:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The copyright year in `test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java` was replaced from 2024 to 2025 instead of adding 2025 by [JDK-8357672](https://bugs.openjdk.org/browse/JDK-8357672).
> 
> Restore the original year in the copyright header.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28983#pullrequestreview-3611911608

From serb at openjdk.org  Thu Dec 25 08:26:26 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 08:26:26 GMT
Subject: RFR: 8374355: Update copyright year to 2025 for demo in files where it
 was missed
Message-ID: <EepHqhgpPqpQCOOkbIW_1VIl7PNFi8qr_fC7FzmWpiU=.18fe49d5-cd35-4275-a4c3-f55193044efc@github.com>

The copyright year in demo files updated in 2025 has been bumped to 2025.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

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

Commit messages:
 - 8374355: Update copyright year to 2025 for demo in files where it was missed

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

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

From aturbanov at openjdk.org  Thu Dec 25 09:18:54 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 25 Dec 2025 09:18:54 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
In-Reply-To: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
Message-ID: <w8ODH4GP8Ezyf2gSwI5c-ULbxPQReyAzal7ALq6K5WY=.fa5321c0-0daa-4596-90c5-e16651429ebb@github.com>

On Wed, 24 Dec 2025 12:17:47 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Instances of FontRenderContext are immutable, but its instance variables are not declared final.

src/java.desktop/share/classes/java/awt/font/FontRenderContext.java line 66:

> 64: */
> 65: public class FontRenderContext {
> 66:     private transient final AffineTransform tx;

Let's use blessed modifiers order
Suggestion:

    private final transient AffineTransform tx;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28981#discussion_r2646775774

From serb at openjdk.org  Fri Dec 26 03:18:25 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 26 Dec 2025 03:18:25 GMT
Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files
 where it was missed
Message-ID: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>

The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.

**Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

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

Commit messages:
 - 8374365: Update copyright year to 2025 for test/jdk in files where it was missed

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

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

From dgredler at openjdk.org  Fri Dec 26 12:00:10 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 26 Dec 2025 12:00:10 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
 [v2]
In-Reply-To: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
Message-ID: <eVwVNPhv-qaTUgi4x4iysFfIztFG61Tcr4bz9h2v4_g=.d9950402-e644-4542-8851-ca583cec0dda@github.com>

> Instances of FontRenderContext are immutable, but its instance variables are not declared final.

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

  Swap order 'transient final' -> 'final transient'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28981/files
  - new: https://git.openjdk.org/jdk/pull/28981/files/6a54426f..2f279543

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

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

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

From dgredler at openjdk.org  Fri Dec 26 12:00:12 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 26 Dec 2025 12:00:12 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
 [v2]
In-Reply-To: <w8ODH4GP8Ezyf2gSwI5c-ULbxPQReyAzal7ALq6K5WY=.fa5321c0-0daa-4596-90c5-e16651429ebb@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
 <w8ODH4GP8Ezyf2gSwI5c-ULbxPQReyAzal7ALq6K5WY=.fa5321c0-0daa-4596-90c5-e16651429ebb@github.com>
Message-ID: <UOBRjKV5jOs2s0GfhXfaFxLRGTcwTvEGlebafU2cvUE=.242ab7d4-6b40-4b0c-afd5-28e2c6752f6a@github.com>

On Thu, 25 Dec 2025 09:16:09 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Swap order 'transient final' -> 'final transient'
>
> src/java.desktop/share/classes/java/awt/font/FontRenderContext.java line 66:
> 
>> 64: */
>> 65: public class FontRenderContext {
>> 66:     private transient final AffineTransform tx;
> 
> Let's use blessed modifiers order
> Suggestion:
> 
>     private final transient AffineTransform tx;

No problem, I've swapped the order as indicated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28981#discussion_r2648092754

From dgredler at openjdk.org  Fri Dec 26 12:03:10 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 26 Dec 2025 12:03:10 GMT
Subject: Integrated: 6517125: FontStrike.getGlyphVectorOutline() not used
In-Reply-To: <OQ__uIyLLfCzjjgIoayCD6c0gEJ9GKRcHWaDQ0ajSCo=.28b46bea-49f8-4e92-9e0c-7099000af5d9@github.com>
References: <OQ__uIyLLfCzjjgIoayCD6c0gEJ9GKRcHWaDQ0ajSCo=.28b46bea-49f8-4e92-9e0c-7099000af5d9@github.com>
Message-ID: <0NSf0zTf5olUIEOJKm7OinRP0dKdDGP44LrIsTrtW9A=.e95da971-ccf5-48dc-9601-4e13ec1bc1d1@github.com>

On Tue, 16 Dec 2025 23:11:19 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> This method is not used and can be deleted from the entire `FontStrike` class hierarchy. There was some discussion in 2007 about re-enabling if there were performance benefits, but 20 years have passed and no performance issues have emerged. In fact, the macOS OpenJDK never implemented this method.

This pull request has now been integrated.

Changeset: e65ace10
Author:    Daniel Gredler <dgredler at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e65ace10e3c40d6fef4e9997311d88c900e84ced
Stats:     94 lines in 8 files changed: 0 ins; 89 del; 5 mod

6517125: FontStrike.getGlyphVectorOutline() not used

Reviewed-by: prr, serb

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

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

From dgredler at openjdk.org  Fri Dec 26 12:06:52 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 26 Dec 2025 12:06:52 GMT
Subject: RFR: 6562639: Wrong pixel bounds from TextLayout with white font
In-Reply-To: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com>
References: <42XmY3f4QQ9W3we9fR70rzJpwdr0F5_vycMn610NRmw=.0952f2dc-04b1-4eea-88fd-7b3a85ba1118@github.com>
Message-ID: <mjpaEfhv1wxozHGUSlaZZsUNJ8U9Nri3sz3r9pcBtbc=.bfa6cef0-ffbd-4747-9ce2-0b5d113fb011@github.com>

On Sat, 13 Dec 2025 00:33:30 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> One of the possible code paths for `TextLayout.getPixelBounds(...)` actually draws the text on a `Graphics2D` and checks the image pixels afterwards. The text is drawn over a white background, so if the user sets the font's foreground color to white then the text pixels cannot be detected (white on white).
> 
> This PR fixes the issue by removing the code that sets the background to white, leaving the background as the default ARGB color (0 = transparent black). This does not cause a new problem for users who might set their font foreground color to transparent black, because transparent font foreground colors always return an empty bounds anyway (by virtue of being transparent).
> 
> The updated code should also be slightly faster since it's doing less work, though I haven't run any performance tests.

Does anyone have time to provide a second review on this PR before the end of the year? Phil has already verified that all tests pass. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28809#issuecomment-3692772807

From aivanov at openjdk.org  Fri Dec 26 20:09:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 26 Dec 2025 20:09:02 GMT
Subject: RFR: 8374340: FontRenderContext instance variables should be final
 [v2]
In-Reply-To: <eVwVNPhv-qaTUgi4x4iysFfIztFG61Tcr4bz9h2v4_g=.d9950402-e644-4542-8851-ca583cec0dda@github.com>
References: <i3zeNP_N_87DwUl0-jfQAfwnXllEk-n-IgQx9amRMks=.757adc63-240b-4c07-84ec-924b732e0a99@github.com>
 <eVwVNPhv-qaTUgi4x4iysFfIztFG61Tcr4bz9h2v4_g=.d9950402-e644-4542-8851-ca583cec0dda@github.com>
Message-ID: <M3Kjuc9J-fLAyN6YTLCNY_LCG4AH59Vt3tpBFGxRX6Y=.38a33ad1-713f-44a5-8cdf-f802a6521187@github.com>

On Fri, 26 Dec 2025 12:00:10 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> Instances of FontRenderContext are immutable, but its instance variables are not declared final.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap order 'transient final' -> 'final transient'

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28981#pullrequestreview-3613847332

From aivanov at openjdk.org  Fri Dec 26 20:15:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 26 Dec 2025 20:15:03 GMT
Subject: Integrated: 8374345: Restore the original copyright year in
 ExtremeFontSizeTest.java
In-Reply-To: <354mBPdrDe7rq4tf6q_GadyIMpboM99CS9_RcHL0_9s=.6b1f7fc2-80c5-469b-ae8a-e12af4dc60f2@github.com>
References: <354mBPdrDe7rq4tf6q_GadyIMpboM99CS9_RcHL0_9s=.6b1f7fc2-80c5-469b-ae8a-e12af4dc60f2@github.com>
Message-ID: <e0I4ljOgaY3MtOXTe8e5WP0M1wfbic2rXaaTRv7te_0=.d71a2d7a-7286-435e-bf18-634671dbb939@github.com>

On Wed, 24 Dec 2025 16:38:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The copyright year in `test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java` was replaced from 2024 to 2025 instead of adding 2025 by [JDK-8357672](https://bugs.openjdk.org/browse/JDK-8357672).
> 
> Restore the original year in the copyright header.

This pull request has now been integrated.

Changeset: e7f9132e
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7f9132e8992ac281d1e4777a9664d1c8b817f4f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8374345: Restore the original copyright year in ExtremeFontSizeTest.java

Reviewed-by: serb, syan

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

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

From phh at openjdk.org  Fri Dec 26 22:58:54 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 Dec 2025 22:58:54 GMT
Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files
 where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <I5ZJ3nhBTqj0rD4QaUxGPGkj7aymTjxki7HTtFrWCe8=.bd5028e4-e007-4dfe-8374-f2eb986cdc8a@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28997#pullrequestreview-3613936569

From serb at openjdk.org  Sat Dec 27 07:07:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:07:04 GMT
Subject: Integrated: 8374365: Update copyright year to 2025 for test/jdk in
 files where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <OVIzxn5wdIZIwLEH1aV5QOpA42bscvlkBnTJnCGxPcI=.1bf256e0-07ec-44a3-9090-79c3dad941e7@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 9512a43e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9512a43e82652be7294338c11cc9ffb0f0324b92
Stats:     76 lines in 76 files changed: 0 ins; 0 del; 76 mod

8374365: Update copyright year to 2025 for test/jdk in files where it was missed

Reviewed-by: phh

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

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

From serb at openjdk.org  Sat Dec 27 07:30:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:30:59 GMT
Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files
 where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <xzvWxS1jF-8teyOrN4Mwd2J8Ws63QJ524glMUW_wQZg=.2db4c8bb-d713-4dbc-90c4-96fe8128c732@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/28997#issuecomment-3693789137

From sadanki190 at gmail.com  Sat Dec 27 15:11:54 2025
From: sadanki190 at gmail.com (Vignesh Sadanki)
Date: Sat, 27 Dec 2025 20:41:54 +0530
Subject: Request to work on JDK-8263355
Message-ID: <CAKz31GAhSwZ_ZCt7RmELyME0ZrN2gmAYb5pvSQW1CwTp1n4ctw@mail.gmail.com>

Hi everyone,

I'm new to OpenJDK and interested in contributing. I came across bug
JDK-8263355 ("Drag color change appearing at mouse press itself") and would
like to work on it.

Could someone confirm if this bug is available for me to take, and if there
are any guidelines I should follow?

Thanks,
Vignesh Sadankae
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251227/72a10698/attachment.htm>

From sadanki190 at gmail.com  Sat Dec 27 15:53:13 2025
From: sadanki190 at gmail.com (Vignesh Sadanki)
Date: Sat, 27 Dec 2025 21:23:13 +0530
Subject: Request to work on JDK-8374344
Message-ID: <CAKz31GBJ+Q9J7i2Tnuybhp1fXh6nV5gWAfCy9E5eFJ-cs1-C3g@mail.gmail.com>

Hi everyone,

I'm new to OpenJDK and interested in contributing. I came across bug
JDK-8374344 ("Clarifying HttpURLConnection.disconnect() Behavior Regarding
Resource Management and Connection Pooling") and would like to work on it.

Could someone confirm if this bug is available for me to take, and if there
are any guidelines I should follow?

Thanks,
Vignesh Sadankae
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20251227/289d9a28/attachment.htm>

From jwood at openjdk.org  Sun Dec 28 02:29:51 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Sun, 28 Dec 2025 02:29:51 GMT
Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs
Message-ID: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com>

When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time.

This PR uses System.arraycopy instead, and it shows approx a 10% improvement.

This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases:

<img width="596" height="366" alt="Screenshot 2025-12-27 at 9 14 19?PM" src="https://github.com/user-attachments/assets/73583cb2-eda0-47a8-b818-735a1835f1e8" />

(This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.)

I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it.

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

Commit messages:
 - 8374377: Use System.arraycopy when possible

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

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

From dgredler at openjdk.org  Sun Dec 28 17:39:55 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Sun, 28 Dec 2025 17:39:55 GMT
Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs
In-Reply-To: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com>
References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com>
Message-ID: <UQc0mTl37L0W6LY51frclCmIl8hTmce5HSgrUFzJ2H8=.e273f2d6-672c-4137-8a91-badbb46beb74@github.com>

On Sun, 28 Dec 2025 02:22:16 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time.
> 
> This PR uses System.arraycopy instead, and it shows approx a 10% improvement.
> 
> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases:
> 
> <img width="596" height="366" alt="Screenshot 2025-12-27 at 9 14 19?PM" src="https://github.com/user-attachments/assets/73583cb2-eda0-47a8-b818-735a1835f1e8" />
> 
> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.)
> 
> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it.

Do you have a JMH test for the attached graph that can be used to replicate locally? If you've not used JMH before, or haven't used it in the context of OpenJDK, you can check existing performance tests in the `test/micro` directory, or see this example (not part of OpenJDK, just something I've used in the past to test things locally): https://gist.github.com/gredler/e8ff9d52440cd103cd5b7766defff5b8

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

PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3694911088

From jwood at openjdk.org  Mon Dec 29 02:59:04 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Mon, 29 Dec 2025 02:59:04 GMT
Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs [v2]
In-Reply-To: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com>
References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com>
Message-ID: <xUMymDAFNlGwY3whzs-s6orQNxr1u06iFRnZ-vK0cuA=.0d902a2f-383e-4157-ba44-ff74d6828c4c@github.com>

> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time.
> 
> This PR uses System.arraycopy instead, and it shows approx a 10% improvement.
> 
> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases:
> 
> <img width="596" height="366" alt="Screenshot 2025-12-27 at 9 14 19?PM" src="https://github.com/user-attachments/assets/73583cb2-eda0-47a8-b818-735a1835f1e8" />
> 
> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.)
> 
> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it.

Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:

  8374377: Adding a JMH test for PNGImageDecoder
  
  This corroborates previous (more informal) tests that show approx a 10% improvement.
  
  Without this PR I observed this result on my Mac 26.2 laptop:
  
  ```
  Benchmark                                                 Mode  Cnt   Score   Error  Units
  PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder  avgt   15  25.296 ? 0.521  ms/op
  ```
  
  With this PR I observed this result:
  
  ```
  Benchmark                                                 Mode  Cnt   Score   Error  Units
  PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder  avgt   15  22.132 ? 0.378  ms/op
  ```

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29004/files
  - new: https://git.openjdk.org/jdk/pull/29004/files/d58d3609..c91a1f44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29004&range=00-01

  Stats: 188 lines in 1 file changed: 188 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29004/head:pull/29004

PR: https://git.openjdk.org/jdk/pull/29004

From jwood at openjdk.org  Mon Dec 29 03:06:56 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Mon, 29 Dec 2025 03:06:56 GMT
Subject: RFR: 8374377: PNGImageDecoder Slow For 8-bit PNGs
In-Reply-To: <UQc0mTl37L0W6LY51frclCmIl8hTmce5HSgrUFzJ2H8=.e273f2d6-672c-4137-8a91-badbb46beb74@github.com>
References: <7qLKnx6t2y86t7k9fq2LztoGD5CFcyQqOsUHaYaIqT8=.0ae5afb7-fa9d-4436-91fa-8c78cc95a6b6@github.com>
 <UQc0mTl37L0W6LY51frclCmIl8hTmce5HSgrUFzJ2H8=.e273f2d6-672c-4137-8a91-badbb46beb74@github.com>
Message-ID: <2AIzL_iPp4jezrZlYWLpo_rNJM4bhOktsluIQ104zdg=.b1919ccb-471a-4275-bacd-e47c5e05f3d2@github.com>

On Sun, 28 Dec 2025 17:36:51 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> When decoding an uninterlaced 8-bit PNG image, the PNGImageDecoder is basically copying one byte at a time.
>> 
>> This PR uses System.arraycopy instead, and it shows approx a 10% improvement.
>> 
>> This graph shows the time it takes different decoders to convert a byte array into a BufferedImage as the size of the PNG image increases:
>> 
>> <img width="596" height="366" alt="Screenshot 2025-12-27 at 9 14 19?PM" src="https://github.com/user-attachments/assets/73583cb2-eda0-47a8-b818-735a1835f1e8" />
>> 
>> (This originally came to my attention when looking at an image in Java 1.8. There the ImageConsumer model took approx 400% longer than ImageIO. I was happy to see in recent JDKs that gap narrowed significantly, but there was still a noticeable 10% discrepancy.)
>> 
>> I haven't tried submitting a performance enhancement PR before; I'm not sure if this issue meets this group's threshold for being worth addressing. And if it does: I'm not sure how to structure a unit test for it.
>
> Do you have a JMH test for the attached graph that can be used to replicate locally? If you've not used JMH before, or haven't used it in the context of OpenJDK, you can check existing performance tests in the `test/micro` directory, or see this example (not part of OpenJDK, just something I've used in the past to test things locally): https://gist.github.com/gredler/e8ff9d52440cd103cd5b7766defff5b8

@gredler Thanks. I'm not familiar with JMH.

I used your example (and a lot of googling) to set up a basic benchmark that is now attached to this ticket.

For a 2500x2500 px image, the time on my Mac went from approx 25.296 to 22.132.

Is there any interest in me:
A. Creating a graph as the image dimensions change?
B. Contrasting this implementation against ImageIO?

I'm not sure what the long-term usage of this benchmark .java would be. If this PR is accepted: the slower "before" time will be not be relevant to anyone going forward.

And the most important question (IMO): is there enough interest in this group to review/accept this proposal? (If not: I can stop spending time on it.)

## Before this PR

Benchmark                                                 Mode  Cnt   Score   Error  Units
PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder  avgt   15  25.296 ? 0.521  ms/op

## After this PR

Benchmark                                                 Mode  Cnt   Score   Error  Units
PNGImageDecoder_8bit_uninterlaced.measurePNGImageDecoder  avgt   15  22.132 ? 0.378  ms/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29004#issuecomment-3695319015

From duke at openjdk.org  Mon Dec 29 12:05:23 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 12:05:23 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v21]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <ZNGaxLTghNJxugN5mx9jYMsQm44JjJB5Egj6ptI7TrY=.34a2cc0f-504e-4474-acb0-0482ac9561c7@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:

  Removes duplicate code added during merge with master

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/f83159ac..a7900257

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=19-20

  Stats: 12 lines in 1 file changed: 0 ins; 12 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  Mon Dec 29 12:05:25 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 12:05:25 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v20]
In-Reply-To: <EAb1eY3g0aPtPGEagBVWx3Jpey10x10SoWv_AFoV6iY=.5883957e-2026-434b-8e70-4e71a03e690e@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>
Message-ID: <ow7pFpsREldbAOqN3VWqFjQ1HrIC30makGYLut1z93Y=.5a7a23b2-39cd-4979-bed0-60b2a752cc25@github.com>

On Tue, 23 Dec 2025 20:55:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes minor conflict origin compilation issue
>
> 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.

> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 189:
> 
>> 187:             } catch (InterruptedException e) {
>> 188:                 throw new RuntimeException(e);
>> 189:             }
> 
> This indented block is exact duplicate of the block above.

Remved duplicate code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2650824338
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2650819338

From duke at openjdk.org  Mon Dec 29 13:33:24 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 13:33:24 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v22]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <rvtMpziUkxpMMPTMjwTWzIn65S4f8_BYmsbA5u3yfvI=.aa0b2edd-04af-4814-a5b9-0d2d0af316db@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:

  Apply suggestion from @aivanov-jdk
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/a7900257..3e9019b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=20-21

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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  Mon Dec 29 13:56:47 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 13:56:47 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v23]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <keW__-UZEHhgreeiqAFt_4lr5XIrYjDbXTilPY8kB60=.c7a11308-1f4a-4173-9000-a91f1220fd4e@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 six additional commits since the last revision:

 - Removes previously added white line
 - Changes color names to uppercase
 - Removes duplicated lines
 - Removes extra line
 - Reverts a change which caused dead code
 - Updated imports and groups exceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/3e9019b1..506b6839

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=21-22

  Stats: 20 lines in 5 files changed: 0 ins; 16 del; 4 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  Mon Dec 29 14:20:39 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 14:20:39 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v24]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <P4WlJy7m1E8jSSh70Wq_nQM0F-DuJeiMXhfvgkOC6aU=.92095dfc-a6cb-4146-a4fe-afcb4961ed46@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:

 - Simplifies return expression
 - Removes previously added white line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/506b6839..cd88c6e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=22-23

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 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  Mon Dec 29 14:24:43 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 14:24:43 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v25]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <Py3KoYBnhe6gkfROGNl03GdVlcn_S3ZTUmoBwQD3mTc=.bdd06613-583c-43fc-815e-be0bfcbbadf6@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:

  Applies suggested change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/cd88c6e2..e47cbb86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=23-24

  Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 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  Mon Dec 29 14:30:26 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 14:30:26 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v26]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <ctWZyTDeHLUAsFB6KYWWtobA29nNnxNfBBT03HaabLo=.15779418-0898-474b-a487-11c7184899fa@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:

 - Removes blank lines
 - Removes blank lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e47cbb86..f678d968

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=24-25

  Stats: 9 lines in 1 file changed: 0 ins; 9 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  Mon Dec 29 14:40:20 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 29 Dec 2025 14:40:20 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v27]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <1BesKj_TIrHeTlabX77gPDuFLRAl0hnLwsfzYODMpf0=.e7c9735e-364d-4a73-b88b-78e090843226@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 formatting and removes extra blank line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/f678d968..9868231f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=25-26

  Stats: 6 lines in 1 file changed: 3 ins; 2 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  Tue Dec 30 14:27:04 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 30 Dec 2025 14:27:04 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v28]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <yp2D9uttJklqglwliwgTlr2hFlCbKGD20mjQ3_eA0Nw=.f5a235d4-4541-45a7-b71f-d021fc0a9fd6@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 few issues when sorting formatting ...

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/9868231f..a73a1572

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=26-27

  Stats: 9 lines in 3 files changed: 3 ins; 2 del; 4 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 serb at openjdk.org  Tue Dec 30 22:53:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 22:53:02 GMT
Subject: RFR: 8374355: Update copyright year to 2025 for demo in files
 where it was missed
In-Reply-To: <EepHqhgpPqpQCOOkbIW_1VIl7PNFi8qr_fC7FzmWpiU=.18fe49d5-cd35-4275-a4c3-f55193044efc@github.com>
References: <EepHqhgpPqpQCOOkbIW_1VIl7PNFi8qr_fC7FzmWpiU=.18fe49d5-cd35-4275-a4c3-f55193044efc@github.com>
Message-ID: <i39KOtph4Tp3uc6OkZw6TBFjii4kRnDSUZJq8CVCR5Q=.43448a6e-1208-40a6-b573-9e115d86ccf1@github.com>

On Thu, 25 Dec 2025 08:10:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in demo files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Looking for volunteers to review this patch. It cannot be integrated in 2026.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28991#issuecomment-3700736161

From aivanov at openjdk.org  Wed Dec 31 15:30:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 31 Dec 2025 15:30:00 GMT
Subject: RFR: 8374355: Update copyright year to 2025 for demo in files
 where it was missed
In-Reply-To: <EepHqhgpPqpQCOOkbIW_1VIl7PNFi8qr_fC7FzmWpiU=.18fe49d5-cd35-4275-a4c3-f55193044efc@github.com>
References: <EepHqhgpPqpQCOOkbIW_1VIl7PNFi8qr_fC7FzmWpiU=.18fe49d5-cd35-4275-a4c3-f55193044efc@github.com>
Message-ID: <3kanDojTZmNOdJ34PRNqsBbLgCEuOftzhV338canQ9U=.fd7596e3-785c-43a6-a060-ec91c8876cf9@github.com>

On Thu, 25 Dec 2025 08:10:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in demo files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28991#pullrequestreview-3621054295

From serb at openjdk.org  Wed Dec 31 17:16:12 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 17:16:12 GMT
Subject: Integrated: 8374355: Update copyright year to 2025 for demo in files
 where it was missed
In-Reply-To: <EepHqhgpPqpQCOOkbIW_1VIl7PNFi8qr_fC7FzmWpiU=.18fe49d5-cd35-4275-a4c3-f55193044efc@github.com>
References: <EepHqhgpPqpQCOOkbIW_1VIl7PNFi8qr_fC7FzmWpiU=.18fe49d5-cd35-4275-a4c3-f55193044efc@github.com>
Message-ID: <JNIeEmwYth8XdBQGLDYM4cAthmwavgCIYRPRrJ9Eb2Q=.e0dade12-18de-462b-b8ed-ff3050a695bc@github.com>

On Thu, 25 Dec 2025 08:10:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in demo files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 2447e071
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2447e07137b809aec9bdbb97f89b52488f5c02de
Stats:     9 lines in 9 files changed: 0 ins; 0 del; 9 mod

8374355: Update copyright year to 2025 for demo in files where it was missed

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/28991

From duke at openjdk.org  Wed Dec 31 17:53:39 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 31 Dec 2025 17:53:39 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v29]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <LsdKyc72N6MxqoYLqBJgXePthWC5P3_7RNvjhYJZz7A=.c0e003e6-f645-4448-8ed4-4ffe5c8845c1@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:

  Removes some mixing tests from problem list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/a73a1572..405f4a8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=27-28

  Stats: 3 lines in 1 file changed: 0 ins; 2 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