From dnguyen at openjdk.org  Fri Aug  1 00:10:58 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 1 Aug 2025 00:10:58 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>
Message-ID: <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>

On Sat, 12 Jul 2025 03:34:08 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8358813: putting the actions in a TreeSet
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
>  - 8358813: make input map types a static constant
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
>  - Merge branch 'master' into JDK-8358813
>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - 8358813: remove more bindings for JPasswordFields in Aqua

Tested with and without the change to AquaKeyBindings. Passes after adding null to the 3 key bindings. Ran on clientlibs tests and all tests still pass. I left a question on the bindings segment for clarification.

src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 162:

> 160:                         "alt BACK_SPACE", null,
> 161:                         "ctrl W", null,
> 162:                         "alt DELETE", null

The change "works" for the test, but I'm not exactly sure what's changed here. When I make my own local test with a JPasswordField, the key binds don't do anything on Aqua. The `CTRL+W` seems to just input `W`. `ALT+BACK_SPACE` seems to just backspace the character before the carat. Can you help me understand this?

Also, I guess you can end in a trailing comma to match the previous format if you want. Either is OK.

test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 43:

> 41: import java.util.Arrays;
> 42: import java.util.Collection;
> 43: import java.util.TreeSet;

Suggestion:

import java.util.Arrays;
import java.util.Collection;
import java.util.TreeSet;

import javax.swing.InputMap;
import javax.swing.JComponent;
import javax.swing.JPasswordField;
import javax.swing.KeyStroke;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import javax.swing.UnsupportedLookAndFeelException;
import javax.swing.text.DefaultEditorKit;


Reorganize imports.

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

PR Review: https://git.openjdk.org/jdk/pull/25688#pullrequestreview-3076765762
PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2246362320
PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2246293491

From achung at openjdk.org  Fri Aug  1 00:34:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 00:34:54 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw
 exception for non-zero image index
In-Reply-To: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
Message-ID: <JC2MuRL0krLRoBmuvnjLoGOWN_hzRwjlqDlKV8G9zog=.ee20f980-adb4-44fe-a8fa-e1751425fec9@github.com>

On Tue, 29 Jul 2025 05:38:00 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We need to throw appropriate exception when we pass invalid image index values to ImageReader.getImageTypes().
> We throw IOOBE in all other plugins except JPEG, Added appropriate check to throw IOOBE when JpegImageReader has invalid image index.

test/jdk/javax/imageio/plugins/jpeg/JpegNegativeImageIndexTest.java line 53:

> 51:         ImageReader ir = readers.next();
> 52:         try {
> 53:             Iterator<ImageTypeSpecifier> types = ir.getImageTypes(-1);

You could expand the test to call this with different non-zero parameters (-2, -1, 1, 2) to see if the behavior is correct

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26522#discussion_r2246625248

From achung at openjdk.org  Fri Aug  1 00:35:07 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 00:35:07 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
Message-ID: <AWyda4-xyiP2pye48KFGOGgeWSUODR3jIKPBQu3Xijo=.bb5f19dc-a108-4ae4-8559-2f449cf7c195@github.com>

On Thu, 31 Jul 2025 07:28:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
>> Test instruction updated to reflect the desired behaviour .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor text instruction update

test/jdk/javax/swing/SwingUtilities/bug4967768.java line 47:

> 45:             underlined at the bottom of the instruction frame.
> 46: 
> 47:             Ensure the underline cuts through the descender

Maybe you can get rid of the part mentioning descender and just say "The letter p cuts through the underline".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26546#discussion_r2246611109

From dnguyen at openjdk.org  Fri Aug  1 01:06:05 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 1 Aug 2025 01:06:05 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
Message-ID: <hHFyLFe1S3vq9RwRPPl9DfzCpsoRx4VjRFSgHuGYv9E=.300afd1e-61a1-4d5b-ad02-1a17979c347e@github.com>

On Thu, 31 Jul 2025 02:20:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename listener class

I looked through all of the new changes. Building & headful testing seems good. LGTM

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3077282515

From duke at openjdk.org  Fri Aug  1 02:26:44 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 1 Aug 2025 02:26:44 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v3]
In-Reply-To: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
Message-ID: <pRA0pQIz4irlOxCx7T4Tu6OLRrPDfuEAoYeaZg_Fl1s=.23da5d33-8993-45fa-b9db-9102c7f9717e@github.com>

> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
> 
> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)

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

  Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
  
  Co-authored-by: DamonGuy <damon.nguyen at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25688/files
  - new: https://git.openjdk.org/jdk/pull/25688/files/6b497a71..486f575e

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

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

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

From psadhukhan at openjdk.org  Fri Aug  1 02:58:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 02:58:58 GMT
Subject: RFR: 4870789: RFE: UIDefaults.getUIError() hides real error
In-Reply-To: <VK4RjRS_P2CwzSGi9aIy4LrpIFl7Pe6FrAiwrg49Gtw=.eab3869a-9509-4ebd-abf3-4b93bf58e84d@github.com>
References: <KmIIfh9U9Ao7EVepMjO5aNKS1i1LUS72TjmaVZ6FyCU=.59610038-c1a7-489d-822f-6a91094fb413@github.com>
 <VK4RjRS_P2CwzSGi9aIy4LrpIFl7Pe6FrAiwrg49Gtw=.eab3869a-9509-4ebd-abf3-4b93bf58e84d@github.com>
Message-ID: <DDxSNWBFIVGa_DthMpnEKqV8ECFgqoR0wdEd8m0Eios=.b72372a6-8a50-44b9-8c0b-ecade822820f@github.com>

On Thu, 31 Jul 2025 19:30:56 GMT, Phil Race <prr at openjdk.org> wrote:

> This is an incompatible change. All it does is break any code that calls getUIError() And I notice no JDK code calls this so I am not seeing any point to this change. I think this RFE should be closed as will-not-fix.

I also thought so but nothing better than to conclude in open discussion..Closed..

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

PR Comment: https://git.openjdk.org/jdk/pull/26567#issuecomment-3141998865

From psadhukhan at openjdk.org  Fri Aug  1 02:58:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 02:58:59 GMT
Subject: Withdrawn: 4870789: RFE: UIDefaults.getUIError() hides real error
In-Reply-To: <KmIIfh9U9Ao7EVepMjO5aNKS1i1LUS72TjmaVZ6FyCU=.59610038-c1a7-489d-822f-6a91094fb413@github.com>
References: <KmIIfh9U9Ao7EVepMjO5aNKS1i1LUS72TjmaVZ6FyCU=.59610038-c1a7-489d-822f-6a91094fb413@github.com>
Message-ID: <_d9kDugEc-YhfmXO9CwB-Hca-WbI8uXBB7xa9fk2T38=.a5c1adcf-9140-4aa4-8afc-17094cec9258@github.com>

On Thu, 31 Jul 2025 05:20:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `UIDefaults.getUIError` method is invoked when an exception occurred in UI code but this method hides the underlying exception, this method could be more useful if the original exception is passed as argument and used as the cause of the Error thrown from `getUIError` body

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Fri Aug  1 03:20:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 03:20:55 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <0AugtjRm8JvkkVaQfhEZWkc4Sr4q3jVsQ9WTbJ1DXSc=.98ed7882-3d25-461f-9efd-43683de2d059@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
 <SFgzHGUAIICW4EOcwlQTNht3_Of8YlE9H7-ILbLcLFg=.bb6da4ca-5d72-47ec-85c1-b643161ee08b@github.com>
 <0AugtjRm8JvkkVaQfhEZWkc4Sr4q3jVsQ9WTbJ1DXSc=.98ed7882-3d25-461f-9efd-43683de2d059@github.com>
Message-ID: <glYymbkZHShNQi_yi0gvLYqqrudLMDUFTRVS20Lv_aE=.4a5a381c-2d0f-48c7-8f59-782b56501db8@github.com>

On Thu, 31 Jul 2025 19:47:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/font/CStrike.java line 99:
>> 
>>> 97: 
>>> 98:     public long getNativeStrikePtr() {
>>> 99:         return nativeStrikePtr;
>> 
>> Any reason this check was removed?
>> I see that initNativeStrikePtr will call createNativeStrikePtr which does this where there is no null check and it just returns what it gets so shouldn't we check it here?
>> 
>> 
>> awtStrike = [AWTStrike awtStrikeForFont:awtFont tx:glyphTx invDevTx:invDevTx style:style aaStyle:aaStyle]; // autoreleased
>> 
>>     if (awtStrike)
>>     {
>>         CFRetain(awtStrike); // GC
>>     }
>> 
>> JNI_COCOA_EXIT(env);
>>     return ptr_to_jlong(awtStrike);
>
> And if it is 0, what would you do ?
> Previously 0 meant it hadn't yet been initialized. Now it is always initialized.
> 
> You'd need to return it anyway even it was zero.

Then I guess whoever is using the `nativeStrikePtr` should account for that it can receive null or 0..
I haven't seen all cases but one case I saw `getFontMetrics `calls `getFontMetrics(getNativeStrikePtr())`
and there it does this where it dereference `awtStrikePtr`...Shouldn't it cause SIGSEGV if it ever becomes 0?


JNIEXPORT jobject JNICALL
Java_sun_font_CStrike_getFontMetrics
    (JNIEnv *env, jclass clazz, jlong awtStrikePtr)
{
    jobject metrics = NULL;

JNI_COCOA_ENTER(env);
    AWT_FONT_CLEANUP_SETUP;

    AWTFont *awtfont = ((AWTStrike *)jlong_to_ptr(awtStrikePtr))->fAWTFont;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26397#discussion_r2246796256

From psadhukhan at openjdk.org  Fri Aug  1 03:35:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 03:35:56 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <hHFyLFe1S3vq9RwRPPl9DfzCpsoRx4VjRFSgHuGYv9E=.300afd1e-61a1-4d5b-ad02-1a17979c347e@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
 <hHFyLFe1S3vq9RwRPPl9DfzCpsoRx4VjRFSgHuGYv9E=.300afd1e-61a1-4d5b-ad02-1a17979c347e@github.com>
Message-ID: <6f01mVyQD0TetD508Qmz818dzNoeSR40kEx4e5qkj54=.f134ec4d-75db-4be9-873c-15847b17d283@github.com>

On Fri, 1 Aug 2025 01:03:26 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename listener class
>
> I looked through all of the new changes. Building & headful testing seems good. LGTM

Thanks @DamonGuy ... Any 2nd Reviewer?

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

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3142053185

From psadhukhan at openjdk.org  Fri Aug  1 04:14:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 04:14:01 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
Message-ID: <JhKHluwEeVmjvBw5ytcm2wB80Z3JxAPWCXW0sGJLD3Q=.03c59949-b774-49a1-a059-801def8f354b@github.com>

On Tue, 22 Jul 2025 22:10:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
>> 
>> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363889

src/java.desktop/share/classes/sun/print/PrintJob2D.java line 35:

> 33: import java.awt.JobAttributes.*;
> 34: import java.awt.PageAttributes;
> 35: import java.awt.PageAttributes.*;

wildcard..probably it should be removed as it is used in Delegate class

src/java.desktop/share/classes/sun/print/PrintJob2D.java line 115:

> 113:     }
> 114: 
> 115:     private static class PrintJobDisposerRecord implements DisposerRecord {

should we also make it a final class?

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved.

should it be 2000? its a new class but its content is from 2000!!

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 36:

> 34: import java.awt.JobAttributes.*;
> 35: import java.awt.PageAttributes;
> 36: import java.awt.PageAttributes.*;

wildcard

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2246853626
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2246853391
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2246854668
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2246855763

From tr at openjdk.org  Fri Aug  1 05:05:58 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 1 Aug 2025 05:05:58 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <lI9u4yY3DXCiuA6xGQseQgCH7fBnM6mulHOwuTP8vvY=.9204f0c5-9d3f-4e9b-ae64-0fc2f6ab20e1@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
 <2s1wmxROMbswI-vhhS8_-JpNuJ3ZnTE9n0ACPmw3E0k=.4809f5b7-e5b8-4dec-a96f-d47999ab742e@github.com>
 <dxkWt8VODuyidUIFl5eVxjIqtLBvpl-klFO20st_KN8=.750712e5-c97b-432b-af06-fab3b173fa8d@github.com>
 <lI9u4yY3DXCiuA6xGQseQgCH7fBnM6mulHOwuTP8vvY=.9204f0c5-9d3f-4e9b-ae64-0fc2f6ab20e1@github.com>
Message-ID: <lz9vrqviRc59uYKLrLIKmm1JouKjWB70VogcDbEQ9-4=.06911bb3-b9d6-4963-a765-24a00e553f95@github.com>

On Thu, 31 Jul 2025 16:21:46 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > > If I am right, the main bug is about underline drawing and not about mnemonic. Yet mnemonic is used to check underline drawing under the string, I guess you can think of using the code mentioned in [JDK-4967768](https://bugs.openjdk.org/browse/JDK-4967768) in the test which would be fine for all L&F.
> > 
> > 
> > Good point. I second this if possible.
> 
> Yes, the main bug is about the underline drawing and not mnemonic but the underline i.e. mnemonic visibility depends on the platform the test is running. It depends on the current L&F as well. In case of Metal, Motif and Nimbus, the underline is visible always whereas if the test ran with Windows or GTK L&F, underline visibility depends on the how the underlying platform handle the underline. If the underline drawing is invisible then I don't see any way to verify it's position.
> 
> > I guess you can think of using the code mentioned in [JDK-4967768](https://bugs.openjdk.org/browse/JDK-4967768) in the test which would be fine for all L&F.
> 
> The code you mentioned is already implemented in [SwingUtilities's drawStringUnderlineCharAt](https://github.com/kumarabhi006/jdk/blob/04c0b130f09c093797895cc928fe020d7e584cb9/src/java.desktop/share/classes/sun/swing/SwingUtilities2.java#L694) method and I checked on Windows and macOS that this code path is executed and that impact the underline drawing. If it is commented then there is no underline drawing for the mnemonics and vice-versa.
> 
> The underline drawing is correct as it has drawn just below the baseline and not below the character "P".
> 
> So, I think the fix requires an instruction change to let the tester know that the "ALT" key press is a requirement to make the mnemonic visible and then the underline position can be verified further.

I got the point. I'm suggesting that instead of relying on "ALT" key press which in turn draw underline that has some dependency on L&F, drawing underline to verify the test would be better.

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

PR Comment: https://git.openjdk.org/jdk/pull/26546#issuecomment-3142183359

From abhiscxk at openjdk.org  Fri Aug  1 05:17:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 05:17:56 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <AWyda4-xyiP2pye48KFGOGgeWSUODR3jIKPBQu3Xijo=.bb5f19dc-a108-4ae4-8559-2f449cf7c195@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
 <AWyda4-xyiP2pye48KFGOGgeWSUODR3jIKPBQu3Xijo=.bb5f19dc-a108-4ae4-8559-2f449cf7c195@github.com>
Message-ID: <MmeRYRHB0r4Z8b78fPOqZ7fVpyRUNbWYwbI2VZnz5Xw=.18e4dcd3-3c64-4578-a944-329204bd926b@github.com>

On Fri, 1 Aug 2025 00:17:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor text instruction update
>
> test/jdk/javax/swing/SwingUtilities/bug4967768.java line 47:
> 
>> 45:             underlined at the bottom of the instruction frame.
>> 46: 
>> 47:             Ensure the underline cuts through the descender
> 
> Maybe you can get rid of the part mentioning descender and just say "The letter p cuts through the underline".

I just kept it from the original test and it seems ok to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26546#discussion_r2246926692

From abhiscxk at openjdk.org  Fri Aug  1 05:17:54 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 05:17:54 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <lz9vrqviRc59uYKLrLIKmm1JouKjWB70VogcDbEQ9-4=.06911bb3-b9d6-4963-a765-24a00e553f95@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
 <2s1wmxROMbswI-vhhS8_-JpNuJ3ZnTE9n0ACPmw3E0k=.4809f5b7-e5b8-4dec-a96f-d47999ab742e@github.com>
 <dxkWt8VODuyidUIFl5eVxjIqtLBvpl-klFO20st_KN8=.750712e5-c97b-432b-af06-fab3b173fa8d@github.com>
 <lI9u4yY3DXCiuA6xGQseQgCH7fBnM6mulHOwuTP8vvY=.9204f0c5-9d3f-4e9b-ae64-0fc2f6ab20e1@github.com>
 <lz9vrqviRc59uYKLrLIKmm1JouKjWB70VogcDbEQ9-4=.06911bb3-b9d6-4963-a765-24a00e553f95@github.com>
Message-ID: <N6CFyhoePVuoTDE_Rus3xJGX7KWjpokwpBXa37NjiYk=.61e1f396-839b-4e92-854e-dbf25ac118e6@github.com>

On Fri, 1 Aug 2025 05:03:32 GMT, Tejesh R <tr at openjdk.org> wrote:

> I got the point. I'm suggesting that instead of relying on "ALT" key press which in turn draw underline that has some dependency on L&F, drawing underline to verify the test would be better.

I don't think so. We should follow the platform specific requirement to test the fix as we try to mimic the native side behaviour for few L&Fs (Windows and GTK).

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

PR Comment: https://git.openjdk.org/jdk/pull/26546#issuecomment-3142200508

From psadhukhan at openjdk.org  Fri Aug  1 05:19:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 05:19:56 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
Message-ID: <EdfX-esI_0GVAO543WMxyrN9bg_bVcREetuBC9MKsKs=.feaaf96c-e02c-455d-bcb3-3978360f97dd@github.com>

On Tue, 22 Jul 2025 22:10:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
>> 
>> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363889

Looks ok otherwise..

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26432#pullrequestreview-3077683713

From psadhukhan at openjdk.org  Fri Aug  1 05:21:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 05:21:55 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <j37dB7al9Yonxg5yXPImSeeREj6BQdteh0n1OFhd9u0=.52c32a22-ced0-4065-9d7f-13d8b1bfad5a@github.com>

On Mon, 28 Jul 2025 22:38:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

src/java.desktop/share/classes/javax/swing/text/StringContent.java line 29:

> 27: import java.util.Vector;
> 28: import java.io.Serializable;
> 29: import javax.swing.undo.*;

wildcard

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2246931524

From psadhukhan at openjdk.org  Fri Aug  1 05:25:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 05:25:53 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <oFfcqVqqdjgsFw93G-c9bXB0kk0_kO42WxKL2eUdoa0=.dbd759a4-14b7-4d64-889d-a46355a432dc@github.com>

On Mon, 28 Jul 2025 22:38:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 65:

> 63:         for (int i=0; i<SIZE; i++) {
> 64:             if (positions[i].getOffset() != 0) {
> 65:                System.err.println("remove: Bad offset i=" + i + " off=" + positions[i].getOffset());

Why a RuntimeException is not thrown instead of just logging?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2246935417

From psadhukhan at openjdk.org  Fri Aug  1 05:44:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 05:44:56 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
Message-ID: <YV-Kh6WMGIU_pDBn6oSg1DCf22Z4IUFFRWZIoJcORig=.c5997639-1d48-4bda-b25a-c565e80cc2a4@github.com>

On Thu, 31 Jul 2025 07:28:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
>> Test instruction updated to reflect the desired behaviour .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor text instruction update

I guess the main bug is about mnemonics [[4967768 :](https://bugs.openjdk.org/browse/JDK-4967768)Incorrect underline painting in mnemonics (and possibly elsewhere)] so it seems ok to have testing to be done with mnemonics for this test and to fix with description change..We can have another test if needed with any other way of drawing underline but I presume there are already

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26546#pullrequestreview-3077741582

From psadhukhan at openjdk.org  Fri Aug  1 06:01:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 06:01:56 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <YV-Kh6WMGIU_pDBn6oSg1DCf22Z4IUFFRWZIoJcORig=.c5997639-1d48-4bda-b25a-c565e80cc2a4@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
 <YV-Kh6WMGIU_pDBn6oSg1DCf22Z4IUFFRWZIoJcORig=.c5997639-1d48-4bda-b25a-c565e80cc2a4@github.com>
Message-ID: <2k-K7jdSnFn-PuN4Z9S8skp0nU1aNLYaTaCnOmqXfeE=.04a8ffcb-4dc6-4b38-a25e-4e063864a984@github.com>

On Fri, 1 Aug 2025 05:42:36 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess the main bug is about mnemonics [[4967768 :](https://bugs.openjdk.org/browse/JDK-4967768)Incorrect underline painting in mnemonics (and possibly elsewhere)] so it seems ok to have testing to be done with mnemonics for this test and to fix with description change..We can have another test if needed with any other way of drawing underline but I presume there are already

there's one in javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.java#testDrawString(underline)  which test BasicGraphicsUtils.drawStringUnderlineCharAt

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

PR Comment: https://git.openjdk.org/jdk/pull/26546#issuecomment-3142506283

From psadhukhan at openjdk.org  Fri Aug  1 06:10:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 06:10:56 GMT
Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java
In-Reply-To: <JQb1C0yKejFuZVa9B-hX20jN4ic13jiWalu8r902fW0=.fabc1b9f-8565-4ef8-9a75-63029c90388f@github.com>
References: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
 <JQb1C0yKejFuZVa9B-hX20jN4ic13jiWalu8r902fW0=.fabc1b9f-8565-4ef8-9a75-63029c90388f@github.com>
Message-ID: <TtNpV4-w-5CCuBtdwXkxhWxP6fLzEHfxjWoS66U8O8M=.ab5471c6-ffda-4cd8-ae4c-a085ec07ef0b@github.com>

On Thu, 31 Jul 2025 16:24:10 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> The java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java test uses object monitors and wait/notify to synchronise actions in the test.
>> 
>> Using CountDownLatch could make the test simpler, shorter, clearer.
>> Tested the code on a windows-x64, macos-x64 and lnux-x64 machines and the test is working as expected.
>
> test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 59:
> 
>> 57:     private static final CountDownLatch windowActivatedLatch = new CountDownLatch(1);
>> 58:     private static final CountDownLatch windowDeactivatedLatch = new CountDownLatch(1);
>> 59:     private static final CountDownLatch windowFocusGainedLatch = new CountDownLatch(1);
> 
> I see where we decrement this latch but i do not see where we check it or wait on it. Is it really needed?

also no need to use ExtendedRobot as all I can see is mousePress/mouseRelease which can be used from java.awt.Robot class itself..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2247030087

From abhiscxk at openjdk.org  Fri Aug  1 06:14:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 06:14:56 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <2sPT_bmjwCqDaVu6zEQqx5TGGmOj5DGPq86-XktyV_Y=.bdb2a33c-10d3-4d03-afef-30c63f315d72@github.com>

On Mon, 28 Jul 2025 22:38:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 38:

> 36:     static final String text = "hello";
> 37:     static final int LEN = text.length();
> 38:     static final StringContent st = new StringContent();

For consistency, static final variables can be capitalized.

test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 56:

> 54:             positions[i] = st.createPosition(5);
> 55:         }
> 56:         for (int i=0; i<SIZE; i++) {

Suggestion:

        for (int i = 0; i < SIZE; i++) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2247037497
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2247038442

From abhiscxk at openjdk.org  Fri Aug  1 06:29:59 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 06:29:59 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
Message-ID: <E4CoX3MXsCUy3NmgG65SndWfgEbyaETi8-KJUwE7_1w=.2c56c474-9afc-40d7-9c65-1f9c08c24923@github.com>

On Thu, 31 Jul 2025 02:20:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename listener class

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 53:

> 51: 
> 52:     private static final CountDownLatch popupShown = new CountDownLatch(1);
> 53:     private static final CountDownLatch popupHidden = new CountDownLatch(1);

Final variables can be capitalized.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 106:

> 104:                 pane.repaint();
> 105:             });
> 106:             if (!popupHidden.await(1, SECONDS)) {

is it ok to have the same timeout for both latches ?
If yes, then a final TIMEOUT variable can be declared and used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2247061840
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2247072039

From abhiscxk at openjdk.org  Fri Aug  1 06:47:54 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 06:47:54 GMT
Subject: RFR: 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: <wcy_5XD5X9WvDbtk2oFBdchqkdRY3f8ua1L89Yz-enw=.0de33457-0343-4942-a273-350effa88bd2@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.

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

> 2510:      * @return the "unit" increment for scrolling in the specified direction;
> 2511:      *         which is usually positive. But it can return 0
> 2512:      *         if {@code visibleRect} points to that row

should it be `the` or `that` ?
Suggestion:

     *         if {@code visibleRect} points to the row


Requires a CSR too ?

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

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

From psadhukhan at openjdk.org  Fri Aug  1 07:14:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 07:14:58 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <E4CoX3MXsCUy3NmgG65SndWfgEbyaETi8-KJUwE7_1w=.2c56c474-9afc-40d7-9c65-1f9c08c24923@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
 <E4CoX3MXsCUy3NmgG65SndWfgEbyaETi8-KJUwE7_1w=.2c56c474-9afc-40d7-9c65-1f9c08c24923@github.com>
Message-ID: <T73-6DXqi6E3pyTg6SAzu_h0mfjEV7GmIhr2bHEwtQA=.18e61b03-ba1e-44cd-a097-4f3b7c8c8123@github.com>

On Fri, 1 Aug 2025 06:22:23 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename listener class
>
> test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 53:
> 
>> 51: 
>> 52:     private static final CountDownLatch popupShown = new CountDownLatch(1);
>> 53:     private static final CountDownLatch popupHidden = new CountDownLatch(1);
> 
> Final variables can be capitalized.

It is not a constant so no need.

> test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 106:
> 
>> 104:                 pane.repaint();
>> 105:             });
>> 106:             if (!popupHidden.await(1, SECONDS)) {
> 
> is it ok to have the same timeout for both latches ?
> If yes, then a final TIMEOUT variable can be declared and used.

"show" sometimes might take more time so I guess different timeout is ok..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2247168368
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2247172191

From psadhukhan at openjdk.org  Fri Aug  1 07:16:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 07:16:55 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0
In-Reply-To: <wcy_5XD5X9WvDbtk2oFBdchqkdRY3f8ua1L89Yz-enw=.0de33457-0343-4942-a273-350effa88bd2@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <wcy_5XD5X9WvDbtk2oFBdchqkdRY3f8ua1L89Yz-enw=.0de33457-0343-4942-a273-350effa88bd2@github.com>
Message-ID: <lwS2mLWmtuzPlLiME9GR_LoUWdObqOUYmndwhpcieU4=.97c8c891-1098-4967-9ed9-3d7b103a91e1@github.com>

On Fri, 1 Aug 2025 06:45:37 GMT, Abhishek Kumar <abhiscxk 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.
>
> src/java.desktop/share/classes/javax/swing/JList.java line 2512:
> 
>> 2510:      * @return the "unit" increment for scrolling in the specified direction;
>> 2511:      *         which is usually positive. But it can return 0
>> 2512:      *         if {@code visibleRect} points to that row
> 
> should it be `the` or `that` ?
> Suggestion:
> 
>      *         if {@code visibleRect} points to the row
> 
> 
> Requires a CSR too ?

it is "that" row being pointed to by visibleRect
and yes CSR is needed but I want to finalise the wordings first.

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

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

From abhiscxk at openjdk.org  Fri Aug  1 07:21:55 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 07:21:55 GMT
Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java
In-Reply-To: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
References: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
Message-ID: <14IF7UOoOODTahyScAC9c6rzXTu3f5FexhT35gBbAZs=.68a6d315-84ac-485f-be7f-780e765f2d2b@github.com>

On Fri, 25 Jul 2025 05:33:31 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> The java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java test uses object monitors and wait/notify to synchronise actions in the test.
> 
> Using CountDownLatch could make the test simpler, shorter, clearer.
> Tested the code on a windows-x64, macos-x64 and lnux-x64 machines and the test is working as expected.

Few more observations :
1. Add a space wherever application. At L76... `try {`
2. Don't think it is required to print stack trace, you can throw it in RTE.
3. At L165, robot.waitForIdle(5 * delay);
4. Access UI components on EDT. e.g L166 etc.
5. Can remove `//captureScreenAndSave();` and `System.err.println("Test failed!");` lines

test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 61:

> 59:     private static final CountDownLatch windowFocusGainedLatch = new CountDownLatch(1);
> 60:     private boolean passed = true;
> 61:     private final int delay = 150;

Suggestion:

    private final int DELAY = 150;

test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 98:

> 96:         frame.setUndecorated(true);
> 97:         frame.addWindowFocusListener(new WindowFocusListener() {
> 98:             public void windowGainedFocus(WindowEvent event) {

add @override for all overridden methods.

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

PR Review: https://git.openjdk.org/jdk/pull/26471#pullrequestreview-3077988039
PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2247148963
PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2247149511

From abhiscxk at openjdk.org  Fri Aug  1 07:21:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 07:21:56 GMT
Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java
In-Reply-To: <TtNpV4-w-5CCuBtdwXkxhWxP6fLzEHfxjWoS66U8O8M=.ab5471c6-ffda-4cd8-ae4c-a085ec07ef0b@github.com>
References: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
 <JQb1C0yKejFuZVa9B-hX20jN4ic13jiWalu8r902fW0=.fabc1b9f-8565-4ef8-9a75-63029c90388f@github.com>
 <TtNpV4-w-5CCuBtdwXkxhWxP6fLzEHfxjWoS66U8O8M=.ab5471c6-ffda-4cd8-ae4c-a085ec07ef0b@github.com>
Message-ID: <VND745uZQHqHcir0sOhfnqWucBY9SozOx9tX1JOdg6Y=.a2717a72-4470-43e2-90f4-3295120945cc@github.com>

On Fri, 1 Aug 2025 06:08:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 59:
>> 
>>> 57:     private static final CountDownLatch windowActivatedLatch = new CountDownLatch(1);
>>> 58:     private static final CountDownLatch windowDeactivatedLatch = new CountDownLatch(1);
>>> 59:     private static final CountDownLatch windowFocusGainedLatch = new CountDownLatch(1);
>> 
>> I see where we decrement this latch but i do not see where we check it or wait on it. Is it really needed?
>
> also no need to use ExtendedRobot as all I can see is mousePress/mouseRelease which can be used from java.awt.Robot class itself..

static final variables can be capitalized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2247144121

From achung at openjdk.org  Fri Aug  1 07:36:56 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 07:36:56 GMT
Subject: RFR: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X [v2]
In-Reply-To: <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>
References: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
 <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>
Message-ID: <Hxx8WeP23zpF7gtTiaeLXymD7ZCC-yg5QzksmiFJWTI=.f3546951-9655-469f-a4af-b9e58195fbf8@github.com>

On Tue, 8 Jul 2025 14:56:23 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Sets setOpaque for lightweight, and uses a compares colors with tolerance in MacOS X machines.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds extra space after if
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Please change copyright years for test as well

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

> 302:     }//fail()
> 303:     private static boolean isAlmostEqualColor(Color color, Color refColor) {
> 304:         final int COLOR_TOLERANCE_MACOSX = 10;

I think this field should go with the other final variables at the top for visibility

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

PR Review: https://git.openjdk.org/jdk/pull/26166#pullrequestreview-3078084729
PR Review Comment: https://git.openjdk.org/jdk/pull/26166#discussion_r2247209974

From achung at openjdk.org  Fri Aug  1 07:38:55 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 07:38:55 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
In-Reply-To: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>
References: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>
Message-ID: <Ztqz-SgLpcR5t-FOp3boZi1C-IkBYpFVw5BYEDdzq8A=.f04f15ff-e887-479d-b0d9-83716516c990@github.com>

On Mon, 7 Jul 2025 15:21:33 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.
> 
> Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

Please update test copyright years, otherwise looks fine

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26162#pullrequestreview-3078090668

From achung at openjdk.org  Fri Aug  1 07:41:58 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 07:41:58 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v12]
In-Reply-To: <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
Message-ID: <UNsbFD-Q9TMT4jj4Za2s3_EEo0boW0Y5y7rWxvnAcUo=.5fe26757-2130-4fcd-b59f-255bb64d3fe1@github.com>

On Wed, 23 Jul 2025 14:47:41 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 21 additional commits since the last revision:
> 
>  - Removes not needed component frace ancestor.
>  - Problem unlists passed tests
>  - Uses frame requestFocus instead of robot clicks for focus
>  - Removes extra Robot waitForIdle
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Restores copyright year for tests not updated
>  - Removes some tests from problem list
>  - Uses request frame focus instead of Robot clicks to request frame focus
>  - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
>    
>    This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
>  - Revert "Removes passed tests from problem list"
>    
>    This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/7190359e...b558508f

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 24:

> 22:  */
> 23: 
> 24: import java.awt.*;

please expand wildcard imports

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2247216223

From achung at openjdk.org  Fri Aug  1 07:42:55 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 07:42:55 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
Message-ID: <ff8C8wQsG048coUDnis8MuYQrJ3NYtNlRWLMP0bSUhg=.9a1942a5-0650-4c0c-9cd7-d1a75c45d49e@github.com>

On Thu, 31 Jul 2025 07:28:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
>> Test instruction updated to reflect the desired behaviour .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor text instruction update

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26546#pullrequestreview-3078101926

From achung at openjdk.org  Fri Aug  1 07:51:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 07:51:54 GMT
Subject: RFR: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X [v2]
In-Reply-To: <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>
References: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
 <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>
Message-ID: <C5vFtOkDr3hRSGBmShdiFs4dmzmQcLTDUSPE-y53qCY=.86d8fb9c-87fe-402c-a779-b2f3e2fca4df@github.com>

On Tue, 8 Jul 2025 14:56:23 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Sets setOpaque for lightweight, and uses a compares colors with tolerance in MacOS X machines.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds extra space after if
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Test is failing for me locally on macOS even after the fix.
Test fails at line 163: Execution failed: `main' threw exception: java.lang.RuntimeException: JButton was not redrawn properly on AWT Panel during move
Maybe it would be good to add some debug statements with the color that robot.getPixelColor returns.

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

PR Comment: https://git.openjdk.org/jdk/pull/26166#issuecomment-3143604422

From abhiscxk at openjdk.org  Fri Aug  1 07:52:03 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 07:52:03 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <T73-6DXqi6E3pyTg6SAzu_h0mfjEV7GmIhr2bHEwtQA=.18e61b03-ba1e-44cd-a097-4f3b7c8c8123@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
 <E4CoX3MXsCUy3NmgG65SndWfgEbyaETi8-KJUwE7_1w=.2c56c474-9afc-40d7-9c65-1f9c08c24923@github.com>
 <T73-6DXqi6E3pyTg6SAzu_h0mfjEV7GmIhr2bHEwtQA=.18e61b03-ba1e-44cd-a097-4f3b7c8c8123@github.com>
Message-ID: <fj3Fw8cqNc-UIUvIRP9BWxZfWySTJkcyZXe-OJtm_S4=.1b76a2c2-61f0-44df-8699-c5096228d73b@github.com>

On Fri, 1 Aug 2025 07:12:04 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 106:
>> 
>>> 104:                 pane.repaint();
>>> 105:             });
>>> 106:             if (!popupHidden.await(1, SECONDS)) {
>> 
>> is it ok to have the same timeout for both latches ?
>> If yes, then a final TIMEOUT variable can be declared and used.
>
> "show" sometimes might take more time so I guess different timeout is ok..

In that case, you may have a time out of 5 sec...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2247238629

From psadhukhan at openjdk.org  Fri Aug  1 08:00:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 08:00:01 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <fj3Fw8cqNc-UIUvIRP9BWxZfWySTJkcyZXe-OJtm_S4=.1b76a2c2-61f0-44df-8699-c5096228d73b@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
 <E4CoX3MXsCUy3NmgG65SndWfgEbyaETi8-KJUwE7_1w=.2c56c474-9afc-40d7-9c65-1f9c08c24923@github.com>
 <T73-6DXqi6E3pyTg6SAzu_h0mfjEV7GmIhr2bHEwtQA=.18e61b03-ba1e-44cd-a097-4f3b7c8c8123@github.com>
 <fj3Fw8cqNc-UIUvIRP9BWxZfWySTJkcyZXe-OJtm_S4=.1b76a2c2-61f0-44df-8699-c5096228d73b@github.com>
Message-ID: <zBL4mRVuzvyTZp94rmDdtp8Uyf2QiDDJLwWmMsjJwCk=.33eb1ac0-2248-43a8-8a8c-794207c7766a@github.com>

On Fri, 1 Aug 2025 07:48:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> "show" sometimes might take more time so I guess different timeout is ok..
>
> In that case, you may have a time out of 5 sec...

No, it works well in CI so I dont think we need to change anything now..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2247254205

From abhiscxk at openjdk.org  Fri Aug  1 09:11:04 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 1 Aug 2025 09:11:04 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
Message-ID: <U7BY9fS3-5R8r-K2a-jT3PTGp4BogxQJxqdb5Xc5SAw=.0ac38c49-00e0-4648-9f47-6776a1b7f0d3@github.com>

On Thu, 31 Jul 2025 02:20:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename listener class

Marked as reviewed by abhiscxk (Reviewer).

Updated test looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3078359061
PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3143824607

From psadhukhan at openjdk.org  Fri Aug  1 09:19:08 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Aug 2025 09:19:08 GMT
Subject: Integrated: 4938801: The popup does not go when the component is
 removed
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <o8PvKxjDYgrMwGHmliVtso79eG3uWjU5UxD6irBfZSc=.afa2fc48-bafc-4e70-87bc-6e839290524f@github.com>

On Mon, 21 Jul 2025 02:16:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

This pull request has now been integrated.

Changeset: 7fbeede1
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fbeede14c558221ae0e5b8d65f50e50c0e3737a
Stats:     145 lines in 2 files changed: 144 ins; 0 del; 1 mod

4938801: The popup does not go when the component is removed

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: dnguyen, abhiscxk

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

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

From aivanov at openjdk.org  Fri Aug  1 10:36:05 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Aug 2025 10:36:05 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <6f01mVyQD0TetD508Qmz818dzNoeSR40kEx4e5qkj54=.f134ec4d-75db-4be9-873c-15847b17d283@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>
 <hHFyLFe1S3vq9RwRPPl9DfzCpsoRx4VjRFSgHuGYv9E=.300afd1e-61a1-4d5b-ad02-1a17979c347e@github.com>
 <6f01mVyQD0TetD508Qmz818dzNoeSR40kEx4e5qkj54=.f134ec4d-75db-4be9-873c-15847b17d283@github.com>
Message-ID: <yRdb-Q79KxTHUxSZZUEuhK8jd58jqjFpKZSqBJ0RKFA=.498d6568-8615-404c-a33c-d4dff32d5dc5@github.com>

On Fri, 1 Aug 2025 03:32:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I looked through all of the new changes. Building & headful testing seems good. LGTM
>
> Thanks @DamonGuy ... Any 2nd Reviewer?

@prsadhuk You could've waited for me to take another look. My contribution to reviewing this PR isn't recorded even though I found a bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3144092440

From azvegint at openjdk.org  Fri Aug  1 12:04:02 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Aug 2025 12:04:02 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
Message-ID: <mT4JDyNOCpmndxJNP_jQUqm_ooO6BvWjoaPMORL_EtA=.31ab96d0-faa4-4e52-9abd-4b3f61cc992c@github.com>

On Thu, 31 Jul 2025 07:28:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
>> Test instruction updated to reflect the desired behaviour .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor text instruction update

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26546#pullrequestreview-3078954629

From azvegint at openjdk.org  Fri Aug  1 12:42:55 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Aug 2025 12:42:55 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
Message-ID: <YE6I7thMSRFf-HHHE4YigkqMyfkRKN_OkiEpM_uPWIQ=.6bb51aec-0d1d-4f95-9ec5-8e373af0ddc6@github.com>

On Tue, 22 Jul 2025 22:10:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
>> 
>> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363889

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 824:

> 822:              */
> 823:             //printGraphics = new ProxyPrintGraphics(currentGraphics.create(), this);
> 824:             printGraphics =  currentGraphics.create();

Do we need the comment on line 823?

> The returned Graphics also  to implement PrintGraphics, so we  wrap the Graphics2D instance.

That doesn't seem true anymore.

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 876:

> 874:      * Returns true if the last page will be printed first.
> 875:      */
> 876:     public boolean lastPageFirst() {

It appears to be unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2247879061
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2247857206

From azvegint at openjdk.org  Fri Aug  1 13:41:54 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Aug 2025 13:41:54 GMT
Subject: RFR: 8362898: Remove finalize() methods from javax.imagio TIFF
 classes.
In-Reply-To: <X-lrqNQSpo2EIYSMxAMUTqROPoXmKRqxfCV8OKTztQ8=.fe557cf2-0a8c-435d-bd94-fef78ccddac2@github.com>
References: <X-lrqNQSpo2EIYSMxAMUTqROPoXmKRqxfCV8OKTztQ8=.fe557cf2-0a8c-435d-bd94-fef78ccddac2@github.com>
Message-ID: <MaJbOPzaF6jNFMTYdUwfHY-9b7EvG3rrU2psuaJUbMY=.48f79a38-1fe8-4a25-ae41-4e6dbb67169e@github.com>

On Mon, 21 Jul 2025 16:51:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize from TIFF ImageIO implementatation classes.
> 
> Following copied from the bug description 
> The TIFF image (de)compressors can make use of a JPEG reader / writer
> Like all ImageIO readers and writers, once done, the owner should call their dispose() method.
> This is currently done with finalize() to ensure it isn't missed.
> 
> This can be migrated to a Disposer.
> 
> However, the most common case is that it is the ImageIO built-in JPEGImageReader and JPEGImageWriter
> that is located and that already implements a Disposer. So there is no need to add a Disposer for that.
> We only need to add it if we find some other reader/writer.
> 
> With enough work, it might be possible for the TIFF compressor/decompressor classes to work out when
> they are really done and avoid a Disposer at all. But it could also be that they instead need to discard
> them when a specific task is done and then obtain a new one.
> That would be much more overhead than just adding a Disposer for the rare case and regardless
> of what is done in the TIFF code, the built in JPEG classes will install their own Disposer so I don't
> think I want to pursue that route.
> 
> I also noticed that TIFFBaseJPEGCompressor.java can replace the current writer if it doesn't satisfy a need.
> In that case it just nulls it out and doesn't call dispose() and of course finalize() will then refer to the replacement.
> So I added direct calls to dispose() in such a case. That was definitely necessary with the finalize() code
> but the Disposer would have taken care of it anyway, so it isn't strictly needed with the new code but
> it is still good to do it early if you can.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26416#pullrequestreview-3079289110

From erikj at openjdk.org  Fri Aug  1 18:28:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 18:28:56 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <4HeV-EoMcR1tBbXn11liF56ksr2IuG1b7WhVW3_lsnk=.ae004f63-4a7e-45af-bad6-b86323ea7aec@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26501#pullrequestreview-3080173442

From aivanov at openjdk.org  Fri Aug  1 19:26:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Aug 2025 19:26:57 GMT
Subject: RFR: 8362067: Remove unnecessary List.contains key from
 SpringLayout.Constraints.pushConstraint
In-Reply-To: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
References: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
Message-ID: <RBwgNkjarhDSObCGd7rGvFR48l2KU0oXPu8iD-j3WhI=.c78e5c7b-e43b-47e6-ae99-6b517a11828e@github.com>

On Thu, 24 Apr 2025 14:53:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no need to call `List.contains` before `List.remove` call.
> `history` is an either `horizontalHistory` or `verticalHistory`. Both of them are ArrayList's.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24852#pullrequestreview-3080342868

From prr at openjdk.org  Fri Aug  1 19:55:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 19:55:53 GMT
Subject: RFR: 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: <LR56gUD-lr5heXd4rz9iVC4SvDlCMUJkVXO7_plBuLE=.145eb7ea-f327-4c25-b5e6-5697857f4caf@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.

Isn't this just a bug ?
I get zero from the test whenever "-1" is the direction - meaning scroll up - even if I use something like

https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/JList.html#getScrollableUnitIncrement(java.awt.Rectangle,int,int)

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

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

From prr at openjdk.org  Fri Aug  1 20:12:07 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 20:12:07 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <S9Buvgb6fkfHndrB-I8Tvs9o-H3KcyFtZZ9ZP8yMFGA=.722fdce0-d95b-4c2f-840c-bd2fa5e90aa5@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
 <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
 <S9Buvgb6fkfHndrB-I8Tvs9o-H3KcyFtZZ9ZP8yMFGA=.722fdce0-d95b-4c2f-840c-bd2fa5e90aa5@github.com>
Message-ID: <0TXAOQRqUnRE-AHJrl5yUjnYpEcYs2dAdvPCHoE2F08=.b1ee7514-7668-4e2b-84ac-af08869b132c@github.com>

On Thu, 31 Jul 2025 02:31:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:
>> 
>>> 66:  * If the image source parameter to a constructor or method is non-null,
>>> 67:  * but does not reference valid accessible image data,
>>> 68:  * no exceptions will be thrown but the image will be unset,
>> 
>> "will behave as if unset" ?
>> or maybe 
>> "will behave as if uninitialized " ?
>
> @prrace Any objection to my suggestion of statement? I guess that is succinct and describe what's the end result!!
> `no exceptions will be thrown but the image will behave as if unset/uninitialized/null` doesn't sound right in my opinion as then user need to know "how it would behave" when image is unset or null which is basically image icon not getting rendered so I thought to cut the chase and describe the final result

> ?will behave as if the image is null?

That's got the same mention of null that Joe was questioning

>"no exceptions will be thrown but no image icon will be rendered"

That seems OK to me. I'd just drop the word 'icon'.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2248790134

From aturbanov at openjdk.org  Fri Aug  1 20:12:36 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 1 Aug 2025 20:12:36 GMT
Subject: RFR: 8362067: Remove unnecessary List.contains key from
 SpringLayout.Constraints.pushConstraint [v2]
In-Reply-To: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
References: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
Message-ID: <ZDoHhiJXlNZwmWMgrcsnRtS3-tcrHA_E78RAS0jcsIA=.faeac996-a4f3-4b20-806b-a83c9792c685@github.com>

> There is no need to call `List.contains` before `List.remove` call.
> `history` is an either `horizontalHistory` or `verticalHistory`. Both of them are ArrayList's.

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

  expand star import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24852/files
  - new: https://git.openjdk.org/jdk/pull/24852/files/2667de76..57bb716c

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

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

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

From aivanov at openjdk.org  Fri Aug  1 20:23:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Aug 2025 20:23:07 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <0TXAOQRqUnRE-AHJrl5yUjnYpEcYs2dAdvPCHoE2F08=.b1ee7514-7668-4e2b-84ac-af08869b132c@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
 <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
 <S9Buvgb6fkfHndrB-I8Tvs9o-H3KcyFtZZ9ZP8yMFGA=.722fdce0-d95b-4c2f-840c-bd2fa5e90aa5@github.com>
 <0TXAOQRqUnRE-AHJrl5yUjnYpEcYs2dAdvPCHoE2F08=.b1ee7514-7668-4e2b-84ac-af08869b132c@github.com>
Message-ID: <5KXytiPcV62T57sWYHJMAxAnj_q8916gBNF74vbDy2E=.e9beea71-0c2a-4d66-a431-9c991be6f891@github.com>

On Fri, 1 Aug 2025 20:09:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Any objection to my suggestion of statement? I guess that is succinct and describe what's the end result!!
>> `no exceptions will be thrown but the image will behave as if unset/uninitialized/null` doesn't sound right in my opinion as then user need to know "how it would behave" when image is unset or null which is basically image icon not getting rendered so I thought to cut the chase and describe the final result
>
>> ?will behave as if the image is null?
> 
> That's got the same mention of null that Joe was questioning
> 
>>"no exceptions will be thrown but no image icon will be rendered"
> 
> That seems OK to me. I'd just drop the word 'icon'.

To make things clearer, we may mention that the `getImage` method will return a non-null value, yet no image will be rendered because `{@link #getImageLoadStatus()}` will report `{@code MediaTracker.ERRORED}`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2248805256

From prr at openjdk.org  Fri Aug  1 20:24:58 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 20:24:58 GMT
Subject: RFR: 8359380: Rework deferral profile logic after JDK-8346465
In-Reply-To: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
References: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
Message-ID: <CqyQVkJQBBx9K4IHzypFtg2bG5irQvtwTRvOKbQvDtI=.0f9c3680-9274-4f8d-82cd-fd3143ae3f49@github.com>

On Tue, 8 Jul 2025 05:26:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
> 
> After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
> 
> This patch includes two changes:
> 
> 1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
> 
> 2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

Tests pass.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26179#pullrequestreview-3080471221

From aivanov at openjdk.org  Fri Aug  1 20:26:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Aug 2025 20:26:55 GMT
Subject: RFR: 8362067: Remove unnecessary List.contains key from
 SpringLayout.Constraints.pushConstraint [v2]
In-Reply-To: <ZDoHhiJXlNZwmWMgrcsnRtS3-tcrHA_E78RAS0jcsIA=.faeac996-a4f3-4b20-806b-a83c9792c685@github.com>
References: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
 <ZDoHhiJXlNZwmWMgrcsnRtS3-tcrHA_E78RAS0jcsIA=.faeac996-a4f3-4b20-806b-a83c9792c685@github.com>
Message-ID: <AUX6XLqZ9F3z-y_MM7vFzLqCXl8XcNIqRk6IYrpj5fE=.2147877d-bf06-492b-a46f-3eb6dfc3c219@github.com>

On Fri, 1 Aug 2025 20:12:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> There is no need to call `List.contains` before `List.remove` call.
>> `history` is an either `horizontalHistory` or `verticalHistory`. Both of them are ArrayList's.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   expand star import

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24852#pullrequestreview-3080475493

From prr at openjdk.org  Fri Aug  1 21:46:37 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 21:46:37 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v3]
In-Reply-To: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
Message-ID: <nyBeBQVye1P2e1K5doI-6I7XQIyMK4DkYQuEDjfx5M4=.c70992d8-959f-415e-9836-31da1b628f42@github.com>

> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
> 
> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.

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

  8363889

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26432/files
  - new: https://git.openjdk.org/jdk/pull/26432/files/45a5aa7c..b70e147e

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

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

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

From prr at openjdk.org  Fri Aug  1 21:46:38 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 21:46:38 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <JhKHluwEeVmjvBw5ytcm2wB80Z3JxAPWCXW0sGJLD3Q=.03c59949-b774-49a1-a059-801def8f354b@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
 <JhKHluwEeVmjvBw5ytcm2wB80Z3JxAPWCXW0sGJLD3Q=.03c59949-b774-49a1-a059-801def8f354b@github.com>
Message-ID: <bsWfWL63kXgKS1j7s2dRT9Dt9A5CGMZNnl6YqP3pqCo=.77d6a23c-e0bb-4897-8a98-55820b6b97ea@github.com>

On Fri, 1 Aug 2025 04:09:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8363889
>
> src/java.desktop/share/classes/sun/print/PrintJob2D.java line 35:
> 
>> 33: import java.awt.JobAttributes.*;
>> 34: import java.awt.PageAttributes;
>> 35: import java.awt.PageAttributes.*;
> 
> wildcard..probably it should be removed as it is used in Delegate class

yes, they aren't used in this class. I'll remove them.

> src/java.desktop/share/classes/sun/print/PrintJob2D.java line 115:
> 
>> 113:     }
>> 114: 
>> 115:     private static class PrintJobDisposerRecord implements DisposerRecord {
> 
> should we also make it a final class?

I don't see that it matters.

> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> should it be 2000? its a new class but its content is from 2000!!

Not sure what you are saying.
You seem to be saying it should say 2000 .. but it does .. and yes it should ...
The filename doesn't matter the material is what matters.

> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 36:
> 
>> 34: import java.awt.JobAttributes.*;
>> 35: import java.awt.PageAttributes;
>> 36: import java.awt.PageAttributes.*;
> 
> wildcard

Here I'm not 'cleaning up' anything. I just moved it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2248894928
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2248896184
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2248898997
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2248899448

From prr at openjdk.org  Fri Aug  1 21:46:38 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 21:46:38 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <YE6I7thMSRFf-HHHE4YigkqMyfkRKN_OkiEpM_uPWIQ=.6bb51aec-0d1d-4f95-9ec5-8e373af0ddc6@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
 <YE6I7thMSRFf-HHHE4YigkqMyfkRKN_OkiEpM_uPWIQ=.6bb51aec-0d1d-4f95-9ec5-8e373af0ddc6@github.com>
Message-ID: <w06yIM8gJEwW6kOSVWvelYeOgUwZ52h6nO_YdKPbP5s=.6ff04225-ccc8-4f7d-bf66-4294ca614800@github.com>

On Fri, 1 Aug 2025 12:40:40 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8363889
>
> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 824:
> 
>> 822:              */
>> 823:             //printGraphics = new ProxyPrintGraphics(currentGraphics.create(), this);
>> 824:             printGraphics =  currentGraphics.create();
> 
> Do we need the comment on line 823?
> 
>> The returned Graphics also  to implement PrintGraphics, so we  wrap the Graphics2D instance.
> 
> That doesn't seem true anymore.

Moving part of this comment back over to PrintJob2D.

> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 876:
> 
>> 874:      * Returns true if the last page will be printed first.
>> 875:      */
>> 876:     public boolean lastPageFirst() {
> 
> It appears to be unused.

because the method just returns false the delegate wasn't needed.
I decided to make it call the delegate anyway for consistency so now it is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2248902770
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2248914068

From prr at openjdk.org  Fri Aug  1 21:55:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 21:55:52 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <SFgzHGUAIICW4EOcwlQTNht3_Of8YlE9H7-ILbLcLFg=.bb6da4ca-5d72-47ec-85c1-b643161ee08b@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
 <SFgzHGUAIICW4EOcwlQTNht3_Of8YlE9H7-ILbLcLFg=.bb6da4ca-5d72-47ec-85c1-b643161ee08b@github.com>
Message-ID: <-Jo5mI2nhqULdUB1B_kZGjxDIftsLGuAwheTKy9nmMA=.502598f0-6f51-4f8f-8dcd-4ec07b42d155@github.com>

On Thu, 31 Jul 2025 04:12:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Guess wildcard import and copyright year fix can be done..

I'm not going looking for clean up here.

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

PR Comment: https://git.openjdk.org/jdk/pull/26397#issuecomment-3145861648

From prr at openjdk.org  Fri Aug  1 21:55:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 21:55:53 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <glYymbkZHShNQi_yi0gvLYqqrudLMDUFTRVS20Lv_aE=.4a5a381c-2d0f-48c7-8f59-782b56501db8@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
 <SFgzHGUAIICW4EOcwlQTNht3_Of8YlE9H7-ILbLcLFg=.bb6da4ca-5d72-47ec-85c1-b643161ee08b@github.com>
 <0AugtjRm8JvkkVaQfhEZWkc4Sr4q3jVsQ9WTbJ1DXSc=.98ed7882-3d25-461f-9efd-43683de2d059@github.com>
 <glYymbkZHShNQi_yi0gvLYqqrudLMDUFTRVS20Lv_aE=.4a5a381c-2d0f-48c7-8f59-782b56501db8@github.com>
Message-ID: <ttLsZaVWk99Zoo2l1e0syj3m4D9ZWikNNkTbMEx6Scw=.2abda3e4-2424-4b7d-b2b2-8828f4d778e9@github.com>

On Fri, 1 Aug 2025 03:18:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> And if it is 0, what would you do ?
>> Previously 0 meant it hadn't yet been initialized. Now it is always initialized.
>> 
>> You'd need to return it anyway even it was zero.
>
> Then I guess whoever is using the `nativeStrikePtr` should account for that it can receive null or 0..
> I haven't seen all cases but one case I saw `getFontMetrics `calls `getFontMetrics(getNativeStrikePtr())`
> and there it does this where it dereference `awtStrikePtr`...Shouldn't it cause SIGSEGV if it ever becomes 0?
> 
> 
> JNIEXPORT jobject JNICALL
> Java_sun_font_CStrike_getFontMetrics
>     (JNIEnv *env, jclass clazz, jlong awtStrikePtr)
> {
>     jobject metrics = NULL;
> 
> JNI_COCOA_ENTER(env);
>     AWT_FONT_CLEANUP_SETUP;
> 
>     AWTFont *awtfont = ((AWTStrike *)jlong_to_ptr(awtStrikePtr))->fAWTFont;

Nothing is different than before.
We return the result of calling createNativeStrikePtr() both before and after this fix.
So this is a pre-existing issue and one that I am not sure is very likely.
It would require the native alloc for the Objective C object to fail. 
And it probably would require all callers to be ready to handle it.
Dealing with that pre-existing theoretical problem is well outside the scope of this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26397#discussion_r2248923672

From achung at openjdk.org  Fri Aug  1 21:56:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 21:56:54 GMT
Subject: RFR: 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: <8bEe2OeUihKxm0TFkW13sHmQnQanxOVM3gfjHuAiwqk=.d407959b-e8b9-4f70-aa4c-4ca72c75237f@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.

I think adding an explanation of possible values to the return value makes it too wordy. The explanation of what can be returned should probably be put into the body of the specification. Maybe it would work as a note above the parameters?

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

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

From prr at openjdk.org  Fri Aug  1 22:16:16 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Aug 2025 22:16:16 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v27]
In-Reply-To: <eCmW66NgKnH5_U95zw397epT6L56urIJvBep6CZsFzc=.2a90af5c-1f36-4f70-bb3c-37730d76a7ad@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <eCmW66NgKnH5_U95zw397epT6L56urIJvBep6CZsFzc=.2a90af5c-1f36-4f70-bb3c-37730d76a7ad@github.com>
Message-ID: <kJxEiaViWmOtwlQQG-mtO64v7hk95nMfWgw1XnA0Y44=.9e2f07dc-99a1-4836-8a82-35c6c3757e81@github.com>

On Tue, 29 Jul 2025 21:40:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert robot set/get for step delay/length and readd glide(int,int,int,int,int,int), remove restriction on dist < stepLength and corresponding IAE from spec

src/java.desktop/share/classes/java/awt/Robot.java line 846:

> 844:     /**
> 845:      * A convenience method that moves the mouse in multiple
> 846:      * steps from its current location to the destination coordinates. Invokes

I think this is the text that caused Joe to write
"From reading the text, it should like the method would benefit from an @implSpec tag describing the behavior."
You can read about implSpec here https://bugs.openjdk.org/browse/JDK-8068562

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2248945478

From achung at openjdk.org  Fri Aug  1 23:49:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Aug 2025 23:49:54 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
Message-ID: <Ufro5a_cat-pG9ljuGzdJgzS5n-K2Crb4uhtv-dbztk=.9a65d5cf-1b87-4c53-b3e0-09310f8ef74f@github.com>

On Mon, 21 Jul 2025 16:52:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove finalize method from CStrike.java
>> 
>> This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
>> CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
>> CStrike.GlyphInfoCache is tracking all the glyph image references.
>> 
>> CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
>> for the native context
>> 
>> And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
>> but that native method does not exist !
>> And there's no CStrike.GlyphInfoCache constructor which allows it to be specified
>> 
>> So the fix is to add that and call the disposeNativeStrikePtr method instead.
>> 
>> I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8210765

I ran clientlibs test and everything looks good

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26397#pullrequestreview-3080786794

From azvegint at openjdk.org  Sat Aug  2 00:27:55 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 2 Aug 2025 00:27:55 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v3]
In-Reply-To: <nyBeBQVye1P2e1K5doI-6I7XQIyMK4DkYQuEDjfx5M4=.c70992d8-959f-415e-9836-31da1b628f42@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <nyBeBQVye1P2e1K5doI-6I7XQIyMK4DkYQuEDjfx5M4=.c70992d8-959f-415e-9836-31da1b628f42@github.com>
Message-ID: <WBTAQEALg5JxsSRM6kc_lEImYodN4bS_CV917AeiZlE=.e52a6caf-528c-4300-8499-503c93dba376@github.com>

On Fri, 1 Aug 2025 21:46:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
>> 
>> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363889

src/java.desktop/share/classes/sun/print/PrintJob2D.java line 127:

> 125: 
> 126:         public void dispose() {
> 127:             Thread.dumpStack();

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2249033958

From aoqi at openjdk.org  Sat Aug  2 00:56:02 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Sat, 2 Aug 2025 00:56:02 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <o0Ql3pw0oWtpI_OUT-8p7JAT-6AWe-U6mPY68U2_Hks=.08b1a4e7-6987-40d3-8093-0bfe498d7555@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3146072074

From duke at openjdk.org  Sat Aug  2 00:56:02 2025
From: duke at openjdk.org (duke)
Date: Sat, 2 Aug 2025 00:56:02 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <L3qIK6l9NPuTc7f0KVZQfRdEIkfvTpcUQD0w9Fo5x94=.417b0c2f-76a5-4734-a384-10f55c4a5547@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

@theaoqi 
Your change (at version 2078e5eb1336ff4f00dccc1702c2c11df32bc266) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3146072490

From prr at openjdk.org  Sat Aug  2 19:44:41 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 2 Aug 2025 19:44:41 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v4]
In-Reply-To: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
Message-ID: <nYX49JC2-3tTGGj-8PODwC4mwS_aLgFCqOopd-u3NJ4=.2559dedc-9bba-4ef3-b506-35367592b86d@github.com>

> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
> 
> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.

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

  8363889

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26432/files
  - new: https://git.openjdk.org/jdk/pull/26432/files/b70e147e..312840fc

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

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

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

From prr at openjdk.org  Sat Aug  2 19:44:41 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 2 Aug 2025 19:44:41 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v3]
In-Reply-To: <WBTAQEALg5JxsSRM6kc_lEImYodN4bS_CV917AeiZlE=.e52a6caf-528c-4300-8499-503c93dba376@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <nyBeBQVye1P2e1K5doI-6I7XQIyMK4DkYQuEDjfx5M4=.c70992d8-959f-415e-9836-31da1b628f42@github.com>
 <WBTAQEALg5JxsSRM6kc_lEImYodN4bS_CV917AeiZlE=.e52a6caf-528c-4300-8499-503c93dba376@github.com>
Message-ID: <4y4pdLcdgNV_OSpqYdnc5T5hGtDQOF9sYUObV2esIlY=.bd3eede3-00cc-41cd-b158-13d49179c6be@github.com>

On Sat, 2 Aug 2025 00:24:24 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8363889
>
> src/java.desktop/share/classes/sun/print/PrintJob2D.java line 127:
> 
>> 125: 
>> 126:         public void dispose() {
>> 127:             Thread.dumpStack();
> 
> Suggestion:

oops. removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2249371334

From psadhukhan at openjdk.org  Sun Aug  3 06:18:15 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 3 Aug 2025 06:18:15 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <5KXytiPcV62T57sWYHJMAxAnj_q8916gBNF74vbDy2E=.e9beea71-0c2a-4d66-a431-9c991be6f891@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
 <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
 <S9Buvgb6fkfHndrB-I8Tvs9o-H3KcyFtZZ9ZP8yMFGA=.722fdce0-d95b-4c2f-840c-bd2fa5e90aa5@github.com>
 <0TXAOQRqUnRE-AHJrl5yUjnYpEcYs2dAdvPCHoE2F08=.b1ee7514-7668-4e2b-84ac-af08869b132c@github.com>
 <5KXytiPcV62T57sWYHJMAxAnj_q8916gBNF74vbDy2E=.e9beea71-0c2a-4d66-a431-9c991be6f891@github.com>
Message-ID: <30yQsfVKSobJdFw24skkDEun-Ef83FTgzipEO1fR2-I=.fafbd3a6-6243-4a47-a0b4-26c31611e0cc@github.com>

On Fri, 1 Aug 2025 20:20:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> ?will behave as if the image is null?
>> 
>> That's got the same mention of null that Joe was questioning
>> 
>>>"no exceptions will be thrown but no image icon will be rendered"
>> 
>> That seems OK to me. I'd just drop the word 'icon'.
>
> To make things clearer, we may mention that the `getImage` method will return a non-null value, yet no image will be rendered because `{@link #getImageLoadStatus()}` will report `{@code MediaTracker.ERRORED}`.

Updated the class-level javadoc

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2249583976

From psadhukhan at openjdk.org  Sun Aug  3 06:18:14 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 3 Aug 2025 06:18:14 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

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

  class javadoc modification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/85f2a841..c6be2a91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=23-24

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

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

From psadhukhan at openjdk.org  Sun Aug  3 06:26:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 3 Aug 2025 06:26:03 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0
In-Reply-To: <LR56gUD-lr5heXd4rz9iVC4SvDlCMUJkVXO7_plBuLE=.145eb7ea-f327-4c25-b5e6-5697857f4caf@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <LR56gUD-lr5heXd4rz9iVC4SvDlCMUJkVXO7_plBuLE=.145eb7ea-f327-4c25-b5e6-5697857f4caf@github.com>
Message-ID: <2hCwbX522BypcHQMhMrOL6gx0gVPqSVT5C0wOzvQx-U=.17ac8712-fd4a-4865-a6aa-4e21a3b6220f@github.com>

On Fri, 1 Aug 2025 19:53:13 GMT, Phil Race <prr at openjdk.org> wrote:

> Isn't this just a bug ? I get zero from the test whenever "-1" is the direction - meaning scroll up - even if I use something like
> 
> https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/JList.html#getScrollableUnitIncrement(java.awt.Rectangle,int,int)

If the `visibleRect` Rectangle points to the 1st row or row 0 and we are scrolling up i.e -1 direction there is no more space to scroll up so `getScrollableUnitIncrement` returns 0.
If we modify the testcase to have `Rectangle cell = list.getCellBounds(data.length-1, data.length-1);` instead of `list.getCellBounds(0, 0);`
to point to last cell, it returns positive number for -1 direction too

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

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

From psadhukhan at openjdk.org  Sun Aug  3 06:27:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 3 Aug 2025 06:27:00 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
Message-ID: <OGDMz3FA5L_RLHq3KqdoXYuXeoRYFlVLSElYo9a9kI8=.d57f92cb-40e1-4dff-8895-372848e40da5@github.com>

On Mon, 21 Jul 2025 16:52:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove finalize method from CStrike.java
>> 
>> This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
>> CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
>> CStrike.GlyphInfoCache is tracking all the glyph image references.
>> 
>> CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
>> for the native context
>> 
>> And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
>> but that native method does not exist !
>> And there's no CStrike.GlyphInfoCache constructor which allows it to be specified
>> 
>> So the fix is to add that and call the disposeNativeStrikePtr method instead.
>> 
>> I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8210765

LGTM

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26397#pullrequestreview-3081745153

From lbourges at openjdk.org  Sun Aug  3 16:12:00 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 3 Aug 2025 16:12:00 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <3Wx2_FWhzlYu6UFfvDx_Z_p3yn-pt5YXfQ4owMBK7Dg=.10bc3175-adad-4889-a899-4dff3dd0e757@github.com>

On Thu, 31 Jul 2025 13:31:49 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

LGTM, not a reviewer

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3148522637

From abhiscxk at openjdk.org  Mon Aug  4 04:19:59 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 4 Aug 2025 04:19:59 GMT
Subject: Integrated: 8361298: SwingUtilities/bug4967768.java fails where
 character P is not underline
In-Reply-To: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
Message-ID: <39KK54VEi9cfoCduhJqAK2dLzg7HMeIPQJDBrE3YjG4=.2b251cc9-c516-4d1e-bd34-5e599d04f39f@github.com>

On Wed, 30 Jul 2025 06:22:56 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
> Test instruction updated to reflect the desired behaviour .

This pull request has now been integrated.

Changeset: 57553ca1
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57553ca1dbc63e329116bc11764816a4c5ccb297
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8361298: SwingUtilities/bug4967768.java fails where character P is not underline

Reviewed-by: dnguyen, psadhukhan, achung, azvegint

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

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

From psadhukhan at openjdk.org  Mon Aug  4 05:31:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 4 Aug 2025 05:31:46 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v38]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - Fix not needed background effect for Windows 10
 - Remove Windows version check
 - Merge master
 - bullet/checkmark placement for varying imageicon size fix, test update
 - Adjust offset for varying size imageicon
 - squish fix
 - Alignment fix
 - MenuItem with icon fix
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - ... and 32 more: https://git.openjdk.org/jdk/compare/57553ca1...5f51ecdc

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

Changes: https://git.openjdk.org/jdk/pull/23324/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=37
  Stats: 630 lines in 8 files changed: 524 ins; 81 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

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

From duke at openjdk.org  Mon Aug  4 05:40:05 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 4 Aug 2025 05:40:05 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>
 <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>
Message-ID: <XV9HovqNjlaWF0QLsYaujXb9vDJeKck--8K-F_XA0yU=.e884154d-6b20-46ae-8cc4-621b067928b7@github.com>

On Thu, 31 Jul 2025 20:55:49 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - 8358813: putting the actions in a TreeSet
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
>>  - 8358813: make input map types a static constant
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
>>  - Merge branch 'master' into JDK-8358813
>>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - 8358813: remove more bindings for JPasswordFields in Aqua
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 162:
> 
>> 160:                         "alt BACK_SPACE", null,
>> 161:                         "ctrl W", null,
>> 162:                         "alt DELETE", null
> 
> The change "works" for the test, but I'm not exactly sure what's changed here. When I make my own local test with a JPasswordField, the key binds don't do anything on Aqua. The `CTRL+W` seems to just input `W`. `ALT+BACK_SPACE` seems to just backspace the character before the carat. Can you help me understand this?
> 
> Also, I guess you can end in a trailing comma to match the previous format if you want. Either is OK.

@DamonGuy it sounds like maybe (?) you're not able to reproduce the original ticket?

Here's a video showing what I experience in JDK 24 vs what I see when I use this PR:
https://go.screenpal.com/watch/cTjfh4nI55H

Does this match what you're observing/experiencing, and if not: what do you see instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2250445813

From duke at openjdk.org  Mon Aug  4 05:59:41 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 4 Aug 2025 05:59:41 GMT
Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v8]
In-Reply-To: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
Message-ID: <jXuT7YM2TNa6mc2UiqDE4znf8QILfrd7UDy2ZU6FA1w=.84bab82b-b8d7-4cb6-8005-c5b0e09198b1@github.com>

> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
> 
> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
> 
> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
> 
> There are a cluster of four related PRs that share the GifComparison class in this PR.
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) (this one)
> 
> This bug can be observed reading these gif animations:
> https://pixabay.com/gifs/pattern-mandela-geometric-loading-20162/
> https://pixabay.com/gifs/colourful-paint-spiral-pattern-20276/
> https://pixabay.com/gifs/dance-party-dancer-dancing-girl-19993/
> https://pixabay.com/gifs/spiral-orbit-colourful-pattern-20278/
> https://pixabay.com/gifs/flower-smiley-happy-yellow-bright-11997/
> https://pixabay.com/gifs/ghost-spooky-halloween-horror-20223/
> https://pixabay.com/gifs/fish-tadpole-sperm-decorative-20078/
> https://pixabay.com/gifs/cat-kitten-black-cats-sleep-nap-20104/
> https://giphy.com/gifs/party-gzhreEYEFrEYw
> https://giphy.com/gifs/hello-happy-birthday-all-xRVUlSCqTTZRLMdUiC
> https://giphy.com/gifs/GpANv0ZGOo973DNPyg
> https://giphy.com/gifs/pinatafarmsapp-birthday-happy-pinata-farms-rrmf3fICPZWg1MMXOW
> https://pixabay.com/gifs/stars-twinkle-sky-universe-cosmos-13910/
> https://pixabay.com/gifs/laundry-washing-clean-clothes-18875/
> https://giphy.com/gifs/cat-white-mikitti-VItynXR1BzF5z0aTM7
> https://giphy.com/gifs/love-good-morning-cute-sTuKV3kHCkuc1hzd5C
> https://giphy.com/gifs/tv2norge-dance-celebration-birthday-duNowzaVje6Di3hnOu
> https://tenor.com/view/hasher-sticker-gif-24531859
> https://giphy.com/gifs/animanias-emoji-mickey-mouse-minnie-BeiTtDrExJZsoHzglJ
> https://giphy.com/gifs/morning-good-gm-dvwk9tqWYN8Wn2s4yn
> https://giphy.com/gifs/memoriachilena-familia-memoria-chilena-patrimonio-cultural-comn-7rRmOg13aXImUOEhO7
> https://giphy.com/gifs/thegoodpla...

Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into JDK-8351913
 - 8351913: re-wrapping line breaks
 - Merge branch 'master' into JDK-8351913
   
   # Conflicts:
   #	test/jdk/sun/awt/image/gif/GifComparison.java
 - Merge branch 'master' into JDK-8351913
 - 8356137: Adding copyright to GifComparison
 - 8356320: trivial whitespace and comment changes
 - Merge branch 'master' into JDK-8351913
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - 8351913: renaming class, rewording comment
   
   There's a cluster of 4 related gif tickets I intend to put in this /gif/ directory. I want to better clarify exactly what this test focuses on.
 - GifComparison: fixing error message
 - ... and 24 more: https://git.openjdk.org/jdk/compare/57553ca1...ad69988d

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

Changes: https://git.openjdk.org/jdk/pull/24271/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24271&range=07
  Stats: 53 lines in 4 files changed: 47 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/24271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24271/head:pull/24271

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

From aoqi at openjdk.org  Mon Aug  4 07:22:54 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 4 Aug 2025 07:22:54 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <cIW61FqCt8ZlKa-l-_4xI1bwQx1vR78UXSonKANecyI=.54fbb0cd-b3a9-46ff-ad51-9fe087c3987f@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

Could any committer please help to sponsor this patch?

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3149424916

From aturbanov at openjdk.org  Mon Aug  4 08:18:04 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 4 Aug 2025 08:18:04 GMT
Subject: Integrated: 8362067: Remove unnecessary List.contains key from
 SpringLayout.Constraints.pushConstraint
In-Reply-To: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
References: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
Message-ID: <vQbWPV0Wm2MXMI29SPs0cdUj8jdKhUMWskJvOHCbCvs=.6aec8bf5-e42c-4b24-8dda-b89a8de23205@github.com>

On Thu, 24 Apr 2025 14:53:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no need to call `List.contains` before `List.remove` call.
> `history` is an either `horizontalHistory` or `verticalHistory`. Both of them are ArrayList's.

This pull request has now been integrated.

Changeset: 8269fdc7
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8269fdc78ef40d8238bf1509531f5cfc25d54820
Stats:     11 lines in 1 file changed: 5 ins; 2 del; 4 mod

8362067: Remove unnecessary List.contains key from SpringLayout.Constraints.pushConstraint

Reviewed-by: aivanov

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

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

From jdv at openjdk.org  Mon Aug  4 08:37:57 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 4 Aug 2025 08:37:57 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image [v2]
In-Reply-To: <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
 <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
Message-ID: <lRC7M6d7Dw9SiG_CfzVZQxtOEQVpKxsMLYbyqeNX-fI=.634afeac-0967-4666-8e6f-502dd4034b72@github.com>

On Fri, 25 Jul 2025 23:58:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> XBM (X Bitmap) images are small one-bit deep images that were developed as a simple uncompressed format that could easily be included in C source files as include files.
>> 
>> Format of XBM image:
>> 
>> 
>>  #define width w
>>  #define height h
>>  static char foo_bits[] = {
>>  0xnn,0xnn,0xnn,0xnn,0xnn, .......
>>  0xnn,0xnn,0xnn,0xnn, .........
>>  0xnn,0xnn,0xnn,0xnn};
>> 
>> 
>> The first two #defines statements specify the width and height of the bitmap in pixels followed by hex byte array which represent pixel data itself.
>> 
>> The current implementation allows an arbitrarily large XBM which is not a valid use case for any XBM.
>> Also it doesn't validate that the provided byte array is sufficient to populate the specified WxH. Since these are small one-bit mono images a reasonable size limit is set to `MAX_XBM_SIZE = 16384 bytes`. It can be set to a larger limit if someone thinks it is necessary.
>> 
>> The XBMDecoder's produceImage() has outdated logic, it has been restructured by adding more efficient parser logic and better error handling checks.
>
> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename
>  - test summary

Apart from minor indentation issue, change looks good to me.

test/jdk/java/awt/image/XBMDecoder/XBMDecoderTest.java line 55:

> 53:             System.out.println("--- Testing " + fileName + " ---");
> 54:             try (FileInputStream fis = new FileInputStream(file);
> 55:                  ByteArrayOutputStream errContent = new ByteArrayOutputStream()) {

Indentation issue.

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26488#pullrequestreview-3083016584
PR Review Comment: https://git.openjdk.org/jdk/pull/26488#discussion_r2250642777

From jdv at openjdk.org  Mon Aug  4 09:23:56 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 4 Aug 2025 09:23:56 GMT
Subject: RFR: 8362898: Remove finalize() methods from javax.imagio TIFF
 classes.
In-Reply-To: <X-lrqNQSpo2EIYSMxAMUTqROPoXmKRqxfCV8OKTztQ8=.fe557cf2-0a8c-435d-bd94-fef78ccddac2@github.com>
References: <X-lrqNQSpo2EIYSMxAMUTqROPoXmKRqxfCV8OKTztQ8=.fe557cf2-0a8c-435d-bd94-fef78ccddac2@github.com>
Message-ID: <GO1VNqTtA0fnyJRt_BYAXWbcdxnUPIcxowZQFXFEOMk=.df0e7ade-1583-4c01-8aff-84cccaddc7ea@github.com>

On Mon, 21 Jul 2025 16:51:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize from TIFF ImageIO implementatation classes.
> 
> Following copied from the bug description 
> The TIFF image (de)compressors can make use of a JPEG reader / writer
> Like all ImageIO readers and writers, once done, the owner should call their dispose() method.
> This is currently done with finalize() to ensure it isn't missed.
> 
> This can be migrated to a Disposer.
> 
> However, the most common case is that it is the ImageIO built-in JPEGImageReader and JPEGImageWriter
> that is located and that already implements a Disposer. So there is no need to add a Disposer for that.
> We only need to add it if we find some other reader/writer.
> 
> With enough work, it might be possible for the TIFF compressor/decompressor classes to work out when
> they are really done and avoid a Disposer at all. But it could also be that they instead need to discard
> them when a specific task is done and then obtain a new one.
> That would be much more overhead than just adding a Disposer for the rare case and regardless
> of what is done in the TIFF code, the built in JPEG classes will install their own Disposer so I don't
> think I want to pursue that route.
> 
> I also noticed that TIFFBaseJPEGCompressor.java can replace the current writer if it doesn't satisfy a need.
> In that case it just nulls it out and doesn't call dispose() and of course finalize() will then refer to the replacement.
> So I added direct calls to dispose() in such a case. That was definitely necessary with the finalize() code
> but the Disposer would have taken care of it anyway, so it isn't strictly needed with the new code but
> it is still good to do it early if you can.

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26416#pullrequestreview-3083370345

From duke at openjdk.org  Mon Aug  4 09:24:52 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 09:24:52 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v13]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <lnD7RnVqtSGxOabb3bqeyD9iKPIufCCrRr9aWnX9ClQ=.0b645aa5-5f92-4fcc-a5a0-a106fcb6e746@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Merge branch 'openjdk:master' into jdk-8158801
 - Removes not needed component frace ancestor.
 - Problem unlists passed tests
 - Uses frame requestFocus instead of robot clicks for focus
 - Removes extra Robot waitForIdle
 - Merge branch 'openjdk:master' into jdk-8158801
 - Restores copyright year for tests not updated
 - Removes some tests from problem list
 - Uses request frame focus instead of Robot clicks to request frame focus
 - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
   
   This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
 - ... and 12 more: https://git.openjdk.org/jdk/compare/e38e8946...3cae7357

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/b558508f..3cae7357

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

  Stats: 19936 lines in 513 files changed: 10362 ins; 7997 del; 1577 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Mon Aug  4 09:48:36 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 09:48:36 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v14]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <sBgBAvbmRlp-klRdCRHzYS-MZkMZMB8QXRtALs-WYv0=.3603af56-6c47-48ec-9c16-75604280d5c4@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Removes wildcard imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/3cae7357..d986747c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=12-13

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

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

From duke at openjdk.org  Mon Aug  4 09:48:39 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 09:48:39 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v12]
In-Reply-To: <UNsbFD-Q9TMT4jj4Za2s3_EEo0boW0Y5y7rWxvnAcUo=.5fe26757-2130-4fcd-b59f-255bb64d3fe1@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
 <UNsbFD-Q9TMT4jj4Za2s3_EEo0boW0Y5y7rWxvnAcUo=.5fe26757-2130-4fcd-b59f-255bb64d3fe1@github.com>
Message-ID: <mFVcjIG4RXvgsEPFLI6BOcNwuSMonIAS-n87lCQR5rc=.0de906a0-13ac-4738-8e27-7450d4919465@github.com>

On Fri, 1 Aug 2025 07:36:52 GMT, Alisen Chung <achung 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 21 additional commits since the last revision:
>> 
>>  - Removes not needed component frace ancestor.
>>  - Problem unlists passed tests
>>  - Uses frame requestFocus instead of robot clicks for focus
>>  - Removes extra Robot waitForIdle
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Restores copyright year for tests not updated
>>  - Removes some tests from problem list
>>  - Uses request frame focus instead of Robot clicks to request frame focus
>>  - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
>>    
>>    This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
>>  - Revert "Removes passed tests from problem list"
>>    
>>    This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/bb7c29bf...b558508f
>
> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: import java.awt.*;
> 
> please expand wildcard imports

done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2250966324

From duke at openjdk.org  Mon Aug  4 10:07:58 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 10:07:58 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v12]
In-Reply-To: <4gcx7io3xNfusJ0OtErbmzQ5n2ywgvMk7Iz6jMXSHsI=.8437e6d1-aa15-4d19-aebc-4bb1ddbb3af4@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
 <4gcx7io3xNfusJ0OtErbmzQ5n2ywgvMk7Iz6jMXSHsI=.8437e6d1-aa15-4d19-aebc-4bb1ddbb3af4@github.com>
Message-ID: <cCfGTn4yE2uAft7znn9LUW5eiorCuscfUgqJ-pUujKI=.dc17b2b9-87f6-49ed-98f5-4f5ea67b9910@github.com>

On Thu, 31 Jul 2025 20:02:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
>> 
>>  - Removes not needed component frace ancestor.
>>  - Problem unlists passed tests
>>  - Uses frame requestFocus instead of robot clicks for focus
>>  - Removes extra Robot waitForIdle
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Restores copyright year for tests not updated
>>  - Removes some tests from problem list
>>  - Uses request frame focus instead of Robot clicks to request frame focus
>>  - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
>>    
>>    This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
>>  - Revert "Removes passed tests from problem list"
>>    
>>    This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/50b49291...b558508f
>
> I see that you filed all these 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
> 
> and not one of them has a description or evaluation.
> And the dependencies suggest they aren't completely unrelated.
> Also you will be making "N" problem list updates ..
> This would have been easier for people to follow and you to manage if it was ONE bug and ONE PR.
> I suggest you close all but one and deal with them all together.
> 
> Also be a bit more clear in why the change fixes it - I read comments like 
> "Changes heavyweight color to white, for the test to pass." - What was the problem and why does that fix it ?
> "Fixes failed test by disabling heavyweight component in ItemListener." - same issues.
> 
> I won't repeat everything like that but I need to be confident that you've understood the problem and can explain the fix.

@prrace Since all the listed bugs are sub-tasks of bug JDK-8360498, I will create one PR with this bug and include all fixes in it. I will close all subtask and link them to their parent bug JDK-8360498.

I will proceed with fixes and explain the issues encountered and why I suggest to fix it that way.

Please let me know if this is ok. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3149923164

From jdv at openjdk.org  Mon Aug  4 10:39:07 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 4 Aug 2025 10:39:07 GMT
Subject: RFR: 8356320: GifImageDecoder can produce wrong image when GCE
 changes transparent pixel index [v3]
In-Reply-To: <_PbpWiu5Ggo6nKOlpaJC0mBZl9vxDQln5Z-2q67O9iU=.26c8458c-813e-43b5-8a34-0b76b4dca6fe@github.com>
References: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
 <_PbpWiu5Ggo6nKOlpaJC0mBZl9vxDQln5Z-2q67O9iU=.26c8458c-813e-43b5-8a34-0b76b4dca6fe@github.com>
Message-ID: <duaSu7IeuQx6qDyMi1TrrwQBKb482a_fMn_cM_WHpSc=.be690c8d-f43c-4162-9934-96c3e6f79655@github.com>

On Fri, 11 Jul 2025 23:01:24 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) (this one)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> The test in this PR required [8356137's PR](https://github.com/openjdk/jdk/pull/25044) to pass.
>> 
>> This bug can be observed reading this gif animation:
>> https://tenor.com/view/fnf-free-download-fnf-free-download-fnf-fd-cyan-gif-15334412416964826224
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' into JDK-8356320
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - Merge branch 'master' into JDK-8356320
>  - 8356320: Use new GifBuilder and remove leo.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: trivial javadoc update
>  - 8356137: only inspect last frame of gif
>    
>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>  - 8356137: Adding copyright to GifComparison
>  - 8356320: trivial whitespace and comment changes
>  - Merge branch 'master' into JDK-8356320
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/a86dd56d...3deeb497

Code change looks good to me.
CI testing is green.

Please update the test to include image dumping logic for debugging.

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25076#pullrequestreview-3083612141

From azvegint at openjdk.org  Mon Aug  4 12:07:56 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 4 Aug 2025 12:07:56 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v4]
In-Reply-To: <nYX49JC2-3tTGGj-8PODwC4mwS_aLgFCqOopd-u3NJ4=.2559dedc-9bba-4ef3-b506-35367592b86d@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <nYX49JC2-3tTGGj-8PODwC4mwS_aLgFCqOopd-u3NJ4=.2559dedc-9bba-4ef3-b506-35367592b86d@github.com>
Message-ID: <fovVvHKK5DN0ch1qHfu_g-t-ZYrZ19vYPw3Sg1i60Zc=.7312686d-5f5e-405a-bc58-aaa1afabdbc0@github.com>

On Sat, 2 Aug 2025 19:44:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
>> 
>> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363889

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26432#pullrequestreview-3083875824

From aoqi at openjdk.org  Mon Aug  4 12:40:04 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 4 Aug 2025 12:40:04 GMT
Subject: Integrated: 8364177: JDK fails to build due to undefined symbol in
 libpng on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <gcE667FP9P6GmTsgDrIDuWuzCn9V6l6A1R7LWZ_aqkQ=.e73a231c-6e4d-46de-839e-25990f1c7ea0@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

This pull request has now been integrated.

Changeset: a9f3d3a2
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9f3d3a290060f98967feaad2fa03ef077a64534
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8364177: JDK fails to build due to undefined symbol in libpng on LoongArch64

Reviewed-by: prr, aivanov, erikj

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

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

From aoqi at openjdk.org  Mon Aug  4 13:14:13 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 4 Aug 2025 13:14:13 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <4HeV-EoMcR1tBbXn11liF56ksr2IuG1b7WhVW3_lsnk=.ae004f63-4a7e-45af-bad6-b86323ea7aec@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
 <4HeV-EoMcR1tBbXn11liF56ksr2IuG1b7WhVW3_lsnk=.ae004f63-4a7e-45af-bad6-b86323ea7aec@github.com>
Message-ID: <nE0oshLhf9J_xSlT2doxkLirAD2qLkXFLKzry-d-9UE=.79484802-5e8b-4131-a1d5-bb5a4a685980@github.com>

On Fri, 1 Aug 2025 18:26:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
>> 
>> 
>> #ifndef PNG_LOONGARCH_LSX_OPT
>> # if defined(__loongarch_sx)
>> # define PNG_LOONGARCH_LSX_OPT 1
>> # else
>> # define PNG_LOONGARCH_LSX_OPT 0
>> # endif
>> #endif
>> 
>> 
>> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.
>
> Marked as reviewed by erikj (Reviewer).

@erikj79, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3150658075

From azvegint at openjdk.org  Mon Aug  4 14:59:56 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 4 Aug 2025 14:59:56 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
Message-ID: <LCJpNGn6F4OVkLvjJImw8Mv6EnooPQXgRicntmZtVpg=.cdfade55-1728-4de5-be63-568758b0f656@github.com>

On Mon, 21 Jul 2025 16:52:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove finalize method from CStrike.java
>> 
>> This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
>> CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
>> CStrike.GlyphInfoCache is tracking all the glyph image references.
>> 
>> CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
>> for the native context
>> 
>> And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
>> but that native method does not exist !
>> And there's no CStrike.GlyphInfoCache constructor which allows it to be specified
>> 
>> So the fix is to add that and call the disposeNativeStrikePtr method instead.
>> 
>> I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8210765

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26397#pullrequestreview-3084618160

From simon at cjnash.com  Mon Aug  4 15:01:03 2025
From: simon at cjnash.com (Simon Nash)
Date: Mon, 4 Aug 2025 16:01:03 +0100
Subject: TrayIcon on macOS Tahoe beta
Message-ID: <a05a230f-a4d9-470c-d59f-ee3158544f5f@cjnash.com>

My application creates a tray icon and adds it to the system tray. This is no longer working on the macOS Tahoe beta. There are no errors from the Java API 
calls, just nothing shown in the macOS menu bar.

Is this a known issue with SystemTray/TrayIcon and macOS Tahoe?

Many thanks,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250804/dfe80c2d/attachment.htm>

From mvs at openjdk.org  Mon Aug  4 15:19:50 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 4 Aug 2025 15:19:50 GMT
Subject: RFR: 8364506: javax/swing/Popup/TaskbarPositionTest.java can fail
 subsequent tests on MacOS
Message-ID: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>

Issue:
javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to show all windows related to the focused one.

Fix:
Change the 'Cntrl' key to 'Shift'

Testing:
Tested in all supported platforms using mach5 and got all PASS.

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

Commit messages:
 - 8364506: javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS

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

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

From duke at openjdk.org  Mon Aug  4 16:07:01 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:07:01 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail
Message-ID: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>

This PR will consolidate fixes of the following bugs:

https://bugs.openjdk.org/browse/JDK-8361188
https://bugs.openjdk.org/browse/JDK-8361189
https://bugs.openjdk.org/browse/JDK-8361190
https://bugs.openjdk.org/browse/JDK-8361191
https://bugs.openjdk.org/browse/JDK-8361192
https://bugs.openjdk.org/browse/JDK-8361193
https://bugs.openjdk.org/browse/JDK-8361195

This PR depends on https://github.com/openjdk/jdk/pull/25971

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Checks if component is null for pixel color verification
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From duke at openjdk.org  Mon Aug  4 16:07:08 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:07:08 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
In-Reply-To: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>
References: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>
Message-ID: <qlj35Ea4V4CtoV7GunzqYpp8P-L1nd9ltTSi70TvQmg=.51b1abdc-f671-4373-bfb5-d7d3312a1e70@github.com>

On Mon, 7 Jul 2025 15:21:33 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.
> 
> Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

This PR fix will be moved to PR https://github.com/openjdk/jdk/pull/26625 and it will be closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26162#issuecomment-3151360763

From duke at openjdk.org  Mon Aug  4 16:07:09 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:07:09 GMT
Subject: Withdrawn: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
In-Reply-To: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>
References: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>
Message-ID: <_oyyqsDwSiB5g26tq0s0cO6pyB2FvVQgAYUXBVHwdnM=.2c20897c-57ac-4314-a92c-bca476cf15d4@github.com>

On Mon, 7 Jul 2025 15:21:33 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.
> 
> Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Aug  4 16:08:06 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:08:06 GMT
Subject: RFR: 8361190: Test
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java fails on MacOS X
In-Reply-To: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
References: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
Message-ID: <DJ-pIW87XpH3RWRHezdcY9iFI4xeNqCbNVO0CksR0B0=.7a0773a4-4977-44d9-9ceb-4e3b47769d55@github.com>

On Tue, 8 Jul 2025 16:34:31 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Add more timeout for the test to pass.

This PR fix will be moved to PR https://github.com/openjdk/jdk/pull/26625 and it will be closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26196#issuecomment-3151375750

From duke at openjdk.org  Mon Aug  4 16:08:10 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:08:10 GMT
Subject: RFR: 8361191: Test
 java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java fails on MacOS X
In-Reply-To: <Z_B9aJ4T479Bk9GxIR4eI35FZLpqYYcLarqrHru98VU=.f1beedce-3dd2-41a5-bc5c-f2a9b4565c3a@github.com>
References: <Z_B9aJ4T479Bk9GxIR4eI35FZLpqYYcLarqrHru98VU=.f1beedce-3dd2-41a5-bc5c-f2a9b4565c3a@github.com>
Message-ID: <xP17qE8hT6D1TVE7TyLt4LRMTDF4JCMmr39fAEi-tDo=.b49e96f3-01a4-4b74-a129-a9440df3fa2e@github.com>

On Tue, 8 Jul 2025 15:23:03 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Fixes failed test by disabling heavyweight component in ItemListener.

This PR fix will be moved to PR https://github.com/openjdk/jdk/pull/26625 and it will be closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26190#issuecomment-3151374981

From duke at openjdk.org  Mon Aug  4 16:08:07 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:08:07 GMT
Subject: Withdrawn: 8361190: Test
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java fails on MacOS X
In-Reply-To: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
References: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
Message-ID: <Oypw9tBpusRYH-kka0ij2y94hL0AhgMCajJujzDjijw=.79239a73-d587-4e32-81ba-8997e912e1ac@github.com>

On Tue, 8 Jul 2025 16:34:31 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Add more timeout for the test to pass.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Aug  4 16:08:10 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:08:10 GMT
Subject: Withdrawn: 8361191: Test
 java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java fails on MacOS X
In-Reply-To: <Z_B9aJ4T479Bk9GxIR4eI35FZLpqYYcLarqrHru98VU=.f1beedce-3dd2-41a5-bc5c-f2a9b4565c3a@github.com>
References: <Z_B9aJ4T479Bk9GxIR4eI35FZLpqYYcLarqrHru98VU=.f1beedce-3dd2-41a5-bc5c-f2a9b4565c3a@github.com>
Message-ID: <kbTTV8ehBpMHWXNCbJjhBSyEII8rvjIq8iWLfXJNnwo=.0f81da3e-dd8c-43de-a24d-beff92aecd1d@github.com>

On Tue, 8 Jul 2025 15:23:03 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Fixes failed test by disabling heavyweight component in ItemListener.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Aug  4 16:15:06 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:15:06 GMT
Subject: RFR: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X [v2]
In-Reply-To: <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>
References: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
 <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>
Message-ID: <-5DNe8V-PNdrpnls_2v-8uha2n3PdcMPfBRIbBVqbxk=.32065217-a7e8-4933-a5ba-6a4945a497e5@github.com>

On Tue, 8 Jul 2025 14:56:23 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Sets setOpaque for lightweight, and uses a compares colors with tolerance in MacOS X machines.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds extra space after if
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

This PR fix will be moved to PR https://github.com/openjdk/jdk/pull/26625 and it will be closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26166#issuecomment-3151403596

From duke at openjdk.org  Mon Aug  4 16:15:08 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:15:08 GMT
Subject: RFR: 8361192: Test
 java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java fails on all platforms
 [v3]
In-Reply-To: <IgQDG_RgscMb085M3rcF2a-mRAlWGPFfRNcUCsqH9Hs=.6df0d70a-1c88-4f39-97da-4712c028e128@github.com>
References: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
 <IgQDG_RgscMb085M3rcF2a-mRAlWGPFfRNcUCsqH9Hs=.6df0d70a-1c88-4f39-97da-4712c028e128@github.com>
Message-ID: <falQ_ZvwdGlNp2HR37dgp708k3Tz4il9LarCoIvkWc0=.09370520-a0c1-4694-85c6-235b265f52ed@github.com>

On Thu, 24 Jul 2025 08:18:32 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Changes heavyweight color to white, for the test to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

This PR fix will be moved to PR https://github.com/openjdk/jdk/pull/26625 and it will be closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26167#issuecomment-3151402565

From duke at openjdk.org  Mon Aug  4 16:15:07 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:15:07 GMT
Subject: Withdrawn: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X
In-Reply-To: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
References: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
Message-ID: <TJj9Jh4DBeRsNtfMTpPPJTTlKkFEK8i_XazDcjRBBWE=.6853487c-90e8-4b18-9b1e-0d791c3b7872@github.com>

On Mon, 7 Jul 2025 17:36:42 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Sets setOpaque for lightweight, and uses a compares colors with tolerance in MacOS X machines.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Aug  4 16:15:09 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:15:09 GMT
Subject: Withdrawn: 8361192: Test
 java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java fails on all platforms
In-Reply-To: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
References: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
Message-ID: <KcbsIIQ1DCEmbnBsP6kxLkmOaBO0KPtUjMH7c_fIDyM=.56340011-3f98-40ae-ab3a-c9161079609d@github.com>

On Mon, 7 Jul 2025 17:43:39 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Changes heavyweight color to white, for the test to pass.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Aug  4 16:16:59 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 4 Aug 2025 16:16:59 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v12]
In-Reply-To: <4gcx7io3xNfusJ0OtErbmzQ5n2ywgvMk7Iz6jMXSHsI=.8437e6d1-aa15-4d19-aebc-4bb1ddbb3af4@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
 <4gcx7io3xNfusJ0OtErbmzQ5n2ywgvMk7Iz6jMXSHsI=.8437e6d1-aa15-4d19-aebc-4bb1ddbb3af4@github.com>
Message-ID: <WQk58d-2LjK48cW74-P-UjGAJhedvipLeO6SOyTOGkc=.73d8b285-ce75-40da-ade1-06b703b8836a@github.com>

On Thu, 31 Jul 2025 20:02:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
>> 
>>  - Removes not needed component frace ancestor.
>>  - Problem unlists passed tests
>>  - Uses frame requestFocus instead of robot clicks for focus
>>  - Removes extra Robot waitForIdle
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Restores copyright year for tests not updated
>>  - Removes some tests from problem list
>>  - Uses request frame focus instead of Robot clicks to request frame focus
>>  - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
>>    
>>    This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
>>  - Revert "Removes passed tests from problem list"
>>    
>>    This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/769b88fd...b558508f
>
> I see that you filed all these 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
> 
> and not one of them has a description or evaluation.
> And the dependencies suggest they aren't completely unrelated.
> Also you will be making "N" problem list updates ..
> This would have been easier for people to follow and you to manage if it was ONE bug and ONE PR.
> I suggest you close all but one and deal with them all together.
> 
> Also be a bit more clear in why the change fixes it - I read comments like 
> "Changes heavyweight color to white, for the test to pass." - What was the problem and why does that fix it ?
> "Fixes failed test by disabling heavyweight component in ItemListener." - same issues.
> 
> I won't repeat everything like that but I need to be confident that you've understood the problem and can explain the fix.

@prrace bugs and PRs are closed as requested. All fixes will be consolidated under PR https://github.com/openjdk/jdk/pull/26625

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3151408467

From duke at openjdk.org  Mon Aug  4 17:02:00 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 4 Aug 2025 17:02:00 GMT
Subject: RFR: 8356320: GifImageDecoder can produce wrong image when GCE
 changes transparent pixel index [v3]
In-Reply-To: <_PbpWiu5Ggo6nKOlpaJC0mBZl9vxDQln5Z-2q67O9iU=.26c8458c-813e-43b5-8a34-0b76b4dca6fe@github.com>
References: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
 <_PbpWiu5Ggo6nKOlpaJC0mBZl9vxDQln5Z-2q67O9iU=.26c8458c-813e-43b5-8a34-0b76b4dca6fe@github.com>
Message-ID: <qVnXRFVjmxXAN3ebPo3bReDm6463kc40URjrjN7iyGQ=.bc325687-4fa4-4d9a-8b9d-0784608e497d@github.com>

On Fri, 11 Jul 2025 23:01:24 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) (this one)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> The test in this PR required [8356137's PR](https://github.com/openjdk/jdk/pull/25044) to pass.
>> 
>> This bug can be observed reading this gif animation:
>> https://tenor.com/view/fnf-free-download-fnf-free-download-fnf-fd-cyan-gif-15334412416964826224
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' into JDK-8356320
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - Merge branch 'master' into JDK-8356320
>  - 8356320: Use new GifBuilder and remove leo.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: trivial javadoc update
>  - 8356137: only inspect last frame of gif
>    
>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>  - 8356137: Adding copyright to GifComparison
>  - 8356320: trivial whitespace and comment changes
>  - Merge branch 'master' into JDK-8356320
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/a86dd56d...3deeb497

Regarding the image dumping logic: that will (mostly) automatically appear once we merge https://github.com/openjdk/jdk/pull/25264 (specifically https://github.com/openjdk/jdk/pull/25264/commits/b418a02d1d8854d58aa8da9805c69e1ddd640502 ). I'll remove `rfr` for now until that ticket is merged.

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

PR Comment: https://git.openjdk.org/jdk/pull/25076#issuecomment-3151582438

From duke at openjdk.org  Mon Aug  4 17:03:04 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Mon, 4 Aug 2025 17:03:04 GMT
Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v8]
In-Reply-To: <jXuT7YM2TNa6mc2UiqDE4znf8QILfrd7UDy2ZU6FA1w=.84bab82b-b8d7-4cb6-8005-c5b0e09198b1@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
 <jXuT7YM2TNa6mc2UiqDE4znf8QILfrd7UDy2ZU6FA1w=.84bab82b-b8d7-4cb6-8005-c5b0e09198b1@github.com>
Message-ID: <AsXy_EtOZq7qO_QtFgJFkzMDwCoZj4C1iXGEqO3yF_I=.5ab191e1-f5f7-4707-a676-6f2762317586@github.com>

On Mon, 4 Aug 2025 05:59:41 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
>> 
>> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
>> 
>> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) (this one)
>> 
>> This bug can be observed reading these gif animations:
>> https://pixabay.com/gifs/pattern-mandela-geometric-loading-20162/
>> https://pixabay.com/gifs/colourful-paint-spiral-pattern-20276/
>> https://pixabay.com/gifs/dance-party-dancer-dancing-girl-19993/
>> https://pixabay.com/gifs/spiral-orbit-colourful-pattern-20278/
>> https://pixabay.com/gifs/flower-smiley-happy-yellow-bright-11997/
>> https://pixabay.com/gifs/ghost-spooky-halloween-horror-20223/
>> https://pixabay.com/gifs/fish-tadpole-sperm-decorative-20078/
>> https://pixabay.com/gifs/cat-kitten-black-cats-sleep-nap-20104/
>> https://giphy.com/gifs/party-gzhreEYEFrEYw
>> https://giphy.com/gifs/hello-happy-birthday-all-xRVUlSCqTTZRLMdUiC
>> https://giphy.com/gifs/GpANv0ZGOo973DNPyg
>> https://giphy.com/gifs/pinatafarmsapp-birthday-happy-pinata-farms-rrmf3fICPZWg1MMXOW
>> https://pixabay.com/gifs/stars-twinkle-sky-universe-cosmos-13910/
>> https://pixabay.com/gifs/laundry-washing-clean-clothes-18875/
>> https://giphy.com/gifs/cat-white-mikitti-VItynXR1BzF5z0aTM7
>> https://giphy.com/gifs/love-good-morning-cute-sTuKV3kHCkuc1hzd5C
>> https://giphy.com/gifs/tv2norge-dance-celebration-birthday-duNowzaVje6Di3hnOu
>> https://tenor.com/view/hasher-sticker-gif-24531859
>> https://giphy.com/gifs/animanias-emoji-mickey-mouse-minnie-BeiTtDrExJZsoHzglJ
>> https://giphy.com/gifs/morning-good-gm-dvwk9tqWYN8Wn2s4yn
>> https://giphy.com/gifs/memoriachilena-familia-memoria-chilena-patrimo...
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into JDK-8351913
>  - 8351913: re-wrapping line breaks
>  - Merge branch 'master' into JDK-8351913
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - Merge branch 'master' into JDK-8351913
>  - 8356137: Adding copyright to GifComparison
>  - 8356320: trivial whitespace and comment changes
>  - Merge branch 'master' into JDK-8351913
>  - Merge branch 'master' of https://github.com/mickleness/jdk
>  - 8351913: renaming class, rewording comment
>    
>    There's a cluster of 4 related gif tickets I intend to put in this /gif/ directory. I want to better clarify exactly what this test focuses on.
>  - GifComparison: fixing error message
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/57553ca1...ad69988d

Once https://github.com/openjdk/jdk/pull/25264 is merged (specifically https://github.com/openjdk/jdk/pull/25264/commits/b418a02d1d8854d58aa8da9805c69e1ddd640502 ) this will include some new image dumping logic for debugging. I'll remove `rfr` for now until that ticket is merged.

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

PR Comment: https://git.openjdk.org/jdk/pull/24271#issuecomment-3151588621

From psadhukhan at openjdk.org  Mon Aug  4 18:20:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 4 Aug 2025 18:20:52 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <hUHBpa2T_QmENVCmARgeI37BQ5D2biexpAOPXi3BJkY=.8fdae740-361b-471b-8a79-21bcca20ff9b@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
 <V2RwVfV4XBSb2-dE2uOTD9QY50ehgAh1qBjPtbWfQgg=.97774559-f939-49c8-97d8-eb026aae17b4@github.com>
 <HL7C1P-P1cPx5Wcqj8YF_NaINgr2ea6fLoFeX4vy07o=.c52c3796-b395-47d6-bdcd-09e86a0a119c@github.com>
 <yaK9OSeq3upNWI9d8wBcrA9hfYV9CzXcez_83i0P9ZM=.1bdbe824-37af-4145-a327-0c790da9f66c@github.com>
 <hUHBpa2T_QmENVCmARgeI37BQ5D2biexpAOPXi3BJkY=.8fdae740-361b-471b-8a79-21bcca20ff9b@github.com>
Message-ID: <-UkrNnkVAzccBXulkP9CmSYaKNx71lLNL-xhdQNlFnM=.82f27029-4a3c-4d4d-835c-93e0c5f4c573@github.com>

On Thu, 24 Jul 2025 15:24:52 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> > > > What exactly is the failure thrown in Nimbus L&F? JBS says `PassFailJFrame.forceFail `is called From my running it seems the failure is `"java.lang.RuntimeException: leading cell is not aligned"` It can be a genuine issue for Nimbus since it behaves ok for other L&F..
> > > 
> > > 
> > > I ran into the same issue when I previously checked this. I can submit a Nimbus issue afterwards if needed. Wanted to handle the test here first.
> > 
> > 
> > But you are handling the test failure by just omitting Nimbus run, which is not the way to go about it in my opinion..
> 
> I have gone through the changes again and in converting the test, nothing Nimbus specific was touched. I can't re-run the old test due to its reliance on Applet. When converting the test, I don't believe anyone, including myself, tested it on Nimbus since the test doesn't cycle thru all LAFs. The error in Nimbus only seems to be due to `cellRect` sizing not matching `visRect`. I don't see how that's related to the changes in this test, and rather may be a Nimbus issue.

That's what I was saying that if it's a Nimbus issue it will not be alright to discard Nimbus testing from the test as it can be a product bug in Nimbus and we can use this regression test to fix that issue, so as a positive side no need to write a new regression test and maybe the bug summary can be changed to show it's failing in Nimbus with "java.lang.RuntimeException: leading cell is not aligned"

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

PR Comment: https://git.openjdk.org/jdk/pull/26165#issuecomment-3142098273

From prr at openjdk.org  Mon Aug  4 19:30:21 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Aug 2025 19:30:21 GMT
Subject: Integrated: 8363889: Update sun.print.PrintJob2D to use Disposer
In-Reply-To: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
Message-ID: <2LpZTRu63ncI22cI1q-m8ocGOZ8_br0t-XFB5Y0DlV0=.a022535b-afac-46fb-a640-138d2ec456bc@github.com>

On Tue, 22 Jul 2025 21:44:05 GMT, Phil Race <prr at openjdk.org> wrote:

> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
> 
> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.

This pull request has now been integrated.

Changeset: d1e362e9
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1e362e9a8aae7f2c095510633624ed90a1d3b78
Stats:     1147 lines in 2 files changed: 3 ins; 1114 del; 30 mod

8363889: Update sun.print.PrintJob2D to use Disposer

Reviewed-by: azvegint, psadhukhan

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

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

From prr at openjdk.org  Mon Aug  4 19:32:11 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Aug 2025 19:32:11 GMT
Subject: Integrated: 8210765: Remove finalize method in CStrike.java
In-Reply-To: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
Message-ID: <FR6Ux2teviEvZHylcppCHWcMKEcAyjv8BT0dS-bww2w=.4c0e5e92-d1dd-4855-89fe-713d2ff2afa4@github.com>

On Fri, 18 Jul 2025 20:51:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize method from CStrike.java
> 
> This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
> CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
> CStrike.GlyphInfoCache is tracking all the glyph image references.
> 
> CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
> for the native context
> 
> And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
> but that native method does not exist !
> And there's no CStrike.GlyphInfoCache constructor which allows it to be specified
> 
> So the fix is to add that and call the disposeNativeStrikePtr method instead.
> 
> I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.

This pull request has now been integrated.

Changeset: 0d0d93e8
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d0d93e8f6e2e6d0831b011e47da0c6069f6f4f5
Stats:     31 lines in 2 files changed: 7 ins; 15 del; 9 mod

8210765: Remove finalize method in CStrike.java

Reviewed-by: psadhukhan, achung, azvegint

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

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

From prr at openjdk.org  Mon Aug  4 19:32:24 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Aug 2025 19:32:24 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
Message-ID: <LtBIIRU-UAZFmMv_Mpi8Ab3sT5sf0T7vHwM-1WjHrig=.4e332093-6d1f-45f4-9494-92a9f14a85d9@github.com>

On Sun, 3 Aug 2025 06:18:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class javadoc modification

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-3085497821

From philip.race at oracle.com  Mon Aug  4 20:06:01 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 4 Aug 2025 13:06:01 -0700
Subject: TrayIcon on macOS Tahoe beta
In-Reply-To: <a05a230f-a4d9-470c-d59f-ee3158544f5f@cjnash.com>
References: <a05a230f-a4d9-470c-d59f-ee3158544f5f@cjnash.com>
Message-ID: <850c998e-de03-4bda-8446-42e7f63f99be@oracle.com>

Not known. And we've been running our tests on the beta. Specifically 
Damon has.
I just ran one of the basic jtreg tests (TrayIconAddTest.java) on the 
latest beta and it worked.
Wild guess: is your icon image transparent or translucent ? Maybe 
related to the menubar now being transparent.

-phil.


On 8/4/25 8:01 AM, Simon Nash wrote:
> My application creates a tray icon and adds it to the system tray. 
> This is no longer working on the macOS Tahoe beta. There are no errors 
> from the Java API calls, just nothing shown in the macOS menu bar.
>
> Is this a known issue with SystemTray/TrayIcon and macOS Tahoe?
>
> Many thanks,
> Simon


From damon.nguyen at oracle.com  Mon Aug  4 20:21:14 2025
From: damon.nguyen at oracle.com (Damon Nguyen)
Date: Mon, 4 Aug 2025 20:21:14 +0000
Subject: TrayIcon on macOS Tahoe beta
In-Reply-To: <850c998e-de03-4bda-8446-42e7f63f99be@oracle.com>
References: <a05a230f-a4d9-470c-d59f-ee3158544f5f@cjnash.com>
 <850c998e-de03-4bda-8446-42e7f63f99be@oracle.com>
Message-ID: <029BB048-99B5-4F28-9D9E-46B9BC043D45@oracle.com>

Hi Simon,

I have recently gone through tests against macOS 26 Tahoe and I can confirm that SystemTray/TrayIcon worked as expected. The icon appears in the menu bar similar to previous macOS versions. Can you provide a test case where the TrayIcon is not shown in the macOS menu bar? And could you attach an image with it as well? That would make it easier to look into.

Thanks,
Damon


> On Aug 4, 2025, at 1:06?PM, Philip Race <philip.race at oracle.com> wrote:
> 
> Not known. And we've been running our tests on the beta. Specifically Damon has.
> I just ran one of the basic jtreg tests (TrayIconAddTest.java) on the latest beta and it worked.
> Wild guess: is your icon image transparent or translucent ? Maybe related to the menubar now being transparent.
> 
> -phil.
> 
> 
> On 8/4/25 8:01 AM, Simon Nash wrote:
>> My application creates a tray icon and adds it to the system tray. This is no longer working on the macOS Tahoe beta. There are no errors from the Java API calls, just nothing shown in the macOS menu bar.
>> 
>> Is this a known issue with SystemTray/TrayIcon and macOS Tahoe?
>> 
>> Many thanks,
>> Simon
> 


From prr at openjdk.org  Mon Aug  4 20:28:17 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Aug 2025 20:28:17 GMT
Subject: Integrated: 8362898: Remove finalize() methods from javax.imageio TIFF
 classes
In-Reply-To: <X-lrqNQSpo2EIYSMxAMUTqROPoXmKRqxfCV8OKTztQ8=.fe557cf2-0a8c-435d-bd94-fef78ccddac2@github.com>
References: <X-lrqNQSpo2EIYSMxAMUTqROPoXmKRqxfCV8OKTztQ8=.fe557cf2-0a8c-435d-bd94-fef78ccddac2@github.com>
Message-ID: <88DNRWaf6e-T3RZmHazyEqXX1Onb8vBLr6D8HygjvYE=.b3e8c56c-2c34-4034-92e9-befeb74418e5@github.com>

On Mon, 21 Jul 2025 16:51:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize from TIFF ImageIO implementatation classes.
> 
> Following copied from the bug description 
> The TIFF image (de)compressors can make use of a JPEG reader / writer
> Like all ImageIO readers and writers, once done, the owner should call their dispose() method.
> This is currently done with finalize() to ensure it isn't missed.
> 
> This can be migrated to a Disposer.
> 
> However, the most common case is that it is the ImageIO built-in JPEGImageReader and JPEGImageWriter
> that is located and that already implements a Disposer. So there is no need to add a Disposer for that.
> We only need to add it if we find some other reader/writer.
> 
> With enough work, it might be possible for the TIFF compressor/decompressor classes to work out when
> they are really done and avoid a Disposer at all. But it could also be that they instead need to discard
> them when a specific task is done and then obtain a new one.
> That would be much more overhead than just adding a Disposer for the rare case and regardless
> of what is done in the TIFF code, the built in JPEG classes will install their own Disposer so I don't
> think I want to pursue that route.
> 
> I also noticed that TIFFBaseJPEGCompressor.java can replace the current writer if it doesn't satisfy a need.
> In that case it just nulls it out and doesn't call dispose() and of course finalize() will then refer to the replacement.
> So I added direct calls to dispose() in such a case. That was definitely necessary with the finalize() code
> but the Disposer would have taken care of it anyway, so it isn't strictly needed with the new code but
> it is still good to do it early if you can.

This pull request has now been integrated.

Changeset: dc4d9b48
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc4d9b4849f6557f290338643910f0b05751d748
Stats:     44 lines in 3 files changed: 31 ins; 4 del; 9 mod

8362898: Remove finalize() methods from javax.imageio TIFF classes

Reviewed-by: azvegint, jdv

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

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

From simon at cjnash.com  Mon Aug  4 21:10:53 2025
From: simon at cjnash.com (Simon Nash)
Date: Mon, 4 Aug 2025 22:10:53 +0100
Subject: TrayIcon on macOS Tahoe beta
In-Reply-To: <029BB048-99B5-4F28-9D9E-46B9BC043D45@oracle.com>
References: <a05a230f-a4d9-470c-d59f-ee3158544f5f@cjnash.com>
 <850c998e-de03-4bda-8446-42e7f63f99be@oracle.com>
 <029BB048-99B5-4F28-9D9E-46B9BC043D45@oracle.com>
Message-ID: <78904cf2-66ee-bcae-de7b-da402397943c@cjnash.com>

Hi Damon and Phil,
I have found the cause of this problem. On macOS Tahoe, a menu bar icon must be displayed from the main process of the application, not by a subprocess started 
by the main process. My application was using a subprocess to display the icon. Restructuring the application to display the icon from the main process has 
solved the problem. My apologies for the false alarm!

Best regards,
Simon

On 04/08/2025 21:21, Damon Nguyen wrote:
> Hi Simon,
>
> I have recently gone through tests against macOS 26 Tahoe and I can confirm that SystemTray/TrayIcon worked as expected. The icon appears in the menu bar similar to previous macOS versions. Can you provide a test case where the TrayIcon is not shown in the macOS menu bar? And could you attach an image with it as well? That would make it easier to look into.
>
> Thanks,
> Damon
>
>
>> On Aug 4, 2025, at 1:06?PM, Philip Race <philip.race at oracle.com> wrote:
>>
>> Not known. And we've been running our tests on the beta. Specifically Damon has.
>> I just ran one of the basic jtreg tests (TrayIconAddTest.java) on the latest beta and it worked.
>> Wild guess: is your icon image transparent or translucent ? Maybe related to the menubar now being transparent.
>>
>> -phil.
>>
>>
>> On 8/4/25 8:01 AM, Simon Nash wrote:
>>> My application creates a tray icon and adds it to the system tray. This is no longer working on the macOS Tahoe beta. There are no errors from the Java API calls, just nothing shown in the macOS menu bar.
>>>
>>> Is this a known issue with SystemTray/TrayIcon and macOS Tahoe?
>>>
>>> Many thanks,
>>> Simon

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

From prr at openjdk.org  Mon Aug  4 21:11:42 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Aug 2025 21:11:42 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v2]
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <5ukKwWzpYzEiAaeJ6YCIRmkg90Z4_UEgdxF7iKaGNn0=.c84a5018-c04d-4b18-a1a8-df4af8e8d16c@github.com>

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

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

  8364230

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26519/files
  - new: https://git.openjdk.org/jdk/pull/26519/files/f423e1d9..e37e57c2

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

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

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

From damon.nguyen at oracle.com  Mon Aug  4 23:33:57 2025
From: damon.nguyen at oracle.com (Damon Nguyen)
Date: Mon, 4 Aug 2025 23:33:57 +0000
Subject: TrayIcon on macOS Tahoe beta
In-Reply-To: <78904cf2-66ee-bcae-de7b-da402397943c@cjnash.com>
References: <a05a230f-a4d9-470c-d59f-ee3158544f5f@cjnash.com>
 <850c998e-de03-4bda-8446-42e7f63f99be@oracle.com>
 <029BB048-99B5-4F28-9D9E-46B9BC043D45@oracle.com>
 <78904cf2-66ee-bcae-de7b-da402397943c@cjnash.com>
Message-ID: <485EC7BE-0453-4CB0-9F9C-8F2E43B2242C@oracle.com>

Hi Simon,

Great to hear you got it to work. I appreciate the follow-up to better understand the reasoning/solution.

Thanks,
Damon

On Aug 4, 2025, at 2:10?PM, Simon Nash <simon at cjnash.com> wrote:

Hi Damon and Phil,
I have found the cause of this problem. On macOS Tahoe, a menu bar icon must be displayed from the main process of the application, not by a subprocess started by the main process. My application was using a subprocess to display the icon. Restructuring the application to display the icon from the main process has solved the problem. My apologies for the false alarm!

Best regards,
Simon

On 04/08/2025 21:21, Damon Nguyen wrote:

Hi Simon,

I have recently gone through tests against macOS 26 Tahoe and I can confirm that SystemTray/TrayIcon worked as expected. The icon appears in the menu bar similar to previous macOS versions. Can you provide a test case where the TrayIcon is not shown in the macOS menu bar? And could you attach an image with it as well? That would make it easier to look into.

Thanks,
Damon




On Aug 4, 2025, at 1:06?PM, Philip Race <philip.race at oracle.com><mailto:philip.race at oracle.com> wrote:

Not known. And we've been running our tests on the beta. Specifically Damon has.
I just ran one of the basic jtreg tests (TrayIconAddTest.java) on the latest beta and it worked.
Wild guess: is your icon image transparent or translucent ? Maybe related to the menubar now being transparent.

-phil.


On 8/4/25 8:01 AM, Simon Nash wrote:


My application creates a tray icon and adds it to the system tray. This is no longer working on the macOS Tahoe beta. There are no errors from the Java API calls, just nothing shown in the macOS menu bar.

Is this a known issue with SystemTray/TrayIcon and macOS Tahoe?

Many thanks,
Simon



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

From achung at openjdk.org  Tue Aug  5 02:42:24 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Aug 2025 02:42:24 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v28]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <GIoLhJo9JxasvtBTtaA3uSlIQxu02smXwYHrD1kh9JU=.f5c75fac-e8ed-4ada-9085-17bc98686fe0@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  moved sentence describing method behavior into implSpec tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/c0b1a260..b478652f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=26-27

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

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

From achung at openjdk.org  Tue Aug  5 02:42:24 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Aug 2025 02:42:24 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v27]
In-Reply-To: <kJxEiaViWmOtwlQQG-mtO64v7hk95nMfWgw1XnA0Y44=.9e2f07dc-99a1-4836-8a82-35c6c3757e81@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <eCmW66NgKnH5_U95zw397epT6L56urIJvBep6CZsFzc=.2a90af5c-1f36-4f70-bb3c-37730d76a7ad@github.com>
 <kJxEiaViWmOtwlQQG-mtO64v7hk95nMfWgw1XnA0Y44=.9e2f07dc-99a1-4836-8a82-35c6c3757e81@github.com>
Message-ID: <p1iiox9UmTlbneWi7BjlrYuVY4a6lSUPqqeXuktzabU=.90fc9b50-7e51-4584-9a40-3ff1d173c02e@github.com>

On Fri, 1 Aug 2025 22:13:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert robot set/get for step delay/length and readd glide(int,int,int,int,int,int), remove restriction on dist < stepLength and corresponding IAE from spec
>
> src/java.desktop/share/classes/java/awt/Robot.java line 846:
> 
>> 844:     /**
>> 845:      * A convenience method that moves the mouse in multiple
>> 846:      * steps from its current location to the destination coordinates. Invokes
> 
> I think this is the text that caused Joe to write
> "From reading the text, it should like the method would benefit from an @implSpec tag describing the behavior."
> You can read about implSpec here https://bugs.openjdk.org/browse/JDK-8068562

I've moved the description of the implementation into a implSpec tag for both glide(int int) and glide(int int int int). I'm not sure if and how the implSpec should be expanded to include more detail. Do you have any suggestions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2252966898

From kizune at openjdk.org  Tue Aug  5 04:58:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 5 Aug 2025 04:58:11 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
Message-ID: <8C94vMtiSaNxyFGwT5QVyRmWPRwepKEqsbW1F6V3nBM=.da7b5049-80fb-4486-b324-8f6b3636cc72@github.com>

On Sun, 3 Aug 2025 06:18:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class javadoc modification

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-3086506795

From rgupta at openjdk.org  Tue Aug  5 06:53:40 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Tue, 5 Aug 2025 06:53:40 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v7]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <x2T6mj7BWj_CJSyqdxk2lFHpebeK0DJuJ2C8N_-XUy0=.6b3d78a5-f598-4f9b-92c6-54f0a6d963c5@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

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

  8361067: Added linux check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/995c93b1..af4d38e1

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

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

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

From dnguyen at openjdk.org  Tue Aug  5 08:36:19 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 5 Aug 2025 08:36:19 GMT
Subject: Withdrawn: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
Message-ID: <AekXHUue3ejMxZbpjFyqrTIn2p2P2tAdMtHKsWojRlM=.1e3bb560-ef33-4780-86a0-e3318e6fdc12@github.com>

On Mon, 7 Jul 2025 16:51:58 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This test only fails in the automated portion on Windows with Nimbus LAF. The failure message is always that the leading cell is not aligned, but I see no obvious issues with the UI when testing myself. The test fails in older JDK versions as well. The original test relies on applet and cannot be run exactly, but this test was previously converted to remove all applet usage in [JDK-8354695](https://bugs.openjdk.org/browse/JDK-8354695). Since this test still fails on older JDKs and is not a regression, I chose to skip the test specifically for Nimbus LAF. I suspect this is better than ProblemListing the test for Windows since the test only fails on Windows if Nimbus LAF is used.
> 
> I also removed the automated failing of the test to allow the user to see the failure message before the test closes. Test instructions are updated to align with this.

This pull request has been closed without being integrated.

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

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

From dnguyen at openjdk.org  Tue Aug  5 09:38:33 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 5 Aug 2025 09:38:33 GMT
Subject: RFR: 8364363: Modify some manual test instructions
Message-ID: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>

When testing jtreg manual tests, some tests had unclear instructions. This PR is an attempt at updating these tests for clarity. 

`MouseDraggedOriginatedByScrollBarTest.java` works as expected when compared to native apps and outputs drag events even when the mouse pointer is dragged off of the scrollbar and window altogether. Events should still fire, but the previous instructions may make this confusing since it reads as if no events should be output to the textarea at all.

`TextAreaAppendScrollTest2.java` seems to not work when testing with the previous implementation of programmatically appending strings to the textarea. When I scroll down using the down arrow key, none of the text below would be visible when the textarea is scrolled down. However, it would show if I pressed `ENTER` to create a new line or manually modify the text in the textarea first. So instead, I have implemented the original reported approach to the test of adding a button to append a string to the textarea to test for automatic scrolling when the word is wrapped to a new line.

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

Commit messages:
 - Initial open commit
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a86dd56d...86f38b37

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

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

From rgupta at openjdk.org  Tue Aug  5 11:01:24 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Tue, 5 Aug 2025 11:01:24 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v8]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <nP0pBki2BE9FsuPR8u4ESpVwFWEKLIB1boPAFblhzJo=.3f293496-bed8-4985-b06b-289811ada287@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

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

  8361067: Summary updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/af4d38e1..fd70f19f

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

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

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

From aivanov at openjdk.org  Tue Aug  5 11:34:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Aug 2025 11:34:14 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
Message-ID: <n0zF6BroPP9idfd6G_pPwBCowHzHDeDpMdkpubzC3-A=.f15c1ae2-2aae-4856-bb9e-03e83e7673cf@github.com>

On Sun, 3 Aug 2025 06:18:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class javadoc modification

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 71:

> 69:  * even though {@link #getImage()} will return a non-null value,
> 70:  * as the image will have no dimensions
> 71:  * and {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.

What do you think about this version?
Suggestion:

 * If the image source parameter provided to a constructor or method is non-{@code null}
 * but does not reference valid or accessible image data, no exceptions will be thrown.
 * In this case, {@link #getImage()} will return a non-{@code null} value, but the image
 * will have no dimensions, and nothing will be rendered.
 * Additionally, {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.

Shorter sentences are easier to read, the statements are clearer.

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 74:

> 72:                            } else if (v == ArgVal.INVALID_DATA) {
> 73:                                expected = false;
> 74:                                new ImageIcon("file://" + imgName, "gif");

There's a discrepancy: `null` is tested with one-arg constructor whereas invalid data is tested with two-arg constructor which accepts the description in addition to the URL.

More over, `new ImageIcon("file://" + imgName, "gif")` does not call `ImageIcon(URL, String)` constructor, it calls `ImageIcon(String, String)`.

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 84:

> 82:                            } else if (v == ArgVal.INVALID_DATA) {
> 83:                                expected = false;
> 84:                                new ImageIcon(new byte[0], "gif");

Why not `new ImageIcon(new byte[0])`?

Why is it `new byte[0]` instead of `invalidData` that you seemingly created for the purpose of having invalid data?

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 90:

> 88:                        case IMAGE :
> 89:                            if (v == ArgVal.NULL) {
> 90:                                new ImageIcon((Image)null);

Suggestion:

                               new ImageIcon((Image) null);

I guess you advocated for having a space between the type cast operator and its argument.

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 116:

> 114:                    System.err.println("Did not receive expected exception for : " + a);
> 115:                    throw new RuntimeException("Test failed");
> 116:                 }

Suggestion:

                if (expected && !passed) {
                   throw new RuntimeException("Did not receive expected exception for: " + a);
                }

Why not throw a more meaningful error message, this would make analysing test failure easier. At the very least, you will be able to distinguish different types of failures without looking into the test log file.

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 120:

> 118:                    System.err.println("Received unexpected exception for : " + a);
> 119:                    throw new RuntimeException("Test failed");
> 120:                 }

Suggestion:

                if (!expected && !passed) {
                   throw new RuntimeException("Received unexpected exception for: " + a);
                }

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

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-3087840636
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2254034417
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2254046393
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2254052610
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2254054860
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2254063647
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2254065010

From duke at openjdk.org  Tue Aug  5 13:11:19 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 5 Aug 2025 13:11:19 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v2]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <Mz5WCbfLeeztyS_VkOP-hkSJGs-dORJ6bkdmBfdlSd4=.d6f31872-5f9c-4e62-99be-8217a48d5941@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971

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

 - Removes test from Problem List
 - Changes test timeout to 180 seconds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/6220e8de..861cbb3b

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

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

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

From aivanov at openjdk.org  Tue Aug  5 13:42:21 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Aug 2025 13:42:21 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <n0zF6BroPP9idfd6G_pPwBCowHzHDeDpMdkpubzC3-A=.f15c1ae2-2aae-4856-bb9e-03e83e7673cf@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
 <n0zF6BroPP9idfd6G_pPwBCowHzHDeDpMdkpubzC3-A=.f15c1ae2-2aae-4856-bb9e-03e83e7673cf@github.com>
Message-ID: <LOt3-OrDc6HEGMWJU_5xtfyzAcv5osYNBj9RwrCQ5s4=.4b933337-97a8-4560-91a6-ef66c7a3814a@github.com>

On Tue, 5 Aug 2025 11:19:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   class javadoc modification
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 71:
> 
>> 69:  * even though {@link #getImage()} will return a non-null value,
>> 70:  * as the image will have no dimensions
>> 71:  * and {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.
> 
> What do you think about this version?
> Suggestion:
> 
>  * If the image source parameter provided to a constructor or method is non-{@code null}
>  * but does not reference valid or accessible image data, no exceptions will be thrown.
>  * In this case, {@link #getImage()} will return a non-{@code null} value, but the image
>  * will have no dimensions, and nothing will be rendered.
>  * Additionally, {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.
> 
> Shorter sentences are easier to read, the statements are clearer.

@prrace What do you say about the above suggestion?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2254382619

From avu at openjdk.org  Tue Aug  5 13:48:07 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 5 Aug 2025 13:48:07 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC
In-Reply-To: <UC70cDpCeGrWoCpK69CxGyuIolLueAkPV1gEYc5VSDI=.d7b51c6a-6d91-4a22-82b4-6a76c5fba6fa@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <UC70cDpCeGrWoCpK69CxGyuIolLueAkPV1gEYc5VSDI=.d7b51c6a-6d91-4a22-82b4-6a76c5fba6fa@github.com>
Message-ID: <o60Goywr_tirm5QuH4iqeH6hpm8HsqQeRM2GFpIDbWE=.f7e61894-de0c-4596-a657-f01ebad04e29@github.com>

On Tue, 5 Aug 2025 13:25:19 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java line 103:
> 
>> 101:     protected static BufferedContext currentContext;
>> 102: 
>> 103:     private Reference<AccelSurface> validSrcDataRef = null;
> 
> I think that you can wrap these fields into Optional ones to simplify the state change verification.

For wrapping, you can use the following one-liner 
`Optional.ofNullable(val).flatMap(e -> Optional.of(new WeakReference(val)));`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2254404302

From avu at openjdk.org  Tue Aug  5 13:48:06 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 5 Aug 2025 13:48:06 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <UC70cDpCeGrWoCpK69CxGyuIolLueAkPV1gEYc5VSDI=.d7b51c6a-6d91-4a22-82b4-6a76c5fba6fa@github.com>

On Thu, 31 Jul 2025 13:31:49 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

Changes requested by avu (Committer).

src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java line 103:

> 101:     protected static BufferedContext currentContext;
> 102: 
> 103:     private Reference<AccelSurface> validSrcDataRef = null;

I think that you can wrap these fields into Optional ones to simplify the state change verification.

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

PR Review: https://git.openjdk.org/jdk/pull/26576#pullrequestreview-3088271616
PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2254341082

From avu at openjdk.org  Tue Aug  5 13:51:03 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 5 Aug 2025 13:51:03 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <3lFIwMgLt4s7Cac3cTbcjW7dazoAQFt_yxQO4kqp_RI=.ba9cd419-e1f3-4d30-a476-416d45eb41da@github.com>

On Thu, 31 Jul 2025 13:31:49 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

Also, could you add a regression test based on your sample in the issue

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3155303327

From duke at openjdk.org  Tue Aug  5 14:11:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 5 Aug 2025 14:11:50 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v3]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <RE046-hzN2EGYWDiOuj_0ZD-r5eUNtvGmsuf4mCI6CM=.b6dd373d-e164-4198-ba65-410a550bd01e@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971

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

 - Removes test from Problem List
 - Disables frame in ItemListener

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/861cbb3b..b54f41ed

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

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

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

From duke at openjdk.org  Tue Aug  5 15:19:12 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 5 Aug 2025 15:19:12 GMT
Subject: RFR: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X [v2]
In-Reply-To: <C5vFtOkDr3hRSGBmShdiFs4dmzmQcLTDUSPE-y53qCY=.86d8fb9c-87fe-402c-a779-b2f3e2fca4df@github.com>
References: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
 <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>
 <C5vFtOkDr3hRSGBmShdiFs4dmzmQcLTDUSPE-y53qCY=.86d8fb9c-87fe-402c-a779-b2f3e2fca4df@github.com>
Message-ID: <_xaCuww-6O4Pp68JfZi-mXYih_Dbl1foU_DHkLGN-fM=.8876f0aa-5c49-4324-bc8a-ce254efed455@github.com>

On Fri, 1 Aug 2025 07:49:22 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds extra space after if
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> Test is failing for me locally on macOS even after the fix.
> Test fails at line 163: Execution failed: `main' threw exception: java.lang.RuntimeException: JButton was not redrawn properly on AWT Panel during move
> Maybe it would be good to add some debug statements with the color that robot.getPixelColor returns.

@alisenchung I will add debug statements as requested.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 304:
> 
>> 302:     }//fail()
>> 303:     private static boolean isAlmostEqualColor(Color color, Color refColor) {
>> 304:         final int COLOR_TOLERANCE_MACOSX = 10;
> 
> I think this field should go with the other final variables at the top for visibility

Done. The requested changes is now in PR https://github.com/openjdk/jdk/pull/26625

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

PR Comment: https://git.openjdk.org/jdk/pull/26166#issuecomment-3155643037
PR Review Comment: https://git.openjdk.org/jdk/pull/26166#discussion_r2254664239

From duke at openjdk.org  Tue Aug  5 16:14:42 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 5 Aug 2025 16:14:42 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v4]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <RdThkwJfNupCpudAOenkkSMxTl5tOHEtJ4O5_dcpRP4=.8d3d0940-576e-4ac1-8d93-4e7a00f055d5@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971

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

 - Adds more debugging for picked color
 - Removes test from Problem List
 - Fixes color comparison on for MacOS X
 - Problem unlist test
 - Updates copyright years
 - Sets heavyweight background and foreground colors different than the back frame color

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/b54f41ed..e840a719

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

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

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

From duke at openjdk.org  Tue Aug  5 16:18:41 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 5 Aug 2025 16:18:41 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971

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

  Updates copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e840a719..ed3707ad

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

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

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

From prr at openjdk.org  Tue Aug  5 18:39:28 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Aug 2025 18:39:28 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v28]
In-Reply-To: <GIoLhJo9JxasvtBTtaA3uSlIQxu02smXwYHrD1kh9JU=.f5c75fac-e8ed-4ada-9085-17bc98686fe0@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <GIoLhJo9JxasvtBTtaA3uSlIQxu02smXwYHrD1kh9JU=.f5c75fac-e8ed-4ada-9085-17bc98686fe0@github.com>
Message-ID: <3mNmmwQoRzF4EdqSEpvJ7nlSi6PCsEzzFYi4C2fQPwM=.61ba0e1e-1ebc-40f9-8e96-d720c14b40a6@github.com>

On Tue, 5 Aug 2025 02:42:24 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved sentence describing method behavior into implSpec tag

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22044#pullrequestreview-3089309197

From prr at openjdk.org  Tue Aug  5 18:47:12 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Aug 2025 18:47:12 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
Message-ID: <jAsyiv0ErIAPM2zxobG__u34kasaS3LfaVERvIz7FTw=.153ac724-920f-4963-8747-61250a268e0d@github.com>

On Sun, 3 Aug 2025 06:18:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class javadoc modification

This PR seems to be back waiting on the CSR ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3156215250

From prr at openjdk.org  Tue Aug  5 18:47:13 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Aug 2025 18:47:13 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <LOt3-OrDc6HEGMWJU_5xtfyzAcv5osYNBj9RwrCQ5s4=.4b933337-97a8-4560-91a6-ef66c7a3814a@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
 <n0zF6BroPP9idfd6G_pPwBCowHzHDeDpMdkpubzC3-A=.f15c1ae2-2aae-4856-bb9e-03e83e7673cf@github.com>
 <LOt3-OrDc6HEGMWJU_5xtfyzAcv5osYNBj9RwrCQ5s4=.4b933337-97a8-4560-91a6-ef66c7a3814a@github.com>
Message-ID: <NyGa6EAd-QqWiQFrkGTpbx-JgW6G8yJtwrVeNz8ZyKI=.4123517a-5c9c-4815-ba8c-cb42f694fd3a@github.com>

On Tue, 5 Aug 2025 13:39:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 71:
>> 
>>> 69:  * even though {@link #getImage()} will return a non-null value,
>>> 70:  * as the image will have no dimensions
>>> 71:  * and {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.
>> 
>> What do you think about this version?
>> Suggestion:
>> 
>>  * If the image source parameter provided to a constructor or method is non-{@code null}
>>  * but does not reference valid or accessible image data, no exceptions will be thrown.
>>  * In this case, {@link #getImage()} will return a non-{@code null} value, but the image
>>  * will have no dimensions, and nothing will be rendered.
>>  * Additionally, {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.
>> 
>> Shorter sentences are easier to read, the statements are clearer.
>
> @prrace What do you say about the above suggestion?

I prefer one sentence because these aren't disjoint statements.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2255071686

From prr at openjdk.org  Tue Aug  5 18:50:04 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Aug 2025 18:50:04 GMT
Subject: RFR: 8364363: Modify some manual test instructions
In-Reply-To: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
References: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
Message-ID: <YQfjnkiD400jFFTPkSlKZGfLR2HdkwZuCi17epi3CHk=.8a8cf203-0f74-477b-be51-bbe7be5c4766@github.com>

On Tue, 5 Aug 2025 09:33:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> When testing jtreg manual tests, some tests had unclear instructions. This PR is an attempt at updating these tests for clarity. 
> 
> `MouseDraggedOriginatedByScrollBarTest.java` works as expected when compared to native apps and outputs drag events even when the mouse pointer is dragged off of the scrollbar and window altogether. Events should still fire, but the previous instructions may make this confusing since it reads as if no events should be output to the textarea at all.
> 
> `TextAreaAppendScrollTest2.java` seems to not work when testing with the previous implementation of programmatically appending strings to the textarea. When I scroll down using the down arrow key, none of the text below would be visible when the textarea is scrolled down. However, it would show if I pressed `ENTER` to create a new line or manually modify the text in the textarea first. So instead, I have implemented the original reported approach to the test of adding a button to append a string to the textarea to test for automatic scrolling when the word is wrapped to a new line.

test/jdk/java/awt/TextArea/TextAreaAppendScrollTest2.java line 42:

> 40:     TextArea area;
> 41:     private static final String INSTRUCTIONS = """
> 42:             Press the "Append \'cool\' button until you are able

Is this necessary even on X11 ? The test seems to have been written for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2255078949

From aivanov at openjdk.org  Tue Aug  5 19:57:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Aug 2025 19:57:11 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <jAsyiv0ErIAPM2zxobG__u34kasaS3LfaVERvIz7FTw=.153ac724-920f-4963-8747-61250a268e0d@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
 <jAsyiv0ErIAPM2zxobG__u34kasaS3LfaVERvIz7FTw=.153ac724-920f-4963-8747-61250a268e0d@github.com>
Message-ID: <2_FsHSSzQOuwEr3e2-xAEnA3HKDRO-gd4r1ppjC6iQQ=.3a5f6809-88c2-4b23-95d3-506ab872762f@github.com>

On Tue, 5 Aug 2025 18:44:18 GMT, Phil Race <prr at openjdk.org> wrote:

> This PR seems to be back waiting on the CSR ?

Yes, because the text was updated.

Additionally, the test needs updating because it doesn't test ImageIcon(URL) constructor, it tests `ImageIcon(String)` twice.

https://github.com/openjdk/jdk/blob/c6be2a91aa37b19168985d9d6aec2f668343160c/test/jdk/javax/swing/ImageIcon/ImageIconTest.java#L69-L76

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3156447154

From kizune at openjdk.org  Tue Aug  5 19:59:03 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 5 Aug 2025 19:59:03 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v2]
In-Reply-To: <5ukKwWzpYzEiAaeJ6YCIRmkg90Z4_UEgdxF7iKaGNn0=.c84a5018-c04d-4b18-a1a8-df4af8e8d16c@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <5ukKwWzpYzEiAaeJ6YCIRmkg90Z4_UEgdxF7iKaGNn0=.c84a5018-c04d-4b18-a1a8-df4af8e8d16c@github.com>
Message-ID: <Yv119fL-4TUPvdEpkZbd0zBb_tFRCNnbEZ7GpmXyJ8c=.40df66a9-f5a5-42ea-8e43-42eb243f948c@github.com>

On Mon, 4 Aug 2025 21:11:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Convert StringContent's Position usage tracking to use a WeakReference
>> 
>> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364230

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26519#pullrequestreview-3089542308

From aivanov at openjdk.org  Tue Aug  5 20:00:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Aug 2025 20:00:15 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <NyGa6EAd-QqWiQFrkGTpbx-JgW6G8yJtwrVeNz8ZyKI=.4123517a-5c9c-4815-ba8c-cb42f694fd3a@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
 <n0zF6BroPP9idfd6G_pPwBCowHzHDeDpMdkpubzC3-A=.f15c1ae2-2aae-4856-bb9e-03e83e7673cf@github.com>
 <LOt3-OrDc6HEGMWJU_5xtfyzAcv5osYNBj9RwrCQ5s4=.4b933337-97a8-4560-91a6-ef66c7a3814a@github.com>
 <NyGa6EAd-QqWiQFrkGTpbx-JgW6G8yJtwrVeNz8ZyKI=.4123517a-5c9c-4815-ba8c-cb42f694fd3a@github.com>
Message-ID: <bciPU4NY1Z2IPAEA5hWIbXDvZrklvKkso8F6nm1DYJY=.ab288e23-ed49-4e99-8542-d988a65c4c05@github.com>

On Tue, 5 Aug 2025 18:43:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace What do you say about the above suggestion?
>
> I prefer one sentence because these aren't disjoint statements.

Okay. They're still the same statements in a few sentences rather than in one long sentence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2255215942

From aivanov at openjdk.org  Tue Aug  5 20:15:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Aug 2025 20:15:03 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v3]
In-Reply-To: <pRA0pQIz4irlOxCx7T4Tu6OLRrPDfuEAoYeaZg_Fl1s=.23da5d33-8993-45fa-b9db-9102c7f9717e@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <pRA0pQIz4irlOxCx7T4Tu6OLRrPDfuEAoYeaZg_Fl1s=.23da5d33-8993-45fa-b9db-9102c7f9717e@github.com>
Message-ID: <CC11nZNpuiaSUjTfgYkuCvUoxGvH5hlBx2O2XG6EDzA=.426c4273-5163-43ed-8e67-b996e5ac3bee@github.com>

On Fri, 1 Aug 2025 02:26:44 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>   
>   Co-authored-by: DamonGuy <damon.nguyen at oracle.com>

test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 81:

> 79:      * These are all the actions with "word" in their field name.
> 80:      */
> 81:     static Collection<String> wordActions = new TreeSet<>(Arrays.asList(

Would `Set.of` do the job?

Perhaps, `List.of` would be as good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2255241147

From aivanov at openjdk.org  Tue Aug  5 20:20:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Aug 2025 20:20:07 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>
 <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>
Message-ID: <zwGT_i2rpa21cpEO3VpWMMwW2NwyQ2LUlAqo2BYsX6A=.9986e23d-71b3-450f-abce-0d45ccfdef77@github.com>

On Thu, 31 Jul 2025 20:55:49 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - 8358813: putting the actions in a TreeSet
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
>>  - 8358813: make input map types a static constant
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
>>  - Merge branch 'master' into JDK-8358813
>>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - 8358813: remove more bindings for JPasswordFields in Aqua
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 162:
> 
>> 160:                         "alt BACK_SPACE", null,
>> 161:                         "ctrl W", null,
>> 162:                         "alt DELETE", null
> 
> The change "works" for the test, but I'm not exactly sure what's changed here. When I make my own local test with a JPasswordField, the key binds don't do anything on Aqua. The `CTRL+W` seems to just input `W`. `ALT+BACK_SPACE` seems to just backspace the character before the carat. Can you help me understand this?
> 
> Also, I guess you can end in a trailing comma to match the previous format if you want. Either is OK.

@DamonGuy I can reproduce the problem with the test, `PasswordSelectionWordTest.java`, attached to [JDK-8358813](https://bugs.openjdk.org/browse/JDK-8358813).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2255252897

From aivanov at openjdk.org  Tue Aug  5 20:24:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Aug 2025 20:24:04 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <zwGT_i2rpa21cpEO3VpWMMwW2NwyQ2LUlAqo2BYsX6A=.9986e23d-71b3-450f-abce-0d45ccfdef77@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>
 <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>
 <zwGT_i2rpa21cpEO3VpWMMwW2NwyQ2LUlAqo2BYsX6A=.9986e23d-71b3-450f-abce-0d45ccfdef77@github.com>
Message-ID: <aY8u24zTZce7irSte1vD-gOeUIm0XhAg6CBnMps7JNo=.2c3354b0-9c74-4954-b453-50429d3ea92a@github.com>

On Tue, 5 Aug 2025 20:17:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 162:
>> 
>>> 160:                         "alt BACK_SPACE", null,
>>> 161:                         "ctrl W", null,
>>> 162:                         "alt DELETE", null
>> 
>> The change "works" for the test, but I'm not exactly sure what's changed here. When I make my own local test with a JPasswordField, the key binds don't do anything on Aqua. The `CTRL+W` seems to just input `W`. `ALT+BACK_SPACE` seems to just backspace the character before the carat. Can you help me understand this?
>> 
>> Also, I guess you can end in a trailing comma to match the previous format if you want. Either is OK.
>
> @DamonGuy I can reproduce the problem with the test, `PasswordSelectionWordTest.java`, attached to [JDK-8358813](https://bugs.openjdk.org/browse/JDK-8358813).

> Also, I guess you can end in a trailing comma to match the previous format if you want. Either is OK.

This is a nice suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2255259873

From prr at openjdk.org  Tue Aug  5 21:26:44 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Aug 2025 21:26:44 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method from
 javax.imageio.stream APIs
Message-ID: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>

This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
As a result, sub-classes which over-ride it to be empty no longer need to do so.
Also it means that the 2 remaining classes which used it no longer can.
FileCacheImageOutputStream will have its cache cleaned up by a disposer.
The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
really meant to clean up internal resources.
The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.

The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
The risks of this will be covered in the CSR.

There's also a lengthy write up in the JBS issue.

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

Commit messages:
 - 8277585
 - 8277585

Changes: https://git.openjdk.org/jdk/pull/26650/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26650&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277585
  Stats: 276 lines in 10 files changed: 63 ins; 202 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26650/head:pull/26650

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

From prr at openjdk.org  Tue Aug  5 21:43:05 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Aug 2025 21:43:05 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features [v2]
In-Reply-To: <AmSJyVF1G5KSGmEKbU5b-0ToJwExct2Z_ldQnqndVEI=.05223bff-e6e6-4cc2-9a36-436beda3077e@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <2wtH9yzh-z77a2X0-Lv1wBBlQk7SwZhcLCaKTK_-FUU=.ceeb4cb1-68c6-4009-a8ad-b09678c8e047@github.com>
 <AmSJyVF1G5KSGmEKbU5b-0ToJwExct2Z_ldQnqndVEI=.05223bff-e6e6-4cc2-9a36-436beda3077e@github.com>
Message-ID: <3o_fjxhOQwxsqeh0wNW_JecCROcOUWBhCEvbSeqnbJE=.33f2520e-38a3-4fe6-9b28-a295f5027626@github.com>

On Sat, 12 Jul 2025 07:47:26 GMT, Valery Semenchuk <duke at openjdk.org> wrote:

> Sure. My mistake

I don't think you need to reply to a bot :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3156733674

From prr at openjdk.org  Tue Aug  5 21:47:07 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Aug 2025 21:47:07 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features
In-Reply-To: <1w4F6Xm6XdTuuErRsQUyXhCa7DYd_P7MKctT6SkNeC4=.88032ea8-9f51-40dd-ad33-d6a1ba8f9b99@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <foHud3SBXwVBkUVmYRoKO5ybxJUGpYgs3938DCG4vR4=.77d6fce3-8540-4fec-9c8c-78725182d1a4@github.com>
 <pbR1Da7KATa7bQ2hVoGR3dm5QIdqzUgdzPfA1IFYmlU=.4b1910ee-7b7d-4ecd-b239-6c896c79dcc4@github.com>
 <1w4F6Xm6XdTuuErRsQUyXhCa7DYd_P7MKctT6SkNeC4=.88032ea8-9f51-40dd-ad33-d6a1ba8f9b99@github.com>
Message-ID: <wwp260jJtrBlIx6wZmjYLgKOAnhRUAMzQV4OVdCnmY4=.b7d5a1a4-1e8f-4e2f-bccd-2d5e6c5a2b97@github.com>

On Mon, 14 Jul 2025 13:43:40 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> @prrace about tests. I can draw test image with font which is support tnum feature, and validate without it. Primitive one.
>> 
>> For example
>>  * at start - need load font, which supports this features. For example `Inter` (also need attach license of it inside repo?)
>>  * draw image `0123456789` with `pnum` 
>>  * <img width="200" height="50" alt="pnum" src="https://github.com/user-attachments/assets/2e80a463-a608-425f-a264-6097e415d397" />
>>  * draw image `0123456789` with `tnum`
>>  * <img width="200" height="50" alt="tnum" src="https://github.com/user-attachments/assets/62600f4e-1094-4fce-bd09-3876b4a8610e" />
>>  * if all bytes of images equals - it's means `tnum` not works. 
>> 
>> Also check default instance of `Font` without options
>> 
>> We can add this images inside repo, and validate image drawing (not sure)
>
> @VISTALL You can take a look at https://github.com/openjdk/jdk/blob/bcd86d575fe0682a234228c18b0c2e817d3816da/test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java - it has a good example of synthetic font generated specifically for the test and embedded into the test as base64. This avoids the hussle with licences and whatnot.
> I would also suggest to avoid golden-image tests, as those tend to be burdensome to maintain. But in your case you can probably inspect line metrics and compare the widths of a sample text.

> @YaaZ Thanks for example. About API. Will be good to make universal api - but I think it's too big task will be.
> 
> Maybe introduce api like nio2 - CopyOption* etc.
> 
> for example
> 
> ```java
> interface FontFeature<V> (FontExtension?) {
>    // some code
> }
> 
> // V is Integer? or delegate to impl
> class OpenTypeFontFeature implements FontFeature<Integer > {
>    OpenTypeFontFeature (String name) {
>    }
> }
> 
> public final class OpenTypeFontFeatures {
>     FontFeature<Integer> TABULAR_NUMBERS = new OpenTypeFontFeature<> ("tnum");
> } 
> ```
> 
> There few questions:
> 
> * conflicting features?
> * need method `Font#supportsFeature(FontFeature)` ?
> * need opentype class? or utilize to default font naming? (eg FontFeatureImpl)
> * need make public `OpenTypeFontFeature` class? (accesing from clients)
> * FontFeature will be extends TextAttribute?

I have previously prototyped APIs in this area. And they inter-operate with other ideas.
I'm working on other things right now so I can't switch gears to that but it probably does make sense to pause on this until I can think about whether this API on its own makes sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3156744114

From duke at openjdk.org  Wed Aug  6 00:08:46 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 6 Aug 2025 00:08:46 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v4]
In-Reply-To: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
Message-ID: <XUjL8nCcsALEY9D0UAjLhfJGRVp9IV0_miZdfGxkIZk=.a92c4523-29b8-46c0-b3c4-558066a3262e@github.com>

> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
> 
> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)

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

 - 8358813: use Set.of
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25688/files#r2255241147
 - Merge branch 'master' into JDK-8358813
 - 8358813: add trailing comma
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25688/files#r2246362320
 - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
   
   Co-authored-by: DamonGuy <damon.nguyen at oracle.com>
 - 8358813: putting the actions in a TreeSet
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
 - 8358813: make input map types a static constant
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
 - Merge branch 'master' into JDK-8358813
 - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - 8358813: remove more bindings for JPasswordFields in Aqua

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25688/files
  - new: https://git.openjdk.org/jdk/pull/25688/files/486f575e..58f01781

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

  Stats: 44415 lines in 1152 files changed: 26462 ins; 13261 del; 4692 mod
  Patch: https://git.openjdk.org/jdk/pull/25688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25688/head:pull/25688

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

From duke at openjdk.org  Wed Aug  6 00:08:46 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 6 Aug 2025 00:08:46 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <aY8u24zTZce7irSte1vD-gOeUIm0XhAg6CBnMps7JNo=.2c3354b0-9c74-4954-b453-50429d3ea92a@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>
 <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>
 <zwGT_i2rpa21cpEO3VpWMMwW2NwyQ2LUlAqo2BYsX6A=.9986e23d-71b3-450f-abce-0d45ccfdef77@github.com>
 <aY8u24zTZce7irSte1vD-gOeUIm0XhAg6CBnMps7JNo=.2c3354b0-9c74-4954-b453-50429d3ea92a@github.com>
Message-ID: <U0sN6kP-gbZgBq261ptbhvj9m1gjJrxR8FpwncGYnkw=.fd118b0e-0c90-4a76-9a7b-bd46d9dc970e@github.com>

On Tue, 5 Aug 2025 20:21:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @DamonGuy I can reproduce the problem with the test, `PasswordSelectionWordTest.java`, attached to [JDK-8358813](https://bugs.openjdk.org/browse/JDK-8358813).
>
>> Also, I guess you can end in a trailing comma to match the previous format if you want. Either is OK.
> 
> This is a nice suggestion.

OK, I added a trailing comma

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2255567085

From duke at openjdk.org  Wed Aug  6 00:08:46 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 6 Aug 2025 00:08:46 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v3]
In-Reply-To: <CC11nZNpuiaSUjTfgYkuCvUoxGvH5hlBx2O2XG6EDzA=.426c4273-5163-43ed-8e67-b996e5ac3bee@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <pRA0pQIz4irlOxCx7T4Tu6OLRrPDfuEAoYeaZg_Fl1s=.23da5d33-8993-45fa-b9db-9102c7f9717e@github.com>
 <CC11nZNpuiaSUjTfgYkuCvUoxGvH5hlBx2O2XG6EDzA=.426c4273-5163-43ed-8e67-b996e5ac3bee@github.com>
Message-ID: <oMSxtFjD4QCI7ya410prm9ypFFK59nOVcHW5uniugRA=.f60d0c9d-cad8-4877-aa3f-e6bab058bf39@github.com>

On Tue, 5 Aug 2025 20:11:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>>   
>>   Co-authored-by: DamonGuy <damon.nguyen at oracle.com>
>
> test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 81:
> 
>> 79:      * These are all the actions with "word" in their field name.
>> 80:      */
>> 81:     static Collection<String> wordActions = new TreeSet<>(Arrays.asList(
> 
> Would `Set.of` do the job?
> 
> Perhaps, `List.of` would be as good.

OK, this is updated to Set.of

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2255568216

From psadhukhan at openjdk.org  Wed Aug  6 02:58:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 02:58:01 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v26]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <hjI1ozzITjVZWLTEL5wFvEROkJivgnqyjgrRCB3H1F0=.908100fc-9f8a-4c62-9898-749406314d4e@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/c6be2a91..5b388869

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=24-25

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

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

From psadhukhan at openjdk.org  Wed Aug  6 02:58:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 02:58:04 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
Message-ID: <WrL2ErpBw0Jhh8w_fckyiiL80AMQMXpX_lBjietkxKY=.703260fc-91c7-466f-b721-33d7c6a40a7e@github.com>

On Sun, 3 Aug 2025 06:18:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class javadoc modification

Test updated

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3157234491

From mickleness at gmail.com  Wed Aug  6 04:56:43 2025
From: mickleness at gmail.com (Jeremy Wood)
Date: Wed, 06 Aug 2025 04:56:43 +0000
Subject: Flagging JDK-4851378 as duplicate of JDK-8176501
Message-ID: <em8bff8d3c-697f-4e08-888e-cec06221669d@3043ce10.com>

What is the protocol to flag one JDK ticket as a duplicate of another?

This ticket <https://bugs.openjdk.org/browse/JDK-4851378> appears to be 
a duplicate of the ticket addressed in this PR 
<https://github.com/openjdk/jdk/pull/6227> a few years ago.

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

From psadhukhan at openjdk.org  Wed Aug  6 05:47:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 05:47:03 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v2]
In-Reply-To: <5ukKwWzpYzEiAaeJ6YCIRmkg90Z4_UEgdxF7iKaGNn0=.c84a5018-c04d-4b18-a1a8-df4af8e8d16c@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <5ukKwWzpYzEiAaeJ6YCIRmkg90Z4_UEgdxF7iKaGNn0=.c84a5018-c04d-4b18-a1a8-df4af8e8d16c@github.com>
Message-ID: <AuAy50Hpki9QeaSGbYShh5VtXyzVWA8mDqHgdtjir-Y=.8c461e27-0538-42bf-826a-3e1fe156ea81@github.com>

On Mon, 4 Aug 2025 21:11:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> Convert StringContent's Position usage tracking to use a WeakReference
>> 
>> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364230

test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 33:

> 31:  */
> 32: 
> 33: public class StringContentPositionTest {

I believe @bug is not added because this is not strictly a regression test for this issue as I see it does not fail even without the fix?
Since `System.gc` is used, can we try restricting the heap size in commandline to see if it will fail without the fix and pass with it?

test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 54:

> 52:         for (int i = 0; i < SIZE; i++) {
> 53:             SC.insertString(0, TEXT);
> 54:             positions[i] = SC.createPosition(5);

should it be LEN instead of 5?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2255919971
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2255917014

From psadhukhan at openjdk.org  Wed Aug  6 05:51:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 05:51:06 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0
In-Reply-To: <lwS2mLWmtuzPlLiME9GR_LoUWdObqOUYmndwhpcieU4=.97c8c891-1098-4967-9ed9-3d7b103a91e1@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <wcy_5XD5X9WvDbtk2oFBdchqkdRY3f8ua1L89Yz-enw=.0de33457-0343-4942-a273-350effa88bd2@github.com>
 <lwS2mLWmtuzPlLiME9GR_LoUWdObqOUYmndwhpcieU4=.97c8c891-1098-4967-9ed9-3d7b103a91e1@github.com>
Message-ID: <ydZnFFfD94K28nNBleMkYzO1OTaIrdhEExTIRUKFbX4=.c6e88a4f-8385-4e3b-b665-21700ed18a1c@github.com>

On Fri, 1 Aug 2025 07:14:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JList.java line 2512:
>> 
>>> 2510:      * @return the "unit" increment for scrolling in the specified direction;
>>> 2511:      *         which is usually positive. But it can return 0
>>> 2512:      *         if {@code visibleRect} points to that row
>> 
>> should it be `the` or `that` ?
>> Suggestion:
>> 
>>      *         if {@code visibleRect} points to the row
>> 
>> 
>> Requires a CSR too ?
>
> it is "that" row being pointed to by visibleRect
> and yes CSR is needed but I want to finalise the wordings first.

@prrace Can we just say "it will return >=0" or "it will return a non-negative number" instead of explaining when, as it might be delving into implementation details?

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

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

From abhiscxk at openjdk.org  Wed Aug  6 06:28:15 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Aug 2025 06:28:15 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v8]
In-Reply-To: <nP0pBki2BE9FsuPR8u4ESpVwFWEKLIB1boPAFblhzJo=.3f293496-bed8-4985-b06b-289811ada287@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <nP0pBki2BE9FsuPR8u4ESpVwFWEKLIB1boPAFblhzJo=.3f293496-bed8-4985-b06b-289811ada287@github.com>
Message-ID: <qUCPeQL00A5LHGC_L7uu8WfoIZQkIbesXUxM3nNzhKo=.dee3d4d6-2866-45a5-9650-18af897b72f4@github.com>

On Tue, 5 Aug 2025 11:01:24 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: Summary updated

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 28:

> 26:  * @key headful
> 27:  * @bug 6315717
> 28:  * @summary Verifies that mouse drag events received for every button if the property is set to true

Suggestion:

 * @summary Verifies that the mouse drag events received for every button if the property is set to true

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 53:

> 51:     private static volatile Point centerFrame;
> 52:     private static volatile Point outboundsFrame;
> 53:     static String osName = System.getProperty("os.name");

Can be declared as `final` variable as it's value is not going to be changed
Suggestion:

    private static final String OS_NAME = System.getProperty("os.name");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2255984137
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2255973828

From psadhukhan at openjdk.org  Wed Aug  6 07:16:07 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 07:16:07 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
 <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
 <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
Message-ID: <pqDRhNoCmC9CO2u75fvkVJD1BdvMpKzojfHlJHhmzS4=.a3650b28-c08c-4b38-b9b6-e4394531a616@github.com>

On Fri, 18 Jul 2025 04:00:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
>> 
>> I have tested with undecorated frames, but the test continues to fail. The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
>> 
>> I will set the frames (The background undecorated frame, and the heavyweight component frames) on center as you have suggested.
>
>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
> 
> WHich test in particular? or is it all tests have this behavior?
> 
>> The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
> 
> I tried JMenuBarOverlapping.java but I dont see any click on title bar..The cursor in on top-left of "Test Menu" menu..
> If clicking on the title bar is needed to make it gain focus, probably you can try with calling `frame.requestFocus` and use `CountDownLatch `with timeout to wait till FOCUS_GAINED event is received and release the latch in `focusGained()` and then start the test

> @prsadhuk after applying your suggested change, I can see that it has fixed the issue for most of the tests but still the following tests didn't pass on Windows compared with the original fix of changing frame width :
> 
> java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java
> 
> I will check why these tests had failed.

I see this tests are also deproblemlisted despite mentioning they fail, so my idea of CountDownLatch for focus gain event solved these too?

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3157656682

From psadhukhan at openjdk.org  Wed Aug  6 07:16:09 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 07:16:09 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v14]
In-Reply-To: <sBgBAvbmRlp-klRdCRHzYS-MZkMZMB8QXRtALs-WYv0=.3603af56-6c47-48ec-9c16-75604280d5c4@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <sBgBAvbmRlp-klRdCRHzYS-MZkMZMB8QXRtALs-WYv0=.3603af56-6c47-48ec-9c16-75604280d5c4@github.com>
Message-ID: <jXQlBuiWGb-J2k5DhEkEXHgG8H_kdl1mD0wbbA_H83M=.52bec05d-faa7-4480-9fe8-1ec23c920585@github.com>

On Mon, 4 Aug 2025 09:48:36 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes wildcard imports

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 138:

> 136:                                     FocusManager.getCurrentManager()
> 137:                                             .getFocusOwner();
> 138:                             if (focusOwner == f) {

Guess you should be checking these before calling `requestFocusInWindow` as there's no point in calling `requestFocusInWindow` if current focusOwner is f?

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 154:

> 152:             lLoc.translate(1, testedComponent.getPreferredSize().height + 1);
> 153:             try {
> 154:                 boolean await = latch.await(50, TimeUnit.MILLISECONDS);

50 ms is enough? guess you can go upto 1sec!!
will it make the other failed tests pass if we increase this timeout?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2256096136
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2256099509

From abhiscxk at openjdk.org  Wed Aug  6 07:18:04 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Aug 2025 07:18:04 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
 <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>
Message-ID: <yMTjTdTv-P0wqrGx0Rj6YMbRESQxCSXbJFPNDVKrrk8=.e940b92a-2622-4587-bd15-946be04aa0bf@github.com>

On Wed, 23 Jul 2025 19:44:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> At the same time, I agree that all implementations of AccessibleText need updating to be consistent.

I checked with the implementation of `getAtIndex, getBeforeIndex and getAfterIndex` APIs and these UI components (JSpinner, JPasswordField, JTextComponent, JLabel, AbstractButton, ProgressMonitor classes) implement them. JSpinner, JPasswordField internally depends on the JTextComponent for the actual implementation as the Accessible Text object is an instance of Accessible JTextComponent. Similarly, ProgressMonitor depends on the JLabel class implementation.

JLabel and AbstractButton support these methods only if the  text is html and not plain text. 

I tried with html based JLabel and analyze the result returned by the getAtIndex API.
If a JLabel has the html text `<html>This is <b>Bold</b> text</html>`, then the result shown by getAtIndex for CHARACTER is:

      Index 0 : 

      Index 1 : T
      Index 2 : h
      Index 3 : i
      Index 4 : s
      Index 5 :  
      Index 6 : i
      Index 7 : s
      Index 8 :  
      Index 9 : B
      Index 10 : o
      Index 11 : l
      Index 12 : d
      Index 13 :  
      Index 14 : t
      Index 15 : e
      Index 16 : x
      Index 17 : t

This seems wrong to me, I expect the character at index **0** should be **T**. 

The array layout from the AbstractDocument class after html tags removal shows
<img width="1333" height="809" alt="image" src="https://github.com/user-attachments/assets/8dfeeec0-da78-4b9b-8b64-19f78ee90724" />


I don't understand **why there is a newline character at the start of the JLabel's text** after removing the html tags.

`getCharCount` method return the number of characters (valid indices) as 18, this includes the newline character at index 0 and trims the last newline character.

I think the new line character shouldn't be considered, otherwise, the results returned from get*Index APIs looks incorrect.

@aivanov-jdk As per my opinion, updating Accessible Text implementation for JLabel and AbstractButton can be taken up as a separate issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3157688225

From psadhukhan at openjdk.org  Wed Aug  6 07:22:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 07:22:06 GMT
Subject: RFR: 8364506: javax/swing/Popup/TaskbarPositionTest.java can fail
 subsequent tests on MacOS
In-Reply-To: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
References: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
Message-ID: <IWV_ZQGklpwJWhYLlroRf1RqmYMHSJRfW3NuacYYon0=.47bcbf7f-7400-45f3-9c66-c472132e1972@github.com>

On Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to show all windows related to the focused one.
> 
> Fix:
> Change the 'Cntrl' key to 'Shift'
> 
> Testing:
> Tested in all supported platforms using mach5 and got all PASS.

test/jdk/javax/swing/Popup/TaskbarPositionTest.java line 104:

> 102: 
> 103:     public TaskbarPositionTest() {
> 104:         frame = new JFrame("Use SHIFT-down to show a JPopupMenu");

guess for these kind of jtreg headful tests it is suggested "Go into System Settings, locate the Keyboard Panel, and from there select the Shortcuts tab. Disable ALL shortcuts. "
which is already mentioned in the summary above "The test uses Ctrl+Down Arrow which is a system shortcut on macOS,
* disable it in system settings, otherwise the test will fail"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26623#discussion_r2256115338

From psadhukhan at openjdk.org  Wed Aug  6 07:44:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 07:44:54 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v2]
In-Reply-To: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
Message-ID: <nN4-pd_rBeaj6UO8BO9C4WXuDrknYlTTCPGoChAXPD0=.d7d2a0b0-4078-469b-9dfd-d80e38d6d3bb@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 update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26500/files
  - new: https://git.openjdk.org/jdk/pull/26500/files/0ba55ae8..7309f6b8

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

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

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

From psadhukhan at openjdk.org  Wed Aug  6 07:51:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Aug 2025 07:51:00 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v3]
In-Reply-To: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
Message-ID: <0MDTPquVuMulH9tEnu_VEaKM7e6SPCpHh_19RhGWXMw=.56db997b-8a7e-48ea-bd07-e9721c5eea28@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 update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26500/files
  - new: https://git.openjdk.org/jdk/pull/26500/files/7309f6b8..b4d22ac9

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

  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 aturbanov at openjdk.org  Wed Aug  6 08:16:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 6 Aug 2025 08:16:17 GMT
Subject: RFR: 8364808: Make BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT
 static
Message-ID: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>

Looks like no reasons for it to be instance field

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

Commit messages:
 - [PATCH] Make BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static

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

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

From tr at openjdk.org  Wed Aug  6 08:16:18 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 6 Aug 2025 08:16:18 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
Message-ID: <mbcENwUu4XS9cYOPX30VjAbE0RXlVPcemOK7GAqALsE=.daf0e5d4-230d-4ca2-ade1-b348b5f8d4ce@github.com>

On Thu, 19 Jun 2025 08:25:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Looks like no reasons for it to be instance field

LGTM

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25893#pullrequestreview-3078518142

From serb at openjdk.org  Wed Aug  6 08:16:18 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 6 Aug 2025 08:16:18 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
Message-ID: <dDLnOYozgNvUMhstoiPZ_YFCXGuI5d1JOuGica6LHqc=.bab11273-cd4d-4b85-b167-748126aeb8e7@github.com>

On Thu, 19 Jun 2025 08:25:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Looks like no reasons for it to be instance field

I think we can unify the common patterns used by all these "Actions extends UIAction" classes to
"private final static XXX", but it will be good to check how the finals for String constants will affect the size of the classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25893#issuecomment-3081673366

From duke at openjdk.org  Wed Aug  6 08:35:07 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 08:35:07 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <pqDRhNoCmC9CO2u75fvkVJD1BdvMpKzojfHlJHhmzS4=.a3650b28-c08c-4b38-b9b6-e4394531a616@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
 <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
 <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
 <pqDRhNoCmC9CO2u75fvkVJD1BdvMpKzojfHlJHhmzS4=.a3650b28-c08c-4b38-b9b6-e4394531a616@github.com>
Message-ID: <cdoUdwbddKoeK-7MTWePobhsATAze-gf-nbdiYi94t8=.11b7b71b-eaf7-41a8-96a8-79d24a7a46de@github.com>

On Wed, 6 Aug 2025 07:04:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
>> 
>> WHich test in particular? or is it all tests have this behavior?
>> 
>>> The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
>> 
>> I tried JMenuBarOverlapping.java but I dont see any click on title bar..The cursor in on top-left of "Test Menu" menu..
>> If clicking on the title bar is needed to make it gain focus, probably you can try with calling `frame.requestFocus` and use `CountDownLatch `with timeout to wait till FOCUS_GAINED event is received and release the latch in `focusGained()` and then start the test
>
>> @prsadhuk after applying your suggested change, I can see that it has fixed the issue for most of the tests but still the following tests didn't pass on Windows compared with the original fix of changing frame width :
>> 
>> java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java
>> 
>> I will check why these tests had failed.
> 
> I see this tests are also deproblemlisted despite mentioning they fail, so my idea of CountDownLatch for focus gain event solved these too?

@prsadhuk The solution you suggested using CountDownLatch and request focus fixed all the test that are deproblemlisted in this PR. 
All tests deproblemlisted were tested on macosx-x64, windows-x64 and linux-x64.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3158222665

From duke at openjdk.org  Wed Aug  6 09:12:53 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 09:12:53 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v14]
In-Reply-To: <jXQlBuiWGb-J2k5DhEkEXHgG8H_kdl1mD0wbbA_H83M=.52bec05d-faa7-4480-9fe8-1ec23c920585@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <sBgBAvbmRlp-klRdCRHzYS-MZkMZMB8QXRtALs-WYv0=.3603af56-6c47-48ec-9c16-75604280d5c4@github.com>
 <jXQlBuiWGb-J2k5DhEkEXHgG8H_kdl1mD0wbbA_H83M=.52bec05d-faa7-4480-9fe8-1ec23c920585@github.com>
Message-ID: <5M_6sAovVCNL1EuflNaBQOGsLKBZlajh3gH0o4tUVWg=.30befa49-82c4-4141-88d5-3b159b915054@github.com>

On Wed, 6 Aug 2025 07:12:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes wildcard imports
>
> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 138:
> 
>> 136:                                     FocusManager.getCurrentManager()
>> 137:                                             .getFocusOwner();
>> 138:                             if (focusOwner == f) {
> 
> Guess you should be checking these before calling `requestFocusInWindow` as there's no point in calling `requestFocusInWindow` if current focusOwner is f?

Thanks for pointing this to me. I have changed the code accordingly and running all tests to make sure my change does not break anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2256493649

From duke at openjdk.org  Wed Aug  6 09:12:53 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 09:12:53 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v15]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <q3aCIrWKQIXQmSV-i08UD1lRmk-15HysmAjIho-hvP8=.93ba5f53-57c0-40ad-a02a-7988db52e914@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Checks if component had focus first.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/d986747c..890430eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=13-14

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

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

From duke at openjdk.org  Wed Aug  6 09:23:46 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 09:23:46 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v16]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <fGjE7vVfMkHQyGelXbb-ZUCVMYrrNT0EU9FVWzhwPmM=.eedb7c03-e339-41b9-b7d1-75d2c9c36946@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Merge branch 'openjdk:master' into jdk-8158801
 - Checks if component had focus first.
 - Removes wildcard imports
 - Merge branch 'openjdk:master' into jdk-8158801
 - Removes not needed component frace ancestor.
 - Problem unlists passed tests
 - Uses frame requestFocus instead of robot clicks for focus
 - Removes extra Robot waitForIdle
 - Merge branch 'openjdk:master' into jdk-8158801
 - Restores copyright year for tests not updated
 - ... and 15 more: https://git.openjdk.org/jdk/compare/d4a6f6c4...ce91a9d7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/890430eb..ce91a9d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=14-15

  Stats: 4268 lines in 120 files changed: 2055 ins; 1902 del; 311 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From rgupta at openjdk.org  Wed Aug  6 09:43:48 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Wed, 6 Aug 2025 09:43:48 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v9]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

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

  8361067: Added review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/fd70f19f..83a8bc7e

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

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

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

From duke at openjdk.org  Wed Aug  6 10:18:22 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 10:18:22 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v17]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <OkjI6oMPDnVw3iKG-TEbiBdH9hGDaEYRSlw3x4rja6g=.d422290d-734f-44b7-813d-4e2455da21bb@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Requests focus, if component does not have it already.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/ce91a9d7..fcde066a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=15-16

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

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

From duke at openjdk.org  Wed Aug  6 10:27:06 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 10:27:06 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v18]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <DYMGVqk6tz_-rtvl8oEzXzt2MXwWxYH1AExCYZDQIv4=.4c231fd8-08c8-4a63-80e3-f51fd64c7b82@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Updates CountDownLatch waiting time to one second

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/fcde066a..abc0797c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=16-17

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

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

From duke at openjdk.org  Wed Aug  6 10:27:08 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 10:27:08 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v14]
In-Reply-To: <jXQlBuiWGb-J2k5DhEkEXHgG8H_kdl1mD0wbbA_H83M=.52bec05d-faa7-4480-9fe8-1ec23c920585@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <sBgBAvbmRlp-klRdCRHzYS-MZkMZMB8QXRtALs-WYv0=.3603af56-6c47-48ec-9c16-75604280d5c4@github.com>
 <jXQlBuiWGb-J2k5DhEkEXHgG8H_kdl1mD0wbbA_H83M=.52bec05d-faa7-4480-9fe8-1ec23c920585@github.com>
Message-ID: <PZWowrvmxhZC9wmpe71GXgjutySE9FtHYC6yOCGTwZc=.2209bfc2-39b6-439a-b512-223e90834670@github.com>

On Wed, 6 Aug 2025 07:13:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes wildcard imports
>
> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 154:
> 
>> 152:             lLoc.translate(1, testedComponent.getPreferredSize().height + 1);
>> 153:             try {
>> 154:                 boolean await = latch.await(50, TimeUnit.MILLISECONDS);
> 
> 50 ms is enough? guess you can go upto 1sec!!
> will it make the other failed tests pass if we increase this timeout?

I have increased awaiting time to 1 seconds for both tests java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java and java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java, I will test and confirm if this is working.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2256707309

From aivanov at openjdk.org  Wed Aug  6 12:44:08 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 12:44:08 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v3]
In-Reply-To: <oMSxtFjD4QCI7ya410prm9ypFFK59nOVcHW5uniugRA=.f60d0c9d-cad8-4877-aa3f-e6bab058bf39@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <pRA0pQIz4irlOxCx7T4Tu6OLRrPDfuEAoYeaZg_Fl1s=.23da5d33-8993-45fa-b9db-9102c7f9717e@github.com>
 <CC11nZNpuiaSUjTfgYkuCvUoxGvH5hlBx2O2XG6EDzA=.426c4273-5163-43ed-8e67-b996e5ac3bee@github.com>
 <oMSxtFjD4QCI7ya410prm9ypFFK59nOVcHW5uniugRA=.f60d0c9d-cad8-4877-aa3f-e6bab058bf39@github.com>
Message-ID: <2elvFDL1L0YJ0PUraR-5jZnxpOctsLI4SFJ9AqnHZ0E=.c5f0a915-1756-4014-8251-aa3c0118d6db@github.com>

On Wed, 6 Aug 2025 00:05:15 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 81:
>> 
>>> 79:      * These are all the actions with "word" in their field name.
>>> 80:      */
>>> 81:     static Collection<String> wordActions = new TreeSet<>(Arrays.asList(
>> 
>> Would `Set.of` do the job?
>> 
>> Perhaps, `List.of` would be as good.
>
> OK, this is updated to Set.of

Thanks! Using `Set` ensures there are no duplicates in the list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2257026346

From azvegint at openjdk.org  Wed Aug  6 12:49:04 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 6 Aug 2025 12:49:04 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
Message-ID: <5iZukFjzLJR-FOVx4fRVFgpf0Bdywj6bUfwfxCt_qTk=.f4cdf403-6168-4192-acea-aca73e1ec515@github.com>

On Thu, 19 Jun 2025 08:25:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Looks like no reasons for it to be instance field

Marked as reviewed by azvegint (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java line 377:

> 375:         private static String NAVIGATE_NEXT = "navigateNext";
> 376:         private static String NAVIGATE_PREVIOUS = "navigatePrevious";
> 377:         private static final int MOVE_RESIZE_INCREMENT = 10;

It appears that all of the above strings in `Actions` class can be final.

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

PR Review: https://git.openjdk.org/jdk/pull/25893#pullrequestreview-3092374474
PR Review Comment: https://git.openjdk.org/jdk/pull/25893#discussion_r2257034353

From duke at openjdk.org  Wed Aug  6 13:07:05 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 6 Aug 2025 13:07:05 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <pqDRhNoCmC9CO2u75fvkVJD1BdvMpKzojfHlJHhmzS4=.a3650b28-c08c-4b38-b9b6-e4394531a616@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
 <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
 <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
 <pqDRhNoCmC9CO2u75fvkVJD1BdvMpKzojfHlJHhmzS4=.a3650b28-c08c-4b38-b9b6-e4394531a616@github.com>
Message-ID: <dhJG4yWkwyt34lNXk1s-CvJwKjoVfldEAHYQJG1Ynn4=.d1f1d9ac-9698-424c-9697-bdab83d9645e@github.com>

On Wed, 6 Aug 2025 07:04:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
>> 
>> WHich test in particular? or is it all tests have this behavior?
>> 
>>> The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
>> 
>> I tried JMenuBarOverlapping.java but I dont see any click on title bar..The cursor in on top-left of "Test Menu" menu..
>> If clicking on the title bar is needed to make it gain focus, probably you can try with calling `frame.requestFocus` and use `CountDownLatch `with timeout to wait till FOCUS_GAINED event is received and release the latch in `focusGained()` and then start the test
>
>> @prsadhuk after applying your suggested change, I can see that it has fixed the issue for most of the tests but still the following tests didn't pass on Windows compared with the original fix of changing frame width :
>> 
>> java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java
>> 
>> I will check why these tests had failed.
> 
> I see this tests are also deproblemlisted despite mentioning they fail, so my idea of CountDownLatch for focus gain event solved these too?

@prsadhuk All tests passed after the applying both changes: Awaiting time set to one second and checking if component has focus first before requesting focus.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3160091352

From aivanov at openjdk.org  Wed Aug  6 13:37:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 13:37:07 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v4]
In-Reply-To: <XUjL8nCcsALEY9D0UAjLhfJGRVp9IV0_miZdfGxkIZk=.a92c4523-29b8-46c0-b3c4-558066a3262e@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <XUjL8nCcsALEY9D0UAjLhfJGRVp9IV0_miZdfGxkIZk=.a92c4523-29b8-46c0-b3c4-558066a3262e@github.com>
Message-ID: <ebYL3mtEQnZc54JSFC1W1tgGK2uDXJgJrqETSI7MqLk=.29e4c589-8f13-4887-bcee-3be510f1dd24@github.com>

On Wed, 6 Aug 2025 00:08:46 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - 8358813: use Set.of
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688/files#r2255241147
>  - Merge branch 'master' into JDK-8358813
>  - 8358813: add trailing comma
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688/files#r2246362320
>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>    
>    Co-authored-by: DamonGuy <damon.nguyen at oracle.com>
>  - 8358813: putting the actions in a TreeSet
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
>  - 8358813: make input map types a static constant
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
>  - Merge branch 'master' into JDK-8358813
>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - 8358813: remove more bindings for JPasswordFields in Aqua

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25688#pullrequestreview-3092593453

From aivanov at openjdk.org  Wed Aug  6 13:56:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 13:56:19 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v4]
In-Reply-To: <XUjL8nCcsALEY9D0UAjLhfJGRVp9IV0_miZdfGxkIZk=.a92c4523-29b8-46c0-b3c4-558066a3262e@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <XUjL8nCcsALEY9D0UAjLhfJGRVp9IV0_miZdfGxkIZk=.a92c4523-29b8-46c0-b3c4-558066a3262e@github.com>
Message-ID: <60cAUIO7ZEsShZaQDdMH8qvtfkh01lVw_SpYPc2YKHA=.cddf6b29-587a-4deb-8014-91b2c1151194@github.com>

On Wed, 6 Aug 2025 00:08:46 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - 8358813: use Set.of
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688/files#r2255241147
>  - Merge branch 'master' into JDK-8358813
>  - 8358813: add trailing comma
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688/files#r2246362320
>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>    
>    Co-authored-by: DamonGuy <damon.nguyen at oracle.com>
>  - 8358813: putting the actions in a TreeSet
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
>  - 8358813: make input map types a static constant
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
>  - Merge branch 'master' into JDK-8358813
>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - 8358813: remove more bindings for JPasswordFields in Aqua

test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 24:

> 22:  */
> 23: 
> 24: /**

Suggestion:

/*

Please do not use javadoc comment for jtreg tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2257249271

From aivanov at openjdk.org  Wed Aug  6 14:15:06 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 14:15:06 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <yMTjTdTv-P0wqrGx0Rj6YMbRESQxCSXbJFPNDVKrrk8=.e940b92a-2622-4587-bd15-946be04aa0bf@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
 <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>
 <yMTjTdTv-P0wqrGx0Rj6YMbRESQxCSXbJFPNDVKrrk8=.e940b92a-2622-4587-bd15-946be04aa0bf@github.com>
Message-ID: <2XHehgSV0fo5R5dXdy_rQ2TuEwu45EnHAnjgRRSoWUk=.d1caa66b-5ea1-4f98-bfad-6b4fc4a72aad@github.com>

On Wed, 6 Aug 2025 07:14:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> I think the new line character shouldn't be considered from accessibility POV, otherwise, the results returned from get*Index APIs looks incorrect to me.
> 
> @azuev-java What are your thoughts on it ?
> 
> @aivanov-jdk As per my opinion, updating Accessible Text implementation for JLabel and AbstractButton can be taken up as a separate issue.

I agree this seems weird to me. I have no objections from taking this newly found bug under a new bug id.

The newline character at the start of the message could be required for modelling of HTML in the `Document`, however, off the top of my head, I can't think of any reason why this would be required.

What I also find weird is that all these component implement `AccessibleText` from scratch rather than using an implementation that exists in for a text component. Yes, I understand that it's a nested class and therefore it can't be easily extended, yet there could be an internal class which stores the reference for a text component and or text model and implements the methods on top of that. The implementations for other components could use composition in delegate its implementation of `AccessibleText` to one instance. This would avoid code duplication, and resolving a bug, such as this one, would automatically propagate into other components.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3160352519

From aivanov at openjdk.org  Wed Aug  6 14:32:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 14:32:03 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
 <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>
Message-ID: <HI7SXp1kune-8vsBU_SHvbyYf8Gl29a6tpwKftjbKpA=.79d999fa-4e52-4b84-859b-d8887946c22b@github.com>

On Wed, 23 Jul 2025 19:44:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Ok, let's step away from the documentation and try to focus on the use case of this method. Method is supposed to expose navigation within the text component to the assistive technology devices and programs.

I agree with @azuev-java here, we should focus on the purpose of the API and how this API is supposed to be used.

I think it is reasonable to expect that `Document.getLength()` is a valid index for text APIs, and `getBeforeIndex` should return the last character of the text in this case.

I said it a few times now, _?an index within the text?_ is a vague condition, we should update the specification so that it is clear which indexes are valid.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3160424445

From duke at openjdk.org  Wed Aug  6 14:47:16 2025
From: duke at openjdk.org (Christian Heilmann)
Date: Wed, 6 Aug 2025 14:47:16 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
Message-ID: <lkCjm0aOhdTsHXfo6dDVrTnOtws8o_B_vvnY9CsqfnQ=.71a7fdb4-1e4f-494c-bc5b-78b1aa9914ee@github.com>

On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann <duke at openjdk.org> wrote:

>> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
>> 
>> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.
>
> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
>  - Merge branch 'master' into pr/11266
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS

Were you able to follow my explanations? Is there anything else I can do, to get the pull request through the review?

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

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3160476557

From aivanov at openjdk.org  Wed Aug  6 15:04:17 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 15:04:17 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v26]
In-Reply-To: <hjI1ozzITjVZWLTEL5wFvEROkJivgnqyjgrRCB3H1F0=.908100fc-9f8a-4c62-9898-749406314d4e@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <hjI1ozzITjVZWLTEL5wFvEROkJivgnqyjgrRCB3H1F0=.908100fc-9f8a-4c62-9898-749406314d4e@github.com>
Message-ID: <EBjMR1jA_dHho5OCYMVQmG8hO-Rfraq2Jd-a1WsJYAk=.3a38a701-a1f8-46f5-b822-9a22a607d6ed@github.com>

On Wed, 6 Aug 2025 02:58:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Looks good? except for lots of unexpected blank lines in the test code.

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 73:

> 71:                            break;
> 72: 
> 73:                        case URL :

Was adding so many blank lines intentional?

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-3093086116
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2257484753

From prr at openjdk.org  Wed Aug  6 15:52:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 15:52:03 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0
In-Reply-To: <2hCwbX522BypcHQMhMrOL6gx0gVPqSVT5C0wOzvQx-U=.17ac8712-fd4a-4865-a6aa-4e21a3b6220f@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <LR56gUD-lr5heXd4rz9iVC4SvDlCMUJkVXO7_plBuLE=.145eb7ea-f327-4c25-b5e6-5697857f4caf@github.com>
 <2hCwbX522BypcHQMhMrOL6gx0gVPqSVT5C0wOzvQx-U=.17ac8712-fd4a-4865-a6aa-4e21a3b6220f@github.com>
Message-ID: <TcQtEtcFgYh1LU2AlT4TFqbDknMXr7yiRuFqwIO-uuQ=.ecffebff-fadb-4fd7-bcc4-1450893608d4@github.com>

On Sun, 3 Aug 2025 06:23:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Isn't this just a bug ? I get zero from the test whenever "-1" is the direction - meaning scroll up - even if I use something like
> > https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/JList.html#getScrollableUnitIncrement(java.awt.Rectangle,int,int)
> 
> If the `visibleRect` Rectangle points to the 1st row or row 0 and we are scrolling up i.e -1 direction there is no more space to scroll up so `getScrollableUnitIncrement` returns 0. If we modify the testcase to have `Rectangle cell = list.getCellBounds(data.length-1, data.length-1);` instead of `list.getCellBounds(0, 0);` to point to last cell, it returns positive number for -1 direction too

As I wrote it returns zero for me no matter what. Eg if I use
 Rectangle cell = list.getCellBounds(1, 2);

so why is that ?

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

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

From duke at openjdk.org  Wed Aug  6 16:19:56 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 6 Aug 2025 16:19:56 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v5]
In-Reply-To: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
Message-ID: <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>

> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
> 
> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)

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

  Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25688/files
  - new: https://git.openjdk.org/jdk/pull/25688/files/58f01781..e618df35

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

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

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

From dnguyen at openjdk.org  Wed Aug  6 16:44:04 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 6 Aug 2025 16:44:04 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v5]
In-Reply-To: <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
Message-ID: <P3SdPYDPC7FrGVWV9pAxKp5MqKy0RDMuKGJiwN7tZB8=.b0ec783e-322b-4aec-9ca3-476b990e8d38@github.com>

On Wed, 6 Aug 2025 16:19:56 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25688#pullrequestreview-3093448804

From dnguyen at openjdk.org  Wed Aug  6 16:44:05 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 6 Aug 2025 16:44:05 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <U0sN6kP-gbZgBq261ptbhvj9m1gjJrxR8FpwncGYnkw=.fd118b0e-0c90-4a76-9a7b-bd46d9dc970e@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>
 <PTf7q0b9bvfvSZ3x18KxD7rWFUx8RaLScOleRerY1wo=.5ed2b676-88eb-4c1a-ae59-af27f1bd2f39@github.com>
 <zwGT_i2rpa21cpEO3VpWMMwW2NwyQ2LUlAqo2BYsX6A=.9986e23d-71b3-450f-abce-0d45ccfdef77@github.com>
 <aY8u24zTZce7irSte1vD-gOeUIm0XhAg6CBnMps7JNo=.2c3354b0-9c74-4954-b453-50429d3ea92a@github.com>
 <U0sN6kP-gbZgBq261ptbhvj9m1gjJrxR8FpwncGYnkw=.fd118b0e-0c90-4a76-9a7b-bd46d9dc970e@github.com>
Message-ID: <xI2AW1199h6XgUI5ae0GBypPsO7Cs_XsDuGvRkQ38U4=.b061df29-0854-4223-bd1c-54a097f76771@github.com>

On Wed, 6 Aug 2025 00:03:47 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>>> Also, I guess you can end in a trailing comma to match the previous format if you want. Either is OK.
>> 
>> This is a nice suggestion.
>
> OK, I added a trailing comma

Thanks for the video showcase. I was catching up yesterday after being out and I can now see the issue. I can match what is shown now as well. I might have built the image with incomplete changes the first go around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2257737302

From aivanov at openjdk.org  Wed Aug  6 18:16:25 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 18:16:25 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v5]
In-Reply-To: <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
Message-ID: <OleiJF6iQBb8MVxuViBrcJTwmpsslaqyUDniRTt3r3k=.36af4755-0b03-4c26-b3b9-5f136a5efa57@github.com>

On Wed, 6 Aug 2025 16:19:56 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25688#pullrequestreview-3093713674

From alexey.ivanov at oracle.com  Wed Aug  6 19:08:04 2025
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 6 Aug 2025 20:08:04 +0100
Subject: Flagging JDK-4851378 as duplicate of JDK-8176501
In-Reply-To: <em8bff8d3c-697f-4e08-888e-cec06221669d@3043ce10.com>
References: <em8bff8d3c-697f-4e08-888e-cec06221669d@3043ce10.com>
Message-ID: <4f1594a0-562d-4c5d-967e-78ad5005967c@oracle.com>

Hi Jeremy,

I read both JDK-4851378 and JDK-8176501, they indeed seem to be 
duplicate of each other.

Just close JDK-4851378 as Duplicate and add duplicates link to 
JDK-8176501, you may add a comment explaining why they're duplicate. 
JDK-4851378 contains a test case, you may want to attach a screenshot 
which demonstrates what's painted before and after JDK-8176501 is fixed.

On 2025-08-06 05:56, Jeremy Wood wrote:
> What is the protocol to flag one JDK ticket as a duplicate of another?
>
> This ticket <https://bugs.openjdk.org/browse/JDK-4851378> appears to 
> be a duplicate of the ticket addressed in this PR 
> <https://github.com/openjdk/jdk/pull/6227> a few years ago.
>
> Regards,
> ?- Jeremy
-- 
Regards,
Alexey

https://bugs.openjdk.org/browse/JDK-4851378
https://bugs.openjdk.org/browse/JDK-8176501

From aivanov at openjdk.org  Wed Aug  6 19:21:33 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 19:21:33 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v38]
In-Reply-To: <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
Message-ID: <sdsM71mIczZoQj4qW5B_NfnUx9eegb1lIgYIW1nf_cA=.43d294ca-632c-43a2-b1a0-10dc59f66fb1@github.com>

On Mon, 4 Aug 2025 05:31:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - Fix not needed background effect for Windows 10
>  - Remove Windows version check
>  - Merge master
>  - bullet/checkmark placement for varying imageicon size fix, test update
>  - Adjust offset for varying size imageicon
>  - squish fix
>  - Alignment fix
>  - MenuItem with icon fix
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/57553ca1...5f51ecdc

I do not think that removing the background that Windows 10 provides is the correct way to resolve the problem.

I still think the current menu layout doesn't match what we see in Windows 11 File Explorer. If you applied the right margins between check mark / bullet column and the icon, there would be no clash that we see on Alex's screenshot from Windows 10.

Additionally, the size of the icon should not affect the size of the highlight that's still seen in Windows 10, I think it should remain 16?16 per the default size of the check mark and bullet.

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

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3161309759

From philip.race at oracle.com  Wed Aug  6 19:26:45 2025
From: philip.race at oracle.com (Philip Race)
Date: Wed, 6 Aug 2025 12:26:45 -0700
Subject: Flagging JDK-4851378 as duplicate of JDK-8176501
In-Reply-To: <4f1594a0-562d-4c5d-967e-78ad5005967c@oracle.com>
References: <em8bff8d3c-697f-4e08-888e-cec06221669d@3043ce10.com>
 <4f1594a0-562d-4c5d-967e-78ad5005967c@oracle.com>
Message-ID: <90fd07df-c9a4-4086-8a17-39e1c546425f@oracle.com>


That bug also lists several other bugs as known duplicates.
A couple seemed to be different but 3 were the same.
I've made them all duplicates of JDK-8176501

-phil.


On 8/6/25 12:08 PM, Alexey Ivanov wrote:
> Hi Jeremy,
>
> I read both JDK-4851378 and JDK-8176501, they indeed seem to be 
> duplicate of each other.
>
> Just close JDK-4851378 as Duplicate and add duplicates link to 
> JDK-8176501, you may add a comment explaining why they're duplicate. 
> JDK-4851378 contains a test case, you may want to attach a screenshot 
> which demonstrates what's painted before and after JDK-8176501 is fixed.
>
> On 2025-08-06 05:56, Jeremy Wood wrote:
>> What is the protocol to flag one JDK ticket as a duplicate of another?
>>
>> This ticket <https://bugs.openjdk.org/browse/JDK-4851378> appears to 
>> be a duplicate of the ticket addressed in this PR 
>> <https://github.com/openjdk/jdk/pull/6227> a few years ago.
>>
>> Regards,
>> ?- Jeremy


From philip.race at oracle.com  Wed Aug  6 19:26:45 2025
From: philip.race at oracle.com (Philip Race)
Date: Wed, 6 Aug 2025 12:26:45 -0700
Subject: Flagging JDK-4851378 as duplicate of JDK-8176501
In-Reply-To: <4f1594a0-562d-4c5d-967e-78ad5005967c@oracle.com>
References: <em8bff8d3c-697f-4e08-888e-cec06221669d@3043ce10.com>
 <4f1594a0-562d-4c5d-967e-78ad5005967c@oracle.com>
Message-ID: <90fd07df-c9a4-4086-8a17-39e1c546425f@oracle.com>


That bug also lists several other bugs as known duplicates.
A couple seemed to be different but 3 were the same.
I've made them all duplicates of JDK-8176501

-phil.


On 8/6/25 12:08 PM, Alexey Ivanov wrote:
> Hi Jeremy,
>
> I read both JDK-4851378 and JDK-8176501, they indeed seem to be 
> duplicate of each other.
>
> Just close JDK-4851378 as Duplicate and add duplicates link to 
> JDK-8176501, you may add a comment explaining why they're duplicate. 
> JDK-4851378 contains a test case, you may want to attach a screenshot 
> which demonstrates what's painted before and after JDK-8176501 is fixed.
>
> On 2025-08-06 05:56, Jeremy Wood wrote:
>> What is the protocol to flag one JDK ticket as a duplicate of another?
>>
>> This ticket <https://bugs.openjdk.org/browse/JDK-4851378> appears to 
>> be a duplicate of the ticket addressed in this PR 
>> <https://github.com/openjdk/jdk/pull/6227> a few years ago.
>>
>> Regards,
>> ?- Jeremy


From bchristi at openjdk.org  Wed Aug  6 19:32:16 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 6 Aug 2025 19:32:16 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs
In-Reply-To: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
Message-ID: <pPtqa6pbavYurVPRANfREsaIBd3oaRrzH8RxDdTRMVI=.c058bcb6-ed7d-43ac-b252-06b9a7b14724@github.com>

On Tue, 5 Aug 2025 21:17:36 GMT, Phil Race <prr at openjdk.org> wrote:

> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
> As a result, sub-classes which over-ride it to be empty no longer need to do so.
> Also it means that the 2 remaining classes which used it no longer can.
> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
> really meant to clean up internal resources.
> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
> 
> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
> The risks of this will be covered in the CSR.
> 
> There's also a lengthy write up in the JBS issue.

Changes requested by bchristi (Reviewer).

src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java line 275:

> 273:         //cache.close();
> 274:         cache = null;
> 275:         //cacheFile.delete();

Remove commented code?

src/java.desktop/share/classes/javax/imageio/stream/package-info.java line 48:

> 46:  * of sequences of bytes that reduces the amount of internal data copying.
> 47:  * <p>
> 48:  * An {@code ImageInputStream} or {@code ImageInputStream} may internally allocate

"...or Image**Output**Stream..." ?

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

PR Review: https://git.openjdk.org/jdk/pull/26650#pullrequestreview-3093759313
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258082917
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2257961502

From prr at openjdk.org  Wed Aug  6 19:39:08 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:39:08 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v3]
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <h7dxXciP_nVvDZ5FuYqEa2xlUX_8cZfEBUMkajj8KgI=.a4a4f502-52ce-4bf5-9749-ab55d945b4f6@github.com>

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

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

  8364230

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26519/files
  - new: https://git.openjdk.org/jdk/pull/26519/files/e37e57c2..41fdf62e

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

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

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

From prr at openjdk.org  Wed Aug  6 19:39:10 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:39:10 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v3]
In-Reply-To: <z23-G9qDrahHOzP_o7zCs-mruhQZPlU6ckmrVmd-270=.d0ae5406-d3a2-482b-be74-2b4138f9bef8@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <z23-G9qDrahHOzP_o7zCs-mruhQZPlU6ckmrVmd-270=.d0ae5406-d3a2-482b-be74-2b4138f9bef8@github.com>
Message-ID: <8gyond85JKGWxyqc-5ThQcB1za2GmhhmZiipeBcTK98=.1d7afd40-6067-4867-b077-8555baaa247e@github.com>

On Tue, 29 Jul 2025 10:35:10 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364230
>
> src/java.desktop/share/classes/javax/swing/text/StringContent.java line 27:
> 
>> 25: package javax.swing.text;
>> 26: 
>> 27: import java.util.Vector;
> 
> Could you please update copyright in this file?

I'm not a fan of this tedious process.

> test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 29:
> 
>> 27: 
>> 28: /*
>> 29:  * @test
> 
> Could you please add `@bug` with bug id here

what bug ?
This isn't a test for a bug fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2252578257
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2252570614

From prr at openjdk.org  Wed Aug  6 19:39:12 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:39:12 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v3]
In-Reply-To: <j37dB7al9Yonxg5yXPImSeeREj6BQdteh0n1OFhd9u0=.52c32a22-ced0-4065-9d7f-13d8b1bfad5a@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <j37dB7al9Yonxg5yXPImSeeREj6BQdteh0n1OFhd9u0=.52c32a22-ced0-4065-9d7f-13d8b1bfad5a@github.com>
Message-ID: <cBY2khoAvXqS2mm1mjv3ebTv6uhUs6tvsHxVBHSDKX4=.0d8c3964-ad91-4834-9a61-c04b6439af8b@github.com>

On Fri, 1 Aug 2025 05:19:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364230
>
> src/java.desktop/share/classes/javax/swing/text/StringContent.java line 29:
> 
>> 27: import java.util.Vector;
>> 28: import java.io.Serializable;
>> 29: import javax.swing.undo.*;
> 
> wildcard

I am not doing clean up

> test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 65:
> 
>> 63:         for (int i=0; i<SIZE; i++) {
>> 64:             if (positions[i].getOffset() != 0) {
>> 65:                System.err.println("remove: Bad offset i=" + i + " off=" + positions[i].getOffset());
> 
> Why a RuntimeException is not thrown instead of just logging?

Because I was testing and wanted to see all errors - I've fixed this now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2252569854
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2252581327

From prr at openjdk.org  Wed Aug  6 19:39:14 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:39:14 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v2]
In-Reply-To: <AuAy50Hpki9QeaSGbYShh5VtXyzVWA8mDqHgdtjir-Y=.8c461e27-0538-42bf-826a-3e1fe156ea81@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <5ukKwWzpYzEiAaeJ6YCIRmkg90Z4_UEgdxF7iKaGNn0=.c84a5018-c04d-4b18-a1a8-df4af8e8d16c@github.com>
 <AuAy50Hpki9QeaSGbYShh5VtXyzVWA8mDqHgdtjir-Y=.8c461e27-0538-42bf-826a-3e1fe156ea81@github.com>
Message-ID: <03bdefgXmAKRKesFtHZAKSWxbNeMlgOU66rUIGdyCNA=.ed304d20-b8da-487b-a595-e0c387b0f9dd@github.com>

On Wed, 6 Aug 2025 05:43:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364230
>
> test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 33:
> 
>> 31:  */
>> 32: 
>> 33: public class StringContentPositionTest {
> 
> I believe @bug is not added because this is not strictly a regression test for this issue as I see it does not fail even without the fix?
> Since `System.gc` is used, can we try restricting the heap size in commandline to see if it will fail without the fix and pass with it?

It won't fail either way.  I just changed how the clean up was done.
And GC is kicking in anyway with default settings.
So no point on both counts.

> test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 54:
> 
>> 52:         for (int i = 0; i < SIZE; i++) {
>> 53:             SC.insertString(0, TEXT);
>> 54:             positions[i] = SC.createPosition(5);
> 
> should it be LEN instead of 5?

yes. fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2258090594
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2258091404

From prr at openjdk.org  Wed Aug  6 19:39:16 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:39:16 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v3]
In-Reply-To: <2sPT_bmjwCqDaVu6zEQqx5TGGmOj5DGPq86-XktyV_Y=.bdb2a33c-10d3-4d03-afef-30c63f315d72@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <2sPT_bmjwCqDaVu6zEQqx5TGGmOj5DGPq86-XktyV_Y=.bdb2a33c-10d3-4d03-afef-30c63f315d72@github.com>
Message-ID: <Pjpbm9WeyEnj8sNq6xJHPEE1mACIZBEUdp9va8QQx9o=.c2c16890-30a3-48da-8b5a-00b87cb46f9d@github.com>

On Fri, 1 Aug 2025 06:11:21 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364230
>
> test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 38:
> 
>> 36:     static final String text = "hello";
>> 37:     static final int LEN = text.length();
>> 38:     static final StringContent st = new StringContent();
> 
> For consistency, static final variables can be capitalized.

OK ... and it made me notice I wasn't using text/TEXT - fixed that

> test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 56:
> 
>> 54:             positions[i] = st.createPosition(5);
>> 55:         }
>> 56:         for (int i=0; i<SIZE; i++) {
> 
> Suggestion:
> 
>         for (int i = 0; i < SIZE; i++) {

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2252580252
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2252580366

From prr at openjdk.org  Wed Aug  6 19:39:18 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:39:18 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v3]
In-Reply-To: <A4JyvGe3XoZcaMuhc9a4291bFUTPHIcl6H4nx87ikgE=.b1d344e7-36af-479f-8f6c-af01bdff2b11@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <A4JyvGe3XoZcaMuhc9a4291bFUTPHIcl6H4nx87ikgE=.b1d344e7-36af-479f-8f6c-af01bdff2b11@github.com>
Message-ID: <01PYGUq-frjCTZl6tny9amUvVkBi8aVH1JQaHevn9Bc=.f7b92e42-2334-4276-910a-3de6c792b43e@github.com>

On Tue, 29 Jul 2025 12:06:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364230
>
> test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 62:
> 
>> 60:            }
>> 61:         }
>> 62:         st.remove(0,  SIZE * LEN);
> 
> Suggestion:
> 
>         st.remove(0, SIZE * LEN);

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2252580675

From prr at openjdk.org  Wed Aug  6 19:41:41 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:41:41 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v2]
In-Reply-To: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
Message-ID: <naFUeWy3VcI8vlO1BHeXc6PNSHaV6l-zngPCYdIGv3U=.3625d4a2-8d23-44f0-8740-113b763dfd52@github.com>

> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
> As a result, sub-classes which over-ride it to be empty no longer need to do so.
> Also it means that the 2 remaining classes which used it no longer can.
> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
> really meant to clean up internal resources.
> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
> 
> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
> The risks of this will be covered in the CSR.
> 
> There's also a lengthy write up in the JBS issue.

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

  8277585

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26650/files
  - new: https://git.openjdk.org/jdk/pull/26650/files/edbbbd4f..8aabb9d8

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

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

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

From prr at openjdk.org  Wed Aug  6 19:41:41 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 19:41:41 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v2]
In-Reply-To: <pPtqa6pbavYurVPRANfREsaIBd3oaRrzH8RxDdTRMVI=.c058bcb6-ed7d-43ac-b252-06b9a7b14724@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <pPtqa6pbavYurVPRANfREsaIBd3oaRrzH8RxDdTRMVI=.c058bcb6-ed7d-43ac-b252-06b9a7b14724@github.com>
Message-ID: <f5-GTaVPMcG2PnBNTq31ZF2_CGpMbUsrXk7G8wpx3To=.69eff2e8-2431-409b-a80f-fccaa5d1aa38@github.com>

On Wed, 6 Aug 2025 19:29:01 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277585
>
> src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java line 275:
> 
>> 273:         //cache.close();
>> 274:         cache = null;
>> 275:         //cacheFile.delete();
> 
> Remove commented code?

yep

> src/java.desktop/share/classes/javax/imageio/stream/package-info.java line 48:
> 
>> 46:  * of sequences of bytes that reduces the amount of internal data copying.
>> 47:  * <p>
>> 48:  * An {@code ImageInputStream} or {@code ImageInputStream} may internally allocate
> 
> "...or Image**Output**Stream..." ?

fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258094919
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258097744

From aivanov at openjdk.org  Wed Aug  6 20:18:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Aug 2025 20:18:15 GMT
Subject: RFR: 8364363: Modify some manual test instructions
In-Reply-To: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
References: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
Message-ID: <R-GOZV89lBHRfupG9_S-bHrenlhIAuGa6CHurJEZXUI=.bbb46cb1-4116-4f19-96a9-addbe9392080@github.com>

On Tue, 5 Aug 2025 09:33:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> When testing jtreg manual tests, some tests had unclear instructions. This PR is an attempt at updating these tests for clarity. 
> 
> `MouseDraggedOriginatedByScrollBarTest.java` works as expected when compared to native apps and outputs drag events even when the mouse pointer is dragged off of the scrollbar and window altogether. Events should still fire, but the previous instructions may make this confusing since it reads as if no events should be output to the textarea at all.
> 
> `TextAreaAppendScrollTest2.java` seems to not work when testing with the previous implementation of programmatically appending strings to the textarea. When I scroll down using the down arrow key, none of the text below would be visible when the textarea is scrolled down. However, it would show if I pressed `ENTER` to create a new line or manually modify the text in the textarea first. So instead, I have implemented the original reported approach to the test of adding a button to append a string to the textarea to test for automatic scrolling when the word is wrapped to a new line.

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 48:

> 46:             3) The test fails if you see messages about drag
> 47:             events for anything other than list0.
> 48:             The test passes if you don't.

Is it possible to automate this part? I mean, automatically flag the test as failed (after displaying a message to the tester after dragging is complete).

test/jdk/java/awt/TextArea/TextAreaAppendScrollTest2.java line 71:

> 69:             coolStr.append("cool ");
> 70:         }
> 71:         area.append(coolStr.toString());

Is adding `12 * 15` _cools_ not enough?

The original instructions are pretty clear: if you see the exclamation marks, then auto-scrolling works correctly; otherwise, it auto-scrolling doesn't work as expected and the tester has to click **Fail**.

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

PR Review: https://git.openjdk.org/jdk/pull/26636#pullrequestreview-3094081274
PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2258176698
PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2258188866

From prr at openjdk.org  Wed Aug  6 21:29:24 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 21:29:24 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v38]
In-Reply-To: <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
Message-ID: <J17BRlgn6QpycvrX-FFQ6E-CYLos5JFjK1cvYgqHNb8=.5893a278-752d-48c2-8575-0653a572b04b@github.com>

On Mon, 4 Aug 2025 05:31:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - Fix not needed background effect for Windows 10
>  - Remove Windows version check
>  - Merge master
>  - bullet/checkmark placement for varying imageicon size fix, test update
>  - Adjust offset for varying size imageicon
>  - squish fix
>  - Alignment fix
>  - MenuItem with icon fix
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/57553ca1...5f51ecdc

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-3094362194

From duke at openjdk.org  Wed Aug  6 21:44:16 2025
From: duke at openjdk.org (duke)
Date: Wed, 6 Aug 2025 21:44:16 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v5]
In-Reply-To: <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
Message-ID: <Dv5Ca_Q4Mj0HRIomhEiqkz5xeFM0geZ79yGQvwWBZBo=.bc07e312-8096-4190-adb4-81d95dbb62f5@github.com>

On Wed, 6 Aug 2025 16:19:56 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25688#issuecomment-3161715075

From achung at openjdk.org  Wed Aug  6 21:48:30 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 6 Aug 2025 21:48:30 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v2]
In-Reply-To: <naFUeWy3VcI8vlO1BHeXc6PNSHaV6l-zngPCYdIGv3U=.3625d4a2-8d23-44f0-8740-113b763dfd52@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <naFUeWy3VcI8vlO1BHeXc6PNSHaV6l-zngPCYdIGv3U=.3625d4a2-8d23-44f0-8740-113b763dfd52@github.com>
Message-ID: <JrHGy2XyPC_fZ9jh-oC_nZqd8vGicEM95zZ_4S5oaOs=.f9589581-4c0d-4fe6-8b65-94e812dd8b8d@github.com>

On Wed, 6 Aug 2025 19:41:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
>> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
>> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
>> really meant to clean up internal resources.
>> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
>> 
>> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
>> The risks of this will be covered in the CSR.
>> 
>> There's also a lengthy write up in the JBS issue.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277585

src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java line 238:

> 236:         private volatile boolean disposed;
> 237: 
> 238:         public FileCacheDisposerRecord(File cacheFile, RandomAccessFile cache) {

FileCacheDisposer makes more sense based on what the code does, but would StreamDisposerRecord be better to remain consistent for the input/output streams?

src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java line 249:

> 247:             }
> 248:             try {
> 249:                 cache.close();

I notice a similar nested class/method in FileCacheImageInputStream with a few differences. Does the cache.close() and cacheFile.delete need to be wrapped in null checks? And once deleted do the StreamDisposerRecord pointers (this.cacheFile and this.cache) need to be set to null like in the ImageInputStream version of the code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258381256
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258358972

From achung at openjdk.org  Wed Aug  6 22:02:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 6 Aug 2025 22:02:15 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v2]
In-Reply-To: <naFUeWy3VcI8vlO1BHeXc6PNSHaV6l-zngPCYdIGv3U=.3625d4a2-8d23-44f0-8740-113b763dfd52@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <naFUeWy3VcI8vlO1BHeXc6PNSHaV6l-zngPCYdIGv3U=.3625d4a2-8d23-44f0-8740-113b763dfd52@github.com>
Message-ID: <Gebo6eKXFa1RB37QN7wg_VjsN6ZZoUHrDODpb9wZEh4=.fa8e04e5-6cbf-4f30-8c2c-35d8bee01fab@github.com>

On Wed, 6 Aug 2025 19:41:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
>> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
>> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
>> really meant to clean up internal resources.
>> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
>> 
>> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
>> The risks of this will be covered in the CSR.
>> 
>> There's also a lengthy write up in the JBS issue.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277585

src/java.desktop/share/classes/javax/imageio/stream/package-info.java line 60:

> 58:  * {@snippet lang='java':
> 59:  * try (FileOutputStream fos = new FileOutputStream("out.jpg");
> 60:  *     (ImageOutputStream ios = new FileCacheImageOutputStream(fos, null)) {

I think there is an extra left parenthesis here at the start of the line

src/java.desktop/share/classes/javax/imageio/stream/package-info.java line 66:

> 64:  * }
> 65:  * <p>
> 66:  * Sub-classers of these Image I/O API stream types can to a limited extent protect

Commas missing here
`Sub-classers of these Image I/O API stream types can, to a limited extent, protect`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258402538
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258404716

From prr at openjdk.org  Wed Aug  6 22:34:30 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 22:34:30 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
Message-ID: <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>

> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
> As a result, sub-classes which over-ride it to be empty no longer need to do so.
> Also it means that the 2 remaining classes which used it no longer can.
> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
> really meant to clean up internal resources.
> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
> 
> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
> The risks of this will be covered in the CSR.
> 
> There's also a lengthy write up in the JBS issue.

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

  8277585

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26650/files
  - new: https://git.openjdk.org/jdk/pull/26650/files/8aabb9d8..7d422513

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

  Stats: 32 lines in 3 files changed: 1 ins; 26 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26650/head:pull/26650

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

From prr at openjdk.org  Wed Aug  6 22:34:31 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Aug 2025 22:34:31 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v2]
In-Reply-To: <JrHGy2XyPC_fZ9jh-oC_nZqd8vGicEM95zZ_4S5oaOs=.f9589581-4c0d-4fe6-8b65-94e812dd8b8d@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <naFUeWy3VcI8vlO1BHeXc6PNSHaV6l-zngPCYdIGv3U=.3625d4a2-8d23-44f0-8740-113b763dfd52@github.com>
 <JrHGy2XyPC_fZ9jh-oC_nZqd8vGicEM95zZ_4S5oaOs=.f9589581-4c0d-4fe6-8b65-94e812dd8b8d@github.com>
Message-ID: <ClhAsz9cEeoS9AUvcaLmdUgriEIRRiWXsDM9tt3BBJk=.2c602876-1f48-4254-9712-1e2680c8dad3@github.com>

On Wed, 6 Aug 2025 21:41:27 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277585
>
> src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java line 238:
> 
>> 236:         private volatile boolean disposed;
>> 237: 
>> 238:         public FileCacheDisposerRecord(File cacheFile, RandomAccessFile cache) {
> 
> FileCacheDisposer makes more sense based on what the code does, but would StreamDisposerRecord be better to remain consistent for the input/output streams?

Sure, see comment below.

> src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java line 249:
> 
>> 247:             }
>> 248:             try {
>> 249:                 cache.close();
> 
> I notice a similar nested class/method in FileCacheImageInputStream with a few differences. Does the cache.close() and cacheFile.delete need to be wrapped in null checks? And once deleted do the StreamDisposerRecord pointers (this.cacheFile and this.cache) need to be set to null like in the ImageInputStream version of the code?

Yes, I could re-use that. I just need to make it accessible .. but not public.
That one has null checks because it clears the vars. 
My version uses a "disposed" var for the same since I made those vars final.

> src/java.desktop/share/classes/javax/imageio/stream/package-info.java line 60:
> 
>> 58:  * {@snippet lang='java':
>> 59:  * try (FileOutputStream fos = new FileOutputStream("out.jpg");
>> 60:  *     (ImageOutputStream ios = new FileCacheImageOutputStream(fos, null)) {
> 
> I think there is an extra left parenthesis here at the start of the line

fixed

> src/java.desktop/share/classes/javax/imageio/stream/package-info.java line 66:
> 
>> 64:  * }
>> 65:  * <p>
>> 66:  * Sub-classers of these Image I/O API stream types can to a limited extent protect
> 
> Commas missing here
> `Sub-classers of these Image I/O API stream types can, to a limited extent, protect`

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258441776
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258441819
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258443191
PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258447549

From bchristi at openjdk.org  Thu Aug  7 00:12:14 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 7 Aug 2025 00:12:14 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v2]
In-Reply-To: <ClhAsz9cEeoS9AUvcaLmdUgriEIRRiWXsDM9tt3BBJk=.2c602876-1f48-4254-9712-1e2680c8dad3@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <naFUeWy3VcI8vlO1BHeXc6PNSHaV6l-zngPCYdIGv3U=.3625d4a2-8d23-44f0-8740-113b763dfd52@github.com>
 <JrHGy2XyPC_fZ9jh-oC_nZqd8vGicEM95zZ_4S5oaOs=.f9589581-4c0d-4fe6-8b65-94e812dd8b8d@github.com>
 <ClhAsz9cEeoS9AUvcaLmdUgriEIRRiWXsDM9tt3BBJk=.2c602876-1f48-4254-9712-1e2680c8dad3@github.com>
Message-ID: <6Kn4kVKRTHwaxHvvjcpH8IDkebfREzgkMyKZKoSHpzA=.50ed7197-e5d0-471c-940b-e4d29a8f325e@github.com>

On Wed, 6 Aug 2025 22:25:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java line 249:
>> 
>>> 247:             }
>>> 248:             try {
>>> 249:                 cache.close();
>> 
>> I notice a similar nested class/method in FileCacheImageInputStream with a few differences. Does the cache.close() and cacheFile.delete need to be wrapped in null checks? And once deleted do the StreamDisposerRecord pointers (this.cacheFile and this.cache) need to be set to null like in the ImageInputStream version of the code?
>
> Yes, I could re-use that. I just need to make it accessible .. but not public.
> That one has null checks because it clears the vars. 
> My version uses a "disposed" var for the same since I made those vars final.

Use of `final` is recommended wherever possible, as the values are then guaranteed to be visible on other threads (e.g. the disposer thread).

However IIUC, values set in a `DisposerRecord` by a program thread should (already) be visible on the disposer thread because `Disposer.add()` and `Disposer.run()` (via `records.put()` and `records.remove()`, respectively) lock the same `records` `Hashtable` object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26650#discussion_r2258574384

From psadhukhan at openjdk.org  Thu Aug  7 04:22:19 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 7 Aug 2025 04:22:19 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0
In-Reply-To: <TcQtEtcFgYh1LU2AlT4TFqbDknMXr7yiRuFqwIO-uuQ=.ecffebff-fadb-4fd7-bcc4-1450893608d4@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <LR56gUD-lr5heXd4rz9iVC4SvDlCMUJkVXO7_plBuLE=.145eb7ea-f327-4c25-b5e6-5697857f4caf@github.com>
 <2hCwbX522BypcHQMhMrOL6gx0gVPqSVT5C0wOzvQx-U=.17ac8712-fd4a-4865-a6aa-4e21a3b6220f@github.com>
 <TcQtEtcFgYh1LU2AlT4TFqbDknMXr7yiRuFqwIO-uuQ=.ecffebff-fadb-4fd7-bcc4-1450893608d4@github.com>
Message-ID: <LYZmJxxp20Glb8TS_r2rSUl6pgFRrURhBSizgD2GO2U=.e74f0c63-7333-42db-bbe8-db538eb16658@github.com>

On Wed, 6 Aug 2025 15:49:19 GMT, Phil Race <prr at openjdk.org> wrote:

> > > Isn't this just a bug ? I get zero from the test whenever "-1" is the direction - meaning scroll up - even if I use something like
> > > https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/JList.html#getScrollableUnitIncrement(java.awt.Rectangle,int,int)
> > 
> > 
> > If the `visibleRect` Rectangle points to the 1st row or row 0 and we are scrolling up i.e -1 direction there is no more space to scroll up so `getScrollableUnitIncrement` returns 0. If we modify the testcase to have `Rectangle cell = list.getCellBounds(data.length-1, data.length-1);` instead of `list.getCellBounds(0, 0);` to point to last cell, it returns positive number for -1 direction too
> 
> As I wrote it returns zero for me no matter what. Eg if I use Rectangle cell = list.getCellBounds(1, 2);
> 
> so why is that ?

That is because of test does wrap layout via this line `list.setLayoutOrientation(JList.HORIZONTAL_WRAP);`
whereby 1st and 2nd cell are in the same row 0 and then it wraps to next line where it displays 3rd and 4th cell so if we call 
`list.getCellBounds(1, 2)` it will still result in pointing to 1st row or row 0
 
but if we call getCellBounds(2, 3) it will have positive number and not 0 as then it will select the 2nd row because cell 3 is in 2nd row.

If we remove `list.setLayoutOrientation(JList.HORIZONTAL_WRAP);` then it will layout each cell in separate line so we will get positive number for `list.getCellBounds(1, 2)`  too as then it will select the 2nd row and not 1st row for which scrolling is not required.

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

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

From psadhukhan at openjdk.org  Thu Aug  7 04:34:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 7 Aug 2025 04:34:16 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v3]
In-Reply-To: <h7dxXciP_nVvDZ5FuYqEa2xlUX_8cZfEBUMkajj8KgI=.a4a4f502-52ce-4bf5-9749-ab55d945b4f6@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <h7dxXciP_nVvDZ5FuYqEa2xlUX_8cZfEBUMkajj8KgI=.a4a4f502-52ce-4bf5-9749-ab55d945b4f6@github.com>
Message-ID: <uLXJ_HeCgnNV9QdwlTkXrKnIDTExV-h8B-OJT8PBaRQ=.5418e445-92ea-4280-88f4-52fe40ae5364@github.com>

On Wed, 6 Aug 2025 19:39:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Convert StringContent's Position usage tracking to use a WeakReference
>> 
>> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364230

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26519#pullrequestreview-3095213319

From abhiscxk at openjdk.org  Thu Aug  7 04:38:17 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Aug 2025 04:38:17 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize [v3]
In-Reply-To: <h7dxXciP_nVvDZ5FuYqEa2xlUX_8cZfEBUMkajj8KgI=.a4a4f502-52ce-4bf5-9749-ab55d945b4f6@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
 <h7dxXciP_nVvDZ5FuYqEa2xlUX_8cZfEBUMkajj8KgI=.a4a4f502-52ce-4bf5-9749-ab55d945b4f6@github.com>
Message-ID: <1jAZepKFbFQjQCXPVWwOyqmd_N0iBf2HwNcS6Id5tcA=.44426fc3-ccd0-491b-a6a5-b12a0f3219d0@github.com>

On Wed, 6 Aug 2025 19:39:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Convert StringContent's Position usage tracking to use a WeakReference
>> 
>> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364230

Marked as reviewed by abhiscxk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26519#pullrequestreview-3095226331

From mbaesken at openjdk.org  Thu Aug  7 08:21:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Aug 2025 08:21:17 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times out
 on Windows
Message-ID: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>

java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
Add some logging to the test, and we could also increase the test timeout a bit.

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

Commit messages:
 - JDK-8364996

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

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

From clanger at openjdk.org  Thu Aug  7 08:26:17 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 7 Aug 2025 08:26:17 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows
In-Reply-To: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
Message-ID: <n9TCgDK8okFjonvkehbkbVPLWCes6gWLAvJqR0t6DPQ=.fa0c08db-4fd8-45c7-ad4d-f4ae79cc340e@github.com>

On Thu, 7 Aug 2025 08:14:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
> Add some logging to the test, and we could also increase the test timeout a bit.

Looks good. What is the reason to use othervm mode?

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26668#pullrequestreview-3095986412

From aturbanov at openjdk.org  Thu Aug  7 09:23:23 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 7 Aug 2025 09:23:23 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <5iZukFjzLJR-FOVx4fRVFgpf0Bdywj6bUfwfxCt_qTk=.f4cdf403-6168-4192-acea-aca73e1ec515@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
 <5iZukFjzLJR-FOVx4fRVFgpf0Bdywj6bUfwfxCt_qTk=.f4cdf403-6168-4192-acea-aca73e1ec515@github.com>
Message-ID: <yLDRaibHbXBRgwK8Or4r4kb1zsEPKn-YIaOJMNQ8fsw=.5db8981f-0891-4b2f-9821-7c24ead5733d@github.com>

On Wed, 6 Aug 2025 12:44:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Looks like no reasons for it to be instance field
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java line 377:
> 
>> 375:         private static String NAVIGATE_NEXT = "navigateNext";
>> 376:         private static String NAVIGATE_PREVIOUS = "navigatePrevious";
>> 377:         private static final int MOVE_RESIZE_INCREMENT = 10;
> 
> It appears that all of the above strings in `Actions` class can be final.

Yep. I noticed that in JDK some of constant String's are not marked as `final`. Not sure what the reason for that.
It deserves a separate issue for investigation/fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25893#discussion_r2259675372

From aivanov at openjdk.org  Thu Aug  7 10:25:24 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Aug 2025 10:25:24 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v5]
In-Reply-To: <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <zzL63cCp2B-NQpRkp4nzKYoC3Tv9VgDULRXrb96t-kM=.b6a23106-0b8f-4aa2-98a8-f175578b9170@github.com>
Message-ID: <L2TMsurzQIuLaJkPWbMovJyQfdPVJa90jJgVAH4LuLU=.cd1cffd0-2a7d-4924-bc0a-cc9e272f081a@github.com>

On Wed, 6 Aug 2025 16:19:56 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Client tests are green. I ran a job yesterday with the latest updates.

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

PR Comment: https://git.openjdk.org/jdk/pull/25688#issuecomment-3163469720

From duke at openjdk.org  Thu Aug  7 10:25:25 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 7 Aug 2025 10:25:25 GMT
Subject: Integrated: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts
In-Reply-To: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
Message-ID: <LCMzUNzUQD2h_0tQiwBzmn31ndGNg6YIpAjBz-06i14=.31ec7cd5-9925-43e9-8748-bd3cfbe9d32a@github.com>

On Mon, 9 Jun 2025 02:36:44 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
> 
> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)

This pull request has now been integrated.

Changeset: 8d73fe91
Author:    Jeremy Wood <mickleness at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d73fe91bccd1da53424b9f8a52d9efafabeb243
Stats:     121 lines in 2 files changed: 121 ins; 0 del; 0 mod

8358813: JPasswordField identifies spaces in password via delete shortcuts

Reviewed-by: aivanov, dnguyen

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

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

From aivanov at openjdk.org  Thu Aug  7 10:57:22 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Aug 2025 10:57:22 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts
In-Reply-To: <fFoaAXpGQlPPOhQFU6z6R-hcmB-VL-KeOwRITOV2vok=.adbd85e3-21e3-4f05-8c04-5ac3cdfae8af@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <fFoaAXpGQlPPOhQFU6z6R-hcmB-VL-KeOwRITOV2vok=.adbd85e3-21e3-4f05-8c04-5ac3cdfae8af@github.com>
Message-ID: <j189UY6EhSVKHJoq0eVuTM4ics4_1ElDet_A03N-6m4=.0c60b912-b421-41f2-967a-889e8b372470@github.com>

On Mon, 9 Jun 2025 02:40:02 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
>> 
>> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)
>
> IMO this PR is a simple response that interfaces with an existing method. I recommend this approach because it should be relatively low-risk, and it is based on existing precedent.
> 
> By contrast: #25443 does something more aggressive (and interesting). It replaces selectWordAction with selectLineAction. That looks (to me) like a more thorough/better approach to the general problem of accidentally interacting with words in a password field. This PR should resolve any *KeyStroke-based* actions, but in JDK-8354646 the original complaint had to do with double-clicking the mouse; so this PR wouldn't impact those steps.
> 
> I haven't explored this thoroughly yet, but glancing through the AccessibleJTextField suggests an AX interface could still have access (via AccessibleActions) to the word-related actions we're trying to restrict access to. If so: this problem (accessing words in a password field) keeps popping up, and removing/replacing the unwanted actions seems like the most thorough response.
> 
> (Also see JDK-6191897 and JDK-4231444 ).

@mickleness You should associate your GitHub account with your OpenJDK id, follow the instructions in [Associating your GitHub account and your OpenJDK username](https://wiki.openjdk.org/display/SKARA/#Skara-AssociatingyourGitHubaccountandyourOpenJDKusername).

After that, I also recommend following the instructions in the [OpenJDK Email](https://wiki.openjdk.org/display/SKARA/#Skara-OpenJDKEmail) section.

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

PR Comment: https://git.openjdk.org/jdk/pull/25688#issuecomment-3163574304

From mbaesken at openjdk.org  Thu Aug  7 11:41:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Aug 2025 11:41:15 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows
In-Reply-To: <n9TCgDK8okFjonvkehbkbVPLWCes6gWLAvJqR0t6DPQ=.fa0c08db-4fd8-45c7-ad4d-f4ae79cc340e@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
 <n9TCgDK8okFjonvkehbkbVPLWCes6gWLAvJqR0t6DPQ=.fa0c08db-4fd8-45c7-ad4d-f4ae79cc340e@github.com>
Message-ID: <PwJHqr5QNDhuocaLVZezoWy0287bgtFzdrxGHZNMkH8=.0a0206ba-5760-42f8-b70e-f9d688c5660e@github.com>

On Thu, 7 Aug 2025 08:23:35 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Looks good. What is the reason to use othervm mode?

AFAIK you need this to set a new separate test timeout value; at least I found this when looking through other tests with own special timeout settings.

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

PR Comment: https://git.openjdk.org/jdk/pull/26668#issuecomment-3163738402

From abhiscxk at openjdk.org  Thu Aug  7 11:55:34 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Aug 2025 11:55:34 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v4]
In-Reply-To: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
Message-ID: <ek08cb3IkBZO4um2VIOqquy4Q306oKNpSyG9EAMjCcw=.61c11669-6df1-4009-be52-40ba6ebb0115@github.com>

> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**.
> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect.
> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**.
> 
> After modifying the condition check, expected character is returned. Test is added to verify the check,

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

  index spec update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25941/files
  - new: https://git.openjdk.org/jdk/pull/25941/files/e9c5ae37..5afa7562

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

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

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

From abhiscxk at openjdk.org  Thu Aug  7 11:55:34 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Aug 2025 11:55:34 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
Message-ID: <Wby7ds1pWiqUAUoHe8CbdkZuhjw5bOKVYQYCbf_Nk-c=.e7d13efd-bbb6-46c2-b1e9-f75de3131c24@github.com>

On Tue, 24 Jun 2025 11:44:13 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**.
>> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect.
>> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**.
>> 
>> After modifying the condition check, expected character is returned. Test is added to verify the check,
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test extended for WORD and SENTENCE

>I said it a few times now, ?an index within the text? is a vague condition, we should update the specification so that it is clear which indexes are valid.

Updated the spec.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3163830528

From ngubarkov at openjdk.org  Thu Aug  7 12:02:02 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 7 Aug 2025 12:02:02 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v2]
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <qB0H_h3fK2DcRdSv7mWW8d1gSM82oXkgZYUKa9QnLv8=.96c2be3d-6a57-4bcb-b679-b4c37897a115@github.com>

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

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

  8364434: Inconsistent BufferedContext state after GC
  
  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26576/files
  - new: https://git.openjdk.org/jdk/pull/26576/files/849c74ce..822dc899

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

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

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

From ngubarkov at openjdk.org  Thu Aug  7 12:02:03 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 7 Aug 2025 12:02:03 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v2]
In-Reply-To: <o60Goywr_tirm5QuH4iqeH6hpm8HsqQeRM2GFpIDbWE=.f7e61894-de0c-4596-a657-f01ebad04e29@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <UC70cDpCeGrWoCpK69CxGyuIolLueAkPV1gEYc5VSDI=.d7b51c6a-6d91-4a22-82b4-6a76c5fba6fa@github.com>
 <o60Goywr_tirm5QuH4iqeH6hpm8HsqQeRM2GFpIDbWE=.f7e61894-de0c-4596-a657-f01ebad04e29@github.com>
Message-ID: <FcB_GsxPVCO2lnk0xeh1RkTG_TDFflMAgYZahj0q6xY=.988b387b-4c41-4132-a11c-ebc0b164c275@github.com>

On Tue, 5 Aug 2025 13:45:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java line 103:
>> 
>>> 101:     protected static BufferedContext currentContext;
>>> 102: 
>>> 103:     private Reference<AccelSurface> validSrcDataRef = null;
>> 
>> I think that you can wrap these fields into Optional ones to simplify the state change verification.
>
> For wrapping, you can use the following one-liner 
> `Optional.ofNullable(val).flatMap(e -> Optional.of(new WeakReference(val)));`

I don't really understand how this could simplify the check.
For wrapping, instead of `obj == null ? null : new WeakReference<>(obj)` it would become `Optional.ofNullable(obj).flatMap(e -> Optional.of(new WeakReference<>(obj)))`.
And for comparing the state, it would need to repeat the same logic with special treatment of `null` refs, just replacing the null check with `isEmpty()` - is this what you meant?
Overall, it seems easier to me to understand the null-check version, than the one wrapped into `Optional`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2260094434

From asteiner at openjdk.org  Thu Aug  7 12:05:14 2025
From: asteiner at openjdk.org (Andreas Steiner)
Date: Thu, 7 Aug 2025 12:05:14 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows
In-Reply-To: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
Message-ID: <zBBHIn_0SoijMN0MvlBl_GYM0g5sdMgYo4-6KLPdcjI=.13b9775f-716d-4d4a-8bfe-dc4124db8d9c@github.com>

On Thu, 7 Aug 2025 08:14:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
> Add some logging to the test, and we could also increase the test timeout a bit.

LGTM and the additional output will help to verify if on the affected machines a huge number of fonts or locales are causing this long runtimes.

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

Marked as reviewed by asteiner (Author).

PR Review: https://git.openjdk.org/jdk/pull/26668#pullrequestreview-3096834896

From abhiscxk at openjdk.org  Thu Aug  7 12:13:20 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Aug 2025 12:13:20 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v4]
In-Reply-To: <ek08cb3IkBZO4um2VIOqquy4Q306oKNpSyG9EAMjCcw=.61c11669-6df1-4009-be52-40ba6ebb0115@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <ek08cb3IkBZO4um2VIOqquy4Q306oKNpSyG9EAMjCcw=.61c11669-6df1-4009-be52-40ba6ebb0115@github.com>
Message-ID: <0sV3x50UQnnAJHwDkAxSXe1PSw0ASXRj-zo8s3FLItc=.27db5f50-ad1d-4a1d-a0f8-3ac656b826b9@github.com>

On Thu, 7 Aug 2025 11:55:34 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**.
>> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect.
>> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**.
>> 
>> After modifying the condition check, expected character is returned. Test is added to verify the check,
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   index spec update

There are similar APIs `getTextSequenceAt, getTextSequenceBefore and getTextSequenceAfter` for `AccessibleExtendedText` interface that invokes `getSequenceAtIndex` to return the `AccessibleTextSequence` and I think the fix is required for those method as well.
I also suspect `getTextBounds` method too that it may not return correct bound for `index = length of text` in case of CHARACTER and WORD. I will test and update in next commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3163928134

From abhiscxk at openjdk.org  Thu Aug  7 12:20:34 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Aug 2025 12:20:34 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v5]
In-Reply-To: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
Message-ID: <ZKiSnaaclzstxiKTZeL74Ll24m-ozclxMRpk-dfVLhE=.eaee4333-627e-42a5-9f20-7ae4a8e6febd@github.com>

> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**.
> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect.
> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**.
> 
> After modifying the condition check, expected character is returned. Test is added to verify the check,

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

  spec fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25941/files
  - new: https://git.openjdk.org/jdk/pull/25941/files/5afa7562..cdd90fe0

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

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

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

From ngubarkov at openjdk.org  Thu Aug  7 12:06:02 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 7 Aug 2025 12:06:02 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

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

  8364434: Inconsistent BufferedContext state after GC
  
  Old copyright year left from the test I copied

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26576/files
  - new: https://git.openjdk.org/jdk/pull/26576/files/822dc899..39d150dd

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

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

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

From abhiscxk at openjdk.org  Thu Aug  7 13:20:19 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 7 Aug 2025 13:20:19 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v9]
In-Reply-To: <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
Message-ID: <6CJoaw2gPozClI8Xsm8RcGQ-wH2fqwYnRZfT3MRJqVc=.c37729ba-4daf-49a0-b80b-a2773ec92e1b@github.com>

On Wed, 6 Aug 2025 09:43:48 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: Added review comment

LGTM

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

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26043#pullrequestreview-3097125780

From azvegint at openjdk.org  Thu Aug  7 13:25:37 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 7 Aug 2025 13:25:37 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v28]
In-Reply-To: <GIoLhJo9JxasvtBTtaA3uSlIQxu02smXwYHrD1kh9JU=.f5c75fac-e8ed-4ada-9085-17bc98686fe0@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <GIoLhJo9JxasvtBTtaA3uSlIQxu02smXwYHrD1kh9JU=.f5c75fac-e8ed-4ada-9085-17bc98686fe0@github.com>
Message-ID: <YWrSqVRO3IpJktRPiFqUeMTxOdri9O_bEyYXl5el0f0=.e0e089c4-d028-4ed9-9f90-c5cb618249e4@github.com>

On Tue, 5 Aug 2025 02:42:24 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved sentence describing method behavior into implSpec tag

src/java.desktop/share/classes/java/awt/Robot.java line 885:

> 883:      * @since   26
> 884:      */
> 885:     public void glide(int fromX, int fromY, int toX, int toY) {

Suggestion:

    public void glide(int srcX, int srcY, int dstX, int dstY) {


* for parameter naming consistency with the `public void glide(int srcX, int srcY, int destX, int destY, int stepLength, int stepDelay)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2260292050

From lbourges at openjdk.org  Thu Aug  7 14:11:16 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 7 Aug 2025 14:11:16 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]
In-Reply-To: <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
Message-ID: <mAiyUoOGZkl7btOLIilyAeEfBx6npFjOgOrHDRFI3gA=.d95cf01c-5b76-44a3-b6a0-478350ece166@github.com>

On Thu, 7 Aug 2025 12:06:02 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Old copyright year left from the test I copied

New test looks good

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3164363521

From kizune at openjdk.org  Thu Aug  7 15:47:32 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 7 Aug 2025 15:47:32 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v38]
In-Reply-To: <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
Message-ID: <JPco_WX88l6h9E6p1wf4ty0HzuoG0NB-FImOyn-Rs9w=.bbf85ace-ae4d-45cb-a133-5e8dcbb657a2@github.com>

On Mon, 4 Aug 2025 05:31:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - Fix not needed background effect for Windows 10
>  - Remove Windows version check
>  - Merge master
>  - bullet/checkmark placement for varying imageicon size fix, test update
>  - Adjust offset for varying size imageicon
>  - squish fix
>  - Alignment fix
>  - MenuItem with icon fix
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/57553ca1...5f51ecdc

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-3097758376

From achung at openjdk.org  Thu Aug  7 15:55:18 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 15:55:18 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v29]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <LkfQ0dlWg69O1gQbMGoZAZkS2_l5FLoEjDgqRohjqV8=.a5bf1b1e-a751-48d2-9d5c-d49339f02354@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  Update src/java.desktop/share/classes/java/awt/Robot.java
  
  Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/b478652f..f0910296

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=27-28

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

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

From psadhukhan at openjdk.org  Thu Aug  7 16:07:40 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 7 Aug 2025 16:07:40 GMT
Subject: Integrated: 8348760: RadioButton is not shown if JRadioButtonMenuItem
 is rendered with ImageIcon in WindowsLookAndFeel
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <NPHohDB-iSsnWbMUvaVD0v5Tk9SIaCTevdfiiphSVHk=.0b2ecafa-37c1-449f-a54c-d1d9d6002285@github.com>

On Tue, 28 Jan 2025 03:40:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

This pull request has now been integrated.

Changeset: e29346db
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e29346dbd6328dcadc347a70d8c06ce141efef02
Stats:     630 lines in 8 files changed: 524 ins; 81 del; 25 mod

8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel

Reviewed-by: prr, kizune, abhiscxk

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

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

From achung at openjdk.org  Thu Aug  7 16:10:06 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 16:10:06 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  update robot spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/f0910296..26f5a626

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

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

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

From kizune at openjdk.org  Thu Aug  7 16:12:14 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 7 Aug 2025 16:12:14 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
Message-ID: <mqP36j2pWK9hzP0jnmpwe-x7ukdegpBGP9x7d5CGLdU=.9e010677-17ac-4c89-ae16-e849911939df@github.com>

On Thu, 19 Jun 2025 08:25:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Looks like no reasons for it to be instance field

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25893#pullrequestreview-3097844002

From aivanov at openjdk.org  Thu Aug  7 16:25:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Aug 2025 16:25:16 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
Message-ID: <fpLdFPMwOPIx5aJABszjmCLL7PyhuX6RrNC366T3y9Q=.e85cacf9-728f-4d65-b653-c104b8687b22@github.com>

On Thu, 19 Jun 2025 08:25:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Looks like no reasons for it to be instance field

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java line 33:

> 31: import java.beans.*;
> 32: 
> 33: import java.awt.event.ActionEvent;

I suggest expanding all the wildcard imports:


import java.awt.Component;
import java.awt.Container;
import java.awt.Dimension;
import java.awt.FocusTraversalPolicy;
import java.awt.Graphics;
import java.awt.Insets;
import java.awt.KeyboardFocusManager;
import java.awt.Point;
import java.awt.event.ActionEvent;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.beans.PropertyVetoException;

import javax.swing.AbstractAction;
import javax.swing.DefaultDesktopManager;
import javax.swing.DesktopManager;
import javax.swing.InputMap;
import javax.swing.JComponent;
import javax.swing.JDesktopPane;
import javax.swing.JInternalFrame;
import javax.swing.KeyStroke;
import javax.swing.LookAndFeel;
import javax.swing.SortingFocusTraversalPolicy;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
import javax.swing.plaf.ComponentUI;
import javax.swing.plaf.DesktopPaneUI;
import javax.swing.plaf.UIResource;

import sun.swing.DefaultLookup;
import sun.swing.UIAction;

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

PR Review: https://git.openjdk.org/jdk/pull/25893#pullrequestreview-3097887826
PR Review Comment: https://git.openjdk.org/jdk/pull/25893#discussion_r2260823380

From dnguyen at openjdk.org  Thu Aug  7 16:35:13 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 7 Aug 2025 16:35:13 GMT
Subject: RFR: 8364506: javax/swing/Popup/TaskbarPositionTest.java can fail
 subsequent tests on MacOS
In-Reply-To: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
References: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
Message-ID: <2QS7oeUvg7EIJ50ac4G3IhNpugp78FlnjS1uGG84sp4=.d74b1f29-2012-4a79-865a-72601fc66c7c@github.com>

On Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to show all windows related to the focused one.
> 
> Fix:
> Change the 'Cntrl' key to 'Shift'
> 
> Testing:
> Tested in all supported platforms using mach5 and got all PASS.

I agree. Keyboard shortcuts should be disabled to achieve consistent results across different devices for jtreg tests. There's a guideline and a list of setting changes here: https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements

I think changing the key-binding here is not necessary after changing this setting. I recently also had this failing test (and possibly failing subsequent tests) because my device had keyboard shortcuts enabled. But after removing the shortcuts, the test passed (and others).

I'd recommend disabling keyboard shortcuts and trying your tests again to see if it's still reproducible.

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

PR Review: https://git.openjdk.org/jdk/pull/26623#pullrequestreview-3097924439

From prr at openjdk.org  Thu Aug  7 16:51:14 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Aug 2025 16:51:14 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows
In-Reply-To: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
Message-ID: <PxFOMNvbPkou2cwqqYmDG1MIvggSc_tlMGNDx8qLv0k=.6918c38b-09dd-48e7-9647-d637bd93b065@github.com>

On Thu, 7 Aug 2025 08:14:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
> Add some logging to the test, and we could also increase the test timeout a bit.

test/jdk/java/awt/font/FontNames/LocaleFamilyNames.java line 29:

> 27:  * @summary Tests that all family names that are reported in all locales
> 28:  * correspond to some font returned from getAllFonts().
> 29:  * @run main/othervm/timeout=1200 LocaleFamilyNames

The default is 120 (IIRC) so you've multiplied it by 10.
I think 240 would be more reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26668#discussion_r2260883432

From azvegint at openjdk.org  Thu Aug  7 17:25:42 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 7 Aug 2025 17:25:42 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
Message-ID: <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>

On Thu, 7 Aug 2025 16:10:06 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update robot spec

test/jdk/java/awt/datatransfer/Independence/IndependenceSwingTest.java line 29:

> 27:  * @requires (os.family == "linux")
> 28:  * @summary To make sure that System & Primary clipboards should behave independently
> 29:  * @library /lib/client

Suggestion:



Many tests still use `@library /lib/client`.

Not only are they unnecessary in most cases, but they can also hide the use of `ExtendedRobot`.

For example, in this test, the use of `ExtendedRobot` has not been removed, and it is implicitly compiled due to the presence of `@library /lib/client`. After removing `@library`, the test no longer compiles.

error: cannot find symbol
    private static ExtendedRobot robot;


I suggest removing all unnecessary uses of `@library/lib/client` because there are still plenty of uses of `ExtendedRobot` in other tests as well.

This issue has been [raised](https://github.com/openjdk/jdk/pull/22044#discussion_r2140831788) before, but it has not yet been resolved for all tests.

---

Also, please run a grep search for `ExtendedRobot` in the `test/jdk` directory.  This pull request does not cover many tests that still use the `ExtendedRobot` (which doesn't even use the `dragAndDrop()` and can be safely removed).

test/jdk/lib/client/ExtendedRobot.java line 158:

> 156:      * @see     #dragAndDrop(int, int, int, int)
> 157:      */
> 158:     public void dragAndDrop(Point from, Point to){

I missed that earlier. Why didn't we also move the `dragAndDrop` methods to `java.awt.Robot`?
This would allow us to remove the ExtendedRobot class entirely.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2260904871
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2260964661

From prr at openjdk.org  Thu Aug  7 19:01:43 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Aug 2025 19:01:43 GMT
Subject: Integrated: 8364230: javax/swing/text/StringContent can be migrated
 away from using finalize
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <tmvbt21S2a6JZKANAx5IcZa2zbt1NioN_AEiZcwuPbA=.74e678c4-7511-46c5-9861-b02dbb75ece3@github.com>

On Mon, 28 Jul 2025 22:38:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

This pull request has now been integrated.

Changeset: 78117eff
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78117eff563e59a738c59efa7ef595b13f62b621
Stats:     92 lines in 2 files changed: 71 ins; 14 del; 7 mod

8364230: javax/swing/text/StringContent can be migrated away from using finalize

Reviewed-by: psadhukhan, abhiscxk, kizune

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

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

From achung at openjdk.org  Thu Aug  7 19:08:37 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 19:08:37 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
 <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
Message-ID: <WLYKwj4-qw7QjYw2u5s60CdfN7mKXf9kGeMMrEyemgY=.4f8527a7-ac77-4bef-a505-1abd44875ca2@github.com>

On Thu, 7 Aug 2025 16:55:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update robot spec
>
> test/jdk/java/awt/datatransfer/Independence/IndependenceSwingTest.java line 29:
> 
>> 27:  * @requires (os.family == "linux")
>> 28:  * @summary To make sure that System & Primary clipboards should behave independently
>> 29:  * @library /lib/client
> 
> Suggestion:
> 
> 
> 
> Many tests still use `@library /lib/client`.
> 
> Not only are they unnecessary in most cases, but they can also hide the use of `ExtendedRobot`.
> 
> For example, in this test, the use of `ExtendedRobot` has not been removed, and it is implicitly compiled due to the presence of `@library /lib/client`. After removing `@library`, the test no longer compiles.
> 
> error: cannot find symbol
>     private static ExtendedRobot robot;
> 
> 
> I suggest removing all unnecessary uses of `@library/lib/client` because there are still plenty of uses of `ExtendedRobot` in other tests as well.
> 
> This issue has been [raised](https://github.com/openjdk/jdk/pull/22044#discussion_r2140831788) before, but it has not yet been resolved for all tests.
> 
> ---
> 
> Also, please run a grep search for `ExtendedRobot` in the `test/jdk` directory.  This pull request does not cover many tests that still use the `ExtendedRobot` (which doesn't even use the `dragAndDrop()` and can be safely removed).

I planned on removing ExtendedRobot from these tests in a separate followup PR since there are many test changes in this one already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2261187869

From achung at openjdk.org  Thu Aug  7 19:11:39 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 19:11:39 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
 <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
Message-ID: <sFS4GLxCa2x-yOusZCLuceFjwwA4k76i7wJiORDN2Pk=.9556e4bd-83ee-4bd9-9341-d98b1de4b75b@github.com>

On Thu, 7 Aug 2025 17:22:49 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update robot spec
>
> test/jdk/lib/client/ExtendedRobot.java line 158:
> 
>> 156:      * @see     #dragAndDrop(int, int, int, int)
>> 157:      */
>> 158:     public void dragAndDrop(Point from, Point to){
> 
> I missed that earlier. Why didn't we also move the `dragAndDrop` methods to `java.awt.Robot`?
> This would allow us to remove the ExtendedRobot class entirely.

When I ran tests earlier to see which ExtendedRobot methods were used previously i found that dragAndDrop was never used by any tests, so I decided not to migrate it. It might be better to just remove it all outright and I might do that in a followup PR to remove ExtendedRobot entirely (along with moving the rest of the tests using ER)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2261193206

From azvegint at openjdk.org  Thu Aug  7 20:57:35 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 7 Aug 2025 20:57:35 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <sFS4GLxCa2x-yOusZCLuceFjwwA4k76i7wJiORDN2Pk=.9556e4bd-83ee-4bd9-9341-d98b1de4b75b@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
 <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
 <sFS4GLxCa2x-yOusZCLuceFjwwA4k76i7wJiORDN2Pk=.9556e4bd-83ee-4bd9-9341-d98b1de4b75b@github.com>
Message-ID: <vMxY_R4wOP-9AyH-H63uFzYvOsvyDmbuP6N5qFKPtTc=.ddb67444-ac80-471b-9484-f327a7f163da@github.com>

On Thu, 7 Aug 2025 19:08:32 GMT, Alisen Chung <achung at openjdk.org> wrote:

>  i found that dragAndDrop was never used by any tests

This doesn't seem to be true. I see several tests using it:


./java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java:73:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
./java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java:79:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
./java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java:75:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
./java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java:81:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
./java/awt/Window/ShapedAndTranslucentWindows/Translucent.java:72:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
./java/awt/Window/ShapedAndTranslucentWindows/Translucent.java:78:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
./java/awt/Window/ShapedAndTranslucentWindows/Shaped.java:75:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
./java/awt/Window/ShapedAndTranslucentWindows/Shaped.java:81:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
./java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java:174:        robot.dragAndDrop(MouseInfo.getPointerInfo().getLocation(), new Point(x+5, y));
./java/awt/event/MouseEvent/DragToLightweightTest.java:79:        robot.dragAndDrop(
./javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java:369:        robot.dragAndDrop(location.x + 30, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
./javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java:375:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
./javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java:387:        robot.dragAndDrop(location.x + 30, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
./javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java:393:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);


It seems to be a convenient method because it eliminates the need for all this hassle with a single call.



robot.mouseMove(fromX, fromY);
robot.mousePress(InputEvent.BUTTON1_DOWN_MASK);
robot.waitForIdle();
robot.glide(toX, toY);
robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);
robot.waitForIdle();


vs


robot.dragAndDrop(fromX, fromY, toX, toY)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2261377526

From avu at openjdk.org  Thu Aug  7 21:04:12 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 7 Aug 2025 21:04:12 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]
In-Reply-To: <FcB_GsxPVCO2lnk0xeh1RkTG_TDFflMAgYZahj0q6xY=.988b387b-4c41-4132-a11c-ebc0b164c275@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <UC70cDpCeGrWoCpK69CxGyuIolLueAkPV1gEYc5VSDI=.d7b51c6a-6d91-4a22-82b4-6a76c5fba6fa@github.com>
 <o60Goywr_tirm5QuH4iqeH6hpm8HsqQeRM2GFpIDbWE=.f7e61894-de0c-4596-a657-f01ebad04e29@github.com>
 <FcB_GsxPVCO2lnk0xeh1RkTG_TDFflMAgYZahj0q6xY=.988b387b-4c41-4132-a11c-ebc0b164c275@github.com>
Message-ID: <x0ugzu2qquuluIGdP-SDSyhCaM0qDOOEkj58iUYU1Kc=.0564c5bf-6b70-4fef-b599-3e9e2013ee64@github.com>

On Thu, 7 Aug 2025 11:57:38 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For wrapping, you can use the following one-liner 
>> `Optional.ofNullable(val).flatMap(e -> Optional.of(new WeakReference(val)));`
>
> I don't really understand how this could simplify the check.
> For wrapping, instead of `obj == null ? null : new WeakReference<>(obj)` it would become `Optional.ofNullable(obj).flatMap(e -> Optional.of(new WeakReference<>(obj)))`.
> And for comparing the state, it would need to repeat the same logic with special treatment of `null` refs, just replacing the null check with `isEmpty()` - is this what you meant?
> Overall, it seems easier to me to understand the null-check version, than the one wrapped into `Optional`.

Actually, state change is also oneliner, but if you think that it's too complex for understanding, let's keep the original version.
!mbRef.flatMap(e-> Optional.ofNullable(e.get())).equals(Optional.ofNullable(obj));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2261387813

From honkar at openjdk.org  Thu Aug  7 21:22:17 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 7 Aug 2025 21:22:17 GMT
Subject: Integrated: JDK-8361748 : Enforce limits on the size of an XBM image
In-Reply-To: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
Message-ID: <wlX7lYvWxlOzG4CGv0AxO6v52jkBkdEUUS_nR0QHWmg=.a7a133b0-ea06-45ba-a169-e9cf4e946e08@github.com>

On Fri, 25 Jul 2025 23:37:27 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> XBM (X Bitmap) images are small one-bit deep images that were developed as a simple uncompressed format that could easily be included in C source files as include files.
> 
> Format of XBM image:
> 
> 
>  #define width w
>  #define height h
>  static char foo_bits[] = {
>  0xnn,0xnn,0xnn,0xnn,0xnn, .......
>  0xnn,0xnn,0xnn,0xnn, .........
>  0xnn,0xnn,0xnn,0xnn};
> 
> 
> The first two #defines statements specify the width and height of the bitmap in pixels followed by hex byte array which represent pixel data itself.
> 
> The current implementation allows an arbitrarily large XBM which is not a valid use case for any XBM.
> Also it doesn't validate that the provided byte array is sufficient to populate the specified WxH. Since these are small one-bit mono images a reasonable size limit is set to `MAX_XBM_SIZE = 16384 bytes`. It can be set to a larger limit if someone thinks it is necessary.
> 
> The XBMDecoder's produceImage() has outdated logic, it has been restructured by adding more efficient parser logic and better error handling checks.

This pull request has now been integrated.

Changeset: c71be802
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c71be802b530034169d17325478dba6e2f1c3238
Stats:     245 lines in 7 files changed: 157 ins; 33 del; 55 mod

8361748: Enforce limits on the size of an XBM image

Reviewed-by: prr, jdv

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

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

From honkar at openjdk.org  Thu Aug  7 21:30:18 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 7 Aug 2025 21:30:18 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image [v2]
In-Reply-To: <lRC7M6d7Dw9SiG_CfzVZQxtOEQVpKxsMLYbyqeNX-fI=.634afeac-0967-4666-8e6f-502dd4034b72@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
 <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
 <lRC7M6d7Dw9SiG_CfzVZQxtOEQVpKxsMLYbyqeNX-fI=.634afeac-0967-4666-8e6f-502dd4034b72@github.com>
Message-ID: <GU_wHAVVo5ggeeKgScR5dhTM7sxaNCmStorc-K1Tn5c=.31d5b2fe-50ab-4934-bfe5-e2bb0fe8153b@github.com>

On Mon, 4 Aug 2025 07:29:05 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - rename
>>  - test summary
>
> test/jdk/java/awt/image/XBMDecoder/XBMDecoderTest.java line 55:
> 
>> 53:             System.out.println("--- Testing " + fileName + " ---");
>> 54:             try (FileInputStream fis = new FileInputStream(file);
>> 55:                  ByteArrayOutputStream errContent = new ByteArrayOutputStream()) {
> 
> Indentation issue.

ByteArrayOutputStream stmt part of try-with-resources block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26488#discussion_r2261433937

From achung at openjdk.org  Thu Aug  7 21:58:07 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 21:58:07 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v31]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <lLharY5uHYeq75pi0f21uZXhb5poqzZo-so3EMQy73Y=.ea3f33e9-a42a-408d-859b-cb7dee582275@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  remove /client/lib from tests with ER removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/26f5a626..1beaafb3

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

  Stats: 42 lines in 42 files changed: 0 ins; 30 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044

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

From achung at openjdk.org  Thu Aug  7 23:04:21 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 23:04:21 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v32]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <tsw0XMLtFnUl7WZ2JfMqIUlJDRW68janOGeUJLylvj4=.2ee2c792-ba1d-408f-a139-f40652413e91@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  migrate dragAndDrop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/1beaafb3..9b547ca1

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

  Stats: 70 lines in 2 files changed: 29 ins; 41 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044

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

From achung at openjdk.org  Thu Aug  7 23:04:22 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 23:04:22 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <WLYKwj4-qw7QjYw2u5s60CdfN7mKXf9kGeMMrEyemgY=.4f8527a7-ac77-4bef-a505-1abd44875ca2@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
 <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
 <WLYKwj4-qw7QjYw2u5s60CdfN7mKXf9kGeMMrEyemgY=.4f8527a7-ac77-4bef-a505-1abd44875ca2@github.com>
Message-ID: <IYH2OSfkYb5Xvr3q-JefGeLPav19pelS1Gx4ABl4u5M=.a80f25ff-e784-4024-bac2-c91f8e7b8b18@github.com>

On Thu, 7 Aug 2025 19:05:27 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/java/awt/datatransfer/Independence/IndependenceSwingTest.java line 29:
>> 
>>> 27:  * @requires (os.family == "linux")
>>> 28:  * @summary To make sure that System & Primary clipboards should behave independently
>>> 29:  * @library /lib/client
>> 
>> Suggestion:
>> 
>> 
>> 
>> Many tests still use `@library /lib/client`.
>> 
>> Not only are they unnecessary in most cases, but they can also hide the use of `ExtendedRobot`.
>> 
>> For example, in this test, the use of `ExtendedRobot` has not been removed, and it is implicitly compiled due to the presence of `@library /lib/client`. After removing `@library`, the test no longer compiles.
>> 
>> error: cannot find symbol
>>     private static ExtendedRobot robot;
>> 
>> 
>> I suggest removing all unnecessary uses of `@library/lib/client` because there are still plenty of uses of `ExtendedRobot` in other tests as well.
>> 
>> This issue has been [raised](https://github.com/openjdk/jdk/pull/22044#discussion_r2140831788) before, but it has not yet been resolved for all tests.
>> 
>> ---
>> 
>> Also, please run a grep search for `ExtendedRobot` in the `test/jdk` directory.  This pull request does not cover many tests that still use the `ExtendedRobot` (which doesn't even use the `dragAndDrop()` and can be safely removed).
>
> I planned on removing ExtendedRobot from these tests in a separate followup PR since there are many test changes in this one already.

I've updated the current tests in to remove /client/lib from the tests I already removed ER from and I'll remove the remaining tests when I remove ER in a followup PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2261607062

From achung at openjdk.org  Thu Aug  7 23:04:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 7 Aug 2025 23:04:23 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <vMxY_R4wOP-9AyH-H63uFzYvOsvyDmbuP6N5qFKPtTc=.ddb67444-ac80-471b-9484-f327a7f163da@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
 <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
 <sFS4GLxCa2x-yOusZCLuceFjwwA4k76i7wJiORDN2Pk=.9556e4bd-83ee-4bd9-9341-d98b1de4b75b@github.com>
 <vMxY_R4wOP-9AyH-H63uFzYvOsvyDmbuP6N5qFKPtTc=.ddb67444-ac80-471b-9484-f327a7f163da@github.com>
Message-ID: <PBb6O3mpxLRxajICGx_mLbicl2JKq8kTNFccQsTIz3k=.b054ed3f-2592-4f65-98e1-85da5a4b3416@github.com>

On Thu, 7 Aug 2025 20:54:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> When I ran tests earlier to see which ExtendedRobot methods were used previously i found that dragAndDrop was never used by any tests, so I decided not to migrate it. It might be better to just remove it all outright and I might do that in a followup PR to remove ExtendedRobot entirely (along with moving the rest of the tests using ER)
>
>>  i found that dragAndDrop was never used by any tests
> 
> This doesn't seem to be true. I see several tests using it:
> 
> 
> ./java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java:73:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
> ./java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java:79:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
> ./java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java:75:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
> ./java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java:81:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
> ./java/awt/Window/ShapedAndTranslucentWindows/Translucent.java:72:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
> ./java/awt/Window/ShapedAndTranslucentWindows/Translucent.java:78:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
> ./java/awt/Window/ShapedAndTranslucentWindows/Shaped.java:75:        robot.dragAndDrop(location.x + dl, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
> ./java/awt/Window/ShapedAndTranslucentWindows/Shaped.java:81:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
> ./java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java:174:        robot.dragAndDrop(MouseInfo.getPointerInfo().getLocation(), new Point(x+5, y));
> ./java/awt/event/MouseEvent/DragToLightweightTest.java:79:        robot.dragAndDrop(
> ./javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java:369:        robot.dragAndDrop(location.x + 30, location.y + 5, location.x + dl + random.nextInt(dl), location.y + random.nextInt(dl));
> ./javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java:375:        robot.dragAndDrop(location.x + 4, location.y + 4, location.x + random.nextInt(2*dl)-dl, location.y + random.nextInt(2*dl)-dl);
> ./javax/swing/JWindow/ShapedAndTranslucentWindows/Common.java:387:        robot.dragAndDrop(location.x + 30, location.y + ...

I've migrated dragAndDrop(int, int, int, int) and updated the csr to include the migration. Can you take a look at the specification to see if it meets the standard?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2261604905

From abaya at openjdk.org  Fri Aug  8 00:30:25 2025
From: abaya at openjdk.org (Anass Baya)
Date: Fri, 8 Aug 2025 00:30:25 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux [v4]
In-Reply-To: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
Message-ID: <vcgKUlxIwewW3mEAPG_dMu4YNMOkWqWKgekQDBGHuNE=.475ff567-096e-4f4d-bd02-1eaa762b192f@github.com>

> **Analysis:**
> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> **Proposed Fix:**
> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once

Anass Baya has updated the pull request incrementally with three additional commits since the last revision:

 - Respect rules
 - remove space
 - Update focusability only when it is needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26298/files
  - new: https://git.openjdk.org/jdk/pull/26298/files/f33a7229..489f0734

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

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

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

From abaya at openjdk.org  Fri Aug  8 00:30:26 2025
From: abaya at openjdk.org (Anass Baya)
Date: Fri, 8 Aug 2025 00:30:26 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux [v3]
In-Reply-To: <ZTbsjNekjUeeEErX1m2nsUN_9aqVvHvc97ofLGVqn8w=.abe34dd2-fea6-4c62-8cc7-8d90c4d3efe5@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
 <ZTbsjNekjUeeEErX1m2nsUN_9aqVvHvc97ofLGVqn8w=.abe34dd2-fea6-4c62-8cc7-8d90c4d3efe5@github.com>
Message-ID: <ZdMMMGrSBK9kHF0UvD9_WkqoBGxxBnVtD5ca053yjfs=.f3e42aa4-9686-419b-ac52-12f039fd8ec9@github.com>

On Thu, 31 Jul 2025 14:21:33 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> **Analysis:**
>> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
>> 
>> **Proposed Fix:**
>> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
>> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once
>
> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not update Focusability when it is not needed

Converted to draft for more investigation. the proposed fix my cause issue when resizing

To avoid any issues when resizing the window, we only update focusability when it's necessary, not for every setVisible call

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

PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3141351267
PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3166209476

From aturbanov at openjdk.org  Fri Aug  8 05:07:19 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 8 Aug 2025 05:07:19 GMT
Subject: Integrated: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
Message-ID: <Yj48JTtgLU65iOYoHj-L1QP8Emon_H4tYgQ12evj9EM=.39097a03-4b71-4119-8f7e-ccfad1e826c3@github.com>

On Thu, 19 Jun 2025 08:25:53 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Looks like no reasons for it to be instance field

This pull request has now been integrated.

Changeset: d0624f8b
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0624f8b62fe0c70e5b6a47e05235ca65a2e1a13
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8364808: Make BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static

Reviewed-by: tr, azvegint, kizune, aivanov

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

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

From aturbanov at openjdk.org  Fri Aug  8 07:26:16 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 8 Aug 2025 07:26:16 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <fpLdFPMwOPIx5aJABszjmCLL7PyhuX6RrNC366T3y9Q=.e85cacf9-728f-4d65-b653-c104b8687b22@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
 <fpLdFPMwOPIx5aJABszjmCLL7PyhuX6RrNC366T3y9Q=.e85cacf9-728f-4d65-b653-c104b8687b22@github.com>
Message-ID: <-dU3BxJRdjZthb_MPmjMbRpOg5RWjYAQQtYbB13biic=.2747790b-ebf5-4f3b-acfe-78a56ed47c21@github.com>

On Thu, 7 Aug 2025 16:21:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks like no reasons for it to be instance field
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java line 33:
> 
>> 31: import java.beans.*;
>> 32: 
>> 33: import java.awt.event.ActionEvent;
> 
> I suggest expanding all the wildcard imports:
> 
> 
> import java.awt.Component;
> import java.awt.Container;
> import java.awt.Dimension;
> import java.awt.FocusTraversalPolicy;
> import java.awt.Graphics;
> import java.awt.Insets;
> import java.awt.KeyboardFocusManager;
> import java.awt.Point;
> import java.awt.event.ActionEvent;
> import java.beans.PropertyChangeEvent;
> import java.beans.PropertyChangeListener;
> import java.beans.PropertyVetoException;
> 
> import javax.swing.AbstractAction;
> import javax.swing.DefaultDesktopManager;
> import javax.swing.DesktopManager;
> import javax.swing.InputMap;
> import javax.swing.JComponent;
> import javax.swing.JDesktopPane;
> import javax.swing.JInternalFrame;
> import javax.swing.KeyStroke;
> import javax.swing.LookAndFeel;
> import javax.swing.SortingFocusTraversalPolicy;
> import javax.swing.SwingUtilities;
> import javax.swing.UIManager;
> import javax.swing.plaf.ComponentUI;
> import javax.swing.plaf.DesktopPaneUI;
> import javax.swing.plaf.UIResource;
> 
> import sun.swing.DefaultLookup;
> import sun.swing.UIAction;

Sorry, missed the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25893#discussion_r2262151251

From mbaesken at openjdk.org  Fri Aug  8 08:10:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Aug 2025 08:10:11 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows [v2]
In-Reply-To: <PxFOMNvbPkou2cwqqYmDG1MIvggSc_tlMGNDx8qLv0k=.6918c38b-09dd-48e7-9647-d637bd93b065@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
 <PxFOMNvbPkou2cwqqYmDG1MIvggSc_tlMGNDx8qLv0k=.6918c38b-09dd-48e7-9647-d637bd93b065@github.com>
Message-ID: <BNEKQX3viKLJmu8pqHoGThZPs1xuvUr4BjPTUVOG78s=.18fc1565-f4fa-407e-8462-74ab7ec8bffa@github.com>

On Thu, 7 Aug 2025 16:48:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce timeout value
>
> test/jdk/java/awt/font/FontNames/LocaleFamilyNames.java line 29:
> 
>> 27:  * @summary Tests that all family names that are reported in all locales
>> 28:  * correspond to some font returned from getAllFonts().
>> 29:  * @run main/othervm/timeout=1200 LocaleFamilyNames
> 
> The default is 120 (IIRC) so you've multiplied it by 10.
> I think 240 would be more reasonable.

I borrowed the 1200 from some other test, but you are most likely correct it is a bit extreme .
I reduced the value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26668#discussion_r2262233659

From mbaesken at openjdk.org  Fri Aug  8 08:10:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 8 Aug 2025 08:10:09 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows [v2]
In-Reply-To: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
Message-ID: <f8OdyXT7Hs848J6T-GpJLW0QKVR8dcJ5yU_1p-eOoxI=.523fb1e1-5acd-4ff6-a878-738c4464edca@github.com>

> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
> Add some logging to the test, and we could also increase the test timeout a bit.

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

  reduce timeout value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26668/files
  - new: https://git.openjdk.org/jdk/pull/26668/files/57203637..3d363ada

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

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

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

From jdv at openjdk.org  Fri Aug  8 10:06:18 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 8 Aug 2025 10:06:18 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image [v2]
In-Reply-To: <GU_wHAVVo5ggeeKgScR5dhTM7sxaNCmStorc-K1Tn5c=.31d5b2fe-50ab-4934-bfe5-e2bb0fe8153b@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
 <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
 <lRC7M6d7Dw9SiG_CfzVZQxtOEQVpKxsMLYbyqeNX-fI=.634afeac-0967-4666-8e6f-502dd4034b72@github.com>
 <GU_wHAVVo5ggeeKgScR5dhTM7sxaNCmStorc-K1Tn5c=.31d5b2fe-50ab-4934-bfe5-e2bb0fe8153b@github.com>
Message-ID: <vYrNeVR9N0IDwrw-CeDCQA5hRuEDTA7337WRIa2Felg=.ee940874-4c26-458c-bf1f-490c4925300b@github.com>

On Thu, 7 Aug 2025 21:27:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/image/XBMDecoder/XBMDecoderTest.java line 55:
>> 
>>> 53:             System.out.println("--- Testing " + fileName + " ---");
>>> 54:             try (FileInputStream fis = new FileInputStream(file);
>>> 55:                  ByteArrayOutputStream errContent = new ByteArrayOutputStream()) {
>> 
>> Indentation issue.
>
> ByteArrayOutputStream stmt part of try-with-resources block.

I understand, but line no 55 has extra space instead of usual 4 space indentation which is followed in next line.
Also its a good practice to wait for a day after replying to comments before integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26488#discussion_r2262526164

From jdv at openjdk.org  Fri Aug  8 10:11:19 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 8 Aug 2025 10:11:19 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image [v2]
In-Reply-To: <vYrNeVR9N0IDwrw-CeDCQA5hRuEDTA7337WRIa2Felg=.ee940874-4c26-458c-bf1f-490c4925300b@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
 <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
 <lRC7M6d7Dw9SiG_CfzVZQxtOEQVpKxsMLYbyqeNX-fI=.634afeac-0967-4666-8e6f-502dd4034b72@github.com>
 <GU_wHAVVo5ggeeKgScR5dhTM7sxaNCmStorc-K1Tn5c=.31d5b2fe-50ab-4934-bfe5-e2bb0fe8153b@github.com>
 <vYrNeVR9N0IDwrw-CeDCQA5hRuEDTA7337WRIa2Felg=.ee940874-4c26-458c-bf1f-490c4925300b@github.com>
Message-ID: <b9hkcgFy6Kt9vRmDPzU3bYNKExu3eQck2hyGp1soWVQ=.e1bb1b13-14de-466d-8a52-0e5fb62e2e52@github.com>

On Fri, 8 Aug 2025 10:03:18 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> ByteArrayOutputStream stmt part of try-with-resources block.
>
> I understand, but line no 55 has extra space instead of usual 4 space indentation which is followed in next line.
> Also its a good practice to wait for a day after replying to comments before integration.

I see your point! Change is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26488#discussion_r2262533579

From clanger at openjdk.org  Fri Aug  8 13:21:10 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 8 Aug 2025 13:21:10 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows [v2]
In-Reply-To: <f8OdyXT7Hs848J6T-GpJLW0QKVR8dcJ5yU_1p-eOoxI=.523fb1e1-5acd-4ff6-a878-738c4464edca@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
 <f8OdyXT7Hs848J6T-GpJLW0QKVR8dcJ5yU_1p-eOoxI=.523fb1e1-5acd-4ff6-a878-738c4464edca@github.com>
Message-ID: <GlLZspZzl9x8FB0STKYsPXMiNEf-_PK7beqI2ImMjqc=.a4d4e23d-0b9a-4f79-8080-ca40af944738@github.com>

On Fri, 8 Aug 2025 08:10:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
>> Add some logging to the test, and we could also increase the test timeout a bit.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce timeout value

Thanks for the explanation and adjusting the timeout.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26668#pullrequestreview-3100805891

From avu at openjdk.org  Fri Aug  8 14:22:15 2025
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 8 Aug 2025 14:22:15 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]
In-Reply-To: <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
Message-ID: <kaDfxDq_Pq3mNWoUem8PPFDVHw_2N44_u2oDtR0V8do=.797888d7-57c3-4d59-a1f3-eb82c49d81dc@github.com>

On Thu, 7 Aug 2025 12:06:02 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Old copyright year left from the test I copied

Marked as reviewed by avu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26576#pullrequestreview-3101040335

From azvegint at openjdk.org  Fri Aug  8 15:25:45 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 8 Aug 2025 15:25:45 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v32]
In-Reply-To: <tsw0XMLtFnUl7WZ2JfMqIUlJDRW68janOGeUJLylvj4=.2ee2c792-ba1d-408f-a139-f40652413e91@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <tsw0XMLtFnUl7WZ2JfMqIUlJDRW68janOGeUJLylvj4=.2ee2c792-ba1d-408f-a139-f40652413e91@github.com>
Message-ID: <nSK5I5VdpVEL5zHUyixFEpKzWsiVVelumNKs4mDWUDE=.668f87fc-c1ae-43f9-88d6-0d6ef48d132d@github.com>

On Thu, 7 Aug 2025 23:04:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   migrate dragAndDrop

src/java.desktop/share/classes/java/awt/Robot.java line 957:

> 955:      * @implSpec The method moves the mouse pointer to source point ({@code fromX}, {@code fromY}),
> 956:      * presses mouse button 1, calls glide to drag pointer to
> 957:      * destination point ({@code toX}, {@code toY}), then releases mouse button 1.

It can probably be omitted because it's essentially the same information that's already stated in the previous sentence and the `@param` tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2263229134

From azvegint at openjdk.org  Fri Aug  8 15:25:45 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 8 Aug 2025 15:25:45 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v30]
In-Reply-To: <IYH2OSfkYb5Xvr3q-JefGeLPav19pelS1Gx4ABl4u5M=.a80f25ff-e784-4024-bac2-c91f8e7b8b18@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <x-gIt-q1ZAVF-oKSSRV11q8KfB6neDgcrS8aQlUw3i8=.e3ea95ba-1a2a-4b69-a59c-083b23a5eeda@github.com>
 <ejZopdyNe5866-GPxUdIulk0b3kJ4pXweplVZVP0OMg=.b395faa3-ec71-4a8a-82da-0c8f3fcb81b7@github.com>
 <WLYKwj4-qw7QjYw2u5s60CdfN7mKXf9kGeMMrEyemgY=.4f8527a7-ac77-4bef-a505-1abd44875ca2@github.com>
 <IYH2OSfkYb5Xvr3q-JefGeLPav19pelS1Gx4ABl4u5M=.a80f25ff-e784-4024-bac2-c91f8e7b8b18@github.com>
Message-ID: <owECeBHuCdMWixnfxiJ7nZ2ZIQDgYfhI5jteay1bRK8=.e280030b-23f8-416c-8e41-abca58cb18d6@github.com>

On Thu, 7 Aug 2025 22:58:06 GMT, Alisen Chung <achung at openjdk.org> wrote:

> I've updated the current tests in to remove /client/lib from the tests I already removed ER from

However, it seems that some of the touch tests are still using the ER, which will result in a compilation failure when run with CI.
For instance, the `IndependenceSwingTest.java` test still fails to compile and run. There are more examples.

> I'll remove the remaining tests when I remove ER in a followup PR

Sure, thank you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2263269079

From ngubarkov at openjdk.org  Fri Aug  8 16:18:11 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Fri, 8 Aug 2025 16:18:11 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]
In-Reply-To: <x0ugzu2qquuluIGdP-SDSyhCaM0qDOOEkj58iUYU1Kc=.0564c5bf-6b70-4fef-b599-3e9e2013ee64@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <UC70cDpCeGrWoCpK69CxGyuIolLueAkPV1gEYc5VSDI=.d7b51c6a-6d91-4a22-82b4-6a76c5fba6fa@github.com>
 <o60Goywr_tirm5QuH4iqeH6hpm8HsqQeRM2GFpIDbWE=.f7e61894-de0c-4596-a657-f01ebad04e29@github.com>
 <FcB_GsxPVCO2lnk0xeh1RkTG_TDFflMAgYZahj0q6xY=.988b387b-4c41-4132-a11c-ebc0b164c275@github.com>
 <x0ugzu2qquuluIGdP-SDSyhCaM0qDOOEkj58iUYU1Kc=.0564c5bf-6b70-4fef-b599-3e9e2013ee64@github.com>
Message-ID: <Qe4yL_Dto757j7g1xOinDDM7rDi1VuWsBkFhZtdScOc=.ed413b36-f47f-4296-b49f-94d2f7a24356@github.com>

On Thu, 7 Aug 2025 21:01:46 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> I don't really understand how this could simplify the check.
>> For wrapping, instead of `obj == null ? null : new WeakReference<>(obj)` it would become `Optional.ofNullable(obj).flatMap(e -> Optional.of(new WeakReference<>(obj)))`.
>> And for comparing the state, it would need to repeat the same logic with special treatment of `null` refs, just replacing the null check with `isEmpty()` - is this what you meant?
>> Overall, it seems easier to me to understand the null-check version, than the one wrapped into `Optional`.
>
> Actually, state change is also oneliner, but if you think that it's too complex for understanding, let's keep the original version.
> !mbRef.flatMap(e-> Optional.ofNullable(e.get())).equals(Optional.ofNullable(obj));

Actually, that version wouldn't work, as it doesn't distinguish between null ref itself and null ref value. So yes, let's better keep the null checks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2263422407

From dgredler at openjdk.org  Fri Aug  8 16:44:26 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 8 Aug 2025 16:44:26 GMT
Subject: RFR: 8359955: Regressions ~7% in several J2DBench in 25-b26
Message-ID: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>

Addresses recent slight performance regressions in some J2DBench benchmarks focused on text drawing.

`CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after JDK-8353230 they weren't caching glyph IDs for chars which might be affected by the raw / non-raw glyph distinction, since the cached value may not be correct if we ask for a raw glyph ID one time, but a non-raw glyph ID the next time (or vice versa). This caching exception was the reason for the slightly degraded performance (the `CCharToGlyphMapper` behavior was affecting macOS, and the `CompositeGlyphMapper` behavior was affecting some versions of Windows). This change splits the cache in each of these two classes into two caches, one for raw glyph IDs and one for non-raw glyph IDs, so that all glyphs can benefit from caching.

All of the font tests (`make test TEST="jtreg:test/jdk/java/awt/font"`) pass for me locally with this change on Linux, macOS and Windows.

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

Commit messages:
 - Improve caching in CompositeGlyphMapper
 - Improve caching in macOS CCharToGlyphMapper

Changes: https://git.openjdk.org/jdk/pull/26702/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26702&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359955
  Stats: 70 lines in 2 files changed: 25 ins; 19 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26702/head:pull/26702

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

From prr at openjdk.org  Fri Aug  8 17:40:11 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Aug 2025 17:40:11 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows [v2]
In-Reply-To: <f8OdyXT7Hs848J6T-GpJLW0QKVR8dcJ5yU_1p-eOoxI=.523fb1e1-5acd-4ff6-a878-738c4464edca@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
 <f8OdyXT7Hs848J6T-GpJLW0QKVR8dcJ5yU_1p-eOoxI=.523fb1e1-5acd-4ff6-a878-738c4464edca@github.com>
Message-ID: <cNFMWTCQE1aM5cXzfhmdTM2syiSd20tgdjDb_YrvQU8=.e4905d3d-9b88-41f7-9b9a-686d64db4dab@github.com>

On Fri, 8 Aug 2025 08:10:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
>> Add some logging to the test, and we could also increase the test timeout a bit.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce timeout value

360 (6 minutes) still seems a little generous. But it is better than 20 minutes.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26668#pullrequestreview-3101706473

From prr at openjdk.org  Fri Aug  8 17:40:49 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Aug 2025 17:40:49 GMT
Subject: RFR: 8364768: JDK javax.imageio ImageWriters do not all flush the
 output stream
Message-ID: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>

4 of the 6 JDK ImageWriters flush the stream at the end of writing. 2 (TIFF and GIF) do not. 

This will matter if you are using a caching ImageOutputStream.

This fix makes it consistent.

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

Commit messages:
 - 8364768

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

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

From aivanov at openjdk.org  Fri Aug  8 18:33:27 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Aug 2025 18:33:27 GMT
Subject: RFR: 8364808: Make
 BasicDesktopPaneUI.Actions.MOVE_RESIZE_INCREMENT static
In-Reply-To: <-dU3BxJRdjZthb_MPmjMbRpOg5RWjYAQQtYbB13biic=.2747790b-ebf5-4f3b-acfe-78a56ed47c21@github.com>
References: <wB__4hQhqdn8O6iSEdncc06nzMBT99TOaTqYTMnYBWU=.b159ef49-4021-432a-9e73-1a1196cdef43@github.com>
 <fpLdFPMwOPIx5aJABszjmCLL7PyhuX6RrNC366T3y9Q=.e85cacf9-728f-4d65-b653-c104b8687b22@github.com>
 <-dU3BxJRdjZthb_MPmjMbRpOg5RWjYAQQtYbB13biic=.2747790b-ebf5-4f3b-acfe-78a56ed47c21@github.com>
Message-ID: <UhsOVXzlYWDC8PbAmNaAsDmGVtS20IS46dL9vGOZScI=.f742c2c8-f114-4752-873b-06b7f828a317@github.com>

On Fri, 8 Aug 2025 07:23:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java line 33:
>> 
>>> 31: import java.beans.*;
>>> 32: 
>>> 33: import java.awt.event.ActionEvent;
>> 
>> I suggest expanding all the wildcard imports:
>> 
>> 
>> import java.awt.Component;
>> import java.awt.Container;
>> import java.awt.Dimension;
>> import java.awt.FocusTraversalPolicy;
>> import java.awt.Graphics;
>> import java.awt.Insets;
>> import java.awt.KeyboardFocusManager;
>> import java.awt.Point;
>> import java.awt.event.ActionEvent;
>> import java.beans.PropertyChangeEvent;
>> import java.beans.PropertyChangeListener;
>> import java.beans.PropertyVetoException;
>> 
>> import javax.swing.AbstractAction;
>> import javax.swing.DefaultDesktopManager;
>> import javax.swing.DesktopManager;
>> import javax.swing.InputMap;
>> import javax.swing.JComponent;
>> import javax.swing.JDesktopPane;
>> import javax.swing.JInternalFrame;
>> import javax.swing.KeyStroke;
>> import javax.swing.LookAndFeel;
>> import javax.swing.SortingFocusTraversalPolicy;
>> import javax.swing.SwingUtilities;
>> import javax.swing.UIManager;
>> import javax.swing.plaf.ComponentUI;
>> import javax.swing.plaf.DesktopPaneUI;
>> import javax.swing.plaf.UIResource;
>> 
>> import sun.swing.DefaultLookup;
>> import sun.swing.UIAction;
>
> Sorry, missed the comment.

It's not worth applying without any other changes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25893#discussion_r2263748036

From aivanov at openjdk.org  Fri Aug  8 19:28:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Aug 2025 19:28:12 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <lkCjm0aOhdTsHXfo6dDVrTnOtws8o_B_vvnY9CsqfnQ=.71a7fdb4-1e4f-494c-bc5b-78b1aa9914ee@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
 <lkCjm0aOhdTsHXfo6dDVrTnOtws8o_B_vvnY9CsqfnQ=.71a7fdb4-1e4f-494c-bc5b-78b1aa9914ee@github.com>
Message-ID: <nhVwkMOfIZ1j-XzfrWDgZDQyZTm5ffeOUyE6hff7x74=.6358c3f6-b60d-4eed-a57b-6e5294bb723c@github.com>

On Wed, 6 Aug 2025 14:43:55 GMT, Christian Heilmann <duke at openjdk.org> wrote:

> Were you able to follow my explanations? Is there anything else I can do, to get the pull request through the review?

Sorry, I've been unable to thoroughly look at it. I'll get to this code review next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3169076433

From bchristi at openjdk.org  Fri Aug  8 19:35:09 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 8 Aug 2025 19:35:09 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
Message-ID: <C4CTq2OIiHZ45ok9f8t2SdYKjjvOo6yIBtzUP2bCX7E=.49bb9c2c-4f5f-4db9-9f98-f5962ce06a59@github.com>

On Wed, 6 Aug 2025 22:34:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
>> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
>> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
>> really meant to clean up internal resources.
>> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
>> 
>> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
>> The risks of this will be covered in the CSR.
>> 
>> There's also a lengthy write up in the JBS issue.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277585

Can `MemoryCacheImageOutputStream` be included in this PR?

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

Changes requested by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26650#pullrequestreview-3101966822

From prr at openjdk.org  Fri Aug  8 19:42:10 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Aug 2025 19:42:10 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <C4CTq2OIiHZ45ok9f8t2SdYKjjvOo6yIBtzUP2bCX7E=.49bb9c2c-4f5f-4db9-9f98-f5962ce06a59@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
 <C4CTq2OIiHZ45ok9f8t2SdYKjjvOo6yIBtzUP2bCX7E=.49bb9c2c-4f5f-4db9-9f98-f5962ce06a59@github.com>
Message-ID: <o8ZiOolHtrrA9COABMXJEfgy6C8H7lpFWxQ16ud2K3Y=.e333b970-c84e-462e-8be5-7d2158bec6ff@github.com>

On Fri, 8 Aug 2025 19:32:34 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Can `MemoryCacheImageOutputStream` be included in this PR?

Why ? It has nothing to dispose.

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

PR Comment: https://git.openjdk.org/jdk/pull/26650#issuecomment-3169104939

From bchristi at openjdk.org  Fri Aug  8 19:51:10 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 8 Aug 2025 19:51:10 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <o8ZiOolHtrrA9COABMXJEfgy6C8H7lpFWxQ16ud2K3Y=.e333b970-c84e-462e-8be5-7d2158bec6ff@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
 <C4CTq2OIiHZ45ok9f8t2SdYKjjvOo6yIBtzUP2bCX7E=.49bb9c2c-4f5f-4db9-9f98-f5962ce06a59@github.com>
 <o8ZiOolHtrrA9COABMXJEfgy6C8H7lpFWxQ16ud2K3Y=.e333b970-c84e-462e-8be5-7d2158bec6ff@github.com>
Message-ID: <ZGAL9oWGj3t1ybkr-voMr4aWb2UDIUzqZwaMBNhWemY=.1d65cf20-23fe-4631-8e89-978ea422eebe@github.com>

On Fri, 8 Aug 2025 19:39:52 GMT, Phil Race <prr at openjdk.org> wrote:

> > Can `MemoryCacheImageOutputStream` be included in this PR?
> 
> Why ? It has nothing to dispose.

Doesn't it have a `cache`, similar to `MemoryCacheImageInputStream` ?

`public class MemoryCacheImageOutputStream extends ImageOutputStreamImpl {`
`    ....`
`    private MemoryCache cache = new MemoryCache();`

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

PR Comment: https://git.openjdk.org/jdk/pull/26650#issuecomment-3169122275

From prr at openjdk.org  Fri Aug  8 20:06:11 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Aug 2025 20:06:11 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <ZGAL9oWGj3t1ybkr-voMr4aWb2UDIUzqZwaMBNhWemY=.1d65cf20-23fe-4631-8e89-978ea422eebe@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
 <C4CTq2OIiHZ45ok9f8t2SdYKjjvOo6yIBtzUP2bCX7E=.49bb9c2c-4f5f-4db9-9f98-f5962ce06a59@github.com>
 <o8ZiOolHtrrA9COABMXJEfgy6C8H7lpFWxQ16ud2K3Y=.e333b970-c84e-462e-8be5-7d2158bec6ff@github.com>
 <ZGAL9oWGj3t1ybkr-voMr4aWb2UDIUzqZwaMBNhWemY=.1d65cf20-23fe-4631-8e89-978ea422eebe@github.com>
Message-ID: <EeCrl0CkhroTogcogY8gJU1hRcwP0lhq62xpjxvXNvA=.5d879886-9d21-41e4-b14f-73c51f3ae353@github.com>

On Fri, 8 Aug 2025 19:48:31 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> > > Can `MemoryCacheImageOutputStream` be included in this PR?
> > 
> > 
> > Why ? It has nothing to dispose.
> 
> Doesn't it have a `cache`, similar to `MemoryCacheImageInputStream ` ?
> 
> `public class MemoryCacheImageOutputStream extends ImageOutputStreamImpl {` ` ....` ` private MemoryCache cache = new MemoryCache();`

That just wraps an ArrayList<byte[]> 
I was planning on later removing the disposer from the MemoryCacheImageInputStream

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

PR Comment: https://git.openjdk.org/jdk/pull/26650#issuecomment-3169153045

From prr at openjdk.org  Fri Aug  8 21:29:10 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Aug 2025 21:29:10 GMT
Subject: RFR: 8359955: Regressions ~7% in several J2DBench in 25-b26
In-Reply-To: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
References: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
Message-ID: <SjfWK4lEmurI1MuZonAB--HIMQJql89Ke__lrRQaKYM=.4c74b9e4-9685-43a5-ae88-7446de8b69bf@github.com>

On Fri, 8 Aug 2025 16:37:36 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Addresses recent slight performance regressions in some J2DBench benchmarks focused on text drawing.
> 
> `CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after JDK-8353230 they weren't caching glyph IDs for chars which might be affected by the raw / non-raw glyph distinction, since the cached value may not be correct if we ask for a raw glyph ID one time, but a non-raw glyph ID the next time (or vice versa). This caching exception was the reason for the slightly degraded performance (the `CCharToGlyphMapper` behavior was affecting macOS, and the `CompositeGlyphMapper` behavior was affecting some versions of Windows). This change splits the cache in each of these two classes into two caches, one for raw glyph IDs and one for non-raw glyph IDs, so that all glyphs can benefit from caching.
> 
> All of the font tests (`make test TEST="jtreg:test/jdk/java/awt/font"`) pass for me locally with this change on Linux, macOS and Windows.

LGTM. I ran all our automated jtreg tests on all platforms, plus JCK.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26702#pullrequestreview-3102179909

From achung at openjdk.org  Fri Aug  8 21:38:10 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 8 Aug 2025 21:38:10 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
Message-ID: <LE4I6oemG1t-6bECHodsdJi2Wo-1PiwK2-niD59qXUs=.60dca5a9-0610-4ec6-9cc5-61c5d25b6fed@github.com>

On Wed, 6 Aug 2025 22:34:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
>> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
>> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
>> really meant to clean up internal resources.
>> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
>> 
>> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
>> The risks of this will be covered in the CSR.
>> 
>> There's also a lengthy write up in the JBS issue.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277585

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26650#pullrequestreview-3102191873

From prr at openjdk.org  Fri Aug  8 21:48:33 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Aug 2025 21:48:33 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize()
Message-ID: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>

Remove finalize() from WInputMethod.java - it is used to free a native id.
Also the reason dispose() didn't free it seems no longer relevant.
Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.

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

Commit messages:
 - 8365180

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

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

From achung at openjdk.org  Sat Aug  9 05:12:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Sat, 9 Aug 2025 05:12:23 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v33]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <abheyEupPyxkiB3cLwTvShzZMZtEVszMk7xDgz7p70Q=.be1d7c1e-6c2e-4176-a39b-3caaa2a0b9dc@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  revert DnD migration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/9b547ca1..eece4459

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

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

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

From jwood at openjdk.org  Sun Aug 10 04:42:57 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Sun, 10 Aug 2025 04:42:57 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box
Message-ID: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>

4197755 is marked as a duplicate of [JDK-8176501](https://bugs.openjdk.org/browse/JDK-8176501) , but I think that is a mistake. The complaint in that ticket still reproduces, and it is resolved in this PR.

The complaint is: Arc2D.getBounds() is too large. If an Arc2D represents a small slice of an ellipse, then Arc2D.getBounds() always returns the size of the total ellipse. Arc2D.getBounds2D(), by contrast, has been "high-precision" for decades.

This PR makes Arc2D.getBounds() resemble the same implementation already used in Area, CubicCurve2D, Line2D, Path2D, and QuadCurve2D:

    public Rectangle getBounds() {
        return getBounds2D().getBounds();
    }


This modifies (simplifies) the javadoc for Arc2D.getBounds2D(). If we generally like this PR I assume we'll need a CSR to approve the javadoc change.

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

Commit messages:
 - 4197755: update copyright year
 - 4197755: shorten javadoc
 - 4197755: make Arc2D.getBounds() similar to getBounds2D()
 - 4197755: add failing unit test

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

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

From lbourges at openjdk.org  Sun Aug 10 07:48:09 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 10 Aug 2025 07:48:09 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: <Ogv55q6eH1YulKMgnLNKrsRBbOvH73KSNC4HSS1EqK0=.1a802a05-fafa-4caa-89b4-859bf1fb1e56@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.

LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/26715#issuecomment-3172443956

From psadhukhan at openjdk.org  Sun Aug 10 13:07:12 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 10 Aug 2025 13:07:12 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem
 is rendered with ImageIcon in WindowsLookAndFeel
Message-ID: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>

Hi all,

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

    The commit being backported was authored by Prasanta Sadhukhan on 7 Aug 2025 and was reviewed by Phil Race, Alexander Zuev and Abhishek Kumar.

    Thanks!

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

Commit messages:
 - Backport e29346dbd6328dcadc347a70d8c06ce141efef02

Changes: https://git.openjdk.org/jdk/pull/26717/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26717&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348760
  Stats: 630 lines in 8 files changed: 524 ins; 81 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/26717.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26717/head:pull/26717

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

From liach at openjdk.org  Sun Aug 10 14:20:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Aug 2025 14:20:14 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel
In-Reply-To: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
Message-ID: <DmC_Q3YHzyz3NamSnsc5DdwBwBoiW11AXacOlgJWTas=.a2e02487-78c0-4b60-84fa-a454d128f993@github.com>

On Sun, 10 Aug 2025 12:58:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [e29346db](https://github.com/openjdk/jdk/commit/e29346dbd6328dcadc347a70d8c06ce141efef02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Prasanta Sadhukhan on 7 Aug 2025 and was reviewed by Phil Race, Alexander Zuev and Abhishek Kumar.
> 
>     Thanks!

@prsadhuk We have entered release candidate phase for 25. Only P1 bugs may be fixed with approval. This bug has been present in JDK 8, so I wonder if there is such a critical need at this time. I wonder if you have considered backporting to 25u instead, like 25.0.2.

Also, please close the incorrect version of this backport at #26716.

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

PR Comment: https://git.openjdk.org/jdk/pull/26717#issuecomment-3172665901

From prr at openjdk.org  Sun Aug 10 19:06:11 2025
From: prr at openjdk.org (Phil Race)
Date: Sun, 10 Aug 2025 19:06:11 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
Message-ID: <o_aBDaQ3E58t7qi9qF9XTeG3JjgpATrmCmnw_Hhpke4=.0d8378ba-4cb6-44ac-b45d-3d77def376ef@github.com>

On Wed, 6 Aug 2025 22:34:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
>> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
>> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
>> really meant to clean up internal resources.
>> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
>> 
>> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
>> The risks of this will be covered in the CSR.
>> 
>> There's also a lengthy write up in the JBS issue.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277585

The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8364778

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

PR Comment: https://git.openjdk.org/jdk/pull/26650#issuecomment-3172831881

From mbaesken at openjdk.org  Mon Aug 11 07:08:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Aug 2025 07:08:11 GMT
Subject: RFR: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java times
 out on Windows [v2]
In-Reply-To: <f8OdyXT7Hs848J6T-GpJLW0QKVR8dcJ5yU_1p-eOoxI=.523fb1e1-5acd-4ff6-a878-738c4464edca@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
 <f8OdyXT7Hs848J6T-GpJLW0QKVR8dcJ5yU_1p-eOoxI=.523fb1e1-5acd-4ff6-a878-738c4464edca@github.com>
Message-ID: <dyBxm76lwHxaBieZXTziEP3ng1f5AAqgmrh9mStaL30=.2c099adf-cec5-416f-8e86-ce5193f9dd2a@github.com>

On Fri, 8 Aug 2025 08:10:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
>> Add some logging to the test, and we could also increase the test timeout a bit.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce timeout value

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26668#issuecomment-3173500483

From mbaesken at openjdk.org  Mon Aug 11 07:11:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 11 Aug 2025 07:11:18 GMT
Subject: Integrated: 8364996: java/awt/font/FontNames/LocaleFamilyNames.java
 times out on Windows
In-Reply-To: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
References: <KIBSsmEvDGx9Nx_JRzIuzHYhxdgd3fbaTtkz32QPSEk=.5d75a9f2-88e5-42fa-93bf-119407f35ef8@github.com>
Message-ID: <98INESoiEHTvJ98iCu2Hmisl7UW5lDK5T-LyWL50L1s=.71aafb3e-cf11-4200-a8b8-ae0cedf8026c@github.com>

On Thu, 7 Aug 2025 08:14:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> java/awt/font/FontNames/LocaleFamilyNames.java is slow on Windows and on some machines it even times out.
> Add some logging to the test, and we could also increase the test timeout a bit.

This pull request has now been integrated.

Changeset: 15e8609a
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15e8609a2c3d246e89cfb349cbd21777bc471bae
Stats:     11 lines in 1 file changed: 6 ins; 3 del; 2 mod

8364996: java/awt/font/FontNames/LocaleFamilyNames.java times out on Windows

Reviewed-by: clanger, prr, asteiner

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

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

From aivanov at openjdk.org  Mon Aug 11 11:44:26 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Aug 2025 11:44:26 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
Message-ID: <drGo7OkMCIMLsMKNl1q8vDPvCto9DC_tWEfuZFaeFn0=.63c324a5-283e-4ab9-94e3-69b3ce9bc12b@github.com>

On Thu, 26 Jun 2025 12:24:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MenuItem with icon fix
>
> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 77:
> 
>> 75:     private static Color disabledForeground;
>> 76:     private static Color acceleratorSelectionForeground;
>> 77:     private static Color acceleratorForeground;
> 
> Why are these static? I'm pretty sure the colors can be menu item specific, although more commonly they would be L&F specific.

Why is this comment marked resolved but not resolved at all?

You store a local state of a MenuItemUI in a global class ? this cannot be right!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2266450506

From aivanov at openjdk.org  Mon Aug 11 11:50:25 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Aug 2025 11:50:25 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
Message-ID: <QrfWHpP3EaiJ8R9yerfD7_oU7Pdr0JVfkscLszEVp-w=.9b31498f-ec55-44c4-9745-a55dd00235d7@github.com>

On Thu, 26 Jun 2025 14:22:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MenuItem with icon fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 723:
> 
>> 721:                         acceleratorSelectionForeground);
>> 722:         SwingUtilities3.setAcceleratorForeground(acceleratorForeground);
>> 723:         SwingUtilities3.paintAccText(g, lh, lr);
> 
> This is a really weird way? Pass the colors explicitly as parameters to the `SwingUtilities3.paintAccText` method.

Again, the comment marked as resolved?

You have changed the implementation in `BasicMenuItemUI` but left it unchanged in other methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2266463534

From aivanov at openjdk.org  Mon Aug 11 11:53:26 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Aug 2025 11:53:26 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <QrfWHpP3EaiJ8R9yerfD7_oU7Pdr0JVfkscLszEVp-w=.9b31498f-ec55-44c4-9745-a55dd00235d7@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <QrfWHpP3EaiJ8R9yerfD7_oU7Pdr0JVfkscLszEVp-w=.9b31498f-ec55-44c4-9745-a55dd00235d7@github.com>
Message-ID: <3rrUl2XWzF8hygI1FLF9Bj8R6-4WqS72Db7iAIRF0oY=.a5eef6fa-0230-4b05-9ec2-dd635b750619@github.com>

On Mon, 11 Aug 2025 11:47:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 723:
>> 
>>> 721:                         acceleratorSelectionForeground);
>>> 722:         SwingUtilities3.setAcceleratorForeground(acceleratorForeground);
>>> 723:         SwingUtilities3.paintAccText(g, lh, lr);
>> 
>> This is a really weird way? Pass the colors explicitly as parameters to the `SwingUtilities3.paintAccText` method.
>
> Again, the comment marked as resolved?
> 
> You have changed the implementation in `BasicMenuItemUI` but left it unchanged in other methods.

It's so confusing! This particular comment hasn't been resolved: you still pass parameters to `SwingUtilities3` via global static variables!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2266470220

From aivanov at openjdk.org  Mon Aug 11 12:02:25 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Aug 2025 12:02:25 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
Message-ID: <v-FrdpvVwZ7M4_rWKyL_9iocs12j_fcBgu8bilYL-LM=.7105c561-7540-494b-8f0a-dacead39e181@github.com>

On Thu, 26 Jun 2025 14:30:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MenuItem with icon fix
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 73:
> 
>> 71:     private static Color disabledForeground;
>> 72:     private static Color acceleratorSelectionForeground;
>> 73:     private static Color acceleratorForeground;
> 
> Why are these needed?
> 
> `BasicMenuItemUI` has fields for all three colors: `disabledForeground`, `acceleratorSelectionForeground`, `acceleratorForeground`. Why do you need to create three *new static* fields instead?

Again this doesn't look right to me and this hasn't been resolved at all. These static variables are present in the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2266488331

From aivanov at openjdk.org  Mon Aug 11 12:13:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Aug 2025 12:13:29 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
Message-ID: <0HOiCXT5TrFBzoMZDssNAHbgqJgChqnnm5SbzvkLh14=.45aa80d1-9e10-4ba9-9dd5-9e7cfd197258@github.com>

On Thu, 26 Jun 2025 14:55:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   MenuItem with icon fix
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxMenuItemUI.java line 81:
> 
>> 79:      * Paint MenuItem.
>> 80:      */
>> 81:     protected void paintMenuItem(Graphics g, JComponent c,
> 
> This javadoc doesn't add anything on top of what's in the overridden method, remove the javadoc.
> 
> Add `@Override` annotation.

Again neither of the points raised in this comment has been addressed.

The should be no explicit javadoc, or at least `{@inheritDoc}`, since the overridden method doesn't do anything specific that needs documenting.

> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 157:
> 
>> 155:                     UIManager.getColor(prefix + ".disabledForeground");
>> 156:         }
>> 157:     }
> 
> I'm not convinced `installDefaults` needs overriding, `BasicMenuItemUI` already provides all these colors via its `BasicMenuItemUI.installDefaults` method and protected fields.

This is not addressed / resolved at all ? you've just marked the comment as resolved. Why is it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2266511453
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2266508247

From azvegint at openjdk.org  Mon Aug 11 15:22:11 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 11 Aug 2025 15:22:11 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]
In-Reply-To: <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
Message-ID: <CodJ0ZwrosuiGo3BozRBf3ZzIve9csyphMBgGn0FtW0=.861150b6-3af8-4770-817a-1b3c4de1ffb9@github.com>

On Thu, 7 Aug 2025 12:06:02 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Old copyright year left from the test I copied

Unfortunately, the test fails on Linux, locally and in CI, with `java.lang.Error: Color was not collected after 1000 iterations`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3175334284

From ngubarkov at openjdk.org  Mon Aug 11 15:48:58 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Mon, 11 Aug 2025 15:48:58 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v4]
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

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

  8364434: Inconsistent BufferedContext state after GC
  
  Restrict test to macOS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26576/files
  - new: https://git.openjdk.org/jdk/pull/26576/files/39d150dd..62074474

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

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

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

From ngubarkov at openjdk.org  Mon Aug 11 15:48:58 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Mon, 11 Aug 2025 15:48:58 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v3]
In-Reply-To: <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <aRZ37njbA0MFsexrZtG7Bhi9oybSHfd6winWwA7obYI=.97b13895-0e42-4fdd-bc46-0012d9158455@github.com>
Message-ID: <PVzl9dIhMPa_qPujqnAzXgwmBlWL45k-OkhAgGnlpfA=.b81e96a3-4590-4bfb-9508-662a8d2f51ac@github.com>

On Thu, 7 Aug 2025 12:06:02 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Old copyright year left from the test I copied

I restricted the test to macOS

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3175442743

From prr at openjdk.org  Mon Aug 11 15:54:36 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 11 Aug 2025 15:54:36 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v38]
In-Reply-To: <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
Message-ID: <c6o4qZmnXElHyJW8yNKnBJSnUzFg1mce9SZHuF7cvXA=.16e48164-8c87-4bfa-990e-11eafd896799@github.com>

On Mon, 4 Aug 2025 05:31:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - Fix not needed background effect for Windows 10
>  - Remove Windows version check
>  - Merge master
>  - bullet/checkmark placement for varying imageicon size fix, test update
>  - Adjust offset for varying size imageicon
>  - squish fix
>  - Alignment fix
>  - MenuItem with icon fix
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/57553ca1...5f51ecdc

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 251:

> 249: 
> 250:     public static void setAcceleratorSelectionForeground(Color acceleratorSelectionFg) {
> 251:         acceleratorForeground = acceleratorSelectionFg;

I just noticed this "oops". This should be acceleratorSelectionForeground.
Do we not have a test that would spot this ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2267210782

From prr at openjdk.org  Mon Aug 11 15:54:37 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 11 Aug 2025 15:54:37 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <v-FrdpvVwZ7M4_rWKyL_9iocs12j_fcBgu8bilYL-LM=.7105c561-7540-494b-8f0a-dacead39e181@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <v-FrdpvVwZ7M4_rWKyL_9iocs12j_fcBgu8bilYL-LM=.7105c561-7540-494b-8f0a-dacead39e181@github.com>
Message-ID: <1LHpS99_1k2FHxyif6Zq3wSyHl1uVCrgSgvVd_oUNxg=.45e166d3-fe3e-4525-9bf2-fe235c1fad90@github.com>

On Mon, 11 Aug 2025 11:59:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 73:
>> 
>>> 71:     private static Color disabledForeground;
>>> 72:     private static Color acceleratorSelectionForeground;
>>> 73:     private static Color acceleratorForeground;
>> 
>> Why are these needed?
>> 
>> `BasicMenuItemUI` has fields for all three colors: `disabledForeground`, `acceleratorSelectionForeground`, `acceleratorForeground`. Why do you need to create three *new static* fields instead?
>
> Again this doesn't look right to me and this hasn't been resolved at all. These static variables are present in the class.

This is odd. But since the painting is single-threaded, it shouldn't matter. But this should be re-done.
Maybe I think it can wait for another day but it made me spot a bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2267212681

From prr at openjdk.org  Mon Aug 11 15:57:12 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 11 Aug 2025 15:57:12 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel
In-Reply-To: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
Message-ID: <df4I7Zp_g11Nn11UwYpH5Uod1MfnhaK8yD65Gsb_ojI=.d924c97d-ffe4-40e7-9e0e-3897f9773a8b@github.com>

On Sun, 10 Aug 2025 12:58:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [e29346db](https://github.com/openjdk/jdk/commit/e29346dbd6328dcadc347a70d8c06ce141efef02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Prasanta Sadhukhan on 7 Aug 2025 and was reviewed by Phil Race, Alexander Zuev and Abhishek Kumar.
> 
>     
> The issue is a manual JCK test fails due to lack of demarcation between selected and unselected JRadioButtonMenuItem and JCheckboxMenuItem whereby JDK does not draw bullet/checkmark in WIndows 11 if imgage icon is present as the (position) offset to draw them is same as the image icon position.
> Fix is made to ensure the bullet/checkmark is drawn followed by image icon followed by menu text so that user can distinguish between selected and deselected radiobutton/checkbox menuitem
> 
> CI testing and manual conformance test along with SwingSet2 demo testing is ok

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 258:

> 256:     public static void setAcceleratorSelectionForeground(Color acceleratorSelectionFg) {
> 257:         acceleratorForeground = acceleratorSelectionFg;
> 258:     }

I just pointed this out on the main bug but this looks like a copy/paste error.
It should be acceleratorSelectionForeground.

To Alexei's point, why can't we pass these as parameters ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26717#discussion_r2267225024

From azvegint at openjdk.org  Mon Aug 11 16:17:14 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 11 Aug 2025 16:17:14 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
Message-ID: <xqs_pj98Jl77RbtkRVpSYpoSWCDviQvk_q53AlSWaRk=.a6ea60a3-28a7-4f5d-8c52-fe9736e47564@github.com>

On Wed, 6 Aug 2025 22:34:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
>> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
>> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
>> really meant to clean up internal resources.
>> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
>> 
>> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
>> The risks of this will be covered in the CSR.
>> 
>> There's also a lengthy write up in the JBS issue.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277585

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26650#pullrequestreview-3106645008

From djgredler at gmail.com  Mon Aug 11 16:20:29 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Mon, 11 Aug 2025 18:20:29 +0200
Subject: JDK-4138921: TextLayout handling of empty strings
Message-ID: <CAPA+ug6A88qeG+bRC3UAvvkp67jALtQXEsF0OMxK=WnsXbxQUw@mail.gmail.com>

Hi all,

I was thinking of taking a stab at JDK-4138921 [1], and I have a couple of
questions.

First, there is a related API oddity in that null FontRenderContext
parameters passed to the TextLayout constructors cause a
NullPointerException, rather than an IllegalArgumentException (like all
other parameters). Can this behavior also be changed?

Second, changing all three TextLayout constructors to accept empty strings
sort of implies that we should also allow empty strings in AttributedString
instances (this is currently only allowed if the attribute map is empty).
Is it OK to change this behavior as well?

Let me know your thoughts!

Daniel

[1] https://bugs.openjdk.org/browse/JDK-4138921
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250811/2485cc69/attachment.htm>

From aivanov at openjdk.org  Mon Aug 11 16:25:36 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Aug 2025 16:25:36 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v38]
In-Reply-To: <c6o4qZmnXElHyJW8yNKnBJSnUzFg1mce9SZHuF7cvXA=.16e48164-8c87-4bfa-990e-11eafd896799@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
 <c6o4qZmnXElHyJW8yNKnBJSnUzFg1mce9SZHuF7cvXA=.16e48164-8c87-4bfa-990e-11eafd896799@github.com>
Message-ID: <Agfe2joephR0Ul2hK8fWzesc8lUhvP1RwhJuWCuLJLM=.437aac26-84a6-496a-8233-f2cc7c18418e@github.com>

On Mon, 11 Aug 2025 15:51:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
>> 
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>>  - Fix not needed background effect for Windows 10
>>  - Remove Windows version check
>>  - Merge master
>>  - bullet/checkmark placement for varying imageicon size fix, test update
>>  - Adjust offset for varying size imageicon
>>  - squish fix
>>  - Alignment fix
>>  - MenuItem with icon fix
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
>>  - ... and 32 more: https://git.openjdk.org/jdk/compare/57553ca1...5f51ecdc
>
> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 251:
> 
>> 249: 
>> 250:     public static void setAcceleratorSelectionForeground(Color acceleratorSelectionFg) {
>> 251:         acceleratorForeground = acceleratorSelectionFg;
> 
> I just noticed this "oops". This should be acceleratorSelectionForeground.
> Do we not have a test that would spot this ?

Yes, you're right!

I was curious why my IDE showed `acceleratorSelectionForeground` in grey as if unused. It's used but never assigned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2267330854

From prr at openjdk.org  Mon Aug 11 16:32:27 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 11 Aug 2025 16:32:27 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
Message-ID: <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>

On Mon, 30 Jun 2025 02:16:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 163:
>> 
>>> 161:             rect.y += insets.top;
>>> 162:             rect.width -= (insets.right + rect.x);
>>> 163:             rect.height -= (insets.bottom + rect.y);
>> 
>> Suggestion:
>> 
>>             rect.width -= (insets.right + insets.left);
>>             rect.height -= (insets.bottom + insets.top);
>> 
>> The formula doesn't look right. Why do you subtract `rect.x` and `rect.y` instead of `insets.left` and `insets.top`?
>> 
>> This would work correctly if both `rect.x` and `rect.y` are zero, but it would give wrong results in other cases.
>
> It was the same calculation used in `BasicMenuItemUI `which is now moved to `SwingUtilities3 `so that it can be called from Basic and `WindowsMenuItemUI `to avoid code duplication....you can compare the contents before the fix.....in this specific case, `rect.x` is inclusive of `insets.left`..
> 
> Similarly other SwingUtilities3 changes are also as it was in BasicMenuItemUI, it was just moved verbatim from BasicMenuItemUI to it so that it can be called from both Basic and WindowsMenuItemUI class with no changes..nothing more and nothing less...probably it can be optimized but I wanted to keep the call and the content in each method in SwingUtilities3 same as it was in BasicMenuItemUI

They can be added parameters to SU3.paintAccText.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2267355945

From aivanov at openjdk.org  Mon Aug 11 16:32:27 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Aug 2025 16:32:27 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <1LHpS99_1k2FHxyif6Zq3wSyHl1uVCrgSgvVd_oUNxg=.45e166d3-fe3e-4525-9bf2-fe235c1fad90@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <v-FrdpvVwZ7M4_rWKyL_9iocs12j_fcBgu8bilYL-LM=.7105c561-7540-494b-8f0a-dacead39e181@github.com>
 <1LHpS99_1k2FHxyif6Zq3wSyHl1uVCrgSgvVd_oUNxg=.45e166d3-fe3e-4525-9bf2-fe235c1fad90@github.com>
Message-ID: <UHlPRLuoZgzMhzLwUwIPZ9v03eoXJ4xP9baxJe8s8AM=.61f79f13-3349-413b-96b3-a5d62aae94c0@github.com>

On Mon, 11 Aug 2025 15:51:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> Again this doesn't look right to me and this hasn't been resolved at all. These static variables are present in the class.
>
> This is odd. But since the painting is single-threaded, it shouldn't matter. But this should be re-done.
> Maybe I think it can wait for another day but it made me spot a bug.

I believe there's a potential bug in `WindowsMenuItemUI.java` in the newly overridden method and new static fields. There's a chance that the colors aren't updated when needed. Yet I haven't come up with a test.

> Maybe I think it can wait for another day but it made me spot a bug.

Yeah, it can wait?

This was integrated so quickly that I didn't have any chance to look at the latest code updates.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2267362205

From philip.race at oracle.com  Mon Aug 11 17:11:55 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 11 Aug 2025 10:11:55 -0700
Subject: JDK-4138921: TextLayout handling of empty strings
In-Reply-To: <CAPA+ug6A88qeG+bRC3UAvvkp67jALtQXEsF0OMxK=WnsXbxQUw@mail.gmail.com>
References: <CAPA+ug6A88qeG+bRC3UAvvkp67jALtQXEsF0OMxK=WnsXbxQUw@mail.gmail.com>
Message-ID: <994c74d6-2eb4-4588-ad6a-25529b68bd1e@oracle.com>



On 8/11/25 9:20 AM, Daniel Gredler wrote:
> Hi all,
>
> I was thinking of taking a stab at?JDK-4138921 [1], and I have a 
> couple of questions.
>
> First, there is a related API oddity in that null FontRenderContext 
> parameters passed to the TextLayout constructors cause a 
> NullPointerException, rather than an IllegalArgumentException (like 
> all other parameters). Can this behavior also be changed?

None of these are documented .. they all should be.

It is a bit odd that frc is the only one not explicitly checked so the 
NPE is just what 'happens'.
I'd be reluctant to change the NPE without a good reason and I'm 
half-wondering if a null FRC was
supposed to default to a default FRC ?? But somewhere along the line the 
implementation changed.
I'd say just specify what happens for complete compatibility.

>
> Second, changing all three TextLayout constructors to accept empty 
> strings sort of implies that we should?also allow empty strings in 
> AttributedString instances (this is currently only allowed if the 
> attribute map is empty). Is it OK to change this behavior as well?

I don't think I ever understood why this was dis-allowed on TextLayout.
Perhaps it was to prevent some incorrect usage from ever slipping into 
being acceptable ?

AttributedString is part of the java.base module, I don't have any say 
over that, although in the very beginning
there was a decent overlap in the people working on that and TextLayout etc.
I'd start by asking Naoto (cc'ed).

-phil.

>
> Let me know your thoughts!
>
> Daniel
>
> [1] https://bugs.openjdk.org/browse/JDK-4138921
>
>


From psadhukhan at openjdk.org  Tue Aug 12 01:32:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Aug 2025 01:32:58 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
Message-ID: <-7aupt_im0UMgAdK62BnBs5N_KYCZFJ0sRu3moj3Kdk=.62bbf119-8e81-4636-ae93-04b44a7a7191@github.com>

> Hi all,
> 
>     This pull request contains a backport of commit [e29346db](https://github.com/openjdk/jdk/commit/e29346dbd6328dcadc347a70d8c06ce141efef02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Prasanta Sadhukhan on 7 Aug 2025 and was reviewed by Phil Race, Alexander Zuev and Abhishek Kumar.
> 
>     
> The issue is a manual JCK test fails due to lack of demarcation between selected and unselected JRadioButtonMenuItem and JCheckboxMenuItem whereby JDK does not draw bullet/checkmark in WIndows 11 if imgage icon is present as the (position) offset to draw them is same as the image icon position.
> Fix is made to ensure the bullet/checkmark is drawn followed by image icon followed by menu text so that user can distinguish between selected and deselected radiobutton/checkbox menuitem
> 
> CI testing and manual conformance test along with SwingSet2 demo testing is ok

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

  Fix copy-paste assignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26717/files
  - new: https://git.openjdk.org/jdk/pull/26717/files/5f4ac2eb..1afd2b3b

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

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

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

From psadhukhan at openjdk.org  Tue Aug 12 01:32:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Aug 2025 01:32:58 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <df4I7Zp_g11Nn11UwYpH5Uod1MfnhaK8yD65Gsb_ojI=.d924c97d-ffe4-40e7-9e0e-3897f9773a8b@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
 <df4I7Zp_g11Nn11UwYpH5Uod1MfnhaK8yD65Gsb_ojI=.d924c97d-ffe4-40e7-9e0e-3897f9773a8b@github.com>
Message-ID: <Ew0_ViObEPL_ixB8i1a6q9O-5YCCaoFGQQ7cf6rvbZ0=.5a9f6997-bc44-4693-bbde-a3a9f337e4e6@github.com>

On Mon, 11 Aug 2025 15:54:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copy-paste assignment
>
> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 258:
> 
>> 256:     public static void setAcceleratorSelectionForeground(Color acceleratorSelectionFg) {
>> 257:         acceleratorForeground = acceleratorSelectionFg;
>> 258:     }
> 
> I just pointed this out on the main bug but this looks like a copy/paste error.
> It should be acceleratorSelectionForeground.
> 
> To Alexei's point, why can't we pass these as parameters ?

Fixed the assignment..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26717#discussion_r2268362347

From achung at openjdk.org  Tue Aug 12 01:34:56 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 12 Aug 2025 01:34:56 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v34]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <_8bZ8L-mcOxu11bs0I1sa3_Q6yXVFkQUDIqIYNoLk-8=.e5b535c6-c4e9-46ad-b33f-4401ae9959af@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  dragAndDrop readded to ExtendedRobot

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/eece4459..4425986c

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

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

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

From psadhukhan at openjdk.org  Tue Aug 12 04:17:24 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Aug 2025 04:17:24 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
Message-ID: <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>

On Mon, 11 Aug 2025 16:27:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> It was the same calculation used in `BasicMenuItemUI `which is now moved to `SwingUtilities3 `so that it can be called from Basic and `WindowsMenuItemUI `to avoid code duplication....you can compare the contents before the fix.....in this specific case, `rect.x` is inclusive of `insets.left`..
>> 
>> Similarly other SwingUtilities3 changes are also as it was in BasicMenuItemUI, it was just moved verbatim from BasicMenuItemUI to it so that it can be called from both Basic and WindowsMenuItemUI class with no changes..nothing more and nothing less...probably it can be optimized but I wanted to keep the call and the content in each method in SwingUtilities3 same as it was in BasicMenuItemUI
>
> They can be added parameters to SU3.paintAccText.

Since we needed to move the `paintIcon`, `paintCheckIcon`, `paintAccText`, `paintText `and `paintArrowIcon `from `BasicMenuITemUI` to `SwingUtilties3` so that it can be called from `WindowsMenuItemUI` and `BacisMenuItemUI `to avoid code duplication, I had to made these methods static since these methods are called from `paintMenuItem` which is needed to be called from `WindowsCheckBoxMenuItemUI`, `WindowsRadioButtonMenuItemUI`, `WindowsMenuUI `via `WindowsMenuItemUI.paintMenuItem` and because the methods were static the variables accessed by it also needed to be static to avoid build issues

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2268532062

From tr at openjdk.org  Tue Aug 12 09:30:15 2025
From: tr at openjdk.org (Tejesh R)
Date: Tue, 12 Aug 2025 09:30:15 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
Message-ID: <jFYbnlg8m2KSmdYdoj1FNmxYPtIGY3arRTwsQ29KHt4=.8b421f04-41fa-4d0f-bd0f-1c7c90c5fa8b@github.com>

On Tue, 5 Aug 2025 16:18:41 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
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

Did you try the reporter solution for the failed test ? - [JDK-8158801](https://bugs.openjdk.org/browse/JDK-8158801)
_"We should either use a special separate frame to click on to restore focus handling or hazard to use locationOnScreen"_

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

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

From aivanov at openjdk.org  Tue Aug 12 10:32:28 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 10:32:28 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
Message-ID: <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>

On Tue, 12 Aug 2025 04:14:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> They can be added parameters to SU3.paintAccText.
>
> Since we needed to move the `paintIcon`, `paintCheckIcon`, `paintAccText`, `paintText `and `paintArrowIcon `from `BasicMenuITemUI` to `SwingUtilties3` so that it can be called from `WindowsMenuItemUI` and `BacisMenuItemUI `to avoid code duplication, I had to made these methods static since these methods are called from `paintMenuItem` which is needed to be called from `WindowsCheckBoxMenuItemUI`, `WindowsRadioButtonMenuItemUI`, `WindowsMenuUI `via `WindowsMenuItemUI.paintMenuItem` [similar to existing methods`WindowsMenuItemUI.paintText `and `WindowsMenuItemUI.paintBackground`] and because the methods were static the variables accessed by it also needed to be static to avoid build issues
> 
> and I didnt want to change the call, signature and content of this methods so that there was no inadvertent regression introduced which is the reason I didn't change the parameters of these methods

I understand that methods in SwingUtilities3 had to be static, but why the colors couldn't be passed to the method as parameters? [I did suggest](https://github.com/openjdk/jdk/pull/23324#discussion_r2169199694) passing the colors as parameters:

> Pass the colors explicitly as parameters to the `SwingUtilities3.paintAccText` method.

Storing the colors as global variables in a utility class leaks these objects. After L&F is changed to something else, these colors persist in `SwingUtilities3`.

The same applies to the new static fields in `WindowsMenuItemUI`. They're not needed. [I had raised this concern](https://github.com/openjdk/jdk/pull/23324#discussion_r2169217699), it went unanswered and marked as resolved. And I believe there's a new bug because of these static fields.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269414401

From jdv at openjdk.org  Tue Aug 12 11:34:13 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 12 Aug 2025 11:34:13 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v4]
In-Reply-To: <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
Message-ID: <VxAQoa-wmg5MGarpwWV9coP72jWEHDY5GZPvld0e80g=.be13ec06-6099-4831-8be2-d06411e487ef@github.com>

On Mon, 11 Aug 2025 15:48:58 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Restrict test to macOS

Yes the test if run on linux fails in CI because of Color not getting GC'ed. Adding sleep after each GC also doesn't help(This is done in some other tests which rely on System.gc())
 
Since System.gc() is just a hint to JVM, How about passing the test after trying for MAX_ITERATIONS and not making the test specific to mac? Because this test might start failing intermittently in some scenarios which are not under our control.

test/jdk/java/awt/ColorClass/WeakColorTest.java line 24:

> 22:  */
> 23: 
> 24: import java.awt.*;

Better to expand wild card imports.

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

PR Review: https://git.openjdk.org/jdk/pull/26576#pullrequestreview-3109991257
PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2269531170

From psadhukhan at openjdk.org  Tue Aug 12 11:37:26 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Aug 2025 11:37:26 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
 <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
Message-ID: <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>

On Tue, 12 Aug 2025 10:29:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Since we needed to move the `paintIcon`, `paintCheckIcon`, `paintAccText`, `paintText `and `paintArrowIcon `from `BasicMenuITemUI` to `SwingUtilties3` so that it can be called from `WindowsMenuItemUI` and `BacisMenuItemUI `to avoid code duplication, I had to made these methods static since these methods are called from `paintMenuItem` which is needed to be called from `WindowsCheckBoxMenuItemUI`, `WindowsRadioButtonMenuItemUI`, `WindowsMenuUI `via `WindowsMenuItemUI.paintMenuItem` [similar to existing methods`WindowsMenuItemUI.paintText `and `WindowsMenuItemUI.paintBackground`] and because the methods were static the variables accessed by it also needed to be static to avoid build issues
>> 
>> and I didnt want to change the call, signature and content of this methods so that there was no inadvertent regression introduced which is the reason I didn't change the parameters of these methods
>
> I understand that methods in SwingUtilities3 had to be static, but why the colors couldn't be passed to the method as parameters? [I did suggest](https://github.com/openjdk/jdk/pull/23324#discussion_r2169199694) passing the colors as parameters:
> 
>> Pass the colors explicitly as parameters to the `SwingUtilities3.paintAccText` method.
> 
> Storing the colors as global variables in a utility class leaks these objects. After L&F is changed to something else, these colors persist in `SwingUtilities3`.
> 
> The same applies to the new static fields in `WindowsMenuItemUI`. They're not needed. [I had raised this concern](https://github.com/openjdk/jdk/pull/23324#discussion_r2169217699), it went unanswered and marked as resolved. And I believe there's a new bug because of these static fields.

If we have to call `WindowsMenuItemUI.paintMenuItem` from `WindowsCheckBoxMenuItemUI`, `WindowsRadioButtonMenuItemUI`, `WindowsMenuUI ` then `paintMenuItem `has to be static in `WindowsMenuItemUI`
so `paintAccText ` called from `paintMenuItem` has to be static so even if we try to pass the parameters to `SwingUtilities3.paintAccText` from `WindowsMenuItemUI.paintAccText ` those parameters need to be static else we will be getting this kind of build error

error: non-static variable disabledForeground cannot be referenced from a static context
        SwingUtilities3.paintAccText(g, lh, lr, disabledForeground, acceleratorSelectionForeground, acceleratorForeground);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269557832

From lbourges at openjdk.org  Tue Aug 12 11:52:13 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 12 Aug 2025 11:52:13 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v4]
In-Reply-To: <VxAQoa-wmg5MGarpwWV9coP72jWEHDY5GZPvld0e80g=.be13ec06-6099-4831-8be2-d06411e487ef@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
 <VxAQoa-wmg5MGarpwWV9coP72jWEHDY5GZPvld0e80g=.be13ec06-6099-4831-8be2-d06411e487ef@github.com>
Message-ID: <p3onObjdtqs5w6DiIasCLku7Dh9KeFZR_NtFD5j6Rwk=.1d7b0cea-8a35-467f-b4bb-2b782ca64625@github.com>

On Tue, 12 Aug 2025 11:22:22 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364434: Inconsistent BufferedContext state after GC
>>   
>>   Restrict test to macOS
>
> test/jdk/java/awt/ColorClass/WeakColorTest.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: import java.awt.*;
> 
> Better to expand wild card imports.

If test depends on gc collector + special mode, then set explicitely the needed gc (G1 ?) with small heap + needed tuning to ensure consistent behaviour accross platform if possible and not rely on platform's default behaviour...

My 2 cents.
Laurent

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2269590418

From aivanov at openjdk.org  Tue Aug 12 11:53:28 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 11:53:28 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
 <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
 <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>
Message-ID: <B6wMia5K9zciJNqX7HgJSGtXX1fLzRkKLbIWgkPDkcI=.4b7b4e30-9523-42e0-be9c-bb13085bab4e@github.com>

On Tue, 12 Aug 2025 11:34:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I understand that methods in SwingUtilities3 had to be static, but why the colors couldn't be passed to the method as parameters? [I did suggest](https://github.com/openjdk/jdk/pull/23324#discussion_r2169199694) passing the colors as parameters:
>> 
>>> Pass the colors explicitly as parameters to the `SwingUtilities3.paintAccText` method.
>> 
>> Storing the colors as global variables in a utility class leaks these objects. After L&F is changed to something else, these colors persist in `SwingUtilities3`.
>> 
>> The same applies to the new static fields in `WindowsMenuItemUI`. They're not needed. [I had raised this concern](https://github.com/openjdk/jdk/pull/23324#discussion_r2169217699), it went unanswered and marked as resolved. And I believe there's a new bug because of these static fields.
>
> If we have to call `WindowsMenuItemUI.paintMenuItem` from `WindowsCheckBoxMenuItemUI`, `WindowsRadioButtonMenuItemUI`, `WindowsMenuUI ` then `paintMenuItem `has to be static in `WindowsMenuItemUI`
> so `paintAccText ` called from `paintMenuItem` has to be static so even if we try to pass the parameters to `SwingUtilities3.paintAccText` from `WindowsMenuItemUI.paintAccText ` those parameters need to be static else we will be getting this kind of build error
> 
> error: non-static variable disabledForeground cannot be referenced from a static context
>         SwingUtilities3.paintAccText(g, lh, lr, disabledForeground, acceleratorSelectionForeground, acceleratorForeground);

I don't see the real code that you're referring to, but I strongly believe you can pass these colors as parameters.

`WindowsMenuItemUI.paintMenuItem` isn't static and it has access to all the required colors inherited from `BasicMenuItemUI`, it calls a static method `paintMenuItem` as already passes background and foreground as parameters, therefore you could've added more parameters if they were needed.

One way or another, you call these static methods from a non-static method ? pass all the required parameters, maybe the `WindowsMenuItemUI` object itself to the static methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269593938

From jdv at openjdk.org  Tue Aug 12 11:56:14 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 12 Aug 2025 11:56:14 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v4]
In-Reply-To: <p3onObjdtqs5w6DiIasCLku7Dh9KeFZR_NtFD5j6Rwk=.1d7b0cea-8a35-467f-b4bb-2b782ca64625@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
 <VxAQoa-wmg5MGarpwWV9coP72jWEHDY5GZPvld0e80g=.be13ec06-6099-4831-8be2-d06411e487ef@github.com>
 <p3onObjdtqs5w6DiIasCLku7Dh9KeFZR_NtFD5j6Rwk=.1d7b0cea-8a35-467f-b4bb-2b782ca64625@github.com>
Message-ID: <dYsR-m0e7_K102OLVpuNQe4IGfwnm-20PICASQVSf6w=.94a7052c-003f-4624-b4ce-03dfe5fa4b5f@github.com>

On Tue, 12 Aug 2025 11:48:56 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> test/jdk/java/awt/ColorClass/WeakColorTest.java line 24:
>> 
>>> 22:  */
>>> 23: 
>>> 24: import java.awt.*;
>> 
>> Better to expand wild card imports.
>
> If test depends on gc collector + special mode, then set explicitely the needed gc (G1 ?) with small heap + needed tuning to ensure consistent behaviour accross platform if possible and not rely on platform's default behaviour...
> 
> My 2 cents.
> Laurent

GC is not guaranteed. So its better to try for good number of iterations and not fail just because GC is not honoured.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2269600404

From kcr at openjdk.org  Tue Aug 12 11:58:32 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 12 Aug 2025 11:58:32 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <B6wMia5K9zciJNqX7HgJSGtXX1fLzRkKLbIWgkPDkcI=.4b7b4e30-9523-42e0-be9c-bb13085bab4e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
 <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
 <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>
 <B6wMia5K9zciJNqX7HgJSGtXX1fLzRkKLbIWgkPDkcI=.4b7b4e30-9523-42e0-be9c-bb13085bab4e@github.com>
Message-ID: <9L99GLEqpvF09UNPO360XXwhHxY1g9gJdmr3baoqFYM=.cab0de6c-9ae9-4908-b046-9ba696eda900@github.com>

On Tue, 12 Aug 2025 11:50:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> If we have to call `WindowsMenuItemUI.paintMenuItem` from `WindowsCheckBoxMenuItemUI`, `WindowsRadioButtonMenuItemUI`, `WindowsMenuUI ` then `paintMenuItem `has to be static in `WindowsMenuItemUI`
>> so `paintAccText ` called from `paintMenuItem` has to be static so even if we try to pass the parameters to `SwingUtilities3.paintAccText` from `WindowsMenuItemUI.paintAccText ` those parameters need to be static else we will be getting this kind of build error
>> 
>> error: non-static variable disabledForeground cannot be referenced from a static context
>>         SwingUtilities3.paintAccText(g, lh, lr, disabledForeground, acceleratorSelectionForeground, acceleratorForeground);
>
> I don't see the real code that you're referring to, but I strongly believe you can pass these colors as parameters.
> 
> `WindowsMenuItemUI.paintMenuItem` isn't static and it has access to all the required colors inherited from `BasicMenuItemUI`, it calls a static method `paintMenuItem` as already passes background and foreground as parameters, therefore you could've added more parameters if they were needed.
> 
> One way or another, you call these static methods from a non-static method ? pass all the required parameters, maybe the `WindowsMenuItemUI` object itself to the static methods.

Unless there is a functional regression as a result (as there was for the copy/paste error), given that it is very late in the release cycle for jdk25, I strongly recommend any additional refactoring be done in a follow-up bug for JDK 26 where it can be discussed and done without the pressure of a deadline.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269605816

From ngubarkov at openjdk.org  Tue Aug 12 12:00:37 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Tue, 12 Aug 2025 12:00:37 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v4]
In-Reply-To: <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
Message-ID: <w528LNu4YYl1CKn0LAye9ZUs5HoVeamm7CtC0NHnsY8=.7d2622d1-cd10-4c6e-9ff0-c471a00ed167@github.com>

On Mon, 11 Aug 2025 15:48:58 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Restrict test to macOS

Now the test is skipped if Color fails to get collected

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3179016440

From ngubarkov at openjdk.org  Tue Aug 12 12:00:37 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Tue, 12 Aug 2025 12:00:37 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

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

  8364434: Inconsistent BufferedContext state after GC
  
  Skip the test if Color was not GC'ed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26576/files
  - new: https://git.openjdk.org/jdk/pull/26576/files/62074474..370bdaa6

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

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

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

From ngubarkov at openjdk.org  Tue Aug 12 12:10:12 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Tue, 12 Aug 2025 12:10:12 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v4]
In-Reply-To: <dYsR-m0e7_K102OLVpuNQe4IGfwnm-20PICASQVSf6w=.94a7052c-003f-4624-b4ce-03dfe5fa4b5f@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
 <VxAQoa-wmg5MGarpwWV9coP72jWEHDY5GZPvld0e80g=.be13ec06-6099-4831-8be2-d06411e487ef@github.com>
 <p3onObjdtqs5w6DiIasCLku7Dh9KeFZR_NtFD5j6Rwk=.1d7b0cea-8a35-467f-b4bb-2b782ca64625@github.com>
 <dYsR-m0e7_K102OLVpuNQe4IGfwnm-20PICASQVSf6w=.94a7052c-003f-4624-b4ce-03dfe5fa4b5f@github.com>
Message-ID: <3XJQZSb0bIeMRW5kwXXHOyUUQt3RMGOyDePI4_UOP1s=.82073058-04b2-4e2c-a18e-7cb46251af5b@github.com>

On Tue, 12 Aug 2025 11:53:13 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> If test depends on gc collector + special mode, then set explicitely the needed gc (G1 ?) with small heap + needed tuning to ensure consistent behaviour accross platform if possible and not rely on platform's default behaviour...
>> 
>> My 2 cents.
>> Laurent
>
> GC is not guaranteed. So its better to try for good number of iterations and not fail just because GC is not honoured.

I've limited the heap size to 16Mb and allocating arrays of 1M references 1K times. Apparently, this is still not enough to reliably collect the Color.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2269632142

From aivanov at openjdk.org  Tue Aug 12 12:11:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 12:11:29 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <9L99GLEqpvF09UNPO360XXwhHxY1g9gJdmr3baoqFYM=.cab0de6c-9ae9-4908-b046-9ba696eda900@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
 <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
 <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>
 <B6wMia5K9zciJNqX7HgJSGtXX1fLzRkKLbIWgkPDkcI=.4b7b4e30-9523-42e0-be9c-bb13085bab4e@github.com>
 <9L99GLEqpvF09UNPO360XXwhHxY1g9gJdmr3baoqFYM=.cab0de6c-9ae9-4908-b046-9ba696eda900@github.com>
Message-ID: <PW6-y7L-Os38mWiVH_ZKmSfCm8o5ti4l32XH7bgjJcA=.1f0b8e56-0d5c-4769-958b-bd33e4148907@github.com>

On Tue, 12 Aug 2025 11:55:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I don't see the real code that you're referring to, but I strongly believe you can pass these colors as parameters.
>> 
>> `WindowsMenuItemUI.paintMenuItem` isn't static and it has access to all the required colors inherited from `BasicMenuItemUI`, it calls a static method `paintMenuItem` as already passes background and foreground as parameters, therefore you could've added more parameters if they were needed.
>> 
>> One way or another, you call these static methods from a non-static method ? pass all the required parameters, maybe the `WindowsMenuItemUI` object itself to the static methods.
>
> Unless there is a functional regression as a result (as there was for the copy/paste error), given that it is very late in the release cycle for jdk25, I strongly recommend any additional refactoring be done in a follow-up bug for JDK 26 where it can be discussed and done without the pressure of a deadline.

@kevinrushforth I'm not suggesting fixing this right away?now?under the pressure.

I think these issues should've been resolved before integrating this fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269633677

From aivanov at openjdk.org  Tue Aug 12 12:11:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 12:11:30 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v38]
In-Reply-To: <Agfe2joephR0Ul2hK8fWzesc8lUhvP1RwhJuWCuLJLM=.437aac26-84a6-496a-8233-f2cc7c18418e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <VbX3L3Ja-rOGKD9w55W7DwQ2CrH6TQJeIAqJrh7PzEk=.489f10d5-3828-4658-a244-98c1e530ef7f@github.com>
 <c6o4qZmnXElHyJW8yNKnBJSnUzFg1mce9SZHuF7cvXA=.16e48164-8c87-4bfa-990e-11eafd896799@github.com>
 <Agfe2joephR0Ul2hK8fWzesc8lUhvP1RwhJuWCuLJLM=.437aac26-84a6-496a-8233-f2cc7c18418e@github.com>
Message-ID: <-oiVIlxdGRmSh9YfP_IBLwfHExdzJWrBGdzUDpQTHC0=.ccee0100-68c2-4fd0-9d83-f23f22fdf4f5@github.com>

On Mon, 11 Aug 2025 16:22:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 251:
>> 
>>> 249: 
>>> 250:     public static void setAcceleratorSelectionForeground(Color acceleratorSelectionFg) {
>>> 251:         acceleratorForeground = acceleratorSelectionFg;
>> 
>> I just noticed this "oops". This should be acceleratorSelectionForeground.
>> Do we not have a test that would spot this ?
>
> Yes, you're right!
> 
> I was curious why my IDE showed `acceleratorSelectionForeground` in grey as if unused. It's used but never assigned.

> I just noticed this "oops". This should be acceleratorSelectionForeground. Do we not have a test that would spot this ?

I've submitted [JDK-8365375](https://bugs.openjdk.org/browse/JDK-8365375): _Method SU3.setAcceleratorSelectionForeground assigns to acceleratorForeground_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269635271

From aivanov at openjdk.org  Tue Aug 12 12:14:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 12:14:15 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <Ew0_ViObEPL_ixB8i1a6q9O-5YCCaoFGQQ7cf6rvbZ0=.5a9f6997-bc44-4693-bbde-a3a9f337e4e6@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
 <df4I7Zp_g11Nn11UwYpH5Uod1MfnhaK8yD65Gsb_ojI=.d924c97d-ffe4-40e7-9e0e-3897f9773a8b@github.com>
 <Ew0_ViObEPL_ixB8i1a6q9O-5YCCaoFGQQ7cf6rvbZ0=.5a9f6997-bc44-4693-bbde-a3a9f337e4e6@github.com>
Message-ID: <BsE0A1Rgzp4Tt1oYpTiSu30CGGpdGCMOzUOlkOloCg8=.4f70d8b4-e538-45eb-835f-795530bd3ddc@github.com>

On Tue, 12 Aug 2025 01:30:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Fixed the assignment..

This may be an appropriate quick fix at this moment.

Yet this bug needs fixing in mainline, all the update releases will also be affected as soon as [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) is backported.

I've submitted [JDK-8365375](https://bugs.openjdk.org/browse/JDK-8365375): _Method SU3.setAcceleratorSelectionForeground assigns to acceleratorForeground_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26717#discussion_r2269640007

From kcr at openjdk.org  Tue Aug 12 12:19:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 12 Aug 2025 12:19:26 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <PW6-y7L-Os38mWiVH_ZKmSfCm8o5ti4l32XH7bgjJcA=.1f0b8e56-0d5c-4769-958b-bd33e4148907@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
 <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
 <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>
 <B6wMia5K9zciJNqX7HgJSGtXX1fLzRkKLbIWgkPDkcI=.4b7b4e30-9523-42e0-be9c-bb13085bab4e@github.com>
 <9L99GLEqpvF09UNPO360XXwhHxY1g9gJdmr3baoqFYM=.cab0de6c-9ae9-4908-b046-9ba696eda900@github.com>
 <PW6-y7L-Os38mWiVH_ZKmSfCm8o5ti4l32X
 H7bgjJcA=.1f0b8e56-0d5c-4769-958b-bd33e4148907@github.com>
Message-ID: <_lke_EHP8a2kSnmVeuV07BC0NnolkelfyDs-qlqUnGI=.e5f41721-3aab-4ff6-b4cf-41071bf4d96a@github.com>

On Tue, 12 Aug 2025 12:08:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Unless there is a functional regression as a result (as there was for the copy/paste error), given that it is very late in the release cycle for jdk25, I strongly recommend any additional refactoring be done in a follow-up bug for JDK 26 where it can be discussed and done without the pressure of a deadline.
>
> @kevinrushforth I'm not suggesting fixing this right away?now?under the pressure.
> 
> I think these issues should've been resolved before integrating this fix.

OK, thanks. Let's file a follow-up bug to capture this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269651973

From aivanov at openjdk.org  Tue Aug 12 12:24:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 12:24:31 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <_lke_EHP8a2kSnmVeuV07BC0NnolkelfyDs-qlqUnGI=.e5f41721-3aab-4ff6-b4cf-41071bf4d96a@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
 <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
 <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>
 <B6wMia5K9zciJNqX7HgJSGtXX1fLzRkKLbIWgkPDkcI=.4b7b4e30-9523-42e0-be9c-bb13085bab4e@github.com>
 <9L99GLEqpvF09UNPO360XXwhHxY1g9gJdmr3baoqFYM=.cab0de6c-9ae9-4908-b046-9ba696eda900@github.com>
 <PW6-y7L-Os38mWiVH_ZKmSfCm8o5ti4l32X
 H7bgjJcA=.1f0b8e56-0d5c-4769-958b-bd33e4148907@github.com>
 <_lke_EHP8a2kSnmVeuV07BC0NnolkelfyDs-qlqUnGI=.e5f41721-3aab-4ff6-b4cf-41071bf4d96a@github.com>
Message-ID: <a62uXc8zCxOZJeDgygaQYAAdSjH4xkduCoGHThgV7Zk=.5f170579-a7a8-47aa-aa35-a1155c88ba50@github.com>

On Tue, 12 Aug 2025 12:16:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @kevinrushforth I'm not suggesting fixing this right away?now?under the pressure.
>> 
>> I think these issues should've been resolved before integrating this fix.
>
> OK, thanks. Let's file a follow-up bug to capture this.

> The formula doesn't look right. Why do you subtract `rect.x` and `rect.y` instead of `insets.left` and `insets.top`?
> 
> This would work correctly if both `rect.x` and `rect.y` are zero, but it would give wrong results in other cases.

I've submitted [JDK-8365379](https://bugs.openjdk.org/browse/JDK-8365379): _SU3.applyInsets may produce wrong results_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269664033

From lbourges at openjdk.org  Tue Aug 12 12:27:11 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 12 Aug 2025 12:27:11 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v4]
In-Reply-To: <3XJQZSb0bIeMRW5kwXXHOyUUQt3RMGOyDePI4_UOP1s=.82073058-04b2-4e2c-a18e-7cb46251af5b@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <iHJKdUtrAZeynZRgRAgMiV7xFAfQBIr-fAJy4FHxb8A=.18c3fdae-a8c3-4308-b785-4e86382de78d@github.com>
 <VxAQoa-wmg5MGarpwWV9coP72jWEHDY5GZPvld0e80g=.be13ec06-6099-4831-8be2-d06411e487ef@github.com>
 <p3onObjdtqs5w6DiIasCLku7Dh9KeFZR_NtFD5j6Rwk=.1d7b0cea-8a35-467f-b4bb-2b782ca64625@github.com>
 <dYsR-m0e7_K102OLVpuNQe4IGfwnm-20PICASQVSf6w=.94a7052c-003f-4624-b4ce-03dfe5fa4b5f@github.com>
 <3XJQZSb0bIeMRW5kwXXHOyUUQt3RMGOyDePI4_UOP1s=.82073058-04b2-4e2c-a18e-7cb46251af5b@github.com>
Message-ID: <o6N_hnmMK1CrAngDbHhWOlE3rFRx681BkGwIQQaSvE0=.c1fd8a7b-c1d7-4416-8f5b-ebc0f7e0371e@github.com>

On Tue, 12 Aug 2025 12:07:15 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> GC is not guaranteed. So its better to try for good number of iterations and not fail just because GC is not honoured.
>
> I've limited the heap size to 16Mb and allocating arrays of 1M references 1K times. Apparently, this is still not enough to reliably collect the Color.

Just use -XX:+PrintFlagsFinal ... to get real jvm parameter map to be compared accross platforms to ensure gc consistency.
Or linux pipeline is keeping strong references on Color objects in the specific java/native pipeline code!!!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2269671366

From psadhukhan at openjdk.org  Tue Aug 12 12:35:28 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Aug 2025 12:35:28 GMT
Subject: RFR: 8365375: Method SU3.setAcceleratorSelectionForeground assigns to
 acceleratorForeground
Message-ID: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>

An inadvertent copy-paste error in assignment is fixed

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

Commit messages:
 - 8365375: Method SU3.setAcceleratorSelectionForeground assigns to acceleratorForeground

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

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

From aivanov at openjdk.org  Tue Aug 12 13:23:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 13:23:10 GMT
Subject: RFR: 8365375: Method SU3.setAcceleratorSelectionForeground assigns
 to acceleratorForeground
In-Reply-To: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
References: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
Message-ID: <6HoPwjp4Yptg-Sgw4g_NIlaZvte4FSktnXrEvBFNmcs=.e8bcc779-248c-44c1-b0da-e11cd475e27e@github.com>

On Tue, 12 Aug 2025 12:27:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> An inadvertent copy-paste error in assignment is fixed

Looks good to me.

We should ensure there's a test that covers the usage of `acceleratorSelectionForeground`, I'm fine with handling it separately at a later time.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26743#pullrequestreview-3110587702

From duke at openjdk.org  Tue Aug 12 13:36:20 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 13:36:20 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <jFYbnlg8m2KSmdYdoj1FNmxYPtIGY3arRTwsQ29KHt4=.8b421f04-41fa-4d0f-bd0f-1c7c90c5fa8b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
 <jFYbnlg8m2KSmdYdoj1FNmxYPtIGY3arRTwsQ29KHt4=.8b421f04-41fa-4d0f-bd0f-1c7c90c5fa8b@github.com>
Message-ID: <i2S8Eb0joQoIogQcAAPWmVkGyDo6dwoJ7nYJuz92QgU=.efcf0f0a-faa0-4c4f-9735-366ec4dc5c76@github.com>

On Tue, 12 Aug 2025 09:27:36 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates copyright years
>
> Did you try the reporter solution for the failed test ? - [JDK-8158801](https://bugs.openjdk.org/browse/JDK-8158801)
> _"We should either use a special separate frame to click on to restore focus handling or hazard to use locationOnScreen"_

@TejeshR13 I have not tried exactly as was specified in the reported comment. I have tried first to increase the width of the frames, in which case the click will not land on the minimizing control on the frame, and that worked. @prsadhuk then suggested to request focus from the frame, instead of using the workaround click, and that worked too and that is the solution implemented in PR https://github.com/openjdk/jdk/pull/25971.

I will try to center the frames as per suggested.

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

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

From duke at openjdk.org  Tue Aug 12 13:49:13 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 13:49:13 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
Message-ID: <NhIsKU5JiqdSKFUlbNS0wWSgP05kwgPhCOVoqfUuTfU=.1c5763d5-d0d6-4d00-9a59-584d0e73bb00@github.com>

On Tue, 5 Aug 2025 16:18:41 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
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

The tests in this PR require the the fix from https://github.com/openjdk/jdk/pull/25971 in order for the fix in this PR to work.

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

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

From duke at openjdk.org  Tue Aug 12 14:02:17 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 14:02:17 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
Message-ID: <xgdcnKYPo1og_Dlg3fovnFDgKrScvnXZI_RBGvc2w1E=.1bc36b9a-fe32-47ca-882d-c08f9ec9949e@github.com>

On Tue, 5 Aug 2025 16:18:41 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
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

For test : test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null.

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

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

From aivanov at openjdk.org  Tue Aug 12 14:05:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 14:05:31 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <drGo7OkMCIMLsMKNl1q8vDPvCto9DC_tWEfuZFaeFn0=.63c324a5-283e-4ab9-94e3-69b3ce9bc12b@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <drGo7OkMCIMLsMKNl1q8vDPvCto9DC_tWEfuZFaeFn0=.63c324a5-283e-4ab9-94e3-69b3ce9bc12b@github.com>
Message-ID: <PW-0HB5L1AFEn8KpG1ns39-RcwMkPbT_BxPBHDUVPGM=.31d4ce19-358c-4805-a915-5f1d50323593@github.com>

On Mon, 11 Aug 2025 11:41:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 77:
>> 
>>> 75:     private static Color disabledForeground;
>>> 76:     private static Color acceleratorSelectionForeground;
>>> 77:     private static Color acceleratorForeground;
>> 
>> Why are these static? I'm pretty sure the colors can be menu item specific, although more commonly they would be L&F specific.
>
> Why is this comment marked resolved but not resolved at all?
> 
> You store a local state of a MenuItemUI in a global class ? this cannot be right!

I've submitted [JDK-8365389](https://bugs.openjdk.org/browse/JDK-8365389): *Remove static color fields from SwingUtilities3 and WindowsMenuItemUI* to address all the unresolved comments during this code review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2269964765

From aivanov at openjdk.org  Tue Aug 12 14:19:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 14:19:29 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v29]
In-Reply-To: <a62uXc8zCxOZJeDgygaQYAAdSjH4xkduCoGHThgV7Zk=.5f170579-a7a8-47aa-aa35-a1155c88ba50@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <D0-K2CrWIkemHGHvsXjyVJmltGSxkc1TBeWuq-ThKRo=.a1318ca6-1da7-4664-b98c-76200ea4809d@github.com>
 <nolKf6jbfUMV7LyNLZnb-qAYHF-r92Nz1b3imfX6TSk=.89a3adaf-9d19-4af1-b461-3311cf3e711b@github.com>
 <NcS5x95yjQN3fjuqfcxUV6SUb2JflFlrtJFeSVyJei4=.77d70a37-cb28-4c86-b034-4e5046f22914@github.com>
 <LXcw4xLLjKP8t_RvQisH4SryEGikF1ipcCL1b4BZFNA=.3390a943-7ed4-4515-8cd5-9af645467fca@github.com>
 <HbnxiHGlC-AEE_5K7tCQl-pJlayJTdf6bsBjGqpXBUE=.447a8916-1352-4099-8cac-53300668fd63@github.com>
 <N2B5eGm78HXyKFPjn4MWgP7ev3FH7dnKWIKGiaaW3fk=.68d737f4-47f5-4c37-8e1c-c9ad52cb181b@github.com>
 <su3OWYcag4iPpnDuYRxl70A01nPwpqr4XHtcvlNgqu0=.463bfee6-d022-4f7f-b86b-0d64ca10d23c@github.com>
 <B6wMia5K9zciJNqX7HgJSGtXX1fLzRkKLbIWgkPDkcI=.4b7b4e30-9523-42e0-be9c-bb13085bab4e@github.com>
 <9L99GLEqpvF09UNPO360XXwhHxY1g9gJdmr3baoqFYM=.cab0de6c-9ae9-4908-b046-9ba696eda900@github.com>
 <PW6-y7L-Os38mWiVH_ZKmSfCm8o5ti4l32X
 H7bgjJcA=.1f0b8e56-0d5c-4769-958b-bd33e4148907@github.com>
 <_lke_EHP8a2kSnmVeuV07BC0NnolkelfyDs-qlqUnGI=.e5f41721-3aab-4ff6-b4cf-41071bf4d96a@github.com>
 <a62uXc8zCxOZJeDgygaQYAAdSjH4xkduCoGHThgV7Zk=.5f170579-a7a8-47aa-aa35-a1155c88ba50@github.com>
Message-ID: <oNuxS5TLtljgKxFKvvyVddTXKvMCllT2G23NjFkDvHU=.806ed117-41e3-4164-8f89-1202d64dae98@github.com>

On Tue, 12 Aug 2025 12:21:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> OK, thanks. Let's file a follow-up bug to capture this.
>
>> The formula doesn't look right. Why do you subtract `rect.x` and `rect.y` instead of `insets.left` and `insets.top`?
>> 
>> This would work correctly if both `rect.x` and `rect.y` are zero, but it would give wrong results in other cases.
> 
> I've submitted [JDK-8365379](https://bugs.openjdk.org/browse/JDK-8365379): _SU3.applyInsets may produce wrong results_.

This thread mixes different issues now: `SwingUtilities3.applyInsets` that started this discussion as well as static fields added to `SwingUtilities3` and `WindowsMenuItemUI`.

@prsadhuk @kevinrushforth @prrace

For `SwingUtilities3.applyInsets`, I submitted [JDK-8365379](https://bugs.openjdk.org/browse/JDK-8365379). Prasanta has already started code review for it: #26743.

To clean up the code and get rid of static fields for colors, I submitted [JDK-8365389](https://bugs.openjdk.org/browse/JDK-8365389): *Remove static color fields from SwingUtilities3 and WindowsMenuItemUI*. I added other unresolved comments into this bug such as redundant static methods in `WindowsMenuItemUI`, missing `@Override` annotations. I also included my suggestion for using a new class `sun.swing.MenuItemRenderHelper` (or an existing `sun.swing.MenuItemLayoutHelper`) instead of `SwingUtilities3` for the helper menu rendering methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2270012169

From duke at openjdk.org  Tue Aug 12 14:23:13 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 14:23:13 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
Message-ID: <-aWTad9LvUJQEwx97_UZf-TN61uOodOlGxqN5YiWpdo=.be1734f8-55ad-4f97-94e6-6b6389c6242e@github.com>

On Tue, 5 Aug 2025 16:18:41 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
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

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

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

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

From duke at openjdk.org  Tue Aug 12 14:30:13 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 14:30:13 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
Message-ID: <2uX2oF4yU92L4ZyEiHOu5mYRb_6uAp4k1CRhn8ls09Y=.913a45fe-e20f-48ab-a85c-d34b115e4560@github.com>

On Tue, 5 Aug 2025 16:18:41 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
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

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

As of now, only test java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java and  java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java are not yet fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3179571910
PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3179580275
PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3179587625
PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3179593517

From aivanov at openjdk.org  Tue Aug 12 14:58:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 14:58:14 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
Message-ID: <DacoaFRtCDDjHC8zT38opt0kpyQ5dSsw-gM8NjTF5JA=.89a7743e-f20d-40c9-acab-1d044315c2e3@github.com>

On Tue, 5 Aug 2025 16:18:41 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
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

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

> 116:                 jbutton.setForeground(jbColor);
> 117:                 jbutton.setBackground(jbColor);
> 118:                 jbutton.setOpaque(true);

This should be the default value, I mean Swing components are usually opaque unless it's changed by app developer or look and feel. For example, rounded corners may make the component non-opaque as the background in the rounded corners has to be painted by the parent component.

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

> 175:                 btnLoc = jbutton2.getLocationOnScreen();
> 176:                 c = robot.getPixelColor(btnLoc.x + 5, btnLoc.y + 5);
> 177:                 System.out.println("Color picked for jbutton2: "+c);

Suggestion:

                System.out.println("Color picked for jbutton2: " + c);

Spaces around binary operators.
This applies to other similar cases.

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

> 311:             return true;
> 312:         } else {
> 313:             return Math.abs(color.getRed() - refColor.getRed()) <

The indentation of the first `if` is wrong.

Essentially, this `if` condition can be simplified to


return color.equals(refColor)
       || (Math.abs(color.getRed() - refColor.getRed())
              < COLOR_TOLERANCE_MACOSX
           && Math.abs(color.getGreen() - refColor.getGreen())
              < COLOR_TOLERANCE_MACOSX
           && Math.abs(color.getBlue() - refColor.getBlue())
              < COLOR_TOLERANCE_MACOSX;

There may be a utility method available for colour tolerance which seems quite common for macOS.

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

> 382:             return false;
> 383:         }
> 384:         return true;

Suggestion:

        return !(component == null ||
                (component instanceof java.awt.Scrollbar) ||
                (isMac && (component instanceof java.awt.Button)));

There's no need for the `if` statement, just return the value of the boolean expression. You can propagate the negation into the boolean expression. I suggest using parentheses to group the condition with `isMac` to unambiguously express the intention.

I prefer operators on the wrapped line, this is the way Java Coding Style suggests, and such a way emphasises it's a continuation line rather than a new statement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2270160787
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2270151939
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2270141208
PR Review Comment: https://git.openjdk.org/jdk/pull/26625#discussion_r2270121498

From aivanov at openjdk.org  Tue Aug 12 15:09:24 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 15:09:24 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v18]
In-Reply-To: <DYMGVqk6tz_-rtvl8oEzXzt2MXwWxYH1AExCYZDQIv4=.4c231fd8-08c8-4a63-80e3-f51fd64c7b82@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <DYMGVqk6tz_-rtvl8oEzXzt2MXwWxYH1AExCYZDQIv4=.4c231fd8-08c8-4a63-80e3-f51fd64c7b82@github.com>
Message-ID: <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>

On Wed, 6 Aug 2025 10:27:06 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates CountDownLatch waiting time to one second

Strangely enough, these changes make no difference for me when I run Mixing tests locally. The same number of tests fails with and without this fix. However, it seems to affect the CI.

Additionally, I still see the windows / frames are minimised on Windows. I don't think this is expected, is it? Thus, your previous suggestion for increasing the size of the windows looks reasonable to me.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 140:

> 138:                         }else{
> 139:                             f.requestFocusInWindow();
> 140:                         }

To simplify the code, you can request focus either way. If the component already has focus, requesting focus is a no-op.

Suggestion:

                        if (focusOwner == f) {
                            // frame already had focus
                            latch.countDown();
                        } else {
                            f.requestFocusInWindow();
                        }

Formatting needs tweaking.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 152:

> 150:             try {
> 151:                 boolean await = latch.await(1, TimeUnit.SECONDS);
> 152:                 if (!await) {

Suggestion:

                if (!latch.await(1, TimeUnit.SECONDS)) {

I see no need for the variable.

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 155:

> 153:                     throw new RuntimeException(
> 154:                             "Ancestor frame didn't receive " +
> 155:                                     "focus");

Suggestion:

                    throw new RuntimeException("Ancestor frame didn't receive focus");

I think not wrapping this line improves readability.

test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 169:

> 167:                 throw new RuntimeException("Ancestor frame didn't receive " +
> 168:                         "focus");
> 169:             }

The same comments as for `GlassPaneOverlappingTestBase.java`.

The latch may never release because you don't call its `countDown` method if `ancestor` is `null`. Can `ancestor` be `null`?

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

PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3111232727
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2270174613
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2270182995
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2270179068
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2270192913

From duke at openjdk.org  Tue Aug 12 15:29:19 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 15:29:19 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v6]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <Fx9MXIK-HVlbSreLto76ZqSy4QRNakGx5DIhMJI21q4=.4b9311b5-4c37-4b03-bc90-ad33220503e5@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971

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

  Update test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/ed3707ad..85f9321f

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

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

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

From azvegint at openjdk.org  Tue Aug 12 15:34:13 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 12 Aug 2025 15:34:13 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
Message-ID: <qf_-IM9aUKiUtP0ppp05IMJrdNtO_zjQ44pH-cjMFV0=.687e9947-d32f-4b06-af20-80ad08eb5cec@github.com>

On Tue, 12 Aug 2025 12:00:37 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Skip the test if Color was not GC'ed

test/jdk/java/awt/ColorClass/WeakColorTest.java line 39:

> 37:  * @summary Check that garbage-collecting Color before accelerated painting is complete does not cause artifacts.
> 38:  * @library /test/lib
> 39:  * @run main/othervm -Xms16m -Xmx16m WeakColorTest

I tried 3 different pipelines on Linux:


 * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=false -Dsun.java2d.xrender=false WeakColorTest
 * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=true -Dsun.java2d.xrender=false WeakColorTest
 * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=false -Dsun.java2d.xrender=true WeakColorTest // default


OGL is the only one using the `BufferedContext`.
It passes on SW, and OGL pipelines, the test is skipped on Xrender (the default pipeline).
The results are the same with or without the fix.

As we know that the test is always skipped on Linux on the default pipeline, shouldn't we just just do not run it with ` @requires (os.family != "linux")` to save some CI resources?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2270267348

From duke at openjdk.org  Tue Aug 12 16:05:17 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 16:05:17 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <DacoaFRtCDDjHC8zT38opt0kpyQ5dSsw-gM8NjTF5JA=.89a7743e-f20d-40c9-acab-1d044315c2e3@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
 <DacoaFRtCDDjHC8zT38opt0kpyQ5dSsw-gM8NjTF5JA=.89a7743e-f20d-40c9-acab-1d044315c2e3@github.com>
Message-ID: <_02X24yqAU95_AG7lcnFshN5NBLTFRNPHXtkOknYYZs=.77b7e25f-78a2-4dfc-935a-b4372259fc1c@github.com>

On Tue, 12 Aug 2025 14:50:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates copyright years
>
> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 313:
> 
>> 311:             return true;
>> 312:         } else {
>> 313:             return Math.abs(color.getRed() - refColor.getRed()) <
> 
> The indentation of the first `if` is wrong.
> 
> Essentially, this `if` condition can be simplified to
> 
> 
> return color.equals(refColor)
>        || (Math.abs(color.getRed() - refColor.getRed())
>               < COLOR_TOLERANCE_MACOSX
>            && Math.abs(color.getGreen() - refColor.getGreen())
>               < COLOR_TOLERANCE_MACOSX
>            && Math.abs(color.getBlue() - refColor.getBlue())
>               < COLOR_TOLERANCE_MACOSX;
> 
> There may be a utility method available for colour tolerance which seems quite common for macOS.

I have copied the same method logic in test java.awt.Graphics2D.DrawPrimitivesTest.java

private static boolean isAlmostEqual(Color c1, Color c2) {
        return Math.abs(c1.getRed() - c2.getRed()) < COLOR_TOLERANCE &&
                Math.abs(c1.getGreen() - c2.getGreen()) < COLOR_TOLERANCE &&
                Math.abs(c1.getBlue() - c2.getBlue()) < COLOR_TOLERANCE;

    }

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

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

From prr at openjdk.org  Tue Aug 12 16:05:17 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 16:05:17 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <BsE0A1Rgzp4Tt1oYpTiSu30CGGpdGCMOzUOlkOloCg8=.4f70d8b4-e538-45eb-835f-795530bd3ddc@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
 <df4I7Zp_g11Nn11UwYpH5Uod1MfnhaK8yD65Gsb_ojI=.d924c97d-ffe4-40e7-9e0e-3897f9773a8b@github.com>
 <Ew0_ViObEPL_ixB8i1a6q9O-5YCCaoFGQQ7cf6rvbZ0=.5a9f6997-bc44-4693-bbde-a3a9f337e4e6@github.com>
 <BsE0A1Rgzp4Tt1oYpTiSu30CGGpdGCMOzUOlkOloCg8=.4f70d8b4-e538-45eb-835f-795530bd3ddc@github.com>
Message-ID: <65TlIJbo3JZMaRzKOe_OYR6R5RZFAqRXINO2sqwg8lo=.4025c9dd-f52d-4021-9429-27a7f30f1bb6@github.com>

On Tue, 12 Aug 2025 12:11:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Fixed the assignment..
> 
> This may be an appropriate quick fix at this moment.
> 
> Yet this bug needs fixing in mainline, all the update releases will also be affected as soon as [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) is backported.
> 
I expect, and recommend, that the back ports be based on the JDK 25 version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26717#discussion_r2270429910

From aivanov at openjdk.org  Tue Aug 12 16:15:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 16:15:13 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <65TlIJbo3JZMaRzKOe_OYR6R5RZFAqRXINO2sqwg8lo=.4025c9dd-f52d-4021-9429-27a7f30f1bb6@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
 <df4I7Zp_g11Nn11UwYpH5Uod1MfnhaK8yD65Gsb_ojI=.d924c97d-ffe4-40e7-9e0e-3897f9773a8b@github.com>
 <Ew0_ViObEPL_ixB8i1a6q9O-5YCCaoFGQQ7cf6rvbZ0=.5a9f6997-bc44-4693-bbde-a3a9f337e4e6@github.com>
 <BsE0A1Rgzp4Tt1oYpTiSu30CGGpdGCMOzUOlkOloCg8=.4f70d8b4-e538-45eb-835f-795530bd3ddc@github.com>
 <65TlIJbo3JZMaRzKOe_OYR6R5RZFAqRXINO2sqwg8lo=.4025c9dd-f52d-4021-9429-27a7f30f1bb6@github.com>
Message-ID: <F3lCrjZ6uysW7vc3Wpup7Ji8FenOSctVfvoc1GN_wac=.a29f4d7e-3d45-4d23-bf02-f04753699606@github.com>

On Tue, 12 Aug 2025 16:02:22 GMT, Phil Race <prr at openjdk.org> wrote:

> > > Fixed the assignment..
> > 
> > 
> > This may be an appropriate quick fix at this moment.
> > Yet this bug needs fixing in mainline, all the update releases will also be affected as soon as [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) is backported.
> 
> I expect, and recommend, that the back ports be based on the JDK 25 version.

The backports are nearly done, so it's impossible to add this small fix at this time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26717#discussion_r2270460355

From prr at openjdk.org  Tue Aug 12 16:15:12 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 16:15:12 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <-7aupt_im0UMgAdK62BnBs5N_KYCZFJ0sRu3moj3Kdk=.62bbf119-8e81-4636-ae93-04b44a7a7191@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
 <-7aupt_im0UMgAdK62BnBs5N_KYCZFJ0sRu3moj3Kdk=.62bbf119-8e81-4636-ae93-04b44a7a7191@github.com>
Message-ID: <sQDea2yeJ-NHbwTCgwGeOJ2mhsZsEwQeIJhQ5pwcaeA=.985e66f3-e3d9-4cb7-a7a0-d16340be59eb@github.com>

On Tue, 12 Aug 2025 01:32:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Hi all,
>> 
>>     This pull request contains a backport of commit [e29346db](https://github.com/openjdk/jdk/commit/e29346dbd6328dcadc347a70d8c06ce141efef02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>>     The commit being backported was authored by Prasanta Sadhukhan on 7 Aug 2025 and was reviewed by Phil Race, Alexander Zuev and Abhishek Kumar.
>> 
>>     
>> The issue is a manual JCK test fails due to lack of demarcation between selected and unselected JRadioButtonMenuItem and JCheckboxMenuItem whereby JDK does not draw bullet/checkmark in WIndows 11 if imgage icon is present as the (position) offset to draw them is same as the image icon position.
>> Fix is made to ensure the bullet/checkmark is drawn followed by image icon followed by menu text so that user can distinguish between selected and deselected radiobutton/checkbox menuitem
>> 
>> CI testing and manual conformance test along with SwingSet2 demo testing is ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copy-paste assignment

Whilst a couple of follow on bugs have been filed, which will be fixed in a later release,  SFAIK there is no new functional issue with this fix and it resolves the TCK failure.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26717#pullrequestreview-3111729990

From aivanov at openjdk.org  Tue Aug 12 16:15:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Aug 2025 16:15:12 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <-7aupt_im0UMgAdK62BnBs5N_KYCZFJ0sRu3moj3Kdk=.62bbf119-8e81-4636-ae93-04b44a7a7191@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
 <-7aupt_im0UMgAdK62BnBs5N_KYCZFJ0sRu3moj3Kdk=.62bbf119-8e81-4636-ae93-04b44a7a7191@github.com>
Message-ID: <lsYuWEDFYmUYlAaLH4UiSHgqocIdv4jFlRpG5J2Lunc=.02426f9d-4543-4642-9ce4-f4cea59f46b2@github.com>

On Tue, 12 Aug 2025 01:32:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Hi all,
>> 
>>     This pull request contains a backport of commit [e29346db](https://github.com/openjdk/jdk/commit/e29346dbd6328dcadc347a70d8c06ce141efef02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>>     The commit being backported was authored by Prasanta Sadhukhan on 7 Aug 2025 and was reviewed by Phil Race, Alexander Zuev and Abhishek Kumar.
>> 
>>     
>> The issue is a manual JCK test fails due to lack of demarcation between selected and unselected JRadioButtonMenuItem and JCheckboxMenuItem whereby JDK does not draw bullet/checkmark in WIndows 11 if imgage icon is present as the (position) offset to draw them is same as the image icon position.
>> Fix is made to ensure the bullet/checkmark is drawn followed by image icon followed by menu text so that user can distinguish between selected and deselected radiobutton/checkbox menuitem
>> 
>> CI testing and manual conformance test along with SwingSet2 demo testing is ok
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copy-paste assignment

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26717#pullrequestreview-3111748708

From prr at openjdk.org  Tue Aug 12 16:20:16 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 16:20:16 GMT
Subject: [jdk25] RFR: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2]
In-Reply-To: <F3lCrjZ6uysW7vc3Wpup7Ji8FenOSctVfvoc1GN_wac=.a29f4d7e-3d45-4d23-bf02-f04753699606@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
 <df4I7Zp_g11Nn11UwYpH5Uod1MfnhaK8yD65Gsb_ojI=.d924c97d-ffe4-40e7-9e0e-3897f9773a8b@github.com>
 <Ew0_ViObEPL_ixB8i1a6q9O-5YCCaoFGQQ7cf6rvbZ0=.5a9f6997-bc44-4693-bbde-a3a9f337e4e6@github.com>
 <BsE0A1Rgzp4Tt1oYpTiSu30CGGpdGCMOzUOlkOloCg8=.4f70d8b4-e538-45eb-835f-795530bd3ddc@github.com>
 <65TlIJbo3JZMaRzKOe_OYR6R5RZFAqRXINO2sqwg8lo=.4025c9dd-f52d-4021-9429-27a7f30f1bb6@github.com>
 <F3lCrjZ6uysW7vc3Wpup7Ji8FenOSctVfvoc1GN_wac=.a29f4d7e-3d45-4d23-bf02-f04753699606@github.com>
Message-ID: <lmgjlETVmH0xTkGrGQA6jhe5ri1Dd5JI_madtkUKmQ8=.f36818c6-2a9c-4ef9-84ac-6f41976a4a8e@github.com>

On Tue, 12 Aug 2025 16:10:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > Fixed the assignment..
>>> 
>>> This may be an appropriate quick fix at this moment.
>>> 
>>> Yet this bug needs fixing in mainline, all the update releases will also be affected as soon as [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) is backported.
>>> 
>> I expect, and recommend, that the back ports be based on the JDK 25 version.
>
>> > > Fixed the assignment..
>> > 
>> > 
>> > This may be an appropriate quick fix at this moment.
>> > Yet this bug needs fixing in mainline, all the update releases will also be affected as soon as [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) is backported.
>> 
>> I expect, and recommend, that the back ports be based on the JDK 25 version.
> 
> The backports are nearly done, so it's impossible to add this small fix at this time.

Well they'll have to be re-done. That's life.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26717#discussion_r2270477885

From duke at openjdk.org  Tue Aug 12 16:37:16 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 16:37:16 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <DacoaFRtCDDjHC8zT38opt0kpyQ5dSsw-gM8NjTF5JA=.89a7743e-f20d-40c9-acab-1d044315c2e3@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
 <DacoaFRtCDDjHC8zT38opt0kpyQ5dSsw-gM8NjTF5JA=.89a7743e-f20d-40c9-acab-1d044315c2e3@github.com>
Message-ID: <X1kurmZo66oXXZXar9ggn9ylNSpDbZZB64nECnDftUk=.e79b97a5-fdab-45ba-9668-8aec963e5f73@github.com>

On Tue, 12 Aug 2025 14:54:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates copyright years
>
> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 118:
> 
>> 116:                 jbutton.setForeground(jbColor);
>> 117:                 jbutton.setBackground(jbColor);
>> 118:                 jbutton.setOpaque(true);
> 
> This should be the default value, I mean Swing components are usually opaque unless it's changed by app developer or look and feel. For example, rounded corners may make the component non-opaque as the background in the rounded corners has to be painted by the parent component.

I have removed the additional setOpaque code. I am doing the necessary tests.

> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 177:
> 
>> 175:                 btnLoc = jbutton2.getLocationOnScreen();
>> 176:                 c = robot.getPixelColor(btnLoc.x + 5, btnLoc.y + 5);
>> 177:                 System.out.println("Color picked for jbutton2: "+c);
> 
> Suggestion:
> 
>                 System.out.println("Color picked for jbutton2: " + c);
> 
> Spaces around binary operators.
> This applies to other similar cases.

I have gone through the test and added spaces around binary operators.

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

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

From duke at openjdk.org  Tue Aug 12 16:37:18 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 12 Aug 2025 16:37:18 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <_02X24yqAU95_AG7lcnFshN5NBLTFRNPHXtkOknYYZs=.77b7e25f-78a2-4dfc-935a-b4372259fc1c@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
 <DacoaFRtCDDjHC8zT38opt0kpyQ5dSsw-gM8NjTF5JA=.89a7743e-f20d-40c9-acab-1d044315c2e3@github.com>
 <_02X24yqAU95_AG7lcnFshN5NBLTFRNPHXtkOknYYZs=.77b7e25f-78a2-4dfc-935a-b4372259fc1c@github.com>
Message-ID: <Cz5I-gThjA43HnxjZMdig58SjbQUVir4Tr32HJ62sPs=.3cd26431-0210-4cf8-9060-5bd8f479b53f@github.com>

On Tue, 12 Aug 2025 16:02:28 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 313:
>> 
>>> 311:             return true;
>>> 312:         } else {
>>> 313:             return Math.abs(color.getRed() - refColor.getRed()) <
>> 
>> The indentation of the first `if` is wrong.
>> 
>> Essentially, this `if` condition can be simplified to
>> 
>> 
>> return color.equals(refColor)
>>        || (Math.abs(color.getRed() - refColor.getRed())
>>               < COLOR_TOLERANCE_MACOSX
>>            && Math.abs(color.getGreen() - refColor.getGreen())
>>               < COLOR_TOLERANCE_MACOSX
>>            && Math.abs(color.getBlue() - refColor.getBlue())
>>               < COLOR_TOLERANCE_MACOSX;
>> 
>> There may be a utility method available for colour tolerance which seems quite common for macOS.
>
> I have copied the same method logic in test java.awt.Graphics2D.DrawPrimitivesTest.java
> 
> private static boolean isAlmostEqual(Color c1, Color c2) {
>         return Math.abs(c1.getRed() - c2.getRed()) < COLOR_TOLERANCE &&
>                 Math.abs(c1.getGreen() - c2.getGreen()) < COLOR_TOLERANCE &&
>                 Math.abs(c1.getBlue() - c2.getBlue()) < COLOR_TOLERANCE;
> 
>     }

I updated the method implementation as suggested.

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

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

From serb at openjdk.org  Tue Aug 12 17:02:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 12 Aug 2025 17:02:05 GMT
Subject: RFR: 8359380: Rework deferral profile logic after JDK-8346465 [v2]
In-Reply-To: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
References: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
Message-ID: <cFo51vQS_kr0DKPW3eqIbRkTx03pQXaHepaW3J6rc8A=.a938c555-29b2-433b-9c65-0051a036214c@github.com>

> The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
> 
> After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
> 
> This patch includes two changes:
> 
> 1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
> 
> 2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

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

 - Merge branch 'openjdk:master' into JDK-8359380
 - pdi->bpi
 - Update workaround for 8272860
 - 8359380: Rework deferral profile logic after JDK-8346465

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26179/files
  - new: https://git.openjdk.org/jdk/pull/26179/files/4278a0b8..78ba5480

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

  Stats: 70147 lines in 1733 files changed: 40336 ins; 20434 del; 9377 mod
  Patch: https://git.openjdk.org/jdk/pull/26179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26179/head:pull/26179

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

From lkorinth at openjdk.org  Tue Aug 12 17:09:32 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Aug 2025 17:09:32 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
Message-ID: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>

This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).

My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have ploughed through test cases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

After the review, I will update the copyrights.

I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

I got 4 timing related faults:
1) runtime/Thread/TestThreadDumpMonitorContention.java
   This is probably: https://bugs.openjdk.org/browse/JDK-8361370
2) sun/tools/jhsdb/BasicLauncherTest.java
   I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
3) gc/stress/TestReclaimStringsLeaksMemory.java
   I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
4) sun/security/ssl/X509KeyManager/CertChecking.java
   This is a new test that I got on last rebase. I have added a timeout of 480 to it.

In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.

>From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of default timeout factor", I have taken a few actions:
1) in testing(md|html): interpreted mode -> forced compilation mode
2) in MTTest.java: changed 1200 -> 400 (was 300 to begin with)

I am now re-running tier 1-8.

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

Commit messages:
 - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1

Changes: https://git.openjdk.org/jdk/pull/26749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8260555
  Stats: 598 lines in 297 files changed: 49 ins; 91 del; 458 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

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

From ngubarkov at openjdk.org  Tue Aug 12 17:16:12 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Tue, 12 Aug 2025 17:16:12 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <qf_-IM9aUKiUtP0ppp05IMJrdNtO_zjQ44pH-cjMFV0=.687e9947-d32f-4b06-af20-80ad08eb5cec@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
 <qf_-IM9aUKiUtP0ppp05IMJrdNtO_zjQ44pH-cjMFV0=.687e9947-d32f-4b06-af20-80ad08eb5cec@github.com>
Message-ID: <17Fu4o7q3ZeX--MA67kBHwob9uEwZZszm1cc4FJtCS8=.1cdbf2ce-3865-4c17-8ff3-5670b8c42c34@github.com>

On Tue, 12 Aug 2025 15:25:03 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364434: Inconsistent BufferedContext state after GC
>>   
>>   Skip the test if Color was not GC'ed
>
> test/jdk/java/awt/ColorClass/WeakColorTest.java line 39:
> 
>> 37:  * @summary Check that garbage-collecting Color before accelerated painting is complete does not cause artifacts.
>> 38:  * @library /test/lib
>> 39:  * @run main/othervm -Xms16m -Xmx16m WeakColorTest
> 
> I tried 3 different pipelines on Linux:
> 
> 
>  * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=false -Dsun.java2d.xrender=false WeakColorTest
>  * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=true -Dsun.java2d.xrender=false WeakColorTest
>  * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=false -Dsun.java2d.xrender=true WeakColorTest // default
> 
> 
> OGL is the only one using the `BufferedContext`.
> It passes on SW, and OGL pipelines, the test is skipped on Xrender (the default pipeline).
> The results are the same with or without the fix.
> 
> As we know that the test is always skipped on Linux on the default pipeline, shouldn't we just just do not run it with ` @requires (os.family != "linux")` to save some CI resources?

Although the issues are theoretically possible on any platform when using `BufferedContext`, in practice it is only known to reproduce on Metal.
So if we consider only known scenarios, we could as well limit it to macOS. If we consider a theoretical regression scenario, having it on every platform could also be helpful (but not with default XRender mode on Linux of course).
But having a non-accelerated pipeline on Linux by default may not be permanent either - when we finish our ongoing Vulkan work under Wakefield, we could eventually make it default. So maybe just leave it for all platforms, wdyt?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2270598793

From psadhukhan at openjdk.org  Tue Aug 12 17:18:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 12 Aug 2025 17:18:25 GMT
Subject: [jdk25] Integrated: 8348760: RadioButton is not shown if
 JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel
In-Reply-To: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
References: <bAomLoKa5l0JVblZgOrcNaFznSk4rHiyDEyWDNOxx9I=.c8ca33a1-0de7-4bd8-b4df-5bf86af5e82e@github.com>
Message-ID: <ae7iR91jHHE8hn_r_gCpfjUSe5txMLXuIP_enPWftUs=.c1382f25-3c10-4378-afd0-18f032463e25@github.com>

On Sun, 10 Aug 2025 12:58:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [e29346db](https://github.com/openjdk/jdk/commit/e29346dbd6328dcadc347a70d8c06ce141efef02) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Prasanta Sadhukhan on 7 Aug 2025 and was reviewed by Phil Race, Alexander Zuev and Abhishek Kumar.
> 
>     
> The issue is a manual JCK test fails due to lack of demarcation between selected and unselected JRadioButtonMenuItem and JCheckboxMenuItem whereby JDK does not draw bullet/checkmark in WIndows 11 if imgage icon is present as the (position) offset to draw them is same as the image icon position.
> Fix is made to ensure the bullet/checkmark is drawn followed by image icon followed by menu text so that user can distinguish between selected and deselected radiobutton/checkbox menuitem
> 
> CI testing and manual conformance test along with SwingSet2 demo testing is ok

This pull request has now been integrated.

Changeset: 6c48f4ed
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c48f4ed707bf0b15f9b6098de30db8aae6fa40f
Stats:     630 lines in 8 files changed: 524 ins; 81 del; 25 mod

8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel

Reviewed-by: prr, aivanov
Backport-of: e29346dbd6328dcadc347a70d8c06ce141efef02

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

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

From cjplummer at openjdk.org  Tue Aug 12 17:54:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 12 Aug 2025 17:54:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> sun/tools/jhsdb/BasicLauncherTest.java
> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.

@lkorinth Can you send me a link to the failure?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3180396310

From prr at openjdk.org  Tue Aug 12 18:48:17 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 18:48:17 GMT
Subject: RFR: 8365375: Method SU3.setAcceleratorSelectionForeground assigns
 to acceleratorForeground
In-Reply-To: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
References: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
Message-ID: <gu5uECTgBf7cGhPy5w8WO3d5tBuuNDI4XwnxBqAPpbI=.e0317bc2-a2dc-4996-b371-ec72ac261ce6@github.com>

On Tue, 12 Aug 2025 12:27:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> An inadvertent copy-paste error in assignment is fixed

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26743#pullrequestreview-3112262553

From prr at openjdk.org  Tue Aug 12 19:03:23 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 19:03:23 GMT
Subject: RFR: 8365291: Remove finalize() method from
 sun/awt/X11InputMethodBase.java
Message-ID: <J3t1-jbi_CredJ0loBE8VNLFY2K9kHSrP9EcIBYa_LA=.0c42d59d-c6ed-4ad6-9c9a-d55df747daf0@github.com>

It seems that finalize() in X11InputMethodBase.java isn't useful.
It calls dispose(), which in all actual implementations has just one native resource to release, which
is a native struct of type X11InputMethodData (this is a JDK-defined struct, not one from Xim),
and one of the fields is a JNI GlobalRef pointing to the XInputMethod instance which implements the dispose() method.
So finalize cannot be called unless dispose() is called first. But if dispose() has been called then there's no need for
finalize() since all it does is call dispose()

Many more details in JBS.

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

Commit messages:
 - 8365291

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

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

From prr at openjdk.org  Tue Aug 12 19:39:32 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 19:39:32 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
Message-ID: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>

Remove javax.imageio.spi.ServiceRegistry.finalize() since it is deprecated for removal.
The impact of this should be minimal. The IIORegistry will now be a singleton - which it already was 
in practice since Applets are no longer supported. Since it is a singleton, it will persist for the life
of the VM, so will never be garbage collected.
A test that verifies one per-AppContext is now obsolete, and is deleted, and there's no good reason to make it a negative test, since in due course AppContext itself will be deleted and is un-used today except in tests.

Since JDK 9, ServiceRegistry has supported only Image I/O specified providers, and since the IIORegistry does this,
in practice there is very little reason for an application to create instances or subclasses of it.
And even if they do, typically like IIORegistry, they be used for the life time of the application.
And if they are collected, without calling ServiceRegistry.deregisterAll() there may be no impact,
since only providers that implement RegisterableService will be affected.

See the JBS issue for all the details.

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

Commit messages:
 - 8365292
 - 8365292

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

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

From prr at openjdk.org  Tue Aug 12 19:39:32 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 19:39:32 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
In-Reply-To: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
Message-ID: <J0QqtaSJSToP8NSsQzfL5NUeLMv9krqYbat0_ROJcYc=.53feede9-f051-4e07-943b-5417f21114f2@github.com>

On Tue, 12 Aug 2025 19:32:33 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove javax.imageio.spi.ServiceRegistry.finalize() since it is deprecated for removal.
> The impact of this should be minimal. The IIORegistry will now be a singleton - which it already was 
> in practice since Applets are no longer supported. Since it is a singleton, it will persist for the life
> of the VM, so will never be garbage collected.
> A test that verifies one per-AppContext is now obsolete, and is deleted, and there's no good reason to make it a negative test, since in due course AppContext itself will be deleted and is un-used today except in tests.
> 
> Since JDK 9, ServiceRegistry has supported only Image I/O specified providers, and since the IIORegistry does this,
> in practice there is very little reason for an application to create instances or subclasses of it.
> And even if they do, typically like IIORegistry, they be used for the life time of the application.
> And if they are collected, without calling ServiceRegistry.deregisterAll() there may be no impact,
> since only providers that implement RegisterableService will be affected.
> 
> See the JBS issue for all the details.

src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 82:

> 80:  * <p> An application may customize the contents of a registry as it
> 81:  * sees fit.
> 82:  *

Removing the above text is not related to finalization, but the text is meaningless since the SecurityManager was permanently disabled, so I will take this opportunity to remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26752#discussion_r2270981436

From serb at openjdk.org  Tue Aug 12 19:45:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 12 Aug 2025 19:45:20 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <4EF17yjfvyOmHJFAuVDzC2qG3UuJEyOGO4ZJRhKQz9A=.6c301779-593e-4866-a566-b3b95d4fd214@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
 <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
 <4EF17yjfvyOmHJFAuVDzC2qG3UuJEyOGO4ZJRhKQz9A=.6c301779-593e-4866-a566-b3b95d4fd214@github.com>
Message-ID: <uxwx_Mm6kXeVDsj7sE73YGkZgGKqojmbD4FT7gIBtYE=.69a9b759-c7ed-4559-b839-24c3954319fb@github.com>

On Tue, 22 Jul 2025 05:03:23 GMT, Phil Race <prr at openjdk.org> wrote:

>What does that mean ?

>CFRetainedResource is extended by a lot of classes and it is hard to figure out how correctly it is used.
>I would take a big step back and look before extending what it does.

That code in CFRetainedResource handle the case when the native resource was cleared by the finalizer or directly via dispose method, and after that it is impossible to use the broken native ptr. And at the same time while the native pointer is in use it is impossible to dispose the native resource.

For example the similar issue exists in getHitForPoint. It reads cfDictionaryPtr and then passes it to native code. But it is possible that the object becomes unreachable at some point(during getHitForPoint execution), resulting in a broken pointer being passed to native code, which could lead to a crash. To prevent this, we can either add a reachabilityFence at the end of getHitForPoint, or use an approach similar to CFRetainedResource, ensuring that all usage of the native pointer is properly guarded.

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

PR Comment: https://git.openjdk.org/jdk/pull/26331#issuecomment-3180770974

From prr at openjdk.org  Tue Aug 12 20:51:23 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Aug 2025 20:51:23 GMT
Subject: RFR: 8365198: Remove unnecessary mention of finalize in ImageIO
 reader/writer docs
Message-ID: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>

Image I/O's ImageReader and ImageWriter have never had finalize() methods, yet have a gratuitous mention of finalize(). This should be removed. Simple doc only change

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

Commit messages:
 - 8365198

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

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

From serb at openjdk.org  Wed Aug 13 00:04:15 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 13 Aug 2025 00:04:15 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
 <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>
Message-ID: <GyUocUiru5Uc_-oPkDqkgnnuDk-E6yYIqMpm_YxueFs=.89a1ffb3-b75e-44f3-83a1-ededd985b5c8@github.com>

On Wed, 23 Jul 2025 19:44:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>I think the specification for the index parameter ? ?an index within the text? ? is vague, it's open to interpretation.
>We should make it specific. For example, is 0 within the text? It's not within, it's right before.

I'm not sure I agree with this argument. The indexes mentioned in all these specs are character indexes. Index 0 refers to the first character in the text, and the last valid index is length - 1. I think some confusion arises from misinterpreting the "index within the text" in the spec and the caret position returned by getCaretPosition. As specified, the caret position is ?the zero-based offset of the caret? and it is located between characters. So this value cannot be used directly as a character index in other methods.

> I said it a few times now, ?an index within the text? is a vague condition, we should update the specification so that it is clear which indexes are valid.

The phrase ?an index within the text? appears around 30 times in the spec, and all the relevant methods are implemented consistently to support the index range [0, length - 1]. We could clarify the wording, but why change it to allow character positions outside the text?

>I agree with @azuev-java here, we should focus on the purpose of the API and how this API is supposed to be used.

The proposed change would make all existing subclasses, including custom ones, non-compliant with the spec. For example, our own JPasswordField would no longer behave as specified.

What exactly are we trying to fix here? What is the issue that cannot be addressed by using the correct methods for the first or last character positions?

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3181607843

From syan at openjdk.org  Wed Aug 13 01:50:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:50:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Should we need to update the copyright year for the touch files

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271883564

From achung at openjdk.org  Wed Aug 13 01:53:34 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 13 Aug 2025 01:53:34 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v34]
In-Reply-To: <_8bZ8L-mcOxu11bs0I1sa3_Q6yXVFkQUDIqIYNoLk-8=.e5b535c6-c4e9-46ad-b33f-4401ae9959af@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <_8bZ8L-mcOxu11bs0I1sa3_Q6yXVFkQUDIqIYNoLk-8=.e5b535c6-c4e9-46ad-b33f-4401ae9959af@github.com>
Message-ID: <f9cJzWMdBaCXDzweS2fPutlDAktTLXjWF8Fc4J23yac=.fee55892-bf6c-4a7a-8b88-bf6dc480b6ab@github.com>

On Tue, 12 Aug 2025 01:34:56 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dragAndDrop readded to ExtendedRobot

I've decided to revert the migration of dragAndDrop. I think not enough tests are using it so I will replace it with mousePress + glide when I remove ExtendedRobot. I am currently fixing the remaining tests that have had ExtendedRobot removed from them.

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

PR Comment: https://git.openjdk.org/jdk/pull/22044#issuecomment-3181926119

From syan at openjdk.org  Wed Aug 13 01:54:16 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 13 Aug 2025 01:54:16 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:

> 27:  * @requires vm.debug
> 28:  * @summary Test running with StressRecompilation enabled.
> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation

I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.


> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
55:elapsed time (seconds): 0.581
66:elapsed time (seconds): 0.575
116:elapsed time (seconds): 3.088
162:elapsed time (seconds): 0.001
173:elapsed time (seconds): 11.546

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2271888024

From kizune at openjdk.org  Wed Aug 13 04:25:09 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 13 Aug 2025 04:25:09 GMT
Subject: RFR: 8365375: Method SU3.setAcceleratorSelectionForeground assigns
 to acceleratorForeground
In-Reply-To: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
References: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
Message-ID: <pS3EGAQ014ApsQH2he_9BWI_MceDjYIZmdh_e_1_4SY=.e9708293-c497-4c5e-8619-029dbe3c73bf@github.com>

On Tue, 12 Aug 2025 12:27:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> An inadvertent copy-paste error in assignment is fixed

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26743#pullrequestreview-3113879846

From rgupta at openjdk.org  Wed Aug 13 04:54:17 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Wed, 13 Aug 2025 04:54:17 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v6]
In-Reply-To: <VE8hrTOgcy2nqrvKMKf_reVqsSKvsNX-Tbm2bLONPTo=.bf382a21-1e57-489d-9398-429ea0abb4e5@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <chMDIBRzIshsf1RR9yTEFsrDoN0mxk76BdG8GsweGxk=.a6836859-e861-4e21-ae87-f16aeb6a52fa@github.com>
 <VE8hrTOgcy2nqrvKMKf_reVqsSKvsNX-Tbm2bLONPTo=.bf382a21-1e57-489d-9398-429ea0abb4e5@github.com>
Message-ID: <PaSA1LCNzhZI_LHg3BZOGSQUGWT1U2kHE8DbaEObwaw=.f3521133-b4dc-4fc4-a745-1ebe2a4c36f0@github.com>

On Thu, 31 Jul 2025 20:16:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361067: Review Comments fix
>
> Marked as reviewed by prr (Reviewer).

@prrace requesting you to please re-review the changes

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

PR Comment: https://git.openjdk.org/jdk/pull/26043#issuecomment-3182168928

From tr at openjdk.org  Wed Aug 13 07:11:11 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 13 Aug 2025 07:11:11 GMT
Subject: RFR: 8365291: Remove finalize() method from
 sun/awt/X11InputMethodBase.java
In-Reply-To: <J3t1-jbi_CredJ0loBE8VNLFY2K9kHSrP9EcIBYa_LA=.0c42d59d-c6ed-4ad6-9c9a-d55df747daf0@github.com>
References: <J3t1-jbi_CredJ0loBE8VNLFY2K9kHSrP9EcIBYa_LA=.0c42d59d-c6ed-4ad6-9c9a-d55df747daf0@github.com>
Message-ID: <iDLXMbxdDdslIJup3WFUVRifx8E-8WBG8x4-zurvC64=.ca30d035-29f8-4d56-804a-b0e303ee46c0@github.com>

On Tue, 12 Aug 2025 18:56:56 GMT, Phil Race <prr at openjdk.org> wrote:

> It seems that finalize() in X11InputMethodBase.java isn't useful.
> It calls dispose(), which in all actual implementations has just one native resource to release, which
> is a native struct of type X11InputMethodData (this is a JDK-defined struct, not one from Xim),
> and one of the fields is a JNI GlobalRef pointing to the XInputMethod instance which implements the dispose() method.
> So finalize cannot be called unless dispose() is called first. But if dispose() has been called then there's no need for
> finalize() since all it does is call dispose()
> 
> Many more details in JBS.

LGTM.

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26751#pullrequestreview-3114213540

From tr at openjdk.org  Wed Aug 13 07:16:09 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 13 Aug 2025 07:16:09 GMT
Subject: RFR: 8365291: Remove finalize() method from
 sun/awt/X11InputMethodBase.java
In-Reply-To: <J3t1-jbi_CredJ0loBE8VNLFY2K9kHSrP9EcIBYa_LA=.0c42d59d-c6ed-4ad6-9c9a-d55df747daf0@github.com>
References: <J3t1-jbi_CredJ0loBE8VNLFY2K9kHSrP9EcIBYa_LA=.0c42d59d-c6ed-4ad6-9c9a-d55df747daf0@github.com>
Message-ID: <ZFPNDeCaXLyo7S1j57guMws3_06RNVmja3gXGrSOJO0=.37cdff0b-3a84-4793-b83c-1cceea80141f@github.com>

On Tue, 12 Aug 2025 18:56:56 GMT, Phil Race <prr at openjdk.org> wrote:

> It seems that finalize() in X11InputMethodBase.java isn't useful.
> It calls dispose(), which in all actual implementations has just one native resource to release, which
> is a native struct of type X11InputMethodData (this is a JDK-defined struct, not one from Xim),
> and one of the fields is a JNI GlobalRef pointing to the XInputMethod instance which implements the dispose() method.
> So finalize cannot be called unless dispose() is called first. But if dispose() has been called then there's no need for
> finalize() since all it does is call dispose()
> 
> Many more details in JBS.

Minor one, have to update copyright.

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

PR Review: https://git.openjdk.org/jdk/pull/26751#pullrequestreview-3114226084

From tr at openjdk.org  Wed Aug 13 07:22:13 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 13 Aug 2025 07:22:13 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <xgdcnKYPo1og_Dlg3fovnFDgKrScvnXZI_RBGvc2w1E=.1bc36b9a-fe32-47ca-882d-c08f9ec9949e@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
 <xgdcnKYPo1og_Dlg3fovnFDgKrScvnXZI_RBGvc2w1E=.1bc36b9a-fe32-47ca-882d-c08f9ec9949e@github.com>
Message-ID: <gLBBk99DPImntxpjtofnc7SPLn-Rm6g4Fdl48QvV2n4=.df2e1a79-e16f-4372-979d-fa522041911b@github.com>

On Tue, 12 Aug 2025 14:00:00 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

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

I actually meant to put this in PR descriptions.

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

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

From sspitsyn at openjdk.org  Wed Aug 13 07:29:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 13 Aug 2025 07:29:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

I've reviewed the Serviceability related tweaks and I'm okay with them in general.
But I'm curious if you do not see any timeouts with this anymore.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3114280042

From duke at openjdk.org  Wed Aug 13 08:07:13 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 13 Aug 2025 08:07:13 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v6]
In-Reply-To: <gLBBk99DPImntxpjtofnc7SPLn-Rm6g4Fdl48QvV2n4=.df2e1a79-e16f-4372-979d-fa522041911b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
 <xgdcnKYPo1og_Dlg3fovnFDgKrScvnXZI_RBGvc2w1E=.1bc36b9a-fe32-47ca-882d-c08f9ec9949e@github.com>
 <gLBBk99DPImntxpjtofnc7SPLn-Rm6g4Fdl48QvV2n4=.df2e1a79-e16f-4372-979d-fa522041911b@github.com>
Message-ID: <zlLjbE-vJIZguvs1NxyhzMPaQOW7FzG2ldVmkVQ2ywU=.2729ed5c-9a44-460d-b5b3-d62263a0dbf5@github.com>

On Wed, 13 Aug 2025 07:19:51 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
>> 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)
> 
> I actually meant to put this in PR descriptions.

@TejeshR13 Comments on fixes moved to description, as requested.

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

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

From aturbanov at openjdk.org  Wed Aug 13 09:47:17 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Aug 2025 09:47:17 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

test/langtools/tools/lib/toolbox/ToolBox.java line 480:

> 478: 
> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;

Suggestion:

    private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2272745651

From jdv at openjdk.org  Wed Aug 13 09:57:12 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 13 Aug 2025 09:57:12 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
Message-ID: <jZ_TsZwB3tb37nADN_t35DjOXLWxuRV_5XznSLflrDM=.b950611c-7104-4290-881a-65a46cdb737c@github.com>

On Tue, 12 Aug 2025 12:00:37 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Skip the test if Color was not GC'ed

Test running on all platforms looks good to me.
I have given CI run, if it is green will approve the PR.

Also lets wait for input from @azvegint

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3183079868

From jdv at openjdk.org  Wed Aug 13 13:01:15 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 13 Aug 2025 13:01:15 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
Message-ID: <FBsqHZ0nnG9pvASz2JEKElbwcIgZrw7mcyhMACpBAZU=.85fa2ce2-1cb9-4aa3-9362-c451d0f3f5f4@github.com>

On Tue, 12 Aug 2025 12:00:37 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Skip the test if Color was not GC'ed

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26576#pullrequestreview-3115910517

From lkorinth at openjdk.org  Wed Aug 13 13:09:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:09:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <BfK-uggqI4qHVGLtaqxYB0RChDB0EzlAXlSi2Fqh-Os=.8c4c6e22-d1b7-4721-a408-6db52951a961@github.com>
Message-ID: <RA6T2Udma4QM1EdTUlZ9Y4l6Wo1783yEKYgOPy8UOZY=.7938ce78-45a5-4607-9298-72cf19436662@github.com>

On Wed, 13 Aug 2025 01:47:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c1/TestPinnedIntrinsics.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Should we need to update the copyright year for the touched files

`After the review, I will update the copyrights.`

It is IMO easier to review big changes without the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273410872

From lkorinth at openjdk.org  Wed Aug 13 13:21:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:21:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <ZBnkZKNhKRIYibXTkR2lX6EcVxkHCCgT24V9E0jdJGM=.2bd5baa7-2322-4629-9140-05dddb50100d@github.com>
Message-ID: <4q0047gChugbkkv-W0lis2E8nXVWh8YGVJiBehoojLY=.0b9055a2-f038-4247-82a9-7c60ee9f6637@github.com>

On Tue, 12 Aug 2025 17:52:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > sun/tools/jhsdb/BasicLauncherTest.java
> > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 
> @lkorinth Can you send me a link to the failure?

I sent it to you on email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3183896453

From lbourges at openjdk.org  Wed Aug 13 13:27:13 2025
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 13 Aug 2025 13:27:13 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
Message-ID: <TCxGCiqxMLPUjZrocMcGjTeB6NZIjTm46GZPlLjn46U=.4cdd62ce-13f7-473a-a076-513dfce71a53@github.com>

On Tue, 12 Aug 2025 12:00:37 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Skip the test if Color was not GC'ed

LGTM on final state

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3183914641

From erikj at openjdk.org  Wed Aug 13 13:28:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 13 Aug 2025 13:28:18 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>

On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

make/RunTests.gmk line 939:

> 937: 
> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.

I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273468852

From lkorinth at openjdk.org  Wed Aug 13 13:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T4-fRuHtZ8JR3eehN_gCesgy7fbMS-r8Oh0Z-UCFDJs=.7e0c2ce5-6bc5-4f55-bd87-47f4c595d54b@github.com>
Message-ID: <jX2ocV7Rf3mYq7TYfPkxKQfgucnVdhEDYMB91LwhTtI=.8810fb03-295c-4be5-9771-d7e031390002@github.com>

On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29:
> 
>> 27:  * @requires vm.debug
>> 28:  * @summary Test running with StressRecompilation enabled.
>> 29:  * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions -XX:+StressRecompilation
> 
> I think the default value(120s) will be enough? On my machine this test use 11.546 senonds to finish.
> 
> 
>> grep "elapsed time" tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn
> 55:elapsed time (seconds): 0.581
> 66:elapsed time (seconds): 0.575
> 116:elapsed time (seconds): 3.088
> 162:elapsed time (seconds): 0.001
> 173:elapsed time (seconds): 11.546

I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236

From azvegint at openjdk.org  Wed Aug 13 13:52:12 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 13 Aug 2025 13:52:12 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <17Fu4o7q3ZeX--MA67kBHwob9uEwZZszm1cc4FJtCS8=.1cdbf2ce-3865-4c17-8ff3-5670b8c42c34@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
 <qf_-IM9aUKiUtP0ppp05IMJrdNtO_zjQ44pH-cjMFV0=.687e9947-d32f-4b06-af20-80ad08eb5cec@github.com>
 <17Fu4o7q3ZeX--MA67kBHwob9uEwZZszm1cc4FJtCS8=.1cdbf2ce-3865-4c17-8ff3-5670b8c42c34@github.com>
Message-ID: <7kit18cvNcAxDjfM1vDs8bZgOeEgaabBTsfCYNngp4c=.1d262dd8-5b7c-40f9-b839-b39c7645bf04@github.com>

On Tue, 12 Aug 2025 17:13:42 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> test/jdk/java/awt/ColorClass/WeakColorTest.java line 39:
>> 
>>> 37:  * @summary Check that garbage-collecting Color before accelerated painting is complete does not cause artifacts.
>>> 38:  * @library /test/lib
>>> 39:  * @run main/othervm -Xms16m -Xmx16m WeakColorTest
>> 
>> I tried 3 different pipelines on Linux:
>> 
>> 
>>  * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=false -Dsun.java2d.xrender=false WeakColorTest
>>  * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=true -Dsun.java2d.xrender=false WeakColorTest
>>  * @run main/othervm -Xms16m -Xmx16m -Dsun.java2d.opengl=false -Dsun.java2d.xrender=true WeakColorTest // default
>> 
>> 
>> OGL is the only one using the `BufferedContext`.
>> It passes on SW, and OGL pipelines, the test is skipped on Xrender (the default pipeline).
>> The results are the same with or without the fix.
>> 
>> As we know that the test is always skipped on Linux on the default pipeline, shouldn't we just just do not run it with ` @requires (os.family != "linux")` to save some CI resources?
>
> Although the issues are theoretically possible on any platform when using `BufferedContext`, in practice it is only known to reproduce on Metal.
> So if we consider only known scenarios, we could as well limit it to macOS. If we consider a theoretical regression scenario, having it on every platform could also be helpful (but not with default XRender mode on Linux of course).
> But having a non-accelerated pipeline on Linux by default may not be permanent either - when we finish our ongoing Vulkan work under Wakefield, we could eventually make it default. So maybe just leave it for all platforms, wdyt?

I am not opposed to running the test on all platforms.
Windows and Mac work well, but in the case of Linux and XRender, at this point, we know for certain that the test is not useful and will simply waste 5-15 seconds of CI time on each build.

We can file an issue for Linux to enable the test back on it when we switch to Vulkan (and investigate the XRender case).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2273539244

From lkorinth at openjdk.org  Wed Aug 13 13:53:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 13:53:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
In-Reply-To: <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <m1WHOMUNXCFm7XINWDDGrAskIxel7VMdPlAsqwTKDTw=.82f5a8d1-847f-41f2-b047-d6735e175787@github.com>
Message-ID: <5nc1SBXnwAOJJvnrbMyPIsre61u--GxMHSffdDf8qUU=.77100025-4b9e-4e0a-b71d-df590df5f9ba@github.com>

On Wed, 13 Aug 2025 07:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the Serviceability related tweaks and I'm okay with them in general. But I'm curious if you do not see any timeouts with this anymore.

I only got the four timeouts described in the description, I got a few other failures as well that was not timeout related. I sent you a link to the test results in an email.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3184026177

From lkorinth at openjdk.org  Wed Aug 13 14:22:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:08 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  After suggestions from Erik and Andrey

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/ac47dbdc..dbe42964

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

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

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

From lkorinth at openjdk.org  Wed Aug 13 14:22:10 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:10 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <h_5kX673tkQPkzdAhgrbjwkfXtKCRgHjVDf3AA2jwaA=.f320c583-5c56-4dae-a0f7-356529e3e134@github.com>
Message-ID: <imd2i-VIlFCbEytLUZDyy_1SEU8ebK39Eif8JbdQsTU=.fefa1e8d-027b-445d-be69-07f6c6a475fd@github.com>

On Wed, 13 Aug 2025 13:25:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> make/RunTests.gmk line 939:
> 
>> 937: 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   JTREG_AUTO_TIMEOUT_FACTOR := 1 # IT MAKES NO SENCE TO CHANGE IT. Fix individual test cases that time out instead.
> 
> I'm not sure about this comment, but if we keep it, please move it to the line above and break lines as appropriate.

I updated it to "Please reach consensus before changing this. It was not easy changing it to a `1`. " I also did not break the comment as it was shorter than line 933 above it. Is it acceptable now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273621868

From lkorinth at openjdk.org  Wed Aug 13 14:22:11 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 13 Aug 2025 14:22:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <eYzydMdFKjvnO7FTJ4EwZj6HKsTPVldOtfjSxfR7wik=.dfeb4e4d-adfe-4081-984d-80a74b38a6a9@github.com>
Message-ID: <KRJUnB026z2YmEljJJCHz5JEklLTO2LJfpMvwvt6-5k=.8388ace4-c445-4fdc-a71d-dff5a53cbeb6@github.com>

On Wed, 13 Aug 2025 09:44:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After suggestions from Erik and Andrey
>
> test/langtools/tools/lib/toolbox/ToolBox.java line 480:
> 
>> 478: 
>> 479:     private static final int RETRY_DELETE_MILLIS = isWindows() ? 500 : 0;
>> 480:     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ?  60 * 1000 : 0;
> 
> Suggestion:
> 
>     private static final int MAX_RETRY_DELETE_MILLIS = isWindows() ? 60 * 1000 : 0;

Fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273614076

From ngubarkov at openjdk.org  Wed Aug 13 16:07:45 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 13 Aug 2025 16:07:45 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v6]
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <v5SeTaBgSa3u1n-HyHCE_jBx29GrYkD4-ZeDAVIoVzU=.87fc9987-2d92-4ff1-8eb1-6cc6d475d03a@github.com>

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

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

  8364434: Inconsistent BufferedContext state after GC
  
  Exclude Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26576/files
  - new: https://git.openjdk.org/jdk/pull/26576/files/370bdaa6..7d953161

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

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

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

From ngubarkov at openjdk.org  Wed Aug 13 16:07:45 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 13 Aug 2025 16:07:45 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <7kit18cvNcAxDjfM1vDs8bZgOeEgaabBTsfCYNngp4c=.1d262dd8-5b7c-40f9-b839-b39c7645bf04@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
 <qf_-IM9aUKiUtP0ppp05IMJrdNtO_zjQ44pH-cjMFV0=.687e9947-d32f-4b06-af20-80ad08eb5cec@github.com>
 <17Fu4o7q3ZeX--MA67kBHwob9uEwZZszm1cc4FJtCS8=.1cdbf2ce-3865-4c17-8ff3-5670b8c42c34@github.com>
 <7kit18cvNcAxDjfM1vDs8bZgOeEgaabBTsfCYNngp4c=.1d262dd8-5b7c-40f9-b839-b39c7645bf04@github.com>
Message-ID: <DvJ1I-AsGNPEh-J3kvBo9xXvfD4twccHaSHiv-L3ETo=.63a18a58-13a6-4e33-bbfb-a18b3a1302a3@github.com>

On Wed, 13 Aug 2025 13:49:11 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Although the issues are theoretically possible on any platform when using `BufferedContext`, in practice it is only known to reproduce on Metal.
>> So if we consider only known scenarios, we could as well limit it to macOS. If we consider a theoretical regression scenario, having it on every platform could also be helpful (but not with default XRender mode on Linux of course).
>> But having a non-accelerated pipeline on Linux by default may not be permanent either - when we finish our ongoing Vulkan work under Wakefield, we could eventually make it default. So maybe just leave it for all platforms, wdyt?
>
> I am not opposed to running the test on all platforms.
> Windows and Mac work well, but in the case of Linux and XRender, at this point, we know for certain that the test is not useful and will simply waste 5-15 seconds of CI time on each build.
> 
> We can file an issue for Linux to enable the test back on it when we switch to Vulkan (and investigate the XRender case).

Ok, I pushed the update

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2273921180

From azvegint at openjdk.org  Wed Aug 13 17:08:11 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 13 Aug 2025 17:08:11 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v6]
In-Reply-To: <v5SeTaBgSa3u1n-HyHCE_jBx29GrYkD4-ZeDAVIoVzU=.87fc9987-2d92-4ff1-8eb1-6cc6d475d03a@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <v5SeTaBgSa3u1n-HyHCE_jBx29GrYkD4-ZeDAVIoVzU=.87fc9987-2d92-4ff1-8eb1-6cc6d475d03a@github.com>
Message-ID: <Cf2X1BT-ioq6858IBZkZ3hCjftq4Y4E9HUCnupFF0D0=.b97f7a43-4618-43ed-89f5-b6865b6893b8@github.com>

On Wed, 13 Aug 2025 16:07:45 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Exclude Linux

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26576#pullrequestreview-3116958879

From ngubarkov at openjdk.org  Wed Aug 13 17:15:13 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 13 Aug 2025 17:15:13 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v5]
In-Reply-To: <jZ_TsZwB3tb37nADN_t35DjOXLWxuRV_5XznSLflrDM=.b950611c-7104-4290-881a-65a46cdb737c@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <KkeQPri74zx7LdYEvLL7SABlFQGd9CN2ehNqVlQjLxQ=.08ae2733-bba1-4e59-984b-e4a9088cdfca@github.com>
 <jZ_TsZwB3tb37nADN_t35DjOXLWxuRV_5XznSLflrDM=.b950611c-7104-4290-881a-65a46cdb737c@github.com>
Message-ID: <aK5Gh5xPEzljQOEytLicwoasvjy7Ow2ABHCnLPfG8tc=.c00c32c6-af68-408d-9234-7a25824030cb@github.com>

On Wed, 13 Aug 2025 09:54:56 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364434: Inconsistent BufferedContext state after GC
>>   
>>   Skip the test if Color was not GC'ed
>
> Test running on all platforms looks good to me.
> I have given CI run, if it is green will approve the PR.
> 
> Also lets wait for input from @azvegint

@jayathirthrao could you re-approve it, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3184774616

From jdv at openjdk.org  Wed Aug 13 17:19:12 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 13 Aug 2025 17:19:12 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v6]
In-Reply-To: <v5SeTaBgSa3u1n-HyHCE_jBx29GrYkD4-ZeDAVIoVzU=.87fc9987-2d92-4ff1-8eb1-6cc6d475d03a@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <v5SeTaBgSa3u1n-HyHCE_jBx29GrYkD4-ZeDAVIoVzU=.87fc9987-2d92-4ff1-8eb1-6cc6d475d03a@github.com>
Message-ID: <B5wnDpqYhSBTSqeNjsFjI1Yn8kqXzRlovMpWQ9bwmN4=.4579492a-a0ae-4b4f-9bb7-eec0734151b9@github.com>

On Wed, 13 Aug 2025 16:07:45 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Exclude Linux

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26576#pullrequestreview-3117009278

From duke at openjdk.org  Wed Aug 13 17:28:12 2025
From: duke at openjdk.org (duke)
Date: Wed, 13 Aug 2025 17:28:12 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC [v6]
In-Reply-To: <v5SeTaBgSa3u1n-HyHCE_jBx29GrYkD4-ZeDAVIoVzU=.87fc9987-2d92-4ff1-8eb1-6cc6d475d03a@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
 <v5SeTaBgSa3u1n-HyHCE_jBx29GrYkD4-ZeDAVIoVzU=.87fc9987-2d92-4ff1-8eb1-6cc6d475d03a@github.com>
Message-ID: <puDCal5BRxY9_D0cuZGSI6EJkf5SXAM0pSbYnC4fc-A=.27d24c11-01cb-4ae5-a5b9-a9b5276ad59f@github.com>

On Wed, 13 Aug 2025 16:07:45 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Exclude Linux

@YaaZ 
Your change (at version 7d9531617c0f81fbe48ac5ba60516d3dbe43d18f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26576#issuecomment-3184813941

From ngubarkov at openjdk.org  Wed Aug 13 17:39:26 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Wed, 13 Aug 2025 17:39:26 GMT
Subject: Integrated: 8364434: Inconsistent BufferedContext state after GC
In-Reply-To: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
References: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>
Message-ID: <G3fJXeKIVj2u82QrrCLbJDqfrT99FDxYj-ogiAPyI4Q=.67bde936-81ca-4fd4-9cdc-1ed452be46f9@github.com>

On Thu, 31 Jul 2025 13:31:49 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
> 
> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

This pull request has now been integrated.

Changeset: 899e13f4
Author:    Nikita Gubarkov <ngubarkov at openjdk.org>
Committer: Laurent Bourg?s <lbourges at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/899e13f40a70c98d1d393ba6c3973abcb36e1f00
Stats:     120 lines in 2 files changed: 95 ins; 2 del; 23 mod

8364434: Inconsistent BufferedContext state after GC

Reviewed-by: jdv, azvegint, avu

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

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

From dnguyen at openjdk.org  Wed Aug 13 18:28:19 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 13 Aug 2025 18:28:19 GMT
Subject: RFR: 8364363: Modify some manual test instructions
In-Reply-To: <YQfjnkiD400jFFTPkSlKZGfLR2HdkwZuCi17epi3CHk=.8a8cf203-0f74-477b-be51-bbe7be5c4766@github.com>
References: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
 <YQfjnkiD400jFFTPkSlKZGfLR2HdkwZuCi17epi3CHk=.8a8cf203-0f74-477b-be51-bbe7be5c4766@github.com>
Message-ID: <hmbdjYkW0sn1xtLF2_l_D2pNfqe02M_VatEhyeAToZQ=.ced0d7df-b886-4d5f-9dcd-a43f4c3a1bbe@github.com>

On Tue, 5 Aug 2025 18:47:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> When testing jtreg manual tests, some tests had unclear instructions. This PR is an attempt at updating these tests for clarity. 
>> 
>> `MouseDraggedOriginatedByScrollBarTest.java` works as expected when compared to native apps and outputs drag events even when the mouse pointer is dragged off of the scrollbar and window altogether. Events should still fire, but the previous instructions may make this confusing since it reads as if no events should be output to the textarea at all.
>> 
>> `TextAreaAppendScrollTest2.java` seems to not work when testing with the previous implementation of programmatically appending strings to the textarea. When I scroll down using the down arrow key, none of the text below would be visible when the textarea is scrolled down. However, it would show if I pressed `ENTER` to create a new line or manually modify the text in the textarea first. So instead, I have implemented the original reported approach to the test of adding a button to append a string to the textarea to test for automatic scrolling when the word is wrapped to a new line.
>
> test/jdk/java/awt/TextArea/TextAreaAppendScrollTest2.java line 42:
> 
>> 40:     TextArea area;
>> 41:     private static final String INSTRUCTIONS = """
>> 42:             Press the "Append \'cool\' button until you are able
> 
> Is this necessary even on X11 ? The test seems to have been written for that.

After testing and looking into the test on X11, Wayland, and macOS, I believe you're right. I can keep the original instructions. However, there are definitely issues with appending text and auto-scrolling in a textarea. Works fine when manually done with something like this button. Does not work when appending thru a for-loop as this test does (fails in various ways depending on OS).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2274282816

From dnguyen at openjdk.org  Wed Aug 13 18:28:20 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 13 Aug 2025 18:28:20 GMT
Subject: RFR: 8364363: Modify some manual test instructions
In-Reply-To: <R-GOZV89lBHRfupG9_S-bHrenlhIAuGa6CHurJEZXUI=.bbb46cb1-4116-4f19-96a9-addbe9392080@github.com>
References: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
 <R-GOZV89lBHRfupG9_S-bHrenlhIAuGa6CHurJEZXUI=.bbb46cb1-4116-4f19-96a9-addbe9392080@github.com>
Message-ID: <PK3XOEuhyHeQ7RJd0d_i8JbJMzIDxLZ6bgB6NkHb3H4=.35c9db50-9f93-4e78-95ec-67d2ebb48bd1@github.com>

On Wed, 6 Aug 2025 20:15:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> When testing jtreg manual tests, some tests had unclear instructions. This PR is an attempt at updating these tests for clarity. 
>> 
>> `MouseDraggedOriginatedByScrollBarTest.java` works as expected when compared to native apps and outputs drag events even when the mouse pointer is dragged off of the scrollbar and window altogether. Events should still fire, but the previous instructions may make this confusing since it reads as if no events should be output to the textarea at all.
>> 
>> `TextAreaAppendScrollTest2.java` seems to not work when testing with the previous implementation of programmatically appending strings to the textarea. When I scroll down using the down arrow key, none of the text below would be visible when the textarea is scrolled down. However, it would show if I pressed `ENTER` to create a new line or manually modify the text in the textarea first. So instead, I have implemented the original reported approach to the test of adding a button to append a string to the textarea to test for automatic scrolling when the word is wrapped to a new line.
>
> test/jdk/java/awt/TextArea/TextAreaAppendScrollTest2.java line 71:
> 
>> 69:             coolStr.append("cool ");
>> 70:         }
>> 71:         area.append(coolStr.toString());
> 
> Is adding `12 * 15` _cools_ not enough?
> 
> The original instructions are pretty clear: if you see the exclamation marks, then auto-scrolling works correctly; otherwise, it auto-scrolling doesn't work as expected and the tester has to click **Fail**.

I was testing this on different OS's and on macOS the text is cut off and none of the text renders after a certain point.

This is what it looks like when I manually move the text cursor down to scroll the text area down a bit:
<img width="194" height="160" alt="Screenshot 2025-08-13 at 11 17 56?AM" src="https://github.com/user-attachments/assets/e3a10220-43c0-409b-8270-0f5dd3e134d5" />

I suppose this is a macOS bug. On linux (X11 and Wayland), this works fine, but the test does not start with the textarea showing the exclamation marks. Instead, it starts at the top. But, all of the text renders correctly when scrolled down. When I manually append another `cool` to the text area, the auto scroll and rendering of all the text works fine for all OS's.
<img width="191" height="138" alt="Screenshot 2025-08-13 at 11 23 48?AM" src="https://github.com/user-attachments/assets/92964ff1-792d-4c01-a12f-cef066cd7302" />

What I think I understand now is, there is most likely a macOS bug here and the test fails on linux. I'll revert the changes to this test. I think this also means I should ProblemList this test. I will, however, try fiddling with this test to see if I can get the programmatic appending to render on macOS and figure out the source of the issue. Maybe it will work with an added delay in the beginning or something of the sort.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2274279275

From bchristi at openjdk.org  Wed Aug 13 19:06:11 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 13 Aug 2025 19:06:11 GMT
Subject: RFR: 8365198: Remove unnecessary mention of finalize in ImageIO
 reader/writer docs
In-Reply-To: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
References: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
Message-ID: <KemGkhSJehWeMyjI1Xy3wzE2X4YGBklJ9wpSnodFNrA=.e4f8e1b2-f85f-440f-8e5a-9beacfc8d779@github.com>

On Tue, 12 Aug 2025 20:46:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Image I/O's ImageReader and ImageWriter have never had finalize() methods, yet have a gratuitous mention of finalize(). This should be removed. Simple doc only change
> 
> CSR for review : https://bugs.openjdk.org/browse/JDK-8365410

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26753#pullrequestreview-3117315661

From dnguyen at openjdk.org  Wed Aug 13 20:32:10 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 13 Aug 2025 20:32:10 GMT
Subject: RFR: 8364363: Modify some manual test instructions [v2]
In-Reply-To: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
References: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
Message-ID: <sXQahYNvp9Z5GIDNUK8iHGmrGrc9q1Sum74AmJbQCPo=.f4f0b7c4-5578-4e11-adfe-e0d0cee9a48d@github.com>

> When testing jtreg manual tests, some tests had unclear instructions. This PR is an attempt at updating these tests for clarity. 
> 
> `MouseDraggedOriginatedByScrollBarTest.java` works as expected when compared to native apps and outputs drag events even when the mouse pointer is dragged off of the scrollbar and window altogether. Events should still fire, but the previous instructions may make this confusing since it reads as if no events should be output to the textarea at all.
> 
> `TextAreaAppendScrollTest2.java` seems to not work when testing with the previous implementation of programmatically appending strings to the textarea. When I scroll down using the down arrow key, none of the text below would be visible when the textarea is scrolled down. However, it would show if I pressed `ENTER` to create a new line or manually modify the text in the textarea first. So instead, I have implemented the original reported approach to the test of adding a button to append a string to the textarea to test for automatic scrolling when the word is wrapped to a new line.

Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:

 - Fix correcting character limit to undo all changes and leave file untouched.
 - Convert test to auto. Revert TextArea test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26636/files
  - new: https://git.openjdk.org/jdk/pull/26636/files/86f38b37..39ed1e87

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

  Stats: 91 lines in 2 files changed: 51 ins; 14 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26636/head:pull/26636

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

From dnguyen at openjdk.org  Wed Aug 13 20:32:12 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 13 Aug 2025 20:32:12 GMT
Subject: RFR: 8364363: Modify some manual test instructions [v2]
In-Reply-To: <R-GOZV89lBHRfupG9_S-bHrenlhIAuGa6CHurJEZXUI=.bbb46cb1-4116-4f19-96a9-addbe9392080@github.com>
References: <iQYjptrxsBXbIY24l0S6caGMA1jQFRJGJ-EF94iRzXk=.8337b963-c911-4e50-80cc-fcc87071e2bb@github.com>
 <R-GOZV89lBHRfupG9_S-bHrenlhIAuGa6CHurJEZXUI=.bbb46cb1-4116-4f19-96a9-addbe9392080@github.com>
Message-ID: <Azp3lI_AmejemMiXnxXW1fJJZ3N_tD5CBn4cEmUj1_0=.be99e338-dfe0-4e7d-8621-06591affe138@github.com>

On Wed, 6 Aug 2025 20:10:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix correcting character limit to undo all changes and leave file untouched.
>>  - Convert test to auto. Revert TextArea test changes
>
> test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 48:
> 
>> 46:             3) The test fails if you see messages about drag
>> 47:             events for anything other than list0.
>> 48:             The test passes if you don't.
> 
> Is it possible to automate this part? I mean, automatically flag the test as failed (after displaying a message to the tester after dragging is complete).

I have gone ahead and updated the test to be automated. I tested this on macOS (where the test skips since the test only works for XToolkit) and on Ubuntu on Xorg (where the test is automated and passes with no outputted events).

> test/jdk/java/awt/TextArea/TextAreaAppendScrollTest2.java line 71:
> 
>> 69:             coolStr.append("cool ");
>> 70:         }
>> 71:         area.append(coolStr.toString());
> 
> Is adding `12 * 15` _cools_ not enough?
> 
> The original instructions are pretty clear: if you see the exclamation marks, then auto-scrolling works correctly; otherwise, it auto-scrolling doesn't work as expected and the tester has to click **Fail**.

@aivanov-jdk Is problem-listing this test the ideal solution?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2274553279
PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2274555264

From dnguyen at openjdk.org  Wed Aug 13 22:14:18 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 13 Aug 2025 22:14:18 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v9]
In-Reply-To: <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
Message-ID: <r7frTU2JrTpy48099SEiSJ0QWFG73NX3VnchFZn0kWY=.a0df6347-ed8e-4709-8442-bb25c9243aee@github.com>

On Wed, 6 Aug 2025 09:43:48 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: Added review comment

Tested on macOS and Ubuntu 24.04 (Wayland & X). Test passes on all except I get a timeout error on Wayland. Can you confirm that this test passes on your end on Wayland?

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 114:

> 112:             // move. By default we send MOVED event.
> 113:             // XToolkit: extra buttons should report MOVED events only
> 114:             // WToolkit: extra buttons should report DRAGGED events only

One suggestion could be to use `Toolkit.getDefaultToolkit().getClass().getName()` to access the toolkit names. Some other tests in the test directory use this already. However, as Phil mentioned, I suppose this current way is fine.

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 186:

> 184:         if (frame != null) {
> 185:             frame.dispose();
> 186:             frame = null;

Usually `frame.dispose()` is enough but having `frame = null` is fine too I suppose.

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

PR Review: https://git.openjdk.org/jdk/pull/26043#pullrequestreview-3117841941
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2274741488
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2274737204

From psadhukhan at openjdk.org  Thu Aug 14 04:58:15 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 14 Aug 2025 04:58:15 GMT
Subject: Integrated: 8365375: Method SU3.setAcceleratorSelectionForeground
 assigns to acceleratorForeground
In-Reply-To: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
References: <BSwKeToWB6vygAoK_eXgMfC60LAWUBj-zGH1OUq1gCs=.4c2c7541-d0be-4fd3-9576-c5ee5e04f0d3@github.com>
Message-ID: <pniRY63qYEncmUsu5htG3HWBPfumV8GCOp6TU7N0-ss=.de34da2a-39b9-4f76-9037-7a2060892bde@github.com>

On Tue, 12 Aug 2025 12:27:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> An inadvertent copy-paste error in assignment is fixed

This pull request has now been integrated.

Changeset: 9dcc502c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9dcc502cc83773561707f2afe9aee1f9e2386b9e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8365375: Method SU3.setAcceleratorSelectionForeground assigns to acceleratorForeground

Reviewed-by: aivanov, prr, kizune

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

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

From alanb at openjdk.org  Thu Aug 14 06:17:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Aug 2025 06:17:10 GMT
Subject: RFR: 8365416: java.desktop no longer needs preview feature access
In-Reply-To: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
References: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
Message-ID: <stwJjC3JCXrlRawcPWgha2Lpq64Hfv0wdOoe3_QY4p4=.21926bad-0f02-4de0-b638-0751d449c875@github.com>

On Wed, 13 Aug 2025 18:47:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Now that Scoped Values is no longer preview, the desktop module does not need the entry in the base module-info.java

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26765#pullrequestreview-3119157986

From jpai at openjdk.org  Thu Aug 14 08:00:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Aug 2025 08:00:13 GMT
Subject: RFR: 8365416: java.desktop no longer needs preview feature access
In-Reply-To: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
References: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
Message-ID: <ySVqQXNPc3Q15lGGqv_zec9pcF-c2ue1KlrMSF_4QPg=.ce72d2a7-7c6f-41d0-a449-de975543b1ed@github.com>

On Wed, 13 Aug 2025 18:47:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Now that Scoped Values is no longer preview, the desktop module does not need the entry in the base module-info.java

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26765#pullrequestreview-3119439209

From prr at openjdk.org  Thu Aug 14 15:24:18 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Aug 2025 15:24:18 GMT
Subject: Integrated: 8365416: java.desktop no longer needs preview feature
 access
In-Reply-To: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
References: <tf9Ygi9dJBYCdaIXc2dwjfLfQTtuTBIC0GAKs-AZ3QE=.a7a1cc22-81b5-4be8-bcb6-1eccbfe1510e@github.com>
Message-ID: <K63_x5VIjPJHgWAEOSsrtznQ6z8Jeprm_RETLeNO8-c=.bd16c26f-d079-4bf6-9e4b-6c8e14cdbd85@github.com>

On Wed, 13 Aug 2025 18:47:37 GMT, Phil Race <prr at openjdk.org> wrote:

> Now that Scoped Values is no longer preview, the desktop module does not need the entry in the base module-info.java

This pull request has now been integrated.

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

8365416: java.desktop no longer needs preview feature access

Reviewed-by: alanb, jpai

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

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

From dgredler at openjdk.org  Thu Aug 14 16:02:14 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Thu, 14 Aug 2025 16:02:14 GMT
Subject: RFR: 8359955: Regressions ~7% in several J2DBench in 25-b26
In-Reply-To: <SjfWK4lEmurI1MuZonAB--HIMQJql89Ke__lrRQaKYM=.4c74b9e4-9685-43a5-ae88-7446de8b69bf@github.com>
References: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
 <SjfWK4lEmurI1MuZonAB--HIMQJql89Ke__lrRQaKYM=.4c74b9e4-9685-43a5-ae88-7446de8b69bf@github.com>
Message-ID: <py8h764u66xzjMpEe5uFn8Ve4imX3MhLZtMH80c0scM=.dd6ca175-09a4-4506-b92e-6946d9cb66b6@github.com>

On Fri, 8 Aug 2025 21:26:26 GMT, Phil Race <prr at openjdk.org> wrote:

>> Addresses recent slight performance regressions in some J2DBench benchmarks focused on text drawing.
>> 
>> `CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after JDK-8353230 they weren't caching glyph IDs for chars which might be affected by the raw / non-raw glyph distinction, since the cached value may not be correct if we ask for a raw glyph ID one time, but a non-raw glyph ID the next time (or vice versa). This caching exception was the reason for the slightly degraded performance (the `CCharToGlyphMapper` behavior was affecting macOS, and the `CompositeGlyphMapper` behavior was affecting some versions of Windows). This change splits the cache in each of these two classes into two caches, one for raw glyph IDs and one for non-raw glyph IDs, so that all glyphs can benefit from caching.
>> 
>> All of the font tests (`make test TEST="jtreg:test/jdk/java/awt/font"`) pass for me locally with this change on Linux, macOS and Windows.
>
> LGTM. I ran all our automated jtreg tests on all platforms, plus JCK.

This one needs a second review, if any reviewers have some spare time. The discussion in JBS contains performance test results from Eric, and per @prrace's comment above, all tests are passing. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26702#issuecomment-3188982503

From prr at openjdk.org  Thu Aug 14 16:24:24 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Aug 2025 16:24:24 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI
Message-ID: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>

This refactors some Swing code to pass args instead of using statics

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

Commit messages:
 - 8365389

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

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

From prr at openjdk.org  Thu Aug 14 16:53:27 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Aug 2025 16:53:27 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
Message-ID: <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>

> This refactors some Swing code to pass args instead of using statics

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

  8365389

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26783/files
  - new: https://git.openjdk.org/jdk/pull/26783/files/f991a86e..a1f59db1

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

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

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

From prr at openjdk.org  Thu Aug 14 16:58:14 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Aug 2025 16:58:14 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
Message-ID: <An1dot7pqXFepoRY6dKdF0ukfc9mQuRHas9AwmYDKDs=.8c8b8929-285b-4b01-b3b3-4f342a9f0d03@github.com>

On Thu, 14 Aug 2025 16:53:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> This refactors some Swing code to pass args instead of using statics
>> The bug report suggests some further refactoring which could be considered later, but the most
>> important thing to do is to eliminate using statics to pass args.
>> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365389

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 719:

> 717:     private void paintAccText(Graphics g, MenuItemLayoutHelper lh,
> 718:                               MenuItemLayoutHelper.LayoutResult lr) {
> 719:         SwingUtilities3.paintAccText(g, lh, lr,

I left this private method here rather than calling the SU3 code directly because this method was here all along, before the previous fix. Same for a couple of others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26783#discussion_r2277193060

From prr at openjdk.org  Thu Aug 14 17:35:27 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Aug 2025 17:35:27 GMT
Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java
Message-ID: <gvG7FJiUONPg1uSza7EFPjns0JUFosfE6gHlTDHpzGI=.63540380-fd25-4beb-b062-8da20cd7dceb@github.com>

This refactors com/sun/media/sound/JavaSoundAudioClip.java so that most of the implementation is in a delegate
com/sun/media/sound/JavaSoundAudioClipDelegate.java

Then a disposer can be used to free the audio resources held by the delegate when the JavaSoundAudioClip becomes unreachable.

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

Commit messages:
 - 8365569
 - 8365569

Changes: https://git.openjdk.org/jdk/pull/26784/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365569
  Stats: 848 lines in 2 files changed: 455 ins; 360 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/26784.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26784/head:pull/26784

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

From dnsimon at openjdk.org  Thu Aug 14 19:33:15 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 14 Aug 2025 19:33:15 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
Message-ID: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>

On Wed, 13 Aug 2025 14:22:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   After suggestions from Erik and Andrey

> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.

Would you mind also running tier9 to avoid surprises there.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3189640422

From aivanov at openjdk.org  Thu Aug 14 20:02:14 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 14 Aug 2025 20:02:14 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
Message-ID: <qYzCMAnU-1brIcGDcopGUR8w-tu_iT9vdeuZpjGF-RY=.55850c3b-e9ed-48c1-8b51-d7f2969f21a2@github.com>

On Thu, 14 Aug 2025 16:53:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> This refactors some Swing code to pass args instead of using statics
>> The bug report suggests some further refactoring which could be considered later, but the most
>> important thing to do is to eliminate using statics to pass args.
>> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365389

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26783#pullrequestreview-3121945949

From aivanov at openjdk.org  Thu Aug 14 20:02:16 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 14 Aug 2025 20:02:16 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <An1dot7pqXFepoRY6dKdF0ukfc9mQuRHas9AwmYDKDs=.8c8b8929-285b-4b01-b3b3-4f342a9f0d03@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <An1dot7pqXFepoRY6dKdF0ukfc9mQuRHas9AwmYDKDs=.8c8b8929-285b-4b01-b3b3-4f342a9f0d03@github.com>
Message-ID: <lvizTfxrOVX65c1eSTNVKoKSSGSKunpraQEzAQye3YU=.6a18c595-9b67-4351-8be7-547d2dec0ae2@github.com>

On Thu, 14 Aug 2025 16:55:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8365389
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 719:
> 
>> 717:     private void paintAccText(Graphics g, MenuItemLayoutHelper lh,
>> 718:                               MenuItemLayoutHelper.LayoutResult lr) {
>> 719:         SwingUtilities3.paintAccText(g, lh, lr,
> 
> I left this private method here rather than calling the SU3 code directly because this method was here all along, before the previous fix. Same for a couple of others.

Previously, these private methods did the work that's now performed by the new methods in `SwingUtilities3`.

It's fine to postpone removing these private methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26783#discussion_r2277595953

From serb at openjdk.org  Thu Aug 14 21:31:11 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 14 Aug 2025 21:31:11 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
In-Reply-To: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
Message-ID: <xWy53TemnV-uH_GlxXhu5_21XzZN5iY6Bkp3eAg-PjI=.18ef29dc-d27f-450b-9677-8a51a2f1893e@github.com>

On Tue, 12 Aug 2025 19:32:33 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove javax.imageio.spi.ServiceRegistry.finalize() since it is deprecated for removal.
> The impact of this should be minimal. The IIORegistry will now be a singleton - which it already was 
> in practice since Applets are no longer supported. Since it is a singleton, it will persist for the life
> of the VM, so will never be garbage collected.
> A test that verifies one per-AppContext is now obsolete, and is deleted, and there's no good reason to make it a negative test, since in due course AppContext itself will be deleted and is un-used today except in tests.
> 
> Since JDK 9, ServiceRegistry has supported only Image I/O specified providers, and since the IIORegistry does this,
> in practice there is very little reason for an application to create instances or subclasses of it.
> And even if they do, typically like IIORegistry, they be used for the life time of the application.
> And if they are collected, without calling ServiceRegistry.deregisterAll() there may be no impact,
> since only providers that implement RegisterableService will be affected.
> 
> See the JBS issue for all the details.
> 
> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8365409

src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 109:

> 107:     private static final IIORegistry registry;
> 108:     static {
> 109:         registry = new IIORegistry();

Constructor of IIORegistry executes a large amount of code, might be better to load it lazily as before? instead of from the class initialization. could be a good opportunity to use StableValue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26752#discussion_r2277756129

From serb at openjdk.org  Thu Aug 14 22:16:11 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 14 Aug 2025 22:16:11 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize()
In-Reply-To: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
Message-ID: <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>

On Fri, 8 Aug 2025 21:38:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize() from WInputMethod.java - it is used to free a native id.
> Also the reason dispose() didn't free it seems no longer relevant.
> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.

src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java line 165:

> 163:     @Override
> 164:     public void dispose() {
> 165:         disposerRecord.dispose();

The native dispose will call `ImmDestroyContext` which is specified as:
> However, before calling ImmDestroyContext, the application must remove the input context from any association with windows in the thread by using the [ImmAssociateContext](https://learn.microsoft.com/en-us/windows/desktop/api/imm/nf-imm-immassociatecontext) function.

I did not check the code, but maybe we are calling `ImmAssociateContext` in the wrong moment and have to postpone this "dispose" until all the object is really unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2277816637

From abaya at openjdk.org  Fri Aug 15 00:53:46 2025
From: abaya at openjdk.org (Anass Baya)
Date: Fri, 15 Aug 2025 00:53:46 GMT
Subject: RFR: 8361606 : ConsumeNextMnemonicKeyTypedTest.java fails on Windows:
 character typed with VK_A: a
Message-ID: <WDpNxHS3WnZlz202KKFxr5UayPo5sEiQIyOb6nBQy-o=.db102f0f-efae-46f9-a362-7fb8cc689f3a@github.com>

**Analysis :**
When the problem occurred, the key press event related to the mnemonic triggered the item selection. However, as we returned to the menu, the subsequent key typed event arrived and was treated as a normal key press instead of being recognized as part of the mnemonic sequence.

**Proposed Fix:**
As a fix, we are tagging the next key typed event to be consumed by the Keyboard Focus Manager


    public void processKeyEvent(Component focusedComponent, KeyEvent e) {
        // consume processed event if needed
        if (consumeProcessedKeyEvent(e)) { <--- consumed here
            return;
        }
...

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

Commit messages:
 - Track the next KEY_TYPED related to the mnemonic key press event so it will be consumed but the keyboard focus manager

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

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

From serb at openjdk.org  Fri Aug 15 01:35:10 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Aug 2025 01:35:10 GMT
Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java
In-Reply-To: <gvG7FJiUONPg1uSza7EFPjns0JUFosfE6gHlTDHpzGI=.63540380-fd25-4beb-b062-8da20cd7dceb@github.com>
References: <gvG7FJiUONPg1uSza7EFPjns0JUFosfE6gHlTDHpzGI=.63540380-fd25-4beb-b062-8da20cd7dceb@github.com>
Message-ID: <pgsCJk8xYCFXbo5jNB3X-951-_UsikXtPKfXV9ATZ0c=.2aaaeecf-9938-459a-824f-457c7262c20c@github.com>

On Thu, 14 Aug 2025 17:27:09 GMT, Phil Race <prr at openjdk.org> wrote:

> This refactors com/sun/media/sound/JavaSoundAudioClip.java so that most of the implementation is in a delegate
> com/sun/media/sound/JavaSoundAudioClipDelegate.java
> 
> Then a disposer can be used to free the audio resources held by the delegate when the JavaSoundAudioClip becomes unreachable.

How about modifying the listeners list implementations to store listeners using weak references instead(not sure it will be better that the current patch)? it seems current implementation can cause memory leaks?

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

PR Comment: https://git.openjdk.org/jdk/pull/26784#issuecomment-3190363350

From lkorinth at openjdk.org  Fri Aug 15 11:43:33 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:43:33 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d

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

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

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

From lkorinth at openjdk.org  Fri Aug 15 11:59:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 15 Aug 2025 11:59:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <iWlp9Azqc_MsGBnk-PK8OYZqpcnhSASRJmnz8IgzTQI=.965cedce-3e5a-40e5-9e86-9b1f5c2d2021@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Added three new `/timeout=480` after the last run.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3191343090

From asemenov at openjdk.org  Fri Aug 15 13:11:21 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 15 Aug 2025 13:11:21 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
Message-ID: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>

The defect has been detected and confirmed in the function OGLBlitToSurfaceViaTexture() located in the file src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c with static code analysis. This defect can potentially lead to a null pointer dereference.

The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null.

According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

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

Commit messages:
 - The same issue is present in src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c gtk3_load()
 - The same issue is present in src/java.desktop/share/native/libsplashscreen/splashscreen_gif.c SplashDecodeGif()
 - The same issue is present in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitSwToTexture()
 - 8365609 Null pointer dereference in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitToSurfaceViaTexture()

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

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

From azvegint at openjdk.org  Fri Aug 15 13:25:09 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 15 Aug 2025 13:25:09 GMT
Subject: RFR: 8365198: Remove unnecessary mention of finalize in ImageIO
 reader/writer docs
In-Reply-To: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
References: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
Message-ID: <bYSFMRqrKqCzgTzhDYSYIsSvAuE3VHz3dfCTVnwQQIE=.b497030f-bffb-44a9-928a-cb590bb878f2@github.com>

On Tue, 12 Aug 2025 20:46:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Image I/O's ImageReader and ImageWriter have never had finalize() methods, yet have a gratuitous mention of finalize(). This should be removed. Simple doc only change
> 
> CSR for review : https://bugs.openjdk.org/browse/JDK-8365410

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26753#pullrequestreview-3123843233

From syan at openjdk.org  Fri Aug 15 14:08:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 15 Aug 2025 14:08:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2279056261

From aivanov at openjdk.org  Fri Aug 15 15:20:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 15 Aug 2025 15:20:12 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
Message-ID: <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>

On Thu, 14 Aug 2025 16:53:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> This refactors some Swing code to pass args instead of using statics
>> The bug report suggests some further refactoring which could be considered later, but the most
>> important thing to do is to eliminate using statics to pass args.
>> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365389

There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3191760275

From duke at openjdk.org  Fri Aug 15 16:09:07 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 16:09:07 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v7]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <qYj3SjluRugvWU07GwsK2u26ZqZ-jpNZh6jUHuBhk84=.29f1622b-3af7-4d96-93f5-8b95213d5536@github.com>

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

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

 - Revert "Accept color differences to less or equal to 15"
   
   This reverts commit a98db3e22781088eccd95912697853355f22645e.
 - Accept color differences to less or equal to 15
 - Changes the look and feel to the default Metal
 - Removes setOpqaue for swing buttons
 - Renames color tolerance for macosx
 - Uses simplified statement in method isAlmostEqualColor
 - Adds space around binary operators
 - Merge branch 'openjdk:master' into jdk-8360498
 - 8364723: Sort share/interpreter includes
   
   Reviewed-by: shade, ayang
 - 8365244: Some test control variables are undocumented in doc/testing.md
   
   Reviewed-by: erikj
 - ... and 139 more: https://git.openjdk.org/jdk/compare/47ff0eb6...c748b77f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/85f9321f..c748b77f

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

  Stats: 20034 lines in 564 files changed: 10513 ins; 7299 del; 2222 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From duke at openjdk.org  Fri Aug 15 16:14:55 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 16:14:55 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v19]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <R2ycTXEmBp4sQP5AE4cCBRbm-hJ0FMKMLqSKNm_gPmI=.436f2407-ec13-44a9-aac5-12ef5b8bea1b@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Merge branch 'openjdk:master' into jdk-8158801
 - Updates CountDownLatch waiting time to one second
 - Requests focus, if component does not have it already.
 - Merge branch 'openjdk:master' into jdk-8158801
 - Checks if component had focus first.
 - Removes wildcard imports
 - Merge branch 'openjdk:master' into jdk-8158801
 - Removes not needed component frace ancestor.
 - Problem unlists passed tests
 - Uses frame requestFocus instead of robot clicks for focus
 - ... and 18 more: https://git.openjdk.org/jdk/compare/2d31b3e0...3f8742e7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/abc0797c..3f8742e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=17-18

  Stats: 15747 lines in 461 files changed: 8450 ins; 5395 del; 1902 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Fri Aug 15 16:40:39 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 16:40:39 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v8]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <ezVOaA3eT3cu1k4nClWtM8QOOzxRm2iuDJrIjOGaFLw=.c58b0663-f0ad-46a4-a835-e98af261439b@github.com>

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

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

 - Merge branch 'openjdk:master' into jdk-8360498
 - Revert "Accept color differences to less or equal to 15"
   
   This reverts commit a98db3e22781088eccd95912697853355f22645e.
 - Accept color differences to less or equal to 15
 - Changes the look and feel to the default Metal
 - Removes setOpqaue for swing buttons
 - Renames color tolerance for macosx
 - Uses simplified statement in method isAlmostEqualColor
 - Adds space around binary operators
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Updates copyright years
 - ... and 36 more: https://git.openjdk.org/jdk/compare/dbae90c9...45ed29b3

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

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=07
  Stats: 158 lines in 8 files changed: 75 ins; 41 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

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

From duke at openjdk.org  Fri Aug 15 16:44:30 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 16:44:30 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v9]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <wVDuz_uqDvhMp61vLSOY1puhYWNk0jQHkHrlGR5-mNI=.d9923cd4-adf1-49e2-a4e6-2950c31524d9@github.com>

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

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

 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8360498
 - Revert "Accept color differences to less or equal to 15"
   
   This reverts commit a98db3e22781088eccd95912697853355f22645e.
 - Accept color differences to less or equal to 15
 - Changes the look and feel to the default Metal
 - Removes setOpqaue for swing buttons
 - Renames color tolerance for macosx
 - Uses simplified statement in method isAlmostEqualColor
 - Adds space around binary operators
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - ... and 14 more: https://git.openjdk.org/jdk/compare/7deb328f...e8a3c47c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/45ed29b3..e8a3c47c

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

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

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

From duke at openjdk.org  Fri Aug 15 16:52:55 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 16:52:55 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v20]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <Mv3KFRC51SY1nJh8L8TWF4VFI7cZX7YCT40-LVTEBt0=.12356dec-c525-4c6c-9782-c643dd2afac7@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/3f8742e7..b39fc42d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=18-19

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

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

From aivanov at openjdk.org  Fri Aug 15 16:53:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 15 Aug 2025 16:53:35 GMT
Subject: RFR: 8365615: Improve JMenuBar/RightLeftOrientation.java
Message-ID: <XxNYwd8AnjCdUUQTHNWkeSF89KE7-ruCiwVIpsGUCjM=.c4090af6-c428-41b1-93ae-5380a0f78795@github.com>

Position the two frames with menu bars in left-to-right and right-to-left orientations below the frame that allows changing the look and feel.

Additionally, amend the instructions and refactor the code, show an error message to the tester if setting L&F fails.

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

Commit messages:
 - 8365615: Improve JMenuBar/RightLeftOrientation.java

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

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

From serb at openjdk.org  Fri Aug 15 17:08:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Aug 2025 17:08:09 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
Message-ID: <DWDzmPz9NuO_zs57aeufdU2mfPg2XMAi_sgxja4GBFM=.0a08a649-3cda-41f3-9c3d-a043b1c8da58@github.com>

On Fri, 15 Aug 2025 13:04:35 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null.

It is better first to confirm whether this pointer can actually be NULL. If it cannot then remove the unnecessary earlier NULL check.

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

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

From duke at openjdk.org  Fri Aug 15 17:11:15 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 17:11:15 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v18]
In-Reply-To: <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <DYMGVqk6tz_-rtvl8oEzXzt2MXwWxYH1AExCYZDQIv4=.4c231fd8-08c8-4a63-80e3-f51fd64c7b82@github.com>
 <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
Message-ID: <d1fiyx2XsDAG8kWpZzDQhzBihFdNmFBWJR_NVfSVtc0=.3885d5d4-a517-45ba-bfb0-0044e98df775@github.com>

On Tue, 12 Aug 2025 15:03:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates CountDownLatch waiting time to one second
>
> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 169:
> 
>> 167:                 throw new RuntimeException("Ancestor frame didn't receive " +
>> 168:                         "focus");
>> 169:             }
> 
> The same comments as for `GlassPaneOverlappingTestBase.java`.
> 
> The latch may never release because you don't call its `countDown` method if `ancestor` is `null`. Can `ancestor` be `null`?

It looks for me that ancestor could never be null. All components (Including embedded frame test) reside in a frame. But, to be on the safe side, I will include the case where ancestor could be null, in case this occurs.

Same for GlassPaneOverlappingTestBase.java, if component support resizing. I will add code to release the latch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2279515856

From serb at openjdk.org  Fri Aug 15 17:12:12 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Aug 2025 17:12:12 GMT
Subject: RFR: 8365198: Remove unnecessary mention of finalize in ImageIO
 reader/writer docs
In-Reply-To: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
References: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
Message-ID: <lxVp-pOhgr6oLqPjGO9LXkY4gO8i4zHEg8ztC9h0rXc=.e0a6f633-b2dc-4003-a3bf-d09894dda3df@github.com>

On Tue, 12 Aug 2025 20:46:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Image I/O's ImageReader and ImageWriter have never had finalize() methods, yet have a gratuitous mention of finalize(). This should be removed. Simple doc only change
> 
> CSR for review : https://bugs.openjdk.org/browse/JDK-8365410

src/java.desktop/share/classes/javax/imageio/ImageWriter.java line 2003:

> 2001:     /**
> 2002:      * Allows any resources held by this object to be released.  The
> 2003:      * result of calling any other method subsequent to a call to this method

"any other method" makes it sound like every method in the universe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26753#discussion_r2279518567

From duke at openjdk.org  Fri Aug 15 17:21:30 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 17:21:30 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v21]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <dy1rpWRTRwgOpvOp-KxcVCXnMWTze1Qc01xnf6O7eIw=.a8e751cf-96f4-4473-830d-5ab3a31614a7@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Releses latch in case of null ancestor or resizing component

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/b39fc42d..4df40993

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=19-20

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

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

From duke at openjdk.org  Fri Aug 15 17:29:16 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 17:29:16 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v10]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <AYqusdqEtMO6jvog8FCHsea_U0H0YPrTkk0F_6NmI10=.9b34655d-2535-41a3-b4f9-f8bd9b7ffe74@github.com>

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

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

  Removes extra white lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e8a3c47c..e2b13d6f

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

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

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

From duke at openjdk.org  Fri Aug 15 17:34:17 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 17:34:17 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v5]
In-Reply-To: <X1kurmZo66oXXZXar9ggn9ylNSpDbZZB64nECnDftUk=.e79b97a5-fdab-45ba-9668-8aec963e5f73@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <g1FIBp0KK_EAryWJ8wRLQYaj6cZKH9U2YgWgnVJ5FcM=.16a4833e-4859-4b1b-8124-8c87a75294e7@github.com>
 <DacoaFRtCDDjHC8zT38opt0kpyQ5dSsw-gM8NjTF5JA=.89a7743e-f20d-40c9-acab-1d044315c2e3@github.com>
 <X1kurmZo66oXXZXar9ggn9ylNSpDbZZB64nECnDftUk=.e79b97a5-fdab-45ba-9668-8aec963e5f73@github.com>
Message-ID: <-ldBY9E50cDCOZW3FP2JeGKq-mEEX_14ljbSDfnYgRw=.0703b9a3-5ac5-4093-b629-10e6d6b8da61@github.com>

On Tue, 12 Aug 2025 16:34:39 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 118:
>> 
>>> 116:                 jbutton.setForeground(jbColor);
>>> 117:                 jbutton.setBackground(jbColor);
>>> 118:                 jbutton.setOpaque(true);
>> 
>> This should be the default value, I mean Swing components are usually opaque unless it's changed by app developer or look and feel. For example, rounded corners may make the component non-opaque as the background in the rounded corners has to be painted by the parent component.
>
> I have removed the additional setOpaque code. I am doing the necessary tests.

It seems like for the default Look ad Feel (Aqua) of Macosx an extra `setOpaque(true)` is needed. If the test test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java uses metal look and feel, `setOpaque(true)` is not needed and the test passes.

I have updated the MR accordingly.

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

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

From duke at openjdk.org  Fri Aug 15 17:53:12 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 15 Aug 2025 17:53:12 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v18]
In-Reply-To: <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <DYMGVqk6tz_-rtvl8oEzXzt2MXwWxYH1AExCYZDQIv4=.4c231fd8-08c8-4a63-80e3-f51fd64c7b82@github.com>
 <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
Message-ID: <BoEewukmQxTt8gtaYNQd36SAwFLdQF81TrPA-8KJ1qI=.3db2b79c-73fc-4068-a50a-837ca5056a2a@github.com>

On Tue, 12 Aug 2025 15:06:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates CountDownLatch waiting time to one second
>
> Strangely enough, these changes make no difference for me when I run Mixing tests locally. The same number of tests fails with and without this fix. However, it seems to affect the CI.
> 
> Additionally, I still see the windows / frames are minimised on Windows. I don't think this is expected, is it? Thus, your previous suggestion for increasing the size of the windows looks reasonable to me.

@aivanov-jdk both increasing the width of the frames and the requesting focus in frames worked for me. The test creates many frames and once a test completed for an AWT component, the next frame is created and shown on top of previously created frame (Maybe we can improve this by disposing the frame that finished testing ...). For each AWT component, a mixing frame is created. I will try on Windows and see if I can catch anything.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3192301954

From prr at openjdk.org  Fri Aug 15 19:02:10 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Aug 2025 19:02:10 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize()
In-Reply-To: <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>
Message-ID: <haYFtgNWOsWdvIIASSVV3jrxG9ThC-6_RQB4h-FPkm4=.3e5b5cfb-7fd5-40a4-8e1c-edfb6b35aa31@github.com>

On Thu, 14 Aug 2025 22:13:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Remove finalize() from WInputMethod.java - it is used to free a native id.
>> Also the reason dispose() didn't free it seems no longer relevant.
>> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
>> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.
>
> src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java line 165:
> 
>> 163:     @Override
>> 164:     public void dispose() {
>> 165:         disposerRecord.dispose();
> 
> The native dispose will call `ImmDestroyContext` which is specified as:
>> However, before calling ImmDestroyContext, the application must remove the input context from any association with windows in the thread by using the [ImmAssociateContext](https://learn.microsoft.com/en-us/windows/desktop/api/imm/nf-imm-immassociatecontext) function.
> 
> I did not check the code, but maybe we are calling `ImmAssociateContext` in the wrong moment and have to postpone this "dispose" until all the object is really unused?

This seems to be done by a native method WInputMethod.disableNativeIME(..) - which sets the IME for the window to NULL.  The native method is called from various places in WInputMethod.
I can't see that dispose or finalize would do anything to ensure that is called, or introduce any timing issues either way. So if there's a problem it is un-related.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2279695793

From prr at openjdk.org  Fri Aug 15 19:08:10 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Aug 2025 19:08:10 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
In-Reply-To: <xWy53TemnV-uH_GlxXhu5_21XzZN5iY6Bkp3eAg-PjI=.18ef29dc-d27f-450b-9677-8a51a2f1893e@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
 <xWy53TemnV-uH_GlxXhu5_21XzZN5iY6Bkp3eAg-PjI=.18ef29dc-d27f-450b-9677-8a51a2f1893e@github.com>
Message-ID: <qnp7zW8pwZO7k54u1TIz-xLfBKSbONpX7YvRNH-jtLU=.5829a3f4-a470-4185-ba0a-7e53744bfd9e@github.com>

On Thu, 14 Aug 2025 21:28:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Remove javax.imageio.spi.ServiceRegistry.finalize() since it is deprecated for removal.
>> The impact of this should be minimal. The IIORegistry will now be a singleton - which it already was 
>> in practice since Applets are no longer supported. Since it is a singleton, it will persist for the life
>> of the VM, so will never be garbage collected.
>> A test that verifies one per-AppContext is now obsolete, and is deleted, and there's no good reason to make it a negative test, since in due course AppContext itself will be deleted and is un-used today except in tests.
>> 
>> Since JDK 9, ServiceRegistry has supported only Image I/O specified providers, and since the IIORegistry does this,
>> in practice there is very little reason for an application to create instances or subclasses of it.
>> And even if they do, typically like IIORegistry, they be used for the life time of the application.
>> And if they are collected, without calling ServiceRegistry.deregisterAll() there may be no impact,
>> since only providers that implement RegisterableService will be affected.
>> 
>> See the JBS issue for all the details.
>> 
>> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8365409
>
> src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 109:
> 
>> 107:     private static final IIORegistry registry;
>> 108:     static {
>> 109:         registry = new IIORegistry();
> 
> Constructor of IIORegistry executes a large amount of code, might be better to load it lazily as before? instead of from the class initialization. could be a good opportunity to use StableValue?

I thought about that whilst making the change, but
(1) The javax.imagio.ImageIO class has this code

    private static final IIORegistry theRegistry =  IIORegistry.getDefaultInstance();

So it is going to get initialized really early on in virtually all uses of ImageIO, so doing as I did seems fine.

(2) The code in getDefaultInstance() is now going to run 1,000 times faster than it did before so stable value to get it running 2,000 times faster  probably is not necessary. And in any case, the version cached on ImageIO is what is going to be used. Hmm, it probably should not have been doing that as it defeated the AppContext, but it doesn't matter now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26752#discussion_r2279704926

From prr at openjdk.org  Fri Aug 15 20:06:20 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Aug 2025 20:06:20 GMT
Subject: Integrated: 8365198: Remove unnecessary mention of finalize in ImageIO
 reader/writer docs
In-Reply-To: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
References: <yg-YcN7GOEjquc31fJT--F213GvRASS4DkCWuCxbaZM=.3c4b44ec-73ff-4150-b95b-5b97cb48581b@github.com>
Message-ID: <5XShWwy5qEDxgEoOmIKQRa6V3QRYYJT0Q2bReljpRqQ=.792ee152-66a9-4e2f-8faf-7597e0137c26@github.com>

On Tue, 12 Aug 2025 20:46:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Image I/O's ImageReader and ImageWriter have never had finalize() methods, yet have a gratuitous mention of finalize(). This should be removed. Simple doc only change
> 
> CSR for review : https://bugs.openjdk.org/browse/JDK-8365410

This pull request has now been integrated.

Changeset: b69a3849
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b69a3849b21b4bb1e21ad276633de45da6200168
Stats:     4 lines in 2 files changed: 0 ins; 2 del; 2 mod

8365198: Remove unnecessary mention of finalize in ImageIO reader/writer docs

Reviewed-by: bchristi, azvegint

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

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

From serb at openjdk.org  Fri Aug 15 20:09:12 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Aug 2025 20:09:12 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
In-Reply-To: <qnp7zW8pwZO7k54u1TIz-xLfBKSbONpX7YvRNH-jtLU=.5829a3f4-a470-4185-ba0a-7e53744bfd9e@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
 <xWy53TemnV-uH_GlxXhu5_21XzZN5iY6Bkp3eAg-PjI=.18ef29dc-d27f-450b-9677-8a51a2f1893e@github.com>
 <qnp7zW8pwZO7k54u1TIz-xLfBKSbONpX7YvRNH-jtLU=.5829a3f4-a470-4185-ba0a-7e53744bfd9e@github.com>
Message-ID: <T0O3eFcOgl08lPO75GUV-qg_HpnfV5Jg6Yw1Fwi9_-o=.0ddcff17-0bef-4c00-ab76-add21cbe74af@github.com>

On Fri, 15 Aug 2025 19:05:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 109:
>> 
>>> 107:     private static final IIORegistry registry;
>>> 108:     static {
>>> 109:         registry = new IIORegistry();
>> 
>> Constructor of IIORegistry executes a large amount of code, might be better to load it lazily as before? instead of from the class initialization. could be a good opportunity to use StableValue?
>
> I thought about that whilst making the change, but
> (1) The javax.imagio.ImageIO class has this code
> 
>     private static final IIORegistry theRegistry =  IIORegistry.getDefaultInstance();
> 
> So it is going to get initialized really early on in virtually all uses of ImageIO, so doing as I did seems fine.
> 
> (2) The code in getDefaultInstance() is now going to run 1,000 times faster than it did before so stable value to get it running 2,000 times faster  probably is not necessary. And in any case, the version cached on ImageIO is what is going to be used. Hmm, it probably should not have been doing that as it defeated the AppContext, but it doesn't matter now.

I am not worried much about performance, but I am concerned about the possibility of a deadlock in static initializers, since the services loaded by the IIORegistry can trigger any code.

btw why not "private static final IIORegistry registry = new IIORegistry();"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26752#discussion_r2279797615

From serb at openjdk.org  Fri Aug 15 20:13:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Aug 2025 20:13:09 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize()
In-Reply-To: <haYFtgNWOsWdvIIASSVV3jrxG9ThC-6_RQB4h-FPkm4=.3e5b5cfb-7fd5-40a4-8e1c-edfb6b35aa31@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>
 <haYFtgNWOsWdvIIASSVV3jrxG9ThC-6_RQB4h-FPkm4=.3e5b5cfb-7fd5-40a4-8e1c-edfb6b35aa31@github.com>
Message-ID: <mvREF1kqmZjo-lY7XzSfcS-HcXMIjBW5QMkvIwnlx1w=.5b527fa4-6617-485d-ac23-2bc159b6bac8@github.com>

On Fri, 15 Aug 2025 18:59:22 GMT, Phil Race <prr at openjdk.org> wrote:

>I can't see that dispose or finalize would do anything to ensure that is called, or introduce any timing issues either way. So if there's a problem it is un-related.

Maybe disableNativeIME is called when the top level Window is disposed, and after that there are no more references to WInputMethod? In that case, it is safe to call it from finalize(), but it might not be as safe to call it from dispose(), which mighe be called before "WInputMethod.disableNativeIME"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2279803095

From dnguyen at openjdk.org  Fri Aug 15 20:35:10 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 15 Aug 2025 20:35:10 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
Message-ID: <l7xPQ8caEAWG9vkOL1aex_Qiksh-mbzLZc0FDv8MkT8=.e0ab791c-c2f4-45ad-aa2a-53bbbfbecdd3@github.com>

On Thu, 14 Aug 2025 16:53:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> This refactors some Swing code to pass args instead of using statics
>> The bug report suggests some further refactoring which could be considered later, but the most
>> important thing to do is to eliminate using statics to pass args.
>> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365389

Removal looks correct when I compare it to the original implementation PR. Double-checked this by building and testing the changes on all OS's and I don't see any issues. LGTM

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26783#pullrequestreview-3125073720

From aivanov at openjdk.org  Fri Aug 15 20:50:24 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 15 Aug 2025 20:50:24 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <UHlPRLuoZgzMhzLwUwIPZ9v03eoXJ4xP9baxJe8s8AM=.61f79f13-3349-413b-96b3-a5d62aae94c0@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <v-FrdpvVwZ7M4_rWKyL_9iocs12j_fcBgu8bilYL-LM=.7105c561-7540-494b-8f0a-dacead39e181@github.com>
 <1LHpS99_1k2FHxyif6Zq3wSyHl1uVCrgSgvVd_oUNxg=.45e166d3-fe3e-4525-9bf2-fe235c1fad90@github.com>
 <UHlPRLuoZgzMhzLwUwIPZ9v03eoXJ4xP9baxJe8s8AM=.61f79f13-3349-413b-96b3-a5d62aae94c0@github.com>
Message-ID: <pPg_OM8KUmYPGCOGN6gVL6dhEtiAiTZjWUKpmKkRsVc=.97504b1a-fc83-48af-8c69-9a5c7f59e836@github.com>

On Mon, 11 Aug 2025 16:29:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I believe there's a potential bug in `WindowsMenuItemUI.java` in the newly overridden method and new static fields. There's a chance that the colors aren't updated when needed. Yet I haven't come up with a test.

It's not a potential bug, it's a real bug [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625): *Can't change accelerator colors in Windows L&F*.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2279861749

From jwood at openjdk.org  Fri Aug 15 20:59:07 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 15 Aug 2025 20:59:07 GMT
Subject: RFR: 8303904: [macos]Transparent Windows Paint Wrong (Opaque,
 Pixelated) w/o Volatile Buffering [v3]
In-Reply-To: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
References: <LfyPFIwnUZ6_uiI7zO-N3Do8fAw6lnbGISMt2FQbFqo=.132cd64d-745b-4237-a04d-db3649bf82ad@github.com>
Message-ID: <7wu5iS5ycTC0izi9-Baiuavz5rwEobXIFwF07e_6Rms=.1bda8c5b-1998-4ba6-87f9-f46795c7b6fc@github.com>

> When "swing.volatileImageBufferEnabled" is false: we were mistakenly using an opaque image at 100% resolution.
> 
> In hindsight the original ticket probably should be split up into two distinct issues:
> 1. The window is opaque, so pixels that should be transparent are black.
> 2. The window is the wrong resolution. On a 200% resolution monitor it renders as if it were 100% (so it looks pixelated).
> 
> This PR started 2 years ago. I got stuck and abandoned it, and @anass-baya picked it back up again this year: https://github.com/openjdk/jdk/pull/23430/

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

 - 8303904: comment cleanup
 - 8303904: designing around imagined edge cases
   
   I don't know if these will ever come up in the real world, but since this is critical infrastructure I want to be careful. (A Swing app may become unusable if this code fails.)
   
   Concern A:
   In the event our AffineTransform is a rotation or a flip:
   Now we'll use the c.createImage(virtualWidth, virtualHeight), which means we fall back to the code we've been using for over a decade.
   
   Concern B:
   In the event our AffineTransform scales to zero, we'll at least make the image 1x1.
 - 8303904: minor cleanup
 - 8303904: minor cleanup
 - 8303904: minor cleanup
   
   This makes this method ALWAYS return a BackingStoreMultiResolutionImage, even if the scaled size is the same as the virtual size. (Just because making this method return a BufferedImage OR a BackingStoreMultiResolutionImage seems like an unnecessary level of abstraction; and that could turn into a potential point of confusion for future devs.)
 - 8303904: use BackingStoreMultiResolutionImage
   
   It's functionally the same thing; this is just reusing code (and it avoids the hacky fake image involving getScaledInstance).
 - Revert "8303904: support rotated GraphicsConfiguration"
   
   This reverts commit 55b1a708cdc8608824d04974ad96b62fd50149d3.
 - Revert "8303904: fixing AffineTransform fields"
   
   This reverts commit 2d32aaf0e670a9967877e5a4bf4c0ec1079bb070.
 - 8303904: refactor BackingStoreMultiResolutionImage
   
   Convert this private a private internal class to its own package private class
 - 8303904: code cleanup
   
   Removing old changes that don't apply, & updating copyright year.
 - ... and 20 more: https://git.openjdk.org/jdk/compare/04de4688...ee0d8b1e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13196/files
  - new: https://git.openjdk.org/jdk/pull/13196/files/ffc8ff44..ee0d8b1e

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

  Stats: 3878291 lines in 32738 files changed: 1876616 ins; 1371022 del; 630653 mod
  Patch: https://git.openjdk.org/jdk/pull/13196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13196/head:pull/13196

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

From prr at openjdk.org  Fri Aug 15 21:24:10 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Aug 2025 21:24:10 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
Message-ID: <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>

On Fri, 15 Aug 2025 15:18:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.

Yes I do. I overlooked them.

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

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3192793910

From aivanov at openjdk.org  Fri Aug 15 21:27:15 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 15 Aug 2025 21:27:15 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
 <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>
Message-ID: <7m9fDENxqmPnasJA7urxLaf3t2BrJOCHCstw6aWq2xo=.40aa98dd-db7f-4594-ac1c-be55e32b8998@github.com>

On Fri, 15 Aug 2025 21:21:05 GMT, Phil Race <prr at openjdk.org> wrote:

> > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
> 
> Yes I do. I overlooked them.

If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.

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

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3192800729

From prr at openjdk.org  Fri Aug 15 22:12:09 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Aug 2025 22:12:09 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <7m9fDENxqmPnasJA7urxLaf3t2BrJOCHCstw6aWq2xo=.40aa98dd-db7f-4594-ac1c-be55e32b8998@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
 <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>
 <7m9fDENxqmPnasJA7urxLaf3t2BrJOCHCstw6aWq2xo=.40aa98dd-db7f-4594-ac1c-be55e32b8998@github.com>
Message-ID: <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>

On Fri, 15 Aug 2025 21:24:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
> > 
> > 
> > Yes I do. I overlooked them.
> 
> If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.

oh. ok. I guess I will look at your test case and confirm that  .. and looks like it is a fully done regression test.
Maybe you want to push that yourself ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3192873422

From rgupta at openjdk.org  Mon Aug 18 06:18:30 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Mon, 18 Aug 2025 06:18:30 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v9]
In-Reply-To: <r7frTU2JrTpy48099SEiSJ0QWFG73NX3VnchFZn0kWY=.a0df6347-ed8e-4709-8442-bb25c9243aee@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
 <r7frTU2JrTpy48099SEiSJ0QWFG73NX3VnchFZn0kWY=.a0df6347-ed8e-4709-8442-bb25c9243aee@github.com>
Message-ID: <ZCShAQj3vK8PR0TRXwcWMl1HnNEUxNJ72B1bDCfI5Z8=.3f04f0b8-2fed-45fd-b6d1-9900894c121e@github.com>

On Wed, 13 Aug 2025 22:11:47 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361067: Added review comment
>
> Tested on macOS and Ubuntu 24.04 (Wayland & X). Test passes on all except I get a timeout error on Wayland. Can you confirm that this test passes on your end on Wayland?

@DamonGuy I have tested it on Ubuntu 20.4 wayland  its runs fine.


jpgansible at blrsqe011:~/ravi$ uname -a
Linux blrsqe011.in.oracle.com 6.14.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Sun Apr  6 15:05:05 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
jpgansible at blrsqe011:~/ravi$ loginctl show-session $(awk '/tty/ {print $1}' <(loginctl)) -p Type | awk -F= '{print $2}'
wayland
jpgansible at blrsqe011:~/ravi$ jdk-26/bin/java -version
java version "26-ea" 2026-03-17
Java(TM) SE Runtime Environment (build 26-ea+9-927)
Java HotSpot(TM) 64-Bit Server VM (build 26-ea+9-927, mixed mode, sharing)
jpgansible at blrsqe011:~/ravi$ jdk-26/bin/java ExtraButtonDrag.java 
areExtraMouseButtonsEnabled() == true
button to drag = 1 : value passed to robot = 1024
button to drag = 2 : value passed to robot = 2048
button to drag = 3 : value passed to robot = 4096
Test Passed
jpgansible at blrsqe011:~/ravi$

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

PR Comment: https://git.openjdk.org/jdk/pull/26043#issuecomment-3195266957

From duke at openjdk.org  Mon Aug 18 08:12:26 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 18 Aug 2025 08:12:26 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v18]
In-Reply-To: <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <DYMGVqk6tz_-rtvl8oEzXzt2MXwWxYH1AExCYZDQIv4=.4c231fd8-08c8-4a63-80e3-f51fd64c7b82@github.com>
 <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
Message-ID: <rTUf3capbAYoI4ra_BkY7d9VSWBf414PXF4wJoJ_1Tg=.34b06212-57e6-4156-af84-1e1e13f35f86@github.com>

On Tue, 12 Aug 2025 15:06:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates CountDownLatch waiting time to one second
>
> Strangely enough, these changes make no difference for me when I run Mixing tests locally. The same number of tests fails with and without this fix. However, it seems to affect the CI.
> 
> Additionally, I still see the windows / frames are minimised on Windows. I don't think this is expected, is it? Thus, your previous suggestion for increasing the size of the windows looks reasonable to me.

@aivanov-jdk I have tested all tests with the new modifications and they passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3195585011

From duke at openjdk.org  Mon Aug 18 08:13:21 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 18 Aug 2025 08:13:21 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v11]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <wg6uOducZTaw9q8nyAIvOHbAsMuOEaXhmOixDeXQAIg=.0e0329ec-7a74-4030-9564-35440cdac547@github.com>

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

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

 - Merge branch 'pr/25971' into jdk-8360498
 - Removes extra white lines
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8360498
 - Revert "Accept color differences to less or equal to 15"
   
   This reverts commit a98db3e22781088eccd95912697853355f22645e.
 - Accept color differences to less or equal to 15
 - Changes the look and feel to the default Metal
 - Removes setOpqaue for swing buttons
 - Renames color tolerance for macosx
 - Uses simplified statement in method isAlmostEqualColor
 - ... and 16 more: https://git.openjdk.org/jdk/compare/89cb725a...ecf7d3cf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/e2b13d6f..ecf7d3cf

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

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

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

From duke at openjdk.org  Mon Aug 18 08:13:22 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 18 Aug 2025 08:13:22 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v10]
In-Reply-To: <AYqusdqEtMO6jvog8FCHsea_U0H0YPrTkk0F_6NmI10=.9b34655d-2535-41a3-b4f9-f8bd9b7ffe74@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
 <AYqusdqEtMO6jvog8FCHsea_U0H0YPrTkk0F_6NmI10=.9b34655d-2535-41a3-b4f9-f8bd9b7ffe74@github.com>
Message-ID: <RARHAd2XKsNBtXt-_VCYKYdFLcQVxjo9b42ozjZV1jk=.7eca04d9-be16-47bc-ace3-e642c753784f@github.com>

On Fri, 15 Aug 2025 17:29:16 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

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

Modifications tested and passed.

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

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

From lkorinth at openjdk.org  Mon Aug 18 09:10:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:10:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
Message-ID: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>

On Fri, 15 Aug 2025 14:05:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD
>
> make/RunTests.gmk line 940:
> 
>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
> 
> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281781536

From lkorinth at openjdk.org  Mon Aug 18 09:18:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:18:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
Message-ID: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>

On Mon, 18 Aug 2025 09:07:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> make/RunTests.gmk line 940:
>> 
>>> 938:   JTREG_AUTO_PROBLEM_LISTS :=
>>> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
>>> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1
>> 
>> Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()
>
> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.

It is also something that can be changed later, in a follow up fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2281802454

From lkorinth at openjdk.org  Mon Aug 18 09:36:13 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:36:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v2]
In-Reply-To: <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <FAfomNqQZ68cLZ8lLab4J-SlYDDrwD9QFEQvRha6PP8=.bae56224-0952-468e-bf52-fb3314837f6b@github.com>
 <Ry1BVoIGQcgUyTubSblCxho0XWOogM-rB0dQ89SKcIw=.df6e7284-c874-494f-8083-5f9dc3ea4d4e@github.com>
Message-ID: <3l5I9q7S4O_0gH6mvxy3P21f1JxqcQKNsnBTN7rWhmc=.ddcf4337-dc6e-493d-ae07-5bd4affb9321@github.com>

On Thu, 14 Aug 2025 19:30:30 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> Would you mind also running tier9 to avoid surprises there.

I had problems doing this, and I just want to say that I have not run tier9 (I have talked to Douglas off-list).

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195900610

From lkorinth at openjdk.org  Mon Aug 18 09:43:14 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 09:43:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <9GMJWT-CNwqDVALuPdRR9EDs5G1c2jUr3y887qw2_EU=.1a7347a2-d1e5-427d-aeda-6924e2db39ba@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

If there are no mayor objections, I will update the copyrights before I leave work today.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3195923727

From duke at openjdk.org  Mon Aug 18 10:07:16 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 18 Aug 2025 10:07:16 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v18]
In-Reply-To: <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <DYMGVqk6tz_-rtvl8oEzXzt2MXwWxYH1AExCYZDQIv4=.4c231fd8-08c8-4a63-80e3-f51fd64c7b82@github.com>
 <-mQROJ38JBo_d3HgZdxAbqBtc2L-GKe6vnmgO8Dnibc=.bcc14656-eeb0-4d91-9b59-bda58f924526@github.com>
Message-ID: <TK3YfkSDJX5AJsaEoFjMorNc_0SmeOR-dEbpPSiivDA=.9145883c-6388-4cc8-b84d-ec0c6a7a77c3@github.com>

On Tue, 12 Aug 2025 15:06:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates CountDownLatch waiting time to one second
>
> Strangely enough, these changes make no difference for me when I run Mixing tests locally. The same number of tests fails with and without this fix. However, it seems to affect the CI.
> 
> Additionally, I still see the windows / frames are minimised on Windows. I don't think this is expected, is it? Thus, your previous suggestion for increasing the size of the windows looks reasonable to me.

@aivanov-jdk I have tested on a Windows 11 Pro, before and after the fix in this PR, and I can see only 3 tests failing after an initial 26 failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3196011730

From dfuchs at openjdk.org  Mon Aug 18 11:38:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 11:38:14 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:


	java/net/httpclient/CancelledResponse.java
	java/net/httpclient/whitebox/FlowTestDriver.java


The	first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196281299

From duke at openjdk.org  Mon Aug 18 12:39:27 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 18 Aug 2025 12:39:27 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v22]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <OWno_9zAgEhwtlkhPeKMlHC1VvUxozVvqNyCXeiU1e0=.d3e5b967-a942-4a5c-9a5f-ace713d0ae35@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers frames in the middle of the screen
 - Releses latch in case of null ancestor or resizing component
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Merge branch 'openjdk:master' into jdk-8158801
 - Updates CountDownLatch waiting time to one second
 - Requests focus, if component does not have it already.
 - Merge branch 'openjdk:master' into jdk-8158801
 - ... and 24 more: https://git.openjdk.org/jdk/compare/c037b58a...3fac9c1e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/4df40993..3fac9c1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=20-21

  Stats: 4265 lines in 110 files changed: 3447 ins; 443 del; 375 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From liach at openjdk.org  Mon Aug 18 13:09:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 13:09:12 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Marked as reviewed by liach (Reviewer).

Do we need a update to `EditPadTest` to ensure all parts of that JFrame is rendered on the screen?

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

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3128297469
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3196742832

From rriggs at openjdk.org  Mon Aug 18 13:15:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Aug 2025 13:15:11 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings.  The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3196793327

From duke at openjdk.org  Mon Aug 18 13:16:14 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 18 Aug 2025 13:16:14 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <pqDRhNoCmC9CO2u75fvkVJD1BdvMpKzojfHlJHhmzS4=.a3650b28-c08c-4b38-b9b6-e4394531a616@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
 <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
 <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
 <pqDRhNoCmC9CO2u75fvkVJD1BdvMpKzojfHlJHhmzS4=.a3650b28-c08c-4b38-b9b6-e4394531a616@github.com>
Message-ID: <iH62n0XFuue_UsravO9gSE4Lvv-Kbw7bXSGCSSAGaTg=.69d4f784-21a6-4ad5-8145-32950bfa19e7@github.com>

On Wed, 6 Aug 2025 07:04:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
>> 
>> WHich test in particular? or is it all tests have this behavior?
>> 
>>> The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
>> 
>> I tried JMenuBarOverlapping.java but I dont see any click on title bar..The cursor in on top-left of "Test Menu" menu..
>> If clicking on the title bar is needed to make it gain focus, probably you can try with calling `frame.requestFocus` and use `CountDownLatch `with timeout to wait till FOCUS_GAINED event is received and release the latch in `focusGained()` and then start the test
>
>> @prsadhuk after applying your suggested change, I can see that it has fixed the issue for most of the tests but still the following tests didn't pass on Windows compared with the original fix of changing frame width :
>> 
>> java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java
>> 
>> I will check why these tests had failed.
> 
> I see this tests are also deproblemlisted despite mentioning they fail, so my idea of CountDownLatch for focus gain event solved these too?

@prsadhuk I have updated this PR to center all possible tests in the middle of the screen.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3196801009

From duke at openjdk.org  Mon Aug 18 13:22:58 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 18 Aug 2025 13:22:58 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v23]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <8dn5G3cN32T_u5d1P_n5iMLscKrT7q1a4by6b67NxjU=.792efe80-015d-4a2a-8e17-9411adc7f1d5@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

  Updates copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/3fac9c1e..ffbe6963

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=21-22

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

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

From liach at openjdk.org  Mon Aug 18 13:45:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 13:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <opdfOPyKKszYq-pDpA0Wpc2Jr0SUJ3INrYZO9u-JrOQ=.c5bc2321-d9d9-44d3-8958-c4d60bd10483@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Hi @davidalayachew, can you update the copyright year at top from `2015, 2016,` to `2015, 2025,`?

In addition, according to https://openjdk.org/guide, we usually leave 24 hours for sufficient review. This applies so you should type `/integrate` later in the future.

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

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3128437299

From cstein at openjdk.org  Mon Aug 18 13:54:10 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 18 Aug 2025 13:54:10 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>
Message-ID: <dx4tj2Ea92bkxySR9HGda6Gug112NfCzkfdOB3J4AdM=.084fb73d-1394-4fbd-b9b8-74b3c4ff3683@github.com>

On Mon, 18 Aug 2025 13:04:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> Do we need a update to EditPadTest to ensure all parts of that JFrame is rendered on the screen?

I think such a test, if deemed necessary, should be added to the "core" Swing tests instead. Here, it would be an implementation detail that only applies to screens equal or larger than 800x600 in dimension ... on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3197031599

From lkorinth at openjdk.org  Mon Aug 18 14:34:12 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 14:34:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <G6fg3H3q9Nns8tnPCwBHcm2ZNGdbejBJemr7U6SXfFE=.b589d615-10bf-4bb9-a191-acaff67d05dd@github.com>
Message-ID: <lSUzoh2lhdmeEPYY2eAAGIycS8QSm5_9BLFy7FgOfFw=.f7a8acc4-ead5-4625-9d3c-83a345212193@github.com>

On Mon, 18 Aug 2025 13:12:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally, changes with this many changed files are broken down into smaller PRs to make the review easier and more conclusive. In this case, hotspot, jdk, and langtools might have been good groupings. The reviews could be done in parallel and committed with the final change to jtreg when they are all approved.

Noted. I did it so reviewers could se the change "as a whole". Feel free to review a part of the change!

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197186029

From aivanov at openjdk.org  Mon Aug 18 14:38:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 14:38:11 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <y43eYR60e2f3eeiBKwwWRv8CjHqRnSw2p5nzOrinjm0=.bd36d275-26a9-465c-87e6-ae0dff7a48d3@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Looks good to me.

I agree the copyright year should be updated in `EditPad.java`.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3128658090

From aivanov at openjdk.org  Mon Aug 18 14:41:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 14:41:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <dx4tj2Ea92bkxySR9HGda6Gug112NfCzkfdOB3J4AdM=.084fb73d-1394-4fbd-b9b8-74b3c4ff3683@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <-LIKwKsekoa_7v91mqv5_T1oi9LQWNGgEBElNn16m_w=.58136d63-9fd9-4373-8296-08dd85de5f5b@github.com>
 <dx4tj2Ea92bkxySR9HGda6Gug112NfCzkfdOB3J4AdM=.084fb73d-1394-4fbd-b9b8-74b3c4ff3683@github.com>
Message-ID: <IYZMQiwcRkqvzI4vt_ZjzbI5mtp4jW4C7LraXMdJMtw=.6703656a-aa84-49bd-9489-04f65250b6b6@github.com>

On Mon, 18 Aug 2025 13:51:07 GMT, Christian Stein <cstein at openjdk.org> wrote:

> > Do we need a update to EditPadTest to ensure all parts of that JFrame is rendered on the screen?
> 
> I think such a test, if deemed necessary, should be added to the "core" Swing tests instead. Here, it would be an implementation detail that only applies to screens equal or larger than 800x600 in dimension ... on Windows.

If the screen resolution is 800?600, the frame with the same size can't fit because the screen usually has other elements, such a taskbar, covering portion of the screen.

If it's assumed that no screen is less than 800?600, then the fix is fine; yet if a screen resolution happens to be less than that, the edit pad frame won't fit on the screen.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3197210945

From lmesnik at openjdk.org  Mon Aug 18 15:01:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 18 Aug 2025 15:01:12 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
Message-ID: <O_WRSR2Q7KM1CWMYPxfXyFQI3lU9AjTOklWNVYAxvUk=.387e933f-0eed-43d8-a2eb-dbe2dd98cc75@github.com>

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

Thank you for fixing this! I think the changes are good.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3128749995

From serb at openjdk.org  Mon Aug 18 16:08:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 18 Aug 2025 16:08:39 GMT
Subject: RFR: 8359380: Rework deferral profile logic after JDK-8346465 [v3]
In-Reply-To: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
References: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
Message-ID: <73LMZ7SufcJL7MaITCJQvOSJVOiKNN-b2si0um7YaPg=.7a4794eb-8444-4321-872a-2cb6793d814e@github.com>

> The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
> 
> After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
> 
> This patch includes two changes:
> 
> 1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
> 
> 2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

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

 - Merge branch 'openjdk:master' into JDK-8359380
 - Merge branch 'openjdk:master' into JDK-8359380
 - pdi->bpi
 - Update workaround for 8272860
 - 8359380: Rework deferral profile logic after JDK-8346465

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26179/files
  - new: https://git.openjdk.org/jdk/pull/26179/files/78ba5480..b095c5b2

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

  Stats: 9060 lines in 278 files changed: 5706 ins; 2442 del; 912 mod
  Patch: https://git.openjdk.org/jdk/pull/26179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26179/head:pull/26179

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

From simonis at openjdk.org  Mon Aug 18 16:12:30 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 18 Aug 2025 16:12:30 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to JDK
 8
Message-ID: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>

### TL;DR

This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.

I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  

In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.

### Full description

A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)

Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):

Segment: ?????????? 0 10
Segment: ????????? 10 9
Segment: ???????? 19 8
Segment: ? 27 1

I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) fonts but the results were similar, so I'll stick to KhmerOS for the reminder of this blog.

As you can see, the paragraph was broken after the 10th, 19th, and 27th characters respectively. However, with JDK 9+, the output regresses to:

Segment: ?????????? 0 10
Segment: ???? 10 4
Segment: ? 14 1
Segment: ????????????? 15 13

We now have a premature break after 14 characters, a segment with just a single character and the last line is too long.

In order to verify if there's a difference in the layout and rendering of this sentence between JDK 8 and 9+ I [extended the initial reproducer](./src/java/KhmerTestSwing.java) to paint the whole sentence as well as the single line segments into a Swing `JPanel`. Here's the result for JDK 8:

![](https://raw.githubusercontent.com/simonis/READMEs/refs/heads/master/images/KhmerTestSwing_Corretto8.png)

And JDK 9+:

![](https://raw.githubusercontent.com/simonis/READMEs/refs/heads/master/images/KhmerTestSwing_Corretto21.png)

As can be seen, the whole sentence is laid out and rendered correctly in JDK 9+ as well, as long as it completely fits into a single line. However, in JDK 9+ there's an issue with line breaking at the "????" ligature (highlighted with a red box in the above pictures). This specific ligature is composed from the glyphs of four Unicode code  points, namely `U+178F` ("?", KHMER LETTER TA), `U+17D2` ("?", KHMER SIGN COENG), `U+179A` ("?", KHMER LETTER RO) and `U+17BC` ("?", KHMER VOWEL SIGN UU) ". If rendered correctly, `U+179A` is reordered (visually) before `U+178F` and `U+17BC` below `U+179A`. The visual reordering of `U+179A` before `U+178F` is controlled by `U+17D2` which is not itself represented visually.

In OpenJDK, all this complex text layout is performed by a so called text layout or shaping engine. Up to and including JDK 8, OpenJDK used the [ICU Layout Engine](https://unicode-org.github.io/icu/userguide/layoutengine/) for this task. In JDK 9, the ICU layout engine was deprecated and replaced by [Harfbuzz](https://github.com/harfbuzz/harfbuzz) (see [JEP 258: HarfBuzz Font-Layout Engine](https://bugs.openjdk.org/browse/JDK-8064530)). Whenever OpenJDK will have to do complex text layout, it will eventually call into tha native layout engine. For the current JDK 25 this looks as follows:


at sun.font.HBShaper.shape(HBShaper.java:460)
at sun.font.SunLayoutEngine.layout(SunLayoutEngine.java:182)
at sun.font.GlyphLayout$EngineRecord.layout(GlyphLayout.java:669)
at sun.font.GlyphLayout.layout(GlyphLayout.java:459)
at sun.font.GlyphLayout.layout(GlyphLayout.java:357)
at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:333)
at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:319)
at sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:638)
at sun.font.ExtendedTextSourceLabel.getCharinfo(ExtendedTextSourceLabel.java:563)
at sun.font.ExtendedTextSourceLabel.getLineBreakIndex(ExtendedTextSourceLabel.java:486)
at java.awt.font.TextMeasurer.calcLineBreak(TextMeasurer.java:330)
at java.awt.font.TextMeasurer.getLineBreakIndex(TextMeasurer.java:566)
at java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:360)
at java.awt.font.LineBreakMeasurer.nextOffset(LineBreakMeasurer.java:329)
at KhmerTestSwing.main(KhmerTestSwing.java:82)


Notice that since JDK 22, this is done through a new FFM based interface defined in [`HBShaper_Panama.c`](https://github.com/openjdk/jdk/blob/jdk25/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c) (see [8318364: Add an FFM-based implementation of harfbuzz OpenType layout](https://bugs.openjdk.org/browse/JDK-8318364)) by default, but can still be configured to use the old JNI-based interface (in [`HBShaper.c`](https://github.com/openjdk/jdk/blob/jdk25/src/java.desktop/share/native/libfontmanager/HBShaper.c)) with the `-Dsun.font.layout.ffm=false` system property. In the end, they both call into the bundled, native HarfBuzz function [`hb_shape_full(..)`](https://github.com/openjdk/jdk/blob/6c48f4ed707bf0b15f9b6098de30db8aae6fa40f/src/java.desktop/share/native/libharfbuzz/hb-shape.cc#L127) which takes a font and a buffer of characters (i.e. Unicode code points) as input and returns a buffer of font glyphs along with their metrics and some meta-information as output (here 
 you can find the original [HarfBuzz upstream version](https://github.com/harfbuzz/harfbuzz/blob/0a257b0188ce8b002b51d9955713cd7136ca4769/src/hb-shape.cc#L127)).

HarfBuzz has a [nice documentation](https://harfbuzz.github.io/index.html) which explains a lot of the concepts involved in complex text layout (called "shaping" in HarfBuzz). The relevant part for this discussion is the section on [Clusters and shaping](https://harfbuzz.github.io/clusters.html#clusters-and-shaping) which basically explains the implementation and usage of the [`hb_shape_full()](https://harfbuzz.github.io/harfbuzz-hb-shape.html#hb-shape-full) function.

Previously, in JDK 8, `SunLayoutEngine::layout()` called the native `SunLayoutEngine::nativeLayout()` function which called right into the native, bundled ICU method [`LayoutEngine::layoutChars()`](https://github.com/openjdk/jdk8u-dev/blob/89b85a8f5b0f8e4f7763cf9b4d15e051d6e9f43f/jdk/src/share/native/sun/font/layout/LayoutEngine.cpp#L553) (here's the original [ICU upstream version](https://github.com/unicode-org/icu/blob/8fbc9902bd2ec278ae471b8215cdcc2d1cf13555/source/layout/LayoutEngine.cpp#L442)). The ICU Layout engine is documented [here](https://unicode-org.github.io/icu/userguide/layoutengine/).

The GitHub HarfBuzz organization contains the [`icu-le-hb`](https://github.com/harfbuzz/icu-le-hb) repository which provides a library exposing the ICU Layout Engine API
by using HarfBuzz as internal implementation. Its [`LayoutEngine::layoutChars()`](https://github.com/harfbuzz/icu-le-hb/blob/01b8e255d08a9ea2c2a0665f2b673fe9e71c7ec1/src/LayoutEngine.cpp#L180) method demonstrates how HarfBuzz can be invoked to simulate ICU's layout functionality. We'll revisit its implementation later in this document.

### The ICU layout engine

In order to identify the differences between the two layout engines, we can use the system property `-Dsun.java2d.debugfonts=true` on JDK 9+. For JDK 8, we have to recompile the JDK and set the private, boolean [`DEBUG`](https://github.com/openjdk/jdk8u-dev/blob/89b85a8f5b0f8e4f7763cf9b4d15e051d6e9f43f/jdk/src/share/classes/sun/font/ExtendedTextSourceLabel.java#L640) field in the `sun.font.ExtendedTextSourceLabel` class to true in order to get a similar output. In JDK 8 this will result in the following output from the method [`ExtendedTextSourceLabel::createCharinfo()`](https://github.com/openjdk/jdk8u-dev/blob/89b85a8f5b0f8e4f7763cf9b4d15e051d6e9f43f/jdk/src/share/classes/sun/font/ExtendedTextSourceLabel.java#L618) which translates from the Glyph information computed by the layout engine back to character information:


number of glyphs: 30
glyphinfo.len: 240
indices.len: 30
g: 0  v: 455, x: 0.0, a: 68.115234, n: 0
g: 1  v: 65534, x: 68.115234, a: 0.0, n: 1
g: 2  v: 581, x: 68.115234, a: 45.410156, n: 2
g: 3  v: 627, x: 113.52539, a: 22.705078, n: 6
g: 4  v: 593, x: 136.23047, a: 68.115234, n: 3
g: 5  v: 402, x: 205.07812, a: 0.0, n: 4
g: 6  v: 65535, x: 204.3457, a: 0.0, n: 5
g: 7  v: 714, x: 203.61328, a: 0.0, n: 6
g: 8  v: 593, x: 204.3457, a: 68.115234, n: 7
g: 9  v: 621, x: 271.72852, a: 0.0, n: 8
g: 10  v: 632, x: 271.72852, a: 0.0, n: 9
g: 11  v: 627, x: 272.46094, a: 22.705078, n: 11
g: 12  v: 503, x: 295.16602, a: 68.115234, n: 10
g: 13  v: 65534, x: 363.28125, a: 0.0, n: 11
g: 14  v: 628, x: 363.28125, a: 22.705078, n: 13
g: 15  v: 577, x: 385.98633, a: 45.410156, n: 12
g: 16  v: 409, x: 431.39648, a: 22.705078, n: 15
g: 17  v: 65535, x: 454.10156, a: 0.0, n: 16
g: 18  v: 577, x: 454.10156, a: 45.410156, n: 14
g: 19  v: 622, x: 498.04688, a: 0.0, n: 17
g: 20  v: 590, x: 499.51172, a: 22.705078, n: 18
g: 21  v: 455, x: 522.2168, a: 68.115234, n: 19
g: 22  v: 65534, x: 590.33203, a: 0.0, n: 20
g: 23  v: 581, x: 590.33203, a: 45.410156, n: 21
g: 24  v: 582, x: 635.7422, a: 45.410156, n: 22
g: 25  v: 572, x: 681.15234, a: 45.410156, n: 23
g: 26  v: 617, x: 725.09766, a: 0.0, n: 24
g: 27  v: 627, x: 726.5625, a: 22.705078, n: 26
g: 28  v: 593, x: 749.2676, a: 68.115234, n: 25
g: 29  v: 580, x: 817.3828, a: 45.410156, n: 27


First, there's the glyph list produced by layout engine. It contains 30 glyphs (two more than the 28 characters of our input text). For each glyph, we see its glyph ID in the font that is used, the x-position of that glyph in the final image and the [advance](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/GlyphMetrics.html#getAdvance()), i.e. its space up to the next glyph (notice that the advance can be zero). E.g. we can easily verify that the first glyph with the number 455 (i.e. "??") corresponds to the the ligature of the first two characters `U+1794` ("?", KHMER LETTER BA) and `U+17B6` ("?", KHMER VOWEL SIGN AA) in our `KhmerOS.ttf` font by uploading that font file to https://fontdrop.info/ and searching for the glyph number 455 (the glyph name is `uni1794.a` which indicates that it is a ligature of the unicode character `U+1794` and the vowel AA).

The last column in the output is the [cluster number](https://harfbuzz.github.io/clusters.html#clusters-and-shaping) to which the corresponding glyph belongs to. So in our example, the zeroth glyph belongs to the zeroth cluster, while glyph one belongs to the first cluster. Glyph one is interesting, because we can't find a glyph with index 65534 in the font. Actually, glyph indices which are greater or equal to 65534 (i.e. `0xFFFE` and `0xFFFF`) denote "*invisible glyphs*". These constants are e.g. defined e.g. in [`sun.font.CharToGlyphMapper`](https://github.com/openjdk/jdk/blob/2b756ab1e8cfacc5cf5d9c6dfdf1d1c9a6ecf4b1/src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java#L45-L46):


    public static final int INVISIBLE_GLYPH_ID = 0xffff;
    public static final int INVISIBLE_GLYPHS   = 0xfffe; // and above

The ICU Layout Engine inserts these "invisible glyphs" for characters that were substituted by ligatures in [`LigatureSubstitutionSubtable::process()`](https://github.com/openjdk/jdk8u-dev/blob/89b85a8f5b0f8e4f7763cf9b4d15e051d6e9f43f/jdk/src/share/native/sun/font/layout/LigatureSubstSubtables.cpp#L90) (depending on whether the [OpenType  `IgnoreMarks` lookup flag](https://github.com/openjdk/jdk8u-dev/blob/89b85a8f5b0f8e4f7763cf9b4d15e051d6e9f43f/jdk/src/share/native/sun/font/layout/LigatureSubstSubtables.cpp#L90) is set, it will insert either `0xFFFE` or `0xFFFF` otherwise).

The glyph list is then followed by a character list which displays for every character its Unicode code point, its x/y position, its x/y advance and its visual bounding box (omitted here for brevity):


char info for 28 characters
 ch: 1794 x: 0.0 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17b6 x: 68.115234 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 68.115234 y: 0.0 xa: 45.410156 ya: 0.0 ..
 ch: 179f x: 113.52539 y: 0.0 xa: 90.82031 ya: 0.0 ..
 ch: 17d2 x: 204.3457 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 204.3457 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17be x: 204.3457 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179f x: 204.3457 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17bb x: 272.46094 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17c6 x: 272.46094 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 272.46094 y: 0.0 xa: 90.82031 ya: 0.0 ..
 ch: 17c5 x: 363.28125 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 178f x: 363.28125 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17c2 x: 431.39648 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 178f x: 431.39648 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17d2 x: 499.51172 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179a x: 499.51172 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17bc x: 499.51172 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179c x: 499.51172 y: 0.0 xa: 22.705078 ya: 0.0 ..
 ch: 1794 x: 522.2168 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17b6 x: 590.33203 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 590.33203 y: 0.0 xa: 45.410156 ya: 0.0 ..
 ch: 1794 x: 635.7422 y: 0.0 xa: 45.410156 ya: 0.0 ..
 ch: 178a x: 681.15234 y: 0.0 xa: 45.410156 ya: 0.0 ..
 ch: 17b7 x: 726.5625 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179f x: 726.5625 y: 0.0 xa: 90.82031 ya: 0.0 ..
 ch: 17c1 x: 817.3828 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1792 x: 817.3828 y: 0.0 xa: 45.410156 ya: 0.0 ..


>From the output, we can infer that the first two characters (i.e. `U+1794` ("?", KHMER LETTER BA) and `U+17B6` ("?", KHMER VOWEL SIGN AA)) are visually represented by a single glyph (i.e. the ligature "??"), because `U+17B6`'s advance is zero (i.e. the "visual representation" of `U+17B6` is already "contained" in the ligature glyph for `U+1794`). For the character combination which causes problems in JDK 9+, we get the following information:

 ch: 178f x: 431.39648 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17d2 x: 499.51172 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179a x: 499.51172 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17bc x: 499.51172 y: 0.0 xa: 0.0 ya: 0.0 ..
 ```

 I.e., visually, they are represented by a single ligature starting at x-position `431.39648` with a width of `68.115234` which is fully accounted to the first character `U+178f`. The following three characters start at `499.51172` (i.e. `431.39648 + 68.115234`) with a zero advance. The ligature is composed from the following four glyphs (taken from the glyph listing above):


g: 16  v: 409, x: 431.39648, a: 22.705078, n: 15
g: 17  v: 65535, x: 454.10156, a: 0.0, n: 16
g: 18  v: 577, x: 454.10156, a: 45.410156, n: 14
g: 19  v: 622, x: 498.04688, a: 0.0, n: 17


By inspecting the font, we can find that `409` is the glyph for `U+179a`, `577` for `U+178f` and `622` for `U+17bc`. Notice how `U+179a` was visually re-ordered before `U+178f` and how `U+17d2` was replaced by the invisible glyph `65535` because it has no visible representation.

### The HarfBuzz layout engine

With HarfBuzz in JDK 9+, the glyph list looks slightly different:


number of glyphs: 25
glyphinfo.len: 200
indices.len: 25
g: 0  v: 455, x: 0.0, a: 68.115234, n: 0
g: 1  v: 581, x: 68.115234, a: 45.410156, n: 2
g: 2  v: 627, x: 113.52539, a: 22.705078, n: 3
g: 3  v: 593, x: 136.23047, a: 68.115234, n: 3
g: 4  v: 402, x: 205.07812, a: 0.0, n: 3
g: 5  v: 714, x: 203.61328, a: 0.0, n: 3
g: 6  v: 593, x: 204.3457, a: 68.115234, n: 7
g: 7  v: 621, x: 271.72852, a: 0.0, n: 8
g: 8  v: 632, x: 271.72852, a: 0.0, n: 9
g: 9  v: 627, x: 272.46094, a: 22.705078, n: 10
g: 10  v: 503, x: 295.16602, a: 68.115234, n: 10
g: 11  v: 628, x: 363.28125, a: 22.705078, n: 12
g: 12  v: 577, x: 385.98633, a: 45.410156, n: 12
g: 13  v: 409, x: 431.39648, a: 22.705078, n: 14
g: 14  v: 577, x: 454.10156, a: 45.410156, n: 14
g: 15  v: 554, x: 499.51172, a: 0.0, n: 17
g: 16  v: 590, x: 499.51172, a: 22.705078, n: 18
g: 17  v: 455, x: 522.2168, a: 68.115234, n: 19
g: 18  v: 581, x: 590.33203, a: 45.410156, n: 21
g: 19  v: 582, x: 635.7422, a: 45.410156, n: 22
g: 20  v: 572, x: 681.15234, a: 45.410156, n: 23
g: 21  v: 617, x: 725.09766, a: 0.0, n: 24
g: 22  v: 627, x: 726.5625, a: 22.705078, n: 25
g: 23  v: 593, x: 749.2676, a: 68.115234, n: 25
g: 24  v: 580, x: 817.3828, a: 45.410156, n: 27


First, we only have 25 glyphs, i.e. fewer glyphs than characters. That's because HarfBuzz is not inserting invisible glyphs for characters which have been substituted by ligatures or which have no visible representation. Second, the [cluster numbers](https://harfbuzz.github.io/clusters.html#clusters-and-shaping) are monotonically increasing and non-contiguous (because some cluster numbers are missing). The difference in the number of clusters and their ordering is because OpenJDK is using HarfBuzz's default [cluster level](https://harfbuzz.github.io/working-with-harfbuzz-clusters.html) one (i.e. [`HB_BUFFER_CLUSTER_LEVEL_MONOTONE_CHARACTERS`](https://harfbuzz.github.io/harfbuzz-hb-buffer.html#hb-buffer-cluster-level-t)) which "merges" clusters. If we change the cluster level in [`HBShaper_Panama.c`](https://github.com/openjdk/jdk/blob/6e91ccd1c3926094a9b6d8f9177d895aba3424a1/src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c#L118) to `HB_BUFFER_CLUSTER_LEVEL_CHARACTERS`, 
 we will get the same cluster numbers like with ICU in JDK 8, but it turns out, that this doesn't make any difference for the final layout and breaking decisions, so we wont follow this path any further.

There's a final difference for glyph number 15 which is part of the character sequence that is broken incorrectly in JDK 9+. With HarfBuzz `U+17BC` gets replaced by glyph `554` (i.e. `uni17bc.alt`) whereas ICU replaces it by the glyph `622` (i.e. `uni17bc`) in JDK 8. However, from looking at the font, we can see that both glyphs have the same shape and are both representations of the same Unicode code point (as their names imply). The only difference between them is that the glyph `554` starts at a lower y-position and this can be clearly seen in the screenshots at the beginning of this article. But substituting one with the other doesn't make any different for the line breaking behaviour so we will ignore this difference for now (although it is interesting and the ICU choice in JDK 8 seems to be visually more appealing).

Notice that apart from the mentioned differences, both layouts (i.e. the glyphs and their exact positions and dimensions) are exactly the same which I find quite impressing! Still, the resulting character list looks quite different:


char info for 28 characters
 ch: 1794 x: 0.0 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17b6 x: 68.115234 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 68.115234 y: 0.0 xa: 45.410156 ya: 0.0 ..
 ch: 179f x: 113.52539 y: 0.0 xa: 90.82031 ya: 0.0 ..
 ch: 17d2 x: 204.3457 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 204.3457 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17be x: 204.3457 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179f x: 204.3457 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17bb x: 272.46094 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17c6 x: 272.46094 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 272.46094 y: 0.0 xa: 90.82031 ya: 0.0 ..
 ch: 17c5 x: 363.28125 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 178f x: 363.28125 y: 0.0 xa: 68.115234 ya: 0.0 ..
 ch: 17c2 x: 431.39648 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 178f x: 431.39648 y: 0.0 xa: 431.39648 ya: 0.0 ..
 ch: 17d2 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179a x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17bc x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179c x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1794 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17b6 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1793 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1794 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 178a x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17b7 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 179f x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 17c1 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ch: 1792 x: 862.79297 y: 0.0 xa: 0.0 ya: 0.0 ..
 ```

Starting from character 15 (`U+178f`) all subsequent characters are grouped into the same, huge cluster
with an advance of zero. This is the reason, why in our reproducer, the last segment can't be broken up any more and is much too long.
### The difference between ICU and HarfBuzz

The only remaining difference are the missing invisible glyphs in the resulting glyph vector when using HarfBuzz. But they only seem to impact line breaking and not the general layout as can be seen when we render the whole example sentence in one line. And indeed, manually inserting an invisible glyph at index 14 fixes line breaking in JDK 9+.

Also, if we take a closer look at the [`icu-le-hb`](https://github.com/harfbuzz/icu-le-hb) library mentioned before which wraps HarfBuzz with a ICU Layout Engine compatible API, we can see that its [`LayoutEngine::layoutChars()`](https://github.com/harfbuzz/icu-le-hb/blob/01b8e255d08a9ea2c2a0665f2b673fe9e71c7ec1/src/LayoutEngine.cpp#L204) method contains the following comment:


    /* ICU LE generates at least one glyph for each and every input 16bit codepoint.
     * Do the same by inserting fillers. */


So one possibility to fix our problem would be to integrate this post-processing of the glyph vector after the call to `hb_shape_full()` into OpenJDK as well. One the other hand, we can also take a look on how the resulting glyph vector is processed in OpenJDK and how the corresponding code is handling invisible glyphs. The comments on `ExtendedTextSourceLabel::createCharinfo()` differ as follows between [JDK 8](https://github.com/openjdk/jdk8u-dev/blob/89b85a8f5b0f8e4f7763cf9b4d15e051d6e9f43f/jdk/src/share/classes/sun/font/ExtendedTextSourceLabel.java#L553) and [JDK 9+](https://github.com/openjdk/jdk/blob/c1198bba0e8cbdaa47c821263d122d0ba4dd6759/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#L569):


 /*
 * This takes the glyph info record obtained from the glyph vector and converts it into a similar record
 * adjusted to represent character data instead.  For economy we don't use glyph info records in this processing.
 *
 * Here are some constraints:
 * - there can be more glyphs than characters (glyph insertion, perhaps based on normalization, has taken place)
-* - there can not be fewer glyphs than characters (0xffff glyphs are inserted for characters ligaturized away)
+* - there can be fewer glyphs than characters
+*   Some layout engines may insert 0xffff glyphs for characters ligaturized away, but
+*   not all do, and it cannot be relied upon.
 * - each glyph maps to a single character, when multiple glyphs exist for a character they all map to it, but
 *   no two characters map to the same glyph
 * - multiple glyphs mapping to the same character need not be in sequence (thai, tamil have split characters)
 * - glyphs may be arbitrarily reordered (Indic reorders glyphs)


This only documents one of the differences that we've already detected by looking at the debug output, namely the missing invisible glyphs which are only inserted by the old ICU engine. But it still claims that "*each glyph maps to a single character*" which isn't true any more with HarfBuzz which doesn't add invisible glyphs for ligaturized characters any more. Also, the following part of the comment which describes the algorithm hasn't changed between 8 and 9+:


/*
 ...
 * 3) we consume clusters in the following way:
 *    a) the first element is always consumed
 *    b) subsequent elements are consumed if:
 *       i) their advance is zero
 *       ii) their character index <= the character index of any character seen in this cluster
 *       iii) the minimum character index seen in this cluster isn't adjacent to the previous cluster


I don't think point `iii)` is required any more with HarfBuzz, because with the `HB_BUFFER_CLUSTER_LEVEL_MONOTONE_CHARACTERS` cluster level, the cluster numbers (which initially correspond to the character indices, before they can be merged during the layout) are guaranteed to be monotonic, so we don't have situations like the following (taken from the JDK 8 glyph list above) where glyph `3` has a cluster index of `6` which is bigger than glyph `4`'s cluster index:

g: 3  v: 627, x: 113.52539, a: 22.705078, n: 6
g: 4  v: 593, x: 136.23047, a: 68.115234, n: 3
g: 5  v: 402, x: 205.07812, a: 0.0, n: 4
g: 6  v: 65535, x: 204.3457, a: 0.0, n: 5
g: 7  v: 714, x: 203.61328, a: 0.0, n: 6


Here's the abridged and commented code for the consumption of a [cluster](https://harfbuzz.github.io/clusters.html) from [`ExtendedTextSourceLabel::createCharinfo()`](https://github.com/openjdk/jdk/blob/c1198bba0e8cbdaa47c821263d122d0ba4dd6759/src/java.desktop/share/classes/sun/font/ExtendedTextSourceLabel.java#L637):


    while (gx != gxlimit) {              // gx = glyph index, gxlimit = max. glyph index
        int clusterExtraGlyphs = 0;      // consumed glyphs
        minIndex = indices[gx];          // min. char index
        maxIndex = minIndex;             // max. char index

        // advance to next glyph
        gx += xdelta;

        while (gx != gxlimit &&                               // more glyphs?
               ((glyphinfo[gp + advx] == 0) ||                // i) advance == 0?
               (indices[gx] <= maxIndex) ||                   // ii) char index <= maxIndex?
               (maxIndex - minIndex > clusterExtraGlyphs))) { // iii) THIS IS WRONG in JDK 9+

            ++clusterExtraGlyphs; // have an extra glyph in this cluster
            ...
            // adjust min, max index
            minIndex = Math.min(minIndex, indices[gx]);
            maxIndex = Math.max(maxIndex, indices[gx]);

            // get ready to examine next glyph
            gx += xdelta;
        }
        // done with cluster, gx and gp are set for next glyph


But even worse, condition `iii)` isn't just unnecessary with HarfBuzz, it can lead to errors, just like in our case, where we have the following glyph list:

g: 13  v: 409, x: 431.39648, a: 22.705078, n: 14
g: 14  v: 577, x: 454.10156, a: 45.410156, n: 14
g: 15  v: 554, x: 499.51172, a: 0.0, n: 17

Here we consume glyph `13` as first glyph from cluster `14` and glyph `14` because it has the same cluster index (i.e. `14`, condition `ii`). Next, we also consume glyph `15` because it has zero advance (condition `i`). But this now also increases `maxIndex` (the maximum character index) to `17`, although we've only consumed two extra glyphs until now. This means that `maxIndex - minIndex` will be bigger than `clusterExtraGlyphs` and we will continue to consume further glyphs until the end of the sentence (resulting in the huge last cluster which can't be broken up any more).

Notice that if we had an additional invisible glyph (with zero advance) in the list before glyph `15` (just like in JDK 8), it would have been added to the cluster because of rule `i` and also increased `clusterExtraGlyphs` by one, which would have invalidated the condition `maxIndex - minIndex > clusterExtraGlyphs` after the insertion of glyph `15`.

So, to cut a (very) long story short, removing condition `iii` from the above while loop, will fix this issue (and hopefully don't be harmful for any other cases).

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

Commit messages:
 - 8361381: GlyphLayout behavior differs on JDK 11+ compared to JDK 8

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

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

From aivanov at openjdk.org  Mon Aug 18 16:26:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 16:26:10 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
 <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>
 <7m9fDENxqmPnasJA7urxLaf3t2BrJOCHCstw6aWq2xo=.40aa98dd-db7f-4594-ac1c-be55e32b8998@github.com>
 <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
Message-ID: <BMPBTsc03b8d8uvpPEvLhNgRsf_DeF6AeMLuHuQHccA=.28b4c97a-3031-4911-88a5-acdfe3299927@github.com>

On Fri, 15 Aug 2025 22:09:15 GMT, Phil Race <prr at openjdk.org> wrote:

> > > > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
> > > 
> > > 
> > > Yes I do. I overlooked them.
> > 
> > 
> > If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.
> 
> oh. ok. I guess I will look at your test case and confirm that .. and looks like it is a fully done regression test.

Yes, it is. It was easier to make it a full regression test.

> Maybe you want to push that yourself ?

Yeah, I guess so. I didn't look to update this myself initially. When I left my first comment above, I didn't come up with a test that proves there's a bug even though I had a hunch.

Now I looked at the code and resolved the bug myself. I also submitted my PR that's based on yours.

I edited the subject of the JBS issue that this PR resolves, now it doesn't reference `WindowsMenuItemUI`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3197596934

From abaya at openjdk.org  Mon Aug 18 16:27:14 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 18 Aug 2025 16:27:14 GMT
Subject: RFR: 8361387 : Test bug4655513.java fails intermittently on Windows
 platform.
Message-ID: <hfv0hEengRD06RtkUnozVymRc8fPq-bINbh1sq6eUWI=.2c50007d-9239-40ab-85cf-2899fb921268@github.com>

This test was recently automated and is failing intermittently in the CI due to timing issues.
This enhancement aims to stabilize the test and also adds the missing null pointer check.

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

Commit messages:
 - Test stabilization

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

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

From abaya at openjdk.org  Mon Aug 18 16:30:15 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 18 Aug 2025 16:30:15 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
In-Reply-To: <6rkJv8BuGgrA2L7AQ-gXfvqcRqADHLgZaq9PC3aGZ8w=.64ff2902-b225-4c08-840c-6277b64b40c2@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
 <6rkJv8BuGgrA2L7AQ-gXfvqcRqADHLgZaq9PC3aGZ8w=.64ff2902-b225-4c08-840c-6277b64b40c2@github.com>
Message-ID: <ouK08IA-_r9wZRlYFpbANUSkXoRBy90IUB2xaF4erQM=.ce50cc3c-06f8-4072-b6ed-8c7600368040@github.com>

On Tue, 15 Jul 2025 19:52:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> **Analysis:**
>> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
>> 
>> **Proposed Fix:**
>> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
>> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once
>
>> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> What's causing the recursive re-entry? Is the bug in the code path in linux when calling getFocusableWindowState?

Hello @alisenchung, @mrserb,
Do you agree with the new proposed fix ?
Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3197614367

From lkorinth at openjdk.org  Mon Aug 18 16:34:21 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:21 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

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

  after suggestion from Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/8fa40e7d..286a2cc6

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

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

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

From lkorinth at openjdk.org  Mon Aug 18 16:34:22 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 18 Aug 2025 16:34:22 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <-1NjyGdZla4kxc5tKPvakW_aqwjNcNXt4ibAf3WndRU=.21ac795a-b7ee-44ac-a155-70e1186c8148@github.com>
Message-ID: <KNNxBq11P7lT_D16Mzwx-_VHkNITiw5wQbuYCf58yQI=.cdcf7871-b20c-4e44-b10e-c6108e647afb@github.com>

On Mon, 18 Aug 2025 11:34:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Leo, I played a bit with your changes and I observed intermittent timeout failures for the following tests:
> 
> ```
> 	java/net/httpclient/CancelledResponse.java
> 	java/net/httpclient/whitebox/FlowTestDriver.java
> ```
> 
> The first test failing more frequently. Could you please add /timeout=480 to these two tests as well?

Fixed! Thanks for helping!

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197614389

From aivanov at openjdk.org  Mon Aug 18 16:37:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 16:37:56 GMT
Subject: RFR: 8365625: Can't change accelerator colors in Windows L&F
Message-ID: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>

**Problem:**

The colors for the accelerators are cached in static fields: `disabledForeground`, `acceleratorSelectionForeground` and `acceleratorForeground`. As soon as this field is set to a non-`UIResource` value, the value cannot change.

**Fix:**

Remove the static fields for accelerator from `WindowsMenuItemUI` and use the fields inherited from `BasicMenuItemUI`, pass these fields as parameters to static methods.

Additionally, I formatted the calls to `WindowsMenuItemUI.paintMenuItem` in one consistent way.

I removed the redundant javadoc from `paintMenuItem` and added the missing `@Override` annotation.

I provided a regression test. The test also reproduces [JDK-8365375](https://bugs.openjdk.org/browse/JDK-8365375) that was resolved in #26743.

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

Depends on: https://git.openjdk.org/jdk/pull/26783

Commit messages:
 - 8365625: Can't change accelerator colors in Windows L&F

Changes: https://git.openjdk.org/jdk/pull/26826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365625
  Stats: 234 lines in 5 files changed: 185 ins; 35 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26826/head:pull/26826

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

From dfuchs at openjdk.org  Mon Aug 18 16:46:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Aug 2025 16:46:13 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <a3CwlSQwHYj_F3fC30zoiDhXf9G-cn5xK8ZwVFmxBd0=.afdaf352-e494-4bc6-adf2-dc5afa0dd4b9@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

Thanks! Changes to JNDI / net / httpclient LGTM.

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

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3197675337

From aivanov at openjdk.org  Mon Aug 18 16:55:50 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 16:55:50 GMT
Subject: RFR: 8365708: Add missing @Override annotations to
 WindowsMenuItemUIAccessor
Message-ID: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>

Add the missing `@Override` annotations to anonymous classes implementing `WindowsMenuItemUIAccessor`.

PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638) added the `@Override` annotations to `getMenuItem` and `getPart` but left `getState` without the annotation.

For consistency, add the annotation to the `getState` method too.

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

Commit messages:
 - 8365708: Add missing @Override annotations to WindowsMenuItemUIAccessor

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

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

From serb at openjdk.org  Mon Aug 18 17:06:12 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 18 Aug 2025 17:06:12 GMT
Subject: RFR: 8365708: Add missing @Override annotations to
 WindowsMenuItemUIAccessor
In-Reply-To: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>
References: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>
Message-ID: <X5CgkhNuFVU07qM2hJ59pTV27iz-U0g9wMF4lYGWKso=.7d5a0e8e-cd1f-4f78-b4bd-f93de37bb4fb@github.com>

On Mon, 18 Aug 2025 16:49:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Add the missing `@Override` annotations to anonymous classes implementing `WindowsMenuItemUIAccessor`.
> 
> PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638) added the `@Override` annotations to `getMenuItem` and `getPart` but left `getState` without the annotation.
> 
> For consistency, add the annotation to the `getState` method too.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26828#pullrequestreview-3129202725

From aivanov at openjdk.org  Mon Aug 18 17:13:02 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 17:13:02 GMT
Subject: RFR: 8365711: Declare menuBarHeight and hotTrackingOn private
Message-ID: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>

Since `WindowsMenuUI` is a final class after PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be extended, therefore the `protected` modifier doesn't make sense.

Mark both `menuBarHeight` and `hotTrackingOn` as `private` fields.

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

Commit messages:
 - 8365711: Declare menuBarHeight and hotTrackingOn private

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

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

From serb at openjdk.org  Mon Aug 18 17:18:16 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 18 Aug 2025 17:18:16 GMT
Subject: RFR: 8365708: Add missing @Override annotations to
 WindowsMenuItemUIAccessor
In-Reply-To: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>
References: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>
Message-ID: <rvF0QTBx4_na6C45dln27T-uoYIScsuWpmd8jByBf2o=.28916946-e4c2-4493-b718-6f80158e7e11@github.com>

On Mon, 18 Aug 2025 16:49:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Add the missing `@Override` annotations to anonymous classes implementing `WindowsMenuItemUIAccessor`.
> 
> PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638) added the `@Override` annotations to `getMenuItem` and `getPart` but left `getState` without the annotation.
> 
> For consistency, add the annotation to the `getState` method too.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxMenuItemUI.java line 55:

> 53:             }
> 54: 
> 55:             @Override

There is the new paintMenuItem method below which can be annotated as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26828#discussion_r2282991338

From aivanov at openjdk.org  Mon Aug 18 17:22:17 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 17:22:17 GMT
Subject: RFR: 8365708: Add missing @Override annotations to
 WindowsMenuItemUIAccessor
In-Reply-To: <rvF0QTBx4_na6C45dln27T-uoYIScsuWpmd8jByBf2o=.28916946-e4c2-4493-b718-6f80158e7e11@github.com>
References: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>
 <rvF0QTBx4_na6C45dln27T-uoYIScsuWpmd8jByBf2o=.28916946-e4c2-4493-b718-6f80158e7e11@github.com>
Message-ID: <2o8wZqjC_dxrfGo81YaOuxNEk2EoSgbODdmbXfm4TnM=.84bd49fa-dc95-4909-9fe6-4e83a96697d9@github.com>

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

>> Add the missing `@Override` annotations to anonymous classes implementing `WindowsMenuItemUIAccessor`.
>> 
>> PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638) added the `@Override` annotations to `getMenuItem` and `getPart` but left `getState` without the annotation.
>> 
>> For consistency, add the annotation to the `getState` method too.
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxMenuItemUI.java line 55:
> 
>> 53:             }
>> 54: 
>> 55:             @Override
> 
> There is the new paintMenuItem method below which can be annotated as well.

This is handled in #26826.

I thought about combining both fixes at first, but decided against it. The fix for [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) in PR #26826 will be backported to all supported releases. Yet there's no need to backport either JDK-8365708 (this one) nor [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638 "Enhance code consistency: java.desktop/windows").

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26828#discussion_r2282998734

From aivanov at openjdk.org  Mon Aug 18 17:23:11 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 17:23:11 GMT
Subject: RFR: 8365711: Declare menuBarHeight and hotTrackingOn private
In-Reply-To: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
References: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
Message-ID: <PB0In0qyPHU9ZjhNFO1CkKBJ8kG5HUbZQqiZEyE7yq8=.04312ff4-a9fc-4d52-a978-0b686fcd00b5@github.com>

On Mon, 18 Aug 2025 17:05:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Since `WindowsMenuUI` is a final class after PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be extended, therefore the `protected` modifier doesn't make sense.
> 
> Mark both `menuBarHeight` and `hotTrackingOn` as `private` fields.

@mrserb Could you take a look at another trivial clean-up, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/26829#issuecomment-3197790729

From serb at openjdk.org  Mon Aug 18 17:35:10 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 18 Aug 2025 17:35:10 GMT
Subject: RFR: 8365711: Declare menuBarHeight and hotTrackingOn private
In-Reply-To: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
References: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
Message-ID: <iJc75CDskr5K6aL5ErvorO2MBMP80SoN908NEBavDGs=.b9b81408-c294-46d6-a2e6-7ef936f84961@github.com>

On Mon, 18 Aug 2025 17:05:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Since `WindowsMenuUI` is a final class after PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be extended, therefore the `protected` modifier doesn't make sense.
> 
> Mark both `menuBarHeight` and `hotTrackingOn` as `private` fields.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26829#pullrequestreview-3129292430

From djgredler at gmail.com  Mon Aug 18 18:27:47 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Mon, 18 Aug 2025 20:27:47 +0200
Subject: JDK-4138921: TextLayout handling of empty strings
In-Reply-To: <994c74d6-2eb4-4588-ad6a-25529b68bd1e@oracle.com>
References: <CAPA+ug6A88qeG+bRC3UAvvkp67jALtQXEsF0OMxK=WnsXbxQUw@mail.gmail.com>
 <994c74d6-2eb4-4588-ad6a-25529b68bd1e@oracle.com>
Message-ID: <CAPA+ug7RjS_wYcePSyD-MspDv6wswmLLTpOgueC2Dp-W_4mMSQ@mail.gmail.com>

Hi Naoto,

TextLayout currently is not allowed to represent the layout of an empty
string, and I'm looking to change that (see JDK-4138921).

One of the three TextLayout constructors which needs to change takes
an AttributedCharacterIterator, which is usually obtained from an
AttributedString. However, AttributedString has a similar restriction, in
that it can only wrap an empty string if it doesn't have any attributes. Do
you know why this is? Is this a restriction which can also be relaxed so as
to avoid painful surprises for users of these APIs?

Take care,

Daniel


On Mon, Aug 11, 2025 at 7:12?PM Philip Race <philip.race at oracle.com> wrote:

>
>
> On 8/11/25 9:20 AM, Daniel Gredler wrote:
> > Hi all,
> >
> > I was thinking of taking a stab at JDK-4138921 [1], and I have a
> > couple of questions.
> >
> > First, there is a related API oddity in that null FontRenderContext
> > parameters passed to the TextLayout constructors cause a
> > NullPointerException, rather than an IllegalArgumentException (like
> > all other parameters). Can this behavior also be changed?
>
> None of these are documented .. they all should be.
>
> It is a bit odd that frc is the only one not explicitly checked so the
> NPE is just what 'happens'.
> I'd be reluctant to change the NPE without a good reason and I'm
> half-wondering if a null FRC was
> supposed to default to a default FRC ?? But somewhere along the line the
> implementation changed.
> I'd say just specify what happens for complete compatibility.
>
> >
> > Second, changing all three TextLayout constructors to accept empty
> > strings sort of implies that we should also allow empty strings in
> > AttributedString instances (this is currently only allowed if the
> > attribute map is empty). Is it OK to change this behavior as well?
>
> I don't think I ever understood why this was dis-allowed on TextLayout.
> Perhaps it was to prevent some incorrect usage from ever slipping into
> being acceptable ?
>
> AttributedString is part of the java.base module, I don't have any say
> over that, although in the very beginning
> there was a decent overlap in the people working on that and TextLayout
> etc.
> I'd start by asking Naoto (cc'ed).
>
> -phil.
>
> >
> > Let me know your thoughts!
> >
> > Daniel
> >
> > [1] https://bugs.openjdk.org/browse/JDK-4138921
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250818/a43bd140/attachment-0001.htm>

From aivanov at openjdk.org  Mon Aug 18 19:13:19 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:13:19 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v26]
In-Reply-To: <hjI1ozzITjVZWLTEL5wFvEROkJivgnqyjgrRCB3H1F0=.908100fc-9f8a-4c62-9898-749406314d4e@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <hjI1ozzITjVZWLTEL5wFvEROkJivgnqyjgrRCB3H1F0=.908100fc-9f8a-4c62-9898-749406314d4e@github.com>
Message-ID: <mlyMIb0Yn3bB7Rd8ycKVCwIZ-VE6wt1kR7Uyk58m_34=.18eface1-907a-4edb-9213-048043f3e0cb@github.com>

On Wed, 6 Aug 2025 02:58:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Don't you want to use JUnit for `test/jdk/javax/swing/ImageIcon/ImageIconTest.java`?

I think using separate small methods to test `ImageIcon` constructors is much clearer and readable than switching over a set of enums. Moreover, a JUnit test will run all the test methods, which means you'll get the full picture instead of failing the entire test when the a first assertion fails.

[I posted `ImageIconConstructorsTest.java` that uses JUnit](https://github.com/openjdk/jdk/pull/25767#issuecomment-3049620519). To run this test with jtreg add the following tags:


/*
 * @test
 * @summary Verifies behavior of ImageIcon constructors with null parameters
 * @run junit ImageIconConstructorsTest
 */
public final class ImageIconConstructorsTest {
}


You'll have to add test methods for invalid files and invalid data, though.

The jtreg report looks like this:

----------System.out:(0/0)----------
----------System.err:(31/2237)----------
STARTED    ImageIconConstructorsTest::stringNull 'stringNull()'
SUCCESSFUL ImageIconConstructorsTest::stringNull 'stringNull()' [15ms]
STARTED    ImageIconConstructorsTest::noArgs 'noArgs()'
SUCCESSFUL ImageIconConstructorsTest::noArgs 'noArgs()' [0ms]
STARTED    ImageIconConstructorsTest::imageNull 'imageNull()'
SUCCESSFUL ImageIconConstructorsTest::imageNull 'imageNull()' [0ms]
...

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3198087156

From duke at openjdk.org  Mon Aug 18 19:17:38 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:17:38 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

David Alayachew 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 patch-1
 - Fixing incorrect centering of EditPad window.
   
   When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26814/files
  - new: https://git.openjdk.org/jdk/pull/26814/files/b82d1300..409f392d

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

  Stats: 464 lines in 32 files changed: 252 ins; 84 del; 128 mod
  Patch: https://git.openjdk.org/jdk/pull/26814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26814/head:pull/26814

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

From duke at openjdk.org  Mon Aug 18 19:17:39 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:17:39 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <opdfOPyKKszYq-pDpA0Wpc2Jr0SUJ3INrYZO9u-JrOQ=.c5bc2321-d9d9-44d3-8958-c4d60bd10483@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <opdfOPyKKszYq-pDpA0Wpc2Jr0SUJ3INrYZO9u-JrOQ=.c5bc2321-d9d9-44d3-8958-c4d60bd10483@github.com>
Message-ID: <6q24O2zyCeuIOqj-LQ53gMWY4hUZ7BVDG7KBdpOc9CA=.148f470b-6c3e-40c1-95dd-364859efacfb@github.com>

On Mon, 18 Aug 2025 13:42:45 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi @davidalayachew, can you update the copyright year at top from `2015, 2016,` to `2015, 2025,`?
> 
> In addition, according to https://openjdk.org/guide, we usually leave 24 hours for sufficient review. This applies so you should type `/integrate` later in the future.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198087322

From prr at openjdk.org  Mon Aug 18 19:18:11 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 18 Aug 2025 19:18:11 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v3]
In-Reply-To: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
Message-ID: <j0z7cUnM92zlhkSUhi601FN8a7kzDKSmOa17fJefnVM=.ad8f55e0-41ca-48d1-b487-88b138c5d002@github.com>

> This refactors some Swing code to pass args instead of using statics
> The bug report suggests some further refactoring which could be considered later, but the most
> important thing to do is to eliminate using statics to pass args.
> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.

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

  8365389

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26783/files
  - new: https://git.openjdk.org/jdk/pull/26783/files/a1f59db1..1b676514

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

  Stats: 16 lines in 4 files changed: 9 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26783/head:pull/26783

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

From duke at openjdk.org  Mon Aug 18 19:17:40 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:17:40 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

And yes, in future pull requests, I will try and remember to wait before trying to do an integrate command.

Is there any outstanding tasks? Or are we just waiting the 24 hours before merging?

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198092377

From aivanov at openjdk.org  Mon Aug 18 19:31:39 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:31:39 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
 <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>
 <7m9fDENxqmPnasJA7urxLaf3t2BrJOCHCstw6aWq2xo=.40aa98dd-db7f-4594-ac1c-be55e32b8998@github.com>
 <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
Message-ID: <O4hfWObC32jwFnQ51QLT6_RO7d4Sj7xd-r8tzkX-Rs0=.6673f7a4-4ecc-4b1f-a3cf-1e90a0440d45@github.com>

On Fri, 15 Aug 2025 22:09:15 GMT, Phil Race <prr at openjdk.org> wrote:

>>> > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
>>> 
>>> Yes I do. I overlooked them.
>> 
>> If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.
>
>> > > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
>> > 
>> > 
>> > Yes I do. I overlooked them.
>> 
>> If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.
> 
> oh. ok. I guess I will look at your test case and confirm that  .. and looks like it is a fully done regression test.
> Maybe you want to push that yourself ?

@prrace Your latest commit https://github.com/openjdk/jdk/commit/1b676514010e55d0903ba445e5dd806e9f1b862d doesn't address the problem fully, you should also remove `WindowsMenuItemUI.installDefaults`.

I posted a comment where I said that I went ahead and submitted my own PR #26826 to resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625 "Can't change accelerator colors in Windows L&F"). My PR removes the static fields from `WindowsMenuItemUI` and adds the regression test attached to the JBS issue.

I propose you revert commit 1b67651 and integrate this PR in the state it was last week with the updated subject that doesn't mention `WindowsMenuItemUI`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3198134374

From liach at openjdk.org  Mon Aug 18 19:33:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 19:33:46 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
Message-ID: <c4J3vodR7fUa-eK2BcUKcw6wYsQdrY3g6kk2G8nhtU8=.184d0204-99a4-4c6e-abfa-41529d4aa11a@github.com>

On Mon, 18 Aug 2025 19:12:30 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> And yes, in future pull requests, I will try and remember to wait before trying to do an integrate command.
> 
> Is there any outstanding tasks? Or are we just waiting the 24 hours before merging?

@davidalayachew I don't see the copyright year update committed. Did you accidentally forget to push?

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198130706

From aivanov at openjdk.org  Mon Aug 18 19:33:48 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:33:48 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
Message-ID: <h5pg3Lld19ZHY7a2uYNU_EMvNYGlP5U7UfRfCUYD-Og=.df2edf97-2ebb-4956-a3e0-f65f0e28c158@github.com>

On Mon, 18 Aug 2025 19:29:11 GMT, David Alayachew <duke at openjdk.org> wrote:

> Man, I messed up the commit. It asked me if I wanted to grab upstream changes, now there's all this gunk. Let me try recreating the pull request.

@davidalayachew Why do you need to re-create the PR?

Just pull the changes from your personal fork if you used GitHub interface to sync your remote branch with upstream.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198143898

From duke at openjdk.org  Mon Aug 18 19:33:49 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:33:49 GMT
Subject: Withdrawn: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <F0hKVRBeWcQ9U39Sm4qcnbcD1VGY4zP8OK_2lxIc2RQ=.40b5070b-2bb2-45ef-b90e-d03b4dd40355@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Aug 18 19:33:48 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:33:48 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
Message-ID: <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>

On Mon, 18 Aug 2025 19:17:38 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew 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 patch-1
>  - Fixing incorrect centering of EditPad window.
>    
>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Man, I messed up the commit. It asked me if I wanted to grab upstream changes, now there's all this gunk. Let me try recreating the pull request.

I clicked the button to grab upstream changes, now the file changelist is all garbled. Let me reattempt this pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198138249
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198142558

From liach at openjdk.org  Mon Aug 18 19:45:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 19:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
Message-ID: <2-IHhc2eWon7YxYm-H7R6CVW_WChfP1luUN3GsBjLi0=.638e4f16-7451-4771-bdf4-182586666fe2@github.com>

On Mon, 18 Aug 2025 19:34:14 GMT, David Alayachew <duke at openjdk.org> wrote:

>> David Alayachew 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 patch-1
>>  - Fixing incorrect centering of EditPad window.
>>    
>>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> Ok, let me try. I am not too familiar with this.

Hi @davidalayachew, you can continue with the PR with all "redundant" commits. Our bot just looks at the diff at https://github.com/openjdk/jdk/pull/26814.diff and automatically squashes it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198154273

From aivanov at openjdk.org  Mon Aug 18 19:45:13 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <6HL5exLCnudD8aGOVTz0ljOBmHw-2JQJ1AONHbSEc94=.8263bfaf-fcb8-4bb6-9078-9deb55f6fde2@github.com>
Message-ID: <aMQTn3DxefrGynlpTfvU0hx2_TS59lYAgbRfQTmkxAQ=.ccc7df26-888c-40fd-a742-0a763800bb37@github.com>

On Mon, 18 Aug 2025 19:30:42 GMT, David Alayachew <duke at openjdk.org> wrote:

>> David Alayachew 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 patch-1
>>  - Fixing incorrect centering of EditPad window.
>>    
>>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> I clicked the button to grab upstream changes, now the file changelist is all garbled. Let me reattempt this pull request.

@davidalayachew If you already created a commit in your local branch, you can reset your branch to its previous state before that commit with


git reset HEAD~1


Then pull the updates from `origin`:


git pull origin patch-1


Both commands above imply that your current branch is `patch-1`.

Then update the copyright year again, commit the change, and push the update to your fork.

> Ok, does that look better?

> Hi @davidalayachew, you can continue with the PR with all "redundant" commits. Our bot just looks at the diff at https://github.com/openjdk/jdk/pull/26814.diff and automatically squashes it.

@liach I believe the problem is that the remote and local branches diverged. Pushing from local isn't allowed because of that; pulling from remote directly would create a merge commit, which isn't that bad.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198152910
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198163607

From duke at openjdk.org  Mon Aug 18 19:45:12 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:45:12 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

David Alayachew has updated the pull request incrementally with one additional commit since the last revision:

  Forgot to update the copyright year.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26814/files
  - new: https://git.openjdk.org/jdk/pull/26814/files/409f392d..1a7f9952

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26814&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26814&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26814/head:pull/26814

PR: https://git.openjdk.org/jdk/pull/26814

From duke at openjdk.org  Mon Aug 18 19:45:13 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 19:45:13 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
Message-ID: <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>

On Mon, 18 Aug 2025 19:17:38 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew 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 patch-1
>  - Fixing incorrect centering of EditPad window.
>    
>    When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

Ok, let me try. I am not too familiar with this.

Ok, does that look better?

Thanks for approving. I see that the sponsor tag is gone. I will wait until the 24 hours to do the integrate command. Thanks for the help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198154086
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198157915
PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198172582

From aivanov at openjdk.org  Mon Aug 18 19:45:12 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:45:12 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <avvU2FskaBqejYIPZjvL0SNs1nk-hePJZtr95LoBuTk=.ff972fe5-2bd8-4d8e-a3d6-216efc5ffe75@github.com>

On Mon, 18 Aug 2025 19:40:06 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3129643076

From aivanov at openjdk.org  Mon Aug 18 19:49:37 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 19:49:37 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v2]
In-Reply-To: <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <HoMmg1ML-VkqvVhNg38tMtFU8iCnAxYm3ojHzmohM88=.b2b037df-191e-4d79-813b-fd38ff929199@github.com>
 <blATOzvSDS6vpSu09M6JY4KbOYJ7ffRKUpTiAApGpJo=.caeca850-9bb7-430f-be90-d2fe970f64c5@github.com>
Message-ID: <ByjjNlKEGGXttatV3PCG2Ogeh8JlugoTCLtuvbvGtMw=.54de6d4e-5eac-43f6-83e0-d12e6e9b6d0d@github.com>

On Mon, 18 Aug 2025 19:35:12 GMT, David Alayachew <duke at openjdk.org> wrote:

> Ok, does that look better?

Yes, it looks good to me now, and you learnt some Git magic. (Thanks for not force-pushing.)
 
> Thanks for approving. I see that the sponsor tag is gone. I will wait until the 24 hours to do the integrate command. Thanks for the help.

Yes, it's gone because you added another commit which requires re-approval.

You should still wait for other reviewers from core libs, although copyright update is trivial. @liach has been actively participating, so I expect he'll re-approve the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198194409

From aivanov at openjdk.org  Mon Aug 18 20:02:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Aug 2025 20:02:35 GMT
Subject: RFR: 8364506: javax/swing/Popup/TaskbarPositionTest.java can fail
 subsequent tests on MacOS
In-Reply-To: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
References: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
Message-ID: <JbhqxPchicnDqSNscv4vX44D-nSwmtWO9wyoc1ZAzwQ=.f8cf8707-c5f4-4a1e-94ad-19bedd674893@github.com>

On Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to show all windows related to the focused one.
> 
> Fix:
> Change the 'Cntrl' key to 'Shift'
> 
> Testing:
> Tested in all supported platforms using mach5 and got all PASS.

Yes, all the system shortcuts should be disabled. This is documented in [macOS-specific system set up notes](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements#AutomatedclientGUItestingsystemsetuprequirements-macOS-SpecificSystemsetupnotes).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26623#issuecomment-3198237426

From liach at openjdk.org  Mon Aug 18 20:04:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:04:46 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <oy8h1oWxEc5y7WnWnau5XXdMaFw3avn0A8gwVQumJCY=.86116c2a-8fab-476d-bb50-496f6708dad8@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Thanks for this copyright year update.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26814#pullrequestreview-3129715539

From duke at openjdk.org  Mon Aug 18 20:04:47 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:04:47 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <FJcWSbWPho167r5jnYq-oo8U4_fZl0cnk6sYOBo26ko=.c6a22a6e-193a-44ad-b4f0-8c7fff6057bd@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Then here I go.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198243439

From liach at openjdk.org  Mon Aug 18 20:04:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:04:47 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <5udMsmzS8kw86KW-mDXoLjDFddC88rZ6TxdgZyYUF08=.4f7b0049-bcf3-477a-8dc8-0c561b29abc5@github.com>
Message-ID: <KUtsmAmMKKCNq88St8mmo-bMd1VKCgs6dwKI8pDJvkI=.91d8a983-6b25-447b-b370-890a4b541796@github.com>

On Mon, 18 Aug 2025 19:12:30 GMT, David Alayachew <duke at openjdk.org> wrote:

> Is there any outstanding tasks? Or are we just waiting the 24 hours before merging?

The 24-hour rule is usually to ensure all involved areas can have a reviewer to take a look at the changes, given people live in different time zones. For this contribution we already have people from langtools (compiler-dev) and client, so this is sufficiently reviewed. Thanks for the report and contribution again!

> I see that the sponsor tag is gone. 

It will be restored when you type `/integrate` command again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198241760

From duke at openjdk.org  Mon Aug 18 20:04:47 2025
From: duke at openjdk.org (duke)
Date: Mon, 18 Aug 2025 20:04:47 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <b5Ukf3I4ESF6GUZXMYhJK-iVEuYGCCZ-R3WfHvzJ86k=.82c1ad8f-24e4-468e-865a-feb03da17131@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

@davidalayachew 
Your change (at version 1a7f99524d0841e5f3600abf933c32851af0742a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198244614

From liach at openjdk.org  Mon Aug 18 20:07:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:07:45 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <ZqQ5W8j0OttOjX8sKDuR87uXneuy7iRPHy_rckOvHtA=.d41a3315-7940-4728-ad31-cdbb7a8df476@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Thank you again, and thanks to all reviewers!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198251588

From duke at openjdk.org  Mon Aug 18 20:27:45 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:27:45 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <uifzcBNI69VHsn5fmi2rw_taB-_bURuKqDAGpRmuwDc=.7070c9a2-4497-48d4-9bee-6e68b9c36f4a@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Did I do it wrong?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198313072

From liach at openjdk.org  Mon Aug 18 20:46:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 20:46:43 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <iMFO5cgVQBl_s5c_xDFfGx0fPT2mgK7UwNovbmgO-VQ=.ab9ef996-545f-4c36-beb5-00f895dfcf1c@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

I think I will sponsor again given the status. The skara bots are undergoing mass restarts, and some other patches suddenly have new replies or unexpected status updates too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198361168

From duke at openjdk.org  Mon Aug 18 20:51:44 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:51:44 GMT
Subject: RFR: 8365643: JShell EditPad out of bounds on Windows [v3]
In-Reply-To: <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
 <8F7chWQE0FkISkThIRkWLAB0RTxsjIzHkE0kGe6R8Vs=.08a9fae5-c675-452f-9eb0-81087140fb7c@github.com>
Message-ID: <edam26eDU0jNy_TdOw0bPlMrylLgnHlLh7UZRDOw3hw=.77f1c1e4-1b85-44d9-8795-481746b2637b@github.com>

On Mon, 18 Aug 2025 19:45:12 GMT, David Alayachew <duke at openjdk.org> wrote:

>> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.
>
> David Alayachew has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot to update the copyright year.

Ty all for the help!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26814#issuecomment-3198376598

From duke at openjdk.org  Mon Aug 18 20:51:45 2025
From: duke at openjdk.org (David Alayachew)
Date: Mon, 18 Aug 2025 20:51:45 GMT
Subject: Integrated: 8365643: JShell EditPad out of bounds on Windows
In-Reply-To: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
References: <Kq3MFv0QjfyVP4wW-uElAcK76tBsanHEmTmDCf1rmxo=.515f657f-3c51-4744-9872-d3279d8407d5@github.com>
Message-ID: <U5VLfOhyhYLxP8fCaBOnM1uJ1Rm4A-ty-9PpwVqmxrU=.3a73ec61-ae07-495b-993c-203ab37f8acd@github.com>

On Mon, 18 Aug 2025 04:48:26 GMT, David Alayachew <duke at openjdk.org> wrote:

> When calling the `setLocationRelativeTo()` method, a null parameter means that it centers the window in the screen. However, any subsequent resizing operations will change only the size, not the location of the window. Understandable, but now the window is no longer centered. So, changing the order of operations.

This pull request has now been integrated.

Changeset: bad38a0f
Author:    David Alayachew <davidalayachew at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bad38a0f928589be62cabcc48df8a4651c615b3c
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8365643: JShell EditPad out of bounds on Windows

Reviewed-by: liach, aivanov, cstein, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/26814

From kcr at openjdk.org  Mon Aug 18 21:11:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 18 Aug 2025 21:11:52 GMT
Subject: Withdrawn: 8360070: AccessibleText.getBeforeIndex returns null for
 last character
In-Reply-To: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
Message-ID: <bMH8P69oxB-L-HJsDmnDg6HnEDylEELbFYWRdxu2TNM=.005bd0dd-6333-4604-8914-4e41a8540a6d@github.com>

On Mon, 23 Jun 2025 17:40:42 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**.
> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect.
> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**.
> 
> After modifying the condition check, expected character is returned. Test is added to verify the check,

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25941

From serb at openjdk.org  Tue Aug 19 00:26:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 19 Aug 2025 00:26:37 GMT
Subject: RFR: 8277585: Remove the terminally deprecated finalize() method
 from javax.imageio.stream APIs [v3]
In-Reply-To: <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
 <MvSAdwCVd76TNLswLhTEH_EObA5dcJzfsMkrfWTqOc8=.a425608a-0ee1-40ca-a62b-a9fa8c3f2f27@github.com>
Message-ID: <7jfF16EB8ZanLANMAZfau1Vd4js6rEz4_gJPcz22Duo=.8063f400-2bf4-4433-b9f3-6f4830eff541@github.com>

On Wed, 6 Aug 2025 22:34:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
>> As a result, sub-classes which over-ride it to be empty no longer need to do so.
>> Also it means that the 2 remaining classes which used it no longer can.
>> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
>> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
>> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
>> really meant to clean up internal resources.
>> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
>> 
>> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
>> The risks of this will be covered in the CSR.
>> 
>> There's also a lengthy write up in the JBS issue.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277585

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26650#pullrequestreview-3130299620

From serb at openjdk.org  Tue Aug 19 00:42:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 19 Aug 2025 00:42:40 GMT
Subject: RFR: 8359955: Regressions ~7% in several J2DBench in 25-b26
In-Reply-To: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
References: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
Message-ID: <s__OIm82JHynj7Oy1Kf0JIF9tZ5gQiVgo02Iu9TwPfQ=.670a7ac2-9795-4854-9907-489036b79a76@github.com>

On Fri, 8 Aug 2025 16:37:36 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Addresses recent slight performance regressions in some J2DBench benchmarks focused on text drawing.
> 
> `CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after JDK-8353230 they weren't caching glyph IDs for chars which might be affected by the raw / non-raw glyph distinction, since the cached value may not be correct if we ask for a raw glyph ID one time, but a non-raw glyph ID the next time (or vice versa). This caching exception was the reason for the slightly degraded performance (the `CCharToGlyphMapper` behavior was affecting macOS, and the `CompositeGlyphMapper` behavior was affecting some versions of Windows). This change splits the cache in each of these two classes into two caches, one for raw glyph IDs and one for non-raw glyph IDs, so that all glyphs can benefit from caching.
> 
> All of the font tests (`make test TEST="jtreg:test/jdk/java/awt/font"`) pass for me locally with this change on Linux, macOS and Windows.

src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 287:

> 285:                 } else if (isIgnorableWhitespace(code) || (isDefaultIgnorable(code) && !raw)) {
> 286:                     values[i] = INVISIBLE_GLYPH_ID;
> 287:                     put(code, INVISIBLE_GLYPH_ID);

Why do we need to change these lines instead of changing "get()" method above to use "this.raw" instead of parameter?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26702#discussion_r2283769930

From psadhukhan at openjdk.org  Tue Aug 19 03:12:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 19 Aug 2025 03:12:54 GMT
Subject: RFR: 8365625: Can't change accelerator colors in Windows L&F
In-Reply-To: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
References: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
Message-ID: <sBPuPRiBkpw9RTF87gHzU5rAE2feoPLENQtim9y91ks=.4649a205-0ab8-44e5-9006-53234de52232@github.com>

On Mon, 18 Aug 2025 16:31:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The colors for the accelerators are cached in static fields: `disabledForeground`, `acceleratorSelectionForeground` and `acceleratorForeground`. As soon as this field is set to a non-`UIResource` value, the value cannot change.
> 
> **Fix:**
> 
> Remove the static fields for accelerator from `WindowsMenuItemUI` and use the fields inherited from `BasicMenuItemUI`, pass these fields as parameters to static methods.
> 
> Additionally, I formatted the calls to `WindowsMenuItemUI.paintMenuItem` in one consistent way.
> 
> I removed the redundant javadoc from `paintMenuItem` and added the missing `@Override` annotation.
> 
> I provided a regression test. The test also reproduces [JDK-8365375](https://bugs.openjdk.org/browse/JDK-8365375) that was resolved in #26743.

test/jdk/com/sun/java/swing/plaf/windows/MenuItem/MenuItemAcceleratorColor.java line 126:

> 124:         Color acceleratorSelectionForeground = UIManager.getColor("MenuItem.acceleratorSelectionForeground");
> 125:         UIManager.put("MenuItem.acceleratorForeground", Color.GREEN);
> 126:         UIManager.put("MenuItem.acceleratorSelectionForeground", Color.RED);

We are testing 2 of 3 static fields..I guess since we do not have test for these fields explicitly, we can test the 3rd one too which is `disabledForeground`

like putting `UIManager.put("MenuItem.disabledForeground", Color.BLUE) `
and do `quit.setEnabled(false)` in which case it should be BLUE

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26826#discussion_r2283953201

From syan at openjdk.org  Tue Aug 19 03:34:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 03:34:47 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
Message-ID: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>

On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> It is unclear to me if the author meant this to be `2.5` more than normal or `10` more than JTREG default, or a `multiplier that seems to work`. It does not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a value that is not the multiplicative identity value. I will not change this, the change I have made is already large enough and I want this to be integrated ASAP.
>
> It is also something that can be changed later, in a follow up fix.

Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds too long and it's unacceptable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2283972732

From psadhukhan at openjdk.org  Tue Aug 19 04:21:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 19 Aug 2025 04:21:39 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v23]
In-Reply-To: <8dn5G3cN32T_u5d1P_n5iMLscKrT7q1a4by6b67NxjU=.792efe80-015d-4a2a-8e17-9411adc7f1d5@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <8dn5G3cN32T_u5d1P_n5iMLscKrT7q1a4by6b67NxjU=.792efe80-015d-4a2a-8e17-9411adc7f1d5@github.com>
Message-ID: <MHChzrltjIFudHj77GXx7UsJBqsXWE7PrOKyzmW-sbY=.aaed5b13-a45d-4e11-8d19-ca430ce00bb2@github.com>

On Mon, 18 Aug 2025 13:22:58 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 135:

> 133:                                 testedComponent.getPreferredSize().height + 20);
> 134:                         Component focusOwner = FocusManager.getCurrentManager()
> 135:                                 .getFocusOwner();

Usually we use `KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner()`

test/jdk/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java line 100:

> 98:         f.setLocationRelativeTo(null);
> 99:         f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> 100:         f.setLocationRelativeTo(null);

it already calls `setLocationRelativeTo` above..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2284018183
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2284017150

From mvs at openjdk.org  Tue Aug 19 04:30:54 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 19 Aug 2025 04:30:54 GMT
Subject: RFR: 8364506: javax/swing/Popup/TaskbarPositionTest.java can fail
 subsequent tests on MacOS
In-Reply-To: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
References: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
Message-ID: <Oe2FZ86cXaIw_4clACB5C7PqAhZwCRURZRH-6O7f-jM=.b7608467-0b25-4fba-8c72-97d4161abc1b@github.com>

On Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to show all windows related to the focused one.
> 
> Fix:
> Change the 'Cntrl' key to 'Shift'
> 
> Testing:
> Tested in all supported platforms using mach5 and got all PASS.

Thanks all, I will close this PR and will do the specified settings changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26623#issuecomment-3199163838

From mvs at openjdk.org  Tue Aug 19 04:30:54 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 19 Aug 2025 04:30:54 GMT
Subject: Withdrawn: 8364506: javax/swing/Popup/TaskbarPositionTest.java can
 fail subsequent tests on MacOS
In-Reply-To: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
References: <q4Cyfcw5nkG0R6W6QHjyk48k-p7ABVmqriH9pVDhhBY=.698f869b-c411-4583-8433-95293b1ece27@github.com>
Message-ID: <urPd4xLu-YcVCktqSgzQmTBzGBuci3uPLk3dxMrgp-4=.964d9055-3e3b-4541-83d8-30c2a4f4bccb@github.com>

On Mon, 4 Aug 2025 15:14:30 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/Popup/TaskbarPositionTest.java can fail subsequent tests on MacOS because of using 'Cntrl+Down Arrow' as this acts as a shortcut in MacOS to show all windows related to the focused one.
> 
> Fix:
> Change the 'Cntrl' key to 'Shift'
> 
> Testing:
> Tested in all supported platforms using mach5 and got all PASS.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/26623

From dholmes at openjdk.org  Tue Aug 19 05:25:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:25:40 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
Message-ID: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>

On Tue, 19 Aug 2025 03:31:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> It is also something that can be changed later, in a follow up fix.
>
> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.

> It is unclear to me if the author meant this to be 2.5 more than normal or 10 more than JTREG default, or a multiplier that seems to work. 

What matters is that the actual timeout, in seconds, remains unchanged, so please address this. Timeouts that are excessively long waste machine resources.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284090715

From dholmes at openjdk.org  Tue Aug 19 05:49:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 05:49:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199288818

From dholmes at openjdk.org  Tue Aug 19 06:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Aug 2025 06:07:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
Message-ID: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>

On Tue, 19 Aug 2025 05:23:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Take test test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java as example.
>> If there is a bug in jvm with -Xcomp option which will cause this test run time outed. Before this PR, it will take `7200*10` seconds to run this test finish and report time outed failure. But after this PR, it will take `28800*10` seconds to run this test finish ang then report timed out failure. I think the `28800*10` senonds is too long and it's unacceptable.
>
> DELETED - I confused the timeout with the timeout-factor. New comment below.

No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 

However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284161138

From psadhukhan at openjdk.org  Tue Aug 19 06:22:21 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 19 Aug 2025 06:22:21 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
Message-ID: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>

Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent

-------------

Commit messages:
 - 8365425: [macos26] javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on macOS 26
 - 8365425: [macos26] javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on macOS 26
 - 8365425: [macos26] javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on macOS 26

Changes: https://git.openjdk.org/jdk/pull/26833/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26833&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365425
  Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26833.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26833/head:pull/26833

PR: https://git.openjdk.org/jdk/pull/26833

From serb at openjdk.org  Tue Aug 19 06:36:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 19 Aug 2025 06:36:52 GMT
Subject: Integrated: 8359380: Rework deferral profile logic after JDK-8346465
In-Reply-To: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
References: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
Message-ID: <pt8axCdC1Sd2IFxTXvYy_YnQqX6bVG8K_uNOicq4rpA=.b1b9668e-7a49-48f6-bd9c-97986b028351@github.com>

On Tue, 8 Jul 2025 05:26:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
> 
> After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
> 
> This patch includes two changes:
> 
> 1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
> 
> 2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

This pull request has now been integrated.

Changeset: 4c80780f
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c80780f6a3fef688d932bdad04e98eb1bd16563
Stats:     312 lines in 9 files changed: 192 ins; 72 del; 48 mod

8359380: Rework deferral profile logic after JDK-8346465

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/26179

From syan at openjdk.org  Tue Aug 19 06:40:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 19 Aug 2025 06:40:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
Message-ID: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>

On Tue, 19 Aug 2025 06:04:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DELETED - I confused the timeout with the timeout-factor. New comment below.
>
> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
> 
> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.

But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.

The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284273170

From lkorinth at openjdk.org  Tue Aug 19 09:02:36 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:02:36 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <udTuOggA49cX_TuaXsyvEd8U1IXCrKSagYH41gWoSts=.e4c1dce7-85e3-432e-bb88-ee33d26afd72@github.com>
Message-ID: <uOH12UfZUHixcxSAx8lP66zvzxKr50yUj8x4_x22Su0=.31769f01-81c4-48b0-9050-f642c562deb5@github.com>

On Tue, 19 Aug 2025 05:47:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

> By rough count there are 1300 tests that have an explicit timeout set. This change would reduce the actual applied timeout to a quarter of what was previously used, yet you have only had to bump the timeout value for a fraction of the tests - which I find somewhat (pleasantly) surprising. It may be that many of these timeouts stem from a time when we had much much slower machines, so a refresh might not be a bad thing. It will take some time to see the full effects of this change though.

Thanks David! And as you said, a few more adjustments will probably be needed when we have run this for a while.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3199869795

From lkorinth at openjdk.org  Tue Aug 19 09:19:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 19 Aug 2025 09:19:45 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <BM1P_203-vMLbBYxbzigREy0NuHWoZqfgQvmGV0SH7I=.bf66ee89-19a9-4212-b800-08e7c835f4de@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

I do not think 4x longer timeouts for `-Xcomp` is unreasonable. I also do not want to make this huge change even bigger. If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2284650722

From duke at openjdk.org  Tue Aug 19 09:30:13 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 19 Aug 2025 09:30:13 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v23]
In-Reply-To: <MHChzrltjIFudHj77GXx7UsJBqsXWE7PrOKyzmW-sbY=.aaed5b13-a45d-4e11-8d19-ca430ce00bb2@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <8dn5G3cN32T_u5d1P_n5iMLscKrT7q1a4by6b67NxjU=.792efe80-015d-4a2a-8e17-9411adc7f1d5@github.com>
 <MHChzrltjIFudHj77GXx7UsJBqsXWE7PrOKyzmW-sbY=.aaed5b13-a45d-4e11-8d19-ca430ce00bb2@github.com>
Message-ID: <V1wXweGzYKlqzfkLAZoYSxbXCtJoYAwWeOvDDA_tbpY=.ac209730-2c15-4cb0-a02a-f81b54d74733@github.com>

On Tue, 19 Aug 2025 04:18:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates copyright years
>
> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 135:
> 
>> 133:                                 testedComponent.getPreferredSize().height + 20);
>> 134:                         Component focusOwner = FocusManager.getCurrentManager()
>> 135:                                 .getFocusOwner();
> 
> Usually we use `KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner()`

Requested change committed.

> test/jdk/java/awt/Mixing/AWT_Mixing/ViewportOverlapping.java line 100:
> 
>> 98:         f.setLocationRelativeTo(null);
>> 99:         f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>> 100:         f.setLocationRelativeTo(null);
> 
> it already calls `setLocationRelativeTo` above..

Changes reverted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2284671477
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2284670526

From duke at openjdk.org  Tue Aug 19 09:30:12 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 19 Aug 2025 09:30:12 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v24]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <BZ2RopZ5Gmq4z7k7Xu_nq-1V0sfXgtzuJMOhBH6IOwE=.ebb4a0fd-3ea9-4bb8-ba72-9e25d52e9f90@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision:

 - Uses KeyboardFocusManager instead of FocusManager
 - Reverted not needed changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/ffbe6963..449c397e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=22-23

  Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

PR: https://git.openjdk.org/jdk/pull/25971

From dgredler at openjdk.org  Tue Aug 19 10:58:39 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Tue, 19 Aug 2025 10:58:39 GMT
Subject: RFR: 8359955: Regressions ~7% in several J2DBench in 25-b26
In-Reply-To: <s__OIm82JHynj7Oy1Kf0JIF9tZ5gQiVgo02Iu9TwPfQ=.670a7ac2-9795-4854-9907-489036b79a76@github.com>
References: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
 <s__OIm82JHynj7Oy1Kf0JIF9tZ5gQiVgo02Iu9TwPfQ=.670a7ac2-9795-4854-9907-489036b79a76@github.com>
Message-ID: <bD8x-dLyIgn0DuzuOWE69YeuQdZynLqgLur8jZQoO5Q=.2519b5de-2f44-410d-aa0a-9d150f4930d8@github.com>

On Tue, 19 Aug 2025 00:39:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Addresses recent slight performance regressions in some J2DBench benchmarks focused on text drawing.
>> 
>> `CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after JDK-8353230 they weren't caching glyph IDs for chars which might be affected by the raw / non-raw glyph distinction, since the cached value may not be correct if we ask for a raw glyph ID one time, but a non-raw glyph ID the next time (or vice versa). This caching exception was the reason for the slightly degraded performance (the `CCharToGlyphMapper` behavior was affecting macOS, and the `CompositeGlyphMapper` behavior was affecting some versions of Windows). This change splits the cache in each of these two classes into two caches, one for raw glyph IDs and one for non-raw glyph IDs, so that all glyphs can benefit from caching.
>> 
>> All of the font tests (`make test TEST="jtreg:test/jdk/java/awt/font"`) pass for me locally with this change on Linux, macOS and Windows.
>
> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 287:
> 
>> 285:                 } else if (isIgnorableWhitespace(code) || (isDefaultIgnorable(code) && !raw)) {
>> 286:                     values[i] = INVISIBLE_GLYPH_ID;
>> 287:                     put(code, INVISIBLE_GLYPH_ID);
> 
> Why do we need to change these lines instead of changing "get()" method above to use "this.raw" instead of parameter?

I'm not sure which `get` method you're referring to, but within `Cache` all `raw` parameters should indeed be gone now, and there should only be references to `this.raw`.

The key to the performance improvement is to allow values to be retrieved from the cache *before* any `isIgnorableWhitespace` or `isDefaultIgnorable` checks, and to make sure that all values are cached for future use (even if these checks determine that special handling is needed). That's why these extra lines are moved out of `get(int)`, so that they run only if/after a cache lookup fails.

Let me know if that makes sense, or if I misunderstood your question.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26702#discussion_r2284884051

From djgredler at gmail.com  Tue Aug 19 11:29:13 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Tue, 19 Aug 2025 13:29:13 +0200
Subject: JDK-4138921: TextLayout handling of empty strings
In-Reply-To: <994c74d6-2eb4-4588-ad6a-25529b68bd1e@oracle.com>
References: <CAPA+ug6A88qeG+bRC3UAvvkp67jALtQXEsF0OMxK=WnsXbxQUw@mail.gmail.com>
 <994c74d6-2eb4-4588-ad6a-25529b68bd1e@oracle.com>
Message-ID: <CAPA+ug7fWrp3JUq_VHh+ohpMoGfMvjm-JeXS7gVRht0zfn7Gxg@mail.gmail.com>

Hi Phil,

>> First, there is a related API oddity in that null FontRenderContext
>> parameters passed to the TextLayout constructors cause a
>> NullPointerException, rather than an IllegalArgumentException (like
>> all other parameters). Can this behavior also be changed?

> It is a bit odd that frc is the only one not explicitly checked so the
> NPE is just what 'happens'.
> I'd be reluctant to change the NPE without a good reason [...]
> I'd say just specify what happens for complete compatibility.

I guess I'm hesitant to promote an "accidental" NPE to official behavior
here, when all other null parameter values are handled with an explicit
IAE. This inconsistency is going to surprise developers, and avoiding that
surprise would be ideal. How likely is it that adding an explicit
IAE-generating null FRC check here will break existing code?

Take care,

Daniel


On Mon, Aug 11, 2025 at 7:12?PM Philip Race <philip.race at oracle.com> wrote:

>
>
> On 8/11/25 9:20 AM, Daniel Gredler wrote:
> > Hi all,
> >
> > I was thinking of taking a stab at JDK-4138921 [1], and I have a
> > couple of questions.
> >
> > First, there is a related API oddity in that null FontRenderContext
> > parameters passed to the TextLayout constructors cause a
> > NullPointerException, rather than an IllegalArgumentException (like
> > all other parameters). Can this behavior also be changed?
>
> None of these are documented .. they all should be.
>
> It is a bit odd that frc is the only one not explicitly checked so the
> NPE is just what 'happens'.
> I'd be reluctant to change the NPE without a good reason and I'm
> half-wondering if a null FRC was
> supposed to default to a default FRC ?? But somewhere along the line the
> implementation changed.
> I'd say just specify what happens for complete compatibility.
>
> >
> > Second, changing all three TextLayout constructors to accept empty
> > strings sort of implies that we should also allow empty strings in
> > AttributedString instances (this is currently only allowed if the
> > attribute map is empty). Is it OK to change this behavior as well?
>
> I don't think I ever understood why this was dis-allowed on TextLayout.
> Perhaps it was to prevent some incorrect usage from ever slipping into
> being acceptable ?
>
> AttributedString is part of the java.base module, I don't have any say
> over that, although in the very beginning
> there was a decent overlap in the people working on that and TextLayout
> etc.
> I'd start by asking Naoto (cc'ed).
>
> -phil.
>
> >
> > Let me know your thoughts!
> >
> > Daniel
> >
> > [1] https://bugs.openjdk.org/browse/JDK-4138921
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250819/3cd0cfc6/attachment.htm>

From simonis at openjdk.org  Tue Aug 19 13:20:57 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Aug 2025 13:20:57 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v2]
In-Reply-To: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
Message-ID: <FJcZZVlBklEUXasxgZ2BmkYdpW9SbvMc9N-Zh81Ldt4=.9ef06db3-77b7-4b78-bc81-8d8e534c8388@github.com>

> ### TL;DR
> 
> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
> 
> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
> 
> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
> 
> ### Full description
> 
> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
> 
> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
> 
> Segment: ?????????? 0 10
> Segment: ????????? 10 9
> Segment: ???????? 19 8
> Segment: ? 27 1
> 
> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) fonts but the results were similar, so I'...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  No need to count 'clusterExtraGlyphs' any more

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26825/files
  - new: https://git.openjdk.org/jdk/pull/26825/files/a52916b2..ba3e50b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26825&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26825&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26825/head:pull/26825

PR: https://git.openjdk.org/jdk/pull/26825

From simonis at openjdk.org  Tue Aug 19 13:23:37 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Aug 2025 13:23:37 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8
In-Reply-To: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
Message-ID: <m_QDCwBDnp9VLXl1W7iUD6ZCpuNU1QZTcvV2y0aMjpw=.c322bf7d-c123-4a75-aba4-ca7739927ddb@github.com>

On Mon, 18 Aug 2025 16:05:24 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> ### TL;DR
> 
> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
> 
> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
> 
> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
> 
> ### Full description
> 
> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
> 
> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
> 
> Segment: ?????????? 0 10
> Segment: ????????? 10 9
> Segment: ???????? 19 8
> Segment: ? 27 1
> 
> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) fonts but the results were similar, so I'...

As @mrserb correctly mentioned, there's now no need to count `clusterExtraGlyphs` any more, so I've removed it completely from the code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3200747024

From aturbanov at openjdk.org  Tue Aug 19 14:25:39 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Aug 2025 14:25:39 GMT
Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java
In-Reply-To: <gvG7FJiUONPg1uSza7EFPjns0JUFosfE6gHlTDHpzGI=.63540380-fd25-4beb-b062-8da20cd7dceb@github.com>
References: <gvG7FJiUONPg1uSza7EFPjns0JUFosfE6gHlTDHpzGI=.63540380-fd25-4beb-b062-8da20cd7dceb@github.com>
Message-ID: <fzGO3qUfwVr4661rVZXs1nt5y8kdt3YjWqueTD8D9Xg=.093a2893-67c3-4f8b-869a-2cde83616eda@github.com>

On Thu, 14 Aug 2025 17:27:09 GMT, Phil Race <prr at openjdk.org> wrote:

> This refactors com/sun/media/sound/JavaSoundAudioClip.java so that most of the implementation is in a delegate
> com/sun/media/sound/JavaSoundAudioClipDelegate.java
> 
> Then a disposer can be used to free the audio resources held by the delegate when the JavaSoundAudioClip becomes unreachable.

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClipDelegate.java line 296:

> 294:     // FILE LOADING METHODS
> 295: 
> 296:     private boolean loadAudioData(AudioInputStream as)  throws IOException, UnsupportedAudioFileException {

Suggestion:

    private boolean loadAudioData(AudioInputStream as) throws IOException, UnsupportedAudioFileException {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26784#discussion_r2285446512

From simonis at openjdk.org  Tue Aug 19 14:41:54 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Aug 2025 14:41:54 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v3]
In-Reply-To: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
Message-ID: <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>

> ### TL;DR
> 
> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
> 
> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
> 
> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
> 
> ### Full description
> 
> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
> 
> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
> 
> Segment: ?????????? 0 10
> Segment: ????????? 10 9
> Segment: ???????? 19 8
> Segment: ? 27 1
> 
> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) fonts but the results were similar, so I'...

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Added JTreg test to verify monotonically growing glyph character indices

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26825/files
  - new: https://git.openjdk.org/jdk/pull/26825/files/ba3e50b2..493c6ba1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26825&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26825&range=01-02

  Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26825/head:pull/26825

PR: https://git.openjdk.org/jdk/pull/26825

From simonis at openjdk.org  Tue Aug 19 14:44:38 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 19 Aug 2025 14:44:38 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v2]
In-Reply-To: <FJcZZVlBklEUXasxgZ2BmkYdpW9SbvMc9N-Zh81Ldt4=.9ef06db3-77b7-4b78-bc81-8d8e534c8388@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
 <FJcZZVlBklEUXasxgZ2BmkYdpW9SbvMc9N-Zh81Ldt4=.9ef06db3-77b7-4b78-bc81-8d8e534c8388@github.com>
Message-ID: <inQfRBN_PNTcLJCWGXgw0R3qShtJXhKR6eYf9alr9Ng=.73bab475-3c37-4ebd-9f16-bd3f7aac40d3@github.com>

On Tue, 19 Aug 2025 13:20:57 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### TL;DR
>> 
>> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
>> 
>> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
>> 
>> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
>> 
>> ### Full description
>> 
>> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
>> 
>> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
>> 
>> Segment: ?????????? 0 10
>> Segment: ????????? 10 9
>> Segment: ???????? 19 8
>> Segment: ? 27 1
>> 
>> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) f...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need to count 'clusterExtraGlyphs' any more

It's hard to add a JTreg test for this specific issue because line breaking is inherently font dependent and we don't have any standard Unicode fonts in OpenJDK. But we can at least add a test to verify monotonically growing glyph character indices.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3201048849

From duke at openjdk.org  Tue Aug 19 14:47:58 2025
From: duke at openjdk.org (Christian Heilmann)
Date: Tue, 19 Aug 2025 14:47:58 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
Message-ID: <T2ZpNWsTvBKICBriN_ckaN2qW0HbqPuH-Oc0SySpusw=.cac70133-c2cb-4e7e-b8d3-db6f9fbbe3ea@github.com>

On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann <duke at openjdk.org> wrote:

>> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
>> 
>> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.
>
> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
>  - Merge branch 'master' into pr/11266
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS

Are there any updates on the review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3201062535

From duke at openjdk.org  Tue Aug 19 14:54:16 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 19 Aug 2025 14:54:16 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v25]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 39 additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers missed frames in the middle of screen
 - Uses KeyboardFocusManager instead of FocusManager
 - Reverted not needed changes
 - Updates copyright years
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers frames in the middle of the screen
 - Releses latch in case of null ancestor or resizing component
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - ... and 29 more: https://git.openjdk.org/jdk/compare/1a3b96ad...9358a9d8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/449c397e..9358a9d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=23-24

  Stats: 1437 lines in 106 files changed: 931 ins; 186 del; 320 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

PR: https://git.openjdk.org/jdk/pull/25971

From duke at openjdk.org  Tue Aug 19 14:58:44 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 19 Aug 2025 14:58:44 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v25]
In-Reply-To: <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
Message-ID: <I0bMfOHsLvYrtmtJFwwcWuZYlx6A0IzBEZ0BC1H85A8=.b6c54ad4-4f8c-47e1-831d-defc54857227@github.com>

On Tue, 19 Aug 2025 14:54:16 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 39 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Centers missed frames in the middle of screen
>  - Uses KeyboardFocusManager instead of FocusManager
>  - Reverted not needed changes
>  - Updates copyright years
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Centers frames in the middle of the screen
>  - Releses latch in case of null ancestor or resizing component
>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/5591addc...9358a9d8

Centered some missed frames. Tested all de-problem listed tests on all platforms and tests passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3201101487

From prr at openjdk.org  Tue Aug 19 16:47:43 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Aug 2025 16:47:43 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
Message-ID: <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>

> Remove finalize() from WInputMethod.java - it is used to free a native id.
> Also the reason dispose() didn't free it seems no longer relevant.
> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8365180

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26706/files
  - new: https://git.openjdk.org/jdk/pull/26706/files/fc422aa0..3c8c9cb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26706&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26706/head:pull/26706

PR: https://git.openjdk.org/jdk/pull/26706

From prr at openjdk.org  Tue Aug 19 16:47:44 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Aug 2025 16:47:44 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <mvREF1kqmZjo-lY7XzSfcS-HcXMIjBW5QMkvIwnlx1w=.5b527fa4-6617-485d-ac23-2bc159b6bac8@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <7Y6CyPSlOkULmeXDFaczZZrN3KLud89VFgurU6JIaYw=.9bcc4c75-b118-4d2d-9249-34f9af181993@github.com>
 <haYFtgNWOsWdvIIASSVV3jrxG9ThC-6_RQB4h-FPkm4=.3e5b5cfb-7fd5-40a4-8e1c-edfb6b35aa31@github.com>
 <mvREF1kqmZjo-lY7XzSfcS-HcXMIjBW5QMkvIwnlx1w=.5b527fa4-6617-485d-ac23-2bc159b6bac8@github.com>
Message-ID: <e8mTx75CXVhsoHJMihw2dd5rpAyqqBXWIkNHx-8ths0=.a5c06de6-f8c4-464a-b6c6-a0f39537acff@github.com>

On Fri, 15 Aug 2025 20:10:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Maybe disableNativeIME is called when the top level Window is disposed, 

No it is not.  

 Nothing calls disableNativeIME when the window is disposed. I tried this with the disposer removed and finalize restored just to be sure.

Also it needs to be called 'early' but not 'too early' during WIndow.dispose()
If the input method is active when you try to dispose it via APIs like disableNativeIM() then an exception is thrown.

If you call it too late - after removeNotify()  then it will not be sent because the peer is now nulled out.


src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp
@@ -1082,6 +1082,7 @@ LRESULT CALLBACK AwtToolkit::WndProc(HWND hWnd, UINT message,
           AwtComponent* comp = (AwtComponent*)JNI_GET_PDATA(peer);
           if (comp != NULL)
           {
               comp->SetInputMethod(self, useNativeCompWindow);
comp->ImmAssociateContext((HIMC)((intptr_t)context));
           }

Since we never call it, then this migration to disposer changes nothing.
If we do call it I  think it should be called in WInputMethod.removeNotify() which will clearly be before dispose().
I will add that and we'll be better off then we were before this change.

 I also found that if the window has focus when it is dispose()'d that it will receive a focus lost event which ironically creates a new WInputMethod because Window.dispose() had nulled out the existing one 

Either don't null out the disposed one, or do something else to avoid re-creation, or decide that it is harmless .
For now I will leave that as it seems to be harmless, pre-existing and un-related to this change, although a little wasteful. It also would be more than a windows-only change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26706#discussion_r2285798990

From mvs at openjdk.org  Tue Aug 19 17:24:46 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 19 Aug 2025 17:24:46 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v25]
In-Reply-To: <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
Message-ID: <IGmP0uL5mWS23T2FUnrOf-Ivsru9FZQQWom1snZq9t8=.3f8798c0-363a-44b7-b501-b11a88d96019@github.com>

On Tue, 19 Aug 2025 14:54:16 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 39 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Centers missed frames in the middle of screen
>  - Uses KeyboardFocusManager instead of FocusManager
>  - Reverted not needed changes
>  - Updates copyright years
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Centers frames in the middle of the screen
>  - Releses latch in case of null ancestor or resizing component
>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/d442f9f3...9358a9d8

test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 67:

> 65:         frame.getContentPane().setLayout(new BoxLayout(frame.getContentPane(), BoxLayout.Y_AXIS));
> 66:         frame.setSize(200, 200);
> 67:         frame.setLocationRelativeTo(null);

Are we disposing this frame somewhere(it's applicable to all the test files)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2285879821

From serb at openjdk.org  Tue Aug 19 17:27:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 19 Aug 2025 17:27:39 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
Message-ID: <dDK1UhX6KoY_mKZfY8u0JXBGADWvqdVCv_JQOhG6k50=.231288f7-ee29-40c5-aa0b-8bcfa1477d83@github.com>

On Tue, 19 Aug 2025 06:14:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent

the test might be updated to render components into the buffered image and then compare exact values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26833#issuecomment-3201583970

From prr at openjdk.org  Tue Aug 19 20:06:46 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Aug 2025 20:06:46 GMT
Subject: Integrated: 8277585: Remove the terminally deprecated finalize()
 method from javax.imageio.stream APIs
In-Reply-To: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
References: <_CSlVhwEWQanLFTQvIr8rTuwhhKiFhbRFIW4KOrrgiI=.21ebe51b-bf59-4b80-a06e-6e97be068547@github.com>
Message-ID: <vp3rghiub4g7xxPdmMt8vKrrVPt49a3US1ki-y-QtqU=.5680cea8-b3ab-4147-9d60-f3130d1fcf7a@github.com>

On Tue, 5 Aug 2025 21:17:36 GMT, Phil Race <prr at openjdk.org> wrote:

> This PR removes javax/imageio/stream/ImageInputStreamImpl.finalize()
> As a result, sub-classes which over-ride it to be empty no longer need to do so.
> Also it means that the 2 remaining classes which used it no longer can.
> FileCacheImageOutputStream will have its cache cleaned up by a disposer.
> The impact on applications is that they, or the ImageWriter may need to call flush() IF they relied on finalization.
> However that should be extremely unlikely given that finalization will happen far too late in most cases, and is
> really meant to clean up internal resources.
> The JDK's GIF and TIFF image writers don't flush themselves, so applications which use these together with one of these caching streams would have learned this already.
> 
> The principal outside risk is to 3rd party ImageIO stream subclasses which both allocate native resources and rely on finalization as a backstop clean up in case applications forget to call close. But it will be the applications that are affected if the resource is depleted. 
> The risks of this will be covered in the CSR.
> 
> There's also a lengthy write up in the JBS issue.

This pull request has now been integrated.

Changeset: 0858743d
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0858743deed6b4fa2329983c7911d9f56f875b8e
Stats:     251 lines in 10 files changed: 37 ins; 203 del; 11 mod

8277585: Remove the terminally deprecated finalize() method from javax.imageio.stream APIs

Reviewed-by: achung, azvegint, serb

-------------

PR: https://git.openjdk.org/jdk/pull/26650

From prr at openjdk.org  Tue Aug 19 20:12:40 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Aug 2025 20:12:40 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v4]
In-Reply-To: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
Message-ID: <8UVej2SrE6rah1H5A3EPegbSS_S027me2YJn4iRbaKE=.d1c5e3f6-8fb2-4088-8049-043adb6021da@github.com>

> This refactors some Swing code to pass args instead of using statics
> The bug report suggests some further refactoring which could be considered later, but the most
> important thing to do is to eliminate using statics to pass args.
> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8365389

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26783/files
  - new: https://git.openjdk.org/jdk/pull/26783/files/1b676514..89d6bfc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26783&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26783&range=02-03

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26783/head:pull/26783

PR: https://git.openjdk.org/jdk/pull/26783

From prr at openjdk.org  Tue Aug 19 20:18:35 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Aug 2025 20:18:35 GMT
Subject: RFR: 8365615: Improve JMenuBar/RightLeftOrientation.java
In-Reply-To: <XxNYwd8AnjCdUUQTHNWkeSF89KE7-ruCiwVIpsGUCjM=.c4090af6-c428-41b1-93ae-5380a0f78795@github.com>
References: <XxNYwd8AnjCdUUQTHNWkeSF89KE7-ruCiwVIpsGUCjM=.c4090af6-c428-41b1-93ae-5380a0f78795@github.com>
Message-ID: <REu35ycZTXLHzYNWj6hXH08vphKCa3zW4atAPdNe9CY=.fd35789d-f38d-4ced-b0d0-aaee4aeb6d86@github.com>

On Fri, 15 Aug 2025 16:46:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Position the two frames with menu bars in left-to-right and right-to-left orientations below the frame that allows changing the look and feel.
> 
> Additionally, amend the instructions and refactor the code, show an error message to the tester if setting L&F fails.

I ran it and it LGTM

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26803#pullrequestreview-3133693334

From serb at openjdk.org  Wed Aug 20 01:47:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 20 Aug 2025 01:47:36 GMT
Subject: RFR: 8359955: Regressions ~7% in several J2DBench in 25-b26
In-Reply-To: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
References: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
Message-ID: <QuL2bsRgup__hPXZ561EzDQUZs_S7Im1SvXle-sueOA=.4ab577fc-6ea3-4696-9146-a533840b7609@github.com>

On Fri, 8 Aug 2025 16:37:36 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Addresses recent slight performance regressions in some J2DBench benchmarks focused on text drawing.
> 
> `CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after JDK-8353230 they weren't caching glyph IDs for chars which might be affected by the raw / non-raw glyph distinction, since the cached value may not be correct if we ask for a raw glyph ID one time, but a non-raw glyph ID the next time (or vice versa). This caching exception was the reason for the slightly degraded performance (the `CCharToGlyphMapper` behavior was affecting macOS, and the `CompositeGlyphMapper` behavior was affecting some versions of Windows). This change splits the cache in each of these two classes into two caches, one for raw glyph IDs and one for non-raw glyph IDs, so that all glyphs can benefit from caching.
> 
> All of the font tests (`make test TEST="jtreg:test/jdk/java/awt/font"`) pass for me locally with this change on Linux, macOS and Windows.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26702#pullrequestreview-3134524180

From serb at openjdk.org  Wed Aug 20 02:33:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 20 Aug 2025 02:33:38 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
Message-ID: <nRMLpo0Ge-P1-3KnOxc9MOaeE1zgeel4fMUGWGae_uw=.cd663f4d-c64e-47a9-9939-48fc03fde072@github.com>

On Tue, 19 Aug 2025 16:47:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove finalize() from WInputMethod.java - it is used to free a native id.
>> Also the reason dispose() didn't free it seems no longer relevant.
>> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
>> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365180

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26706#pullrequestreview-3134581026

From serb at openjdk.org  Wed Aug 20 03:36:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 20 Aug 2025 03:36:40 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux [v4]
In-Reply-To: <vcgKUlxIwewW3mEAPG_dMu4YNMOkWqWKgekQDBGHuNE=.475ff567-096e-4f4d-bd02-1eaa762b192f@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
 <vcgKUlxIwewW3mEAPG_dMu4YNMOkWqWKgekQDBGHuNE=.475ff567-096e-4f4d-bd02-1eaa762b192f@github.com>
Message-ID: <4nizPJ8pnbsc_f0IlYI_yuhXaeaPVsShr1O3if9Uk0s=.40bd2d10-280b-4e2e-8d45-3788f72100c5@github.com>

On Fri, 8 Aug 2025 00:30:25 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> **Analysis:**
>> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
>> 
>> **Proposed Fix:**
>> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
>> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once
>
> Anass Baya has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Respect rules
>  - remove space
>  - Update focusability only when it is needed

src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 1101:

> 1099:             }
> 1100:         }
> 1101:         if(isVisible() != vis) {

you may add a space "if (isVisible() != vis) {"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26298#discussion_r2286895718

From rgupta at openjdk.org  Wed Aug 20 04:55:46 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Wed, 20 Aug 2025 04:55:46 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v9]
In-Reply-To: <r7frTU2JrTpy48099SEiSJ0QWFG73NX3VnchFZn0kWY=.a0df6347-ed8e-4709-8442-bb25c9243aee@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
 <r7frTU2JrTpy48099SEiSJ0QWFG73NX3VnchFZn0kWY=.a0df6347-ed8e-4709-8442-bb25c9243aee@github.com>
Message-ID: <fZXbq1qEBtIFwXb07zUBgGJ9lhMOXAun6jcBxDc9cXs=.a7551c14-eb72-4ab6-b78e-82141b5fefbf@github.com>

On Wed, 13 Aug 2025 21:56:39 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361067: Added review comment
>
> test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 186:
> 
>> 184:         if (frame != null) {
>> 185:             frame.dispose();
>> 186:             frame = null;
> 
> Usually `frame.dispose()` is enough but having `frame = null` is fine too I suppose.

@DamonGuy thanks for suggestion , i usually used both as 
frame.dispose() to release native resources and make the window disappear.
frame = null; to help the GC reclaim the object

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2286976783

From psadhukhan at openjdk.org  Wed Aug 20 05:00:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Aug 2025 05:00:42 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
 <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>
 <7m9fDENxqmPnasJA7urxLaf3t2BrJOCHCstw6aWq2xo=.40aa98dd-db7f-4594-ac1c-be55e32b8998@github.com>
 <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
Message-ID: <VzzWNSABtmm0KXg9O1OMmvZaJwGYeJ2NAAJ7bUFOLB0=.aacad0ca-0a2f-44a6-9032-f4aa073fc1c5@github.com>

On Fri, 15 Aug 2025 22:09:15 GMT, Phil Race <prr at openjdk.org> wrote:

>>> > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
>>> 
>>> Yes I do. I overlooked them.
>> 
>> If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.
>
>> > > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
>> > 
>> > 
>> > Yes I do. I overlooked them.
>> 
>> If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.
> 
> oh. ok. I guess I will look at your test case and confirm that  .. and looks like it is a fully done regression test.
> Maybe you want to push that yourself ?

> @prrace Your latest commit [1b67651](https://github.com/openjdk/jdk/commit/1b676514010e55d0903ba445e5dd806e9f1b862d) doesn't address the problem fully, you should also remove `WindowsMenuItemUI.installDefaults`.

Shouldn't we keep it in WIndowMenuItemUI 
as in BasicLookAndFeel the fields are initialized as

"MenuItem.disabledForeground", null,
            "MenuItem.acceleratorForeground", menuText,
            "MenuItem.acceleratorSelectionForeground", textHighlightText,

whereas in WIndowsLookAndFeel it is

"MenuItem.disabledForeground", InactiveTextColor,
            "MenuItem.acceleratorForeground", MenuTextColor,
            "MenuItem.acceleratorSelectionForeground", SelectionTextColor,

so I think it would be better to initialize the defaults in the L&F it is currently on

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3204193921

From abaya at openjdk.org  Wed Aug 20 05:05:21 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 20 Aug 2025 05:05:21 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux [v4]
In-Reply-To: <4nizPJ8pnbsc_f0IlYI_yuhXaeaPVsShr1O3if9Uk0s=.40bd2d10-280b-4e2e-8d45-3788f72100c5@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
 <vcgKUlxIwewW3mEAPG_dMu4YNMOkWqWKgekQDBGHuNE=.475ff567-096e-4f4d-bd02-1eaa762b192f@github.com>
 <4nizPJ8pnbsc_f0IlYI_yuhXaeaPVsShr1O3if9Uk0s=.40bd2d10-280b-4e2e-8d45-3788f72100c5@github.com>
Message-ID: <EnWAWY0YCkMlLoacXsXMmlNLsjEQnmxm2RwXiyCZ-EE=.acaad4c1-0217-4894-9323-57fef053578b@github.com>

On Wed, 20 Aug 2025 03:33:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Respect rules
>>  - remove space
>>  - Update focusability only when it is needed
>
> src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java line 1101:
> 
>> 1099:             }
>> 1100:         }
>> 1101:         if(isVisible() != vis) {
> 
> you may add a space "if (isVisible() != vis) {"

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26298#discussion_r2286987635

From abaya at openjdk.org  Wed Aug 20 05:05:20 2025
From: abaya at openjdk.org (Anass Baya)
Date: Wed, 20 Aug 2025 05:05:20 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux [v5]
In-Reply-To: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
Message-ID: <oDPnaSwF6v4E4QQe2SXaGqtQRZYWdys25Fy9OT8Fq4w=.f38e0cc9-203c-4209-b88f-ca196eb2ec18@github.com>

> **Analysis:**
> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> **Proposed Fix:**
> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  add space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26298/files
  - new: https://git.openjdk.org/jdk/pull/26298/files/489f0734..3e893a08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26298&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26298&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26298/head:pull/26298

PR: https://git.openjdk.org/jdk/pull/26298

From prr at openjdk.org  Wed Aug 20 05:29:38 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 05:29:38 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
Message-ID: <H6SodhHzqEyg_MvilXBfWsBkaDZmS_vU4nlanu65Qok=.64239aae-2a2d-4667-90cc-5bb422093264@github.com>

On Fri, 15 Aug 2025 13:04:35 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function OGLBlitToSurfaceViaTexture() located in the file src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

There seem to be un-related changes in this PR. Please check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26799#issuecomment-3204241480

From prr at openjdk.org  Wed Aug 20 05:44:49 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 05:44:49 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
Message-ID: <L0-f5av7NjC5pHzVcWUO28RqPuwoOdJyKqVthJ9Oga0=.0dc00740-6753-4e73-8fb2-93a750bea828@github.com>

On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann <duke at openjdk.org> wrote:

>> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
>> 
>> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.
>
> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
>  - Merge branch 'master' into pr/11266
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS

This needs a test that people can run that shows "bad before fix, good afterwards".
Either an existing jtreg test tagged in the PR with this bug id, or a new test if none covers it.
And a comment about what tests have been run to show nothing is *broken* by this change would be good too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3204268589

From dgredler at openjdk.org  Wed Aug 20 07:28:44 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Wed, 20 Aug 2025 07:28:44 GMT
Subject: Integrated: 8359955: Regressions ~7% in several J2DBench in 25-b26
In-Reply-To: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
References: <Ekd1XxMI9LstDt89rGwRGQkYdCG9vHDb_vXzlKm_6eo=.2257906a-a4dc-4ca6-b857-657064a81456@github.com>
Message-ID: <v8wR16U-IZrGpnzVVI6HVOmEv7OQaUxmefSiYkY_TTU=.38fa4e1e-877d-4860-9355-92b8aa059a66@github.com>

On Fri, 8 Aug 2025 16:37:36 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

> Addresses recent slight performance regressions in some J2DBench benchmarks focused on text drawing.
> 
> `CCharToGlyphMapper` and `CompositeGlyphMapper` cache glyph IDs, but after JDK-8353230 they weren't caching glyph IDs for chars which might be affected by the raw / non-raw glyph distinction, since the cached value may not be correct if we ask for a raw glyph ID one time, but a non-raw glyph ID the next time (or vice versa). This caching exception was the reason for the slightly degraded performance (the `CCharToGlyphMapper` behavior was affecting macOS, and the `CompositeGlyphMapper` behavior was affecting some versions of Windows). This change splits the cache in each of these two classes into two caches, one for raw glyph IDs and one for non-raw glyph IDs, so that all glyphs can benefit from caching.
> 
> All of the font tests (`make test TEST="jtreg:test/jdk/java/awt/font"`) pass for me locally with this change on Linux, macOS and Windows.

This pull request has now been integrated.

Changeset: c220a6c7
Author:    Daniel Gredler <dgredler at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c220a6c7bb5fe2e27514235f2efa9183a33f12a5
Stats:     70 lines in 2 files changed: 25 ins; 19 del; 26 mod

8359955: Regressions ~7% in several J2DBench in 25-b26

Reviewed-by: prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/26702

From psadhukhan at openjdk.org  Wed Aug 20 07:54:37 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Aug 2025 07:54:37 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v3]
In-Reply-To: <ydZnFFfD94K28nNBleMkYzO1OTaIrdhEExTIRUKFbX4=.c6e88a4f-8385-4e3b-b665-21700ed18a1c@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <wcy_5XD5X9WvDbtk2oFBdchqkdRY3f8ua1L89Yz-enw=.0de33457-0343-4942-a273-350effa88bd2@github.com>
 <lwS2mLWmtuzPlLiME9GR_LoUWdObqOUYmndwhpcieU4=.97c8c891-1098-4967-9ed9-3d7b103a91e1@github.com>
 <ydZnFFfD94K28nNBleMkYzO1OTaIrdhEExTIRUKFbX4=.c6e88a4f-8385-4e3b-b665-21700ed18a1c@github.com>
Message-ID: <oeOdMujmdVTFYfBEkQgUmWEWGOnRYF-OMgNX-hUlLM8=.709ab59a-c7ea-45ed-881a-a8eb32f9806b@github.com>

On Wed, 6 Aug 2025 05:48:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> it is "that" row being pointed to by visibleRect
>> and yes CSR is needed but I want to finalise the wordings first.
>
> @prrace Can we just say "it will return >=0" or "it will return a non-negative number" instead of explaining when, as it might be delving into implementation details?

CSR https://bugs.openjdk.org/browse/JDK-8365843

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26500#discussion_r2287308695

From psadhukhan at openjdk.org  Wed Aug 20 09:00:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Aug 2025 09:00:47 GMT
Subject: RFR: 8361387 : Test bug4655513.java fails intermittently on
 Windows platform.
In-Reply-To: <hfv0hEengRD06RtkUnozVymRc8fPq-bINbh1sq6eUWI=.2c50007d-9239-40ab-85cf-2899fb921268@github.com>
References: <hfv0hEengRD06RtkUnozVymRc8fPq-bINbh1sq6eUWI=.2c50007d-9239-40ab-85cf-2899fb921268@github.com>
Message-ID: <YYYJa7dRh7PM89e39yM-zTG1LKQ6jPWBMkdGCds5-s0=.0c0a1caa-31f5-4d61-b570-b18e1d7f11da@github.com>

On Mon, 18 Aug 2025 16:03:23 GMT, Anass Baya <abaya at openjdk.org> wrote:

> This test was recently automated and is failing intermittently in the CI due to timing issues.
> This enhancement aims to stabilize the test and also adds the missing null pointer check.

test/jdk/javax/swing/DataTransfer/bug4655513.java line 73:

> 71:                 robot.delay(20);
> 72:             }
> 73:             robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);

mousePress parameter should be `InputEvent.BUTTON1_DOWN_MASK` instead which is usually the norm? mouseRelease is called correctly..
Also, I dont think we usually use delay between drag...guess once drag is complete, we can call waitForIdle and delay..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26824#discussion_r2287476781

From rkannathpari at openjdk.org  Wed Aug 20 09:36:39 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 20 Aug 2025 09:36:39 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for JTable.setShowGrid
Message-ID: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>

Hi Reviewers,

Updated the Bean Property description with meaningful string for JTable.setShowGrid.

Pleas review and let me know your suggestions if any.

-------------

Commit messages:
 - 8302057: Wrong BeanProperty description for JTable.setShowGrid

Changes: https://git.openjdk.org/jdk/pull/26857/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26857&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302057
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26857.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26857/head:pull/26857

PR: https://git.openjdk.org/jdk/pull/26857

From psadhukhan at openjdk.org  Wed Aug 20 11:18:43 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Aug 2025 11:18:43 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid
In-Reply-To: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
Message-ID: <cJaaPHRg1XpRENssj_NfPCsDsEv1m9jbt6kBjvM-IH4=.a95c6297-b0ac-4020-9c65-4d4491fcbacd@github.com>

On Wed, 20 Aug 2025 09:30:31 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Updated the Bean Property description with meaningful string for JTable.setShowGrid.
> 
> Pleas review and let me know your suggestions if any.

src/java.desktop/share/classes/javax/swing/JTable.java line 1167:

> 1165:      */
> 1166:     @BeanProperty(description
> 1167:             = "Whether grid lines should be drawn in between the cells.")

It probably need a CSR update as this line is part of spec now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26857#discussion_r2287838170

From asemenov at openjdk.org  Wed Aug 20 11:41:35 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 20 Aug 2025 11:41:35 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <DWDzmPz9NuO_zs57aeufdU2mfPg2XMAi_sgxja4GBFM=.0a08a649-3cda-41f3-9c3d-a043b1c8da58@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <DWDzmPz9NuO_zs57aeufdU2mfPg2XMAi_sgxja4GBFM=.0a08a649-3cda-41f3-9c3d-a043b1c8da58@github.com>
Message-ID: <gGhn-_NgsZ0lsT_cMS_ZDZqSJ6Gq7WN2srrv7BLN4ho=.024170e6-1950-4629-9aec-c40c1d18964e@github.com>

On Fri, 15 Aug 2025 17:05:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> It is better first to confirm whether this pointer can actually be NULL. If it cannot then remove the unnecessary earlier NULL check.

In the same file, line 551 calls OGLBlitToSurfaceViaTexture() from line 263, where NULL is passed in place of pf.
All other calls are fine.

Also, another function with a similar issue from the same file, OGLBlitSwToTexture() from line 396, is called with an existing pf.
It is not possible to remove the first check as you suggest?
Since that line calculates the value:

jboolean adjustAlpha = (pf != NULL && !pf->hasAlpha);

I suggest keeping the NULL check for OGLBlitToSurfaceViaTexture() at line 263, while for OGLBlitSwToTexture() at line 396, the check can be replaced with an assert.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26799#issuecomment-3205854738

From asemenov at openjdk.org  Wed Aug 20 12:08:46 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 20 Aug 2025 12:08:46 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <H6SodhHzqEyg_MvilXBfWsBkaDZmS_vU4nlanu65Qok=.64239aae-2a2d-4667-90cc-5bb422093264@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <H6SodhHzqEyg_MvilXBfWsBkaDZmS_vU4nlanu65Qok=.64239aae-2a2d-4667-90cc-5bb422093264@github.com>
Message-ID: <XIhk126azaZ0CsHwMGRTN4ZfaSbIjh-qZ0FRbDU89FI=.17885d36-7c2d-4967-8c83-d3725a327013@github.com>

On Wed, 20 Aug 2025 05:27:03 GMT, Phil Race <prr at openjdk.org> wrote:

> There seem to be un-related changes in this PR. Please check.

In [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) PR, they asked not to create multiple tickets for the same issues? even if they are in different files?

However, it?s not difficult for me to distribute the fixes across several tickets into different subcomponents if you think it?s necessary to do so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26799#issuecomment-3206038595

From psadhukhan at openjdk.org  Wed Aug 20 12:34:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Aug 2025 12:34:42 GMT
Subject: RFR: 8364768: JDK javax.imageio ImageWriters do not all flush the
 output stream
In-Reply-To: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
References: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
Message-ID: <a_ey9dXmF2AwIWjo3-9-lkAi0q2Ja1olRDEgLTmrNgg=.fea5c782-9d0d-423a-a35e-9bcc6fc76343@github.com>

On Fri, 8 Aug 2025 17:31:03 GMT, Phil Race <prr at openjdk.org> wrote:

> 4 of the 6 JDK ImageWriters flush the stream at the end of writing. 2 (TIFF and GIF) do not. 
> 
> This will matter if you are using a caching ImageOutputStream.
> 
> This fix makes it consistent.

src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java line 737:

> 735:             writeTrailer();
> 736:         }
> 737:         stream.flush();

should we call flush or `flushBefore`(current stream position) as is being done in BMP writer?

test/jdk/javax/imageio/FlushTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.

2025?

test/jdk/javax/imageio/FlushTest.java line 76:

> 74:                failed = true;
> 75:             }
> 76:         } finally {

no need for finally block or do we need to do `baos.close` here since FileCacheImageOutputStream.close says "The destination OutputStream is not closed."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26703#discussion_r2288019130
PR Review Comment: https://git.openjdk.org/jdk/pull/26703#discussion_r2287987561
PR Review Comment: https://git.openjdk.org/jdk/pull/26703#discussion_r2287988788

From dholmes at openjdk.org  Wed Aug 20 12:55:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 12:55:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
Message-ID: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>

On Tue, 19 Aug 2025 06:38:01 GMT, SendaoYan <syan at openjdk.org> wrote:

>> No change should be made to any explicit setting of the timeoutFactor in general as that could cause mass timeouts to occur (old default timeout = 120 * 10 = 1200 but new default = 120 * 2.5 = 300!). 
>> 
>> However I see the concern of @sendaoYan because individual tests may now get much larger timeout values when run with the non-default timeoutFactor because they have been adjusted for the new default. I don't see any solution to this dilemma.
>
> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
> 
> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1

@sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288072431

From psadhukhan at openjdk.org  Wed Aug 20 13:18:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 20 Aug 2025 13:18:46 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v25]
In-Reply-To: <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
Message-ID: <SZDyrTWJpcF15gwGEOdmFBa1Dp4-g6kDiKaJVy8StrQ=.a9b2d743-1106-4219-91bb-6357ca7d9ee2@github.com>

On Tue, 19 Aug 2025 14:54:16 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 39 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Centers missed frames in the middle of screen
>  - Uses KeyboardFocusManager instead of FocusManager
>  - Reverted not needed changes
>  - Updates copyright years
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Centers frames in the middle of the screen
>  - Releses latch in case of null ancestor or resizing component
>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/5b6059ea...9358a9d8

test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 83:

> 81:         frame.add(cb);
> 82:         propagateAWTControls(frame);
> 83:         frame.setLocationRelativeTo(null);

setLocationRelativeTo called twice

test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 109:

> 107:         propagateAWTControls(frame);
> 108:         frame.setLocationRelativeTo(null);
> 109:         frame.setVisible(true);

same here and setVisible() also called twice

test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 86:

> 84:         }
> 85:         propagateAWTControls(frame);
> 86:         frame.setLocationRelativeTo(null);

same here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2288132826
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2288136750
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2288137872

From syan at openjdk.org  Wed Aug 20 14:28:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 20 Aug 2025 14:28:43 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
Message-ID: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>

On Wed, 20 Aug 2025 12:53:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But what this PR do is change the timeoutFactor in general and find out all the tests which may timeout after the timeoutFactor has been changed.
>> 
>> The old default timeout before this PR is 120 * 4, after this PR the new default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.

Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.

So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).

I do agree this change, what I mean is this change has some side effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288361080

From ihse at openjdk.org  Wed Aug 20 15:19:42 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:19:42 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

I don't think there is any point linking to the build source code. 

Suggestion:

certain amount of time will apply this factor. If you run in
forced compilation mode (`-Xcomp`) using `make test`, it
will automatically adjust this factor to compensate for the
interpreter not being as fast as JITed code. Defaults to 1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288510800

From ihse at openjdk.org  Wed Aug 20 15:24:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 15:24:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
Message-ID: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>

On Mon, 18 Aug 2025 16:34:21 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   after suggestion from Daniel

It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.

I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 

Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3206865824

From lkorinth at openjdk.org  Wed Aug 20 16:27:39 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 16:27:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
Message-ID: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>

On Wed, 20 Aug 2025 15:17:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> I don't think there is any point linking to the build source code. 
> 
> Suggestion:
> 
> certain amount of time will apply this factor. If you run in
> forced compilation mode (`-Xcomp`) using `make test`, it
> will automatically adjust this factor to compensate for the
> interpreter not being as fast as JITed code. Defaults to 1.

I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288683592

From dnguyen at openjdk.org  Wed Aug 20 16:50:44 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 20 Aug 2025 16:50:44 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v9]
In-Reply-To: <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <8LW9YNmpiuw43H35z7RtYPj8Blb9KN8CYuBzg72CcnQ=.cc4b66cb-6797-4f89-9b19-534274909fe6@github.com>
Message-ID: <5asQvoINDgg7EmfhtOnI1cCXVpp354UasqVHzUW7wyU=.59a879a0-1c5a-40f0-b683-6c891bc9205d@github.com>

On Wed, 6 Aug 2025 09:43:48 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: Added review comment

Re-tested and works fine as explained. Issue was on my end and was resolved.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26043#pullrequestreview-3137482817

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
Message-ID: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>

> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
> 
> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have ploughed through test cases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> After the review, I will update the copyrights.
> 
> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
> 
> I got 4 timing related faults:
> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
> 2) sun/tools/jhsdb/BasicLauncherTest.java
>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
> 
> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
> 
> From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of...

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  update testing.md, remove makefile link, fix bad text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26749/files
  - new: https://git.openjdk.org/jdk/pull/26749/files/286a2cc6..f24a1e72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=03-04

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749

PR: https://git.openjdk.org/jdk/pull/26749

From lkorinth at openjdk.org  Wed Aug 20 17:05:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 20 Aug 2025 17:05:59 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <zMf--cv1kXQeP-czYxASKgyLFWnMK6kg2Cbqn-XmMOY=.de811934-11d3-4e6b-8323-07cbaa8f0a85@github.com>
 <qR4-T3VHJ00Y_mSlkqNAuTok3bcs5WhKzDiW755CHJI=.60e83871-274b-460f-bbbc-3dd6555a2b47@github.com>
Message-ID: <2Ba-EiFMVh1-nMHcihw93nZq-TkQNtvHc244Bwe8I40=.cfa54a17-0a3f-465d-a1c3-7560965376d7@github.com>

On Wed, 20 Aug 2025 16:24:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: forced compilation mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> I don't think there is any point linking to the build source code. 
>> 
>> Suggestion:
>> 
>> certain amount of time will apply this factor. If you run in
>> forced compilation mode (`-Xcomp`) using `make test`, it
>> will automatically adjust this factor to compensate for the
>> interpreter not being as fast as JITed code. Defaults to 1.
>
> I will remove the link, and I will update my bad text still talking about the interpreter (sorry for that mistake).

fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2288793081

From duke at openjdk.org  Wed Aug 20 17:47:51 2025
From: duke at openjdk.org (duke)
Date: Wed, 20 Aug 2025 17:47:51 GMT
Subject: Withdrawn: 8352407: PixelInterleavedSampleModel with unused components
 throws RasterFormatException: Incorrect pixel stride
In-Reply-To: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
References: <XG3ViAQRcqvh0bpwzKJ60-L_MNPcSLmY-0xdej3kZJ0=.94f48732-976b-4b08-938f-ed1c7a552b6c@github.com>
Message-ID: <Wlr0bAdNt0AzVRNMhGxsZEeD1L4YxyQ5MQqFDD9iuLk=.4595b950-0c39-4ef6-93c8-f1d855ed7193@github.com>

On Wed, 19 Mar 2025 11:23:13 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

> 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24111

From ihse at openjdk.org  Wed Aug 20 19:36:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Aug 2025 19:36:44 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <Pw1uYaqAPK95BsoZ0xgNA1c3rsXjxHCiz-xACzocwqA=.e6cb7fcf-4438-4e4a-aeef-7d9c707c87c8@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

Build changes look good now. Thanks!

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3137980952

From prr at openjdk.org  Wed Aug 20 20:11:36 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 20:11:36 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid
In-Reply-To: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
Message-ID: <X8FyoiZtWjfjRmFISXLNUjNwBqHte4zKBrjNZJhfQaY=.c0fa209f-3efb-4d86-bedd-45be14793780@github.com>

On Wed, 20 Aug 2025 09:30:31 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Updated the Bean Property description with meaningful string for JTable.setShowGrid.
> 
> Pleas review and let me know your suggestions if any.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26857#pullrequestreview-3138087202

From prr at openjdk.org  Wed Aug 20 20:11:38 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 20:11:38 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid
In-Reply-To: <cJaaPHRg1XpRENssj_NfPCsDsEv1m9jbt6kBjvM-IH4=.a95c6297-b0ac-4020-9c65-4d4491fcbacd@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
 <cJaaPHRg1XpRENssj_NfPCsDsEv1m9jbt6kBjvM-IH4=.a95c6297-b0ac-4020-9c65-4d4491fcbacd@github.com>
Message-ID: <3AQWlfyLtvCTtF0UqPFnofXzC6Ijks2SAOndLqjrfmM=.3a6ef77b-ea77-4388-9146-de83636f53f6@github.com>

On Wed, 20 Aug 2025 11:16:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated the Bean Property description with meaningful string for JTable.setShowGrid.
>> 
>> Pleas review and let me know your suggestions if any.
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 1167:
> 
>> 1165:      */
>> 1166:     @BeanProperty(description
>> 1167:             = "Whether grid lines should be drawn in between the cells.")
> 
> It probably need a CSR update as this line is part of spec now

I think we can skip a CSR for this. It is an obvious copy/paste typo and it is a bean property description, nit the javadoc spec which is correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26857#discussion_r2289189091

From prr at openjdk.org  Wed Aug 20 20:12:36 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 20:12:36 GMT
Subject: RFR: 8365711: Declare menuBarHeight and hotTrackingOn private
In-Reply-To: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
References: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
Message-ID: <ZsARLjCr4vr0JVR9nPGeFhQERIvI-mrawXeNUbBqLPk=.446542a4-8f19-43fb-8cb9-6e177eec73c1@github.com>

On Mon, 18 Aug 2025 17:05:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Since `WindowsMenuUI` is a final class after PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be extended, therefore the `protected` modifier doesn't make sense.
> 
> Mark both `menuBarHeight` and `hotTrackingOn` as `private` fields.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26829#pullrequestreview-3138090391

From prr at openjdk.org  Wed Aug 20 20:25:37 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 20:25:37 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v2]
In-Reply-To: <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <miu9zvugVgLz448Au_PBo33QZabVPjdMAOG2fWAgJec=.9dd45fb0-acb5-4113-81df-380e1468b56d@github.com>
 <htYqm1ku3WhXQ9m1pxbyF5TNRggihLKgxJ29IkXlRgg=.f8dfcbd1-cf68-429f-a748-a658a7484f85@github.com>
 <HdVcr3siTT3ukOLA94bPVqt3d_VArlcfP4JZHSs_tLs=.a75789c6-177d-419c-8e6d-e6fb672fa5bf@github.com>
 <7m9fDENxqmPnasJA7urxLaf3t2BrJOCHCstw6aWq2xo=.40aa98dd-db7f-4594-ac1c-be55e32b8998@github.com>
 <XCwFdqrA1H_2AZcNrADHfaZZp7W1510fGTKRaix_Wfc=.9e765a22-7458-45c2-9ed2-5fb16549edc6@github.com>
Message-ID: <7hxaTzZiP6ndhUdro_PhH3ugJxlpHwKINwU5liAu_YM=.6621f173-4a44-4427-9823-4254ae28bcd1@github.com>

On Fri, 15 Aug 2025 22:09:15 GMT, Phil Race <prr at openjdk.org> wrote:

>>> > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
>>> 
>>> Yes I do. I overlooked them.
>> 
>> If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.
>
>> > > There are still static fields to store colors in `WindowsMenuItemUI`, do you want to get rid of those too? My bug report implied removing them, yet currently the static fields with colors remain intact in `WindowsMenuItemUI`.
>> > 
>> > 
>> > Yes I do. I overlooked them.
>> 
>> If you do, this will resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625) that I submitted a few minutes ago.
> 
> oh. ok. I guess I will look at your test case and confirm that  .. and looks like it is a fully done regression test.
> Maybe you want to push that yourself ?

> @prrace Your latest commit [1b67651](https://github.com/openjdk/jdk/commit/1b676514010e55d0903ba445e5dd806e9f1b862d) doesn't address the problem fully, you should also remove `WindowsMenuItemUI.installDefaults`.

You are right. What's there just duplicates the super-class. Although I don't know what "problem" it causes.

> 
> I posted a comment where I said that I went ahead and submitted my own PR #26826 to resolve [JDK-8365625](https://bugs.openjdk.org/browse/JDK-8365625). My PR removes the static fields from `WindowsMenuItemUI` and adds the regression test attached to the JBS issue.

I thought that was supposed to be a follow-on ONCE this was done and I indicated last week I'd be removing these.

> 
> I propose you revert commit [1b67651](https://github.com/openjdk/jdk/commit/1b676514010e55d0903ba445e5dd806e9f1b862d) and integrate this PR in the state it was last week with the updated subject that doesn't mention `WindowsMenuItemUI`.

I think this should go as it is, and that follow-on can be updated.
You can address the duplicate installDefaults()

Also I just noticed this comment 
"I edited the subject of the JBS issue that this PR resolves, now it doesn't reference WindowsMenuItemUI"

I'd prefer you not have done that. In fact I was puzzled at the PR/JBS mismatch and restored the subject.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26783#issuecomment-3207981209

From prr at openjdk.org  Wed Aug 20 20:36:21 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 20:36:21 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
 [v2]
In-Reply-To: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
Message-ID: <0Zwu2GR2cXqlhGDab0Zew2LDhwwMzIRUv5sDLlydsmI=.fa50e1e4-0f9a-44f5-8955-208733dc2e3e@github.com>

> Remove javax.imageio.spi.ServiceRegistry.finalize() since it is deprecated for removal.
> The impact of this should be minimal. The IIORegistry will now be a singleton - which it already was 
> in practice since Applets are no longer supported. Since it is a singleton, it will persist for the life
> of the VM, so will never be garbage collected.
> A test that verifies one per-AppContext is now obsolete, and is deleted, and there's no good reason to make it a negative test, since in due course AppContext itself will be deleted and is un-used today except in tests.
> 
> Since JDK 9, ServiceRegistry has supported only Image I/O specified providers, and since the IIORegistry does this,
> in practice there is very little reason for an application to create instances or subclasses of it.
> And even if they do, typically like IIORegistry, they be used for the life time of the application.
> And if they are collected, without calling ServiceRegistry.deregisterAll() there may be no impact,
> since only providers that implement RegisterableService will be affected.
> 
> See the JBS issue for all the details.
> 
> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8365409

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8365292

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26752/files
  - new: https://git.openjdk.org/jdk/pull/26752/files/1ba9731d..308e472c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26752&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26752&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26752/head:pull/26752

PR: https://git.openjdk.org/jdk/pull/26752

From prr at openjdk.org  Wed Aug 20 20:36:21 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 20:36:21 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
 [v2]
In-Reply-To: <T0O3eFcOgl08lPO75GUV-qg_HpnfV5Jg6Yw1Fwi9_-o=.0ddcff17-0bef-4c00-ab76-add21cbe74af@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
 <xWy53TemnV-uH_GlxXhu5_21XzZN5iY6Bkp3eAg-PjI=.18ef29dc-d27f-450b-9677-8a51a2f1893e@github.com>
 <qnp7zW8pwZO7k54u1TIz-xLfBKSbONpX7YvRNH-jtLU=.5829a3f4-a470-4185-ba0a-7e53744bfd9e@github.com>
 <T0O3eFcOgl08lPO75GUV-qg_HpnfV5Jg6Yw1Fwi9_-o=.0ddcff17-0bef-4c00-ab76-add21cbe74af@github.com>
Message-ID: <PHIAWd7RuhHnE6dHAUlZ-yBNjXM8ZnB85sgDPngIC0I=.5bd7e7df-d451-4630-bb20-46ed1524553e@github.com>

On Fri, 15 Aug 2025 20:06:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I thought about that whilst making the change, but
>> (1) The javax.imagio.ImageIO class has this code
>> 
>>     private static final IIORegistry theRegistry =  IIORegistry.getDefaultInstance();
>> 
>> So it is going to get initialized really early on in virtually all uses of ImageIO, so doing as I did seems fine.
>> 
>> (2) The code in getDefaultInstance() is now going to run 1,000 times faster than it did before so stable value to get it running 2,000 times faster  probably is not necessary. And in any case, the version cached on ImageIO is what is going to be used. Hmm, it probably should not have been doing that as it defeated the AppContext, but it doesn't matter now.
>
> I am not worried much about performance, but I am concerned about the possibility of a deadlock in static initializers, since the services loaded by the IIORegistry can trigger any code.
> 
> btw why not "private static final IIORegistry registry = new IIORegistry();"?

Yes, I might as well now do that initialization.

I don't see how there's any deadlock risk here, and certainly no more than before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26752#discussion_r2289234426

From serb at openjdk.org  Wed Aug 20 20:57:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 20 Aug 2025 20:57:37 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid
In-Reply-To: <3AQWlfyLtvCTtF0UqPFnofXzC6Ijks2SAOndLqjrfmM=.3a6ef77b-ea77-4388-9146-de83636f53f6@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
 <cJaaPHRg1XpRENssj_NfPCsDsEv1m9jbt6kBjvM-IH4=.a95c6297-b0ac-4020-9c65-4d4491fcbacd@github.com>
 <3AQWlfyLtvCTtF0UqPFnofXzC6Ijks2SAOndLqjrfmM=.3a6ef77b-ea77-4388-9146-de83636f53f6@github.com>
Message-ID: <uehWtxl5Oln4EkoYvDiuXFK9tV9NDw21LlPcvGasUTM=.e25cb210-a907-4173-afbb-95f45535e6fb@github.com>

On Wed, 20 Aug 2025 20:09:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 1167:
>> 
>>> 1165:      */
>>> 1166:     @BeanProperty(description
>>> 1167:             = "Whether grid lines should be drawn in between the cells.")
>> 
>> It probably need a CSR update as this line is part of spec now
>
> I think we can skip a CSR for this. It is an obvious copy/paste typo and it is a bean property description, nit the javadoc spec which is correct.

note that unlike the specs for setShowHorizontalLines/setShowVerticalLines below the spec for this method uses the "grid lines *around* cells" instead of "lines *between* cells"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26857#discussion_r2289275986

From prr at openjdk.org  Wed Aug 20 21:00:36 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 21:00:36 GMT
Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java
In-Reply-To: <pgsCJk8xYCFXbo5jNB3X-951-_UsikXtPKfXV9ATZ0c=.2aaaeecf-9938-459a-824f-457c7262c20c@github.com>
References: <gvG7FJiUONPg1uSza7EFPjns0JUFosfE6gHlTDHpzGI=.63540380-fd25-4beb-b062-8da20cd7dceb@github.com>
 <pgsCJk8xYCFXbo5jNB3X-951-_UsikXtPKfXV9ATZ0c=.2aaaeecf-9938-459a-824f-457c7262c20c@github.com>
Message-ID: <IMWmtjV3IjdRYlztuxqZfgzMXg3-b9pnayaq8s9cRto=.99bd80ee-5c7c-4d01-9473-97457b61af08@github.com>

On Fri, 15 Aug 2025 01:32:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> How about modifying the listeners list implementations to store listeners using weak references instead(not sure it will be better that the current patch)? it seems current implementation can cause memory leaks?

Memory leaks ?  Where and how ? By current implementation, you mean before and after the PR ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26784#issuecomment-3208069183

From prr at openjdk.org  Wed Aug 20 21:32:39 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 20 Aug 2025 21:32:39 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: <vg1Jr4yhW-g0Ec4mNau3-Fg3j1tv-WlC-VOIMnm19Gg=.77ae0cc9-0831-4df5-8d9e-24db3d61c736@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.

src/java.desktop/share/classes/java/awt/geom/Arc2D.java line 1067:

> 1065:      *
> 1066:      * @return the {@code Rectangle2D} that represents the arc's
> 1067:      * framing rectangle.

I am confused. Isn't this deleted doc, in fact the doc that you want on both methods now.
Although 'high precision'  if it means float, not int return coords, might not be part of the other method spec.
Also there is a JCK test that fails with this change. Looks like it expects the looser bounds for getBounds().
So we'd definitely need a CSR.
And there'd be a practical compatibility issue as well for someone who relied on those looser bounds.
That's what worries me most.

Also (minor) from JBS I see this comment -
"It looks like the math in getBounds2D could be greatly simplified - at which
point it would make sense to have getBounds also return a tighter bounding
box."

which suggests to me that performance was part of the original reason for the looser bounds of getBounds()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26715#discussion_r2289345340

From dholmes at openjdk.org  Wed Aug 20 21:32:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Aug 2025 21:32:39 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <j5ndr4sR6OHgBGlCY-e1I-VdfMKpG2GS98Wv2qbshtU=.d5aad200-1bc2-4080-ad71-218c59a7e491@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, 

@magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

For this exercise existing explicit timeout values need to be multiplied by 4 to keep the same absolute timeout value. In addition a number of tests that use the implicit default timeout (120*4) now need an explicit timeout (480 generally).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3208143195

From dnguyen at openjdk.org  Wed Aug 20 22:25:17 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 20 Aug 2025 22:25:17 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
Message-ID: <XpKDvR-TEDPSs6vrKA58E3QIq2Ybzosu4qaXlF21Veg=.e9b9655e-2c41-406c-a294-82072c9e6894@github.com>

On Tue, 19 Aug 2025 06:14:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent

The suggestion to use a BufferedImage sounds fair.

The fix here does make the test pass consistently when testing on a macOS 26 device myself. I ran it multiple times with no failures, where the original test (without the changes) did fail consistently. LGTM.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26833#pullrequestreview-3138440025

From jwood at openjdk.org  Thu Aug 21 00:51:51 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Thu, 21 Aug 2025 00:51:51 GMT
Subject: RFR: 4197755: Arc2D.getBounds() returns an unnecessarily large
 bounding box
In-Reply-To: <vg1Jr4yhW-g0Ec4mNau3-Fg3j1tv-WlC-VOIMnm19Gg=.77ae0cc9-0831-4df5-8d9e-24db3d61c736@github.com>
References: <NQaEs5gLhUjJ2jvelIaMSzcD_7s5ERquy6k4AUQ0uwE=.5412e835-b443-4ec5-bde5-fe7b16e9ee1f@github.com>
 <vg1Jr4yhW-g0Ec4mNau3-Fg3j1tv-WlC-VOIMnm19Gg=.77ae0cc9-0831-4df5-8d9e-24db3d61c736@github.com>
Message-ID: <jx44Ni53MjWYxAZk9WqHsch4diXuQurO9v--clskZK8=.04745587-b9e8-441e-a8e0-70d9579e805e@github.com>

On Wed, 20 Aug 2025 21:30:13 GMT, Phil Race <prr 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.
>
> src/java.desktop/share/classes/java/awt/geom/Arc2D.java line 1067:
> 
>> 1065:      *
>> 1066:      * @return the {@code Rectangle2D} that represents the arc's
>> 1067:      * framing rectangle.
> 
> I am confused. Isn't this deleted doc, in fact the doc that you want on both methods now.
> Although 'high precision'  if it means float, not int return coords, might not be part of the other method spec.
> Also there is a JCK test that fails with this change. Looks like it expects the looser bounds for getBounds().
> So we'd definitely need a CSR.
> And there'd be a practical compatibility issue as well for someone who relied on those looser bounds.
> That's what worries me most.
> 
> Also (minor) from JBS I see this comment -
> "It looks like the math in getBounds2D could be greatly simplified - at which
> point it would make sense to have getBounds also return a tighter bounding
> box."
> 
> which suggests to me that performance was part of the original reason for the looser bounds of getBounds()

(Everything that follows is very subjective; feel free to disagree.)

> Isn't this deleted doc, in fact the doc that you want on both methods now..

The previous javadoc existed because it was explaining a very unusual distinction between Arc2D.getBounds() and Arc2D.getBounds2D() that does not exist in any other Shape. That distinction/difference is the crux of JDK-4197755. It was worth explaining precisely because it was unintuitive/weird.

IMO we don't need any additional javadoc around these methods now (with this PR), because now they are behaving like most developers assume they would. Most other Shape implementations already follow the same pattern, and they don't offer any accompanying method documentation. If I was redesigning the `Shape` interface today from scratch, I would probably go so far as to include:

    default public Rectangle getBounds() {
        return getBounds2D().getBounds();
    }

    default public Rectangle2D getBounds2D() {
        return Path2D.getBounds2D(getPathIterator(null));
    }


I'd argue this is the "normal" behavior that most developers expect. We should only override those methods if a specific alternative is faster and approximately as accurate.

(This case study is also weird because Arc2D extends RectangularShape. The shape of a slice of pie does not have a "is-a" relationship with the shape of its pie tin. And yet without this PR: Arc2D inherits getBounds() from RectangularShape.)

> And there'd be a practical compatibility issue as well for someone who relied on those looser bounds.

I agree; that's always a risk. We took the same risk when we resolved JDK-8176501 ; is there room to argue this PR is riskier than JDK-8176501 's resolution?

If this PR is too controversial: I'm fine with closing it. I see you reopened JDK-4197755, which is the thing I feel most strongly about here.

I just thought if I was going to call out reopening 4197755: it'd be trivial to also submit this PR for consideration.

> which suggests to me that performance was part of the original reason for the looser bounds of getBounds()

Hmm. Maybe. I'd just add: RectangularShape provides a getBounds() implementation, but it does NOT provide a getBounds2D() implementation. So I'd suggest getBounds() is looser simply because of legacy design decisions. I do think it's peculiar the Arc2D authors anticipated this complaint and didn't act on it, but I'll probably never know exactly how those decisions were made.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26715#discussion_r2289604504

From dnguyen at openjdk.org  Thu Aug 21 01:29:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 21 Aug 2025 01:29:54 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests
Message-ID: <LJR5GwDbYFRueT-FHkuo2-vk0Mu_rUHzA9XGk7skmt8=.b6248e26-d4c5-4f91-b772-fc234a7c22ba@github.com>

Ubuntu machine has multiple failing java awt tests. When looking at the screenshots of the desktop when each test fails, a white square can be seen at the top-left of the desktop.

<img width="803" height="344" alt="Screenshot 2025-08-20 at 10 06 37?AM" src="https://github.com/user-attachments/assets/52d023f6-18ff-46d4-98c4-e2e332ab6a03" />

This seems to be similar to the white square that `FrameVisualTest.java` creates so the frame was not disposed of properly during this failure. I have tried re-creating this failure on Ubuntu 22.04, similar to the failure OS that this originally occurred on, to no avail. I ran this test individually, and with all of the listed failing tests back-to-back but all the tests pass as normal. This stabilization fix to the test attempts to prevent this in case it occurs again.

-------------

Commit messages:
 - Initial commit
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b69a3849...7f4a298f

Changes: https://git.openjdk.org/jdk/pull/26871/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360160
  Stats: 17 lines in 1 file changed: 7 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26871/head:pull/26871

PR: https://git.openjdk.org/jdk/pull/26871

From psadhukhan at openjdk.org  Thu Aug 21 02:03:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 02:03:53 GMT
Subject: RFR: 8365389: Remove static color fields from SwingUtilities3 and
 WindowsMenuItemUI [v4]
In-Reply-To: <8UVej2SrE6rah1H5A3EPegbSS_S027me2YJn4iRbaKE=.d1c5e3f6-8fb2-4088-8049-043adb6021da@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
 <8UVej2SrE6rah1H5A3EPegbSS_S027me2YJn4iRbaKE=.d1c5e3f6-8fb2-4088-8049-043adb6021da@github.com>
Message-ID: <ev4Jc7KVgI4Yb6A2jz_D6qLQKosugypJH-qYcALV2cA=.a72f1270-6dc8-4392-aeb4-86320c8ddd60@github.com>

On Tue, 19 Aug 2025 20:12:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> This refactors some Swing code to pass args instead of using statics
>> The bug report suggests some further refactoring which could be considered later, but the most
>> important thing to do is to eliminate using statics to pass args.
>> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365389

Marked as reviewed by psadhukhan (Reviewer).

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26783#pullrequestreview-3138785804
PR Review: https://git.openjdk.org/jdk/pull/26783#pullrequestreview-3138787065

From psadhukhan at openjdk.org  Thu Aug 21 02:04:29 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 02:04:29 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
Message-ID: <4AN423-rNpMWI8ROYn_LopO3fi54VpLRhIYVl8RBN2M=.cbdea4c3-b193-4084-9f3d-985f588c4f3a@github.com>

On Tue, 19 Aug 2025 06:14:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent

I modified the test to render component in to bufferedimage

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26833#issuecomment-3208692715

From dnguyen at openjdk.org  Thu Aug 21 02:08:52 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 21 Aug 2025 02:08:52 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26 [v2]
In-Reply-To: <iPre1--JX-iTt3rm2PXSbbvppA7jUigQrnpa8jT2vqM=.bbf24156-7f80-43c8-ae8a-dd13ee7aa5a5@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
 <iPre1--JX-iTt3rm2PXSbbvppA7jUigQrnpa8jT2vqM=.bbf24156-7f80-43c8-ae8a-dd13ee7aa5a5@github.com>
Message-ID: <JLP0KUeD3u-o9fuqpcDpA7wWmaxGopShaI62zEeMjp4=.b6ba2355-78ce-47fe-8610-3cc7615fc88c@github.com>

On Thu, 21 Aug 2025 02:04:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
>> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Render component in bufferedimage

I tested the updated test with the rendered components on macOS 26. Same results as my last approval. Everything seems to be passing and LGTM when the test previously failed.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26833#pullrequestreview-3138799028

From psadhukhan at openjdk.org  Thu Aug 21 02:04:29 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 02:04:29 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26 [v2]
In-Reply-To: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
Message-ID: <iPre1--JX-iTt3rm2PXSbbvppA7jUigQrnpa8jT2vqM=.bbf24156-7f80-43c8-ae8a-dd13ee7aa5a5@github.com>

> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Render component in bufferedimage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26833/files
  - new: https://git.openjdk.org/jdk/pull/26833/files/2c29e497..0517747a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26833&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26833&range=00-01

  Stats: 17 lines in 1 file changed: 4 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26833.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26833/head:pull/26833

PR: https://git.openjdk.org/jdk/pull/26833

From psadhukhan at openjdk.org  Thu Aug 21 02:38:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 02:38:25 GMT
Subject: RFR: 8361610: Avoid wasted work in ImageIcon(Image) for setting
 description
Message-ID: <0xfQm-qD9oIoqjW1ChnYSN5hlfJN5muRK11XicF9olM=.950ef44f-bed6-43c2-9d5e-12a3fde5eee9@github.com>

The `ImageIcon(Image)` constructor sets the description field to the value of "comment" property if it's a string. The `ImageIcon(Image, String)` constructor calls ImageIcon(Image). Since the two-parameter constructor explicitly provides the value for the description field, the implicitly set value for description is immediately overwritten, which is wasted work. 

Fix is to let `ImageIcon(Image, String) `constructor do the actual work of setting the fields and loading the image

-------------

Commit messages:
 - 8361610: Avoid wasted work in ImageIcon(Image) for setting description

Changes: https://git.openjdk.org/jdk/pull/26873/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26873&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361610
  Stats: 15 lines in 1 file changed: 7 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26873.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26873/head:pull/26873

PR: https://git.openjdk.org/jdk/pull/26873

From psadhukhan at openjdk.org  Thu Aug 21 03:07:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 03:07:55 GMT
Subject: RFR: 8360160: ubuntu-22-04 machine is failing client tests
In-Reply-To: <LJR5GwDbYFRueT-FHkuo2-vk0Mu_rUHzA9XGk7skmt8=.b6248e26-d4c5-4f91-b772-fc234a7c22ba@github.com>
References: <LJR5GwDbYFRueT-FHkuo2-vk0Mu_rUHzA9XGk7skmt8=.b6248e26-d4c5-4f91-b772-fc234a7c22ba@github.com>
Message-ID: <MyJUiUMZWjq7FO9jDPtY9OY2rGaoZztKS49FjTXSH1g=.8d1d5aa1-fd9d-43f3-b890-281491c8bbd3@github.com>

On Thu, 21 Aug 2025 01:21:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Ubuntu machine has multiple failing java awt tests. When looking at the screenshots of the desktop when each test fails, a white square can be seen at the top-left of the desktop.
> 
> <img width="803" height="344" alt="Screenshot 2025-08-20 at 10 06 37?AM" src="https://github.com/user-attachments/assets/52d023f6-18ff-46d4-98c4-e2e332ab6a03" />
> 
> This seems to be similar to the white square that `FrameVisualTest.java` creates so the frame was not disposed of properly during this failure. I have tried re-creating this failure on Ubuntu 22.04, similar to the failure OS that this originally occurred on, to no avail. I ran this test individually, and with all of the listed failing tests back-to-back but all the tests pass as normal. This stabilization fix to the test attempts to prevent this in case it occurs again.

test/jdk/java/awt/Frame/FrameVisualTest.java line 60:

> 58:         robot = new Robot();
> 59:         robot.setAutoDelay(100);
> 60:         try {

I believe setAutoDelay was creating some nuisance in ubuntu22.04 system and we removed it to use explicit delay whenever needed. Maybe you can add a waitForIdle after createScreenCapture and/or a delay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26871#discussion_r2289741724

From kizune at openjdk.org  Thu Aug 21 04:46:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 21 Aug 2025 04:46:52 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <dDK1UhX6KoY_mKZfY8u0JXBGADWvqdVCv_JQOhG6k50=.231288f7-ee29-40c5-aa0b-8bcfa1477d83@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
 <dDK1UhX6KoY_mKZfY8u0JXBGADWvqdVCv_JQOhG6k50=.231288f7-ee29-40c5-aa0b-8bcfa1477d83@github.com>
Message-ID: <-U-DcYDioW8P0vJb1nX1tfKlHF4c-ndN0dh8ZkAr54Q=.2df89367-d6a5-40c8-b804-98bed02fd32b@github.com>

On Tue, 19 Aug 2025 17:25:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> the test might be updated to render components into the buffered image and then compare exact values.

And what does it test then? The original bug was about dragging the internal frame creates artifacts on the underlying component. By drawing the component after the drag into the BufferedImage - are we sure the artifacts will be drawn there too? I have my doubts about the logic of the test after the last change...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26833#issuecomment-3208978216

From kizune at openjdk.org  Thu Aug 21 04:50:50 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 21 Aug 2025 04:50:50 GMT
Subject: RFR: 8361610: Avoid wasted work in ImageIcon(Image) for setting
 description
In-Reply-To: <0xfQm-qD9oIoqjW1ChnYSN5hlfJN5muRK11XicF9olM=.950ef44f-bed6-43c2-9d5e-12a3fde5eee9@github.com>
References: <0xfQm-qD9oIoqjW1ChnYSN5hlfJN5muRK11XicF9olM=.950ef44f-bed6-43c2-9d5e-12a3fde5eee9@github.com>
Message-ID: <yIvd34svat-fTJtfh5qrfjqaoTYTA8BOUu0fNI-2cbM=.9b52fcf3-873f-4ac8-b88f-19522697df65@github.com>

On Thu, 21 Aug 2025 02:30:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> The `ImageIcon(Image)` constructor sets the description field to the value of "comment" property if it's a string. The `ImageIcon(Image, String)` constructor calls ImageIcon(Image). Since the two-parameter constructor explicitly provides the value for the description field, the implicitly set value for description is immediately overwritten, which is wasted work. 
> 
> Fix is to let `ImageIcon(Image, String) `constructor do the actual work of setting the fields and loading the image

LGTM

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26873#pullrequestreview-3139009152

From kizune at openjdk.org  Thu Aug 21 04:51:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 21 Aug 2025 04:51:52 GMT
Subject: RFR: 8365708: Add missing @Override annotations to
 WindowsMenuItemUIAccessor
In-Reply-To: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>
References: <v3A05oq-oFMPJNF4PorQkt5oUlavIg82ZzP_debC2Ys=.bb9f514c-990b-46b2-bbb9-38ad468f50bd@github.com>
Message-ID: <bI3Cm47GVzPUHPJZsHGm-TarNXKYe9CQqHHL16Q4bcA=.845cfbb1-fe37-486c-b51c-29dd3034975c@github.com>

On Mon, 18 Aug 2025 16:49:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Add the missing `@Override` annotations to anonymous classes implementing `WindowsMenuItemUIAccessor`.
> 
> PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638) added the `@Override` annotations to `getMenuItem` and `getPart` but left `getState` without the annotation.
> 
> For consistency, add the annotation to the `getState` method too.

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26828#pullrequestreview-3139010434

From jdv at openjdk.org  Thu Aug 21 04:58:12 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 21 Aug 2025 04:58:12 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw
 exception for negative image index [v2]
In-Reply-To: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
Message-ID: <EVI-lhlzW_6j3WBBqcnImUFtJG2N8-4RGvOCsvt5wO0=.842ee3a8-f3bd-4482-92f3-54ff06d31c4e@github.com>

> We need to throw appropriate exception when we pass invalid image index values to ImageReader.getImageTypes().
> We throw IOOBE in all other plugins except JPEG, Added appropriate check to throw IOOBE when JpegImageReader has invalid image index.

Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Update test to handle all regression cases
 - Add checks at other places also
 - Merge remote-tracking branch 'upstream/master' into jpeg_getImageTypes
 - Check only for negative index
 - 8364135: JPEGImageReader.getImageTypes() should throw exception for non-zero image index

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26522/files
  - new: https://git.openjdk.org/jdk/pull/26522/files/cfc24f34..a114acf4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26522&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26522&range=00-01

  Stats: 22793 lines in 627 files changed: 14398 ins; 6572 del; 1823 mod
  Patch: https://git.openjdk.org/jdk/pull/26522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26522/head:pull/26522

PR: https://git.openjdk.org/jdk/pull/26522

From jdv at openjdk.org  Thu Aug 21 05:06:53 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 21 Aug 2025 05:06:53 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw
 exception for negative image index [v2]
In-Reply-To: <4bimZDOPVXTxOjjE24uTit147oJO3_7-m4gDEg49tWs=.6a416335-c2e3-47f6-85d3-cba38b9b38ce@github.com>
References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
 <4bimZDOPVXTxOjjE24uTit147oJO3_7-m4gDEg49tWs=.6a416335-c2e3-47f6-85d3-cba38b9b38ce@github.com>
Message-ID: <tzmNhLOAfw5mHxQ7-XAuHzcPSRjww5Qnsk3MxFXgmsk=.01d08dc1-8084-45e2-89eb-8dc60888fd97@github.com>

On Tue, 29 Jul 2025 17:22:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Update test to handle all regression cases
>>  - Add checks at other places also
>>  - Merge remote-tracking branch 'upstream/master' into jpeg_getImageTypes
>>  - Check only for negative index
>>  - 8364135: JPEGImageReader.getImageTypes() should throw exception for non-zero image index
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 907:
> 
>> 905:         if (imageIndex != 0) {
>> 906:             throw new IndexOutOfBoundsException("imageIndex != 0!");
>> 907:         }
> 
> There are JPEG streams with > 1.
> And elsewhere we handle it. Look at hasNextImage()
> 
> Is this method the sole place where -1 would not throw the right exception ?

Thanks for the inputs.

getWidth(), getHeight(), getRawImageType() also need similar check.
What i have noticed is for all negative indices apart from "-1" we end up in gotoImage() function and it throws appropriate exception. Only getWidth(), getHeight(), getRawImageType() & getImageTypes() we don't throw proper exception according to spec when "-1" index is used. Also in case of getRawImageType() we actually throw NPE when "-1" index is passed.

So i have updated the code to add additional check for negative index at these places also.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26522#discussion_r2289860006

From jdv at openjdk.org  Thu Aug 21 05:06:57 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 21 Aug 2025 05:06:57 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw
 exception for negative image index [v2]
In-Reply-To: <JC2MuRL0krLRoBmuvnjLoGOWN_hzRwjlqDlKV8G9zog=.ee20f980-adb4-44fe-a8fa-e1751425fec9@github.com>
References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
 <JC2MuRL0krLRoBmuvnjLoGOWN_hzRwjlqDlKV8G9zog=.ee20f980-adb4-44fe-a8fa-e1751425fec9@github.com>
Message-ID: <BST6FFAHx9BetoAyOUJSqhKKDh4CXg62oO3SSn1mv3k=.a5b89615-5c0b-4b4a-8b66-6d8e25c04dc7@github.com>

On Fri, 1 Aug 2025 00:31:45 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Update test to handle all regression cases
>>  - Add checks at other places also
>>  - Merge remote-tracking branch 'upstream/master' into jpeg_getImageTypes
>>  - Check only for negative index
>>  - 8364135: JPEGImageReader.getImageTypes() should throw exception for non-zero image index
>
> test/jdk/javax/imageio/plugins/jpeg/JpegNegativeImageIndexTest.java line 53:
> 
>> 51:         ImageReader ir = readers.next();
>> 52:         try {
>> 53:             Iterator<ImageTypeSpecifier> types = ir.getImageTypes(-1);
> 
> You could expand the test to call this with different non-zero parameters (-2, -1, 1, 2) to see if the behavior is correct

Latest findings show that only in case of "-1" index we have issues.
So testing for only "-1" index is fine.

Also the test is updated to call getWidth(), getHeight(), getRawImageType() & getImageTypes().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26522#discussion_r2289862785

From psadhukhan at openjdk.org  Thu Aug 21 07:47:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 07:47:25 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26 [v3]
In-Reply-To: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
Message-ID: <m4B1TuCcb0zEtwm5sYjpQXOv4L565B5xYyD_nXv1zz0=.9b362ea3-12dc-435e-8d2e-1ce1a4c70202@github.com>

> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent

Prasanta Sadhukhan has updated the pull request incrementally with four additional commits since the last revision:

 - Remove not used import
 - Remove not used import
 - Remove debug
 - revert to tolerance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26833/files
  - new: https://git.openjdk.org/jdk/pull/26833/files/0517747a..4a57cb01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26833&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26833&range=01-02

  Stats: 20 lines in 1 file changed: 11 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26833.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26833/head:pull/26833

PR: https://git.openjdk.org/jdk/pull/26833

From psadhukhan at openjdk.org  Thu Aug 21 07:47:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 07:47:25 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <-U-DcYDioW8P0vJb1nX1tfKlHF4c-ndN0dh8ZkAr54Q=.2df89367-d6a5-40c8-b804-98bed02fd32b@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
 <dDK1UhX6KoY_mKZfY8u0JXBGADWvqdVCv_JQOhG6k50=.231288f7-ee29-40c5-aa0b-8bcfa1477d83@github.com>
 <-U-DcYDioW8P0vJb1nX1tfKlHF4c-ndN0dh8ZkAr54Q=.2df89367-d6a5-40c8-b804-98bed02fd32b@github.com>
Message-ID: <WfxqbDS4j_eKboxayl-e06go3Q9vq0ADI4DWCZRJy40=.5437c760-2288-43e8-8638-4e615b0b0852@github.com>

On Thu, 21 Aug 2025 04:44:16 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > the test might be updated to render components into the buffered image and then compare exact values.
> 
> And what does it test then? The original bug was about dragging the internal frame creates artifacts on the underlying component. By drawing the component after the drag into the BufferedImage - are we sure the artifacts will be drawn there too? I have my doubts about the logic of the test after the last change...

I guess you are right..I am not able to get the artifacts drawn into the BI with this...With createScreenCapture I could get so I reverted to the tolerance check
 
<img width="62" height="62" alt="JInternalFrameDraggingTest" src="https://github.com/user-attachments/assets/c6b9e128-8720-433e-8c91-d0f52e872bc7" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26833#issuecomment-3209384334

From lkorinth at openjdk.org  Thu Aug 21 09:12:57 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 21 Aug 2025 09:12:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnXjSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
Message-ID: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>

On Wed, 20 Aug 2025 14:25:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> @sendaoYan this PR changes the default timeoutFactor and so also has to change quite a number of implicit and explicit timeouts. But that doesn't mean that test configs that already set their own timeoutFactor should adjust by the same factor! That just doesn't work for any test with an implicit default timeout.
>
> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
> 
> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
> 
> I do agree this change, what I mean is this change has some side effect.
> 
>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
> 
> I think I can try it in a new PR.

I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.

I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2290422272

From syan at openjdk.org  Thu Aug 21 09:52:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 21 Aug 2025 09:52:54 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]
In-Reply-To: <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <T_idMds1WKla2LblpD3_92YsZ3s1n1-lk7IptDf3v3w=.08b986eb-2fb8-4528-bf12-b29f9171f722@github.com>
 <aKPjO3VM9BYZbLbtBGQ7Dv2RS8XXWxRTaYwom4FpF5s=.596366db-f8f3-462e-8d58-1f2b4875f80e@github.com>
 <JqXGsAnj04C5kBSFzzh2fxkt6FIjF3ltxY_Fc4KI5bw=.27de2a2c-f741-46d3-b7be-a42762419a2a@github.com>
 <bobzgp38GSGRF3TXyFBHfFwNfzlP3_6dEr9D-QRkem4=.a71bd9a1-b55e-4730-ac90-3400a0cb382f@github.com>
 <KD5i2i5usWvOk-6KvMXzTS_CtQu5UaQp383VcCkvFjc=.f8900257-5bfe-49eb-89a7-0b5d3bc9334a@github.com>
 <mDpdAYNZ3afVvamgVD4jhXGGHfn4IFffqGI35oHu7R0=.aa7fae33-3ace-4218-9e5e-c714558f2180@github.com>
 <ySJgsNVQNwyL0CGvE7WvE5v-ibuDMWU9kOK10upVF0Y=.29c05879-21f6-435a-9171-434ab2f625c2@github.com>
 <5YehMZKBa60PIk9Ia2sC4kLuFx5ZvfmtoYT_H-LuQbM=.e40c421f-d2af-46e5-8dc7-5b30fe79c0b0@github.com>
 <Bs-6_eYQA4-gEciriEyl3zBmL8DyqbqUJVXS25h-UD4=.971f2a5c-704b-4bfa-805f-b8edfb1e92fa@github.com>
 <ktQ-nguUwCOXiHqKS_KgndjPV0Re3erRgnX
 jSwDMjTQ=.f7f913ce-2fc7-4a48-8e0d-88a81d018198@github.com>
 <aIb4Lxc_k84vVIu_ljTy8TaLkNu4yJTc_7eZYXW_IUQ=.d64a48ff-0c38-4d81-8100-f1d330e2d7dd@github.com>
Message-ID: <N_1V36WztAVi1O6SdDaGQXa4b8TGB7xGpz5T1TbxL9I=.ea0293e3-eb0b-4d96-bd40-d5c9c4e3fd1d@github.com>

On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Yes, this PR change the default timeoutFactor when the tested JVM options do not contains '-Xcomp', and at the same time also multiplies 4 of the timeout value defined in some tests.
>> 
>> So after this PR, the tests which the timeout value has been multiplied 4 will have more timeout value, when the tested [JVM options contains '-Xcomp'](https://github.com/lkorinth/jdk/blob/286a2cc6e989a1c7dcd641bce792c6411bc1d0ea/make/RunTests.gmk#L593).
>> 
>> I do agree this change, what I mean is this change has some side effect.
>> 
>>> If you would like to change it after the integration I think that would be valuable --- though my guess is that it could be quite a lot of work.
>> 
>> I think I can try it in a new PR.
>
> I want to _warn_ you before you put too much energy into it. Changing the `-Xcomp` timeout factor might have even bigger impact than my change. Also, I have no idea how well that flag is tested in open testing. That is, your change might look good for you --- but might cause havoc for companies doing more extensive testing.
> 
> I have still not received green light for integrating my change, because extensive testing is still being run (and other teams are evaluating). I advise against changing the flag. When I evaluate the benefit for the default timeout, it was mainly not the timeout _in itself_ that was the problem, but the fact that most people have no idea that the timeout factor is applied and thus can not create or debug tests in a good way. I hope this helps you, and does not come out as too negative. I just feel that I have put too much energy into this, and I do not hope that struggle for you.

@lkorinth Thanks for your advice sincerely. I think you are right, we need more evaluate cautiously before start to change the timeoutFactor for -Xcomp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2290523415

From ihse at openjdk.org  Thu Aug 21 12:21:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 21 Aug 2025 12:21:00 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v4]
In-Reply-To: <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <0EoWHaPUvqZvxYNRoBbcFdHS9QVXCnfHQqPyd4srQlc=.cfd617e9-5be4-4c14-bf71-68a73d86836b@github.com>
 <8U5zCHQCXe9z3nrLlCwRVgbXCFzWHxqsvI74M1yQ96Y=.4ee013da-22a4-43e3-8660-8bf3c2261450@github.com>
Message-ID: <zgu5mLb1mA-ca4wxmJJjLNmmq3sJFwWtfjY4yRnmYFQ=.81a024ea-41ce-42cc-9038-3ef40e483793@github.com>

On Wed, 20 Aug 2025 15:21:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   after suggestion from Daniel
>
> It seems to me like there is a need to automatically collect normal test run times automatically, so we can match the timeout given to any individual test with the normal execution time. After all, the purpose of any timeout on tests is to allow the test to execute normally, but not wait too long in case of a problem that causes the test to take too long (or forever) to run.
> 
> I realize that this is highly hardware dependent, but test times tend to be Pareto distributed, so a very quick test maybe takes 1 second on fast machines and 10 on slow, and very slow tests maybe take 15 minutes on fast machines and 40 minutes on slow. In the first case, anything above 15 seconds is probably sus, and in the second case, anything above 60 is probably not good either (I'm just adding 50% to the max time). 
> 
> Right now it seems engineers is spending their valuable time giving guesstimates for each individual test. That seems like poorly used time and resources.

> @magicus unfortunately that is often not the case in practice. We can see many tests that normally run very quickly but occasionally run very slow - minutes versus seconds.

That is surprising and a bit disappointing. I guess it is not worth the effort to try and figure out why this is the case; it could probably vary from test to test and be difficult to track for little gain. Still, it makes you wonder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26749#issuecomment-3210365303

From kizune at openjdk.org  Thu Aug 21 16:24:50 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 21 Aug 2025 16:24:50 GMT
Subject: RFR: 8365711: Declare menuBarHeight and hotTrackingOn private
In-Reply-To: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
References: <lIZcaW2sJN0d2AN9S1zIp2Q85pcavUVUeQVdqD22q84=.76176de7-21a2-49af-8625-aa87fbd7d73d@github.com>
Message-ID: <ff0IhMTfJ86jOLVw57eTPM4zyDFJa0eOknqWEnGE70o=.fe632e7f-28e4-49c7-b5f0-6128ca43c9a3@github.com>

On Mon, 18 Aug 2025 17:05:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Since `WindowsMenuUI` is a final class after PR #24170 for [JDK-8352638](https://bugs.openjdk.org/browse/JDK-8352638)), it cannot be extended, therefore the `protected` modifier doesn't make sense.
> 
> Mark both `menuBarHeight` and `hotTrackingOn` as `private` fields.

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26829#pullrequestreview-3141422180

From kizune at openjdk.org  Thu Aug 21 16:25:53 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 21 Aug 2025 16:25:53 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26 [v3]
In-Reply-To: <m4B1TuCcb0zEtwm5sYjpQXOv4L565B5xYyD_nXv1zz0=.9b362ea3-12dc-435e-8d2e-1ce1a4c70202@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
 <m4B1TuCcb0zEtwm5sYjpQXOv4L565B5xYyD_nXv1zz0=.9b362ea3-12dc-435e-8d2e-1ce1a4c70202@github.com>
Message-ID: <sjpWn2lvOCzs7SB94GcMXYvVDYouv2_uKqmA2iOD73E=.c961f789-1572-48da-a688-a0ecfa27011d@github.com>

On Thu, 21 Aug 2025 07:47:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
>> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent
>
> Prasanta Sadhukhan has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove not used import
>  - Remove not used import
>  - Remove debug
>  - revert to tolerance

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26833#pullrequestreview-3141420151

From dnguyen at openjdk.org  Thu Aug 21 16:25:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 21 Aug 2025 16:25:54 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26 [v3]
In-Reply-To: <m4B1TuCcb0zEtwm5sYjpQXOv4L565B5xYyD_nXv1zz0=.9b362ea3-12dc-435e-8d2e-1ce1a4c70202@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
 <m4B1TuCcb0zEtwm5sYjpQXOv4L565B5xYyD_nXv1zz0=.9b362ea3-12dc-435e-8d2e-1ce1a4c70202@github.com>
Message-ID: <ggmelcN368MIHT7Ejw0hPYnQWIvDQ6f35hgrwp35epw=.523b3694-9190-447a-be33-f88b5c3d2956@github.com>

On Thu, 21 Aug 2025 07:47:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
>> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent
>
> Prasanta Sadhukhan has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove not used import
>  - Remove not used import
>  - Remove debug
>  - revert to tolerance

Marked as reviewed by dnguyen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26833#pullrequestreview-3141424188

From psadhukhan at openjdk.org  Thu Aug 21 16:48:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 21 Aug 2025 16:48:58 GMT
Subject: Integrated: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
Message-ID: <v3RrkLNK0WZCO5aSUokUZXfQJR-SvD-OtQ3S0WFUKnA=.6427cb01-0bf7-4d63-b005-504cfad9f1ef@github.com>

On Tue, 19 Aug 2025 06:14:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test compares specific pixels with expected color and needed color profile setting in macOS26 is not available it seems.
> Since the pixel color difference is slightly off, I have added a tolerance which had been present in many other tests so it's not without precedent

This pull request has now been integrated.

Changeset: bdf9834b
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdf9834b81f0565e3572de42ebd42981d1d05a5c
Stats:     15 lines in 1 file changed: 13 ins; 0 del; 2 mod

8365425: [macos26] javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on macOS 26

Reviewed-by: dnguyen, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/26833

From serb at openjdk.org  Thu Aug 21 18:07:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 21 Aug 2025 18:07:56 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <WfxqbDS4j_eKboxayl-e06go3Q9vq0ADI4DWCZRJy40=.5437c760-2288-43e8-8638-4e615b0b0852@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
 <dDK1UhX6KoY_mKZfY8u0JXBGADWvqdVCv_JQOhG6k50=.231288f7-ee29-40c5-aa0b-8bcfa1477d83@github.com>
 <-U-DcYDioW8P0vJb1nX1tfKlHF4c-ndN0dh8ZkAr54Q=.2df89367-d6a5-40c8-b804-98bed02fd32b@github.com>
 <WfxqbDS4j_eKboxayl-e06go3Q9vq0ADI4DWCZRJy40=.5437c760-2288-43e8-8638-4e615b0b0852@github.com>
Message-ID: <y6RrXWj5oMGZHBAYDTfx_cPLyHh1u4MwF48PDqlgbCc=.6feb0dd6-9eb2-401f-8822-2180b858251f@github.com>

On Thu, 21 Aug 2025 07:42:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>I guess you are right..I am not able to get the artifacts drawn into the BI with this...With createScreenCapture I could get so I reverted to the tolerance check

That because you have to set float transform for that rendering, to reproduce the artifacts, for screen it is covered by the Dsun.java2d.uiScale in the header of the test. There is no difference between rendering to the screen vs rendering to BI.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26833#issuecomment-3211593883

From prr at openjdk.org  Thu Aug 21 19:14:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 19:14:52 GMT
Subject: RFR: 8364768: JDK javax.imageio ImageWriters do not all flush the
 output stream [v2]
In-Reply-To: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
References: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
Message-ID: <iRUIn9l-lizy2tZpUIYrh3XVfJbMgTHlEvzEhynh4TQ=.c242e39c-156a-409d-abce-0848185160b7@github.com>

> 4 of the 6 JDK ImageWriters flush the stream at the end of writing. 2 (TIFF and GIF) do not. 
> 
> This will matter if you are using a caching ImageOutputStream.
> 
> This fix makes it consistent.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8364768

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26703/files
  - new: https://git.openjdk.org/jdk/pull/26703/files/ffe755a0..dac36e9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26703&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26703&range=00-01

  Stats: 14 lines in 1 file changed: 0 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26703/head:pull/26703

PR: https://git.openjdk.org/jdk/pull/26703

From prr at openjdk.org  Thu Aug 21 19:14:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 19:14:54 GMT
Subject: RFR: 8364768: JDK javax.imageio ImageWriters do not all flush the
 output stream [v2]
In-Reply-To: <a_ey9dXmF2AwIWjo3-9-lkAi0q2Ja1olRDEgLTmrNgg=.fea5c782-9d0d-423a-a35e-9bcc6fc76343@github.com>
References: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
 <a_ey9dXmF2AwIWjo3-9-lkAi0q2Ja1olRDEgLTmrNgg=.fea5c782-9d0d-423a-a35e-9bcc6fc76343@github.com>
Message-ID: <o3wVFem0GadG-N7CAoHg1ul0IBdodO3hqo2XpTxPja4=.5ef1a594-3072-4de9-bd51-d3f5916ec8bc@github.com>

On Wed, 20 Aug 2025 12:31:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8364768
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java line 737:
> 
>> 735:             writeTrailer();
>> 736:         }
>> 737:         stream.flush();
> 
> should we call flush or `flushBefore`(current stream position) as is being done in BMP writer?

You mean like BMP does this
            stream.flushBefore(stream.getStreamPosition());

flush() is exactly equivalent to that.

    public void flush() throws IOException {
        flushBefore(getStreamPosition());
    }

> test/jdk/javax/imageio/FlushTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2005, Oracle and/or its affiliates. All rights reserved.
> 
> 2025?

typo

> test/jdk/javax/imageio/FlushTest.java line 76:
> 
>> 74:                failed = true;
>> 75:             }
>> 76:         } finally {
> 
> no need for finally block or do we need to do `baos.close` here since FileCacheImageOutputStream.close says "The destination OutputStream is not closed."

BAOS doesn't need a close() call to report its size.
I can actually dispense with the whole try block since the method throws IOException

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26703#discussion_r2291906324
PR Review Comment: https://git.openjdk.org/jdk/pull/26703#discussion_r2291906705
PR Review Comment: https://git.openjdk.org/jdk/pull/26703#discussion_r2291916877

From prr at openjdk.org  Thu Aug 21 20:44:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 20:44:01 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v25]
In-Reply-To: <n0zF6BroPP9idfd6G_pPwBCowHzHDeDpMdkpubzC3-A=.f15c1ae2-2aae-4856-bb9e-03e83e7673cf@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <MXh3ZxTTwvo4y425WVc-10b3IHrKL9CgiyEZgpH5NM8=.34f14f75-1b71-4e3e-89de-1f91bd9599c8@github.com>
 <n0zF6BroPP9idfd6G_pPwBCowHzHDeDpMdkpubzC3-A=.f15c1ae2-2aae-4856-bb9e-03e83e7673cf@github.com>
Message-ID: <tuYVV1s5ufwTxww2ETZbUCet1OvzNRh_-JL3OMyPbno=.e8fc8432-b028-4fc8-8374-1aa19fdeb048@github.com>

On Tue, 5 Aug 2025 11:28:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   class javadoc modification
>
> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 90:
> 
>> 88:                        case IMAGE :
>> 89:                            if (v == ArgVal.NULL) {
>> 90:                                new ImageIcon((Image)null);
> 
> Suggestion:
> 
>                                new ImageIcon((Image) null);
> 
> I guess you advocated for having a space between the type cast operator and its argument.

Personally, I do not like having a space there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2292086290

From prr at openjdk.org  Thu Aug 21 20:44:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 20:44:00 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v26]
In-Reply-To: <hjI1ozzITjVZWLTEL5wFvEROkJivgnqyjgrRCB3H1F0=.908100fc-9f8a-4c62-9898-749406314d4e@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <hjI1ozzITjVZWLTEL5wFvEROkJivgnqyjgrRCB3H1F0=.908100fc-9f8a-4c62-9898-749406314d4e@github.com>
Message-ID: <_ukVu5U8TM0LkAlt0ZikNJ0P-vFmjNSKhzlfTfaKU20=.174508f0-2fab-4aab-85e3-ee28655c526f@github.com>

On Wed, 6 Aug 2025 02:58:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-3142207584

From prr at openjdk.org  Thu Aug 21 20:48:55 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 20:48:55 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw
 exception for negative image index [v2]
In-Reply-To: <EVI-lhlzW_6j3WBBqcnImUFtJG2N8-4RGvOCsvt5wO0=.842ee3a8-f3bd-4482-92f3-54ff06d31c4e@github.com>
References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
 <EVI-lhlzW_6j3WBBqcnImUFtJG2N8-4RGvOCsvt5wO0=.842ee3a8-f3bd-4482-92f3-54ff06d31c4e@github.com>
Message-ID: <NLFlfIrA2oRWb01eiAXETP-w8wJcOFa5uE0uJHQ62u0=.919fb8cf-7426-46dc-a8d7-c610c942a719@github.com>

On Thu, 21 Aug 2025 04:58:12 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We need to throw appropriate exception when we pass invalid image index values to ImageReader.getImageTypes().
>> We throw IOOBE in all other plugins except JPEG, Added appropriate check to throw IOOBE when JpegImageReader has invalid image index.
>
> Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Update test to handle all regression cases
>  - Add checks at other places also
>  - Merge remote-tracking branch 'upstream/master' into jpeg_getImageTypes
>  - Check only for negative index
>  - 8364135: JPEGImageReader.getImageTypes() should throw exception for non-zero image index

Marked as reviewed by prr (Reviewer).

test/jdk/javax/imageio/plugins/jpeg/JpegNegativeImageIndexTest.java line 60:

> 58:             ImageTypeSpecifier specifier = ir.getRawImageType(-1);
> 59:         } catch (IndexOutOfBoundsException e) {
> 60:             if (Objects.equals(e.getMessage(), "imageIndex < 0")) {

A bit fragile checking the exception text, but I suppose it won't be changed unless this test changes too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26522#pullrequestreview-3142229936
PR Review Comment: https://git.openjdk.org/jdk/pull/26522#discussion_r2292101727

From prr at openjdk.org  Thu Aug 21 20:52:12 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 20:52:12 GMT
Subject: Integrated: 8365389: Remove static color fields from SwingUtilities3
 and WindowsMenuItemUI
In-Reply-To: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
References: <tDTxo22wvhQqp-F2ibMY6DppIt-grJbIbJ0lEa_jlys=.f59ac4f4-c8c0-408a-832a-ea63da97c9f3@github.com>
Message-ID: <MBgGx2gxuJr__9EGGOxqxJ8uG_GlY5oAiJadPSVx6I8=.a79e9b18-5595-48fa-a116-56ebd58baf20@github.com>

On Thu, 14 Aug 2025 16:19:08 GMT, Phil Race <prr at openjdk.org> wrote:

> This refactors some Swing code to pass args instead of using statics
> The bug report suggests some further refactoring which could be considered later, but the most
> important thing to do is to eliminate using statics to pass args.
> I've added one other suggestion from the bug report to have the windows case call SU3 directly rather than via newly added static methods, but for the basic case, I left the pre-existing private instance methods.

This pull request has now been integrated.

Changeset: 3468c6e5
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3468c6e5ef7e7592cf9484736ce333fbe0eaf34d
Stats:     78 lines in 6 files changed: 14 ins; 50 del; 14 mod

8365389: Remove static color fields from SwingUtilities3 and WindowsMenuItemUI

Reviewed-by: psadhukhan, aivanov, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/26783

From aivanov at openjdk.org  Thu Aug 21 20:55:41 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 21 Aug 2025 20:55:41 GMT
Subject: RFR: 8365625: Can't change accelerator colors in Windows L&F [v2]
In-Reply-To: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
References: <ym1xF2kSZDI3OMsJy1evCAprRfw982gMz4fQun4-YWY=.c1e59188-81a4-4e4d-a9c7-7c69b0ae1333@github.com>
Message-ID: <t_S71ApYzaRx9uZxsH7Ik6u8m2PJrDJRGJeCkjcuybA=.dc10eaa4-c2b7-472f-94f7-28153fd85836@github.com>

> **Problem:**
> 
> The colors for the accelerators are cached in static fields: `disabledForeground`, `acceleratorSelectionForeground` and `acceleratorForeground`. As soon as this field is set to a non-`UIResource` value, the value cannot change.
> 
> **Fix:**
> 
> Remove the static fields for accelerator from `WindowsMenuItemUI` and use the fields inherited from `BasicMenuItemUI`, pass these fields as parameters to static methods.
> 
> Additionally, I formatted the calls to `WindowsMenuItemUI.paintMenuItem` in one consistent way.
> 
> I removed the redundant javadoc from `paintMenuItem` and added the missing `@Override` annotation.
> 
> I provided a regression test. The test also reproduces [JDK-8365375](https://bugs.openjdk.org/browse/JDK-8365375) that was resolved in #26743.

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26826/files
  - new: https://git.openjdk.org/jdk/pull/26826/files/d4286bcb..d4286bcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26826&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26826&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26826/head:pull/26826

PR: https://git.openjdk.org/jdk/pull/26826

From prr at openjdk.org  Thu Aug 21 21:02:04 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 21:02:04 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <XIhk126azaZ0CsHwMGRTN4ZfaSbIjh-qZ0FRbDU89FI=.17885d36-7c2d-4967-8c83-d3725a327013@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <H6SodhHzqEyg_MvilXBfWsBkaDZmS_vU4nlanu65Qok=.64239aae-2a2d-4667-90cc-5bb422093264@github.com>
 <XIhk126azaZ0CsHwMGRTN4ZfaSbIjh-qZ0FRbDU89FI=.17885d36-7c2d-4967-8c83-d3725a327013@github.com>
Message-ID: <gKEcOvEnvgcimse0zDe_4IB6aQHeINY-hYBQIFXHnAQ=.b25a2a04-80f0-4836-9086-0f43919cc36e@github.com>

On Wed, 20 Aug 2025 12:06:19 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> > There seem to be un-related changes in this PR. Please check.
> 
> In [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) PR, they asked not to create multiple tickets for the same issues? even if they are in different files?
> 
> However, it?s not difficult for me to distribute the fixes across several tickets into different subcomponents if you think it?s necessary to do so.

I see. From the bug subject I would never have guessed it touched GTK and gif decoding.
And you expended about 3 sentences in the description on the OGL one and didn't discuss the others.
They deserve some discussion too.

And then the JBS issue and the PR should have a title change  .. something like this 
"Fix several potential NULL native pointer dereferences in the desktop module".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26799#issuecomment-3212053696

From serb at openjdk.org  Thu Aug 21 21:15:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 21 Aug 2025 21:15:55 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v3]
In-Reply-To: <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
 <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
Message-ID: <tRNfXK3RHxxaCIMlAYMQmkx7wMkr43yPMPFSzHCUt3M=.81801860-2c5b-4062-b2d7-aa2ee524468a@github.com>

On Tue, 19 Aug 2025 14:41:54 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### TL;DR
>> 
>> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
>> 
>> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
>> 
>> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
>> 
>> ### Full description
>> 
>> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
>> 
>> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
>> 
>> Segment: ?????????? 0 10
>> Segment: ????????? 10 9
>> Segment: ???????? 19 8
>> Segment: ? 27 1
>> 
>> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) f...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added JTreg test to verify monotonically growing glyph character indices

Looks fine to me. I did not find any way to trigger this in cases where it might be needed other than the broken case described in the bug.

@gredler, @prrace please take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3212084183
PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3212087722

From serb at openjdk.org  Thu Aug 21 21:26:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 21 Aug 2025 21:26:56 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v3]
In-Reply-To: <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
 <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
Message-ID: <b1qtjmlEAjn_Yp_9adU10Pds8gvUB4dqL5fx4x3FRZw=.92b379c8-e7bb-46e5-a52e-8590289c7081@github.com>

On Tue, 19 Aug 2025 14:41:54 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### TL;DR
>> 
>> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
>> 
>> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
>> 
>> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
>> 
>> ### Full description
>> 
>> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
>> 
>> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
>> 
>> Segment: ?????????? 0 10
>> Segment: ????????? 10 9
>> Segment: ???????? 19 8
>> Segment: ? 27 1
>> 
>> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) f...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added JTreg test to verify monotonically growing glyph character indices

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26825#pullrequestreview-3142319406

From prr at openjdk.org  Thu Aug 21 21:41:51 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 21:41:51 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v3]
In-Reply-To: <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
 <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
Message-ID: <fjAUpU_OrpNKAJYV17IFpzxQB7CIRqJhHYRE0_JjEIs=.c6ec899a-3b3b-4fa8-be3d-4bde024abf88@github.com>

On Tue, 19 Aug 2025 14:41:54 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### TL;DR
>> 
>> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
>> 
>> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
>> 
>> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
>> 
>> ### Full description
>> 
>> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
>> 
>> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
>> 
>> Segment: ?????????? 0 10
>> Segment: ????????? 10 9
>> Segment: ???????? 19 8
>> Segment: ? 27 1
>> 
>> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) f...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added JTreg test to verify monotonically growing glyph character indices

I already ran all our automated tests, and I'm not too surprised they pass, since they probably don't cover this as well as they should. 
I think it would be possible and a good idea to add a test.
All you need to do is find a font that definitely supports Khmer.
I also  took a quick look but I need to look properly and also I think
that manual testing of editing in a Swing editor pane (not just displaying) be done.
Ideally that needs someone who reads and writes Khmer but I don't know anyone who can do that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3212159047

From prr at openjdk.org  Thu Aug 21 22:40:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 22:40:01 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
Message-ID: <b3gAyt7t_Ur5HBjtUC5Rbw9e494EkCMMsE-rZnwNTU0=.4c94a435-b4f1-49cb-95ba-f5d6481b2bd3@github.com>

On Fri, 15 Aug 2025 13:04:35 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> The defect has been detected and confirmed in the function OGLBlitToSurfaceViaTexture() located in the file src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null.
> 
> According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places.

src/java.desktop/share/native/libsplashscreen/splashscreen_gif.c line 282:

> 280:                 rgbquad_t fillColor = 0;                        // 0 is transparent
> 281: 
> 282:                 if (((colorMap != NULL) && (colorMap->Colors != NULL)) &&

I can't easily verify that this is an impossible place to be if colorMap == null
so I guess this is OK

src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 618:

> 616:         fp_g_string_free = dl_symbol("g_string_free");
> 617: 
> 618:         if (fp_glib_check_version != NULL) {

I don't know why we don't treat failing to find this symbol as a fatal error like we do for others such as this first one. dl_symbol will do a longjmp 
        fp_gtk_check_version = dl_symbol("gtk_check_version");
     
but for this one we just clear the error.
        /* GLib */
        fp_glib_check_version = dlsym(gtk3_libhandle, "glib_check_version");
        if (!fp_glib_check_version) {
            dlerror();
        }

@azvegint any idea ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26799#discussion_r2292275064
PR Review Comment: https://git.openjdk.org/jdk/pull/26799#discussion_r2292273980

From prr at openjdk.org  Thu Aug 21 23:20:53 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 21 Aug 2025 23:20:53 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v6]
In-Reply-To: <kzNLoqMvrG0Gls8KnHlxy1KhQT-VGgLNs3cRphZuUuE=.b98c2075-65a4-4c8d-8c91-af0074a11b19@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <kzNLoqMvrG0Gls8KnHlxy1KhQT-VGgLNs3cRphZuUuE=.b98c2075-65a4-4c8d-8c91-af0074a11b19@github.com>
Message-ID: <SsFE1mYGDrLQ_zKoJXCDgEwHFnbh4v_iiJfy7cASZ54=.a1050c4b-3c42-4e30-ac03-c50ab9274c7e@github.com>

On Fri, 11 Jul 2025 18:59:18 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - 8357034: re-wrapping line breaks
>  - 8356137, 8357034: add debug option to dump PNGs of frames
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
>  - Merge branch 'master' into JDK-8357034
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>  - Merge branch 'master' into JDK-8357034
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: trivial javadoc update
>  - 8356137: only inspect last frame of gif
>    
>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/a86dd56d...7c96ce19

src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 605:

> 603:         if (isSimpleSavedImageComparison) {
> 604:             for (int a = 0; a < saved_image.length; a++) {
> 605:                 if ((saved_image[a] & 0xff) == trans_pixel) {

How do you know here that the transparent pixel changed ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2292318270

From azvegint at openjdk.org  Fri Aug 22 00:27:51 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Aug 2025 00:27:51 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <b3gAyt7t_Ur5HBjtUC5Rbw9e494EkCMMsE-rZnwNTU0=.4c94a435-b4f1-49cb-95ba-f5d6481b2bd3@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <b3gAyt7t_Ur5HBjtUC5Rbw9e494EkCMMsE-rZnwNTU0=.4c94a435-b4f1-49cb-95ba-f5d6481b2bd3@github.com>
Message-ID: <H6tSL-dUri2m5W1Ujf6RdaNupMQ0hOb-xJnOz-NFXsk=.5a4e0789-c512-459c-ae07-00ba684fe384@github.com>

On Thu, 21 Aug 2025 22:36:02 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't know why we don't treat failing to find this symbol as a fatal error like we do for others such as this first one.

It looks like the `glib_check_version` was added but never used. The first instance of its use appears to be the added check for the methods used for Screencast. And it was overlooked that the `fp_glib_check_version` can be `null`.

The `glib_check_version` is [available since 2.6](https://docs.gtk.org/glib/func.check_version.html), and the 2.6.0 [was released in 2004](https://mail.gnome.org/archives/gnome-announce-list/2004-December/msg00036.html), so I guess we can safely replace the `dlsym` with the `dl_symbol`.
This will be better than remembering to protect it with a null check if we decide to use `glib_check_version` later somewhere else.



-        fp_glib_check_version = dlsym(gtk3_libhandle, "glib_check_version");
-        if (!fp_glib_check_version) {
-            dlerror();
-        }
+        fp_glib_check_version = dl_symbol("glib_check_version");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26799#discussion_r2292407186

From azvegint at openjdk.org  Fri Aug 22 00:30:51 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Aug 2025 00:30:51 GMT
Subject: RFR: 8365180: Remove sun.awt.windows.WInputMethod.finalize() [v2]
In-Reply-To: <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
 <PakHVprS3uIgBESFx2fTpcEDM-u3eIpapcla-Ufieyo=.a0b2d58a-2d80-4e4b-8a9f-504d8221f644@github.com>
Message-ID: <CULULS4-D9zUEfYnJn_E05E8ReSzYFUByOD8ll8MlEA=.5b65f494-04f3-4363-98ae-edd53aba84db@github.com>

On Tue, 19 Aug 2025 16:47:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove finalize() from WInputMethod.java - it is used to free a native id.
>> Also the reason dispose() didn't free it seems no longer relevant.
>> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
>> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365180

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26706#pullrequestreview-3142655536

From serb at openjdk.org  Fri Aug 22 03:06:06 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 22 Aug 2025 03:06:06 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
 [v2]
In-Reply-To: <0Zwu2GR2cXqlhGDab0Zew2LDhwwMzIRUv5sDLlydsmI=.fa50e1e4-0f9a-44f5-8955-208733dc2e3e@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
 <0Zwu2GR2cXqlhGDab0Zew2LDhwwMzIRUv5sDLlydsmI=.fa50e1e4-0f9a-44f5-8955-208733dc2e3e@github.com>
Message-ID: <38__1rbFEcTadhVd_ufUca1PtgWOhpdbB8BiHJzCTV4=.72d0447b-4e23-4a81-9c89-17ed5a84c757@github.com>

On Wed, 20 Aug 2025 20:36:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove javax.imageio.spi.ServiceRegistry.finalize() since it is deprecated for removal.
>> The impact of this should be minimal. The IIORegistry will now be a singleton - which it already was 
>> in practice since Applets are no longer supported. Since it is a singleton, it will persist for the life
>> of the VM, so will never be garbage collected.
>> A test that verifies one per-AppContext is now obsolete, and is deleted, and there's no good reason to make it a negative test, since in due course AppContext itself will be deleted and is un-used today except in tests.
>> 
>> Since JDK 9, ServiceRegistry has supported only Image I/O specified providers, and since the IIORegistry does this,
>> in practice there is very little reason for an application to create instances or subclasses of it.
>> And even if they do, typically like IIORegistry, they be used for the life time of the application.
>> And if they are collected, without calling ServiceRegistry.deregisterAll() there may be no impact,
>> since only providers that implement RegisterableService will be affected.
>> 
>> See the JBS issue for all the details.
>> 
>> The CSR is ready for review https://bugs.openjdk.org/browse/JDK-8365409
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8365292

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26752#pullrequestreview-3142943850

From serb at openjdk.org  Fri Aug 22 03:06:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 22 Aug 2025 03:06:07 GMT
Subject: RFR: 8365292: Remove javax.imageio.spi.ServiceRegistry.finalize()
 [v2]
In-Reply-To: <PHIAWd7RuhHnE6dHAUlZ-yBNjXM8ZnB85sgDPngIC0I=.5bd7e7df-d451-4630-bb20-46ed1524553e@github.com>
References: <T4lvWABJYroVElL0_7RYChGAIdvwpRra4V8EPzpcJQk=.13ccec3a-7f8e-4f23-ba4f-e05191b300f4@github.com>
 <xWy53TemnV-uH_GlxXhu5_21XzZN5iY6Bkp3eAg-PjI=.18ef29dc-d27f-450b-9677-8a51a2f1893e@github.com>
 <qnp7zW8pwZO7k54u1TIz-xLfBKSbONpX7YvRNH-jtLU=.5829a3f4-a470-4185-ba0a-7e53744bfd9e@github.com>
 <T0O3eFcOgl08lPO75GUV-qg_HpnfV5Jg6Yw1Fwi9_-o=.0ddcff17-0bef-4c00-ab76-add21cbe74af@github.com>
 <PHIAWd7RuhHnE6dHAUlZ-yBNjXM8ZnB85sgDPngIC0I=.5bd7e7df-d451-4630-bb20-46ed1524553e@github.com>
Message-ID: <mDCwkoxXI6coDqgodjIpDDc6US4bS__8eIDN5tr-JTo=.c400d4de-c8f3-4313-a85b-7b87b0be40b7@github.com>

On Wed, 20 Aug 2025 20:33:09 GMT, Phil Race <prr at openjdk.org> wrote:

>I don't see how there's any deadlock risk here, and certainly no more than before.

I do not have a strong opinion, but this is possible if the application starts loading or initializing classes including those related to its service providers -> which may use IIORegistry. And on another thread, other classes might try to initialize IIORegistry first -> boom.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26752#discussion_r2292585460

From rkannathpari at openjdk.org  Fri Aug 22 03:36:24 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 22 Aug 2025 03:36:24 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid [v2]
In-Reply-To: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
Message-ID: <EdnDFGYm2AkEcZ9EVZGZm3C2q6wqJUr7KAdvf_4ihgo=.6a1c6b5c-ae11-40ce-8440-08f0a9b3d963@github.com>

> Hi Reviewers,
> 
> Updated the Bean Property description with meaningful string for JTable.setShowGrid.
> 
> Pleas review and let me know your suggestions if any.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Upadted based on suggesion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26857/files
  - new: https://git.openjdk.org/jdk/pull/26857/files/1518aa24..33e8e04d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26857&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26857&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26857.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26857/head:pull/26857

PR: https://git.openjdk.org/jdk/pull/26857

From rkannathpari at openjdk.org  Fri Aug 22 03:37:51 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 22 Aug 2025 03:37:51 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid [v2]
In-Reply-To: <3AQWlfyLtvCTtF0UqPFnofXzC6Ijks2SAOndLqjrfmM=.3a6ef77b-ea77-4388-9146-de83636f53f6@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
 <cJaaPHRg1XpRENssj_NfPCsDsEv1m9jbt6kBjvM-IH4=.a95c6297-b0ac-4020-9c65-4d4491fcbacd@github.com>
 <3AQWlfyLtvCTtF0UqPFnofXzC6Ijks2SAOndLqjrfmM=.3a6ef77b-ea77-4388-9146-de83636f53f6@github.com>
Message-ID: <dQg77aM-HSuItQqempVoqSsTxEAeuxXEn3o8B7NG25Q=.257964a5-5af6-4975-9672-2f4140747075@github.com>

On Wed, 20 Aug 2025 20:09:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 1167:
>> 
>>> 1165:      */
>>> 1166:     @BeanProperty(description
>>> 1167:             = "Whether grid lines should be drawn in between the cells.")
>> 
>> It probably need a CSR update as this line is part of spec now
>
> I think we can skip a CSR for this. It is an obvious copy/paste typo and it is a bean property description, nit the javadoc spec which is correct.

Thank you @prrace, @prsadhuk for your time and review.

@mrserb  thank you for bringing this up, I have updated the description made it inline with spec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26857#discussion_r2292611621

From psadhukhan at openjdk.org  Fri Aug 22 03:56:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Aug 2025 03:56:53 GMT
Subject: RFR: 8364768: JDK javax.imageio ImageWriters do not all flush the
 output stream [v2]
In-Reply-To: <iRUIn9l-lizy2tZpUIYrh3XVfJbMgTHlEvzEhynh4TQ=.c242e39c-156a-409d-abce-0848185160b7@github.com>
References: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
 <iRUIn9l-lizy2tZpUIYrh3XVfJbMgTHlEvzEhynh4TQ=.c242e39c-156a-409d-abce-0848185160b7@github.com>
Message-ID: <0W6GTt4K0tY_QAZFvq2i3lPBvLgrS7aD0vytdCC4HbY=.4d200590-1a8c-4e1f-8445-42a246e8eec3@github.com>

On Thu, 21 Aug 2025 19:14:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> 4 of the 6 JDK ImageWriters flush the stream at the end of writing. 2 (TIFF and GIF) do not. 
>> 
>> This will matter if you are using a caching ImageOutputStream.
>> 
>> This fix makes it consistent.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364768

LGTM

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26703#pullrequestreview-3142995391

From psadhukhan at openjdk.org  Fri Aug 22 03:58:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Aug 2025 03:58:38 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when the
 component orientation is changed
Message-ID: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>

When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.

This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
At start `leftComponent = Red, rightComponent = Green`

before `super.addImpl` is called in `JSplitPane.addImpl` the 

`leftComponent = Green, rightComponent = Green`

After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
leftComponent = null.

so we have
leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
so we have now
leftComponent = null, rightComponent = null

so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.

So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components

-------------

Commit messages:
 - 8365886: JSplitPane loses track of the left component when the component orientation is changed

Changes: https://git.openjdk.org/jdk/pull/26893/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365886
  Stats: 40 lines in 2 files changed: 34 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26893/head:pull/26893

PR: https://git.openjdk.org/jdk/pull/26893

From prr at openjdk.org  Fri Aug 22 04:31:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 04:31:55 GMT
Subject: Integrated: 8365180: Remove sun.awt.windows.WInputMethod.finalize()
In-Reply-To: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
References: <yKZeEAmzKnKy_chEj6NN07eWuaFFVJrOmVcPHOeTFMM=.d6729c07-9181-46eb-9ee1-62edb9290cd2@github.com>
Message-ID: <NGFTDdTSnG7Hd7iRtUcKXOHrXwJS4K_JTeXSc_J9404=.1daff851-833d-450f-8342-2bacef4a0862@github.com>

On Fri, 8 Aug 2025 21:38:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize() from WInputMethod.java - it is used to free a native id.
> Also the reason dispose() didn't free it seems no longer relevant.
> Although I did see (when instrumenting) that dispose() was called when I disposed() the Frame referencing the IM,
> I don't know if I can be sure that is always done. So safest to add the Disposer in case it isn't.

This pull request has now been integrated.

Changeset: 8e448569
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e4485699235caff0074c4d25ee78539e57da63a
Stats:     29 lines in 2 files changed: 13 ins; 3 del; 13 mod

8365180: Remove sun.awt.windows.WInputMethod.finalize()

Reviewed-by: serb, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/26706

From prr at openjdk.org  Fri Aug 22 04:36:50 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 04:36:50 GMT
Subject: RFR: 8365609: Null pointer dereference in
 src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c
 OGLBlitToSurfaceViaTexture()
In-Reply-To: <H6tSL-dUri2m5W1Ujf6RdaNupMQ0hOb-xJnOz-NFXsk=.5a4e0789-c512-459c-ae07-00ba684fe384@github.com>
References: <Cu_xbr7_mfLrOrLQVGyFzILxenA70FE0Innu4HeqUrY=.31e190c6-673a-4d4d-9f30-86c1281757fc@github.com>
 <b3gAyt7t_Ur5HBjtUC5Rbw9e494EkCMMsE-rZnwNTU0=.4c94a435-b4f1-49cb-95ba-f5d6481b2bd3@github.com>
 <H6tSL-dUri2m5W1Ujf6RdaNupMQ0hOb-xJnOz-NFXsk=.5a4e0789-c512-459c-ae07-00ba684fe384@github.com>
Message-ID: <7yOf7xqnuzV-FjfdWvP3cJ8fKwRMlBHNtcfmOKyv0Qg=.99a12813-8d56-429e-a7b2-75fa3d761ce1@github.com>

On Fri, 22 Aug 2025 00:23:03 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c line 618:
>> 
>>> 616:         fp_g_string_free = dl_symbol("g_string_free");
>>> 617: 
>>> 618:         if (fp_glib_check_version != NULL) {
>> 
>> I don't know why we don't treat failing to find this symbol as a fatal error like we do for others such as this first one. dl_symbol will do a longjmp 
>>         fp_gtk_check_version = dl_symbol("gtk_check_version");
>>      
>> but for this one we just clear the error.
>>         /* GLib */
>>         fp_glib_check_version = dlsym(gtk3_libhandle, "glib_check_version");
>>         if (!fp_glib_check_version) {
>>             dlerror();
>>         }
>> 
>> @azvegint any idea ?
>
>> I don't know why we don't treat failing to find this symbol as a fatal error like we do for others such as this first one.
> 
> It looks like the `glib_check_version` was added but never used. The first instance of its use appears to be the added check for the methods used for Screencast. And it was overlooked that the `fp_glib_check_version` can be `null`.
> 
> The `glib_check_version` is [available since 2.6](https://docs.gtk.org/glib/func.check_version.html), and the 2.6.0 [was released in 2004](https://mail.gnome.org/archives/gnome-announce-list/2004-December/msg00036.html), so I guess we can safely replace the `dlsym` with the `dl_symbol`.
> This will be better than remembering to protect it with a null check if we decide to use `glib_check_version` later somewhere else.
> 
> 
> 
> -        fp_glib_check_version = dlsym(gtk3_libhandle, "glib_check_version");
> -        if (!fp_glib_check_version) {
> -            dlerror();
> -        }
> +        fp_glib_check_version = dl_symbol("glib_check_version");

So that would be the proper fix here, not the proposed one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26799#discussion_r2292666097

From prr at openjdk.org  Fri Aug 22 04:41:04 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 04:41:04 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v10]
In-Reply-To: <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
 <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
Message-ID: <61rAYTQoEhN8aOtPd69UgfMyHPHu6bOkPZO-2UKCFkM=.66059515-d7fc-4834-875c-da3fbd35f951@github.com>

On Mon, 9 Dec 2024 09:56:15 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731)
>> 
>> This is tracked in JBS as
>> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731)
>> 
>> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input)
>> 
>> `alt` is not an attribute of the `input` element.
>> 
>> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : 
>> 
>>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ...
>> 
>> This feature is not implemented in `FormView.java`.
>> 
>> ??  ~~This also affects the HTML 32 DTD~~
>> 
>> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138)
>> 
>> Left before the patch and right after the patch.
>> 
>> 
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import javax.swing.JEditorPane;
>> import javax.swing.JFrame;
>> import javax.swing.JScrollPane;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.Document;
>> import javax.swing.text.html.HTMLEditorKit;
>> import javax.swing.text.html.StyleSheet;
>> 
>> public class HTMLAddsSupportAltInputTag {
>>   public static void main(String[] args) {
>>     new HTMLAddsSupportAltInputTag();
>>   }
>>   
>>   public HTMLAddsSupportAltInputTag() {
>>     SwingUtilities.invokeLater(new Runnable(){
>>       public void run(){
>>         JEditorPane jEditorPane = new JEditorPane();
>>         jEditorPane.setEditable(false);
>>         JScrollPane scrollPane = new JScrollPane(jEditorPane);
>>         HTMLEditorKit kit = new HTMLEditorKit();
>>         jEditorPane.setEditorKit(kit);
>>         StyleSheet styleSheet = kit.getStyleSheet();
>>         styleSheet.addRule("""
>>             body {
>>                 color: #000;
>>                 font-family:times;
>>                 margin: 4px;
>>             }
>>             """);
>>         String htmlString = """
>>             <html>
>>                 <body>
>>                     <input type=image name=point src="file:oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>>                     <p>
>>                     <input type=image name=point src="file:none_ora...
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge master
>  - JDK-8314731 : Remove all indentations accidentally introduced by the previous commit.
>  - Merge master
>  - Merge master
>  - jdk-8314731 : FormView Alt Support.
>    
>    FormView.java :
>    - revert ALL unrelated changing to formatting.
>    
>    bug8314731.java :
>    - Fix the test description.
>    - Change where the user interface is created.
>    - Add a finall block to be sure the Frame is disposed.
>    - Replace "testPassed" with "testFailed".
>  - Merge master
>  - Replaces this title with "alt attribute test in HTML image type input".
>    
>    Moves this test to /jdk/test/jdk/javax/swing/text/html.
>  - bug8314731.java : Corrects the CopyRight date.
>  - FormView.java :
>    Removes a whitespace
>    
>    bug8314731.java :
>    Adds a newline at end of file.
>  - getMaximumSpan(int axis) method
>    doc -> Not used
>    
>    mouseReleased(MouseEvent evt) method
>    elem and hdoc -> not used
>    return -> could be removed, method returns void
>    
>    loadElementDataIntoBuffer(Element elem, StringBuilder buffer) method
>    value != null -> name can't be null at this point
>    
>    getInputElementData(AttributeSet attr) method
>    value = null -> Already set at null
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/69e664de...9b423808

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-3143050987

From philip.race at oracle.com  Fri Aug 22 05:11:14 2025
From: philip.race at oracle.com (Philip Race)
Date: Thu, 21 Aug 2025 22:11:14 -0700
Subject: JDK-4138921: TextLayout handling of empty strings
In-Reply-To: <CAPA+ug7fWrp3JUq_VHh+ohpMoGfMvjm-JeXS7gVRht0zfn7Gxg@mail.gmail.com>
References: <CAPA+ug6A88qeG+bRC3UAvvkp67jALtQXEsF0OMxK=WnsXbxQUw@mail.gmail.com>
 <994c74d6-2eb4-4588-ad6a-25529b68bd1e@oracle.com>
 <CAPA+ug7fWrp3JUq_VHh+ohpMoGfMvjm-JeXS7gVRht0zfn7Gxg@mail.gmail.com>
Message-ID: <981f8152-dec9-4b04-8dcf-62b0a198ab54@oracle.com>

I suppose they won't be that surprised, since it has been the behaviour 
already.

I think it unlikely that an app throws null at TextLayout on purpose 
knowing it won't work.
That's the realm of conformance tests, not real programs, so I'm not 
terribly worried about that.

What I was getting at, in part, is that it seems possible to me that 
this was not checked
because the thinking was in this case, null was allowed and meant a 
default FRC.
If we change the exception type it makes it one step harder if we find 
out that's where we want to end up.
I don't see a lot of supporting evidence for that, so I am just throwing 
it out there.
It could also be that it was added at a different time by some one not 
following the rest of the API

But this point is minor. The big question is around the empty string.
It certainly was a pain for me when doing printing when I had needed to 
use TextLayout
and had to be careful of this case.

It would be 'ideal' if "" was just silently handled and didn't cause 
issues for existing code - other than conformance tests
which shouldn't be testing unspecified behaviour anyway.

-phil.

On 8/19/25 4:29 AM, Daniel Gredler wrote:
> Hi Phil,
>
> >> First, there is a related API oddity in that null FontRenderContext
> >> parameters passed to the TextLayout constructors cause a
> >> NullPointerException, rather than an IllegalArgumentException (like
> >> all other parameters). Can this behavior also be changed?
>
> > It is a bit odd that frc is the only one not explicitly checked so the
> > NPE is just what 'happens'.
> > I'd be reluctant to change the NPE without a good reason [...]
> > I'd say just specify what happens for complete compatibility.
>
> I guess I'm hesitant to promote an "accidental" NPE to official 
> behavior here, when all other null parameter values are handled with 
> an explicit IAE. This inconsistency is going to surprise developers, 
> and avoiding that surprise would be ideal. How likely is it that 
> adding an explicit IAE-generating null FRC check here will break 
> existing code?
>
> Take care,
>
> Daniel
>
>
> On Mon, Aug 11, 2025 at 7:12?PM Philip Race <philip.race at oracle.com> 
> wrote:
>
>
>
>     On 8/11/25 9:20 AM, Daniel Gredler wrote:
>     > Hi all,
>     >
>     > I was thinking of taking a stab at?JDK-4138921 [1], and I have a
>     > couple of questions.
>     >
>     > First, there is a related API oddity in that null FontRenderContext
>     > parameters passed to the TextLayout constructors cause a
>     > NullPointerException, rather than an IllegalArgumentException (like
>     > all other parameters). Can this behavior also be changed?
>
>     None of these are documented .. they all should be.
>
>     It is a bit odd that frc is the only one not explicitly checked so
>     the
>     NPE is just what 'happens'.
>     I'd be reluctant to change the NPE without a good reason and I'm
>     half-wondering if a null FRC was
>     supposed to default to a default FRC ?? But somewhere along the
>     line the
>     implementation changed.
>     I'd say just specify what happens for complete compatibility.
>
>     >
>     > Second, changing all three TextLayout constructors to accept empty
>     > strings sort of implies that we should?also allow empty strings in
>     > AttributedString instances (this is currently only allowed if the
>     > attribute map is empty). Is it OK to change this behavior as well?
>
>     I don't think I ever understood why this was dis-allowed on
>     TextLayout.
>     Perhaps it was to prevent some incorrect usage from ever slipping
>     into
>     being acceptable ?
>
>     AttributedString is part of the java.base module, I don't have any
>     say
>     over that, although in the very beginning
>     there was a decent overlap in the people working on that and
>     TextLayout etc.
>     I'd start by asking Naoto (cc'ed).
>
>     -phil.
>
>     >
>     > Let me know your thoughts!
>     >
>     > Daniel
>     >
>     > [1] https://bugs.openjdk.org/browse/JDK-4138921
>     >
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250821/c51e5060/attachment-0001.htm>

From prr at openjdk.org  Fri Aug 22 05:54:55 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 05:54:55 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:

> 48:  * @summary URL.getContent() should return SoundClip for supported formats
> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
> 50:  */

I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2292765283

From psadhukhan at openjdk.org  Fri Aug 22 06:01:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Aug 2025 06:01:57 GMT
Subject: RFR: 8365425: [macos26]
 javax/swing/JInternalFrame/8160248/JInternalFrameDraggingTest.java fails on
 macOS 26
In-Reply-To: <y6RrXWj5oMGZHBAYDTfx_cPLyHh1u4MwF48PDqlgbCc=.6feb0dd6-9eb2-401f-8822-2180b858251f@github.com>
References: <XGdWYpy0rTrD8MEBggdIMSk8NJrM8k7yVGxeAZd4q4s=.92c4e962-34c1-4e7b-8bf2-a4fe133bff40@github.com>
 <dDK1UhX6KoY_mKZfY8u0JXBGADWvqdVCv_JQOhG6k50=.231288f7-ee29-40c5-aa0b-8bcfa1477d83@github.com>
 <-U-DcYDioW8P0vJb1nX1tfKlHF4c-ndN0dh8ZkAr54Q=.2df89367-d6a5-40c8-b804-98bed02fd32b@github.com>
 <WfxqbDS4j_eKboxayl-e06go3Q9vq0ADI4DWCZRJy40=.5437c760-2288-43e8-8638-4e615b0b0852@github.com>
 <y6RrXWj5oMGZHBAYDTfx_cPLyHh1u4MwF48PDqlgbCc=.6feb0dd6-9eb2-401f-8822-2180b858251f@github.com>
Message-ID: <sWhg9FlCwK8Rw5OiP1SAf2uokWsMwXMEd1fE0Z4bYxQ=.55f212c1-f6f2-49b7-870e-44177243d4f0@github.com>

On Thu, 21 Aug 2025 18:05:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I guess you are right..I am not able to get the artifacts drawn into the BI with this...With createScreenCapture I could get so I reverted to the tolerance check
> 
> That because you have to set float transform for that rendering, to reproduce the artifacts, for screen it is covered by the Dsun.java2d.uiScale in the header of the test. There is no difference between rendering to the screen vs rendering to BI.

How specifically could you suggest for my future reference?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26833#issuecomment-3213137695

From dholmes at openjdk.org  Fri Aug 22 06:38:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Aug 2025 06:38:56 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <GGszb14v2jX1mI4BbHtgkXQDlgFehKYtLl3yUr0zX40=.1952e76e-0a5c-4be9-944a-505f84d89624@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

@prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2292836043

From psadhukhan at openjdk.org  Fri Aug 22 06:50:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Aug 2025 06:50:55 GMT
Subject: RFR: 8365615: Improve JMenuBar/RightLeftOrientation.java
In-Reply-To: <XxNYwd8AnjCdUUQTHNWkeSF89KE7-ruCiwVIpsGUCjM=.c4090af6-c428-41b1-93ae-5380a0f78795@github.com>
References: <XxNYwd8AnjCdUUQTHNWkeSF89KE7-ruCiwVIpsGUCjM=.c4090af6-c428-41b1-93ae-5380a0f78795@github.com>
Message-ID: <F2XPYGVragTtzdnbJznutBArQpyyaoqb0p-_7DEvQNw=.1fffef4f-3712-4914-aed0-9bd49e04fa30@github.com>

On Fri, 15 Aug 2025 16:46:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Position the two frames with menu bars in left-to-right and right-to-left orientations below the frame that allows changing the look and feel.
> 
> Additionally, amend the instructions and refactor the code, show an error message to the tester if setting L&F fails.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26803#pullrequestreview-3143297266

From psadhukhan at openjdk.org  Fri Aug 22 06:55:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Aug 2025 06:55:55 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid [v2]
In-Reply-To: <EdnDFGYm2AkEcZ9EVZGZm3C2q6wqJUr7KAdvf_4ihgo=.6a1c6b5c-ae11-40ce-8440-08f0a9b3d963@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
 <EdnDFGYm2AkEcZ9EVZGZm3C2q6wqJUr7KAdvf_4ihgo=.6a1c6b5c-ae11-40ce-8440-08f0a9b3d963@github.com>
Message-ID: <-fXn9fNbdp2B5yLBojUJTaWCarprhm_VaSQG3JU9eFU=.367103ea-489f-49dd-ab8d-4150e7cfaa0b@github.com>

On Fri, 22 Aug 2025 03:36:24 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated the Bean Property description with meaningful string for JTable.setShowGrid.
>> 
>> Pleas review and let me know your suggestions if any.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Upadted based on suggesion

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26857#pullrequestreview-3143308556

From psadhukhan at openjdk.org  Fri Aug 22 07:16:54 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 22 Aug 2025 07:16:54 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw
 exception for negative image index [v2]
In-Reply-To: <EVI-lhlzW_6j3WBBqcnImUFtJG2N8-4RGvOCsvt5wO0=.842ee3a8-f3bd-4482-92f3-54ff06d31c4e@github.com>
References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
 <EVI-lhlzW_6j3WBBqcnImUFtJG2N8-4RGvOCsvt5wO0=.842ee3a8-f3bd-4482-92f3-54ff06d31c4e@github.com>
Message-ID: <ZvX8PVuIudOYxf4h4BMTa9md76iS2CYBMrk-F9a_zro=.d1f0651c-9244-453c-9a4b-b4348dc92beb@github.com>

On Thu, 21 Aug 2025 04:58:12 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> We need to throw appropriate exception when we pass invalid image index values to ImageReader.getImageTypes().
>> We throw IOOBE in all other plugins except JPEG, Added appropriate check to throw IOOBE when JpegImageReader has invalid image index.
>
> Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Update test to handle all regression cases
>  - Add checks at other places also
>  - Merge remote-tracking branch 'upstream/master' into jpeg_getImageTypes
>  - Check only for negative index
>  - 8364135: JPEGImageReader.getImageTypes() should throw exception for non-zero image index

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 396:

> 394:     private void checkNegativeImageIndex(int imageIndex) {
> 395:         if (imageIndex < minIndex) {
> 396:             throw new IndexOutOfBoundsException("imageIndex < " + minIndex);

Should we irrespectively throw IOBE or check for `seekForwardOnly` before throwing the exception

https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/imageio/ImageReader.java#L228-L235

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26522#discussion_r2292918680

From tr at openjdk.org  Fri Aug 22 07:38:02 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 22 Aug 2025 07:38:02 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v10]
In-Reply-To: <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
 <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
Message-ID: <sVkpBCn-i1DeocWXvAT4aPaVxjUZke1qgvG1MDq9Yag=.7b632437-de7e-49e1-9c30-85a6f943863b@github.com>

On Mon, 9 Dec 2024 09:56:15 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731)
>> 
>> This is tracked in JBS as
>> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731)
>> 
>> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input)
>> 
>> `alt` is not an attribute of the `input` element.
>> 
>> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : 
>> 
>>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ...
>> 
>> This feature is not implemented in `FormView.java`.
>> 
>> ??  ~~This also affects the HTML 32 DTD~~
>> 
>> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138)
>> 
>> Left before the patch and right after the patch.
>> 
>> 
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import javax.swing.JEditorPane;
>> import javax.swing.JFrame;
>> import javax.swing.JScrollPane;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.Document;
>> import javax.swing.text.html.HTMLEditorKit;
>> import javax.swing.text.html.StyleSheet;
>> 
>> public class HTMLAddsSupportAltInputTag {
>>   public static void main(String[] args) {
>>     new HTMLAddsSupportAltInputTag();
>>   }
>>   
>>   public HTMLAddsSupportAltInputTag() {
>>     SwingUtilities.invokeLater(new Runnable(){
>>       public void run(){
>>         JEditorPane jEditorPane = new JEditorPane();
>>         jEditorPane.setEditable(false);
>>         JScrollPane scrollPane = new JScrollPane(jEditorPane);
>>         HTMLEditorKit kit = new HTMLEditorKit();
>>         jEditorPane.setEditorKit(kit);
>>         StyleSheet styleSheet = kit.getStyleSheet();
>>         styleSheet.addRule("""
>>             body {
>>                 color: #000;
>>                 font-family:times;
>>                 margin: 4px;
>>             }
>>             """);
>>         String htmlString = """
>>             <html>
>>                 <body>
>>                     <input type=image name=point src="file:oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>>                     <p>
>>                     <input type=image name=point src="file:none_ora...
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge master
>  - JDK-8314731 : Remove all indentations accidentally introduced by the previous commit.
>  - Merge master
>  - Merge master
>  - jdk-8314731 : FormView Alt Support.
>    
>    FormView.java :
>    - revert ALL unrelated changing to formatting.
>    
>    bug8314731.java :
>    - Fix the test description.
>    - Change where the user interface is created.
>    - Add a finall block to be sure the Frame is disposed.
>    - Replace "testPassed" with "testFailed".
>  - Merge master
>  - Replaces this title with "alt attribute test in HTML image type input".
>    
>    Moves this test to /jdk/test/jdk/javax/swing/text/html.
>  - bug8314731.java : Corrects the CopyRight date.
>  - FormView.java :
>    Removes a whitespace
>    
>    bug8314731.java :
>    Adds a newline at end of file.
>  - getMaximumSpan(int axis) method
>    doc -> Not used
>    
>    mouseReleased(MouseEvent evt) method
>    elem and hdoc -> not used
>    return -> could be removed, method returns void
>    
>    loadElementDataIntoBuffer(Element elem, StringBuilder buffer) method
>    value != null -> name can't be null at this point
>    
>    getInputElementData(AttributeSet attr) method
>    value = null -> Already set at null
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/69e664de...9b423808

Update copyright year.

test/jdk/javax/swing/text/html/bug8314731.java line 35:

> 33: import java.awt.Container;
> 34: import java.awt.Dimension;
> 35: import java.lang.reflect.InvocationTargetException;

Can be removed.

test/jdk/javax/swing/text/html/bug8314731.java line 68:

> 66:             SwingUtilities.invokeAndWait(new Runnable() {
> 67:                 public void run() {
> 68:                     jf.dispose();

Check if `jf` is not `null ` and then dispose

test/jdk/javax/swing/text/html/bug8314731.java line 104:

> 102:         jEditorPane.setText(htmlString);
> 103: 
> 104:         jf.getContentPane().add(scrollPane, BorderLayout.CENTER);

Suggestion:

        jf.add(scrollPane, BorderLayout.CENTER);

test/jdk/javax/swing/text/html/bug8314731.java line 126:

> 124:         return false;
> 125:     }
> 126: }

Extra blank line is missing.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-3143412871
PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2292935476
PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2292932073
PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2292960806
PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2292964065

From duke at openjdk.org  Fri Aug 22 09:18:52 2025
From: duke at openjdk.org (Francesco Andreuzzi)
Date: Fri, 22 Aug 2025 09:18:52 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed
In-Reply-To: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
Message-ID: <MUKTHaA4ROJhhMtwcdfct5BcnE1upT4gce5yDAaKsa8=.c83468f7-2eab-4ce2-afcf-5f9ec51cf706@github.com>

On Fri, 22 Aug 2025 03:53:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.
> 
> This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
> which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
> At start `leftComponent = Red, rightComponent = Green`
> 
> before `super.addImpl` is called in `JSplitPane.addImpl` the 
> 
> `leftComponent = Green, rightComponent = Green`
> 
> After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
> leftComponent = null.
> 
> so we have
> leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
> so we have now
> leftComponent = null, rightComponent = null
> 
> so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.
> 
> So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components

test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java line 71:

> 69:                 sb.append(rightButton.getText());
> 70:             }
> 71:             System.out.println(sb.toString());

Is the `toString` needed here?
Suggestion:

            System.out.println(sb);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26893#discussion_r2293180156

From duke at openjdk.org  Fri Aug 22 09:27:01 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 09:27:01 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v26]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <96ewX6qgrmquGaFzraKPCSOPjv9MDo04cHdVOUAZ7rM=.3eba53a0-eba0-4a59-bbb4-cd8731acf2bf@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers missed frames in the middle of screen
 - Uses KeyboardFocusManager instead of FocusManager
 - Reverted not needed changes
 - Updates copyright years
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers frames in the middle of the screen
 - Releses latch in case of null ancestor or resizing component
 - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - ... and 30 more: https://git.openjdk.org/jdk/compare/ab9a8cc1...7b46aef4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/9358a9d8..7b46aef4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=24-25

  Stats: 6465 lines in 270 files changed: 3082 ins; 2414 del; 969 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

PR: https://git.openjdk.org/jdk/pull/25971

From duke at openjdk.org  Fri Aug 22 09:27:26 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 09:27:26 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v12]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <QbryC3R3z9-TSttz1SXxvhBqqA4CKK38pQ7x_MlWohM=.612555eb-c05a-4ef0-bee8-fff2d5a289d4@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 67 additional commits since the last revision:

 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers missed frames in the middle of screen
 - Uses KeyboardFocusManager instead of FocusManager
 - Reverted not needed changes
 - Updates copyright years
 - Merge branch 'openjdk:master' into jdk-8158801
 - Centers frames in the middle of the screen
 - Merge branch 'openjdk:master' into jdk-8360498
 - Merge branch 'pr/25971' into jdk-8360498
 - ... and 57 more: https://git.openjdk.org/jdk/compare/ea0b50e2...ce0d3527

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/ecf7d3cf..ce0d3527

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=10-11

  Stats: 12173 lines in 474 files changed: 7460 ins; 3042 del; 1671 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From duke at openjdk.org  Fri Aug 22 09:29:01 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 09:29:01 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v25]
In-Reply-To: <IGmP0uL5mWS23T2FUnrOf-Ivsru9FZQQWom1snZq9t8=.3f8798c0-363a-44b7-b501-b11a88d96019@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
 <IGmP0uL5mWS23T2FUnrOf-Ivsru9FZQQWom1snZq9t8=.3f8798c0-363a-44b7-b501-b11a88d96019@github.com>
Message-ID: <x0kwQFF2iy5E0-ZHbsIdx-yUMk88uEgdpepF8PwynnE=.fcc0310b-6a9b-44e4-8abb-c4c416ce70d4@github.com>

On Tue, 19 Aug 2025 17:22:01 GMT, Manukumar V S <mvs 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 39 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Centers missed frames in the middle of screen
>>  - Uses KeyboardFocusManager instead of FocusManager
>>  - Reverted not needed changes
>>  - Updates copyright years
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Centers frames in the middle of the screen
>>  - Releses latch in case of null ancestor or resizing component
>>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>>    
>>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>>    
>>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/30e3294f...9358a9d8
>
> test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 67:
> 
>> 65:         frame.getContentPane().setLayout(new BoxLayout(frame.getContentPane(), BoxLayout.Y_AXIS));
>> 66:         frame.setSize(200, 200);
>> 67:         frame.setLocationRelativeTo(null);
> 
> Are we disposing this frame somewhere(it's applicable to all the test files)?

@manukumarvs in the original test, frames are not disposed. I will include disposing frame after testing the heavyweight component.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2293204208

From azvegint at openjdk.org  Fri Aug 22 10:29:57 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Aug 2025 10:29:57 GMT
Subject: RFR: 8364768: JDK javax.imageio ImageWriters do not all flush the
 output stream [v2]
In-Reply-To: <iRUIn9l-lizy2tZpUIYrh3XVfJbMgTHlEvzEhynh4TQ=.c242e39c-156a-409d-abce-0848185160b7@github.com>
References: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
 <iRUIn9l-lizy2tZpUIYrh3XVfJbMgTHlEvzEhynh4TQ=.c242e39c-156a-409d-abce-0848185160b7@github.com>
Message-ID: <suUbqtnxpv2LllNTHtKTOU_QGub7tm_gn5TgEL7GPtw=.b95ef43c-70a5-4a27-9e9f-4cc9a4ea875c@github.com>

On Thu, 21 Aug 2025 19:14:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> 4 of the 6 JDK ImageWriters flush the stream at the end of writing. 2 (TIFF and GIF) do not. 
>> 
>> This will matter if you are using a caching ImageOutputStream.
>> 
>> This fix makes it consistent.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364768

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26703#pullrequestreview-3143982088

From djgredler at gmail.com  Fri Aug 22 11:38:29 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Fri, 22 Aug 2025 13:38:29 +0200
Subject: JDK-4138921: TextLayout handling of empty strings
In-Reply-To: <981f8152-dec9-4b04-8dcf-62b0a198ab54@oracle.com>
References: <CAPA+ug6A88qeG+bRC3UAvvkp67jALtQXEsF0OMxK=WnsXbxQUw@mail.gmail.com>
 <994c74d6-2eb4-4588-ad6a-25529b68bd1e@oracle.com>
 <CAPA+ug7fWrp3JUq_VHh+ohpMoGfMvjm-JeXS7gVRht0zfn7Gxg@mail.gmail.com>
 <981f8152-dec9-4b04-8dcf-62b0a198ab54@oracle.com>
Message-ID: <CAPA+ug6CfdY0E6=P33rJ9D29eYdXGL1W0PQiuD7TTU0ieJUTQg@mail.gmail.com>

Ok, thanks for elaborating. I'll submit a PR for review soon.

Take care,

Daniel



On Fri, Aug 22, 2025 at 7:11?AM Philip Race <philip.race at oracle.com> wrote:

> I suppose they won't be that surprised, since it has been the behaviour
> already.
>
> I think it unlikely that an app throws null at TextLayout on purpose
> knowing it won't work.
> That's the realm of conformance tests, not real programs, so I'm not
> terribly worried about that.
>
> What I was getting at, in part, is that it seems possible to me that this
> was not checked
> because the thinking was in this case, null was allowed and meant a
> default FRC.
> If we change the exception type it makes it one step harder if we find out
> that's where we want to end up.
> I don't see a lot of supporting evidence for that, so I am just throwing
> it out there.
> It could also be that it was added at a different time by some one not
> following the rest of the API
>
> But this point is minor. The big question is around the empty string.
> It certainly was a pain for me when doing printing when I had needed to
> use TextLayout
> and had to be careful of this case.
>
> It would be 'ideal' if "" was just silently handled and didn't cause
> issues for existing code - other than conformance tests
> which shouldn't be testing unspecified behaviour anyway.
>
> -phil.
>
> On 8/19/25 4:29 AM, Daniel Gredler wrote:
>
> Hi Phil,
>
> >> First, there is a related API oddity in that null FontRenderContext
> >> parameters passed to the TextLayout constructors cause a
> >> NullPointerException, rather than an IllegalArgumentException (like
> >> all other parameters). Can this behavior also be changed?
>
> > It is a bit odd that frc is the only one not explicitly checked so the
> > NPE is just what 'happens'.
> > I'd be reluctant to change the NPE without a good reason [...]
> > I'd say just specify what happens for complete compatibility.
>
> I guess I'm hesitant to promote an "accidental" NPE to official behavior
> here, when all other null parameter values are handled with an explicit
> IAE. This inconsistency is going to surprise developers, and avoiding that
> surprise would be ideal. How likely is it that adding an explicit
> IAE-generating null FRC check here will break existing code?
>
> Take care,
>
> Daniel
>
>
> On Mon, Aug 11, 2025 at 7:12?PM Philip Race <philip.race at oracle.com>
> wrote:
>
>>
>>
>> On 8/11/25 9:20 AM, Daniel Gredler wrote:
>> > Hi all,
>> >
>> > I was thinking of taking a stab at JDK-4138921 [1], and I have a
>> > couple of questions.
>> >
>> > First, there is a related API oddity in that null FontRenderContext
>> > parameters passed to the TextLayout constructors cause a
>> > NullPointerException, rather than an IllegalArgumentException (like
>> > all other parameters). Can this behavior also be changed?
>>
>> None of these are documented .. they all should be.
>>
>> It is a bit odd that frc is the only one not explicitly checked so the
>> NPE is just what 'happens'.
>> I'd be reluctant to change the NPE without a good reason and I'm
>> half-wondering if a null FRC was
>> supposed to default to a default FRC ?? But somewhere along the line the
>> implementation changed.
>> I'd say just specify what happens for complete compatibility.
>>
>> >
>> > Second, changing all three TextLayout constructors to accept empty
>> > strings sort of implies that we should also allow empty strings in
>> > AttributedString instances (this is currently only allowed if the
>> > attribute map is empty). Is it OK to change this behavior as well?
>>
>> I don't think I ever understood why this was dis-allowed on TextLayout.
>> Perhaps it was to prevent some incorrect usage from ever slipping into
>> being acceptable ?
>>
>> AttributedString is part of the java.base module, I don't have any say
>> over that, although in the very beginning
>> there was a decent overlap in the people working on that and TextLayout
>> etc.
>> I'd start by asking Naoto (cc'ed).
>>
>> -phil.
>>
>> >
>> > Let me know your thoughts!
>> >
>> > Daniel
>> >
>> > [1] https://bugs.openjdk.org/browse/JDK-4138921
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250822/7cde1b0e/attachment-0001.htm>

From duke at openjdk.org  Fri Aug 22 12:01:52 2025
From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac)
Date: Fri, 22 Aug 2025 12:01:52 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed
In-Reply-To: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
Message-ID: <kZr12nL4xjTjLhIkh6KL_DQzYdl0E9NKEnbhCe3f19c=.13decf87-ccf8-4ecf-92fc-458004db3e80@github.com>

On Fri, 22 Aug 2025 03:53:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.
> 
> This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
> which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
> At start `leftComponent = Red, rightComponent = Green`
> 
> before `super.addImpl` is called in `JSplitPane.addImpl` the 
> 
> `leftComponent = Green, rightComponent = Green`
> 
> After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
> leftComponent = null.
> 
> so we have
> leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
> so we have now
> leftComponent = null, rightComponent = null
> 
> so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.
> 
> So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components

src/java.desktop/share/classes/javax/swing/JSplitPane.java line 374:

> 372:         ComponentOrientation curOrn = this.getComponentOrientation();
> 373:         super.setComponentOrientation(orientation);
> 374:         Component comp = null;

Rename comp to tmp? Or swap?
And also reduce its scope by moving the declaration where it is assigned, this makes the code clearer. 
Maybe use var even?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26893#discussion_r2293530774

From djgredler at gmail.com  Fri Aug 22 12:03:38 2025
From: djgredler at gmail.com (Daniel Gredler)
Date: Fri, 22 Aug 2025 14:03:38 +0200
Subject: Possible BufferedImage.getRGB optimization
Message-ID: <CAPA+ug6j4MicbR-c8xQxwb_r3P5VVPa1ZPCdE=u8BQLYEDeyFQ@mail.gmail.com>

Hi all,

`BufferedImage.getRGB(int, int, int, int, int[], int, int)` is often used
for processing of individual image pixels. A common pattern is to loop
through each row of pixels, calling this method once per row to populate
the row pixel `int[]` and then process it.

There are many types of `BufferedImage`, but one of the most common types
is `TYPE_INT_ARGB`. Based on a quick search on GitHub, about one third of
all BufferedImages are of this type [1]. This is also the representation
which `BufferedImage.getRGB(int, int, int, int, int[], int, int)` uses for
its output.

I think there may be an opportunity here (in `BufferedImage.getRGB(int,
int, int, int, int[], int, int)`) to skip the pixel-by-pixel color model
conversion if the `BufferedImage` is already of type `TYPE_INT_ARGB`, which
is relatively common. See here [2] for what this optimization could look
like.

In my local testing, a simple test program [3] went from running in 220
seconds without the change to running in 7 seconds with the change.
Separately, a real-world program which uses the row-by-row pixel access
pattern went from running in 45 seconds to running in 29 seconds.

Does this look like a good change to those of you who know this part of the
code? Am I missing something that might make this dangerous or undesirable?
Is it making too many assumptions? I know this area is fraught with gotchas
-- color models, color spaces, strides, etc.

Thanks!

Daniel

---

[1]
BufferedImage.TYPE_CUSTOM: 2k
BufferedImage.TYPE_INT_RGB: 114k
BufferedImage.TYPE_INT_ARGB: 93k << 35%
BufferedImage.TYPE_INT_ARGB_PRE: 5k
BufferedImage.TYPE_INT_BGR: 4k
BufferedImage.TYPE_3BYTE_BGR: 10k
BufferedImage.TYPE_4BYTE_ABGR: 9k
BufferedImage.TYPE_4BYTE_ABGR_PRE: 2k
BufferedImage.TYPE_USHORT_565_RGB: 1k
BufferedImage.TYPE_USHORT_555_RGB: 1k
BufferedImage.TYPE_BYTE_GRAY: 11k
BufferedImage.TYPE_USHORT_GRAY: 2k
BufferedImage.TYPE_BYTE_BINARY: 5k
BufferedImage.TYPE_BYTE_INDEXED: 3k
Total: 262k

[2]
https://github.com/gredler/jdk/commit/b98f6cdf7573b7e89067c757890193517aeb472e

[3]
public final class PerfTest {
    public static void main(final String[] args) {
        int w = 1_000;
        int h = 1_000;
        int accumulator = 0;
        BufferedImage image = new BufferedImage(w, h,
BufferedImage.TYPE_INT_ARGB);
        int[] row = new int[w];
        long start = System.currentTimeMillis();
        for (int i = 0; i < 100_000; i++) {
            for (int y = 0; y < h; y++) {
                image.getRGB(0, y, w, 1, row, 0, w);
                accumulator += row[i % w];
            }
        }
        long end = System.currentTimeMillis();
        System.out.println("Total time: " + ((end - start) / 1_000) + "
seconds");
        System.out.println("Accumulator: " + accumulator);
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250822/ed166d33/attachment.htm>

From ayang at openjdk.org  Fri Aug 22 16:10:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 16:10:58 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
Message-ID: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>

On Wed, 20 Aug 2025 17:05:59 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update testing.md, remove makefile link, fix bad text

> Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480.

I identified some cases that doesn't follow this. Unclear whether they are intentional.

test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:

> 34:  * @build jdk.test.whitebox.WhiteBox
> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation

Why not `480` in this case?

test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 40:

> 38:  * @requires vm.cds
> 39:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 40:  * @run driver/timeout=8000 LotsOfSyntheticClasses

I was expecting `500 * 4 = 2000`, instead of `8000` here.

test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31:

> 29:  * @compile SuspendResume2.java
> 30:  * @run driver jdk.test.lib.FileInstaller . .
> 31:  * @run main/othervm/native/timeout=700

Why `700` instead of `480` in this file?

test/jdk/java/rmi/transport/dgcDeadLock/DGCDeadLock.java line 59:

> 57: public class DGCDeadLock implements Runnable {
> 58:     final static public int HOLD_TARGET_TIME = 25000;
> 59:     public static final double TEST_FAIL_TIME = (HOLD_TARGET_TIME + 30000) * Math.max(TestLibrary.getTimeoutFactor(), 4);

Why `max(...)`? If it's for backwards compatibility, shouldn't it be `(HOLD_TARGET_TIME + 30000)  * 4 * TestLibrary.getTimeoutFactor()`?

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 60:

> 58:  * @comment skip running this test on 32 bit VM
> 59:  * @requires vm.bits == "64"
> 60:  * @run testng/othervm/timeout=960 -Xmx2g WhiteBoxResizeTest

Why not `480`?

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 34:

> 32:  * @build com.foobar.Utils
> 33:  *        com.bar.*
> 34:  * @run junit/othervm/timeout=960 -Djava.locale.providers=CLDR,SPI LocaleNameProviderTest

Why not `480`?

test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 49:

> 47:  * @library /test/lib /test/jdk
> 48:  * @modules jdk.jfr/jdk.jfr.internal.test
> 49:  * @run main/othervm/timeout=960 -XX:TLABSize=2k jdk.jfr.event.oldobject.TestObjectDescription

Why not `480`?

test/jdk/tools/jpackage/share/InstallDirTest.java line 69:

> 67:  * @compile -Xlint:all -Werror InstallDirTest.java
> 68:  * @requires (jpackage.test.SQETest != null)
> 69:  * @run main/othervm/timeout=4000 -Xmx512m jdk.jpackage.test.Main

Why more than `4x` in this file?

test/langtools/jdk/jshell/HangingRemoteAgent.java line 38:

> 36: class HangingRemoteAgent extends RemoteExecutionControl {
> 37: 
> 38:     private static final int TIMEOUT = (int)(2000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

why not `Utils.TIMEOUT_FACTOR`?

test/langtools/jdk/jshell/UITesting.java line 148:

> 146:     }
> 147: 
> 148:     private static final long TIMEOUT = (long) (60_000 * Double.parseDouble(System.getProperty("test.timeout.factor", "1.0")));

Why not `Utils.TIMEOUT_FACTOR`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3144985957
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294077875
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294085201
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294089550
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294108202
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294110136
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294113670
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294116148
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294119800
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294128741
PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294129243

From javalists at cbfiddle.com  Fri Aug 22 16:12:27 2025
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 22 Aug 2025 09:12:27 -0700
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed
In-Reply-To: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
Message-ID: <20BC7C12-5783-4F85-9F84-216F30B65AD9@cbfiddle.com>

Don?t you also have to update the components in the layout manager?


From duke at openjdk.org  Fri Aug 22 16:15:09 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 16:15:09 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v25]
In-Reply-To: <SZDyrTWJpcF15gwGEOdmFBa1Dp4-g6kDiKaJVy8StrQ=.a9b2d743-1106-4219-91bb-6357ca7d9ee2@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
 <SZDyrTWJpcF15gwGEOdmFBa1Dp4-g6kDiKaJVy8StrQ=.a9b2d743-1106-4219-91bb-6357ca7d9ee2@github.com>
Message-ID: <8N6lmaTEpGGsUvm5ukwCMZMC5o5QGxw2L5p-B2cSVNw=.1a44ce5f-f976-4f59-aa9e-4f73825a52fb@github.com>

On Wed, 20 Aug 2025 13:12:43 GMT, Prasanta Sadhukhan <psadhukhan 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 39 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Centers missed frames in the middle of screen
>>  - Uses KeyboardFocusManager instead of FocusManager
>>  - Reverted not needed changes
>>  - Updates copyright years
>>  - Merge branch 'openjdk:master' into jdk-8158801
>>  - Centers frames in the middle of the screen
>>  - Releses latch in case of null ancestor or resizing component
>>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>>    
>>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>>  - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java
>>    
>>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/8535362b...9358a9d8
>
> test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 83:
> 
>> 81:         frame.add(cb);
>> 82:         propagateAWTControls(frame);
>> 83:         frame.setLocationRelativeTo(null);
> 
> setLocationRelativeTo called twice

Done.

> test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 109:
> 
>> 107:         propagateAWTControls(frame);
>> 108:         frame.setLocationRelativeTo(null);
>> 109:         frame.setVisible(true);
> 
> same here and setVisible() also called twice

Done.

> test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 86:
> 
>> 84:         }
>> 85:         propagateAWTControls(frame);
>> 86:         frame.setLocationRelativeTo(null);
> 
> same here

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2294142587
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2294142232
PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2294141744

From duke at openjdk.org  Fri Aug 22 16:41:14 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 16:41:14 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v27]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <x2jPV0uO3TzlU52I9HcFxrz3BwUsvFkwOzdH9OpdnG8=.0cb084d7-6046-4e36-ab31-c53bbb879dbf@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision:

 - Disposes frames after each AWT component test
 - Removes redundant code for centring frames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/7b46aef4..a1788ae0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=25-26

  Stats: 12 lines in 5 files changed: 7 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

PR: https://git.openjdk.org/jdk/pull/25971

From duke at openjdk.org  Fri Aug 22 16:41:15 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 16:41:15 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v25]
In-Reply-To: <x0kwQFF2iy5E0-ZHbsIdx-yUMk88uEgdpepF8PwynnE=.fcc0310b-6a9b-44e4-8abb-c4c416ce70d4@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <YOPkrsvNzfxwRMvlFiUeIxUKsdpI-xVeTBTKM2pJIHk=.57b15ff8-ed57-4be5-810d-b80f62131aea@github.com>
 <IGmP0uL5mWS23T2FUnrOf-Ivsru9FZQQWom1snZq9t8=.3f8798c0-363a-44b7-b501-b11a88d96019@github.com>
 <x0kwQFF2iy5E0-ZHbsIdx-yUMk88uEgdpepF8PwynnE=.fcc0310b-6a9b-44e4-8abb-c4c416ce70d4@github.com>
Message-ID: <PsaCtqKQMpcoAqL3hWjMeVJA_Mx4LoJFMfjyZfgcDKs=.4c59356c-34ed-4d10-a8cb-09c7649969a3@github.com>

On Fri, 22 Aug 2025 09:26:44 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> test/jdk/java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java line 67:
>> 
>>> 65:         frame.getContentPane().setLayout(new BoxLayout(frame.getContentPane(), BoxLayout.Y_AXIS));
>>> 66:         frame.setSize(200, 200);
>>> 67:         frame.setLocationRelativeTo(null);
>> 
>> Are we disposing this frame somewhere(it's applicable to all the test files)?
>
> @manukumarvs in the original test, frames are not disposed. I will include disposing frame after testing the heavyweight component.

It seems there are two types of testing, some use one frame (GlassPane) and others uses multiple frames. I have updated code to dispose of multiple frames. Currently testing my changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2294188592

From duke at openjdk.org  Fri Aug 22 16:44:40 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 16:44:40 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v13]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <GJ_gd_pFkwFfMu5yfVhVXbW9jKK3dhGQvJwmPjP_Z0M=.cba32ffd-3eda-4582-82bb-083eab2d7e7b@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8360498
 - Merge branch 'pr/25971' into jdk-8360498
 - Removes extra white lines
 - Merge branch 'pr/25971' into jdk-8360498
 - Merge branch 'openjdk:master' into jdk-8360498
 - Revert "Accept color differences to less or equal to 15"
   
   This reverts commit a98db3e22781088eccd95912697853355f22645e.
 - Accept color differences to less or equal to 15
 - Changes the look and feel to the default Metal
 - ... and 19 more: https://git.openjdk.org/jdk/compare/7b46aef4...b2a35b87

-------------

Changes: https://git.openjdk.org/jdk/pull/26625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=12
  Stats: 44 lines in 7 files changed: 30 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From duke at openjdk.org  Fri Aug 22 16:54:12 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 22 Aug 2025 16:54:12 GMT
Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v14]
In-Reply-To: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
References: <OSBIAcBZSrjXy8U2PjkHUlyigIpR4askAoAxS0edXx4=.3781d5da-1814-4fd1-b3f8-c5001b856f7b@github.com>
Message-ID: <Nngo0-KOBLe3Mus9hr5j9ENPXZzxpKPK7Hnu5wli2lw=.0e7922d4-a9bd-433c-9056-30cb1669a63e@github.com>

> This PR will consolidate fixes of the following bugs:
> 
> https://bugs.openjdk.org/browse/JDK-8361188
> https://bugs.openjdk.org/browse/JDK-8361189
> https://bugs.openjdk.org/browse/JDK-8361190
> https://bugs.openjdk.org/browse/JDK-8361191
> https://bugs.openjdk.org/browse/JDK-8361192
> https://bugs.openjdk.org/browse/JDK-8361193
> https://bugs.openjdk.org/browse/JDK-8361195
> 
> This PR depends on https://github.com/openjdk/jdk/pull/25971
> 
> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188)
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193
> 
> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191
> 
> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190

Khalid Boulanouare has updated the pull request incrementally with four additional commits since the last revision:

 - Removes not needed changes
 - Revert "Removes not needed changes"
   
   This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb.
 - Removes not needed changes
 - Removes extra white lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26625/files
  - new: https://git.openjdk.org/jdk/pull/26625/files/b2a35b87..2888ff38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625

PR: https://git.openjdk.org/jdk/pull/26625

From prr at openjdk.org  Fri Aug 22 17:20:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 17:20:57 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
Message-ID: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>

On Fri, 22 Aug 2025 05:51:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 50:
> 
>> 48:  * @summary URL.getContent() should return SoundClip for supported formats
>> 49:  * @run main/othervm/timeout=480 -Xmx128m AudioContentHandlers
>> 50:  */
> 
> I've looked at our CI and this test has run 80,000 times and only 10 of those have gone > 120 seconds (and only 2 > 145 seconds)
> Perhaps I'd see similar for other tests. But I need to hear test-specific reasons for the test-specific boost of 4x from what  I think (120) is the default to 480.
> Otherwise I'd prefer no change, or a small change, by maybe 1.5x not 4x, and we'll adjust the test when we see evidence that it is not enough.

> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.

I don't agree.
If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

I am also questioning whether such a time out was demonstrated for this test.
I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
I can send you my query off-line so you can check it. Maybe it is incomplete.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294258341

From prr at openjdk.org  Fri Aug 22 17:52:31 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 17:52:31 GMT
Subject: RFR: 8366002: Specification Update Needed: Beans.instantiate
 Serialized Object Loading Behavior
Message-ID: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>

Some text describing the Beans.instantiate lookup process existed only on the method that used the now removed AppletInitializer.
Since there are two other Beans.instantiate methods, we need to move that text to the remaining methods.

Note that one of the methods is also deprecated for removal, so it seems prudent to add it to both so that when the next to be removed method is gone, this problem doesn't recur.

-------------

Commit messages:
 - 8366002

Changes: https://git.openjdk.org/jdk/pull/26905/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26905&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366002
  Stats: 32 lines in 1 file changed: 32 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26905.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26905/head:pull/26905

PR: https://git.openjdk.org/jdk/pull/26905

From simonis at openjdk.org  Fri Aug 22 18:23:51 2025
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 22 Aug 2025 18:23:51 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v3]
In-Reply-To: <fjAUpU_OrpNKAJYV17IFpzxQB7CIRqJhHYRE0_JjEIs=.c6ec899a-3b3b-4fa8-be3d-4bde024abf88@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
 <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
 <fjAUpU_OrpNKAJYV17IFpzxQB7CIRqJhHYRE0_JjEIs=.c6ec899a-3b3b-4fa8-be3d-4bde024abf88@github.com>
Message-ID: <j7bAdyH2MMlrz1RmI6Vuj_7-wKxDD0ymY8BYwYvoeds=.132b39b3-896a-4475-8394-665d7b4d2f72@github.com>

On Thu, 21 Aug 2025 21:39:42 GMT, Phil Race <prr at openjdk.org> wrote:

> I already ran all our automated tests, and I'm not too surprised they pass, since they probably don't cover this as well as they should. 

Thanks!

> I think it would be possible and a good idea to add a test. All you need to do is find a font that definitely supports Khmer. 

I can use [`hb-subset`](https://man.archlinux.org/man/extra/harfbuzz-utils/hb-subset.1.en) to create a subset of the [KhmerOS](https://www.cambodia.org/fonts/) open source font (licensed under LGPL 2.1 or later) which will be just enough for the test and check that in along with the test. The subsetted font file will be 28kb. Would that be acceptable

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3215234306

From ayang at openjdk.org  Fri Aug 22 18:45:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 22 Aug 2025 18:45:53 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
Message-ID: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>

On Fri, 22 Aug 2025 17:18:40 GMT, Phil Race <prr at openjdk.org> wrote:

> or don't do it.

Adding `/timeout=480` is more or less don't do anything.

The default timeout (if omitting `/timeout=...`) is 120, so:

master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2294425045

From dgredler at openjdk.org  Fri Aug 22 19:01:50 2025
From: dgredler at openjdk.org (Daniel Gredler)
Date: Fri, 22 Aug 2025 19:01:50 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v3]
In-Reply-To: <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
 <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
Message-ID: <QfqVlwDEqrNX9NRREv6af0zowKKWYiEMaH8F4DbsBBc=.c24e67d4-5d22-404b-8f1f-9c52ede277c8@github.com>

On Tue, 19 Aug 2025 14:41:54 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### TL;DR
>> 
>> This is a fix for what I think is a regression since the introduction of HarfBuzz in JDK 9. The problem is that the algorithm which converts the glyph vector produced by the layout engine into a corresponding character vector (in `ExtendedTextSourceLabel::createCharinfo()`) still assumes that "*each glyph maps to a single character*". But this is not true any more with HarfBuzz and as this example demonstrates, can lead to improper clustering of characters which can result to bad line breaking decisions.
>> 
>> I ran the corresponding JTreg and JCK test on Linux but because this area is heavily dependent on the OS and concrete fonts I'd like to kindly ask you to run your internal test suites in this area if possible.  
>> 
>> In the following you can find a longer (maybe a bit too long :) description of this problem which I merely wrote for my own memory.
>> 
>> ### Full description
>> 
>> A customer reported a regression in JDK 9+ which leads to bad/wrong line breaks for text in the Khmer language. Khmer is a [complex script](https://en.wikipedia.org/wiki/Khmer_script) which was only added to the Unicode standard 3.0 in 1999 (in the [Unicode block U+1780..U+17FF](https://en.wikipedia.org/wiki/Khmer_(Unicode_block))) and I personally don't understand Khmer at all :)
>> 
>> Fortunately, the customer could provide a [simple reproducer](https://bugs.openjdk.org/secure/attachment/115218/KhmerTest.java) which I could further condense to the following example: "????????????????????????????" (according to Google translate, this means "*Requested but still denied*"). If we use OpenJDK's [`LineBreakMeasurer`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/font/LineBreakMeasurer.html) to layout that paragraph (notice that Khmer has no spaces between words) to fit within a specific "wrapping width", the output may look as follows with JDK 8 (the exact output depends on the font and the wrapping width):
>> 
>> Segment: ?????????? 0 10
>> Segment: ????????? 10 9
>> Segment: ???????? 19 8
>> Segment: ? 27 1
>> 
>> I ran with both, the logical [DIALOG](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Font.html#DIALOG) font or directly with `/usr/share/fonts/truetype/ttf-khmeros-core/KhmerOS.ttf` on Ubuntu 22.04 (on my system DIALOG will automatically fall back to the KhmerOS font for characters from the Khmer Unicode code block). I also tried with the [Noto Khmer](https://fonts.google.com/noto/specimen/Noto+Serif+Khmer) f...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added JTreg test to verify monotonically growing glyph character indices

Great write-up. I haven't followed all of the rabbit trails linked, but I think I understand the overall issue.

Regarding testing --

My understanding is that including any open source fonts in the tests requires a long licensing approval process and is best avoided. An alternative is to script the creation of a custom test font (see e.g. `GlyphVectorGsubTest`), but it might be tricky to get right in this case, where we're dealing with an unfamiliar language and so many substitutions.

One idea for testing would be to find all physical fonts which support Khmer at runtime (see e.g. `FormatCharAdvanceTest.getPhysicalFont(int)`, but with a `canDisplayUpTo` for the Khmer chars). Then for each supporting font, use the `LineBreakMeasurer` at a range of text widths (e.g. 100 - 500 pixels, at 10 pixel increments), and make sure that regardless of text width the measurer never leaves a single character on any line (except the last line, which would be OK). I know it's a bit hand-wavey, and quite black-box-ish, but it might be a good way to verify that the user-visible misbehavior that we're trying to fix is gone and doesn't resurface.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3215320748

From prr at openjdk.org  Fri Aug 22 19:41:52 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 19:41:52 GMT
Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to
 JDK 8 [v3]
In-Reply-To: <j7bAdyH2MMlrz1RmI6Vuj_7-wKxDD0ymY8BYwYvoeds=.132b39b3-896a-4475-8394-665d7b4d2f72@github.com>
References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com>
 <PTocBPJBLKKUBErU9JfxvSXXv4PGlSu9Ulaks6aFhlM=.eaa88078-ae61-4701-9094-42a1158238e6@github.com>
 <fjAUpU_OrpNKAJYV17IFpzxQB7CIRqJhHYRE0_JjEIs=.c6ec899a-3b3b-4fa8-be3d-4bde024abf88@github.com>
 <j7bAdyH2MMlrz1RmI6Vuj_7-wKxDD0ymY8BYwYvoeds=.132b39b3-896a-4475-8394-665d7b4d2f72@github.com>
Message-ID: <txznfeL21vzdoeBCAgJ1xhw2p6hQ42mprqCWNBfIOVc=.d0ec734e-8fc3-44b4-9098-ec66733a87d1@github.com>

On Fri, 22 Aug 2025 18:21:18 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> > I already ran all our automated tests, and I'm not too surprised they pass, since they probably don't cover this as well as they should.
> 
> Thanks!
> 
> > I think it would be possible and a good idea to add a test. All you need to do is find a font that definitely supports Khmer.
> 
> I can use [`hb-subset`](https://man.archlinux.org/man/extra/harfbuzz-utils/hb-subset.1.en) to create a subset of the [KhmerOS](https://www.cambodia.org/fonts/) open source font (licensed under LGPL 2.1 or later) which will be just enough for the test and check that in along with the test. The subsetted font file will be 28kb. Would that be acceptable

No. That won't be allowed. You aren't using your own IP.
I meant just use Font.canDisplayUpTo(String) on the physical fonts on the system until you find one that can that can render the entire string. This will work on Windows + Linux. Mac, unfortunately it will be less useful since all fonts will report they support Khmer. I would skip the test on Mac.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26825#issuecomment-3215420938

From prr at openjdk.org  Fri Aug 22 20:52:57 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 20:52:57 GMT
Subject: Integrated: 8364768: JDK javax.imageio ImageWriters do not all flush
 the output stream
In-Reply-To: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
References: <2vHV9jPgPWH0cPJKgMTdL0-tWrP5JWXUeTynVeofehQ=.378395ce-d883-4665-a2dd-b054b5c1e50b@github.com>
Message-ID: <aH-WMAp7cN2WMORH1IOZlhpb0Rp6jDPTso_wu-SpOLs=.fea80674-eee2-493c-8116-61081e1a4aa9@github.com>

On Fri, 8 Aug 2025 17:31:03 GMT, Phil Race <prr at openjdk.org> wrote:

> 4 of the 6 JDK ImageWriters flush the stream at the end of writing. 2 (TIFF and GIF) do not. 
> 
> This will matter if you are using a caching ImageOutputStream.
> 
> This fix makes it consistent.

This pull request has now been integrated.

Changeset: 603526b5
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/603526b55b5e9b6dfc9323d2cdc4a0b4d0f88a49
Stats:     78 lines in 3 files changed: 78 ins; 0 del; 0 mod

8364768: JDK javax.imageio ImageWriters do not all flush the output stream

Reviewed-by: psadhukhan, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/26703

From serb at openjdk.org  Fri Aug 22 22:16:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 22 Aug 2025 22:16:51 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid [v2]
In-Reply-To: <EdnDFGYm2AkEcZ9EVZGZm3C2q6wqJUr7KAdvf_4ihgo=.6a1c6b5c-ae11-40ce-8440-08f0a9b3d963@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
 <EdnDFGYm2AkEcZ9EVZGZm3C2q6wqJUr7KAdvf_4ihgo=.6a1c6b5c-ae11-40ce-8440-08f0a9b3d963@github.com>
Message-ID: <G3Xh78Mu84fGKskWMdDb7wFudddMUBYs_zablc-3Z8c=.6e2e917a-8f90-4184-9ab1-c1cff8811a4d@github.com>

On Fri, 22 Aug 2025 03:36:24 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated the Bean Property description with meaningful string for JTable.setShowGrid.
>> 
>> Pleas review and let me know your suggestions if any.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Upadted based on suggesion

src/java.desktop/share/classes/javax/swing/JTable.java line 1167:

> 1165:      */
> 1166:     @BeanProperty(description
> 1167:             = "Whether grid lines should be drawn in around the cells.")

What about
"Whether grid lines should be drawn around the cells."
or 
"Whether grid lines should be drawn around cells."?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26857#discussion_r2294839396

From prr at openjdk.org  Fri Aug 22 22:19:54 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 22:19:54 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v3]
In-Reply-To: <0MDTPquVuMulH9tEnu_VEaKM7e6SPCpHh_19RhGWXMw=.56db997b-8a7e-48ea-bd07-e9721c5eea28@github.com>
References: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>
 <0MDTPquVuMulH9tEnu_VEaKM7e6SPCpHh_19RhGWXMw=.56db997b-8a7e-48ea-bd07-e9721c5eea28@github.com>
Message-ID: <f3RdJbjdKALPP0cjZakg3wajvw8-yCiUF0J2qopPc6U=.2594f37b-f625-43ca-98d0-a0009a038135@github.com>

On Wed, 6 Aug 2025 07:51:00 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 update

I don't think you are capturing what is going on here.
The cases here are that y=0 so you can't scroll up, because you are at the top.
You don't ordinarlly see this in the positive direction because the cell that is returned is null for out of range, and otherwise it at least points to the TOP of the last cell. 
But I'm not sure how you can actually scroll, because the returned increment would take you off the bottom of the list, 
And if the rectangle you pass in has a y that is = the height of the list, then scrolling in a positive direction also returns 0.
If it is GREATER than the height, then I get back a negative increment !

So this needs quite a bit more than the suggested words, because they aren't accurate or nearly sufficient.
I think a code fix might be needed too.
I can even get a negative scroll value from the upwards direction.
All you have to do is pass a synthesized rect to the API. 
The implementation doesn't seem to be expecting that and it should probably do something in response, but it may be too late from a compatibility point of view. 
I need you to figure this all out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26500#issuecomment-3215821257

From serb at openjdk.org  Fri Aug 22 22:23:54 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 22 Aug 2025 22:23:54 GMT
Subject: RFR: 8366002: Beans.instantiate needs to describe the lookup
 procedure
In-Reply-To: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
References: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
Message-ID: <TrN3j7czRkvDudpTw8veBtqJkdLEAH0ZCPadwqattOU=.024886aa-923f-48d2-b7a0-be520fab83bf@github.com>

On Fri, 22 Aug 2025 17:39:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Some text describing the Beans.instantiate lookup process existed only on the method that used the now removed AppletInitializer.
> Since there are two other Beans.instantiate methods, we need to move that text to the remaining methods.
> 
> Note that one of the methods is also deprecated for removal, so it seems prudent to add it to both so that when the next to be removed method is gone, this problem doesn't recur.
> 
> This is a doc. only change. The CSR is ready for review.

Do we have any tests that verify it actually works as described in the updated specification?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26905#issuecomment-3215824124

From jwood at openjdk.org  Fri Aug 22 22:53:28 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 22 Aug 2025 22:53:28 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v7]
In-Reply-To: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
Message-ID: <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>

> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
> 
> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
> 
> There are a cluster of four related PRs that share the GifComparison class in this PR.
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
> 
> This bug can be observed reading these gif animations:
> 
> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l

Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - 8357034: switch to `isSavedModelReliable`
   
   This reduces how often we resort to "the hard way". The previous implementation would resort to the hard way *any* time the disposal code was SAVE and there was a transparent pixel in use.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25264/files#r2292318270
 - Merge branch 'master' into JDK-8357034
 - 8357034: re-wrapping line breaks
 - 8356137, 8357034: add debug option to dump PNGs of frames
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
 - Merge branch 'master' into JDK-8357034
   
   # Conflicts:
   #	test/jdk/sun/awt/image/gif/GifBuilder.java
   #	test/jdk/sun/awt/image/gif/GifComparison.java
 - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
 - Merge branch 'master' into JDK-8357034
 - 8356320: Use new GifBuilder and remove ukraine-flag.gif
   
   This is an extension of work for this PR:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: adding copyright
 - 8356137: Adding GifBuilder to dynamically create test file
   
   This can be used by multiple gif tests in this directory.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - ... and 24 more: https://git.openjdk.org/jdk/compare/57553ca1...e7796df0

-------------

Changes: https://git.openjdk.org/jdk/pull/25264/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=06
  Stats: 147 lines in 5 files changed: 112 ins; 4 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/25264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25264/head:pull/25264

PR: https://git.openjdk.org/jdk/pull/25264

From jwood at openjdk.org  Fri Aug 22 23:30:55 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Fri, 22 Aug 2025 23:30:55 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v6]
In-Reply-To: <SsFE1mYGDrLQ_zKoJXCDgEwHFnbh4v_iiJfy7cASZ54=.a1050c4b-3c42-4e30-ac03-c50ab9274c7e@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <kzNLoqMvrG0Gls8KnHlxy1KhQT-VGgLNs3cRphZuUuE=.b98c2075-65a4-4c8d-8c91-af0074a11b19@github.com>
 <SsFE1mYGDrLQ_zKoJXCDgEwHFnbh4v_iiJfy7cASZ54=.a1050c4b-3c42-4e30-ac03-c50ab9274c7e@github.com>
Message-ID: <eJfK135IBZ_TzslJayyiertwwZII6Z4Zo2XBHNMewak=.7b9c1c8b-606f-45dd-890b-db8713a8a49c@github.com>

On Thu, 21 Aug 2025 23:18:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
>> 
>>  - 8357034: re-wrapping line breaks
>>  - 8356137, 8357034: add debug option to dump PNGs of frames
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
>>  - Merge branch 'master' into JDK-8357034
>>    
>>    # Conflicts:
>>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>>  - Merge branch 'master' into JDK-8357034
>>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>>    
>>    This is an extension of work for this PR:
>>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>>  - 8356137: adding copyright
>>  - 8356137: Adding GifBuilder to dynamically create test file
>>    
>>    This can be used by multiple gif tests in this directory.
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>>  - 8356137: trivial javadoc update
>>  - 8356137: only inspect last frame of gif
>>    
>>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/a86dd56d...7c96ce19
>
> src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 605:
> 
>> 603:         if (isSimpleSavedImageComparison) {
>> 604:             for (int a = 0; a < saved_image.length; a++) {
>> 605:                 if ((saved_image[a] & 0xff) == trans_pixel) {
> 
> How do you know here that the transparent pixel changed ?

Ah, you're right: I don't.

I ran this test:

new GifBuilder.FrameDescription[] {
        new GifBuilder.FrameDescription(
                GifBuilder.Disposal.doNotDispose, true),
        new GifBuilder.FrameDescription(
                GifBuilder.Disposal.doNotDispose, true),
        new GifBuilder.FrameDescription(
                GifBuilder.Disposal.doNotDispose, true)
};


... and it technically passed (the pixels were all correct), but it followed the wrong logic. It kept entering "the hard way" logic (which is slightly slower) when it didn't need to because the color model never changed.

So as of yesterday: this PR would err on the side of sometimes taking on more work than necessary. (The final pixels were always correct, at least.)

Since that logic is tucked away in such a private method: I don't see how to train the unit test to notice which approach (fast or slow) we're using.

I updated this PR tonight to a new approach: now we track an internal boolean `isSavedModelReliable`. We set this to false once we enter "the hard way" logic once, and we're careful from then on.

Also I updated this PR's original description to better document the failure I'm trying resolve. (Because I'd forgotten the details over the last few months.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2294927594

From prr at openjdk.org  Fri Aug 22 23:54:58 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 23:54:58 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v7]
In-Reply-To: <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>
Message-ID: <W6n_JZUQlVJLL8n4F_bg2cPq41fkmg_4W-qIOQ3FrQg=.63e558af-1673-472d-8cb1-f9d5ae809900@github.com>

On Fri, 22 Aug 2025 22:53:28 GMT, Jeremy Wood <jwood at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>> 
>> ### Describing This Bug
>> 
>> The steps/explanation that lead to this failure are a little complicated. I'll try to summarize the original bug here.
>> 
>> All three frames in this GIF use disposal code doNotDispose, meaning the frames are layered one on top of the previous.
>> 
>> The first frame produces 3 circles from left to right using these colors:
>> 0xff0000 (red) 0xffff00 (yellow) 0x00ff00 (green)
>> 
>> The background is 0x00ffff (cyan). It is the transparent pixel, so the first frame is:
>> 
>> <img width="200" height="100" alt="frame_0" src="https://github.com/user-attachments/assets/8bb53530-fc2b-4a8b-b3a6-5c58782ea5ab" />
>> 
>> Now we start processing the second frame. The pixels are the same, but the color model has changed so the zeroeth color (red) is the transparent index.
>> 
>> When the GifImageDecoder layers the 2nd frame on top of the 1st frame, it notices that `model.equals(saved_model)` is `false`. This means it enter a block of code that refers to "the hard way" of passing new pixel information to the ImageConsumers.
>> 
>> The 2nd frame, after being painted on the 1st frame, looks like:
>> <img width="200" height="100" alt="frame_1" src="https://github.com/user-attachments/assets/0c8ca55b-e25d-418e-bb95-2e6f9e427c08" />
>> ?
>> The 3rd frame is exactly the same as the 2nd. But here's where the bug is: now `model.equals(saved_model)` is `true`, so GifImageDecoder tries to pass the pixel information the easy way. The result is:
>> 
>> <img width="200" height="100" alt="frame_2_awt" src="https://github.com/user-a...
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - 8357034: switch to `isSavedModelReliable`
>    
>    This reduces how often we resort to "the hard way". The previous implementation would resort to the hard way *any* time the disposal code was SAVE and there was a transparent pixel in use.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264/files#r2292318270
>  - Merge branch 'master' into JDK-8357034
>  - 8357034: re-wrapping line breaks
>  - 8356137, 8357034: add debug option to dump PNGs of frames
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
>  - Merge branch 'master' into JDK-8357034
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>  - Merge branch 'master' into JDK-8357034
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/57553ca1...e7796df0

src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 400:

> 398:         boolean save = (curframe.disposal_method == GifFrame.DISPOSAL_SAVE);
> 399:         if (trans_pixel >= 0 && !curframe.initialframe) {
> 400:             if (saved_image != null && model.equals(saved_model) && isSavedModelReliable) {

Without the fix, if the model changes, we go the hard way, on a frame by frame basis.
With the fix, if the model changes, we go the hard way, for this and all subsequent frames.

But what was wrong with frame-by-frame, that "all subsequent frames" fixes ?

I suppose it must be that any frame that had a transparent pixel needs to be preserved for all subsequent frames, but I'm quite hazy on how that works.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2294948284

From prr at openjdk.org  Fri Aug 22 23:57:50 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 22 Aug 2025 23:57:50 GMT
Subject: RFR: 8366002: Beans.instantiate needs to describe the lookup
 procedure
In-Reply-To: <TrN3j7czRkvDudpTw8veBtqJkdLEAH0ZCPadwqattOU=.024886aa-923f-48d2-b7a0-be520fab83bf@github.com>
References: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
 <TrN3j7czRkvDudpTw8veBtqJkdLEAH0ZCPadwqattOU=.024886aa-923f-48d2-b7a0-be520fab83bf@github.com>
Message-ID: <YF5q0pkb5F5pHwF2gsb12_8LixvGMtpIrW4YFWb5Wvs=.89461c79-adf3-488f-9c3c-cb3093079bcb@github.com>

On Fri, 22 Aug 2025 22:18:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Do we have any tests that verify it actually works as described in the updated specification?

If you didn't see any, there probably aren't.
Well I guess there may be JCK ones, since this came from JCK. But that's out of scope here. I'm just restoring doc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26905#issuecomment-3215966700

From serb at openjdk.org  Sat Aug 23 03:01:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 23 Aug 2025 03:01:50 GMT
Subject: RFR: 8366002: Beans.instantiate needs to describe the lookup
 procedure
In-Reply-To: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
References: <PKxEyIH9cItwFZcVkZfKqnMhIb2YK1oRakXzUMmTeRo=.6a310368-a663-44db-ab6b-d580ef8c07c2@github.com>
Message-ID: <4pxSc_xY1AhagCNM7K8W0_uYhYyXEATd5fIbQLFDSFY=.7df0a851-d000-45c7-acbe-7118256f79f9@github.com>

On Fri, 22 Aug 2025 17:39:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Some text describing the Beans.instantiate lookup process existed only on the method that used the now removed AppletInitializer.
> Since there are two other Beans.instantiate methods, we need to move that text to the remaining methods.
> 
> Note that one of the methods is also deprecated for removal, so it seems prudent to add it to both so that when the next to be removed method is gone, this problem doesn't recur.
> 
> This is a doc. only change. The CSR is ready for review.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26905#pullrequestreview-3146786038

From jwood at openjdk.org  Sat Aug 23 03:17:00 2025
From: jwood at openjdk.org (Jeremy Wood)
Date: Sat, 23 Aug 2025 03:17:00 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v7]
In-Reply-To: <W6n_JZUQlVJLL8n4F_bg2cPq41fkmg_4W-qIOQ3FrQg=.63e558af-1673-472d-8cb1-f9d5ae809900@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <9Rm1iSHBouQhfRNBkqJx10T2zXPXz_boHp9U6WEVtPY=.5358256d-737f-4667-b9a9-8792ac36b0e2@github.com>
 <W6n_JZUQlVJLL8n4F_bg2cPq41fkmg_4W-qIOQ3FrQg=.63e558af-1673-472d-8cb1-f9d5ae809900@github.com>
Message-ID: <0UFU7AY4MNec-Avw_thoIWTJmZLmfdotwruRMRrtQq8=.b7e16d0a-34b9-46b5-8f36-13edf6fe0453@github.com>

On Fri, 22 Aug 2025 23:52:39 GMT, Phil Race <prr at openjdk.org> wrote:

> But what was wrong with frame-by-frame, that "all subsequent frames" fixes ?

I'm not sure I understand what you're asking; this bug demonstrates what was wrong with the frame-by-frame response.

Another way to phrase it might be:

A gif works with a fixed color palette of n-many colors. But if you want to be clever: you can switch which pixel is the transparent pixel index, and as you layer frames you can end up with an image that has (n+1)-many colors. The +1 is a transparent pixel.

This demo, for ex, features a 4-color palette: red, yellow, green, cyan. But using this palette we can create an image that is red, yellow, green, cyan AND transparent.

If you process the incoming data "the easy way": we just do a raw dump of the incoming pixels. This forces us back to the 4-color palette *of the current frame*. But if we do it "the hard way": we're processing only the opaque clusters of incoming pixels, which lets us end up with (n+1)-many colors.

If that description helped: great. If not: please disregard. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2295067500

From psadhukhan at openjdk.org  Sun Aug 24 09:03:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 24 Aug 2025 09:03:35 GMT
Subject: RFR: 8365886: JSplitPane loses track of the left component when
 the component orientation is changed [v2]
In-Reply-To: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
References: <mnpbgDbaYQ4yrtM519gQk3h5JQW-J1w1kmnUfQpfSQM=.95298424-195c-449b-ad50-4e2f08b16909@github.com>
Message-ID: <3YhNDPn7cK8_EdaLPQbvXqSXvGfjJ9nNbzvDvyQf_60=.60c89fd8-9ca1-4617-b138-eec1fab94979@github.com>

> When the component orientation is changed from LTR to RTL or the other way around, JSplitPane exchanges the left and right components. However, it does this by adding and removing components instead of swapping the leftComponent and rightComponent fields which results in leftComponent field is left as null.
> 
> This is because when JSplitPane calls `setLeftComponent(rightComponent)` it calls `JSplitPane.addImpl` which calls `super.addImpl`
> which [removes] https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/java/awt/Container.java#L1118 the component from the JSplitPane as it calls `JSplitPane.remove` so the sequence is
> At start `leftComponent = Red, rightComponent = Green`
> 
> before `super.addImpl` is called in `JSplitPane.addImpl` the 
> 
> `leftComponent = Green, rightComponent = Green`
> 
> After super.addImpl is called, it calls [JSplitPane.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L918) where it sets
> leftComponent = null.
> 
> so we have
> leftComponent = null, rightComponent = Green and then it calls [super.remove] (https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L922) which calls `JSplitPane.remove(index)` and since index=1 because "Green" is 1 it removes rightComponent 
> so we have now
> leftComponent = null, rightComponent = null
> 
> so when we now call [setRightComponent](https://github.com/openjdk/jdk/blob/f423e1d9ad37135abacb8deb2d2151e21768a23e/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L382) it sets rightComponent to Red but leftComponent is not set and is still null.
> 
> So fix is to just swap the left and right component in setComponentOrientation call itself without using Container add/remove components

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - update bugid
 - Update component nodes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26893/files
  - new: https://git.openjdk.org/jdk/pull/26893/files/018d019f..6931e97d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26893&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26893&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26893/head:pull/26893

PR: https://git.openjdk.org/jdk/pull/26893

From alanb at openjdk.org  Sun Aug 24 09:58:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 24 Aug 2025 09:58:52 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <OjXR9n3r_ImRUbZsq20V1PRMC7O64HFx4elHq5Syimk=.13dbeee9-9394-4b4f-8881-23da87b44324@github.com>
 <crQ_K__zn-f48cXN9CzX_0FBT22GPuZntr64ZNQb4AE=.77704e1c-30f7-4d46-b2cd-7edc44dbe886@github.com>
 <ma63halKHu2dawB9OaQ2F8ia9hyvwqywipWy8c6peEw=.e15da36f-3830-4e13-a8d8-8c4ab26e9fe8@github.com>
Message-ID: <VveE9LwNHbACMKjKW97dxBek0d1JtVSmaLzxJ1d_gKg=.ebe2da86-b1c5-4ca5-890b-693ddbb1dac7@github.com>

On Fri, 22 Aug 2025 18:43:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>>> @prrace the change maintains the same absolute timeout value for those tests. Before the default of 120 was multiplied by the timeoutFactor of 4 to given 480. Now the value 480 is multiplied by the timeoutFactor of 1 to give 480. And IIRC Leo only did that for tests that demonstrated a timeout with the new default settings (120*1). It is not practical for Leo to investigate every changed test to see if it could get away with a value between 120 and 480. The change just maintains the status quo. Test owners are free to investigate further if they think it worth fine tuning these values.
>> 
>> I don't agree.
>> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.
>> 
>> I am also questioning whether such a time out was demonstrated for this test.
>> I've searched the entire history of CI jobs and I don't see where Leo had such a timeout of this test.
>> I can send you my query off-line so you can check it. Maybe it is incomplete.
>
>> or don't do it.
> 
> Adding `/timeout=480` is more or less don't do anything.
> 
> The default timeout (if omitting `/timeout=...`) is 120, so:
> 
> master: TIMEOUT_FACTOR=4 and /timeout=120 give you actual 480 timeout.
> patch:  TIMEOUT_FACTOR=1 and /timeout=480 give you the same timeout.

> If you are going to modify individual tests, you need to demonstrate what you did for that test is justified or don't do it.

There are several comments in this PR pointing out again and again that adding "/timeout=480" doesn't change anything with the new proposed default timeout and timeoutFactor. I was initially puzzled as to why these were being added to a lot of tests but I think Leo's runs with a timeoutFactor of 0.7 explains it. If the timeoutFactor is reduced then we risk timeouts from tests that are run close to the limit today. The method used to find these tests seems reasonable. So I think the approach is good and we should try to help him get this change integrated to avoid needing to keep it up to date while tests change in main line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2296595504

From dholmes at openjdk.org  Sun Aug 24 22:54:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 24 Aug 2025 22:54:03 GMT
Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5]
In-Reply-To: <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
References: <JV5XmOFEZzaFKyNMYtyAJUYv9dgLYvnit5oQyriC57k=.1b379ced-ad26-47e2-8fa2-fcc82db18f85@github.com>
 <DZLOXaBSykHC6w3qmux0lS3ySSOlXR3WoloKmWnHLBk=.f2f06eab-240b-4142-b879-c83fb7d5421d@github.com>
 <jWzsGkakkbqTWdEVuQUp26C80LCL5b1R_LC49Vz1EJs=.475c7827-f11c-4bf0-bb7d-943e2c940240@github.com>
Message-ID: <LuiIAYhq4IOB9AQHCcFwiHFw30oK-vW-NzGC9ZuIEMo=.32cc7b1d-7426-42f2-bb6a-608b6f0e84ef@github.com>

On Fri, 22 Aug 2025 15:41:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update testing.md, remove makefile link, fix bad text
>
> test/hotspot/jtreg/compiler/tiered/Level2RecompilationTest.java line 36:
> 
>> 34:  * @build jdk.test.whitebox.WhiteBox
>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>> 36:  * @run main/othervm/timeout=960 -Xbootclasspath/a:. -XX:+TieredCompilation
> 
> Why not `480` in this case?

Leo also states in the description:

> In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2296840413

From rkannathpari at openjdk.org  Mon Aug 25 03:54:44 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 25 Aug 2025 03:54:44 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid [v3]
In-Reply-To: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
Message-ID: <jpGH5DvunoM5tV82fkisbjloZ4nVU1e-IVoLaK4LQus=.202586dc-8a27-4c76-bf8d-1a6f221f9572@github.com>

> Hi Reviewers,
> 
> Updated the Bean Property description with meaningful string for JTable.setShowGrid.
> 
> Pleas review and let me know your suggestions if any.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated string

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26857/files
  - new: https://git.openjdk.org/jdk/pull/26857/files/33e8e04d..9bde38ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26857&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26857&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26857.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26857/head:pull/26857

PR: https://git.openjdk.org/jdk/pull/26857

From rkannathpari at openjdk.org  Mon Aug 25 03:54:45 2025
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 25 Aug 2025 03:54:45 GMT
Subject: RFR: 8302057: Wrong BeanProperty description for
 JTable.setShowGrid [v2]
In-Reply-To: <G3Xh78Mu84fGKskWMdDb7wFudddMUBYs_zablc-3Z8c=.6e2e917a-8f90-4184-9ab1-c1cff8811a4d@github.com>
References: <U08ontEc6yZ0rsidqFYSL3i_1ziUAQLQk9k2Ujd_Kqs=.8ebc137c-8cd1-4567-a1d9-8ea99d89ac33@github.com>
 <EdnDFGYm2AkEcZ9EVZGZm3C2q6wqJUr7KAdvf_4ihgo=.6a1c6b5c-ae11-40ce-8440-08f0a9b3d963@github.com>
 <G3Xh78Mu84fGKskWMdDb7wFudddMUBYs_zablc-3Z8c=.6e2e917a-8f90-4184-9ab1-c1cff8811a4d@github.com>
Message-ID: <XF_lnpj7Gvsa26w4vZPBb3OdWI8Xp_SRllxXqh5gaIE=.0a57177e-3183-48e8-ad7d-db9542b27870@github.com>

On Fri, 22 Aug 2025 22:13:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Upadted based on suggesion
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 1167:
> 
>> 1165:      */
>> 1166:     @BeanProperty(description
>> 1167:             = "Whether grid lines should be drawn in around the cells.")
> 
> What about
> "Whether grid lines should be drawn around the cells."
> or 
> "Whether grid lines should be drawn around cells."?

I felt "Whether grid lines should be drawn around the cells" more closer with other properties , I have updated this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26857#discussion_r2297060229