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