From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 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 jdv at openjdk.org Mon Sep 1 08:09:52 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 1 Sep 2025 08:09:52 GMT Subject: Integrated: 8364135: JPEGImageReader.getImageTypes() should throw exception for negative image index In-Reply-To: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com> References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com> Message-ID: On Tue, 29 Jul 2025 05:38:00 GMT, Jayathirth D V 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. This pull request has now been integrated. Changeset: fe4c7a04 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/fe4c7a0429a2cf9ef47701d68d0852ce44e1a9ab Stats: 98 lines in 2 files changed: 95 ins; 2 del; 1 mod 8364135: JPEGImageReader.getImageTypes() should throw exception for negative image index Reviewed-by: aivanov, prr, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/26522 From asemenov at openjdk.org Mon Sep 1 10:24:58 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Mon, 1 Sep 2025 10:24:58 GMT Subject: RFR: 8365609: Fix several potential NULL native pointer dereferences in the desktop module [v5] In-Reply-To: References: Message-ID: > The defect has been detected and confirmed in the function OGLBlitToSurfaceViaTexture() located in the file src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer pf is dereferenced in line 324 without checking for nullptr, although earlier in line 274 the same pointer is checked for nullptr, which indicates that it can be null. > > In the same file, line 551 calls OGLBlitToSurfaceViaTexture() from line 263, where NULL is passed in place of pf. > All other calls are fine. > > Also, another function with a similar issue from the same file, OGLBlitSwToTexture() from line 396. > > In src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c gtk3_load() > The pointer fp_glib_check_version can be null, but it is dereferenced without any check. Although in the same file, for example, line 280 contains a check, this check does not lead to termination of execution. > > > In src/java.desktop/share/native/libsplashscreen/splashscreen_gif.c SplashDecodeGif() > The pointer colorMap is dereferenced after it has been checked against nullptr in lines 151 and 206. Moreover, between these checks and the mentioned location (line 282), the pointer is not modified in any way. > > According to [this](https://github.com/openjdk/jdk/pull/26002#issuecomment-3023050372) comment, this PR contains fixes for similar cases in other places. Artem Semenov has updated the pull request incrementally with three additional commits since the last revision: - Revert "The same issue is present in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitSwToTexture()" This reverts commit c4b87121234bb1427f5e611adf5726ac5b3d15e3. - Revert "8365609 Null pointer dereference in src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c OGLBlitToSurfaceViaTexture()" This reverts commit ff9825cd7d8838c90daa804e794576282be7bb81. - Revert "Fixed indentation" This reverts commit c96d09acd95d0ccf2fef50b8ccfeb5e2a0aa0968. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26799/files - new: https://git.openjdk.org/jdk/pull/26799/files/c96d09ac..1a5a4019 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26799&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26799&range=03-04 Stats: 40 lines in 1 file changed: 11 ins; 16 del; 13 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 asemenov at openjdk.org Mon Sep 1 10:24:59 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Mon, 1 Sep 2025 10:24:59 GMT Subject: RFR: 8365609: Fix several potential NULL native pointer dereferences in the desktop module [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 16:30:40 GMT, Phil Race wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed indentation > > src/java.desktop/share/native/common/java2d/opengl/OGLBlitLoops.c line 324: > >> 322: sx, srcInfo->pixelStride, >> 323: sy, srcInfo->scanStride); >> 324: if (pf != NULL) { > > I don't think any of these changes in this file are necessary. > pf is null IFF sw_surface == JNI_FALSE > and iin that case, we never end the loop where pf is needed. > Put another way, if you look at the call sites one > is > pf != null, srcOps == NULL, sw_surface == FALSE > the other is > pf == null, srcOps != NULL, sw_surface == TRUE > > and you can see that srcOps would have the same theoretical issue except that it would be a bug to call it with the wrong value of sw_surface. > So revert all changes in this file. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26799#discussion_r2313549687 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > 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: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org Mon Sep 1 13:35:20 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Mon, 1 Sep 2025 13:35:20 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v29] In-Reply-To: References: Message-ID: > 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: Moves latch logic inside ancestor frame block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/c7e56eeb..bbeda980 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=27-28 Stats: 16 lines in 1 file changed: 4 ins; 3 del; 9 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 Sep 1 13:39:50 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Mon, 1 Sep 2025 13:39:50 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v27] In-Reply-To: References: <3Vs91nphdprtkbEIA7PElDhEIyC8bO5lr0VxsXsrZp8=.dedd1ff4-c013-4bc5-bc83-9e17309ab458@github.com> Message-ID: On Sun, 31 Aug 2025 09:15:27 GMT, Khalid Boulanouare wrote: >> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 172: >> >>> 170: if (!await) { >>> 171: throw new RuntimeException("Ancestor frame didn't receive " + >>> 172: "focus"); >> >> I guess this latch wait needs to be moved to `ancestor != null` block as it is a noop for null ancestor > > I will move the latch synchronization to `ancestor != null ` condition and test that it is still wokring. I have moved the latch logic inside the `ancestor != null` and run the CI job. Each test is run 5 times on the same machine and on two machines for each OS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2313989122 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth 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: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From aivanov at openjdk.org Mon Sep 1 13:58:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 1 Sep 2025 13:58:45 GMT Subject: RFR: 8366369: Add @requires linux for GTK L&F tests In-Reply-To: References: <8nwXqX5w73kl0-jtB9-IP7aO5jml1_vUND1m5sXl2_A=.cd11d5ee-83bc-41f4-a9ef-dcd95b7c72b1@github.com> <9TReA52m9H5bd8VVXjlWj5Pyk_NpYCiFpkIPS9tq-bo=.9de78465-5422-4a67-9ff2-aec2c1022d52@github.com> Message-ID: On Sat, 30 Aug 2025 03:36:51 GMT, Sergey Bylokhov wrote: > > The purpose of this PR is to avoid running GTK L&F specific tests on the platforms where GTK L&F isn't available. > > But why not try loading it? That would help verify that the validation for missing dependencies works correctly. I think the patch is based on assumptions that are not necessarily true: Both assumptions are true: > * GTK L&F cannot be supported on platforms other than Linux If I run the test on Windows or on macOS, I get ` java.lang.ClassNotFoundException: com.sun.java.swing.plaf.gtk.GTKLookAndFeel`. GTK L&F may be supported on other platforms but *it is not*. > * headful systems always have the GTK library installed Since GNOME is the only desktop environment officially supported, there's no way GTK library isn't installed on a correctly configured headful host. If GTK library isn't available, it needs installing. This is why I think these tests have to fail if `GTKLookAndFeel` can't be loaded rather than silently ignore the failure? even on Linux hosts. Thus, I'm standing with my intent: I see no point in even trying to start a GTK L&F test on platforms other than Linux. I did run the updated tests on CI, and the tests pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26995#discussion_r2314034678 From duke at openjdk.org Mon Sep 1 14:19:41 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Mon, 1 Sep 2025 14:19:41 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v3] In-Reply-To: References: Message-ID: > The fix for the https://bugs.openjdk.org/browse/JDK-8251928. > > **Description**. > This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. > > As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): > 1. Convert the user-space point, size, or rectangle value to device space coordinates; > 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; > 3. Convert the normalized value back to user space; > 4. Draw your content using the adjusted value. > > The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. > The 2-nd step is a drawing process in the java code (without changes). > The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. > The 4-th step is a drawing process in the native code (without changes). > > **Tests**. > I run all tests from javax.print package and there is no any regression. > New test covers macOS and Linux only because we know its default DPI - 300. GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into macOS_printing_DPI - Merge branch 'openjdk:master' into macOS_printing_DPI - [macos] the printer DPI always be 72 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25489/files - new: https://git.openjdk.org/jdk/pull/25489/files/3d61732d..0d739ffa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=01-02 Stats: 74830 lines in 1847 files changed: 45192 ins; 21385 del; 8253 mod Patch: https://git.openjdk.org/jdk/pull/25489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489 PR: https://git.openjdk.org/jdk/pull/25489 From dgredler at openjdk.org Mon Sep 1 14:50:44 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Mon, 1 Sep 2025 14:50:44 GMT Subject: RFR: 4138921: TextLayout handling of empty strings In-Reply-To: References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: On Fri, 29 Aug 2025 00:14:09 GMT, Phil Race wrote: > > REVIEWER NOTE: Please check the empty-string TextLayout behavior documented in TextLayoutConstructorTest carefully; a badly-behaving empty TextLayout is probably worse than a TextLayout which doesn't allow empty strings... > > I assume you mean are the "expected" behaviours you assigned to all the methods of such a constructed TextLayout reasonable behaviours ? That's right; about half of the `TextLayout` public API surface area is new to me, so although I was very careful to try to make sure that the behaviors all made sense, I'll feel more comfortable once this part has been checked carefully. > please create a CSR No problem, here it is: https://bugs.openjdk.org/browse/JDK-8366563 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26947#issuecomment-3242636667 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang 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/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? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From dgredler at openjdk.org Mon Sep 1 16:01:51 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Mon, 1 Sep 2025 16:01:51 GMT Subject: RFR: 4138921: TextLayout handling of empty strings In-Reply-To: References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: <5DGFHD-gRqLV2Ilfj3zHRzfP4hAdcNO2h23zQ6R70hU=.35a9381e-e722-4229-a0b5-e918e8990f29@github.com> On Thu, 28 Aug 2025 22:42:31 GMT, Phil Race wrote: >> `TextLayout` should deal more gracefully with zero length strings. Currently the exception listed below is the one that is thrown. >> >> `new TextLayout("", f, new FontRenderContext(null, false, false));` >> >>> Exception in thread "main" java.lang.IllegalArgumentException: Zero length >>> string passed to TextLayout constructor. >>> at java.lang.Throwable.(Compiled Code) >>> at java.lang.Exception.(Compiled Code) >>> at java.lang.RuntimeException.(Compiled Code) >>> at java.lang.IllegalArgumentException.(Compiled Code) >>> at java.awt.font.TextLayout.(Compiled Code) >>> at test.main(Compiled Code) >> >> **REVIEWER NOTE:** Please check the empty-string `TextLayout` behavior documented in `TextLayoutConstructorTest` carefully; a badly-behaving empty `TextLayout` is probably worse than a `TextLayout` which doesn't allow empty strings... > > src/java.desktop/share/classes/java/awt/font/TextLine.java line 839: > >> 837: >> 838: if (result == null) { >> 839: result = new Rectangle2D.Float(Float.MAX_VALUE, Float.MAX_VALUE, Float.MIN_VALUE, Float.MIN_VALUE); > > That's interesting. I'd have assumed what you changed it to would be the answer in such. a case ? Why was it like this ? Perhaps it was never possible before and this was intended to 'flag a problem' ?? I also wondered this, and came to the conclusion that it probably simply represents an impossibly-positioned, impossibly-sized rectangle that should never overlap with anything -- similar to `getItalicBounds`, which are the default bounds used in some of the `TextLayout` methods which are overloaded to sometimes take a bounds parameter and sometimes not (e.g. `getCaretInfo`). If this assumption is correct, then `(0, 0, 0, 0)` should also be OK. > src/java.desktop/share/classes/java/awt/font/TextLine.java line 934: > >> 932: >> 933: if (!requiresBidi) { >> 934: requiresBidi = Bidi.requiresBidi(chars, 0, characterCount); > > This doesn't change anything, does it ? So why is the change made ? This - and white space changes - make it look like there are more changes than there really are. Correct. One of the solutions I played around with during the experimental phase involved creating a zero-length `TextLine` with one `TextLineComponent` here by replacing any zero-length `chars` with a one-char array, but continuing to report zero length to the supporting classes. We already store `chars.length` in `characterCount`, so this bit of subterfuge was easier if everyone used the variable instead of getting the actual array length again. When I backed out this experiment, I left the variable use since it seemed strange that we were mostly ignoring the variable here... but I can back out the variable use too, if you want. > src/java.desktop/share/classes/sun/font/TextLabelFactory.java line 122: > >> 120: int limit) { >> 121: >> 122: if (start > limit || start < lineStart || limit > lineLimit) { > > Why is this change needed ? I'm supposing that for zero length start==limit==0 but we get here because TextLine calls it in a do { ... } block so will call it at least once, and I wonder if that should change ? So why did you do it this way ? Yes, part of it is the `do {} while` looping in `TextLine.createComponentsOnRun`, but it also avoids having to add an additional `pcm` null check in `TextLine.init` and a check for zero-length `numComponents` in `TextLine.fastCreateTextLine`. Furthermore, even with these additional defensive checks one layer up, we would end up in a situation where we have an empty `TextLineComponent[]` and therefore no metrics and no ascent / descent / leading to report (I've assumed we don't want to report zero for these, since these numbers are consistent for a given font / FRC regardless of the text being used). Then we'd also start to have issues with `getCaretInfo` / `getCaretShape` / `getCaretShapes`, which also rely on the `TextLine` metrics which we won't have with an empty `TextLineComponent[]`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26947#discussion_r2314278179 PR Review Comment: https://git.openjdk.org/jdk/pull/26947#discussion_r2314278799 PR Review Comment: https://git.openjdk.org/jdk/pull/26947#discussion_r2314282455 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From dnguyen at openjdk.org Tue Sep 2 02:45:53 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 2 Sep 2025 02:45:53 GMT Subject: RFR: 8361606 : ConsumeNextMnemonicKeyTypedTest.java fails on Windows: character typed with VK_A: a [v3] In-Reply-To: <_nPRGlMGPKwLlFWCRKKg0sSFhpAivnRlujl3j_AB29g=.81328625-2382-4507-930a-1867816c28a6@github.com> References: <_1yXNCrYeLyBJRqWhP2kjkzUVBxWuZ1gTNmnhRGRrjw=.36be8e3b-12c9-41d4-8389-9bba991fe57f@github.com> <_nPRGlMGPKwLlFWCRKKg0sSFhpAivnRlujl3j_AB29g=.81328625-2382-4507-930a-1867816c28a6@github.com> Message-ID: On Sat, 30 Aug 2025 19:54:39 GMT, Anass Baya wrote: > Could you please confirm whether the proposed fix resolves the issue on macOS, since you're able to reproduce it on it? The fix does not. When testing on macOS, it does not seem like Aqua L&F even touches `menuKeyPressed()` in `BasicPopupMenuUI.java`. Or at least, not that portion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26790#issuecomment-3243611822 From smandalika at openjdk.org Tue Sep 2 04:53:43 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 2 Sep 2025 04:53:43 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 12:04:45 GMT, Srinivas Mandalika 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. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > 8339791: review feedback incorporated. I have incorporated the review suggestions. Can anyone provide feedback on these? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26471#issuecomment-3243772020 From dnguyen at openjdk.org Tue Sep 2 05:22:44 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 2 Sep 2025 05:22:44 GMT Subject: RFR: 8361387 : Test bug4655513.java fails intermittently on Windows platform. [v3] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 05:03:06 GMT, Anass Baya 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. > > Anass Baya has updated the pull request incrementally with one additional commit since the last revision: > > add waitForIdle() I agree. I tested with and without and I haven't seen it occur yet but I can run larger amounts of reruns. I'm not 100% sold that this will fix the intermittent issue but I don't see an issue with the update. ------------- PR Review: https://git.openjdk.org/jdk/pull/26824#pullrequestreview-3174902931 From mvs at openjdk.org Tue Sep 2 07:21:34 2025 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 2 Sep 2025 07:21:34 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently Message-ID: Issue: java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." I have seen it failing in all platforms, but predominantly in macos platform. It fails sometimes in CI also. Fix: Added a countdownlatch for tracking focusGained Added screenshot logic Testing: Tested in all mach5 platforms and got all PASS. ------------- Commit messages: - 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently Changes: https://git.openjdk.org/jdk/pull/27039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347277 Stats: 31 lines in 1 file changed: 19 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27039/head:pull/27039 PR: https://git.openjdk.org/jdk/pull/27039 From mvs at openjdk.org Tue Sep 2 07:29:38 2025 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 2 Sep 2025 07:29:38 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v2] In-Reply-To: References: Message-ID: > Issue: > java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." > I have seen it failing in all platforms, but predominantly in macos platform. > It fails sometimes in CI also. > > Fix: > Added a countdownlatch for tracking focusGained > Added screenshot logic > > Testing: > Tested in all mach5 platforms and got all PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Removed package statement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27039/files - new: https://git.openjdk.org/jdk/pull/27039/files/f3bed35d..2795ea44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27039/head:pull/27039 PR: https://git.openjdk.org/jdk/pull/27039 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth 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... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From duke at openjdk.org Tue Sep 2 08:10:45 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 2 Sep 2025 08:10:45 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 07:29:38 GMT, Manukumar V S wrote: >> Issue: >> java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." >> I have seen it failing in all platforms, but predominantly in macos platform. >> It fails sometimes in CI also. >> >> Fix: >> Added a countdownlatch for tracking focusGained >> Added screenshot logic >> >> Testing: >> Tested in all mach5 platforms and got all PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Removed package statement test/jdk/java/awt/Focus/ComponentLostFocusTest.java line 62: > 60: static volatile int width; > 61: static volatile int top; > 62: static CountDownLatch focusGainedLatch = new CountDownLatch(1); This can be `final` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27039#discussion_r2315268668 From tr at openjdk.org Tue Sep 2 08:33:44 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 2 Sep 2025 08:33:44 GMT Subject: RFR: 8366369: Add @requires linux for GTK L&F tests In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 18:34:00 GMT, Alexey Ivanov wrote: > * Add `@requires os.family == "linux"` to prevent GTK L&F tests from running on other OS but Linux. > * Let any exceptions from `UIManager.setLookAndFeel` propagate. > * Remove `@author` tag. > * Expand imports in `test/jdk/com/sun/java/swing/plaf/gtk/Test6635110.java`. > * Add leading asterisks to jtreg comment block. LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26995#pullrequestreview-3175455311 From tr at openjdk.org Tue Sep 2 08:38:43 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 2 Sep 2025 08:38:43 GMT Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 17:27:09 GMT, Phil Race 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 2: > 1: /* > 2: * Copyright (c) 1999, 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. I hope it was copy paste error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26784#discussion_r2315345165 From duke at openjdk.org Tue Sep 2 11:26:30 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Tue, 2 Sep 2025 11:26:30 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v4] In-Reply-To: References: Message-ID: > The fix for the https://bugs.openjdk.org/browse/JDK-8251928. > > **Description**. > This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. > > As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): > 1. Convert the user-space point, size, or rectangle value to device space coordinates; > 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; > 3. Convert the normalized value back to user space; > 4. Draw your content using the adjusted value. > > The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. > The 2-nd step is a drawing process in the java code (without changes). > The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. > The 4-th step is a drawing process in the native code (without changes). > > **Tests**. > I run all tests from javax.print package and there is no any regression. > New test covers macOS and Linux only because we know its default DPI - 300. GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: remove setDevClip usage. Update names. Handle page format orientation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25489/files - new: https://git.openjdk.org/jdk/pull/25489/files/0d739ffa..f7d5f3f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=02-03 Stats: 204 lines in 6 files changed: 140 ins; 29 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/25489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489 PR: https://git.openjdk.org/jdk/pull/25489 From duke at openjdk.org Tue Sep 2 13:23:47 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Tue, 2 Sep 2025 13:23:47 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 11:26:30 GMT, GennadiyKrivoshein wrote: >> The fix for the https://bugs.openjdk.org/browse/JDK-8251928. >> >> **Description**. >> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. >> >> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): >> 1. Convert the user-space point, size, or rectangle value to device space coordinates; >> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; >> 3. Convert the normalized value back to user space; >> 4. Draw your content using the adjusted value. >> >> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. >> The 2-nd step is a drawing process in the java code (without changes). >> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. >> The 4-th step is a drawing process in the native code (without changes). >> >> **Tests**. >> I run all tests from javax.print package and there is no any regression. >> New test covers macOS and Linux only because we know its default DPI - 300. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > remove setDevClip usage. Update names. Handle page format orientation. @prrace , thank you for the review. I removed the setDevClip method and used a scaled page format to create SunGraphics2D. Also, I updated names. You are absolutely right this is a document DPI not a printer. The default DPI for the document is 300, but users can update DPI to be aligned with a printer's DPI. I also took into account an orientation of the page. The main idea has not changed, that is a document is drawn using default DPI 300, or one of supported printer's DPI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25489#issuecomment-3245328903 From serb at openjdk.org Tue Sep 2 16:47:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Sep 2025 16:47:50 GMT Subject: RFR: 8366369: Add @requires linux for GTK L&F tests In-Reply-To: References: <8nwXqX5w73kl0-jtB9-IP7aO5jml1_vUND1m5sXl2_A=.cd11d5ee-83bc-41f4-a9ef-dcd95b7c72b1@github.com> <9TReA52m9H5bd8VVXjlWj5Pyk_NpYCiFpkIPS9tq-bo=.9de78465-5422-4a67-9ff2-aec2c1022d52@github.com> Message-ID: On Mon, 1 Sep 2025 13:55:39 GMT, Alexey Ivanov wrote: >>>The purpose of this PR is to avoid running GTK L&F specific tests on the platforms where GTK L&F isn't available. >> >> But why not try loading it? That would help verify that the validation for missing dependencies works correctly. >> I think the patch is based on assumptions that are not necessarily true: >> - GTK L&F cannot be supported on platforms other than Linux >> - headful systems always have the GTK library installed > >> > The purpose of this PR is to avoid running GTK L&F specific tests on the platforms where GTK L&F isn't available. >> >> But why not try loading it? That would help verify that the validation for missing dependencies works correctly. I think the patch is based on assumptions that are not necessarily true: > > Both assumptions are true: > >> * GTK L&F cannot be supported on platforms other than Linux > > If I run the test on Windows or on macOS, I get ` java.lang.ClassNotFoundException: com.sun.java.swing.plaf.gtk.GTKLookAndFeel`. > > GTK L&F may be supported on other platforms but *it is not*. > >> * headful systems always have the GTK library installed > > Since GNOME is the only desktop environment officially supported, there's no way GTK library isn't installed on a correctly configured headful host. If GTK library isn't available, it needs installing. > > This is why I think these tests have to fail if `GTKLookAndFeel` can't be loaded rather than silently ignore the failure? even on Linux hosts. > > Thus, I'm standing with my intent: I see no point in even trying to start a GTK L&F test on platforms other than Linux. > > I did run the updated tests on CI, and the tests pass. > > * GTK L&F cannot be supported on platforms other than Linux > > If I run the test on Windows or on macOS, I get ` java.lang.ClassNotFoundException: com.sun.java.swing.plaf.gtk.GTKLookAndFeel`. > > GTK L&F may be supported on other platforms but _it is not_. What's the point of testing on Windows and macOS? For the question above, it should be tested on Unix-like systems such as SAP or BSD. > > * headful systems always have the GTK library installed > > Since GNOME is the only desktop environment officially supported, there's no way GTK library isn't installed on a correctly configured headful host. If GTK library isn't available, it needs installing. Supported by the OpenJDK? That?s definitely not true. It is supported and certified on various systems, many of which do not include GTK. This is one of the reasons why failing to load the GTK library is not considered fatal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26995#discussion_r2316642289 From aivanov at openjdk.org Tue Sep 2 17:19:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 2 Sep 2025 17:19:48 GMT Subject: RFR: 8366369: Add @requires linux for GTK L&F tests In-Reply-To: References: <8nwXqX5w73kl0-jtB9-IP7aO5jml1_vUND1m5sXl2_A=.cd11d5ee-83bc-41f4-a9ef-dcd95b7c72b1@github.com> <9TReA52m9H5bd8VVXjlWj5Pyk_NpYCiFpkIPS9tq-bo=.9de78465-5422-4a67-9ff2-aec2c1022d52@github.com> Message-ID: On Tue, 2 Sep 2025 16:45:24 GMT, Sergey Bylokhov wrote: > > GTK L&F may be supported on other platforms but _it is not_. > > What's the point of testing on Windows and macOS? For the question above, it should be tested on Unix-like systems such as SAP or BSD. It should be tested on Unix-like systems if and only if GTK library is supported. > It is supported and certified on various systems, many of which do not include GTK. This is one of the reasons why failing to load the GTK library is not considered fatal. If GTK library isn't supported (or available) on a system, I see no reason in wasting time and even starting the test. It's the purpose of `@requires` expression that can be amended to include other platforms where GTK library is supported and, therefore, GTK Look-and-Feel can be instantiated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26995#discussion_r2316708683 From prr at openjdk.org Tue Sep 2 17:24:43 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 2 Sep 2025 17:24:43 GMT Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 08:35:37 GMT, Tejesh R 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 2: > >> 1: /* >> 2: * Copyright (c) 1999, 2025, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > I hope it was copy paste error. No it was not an error. This is content moved from another file. Files are an artificial division. It is the same content. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26784#discussion_r2316719434 From serb at openjdk.org Tue Sep 2 17:55:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Sep 2025 17:55:48 GMT Subject: RFR: 8366369: Add @requires linux for GTK L&F tests In-Reply-To: References: <8nwXqX5w73kl0-jtB9-IP7aO5jml1_vUND1m5sXl2_A=.cd11d5ee-83bc-41f4-a9ef-dcd95b7c72b1@github.com> <9TReA52m9H5bd8VVXjlWj5Pyk_NpYCiFpkIPS9tq-bo=.9de78465-5422-4a67-9ff2-aec2c1022d52@github.com> Message-ID: On Tue, 2 Sep 2025 17:17:26 GMT, Alexey Ivanov wrote: >It should be tested on Unix-like systems if and only if GTK library is supported. You?re excluding that possibility by using "@requires=linux". Instead, it should be handled the same way we check for other features like tray icon or multimonitor support by performing the check at the start of the test and exiting if the feature is not supported. You can exclude Windows and macOS but left other platforms as is. >If GTK library isn't supported (or available) on a system, I see no reason in wasting time and even starting the test. It's the purpose of @requires expression that can be amended to include other platforms where GTK library is supported and, therefore, GTK Look-and-Feel can be instantiated. We do not have "requires" for gtk, the "headful" and "linux" tags added to the tests are unrelated to the gtk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26995#discussion_r2316782166 From serb at openjdk.org Tue Sep 2 18:25:44 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 2 Sep 2025 18:25:44 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 07:29:38 GMT, Manukumar V S wrote: >> Issue: >> java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." >> I have seen it failing in all platforms, but predominantly in macos platform. >> It fails sometimes in CI also. >> >> Fix: >> Added a countdownlatch for tracking focusGained >> Added screenshot logic >> >> Testing: >> Tested in all mach5 platforms and got all PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Removed package statement test/jdk/java/awt/Focus/ComponentLostFocusTest.java line 157: > 155: if (!focusGainedLatch.await(5, TimeUnit.SECONDS)) { > 156: captureScreen(); > 157: throw new RuntimeException("Waited too long, TextField got no focus! Test failed."); please split the long lines ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27039#discussion_r2316838513 From serb at openjdk.org Wed Sep 3 00:47:46 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 3 Sep 2025 00:47:46 GMT Subject: RFR: 4138921: TextLayout handling of empty strings In-Reply-To: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: On Tue, 26 Aug 2025 17:40:12 GMT, Daniel Gredler wrote: > `TextLayout` should deal more gracefully with zero length strings. Currently the exception listed below is the one that is thrown. > > `new TextLayout("", f, new FontRenderContext(null, false, false));` > >> Exception in thread "main" java.lang.IllegalArgumentException: Zero length >> string passed to TextLayout constructor. >> at java.lang.Throwable.(Compiled Code) >> at java.lang.Exception.(Compiled Code) >> at java.lang.RuntimeException.(Compiled Code) >> at java.lang.IllegalArgumentException.(Compiled Code) >> at java.awt.font.TextLayout.(Compiled Code) >> at test.main(Compiled Code) > > **REVIEWER NOTE:** Please check the empty-string `TextLayout` behavior documented in `TextLayoutConstructorTest` carefully; a badly-behaving empty `TextLayout` is probably worse than a `TextLayout` which doesn't allow empty strings... src/java.desktop/share/classes/java/awt/font/TextLayout.java line 516: > 514: > 515: int start = text.getBeginIndex(); > 516: int limit = text.getEndIndex(); Why do we call text.first() twice, on line 516 and in the loop init block? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26947#discussion_r2317487911 From prr at openjdk.org Wed Sep 3 01:44:59 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 3 Sep 2025 01:44:59 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: References: Message-ID: On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann 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 I wasn't entirely happy with the explanation that there must be a bug in macOS and the "it now works" seeming to be good enough, I also didn't understand where the wrong first page number was arrived at. Also it wasn't explained how setting the first page to 1 magically caused the actual first page to be rendered to be the first page in the range. So I did some looking around and I have a rough idea what is happening. In CPrinterJob there is a method called javaPrinterJobToNSPrintInfo() This is invoked from within the printing loop and has this code [printingDictionary setObject:[NSNumber numberWithInteger:fromPage] forKey:NSPrintFirstPage]; [printingDictionary setObject:[NSNumber numberWithInteger:toPage] forKey:NSPrintLastPage]; That sets the range based on calling RasterPrinterJob.getFromPageAttrib() and RasterPrinterJob.getToPageAttrib() So what I think happens is we are setting a range within a range. If the user set the range from 2 to 3 that is supplied first to macOS in the implementation of knowsPageRange But when dictionary is applied on top of that it becomes FROM Page 2 of the range[2->3] which is Page 3 TO Page 3 of the range[2->3] which would be Page 4 but that is out of range so isn't printed. So only Page 3 is in range and printed. similarly if the user asks for 2-5 it becomes FROM Page 2 of the range[2->5] which is Page 3 TO Page 5 of the range[2->5] which would be Page 6 but that is out of range so isn't printed. So you get 3, 4, 5 And any starting page that is > half the range max means nothing is printed. This also explains why a range that starts from 1 works. So deleting/commenting out these lines [printingDictionary setObject:[NSNumber numberWithInteger:fromPage] forKey:NSPrintFirstPage]; [printingDictionary setObject:[NSNumber numberWithInteger:toPage] forKey:NSPrintLastPage]; and ensuring we always set [printingDictionary setObject:[NSNumber numberWithBool:YES] forKey:NSPrintAllPages]; Also fixes this bug. It seems odd that we have these two ways of doing a similar thing and that they interact like this. I think this all bears a bit more studying as to which code to update for the fix - one of these has to go (although knowsPageRange probably needs to exist and return YES, else the peek won't happen if I correctly read the Apple docs) Also I'd like to make sure we test more cases than the simple native dialog there's the cross platform dialog, and PageRanges attributes too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3247397993 From psadhukhan at openjdk.org Wed Sep 3 04:01:51 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 3 Sep 2025 04:01:51 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v27] In-Reply-To: References: <3Vs91nphdprtkbEIA7PElDhEIyC8bO5lr0VxsXsrZp8=.dedd1ff4-c013-4bc5-bc83-9e17309ab458@github.com> Message-ID: On Sun, 31 Aug 2025 09:04:28 GMT, Khalid Boulanouare wrote: >> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 63: >> >>> 61: { >>> 62: multiFramesTest = false; >>> 63: } >> >> what is this for? > > The GlassPaneOverlappingTestBase tests are not multi-frame tests, they do not use multiple frames where each frame has an AWT component to test Swing with that AWT component. If the frame is disposed in the SimpleOverlappingTestBase class, the frame will disappear and the test will fail. This applies only the the GlassPane tests (extending GlassPaneOverlappingTestBase) But the frame should be disposed *after* the test is executed, more specifically in finally block so am still not sure about this addition ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2317693101 From tr at openjdk.org Wed Sep 3 04:39:42 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 3 Sep 2025 04:39:42 GMT Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 17:22:33 GMT, Phil Race wrote: >> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClipDelegate.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 1999, 2025, Oracle and/or its affiliates. All rights reserved. >> >> Suggestion: >> >> * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. >> >> I hope it was copy paste error. > > No it was not an error. This is content moved from another file. Files are an artificial division. It is the same content. Ok, so when we create a new file and move the contents from old file as part of refactoring we retain the copyright year too. Got it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26784#discussion_r2317736333 From psadhukhan at openjdk.org Wed Sep 3 05:17:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 3 Sep 2025 05:17:47 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v2] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 12:04:45 GMT, Srinivas Mandalika 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. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > 8339791: review feedback incorporated. test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 68: > 66: doTest(); > 67: } catch (Exception e) { > 68: throw new RuntimeException("Unexpected Exception encountered."); no need to catch Exception only to rethrow test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 155: > 153: try { > 154: robot = new Robot(); > 155: } catch (Exception e) { no need to catch Exception as main already has it in signature test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 164: > 162: passed = false; > 163: } > 164: } catch (InterruptedException e) { no need to catch this exception test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 179: > 177: windowActivatedLatch.await(1500, TimeUnit.MILLISECONDS); > 178: } catch (Exception e) { > 179: throw new RuntimeException("Unexpected Exception: " same test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 198: > 196: windowDeactivatedLatch.await(1500, TimeUnit.MILLISECONDS); > 197: } catch (Exception e) { > 198: throw new RuntimeException("Unexpected Exception: " same ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2317715078 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2317718685 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2317722816 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2317779936 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2317780065 From mvs at openjdk.org Wed Sep 3 05:23:02 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 3 Sep 2025 05:23:02 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v3] In-Reply-To: References: Message-ID: > Issue: > java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." > I have seen it failing in all platforms, but predominantly in macos platform. > It fails sometimes in CI also. > > Fix: > Added a countdownlatch for tracking focusGained > Added screenshot logic > > Testing: > Tested in all mach5 platforms and got all PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed: formatting changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27039/files - new: https://git.openjdk.org/jdk/pull/27039/files/2795ea44..1ea3a8ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27039/head:pull/27039 PR: https://git.openjdk.org/jdk/pull/27039 From duke at openjdk.org Wed Sep 3 09:14:47 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Wed, 3 Sep 2025 09:14:47 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v27] In-Reply-To: References: <3Vs91nphdprtkbEIA7PElDhEIyC8bO5lr0VxsXsrZp8=.dedd1ff4-c013-4bc5-bc83-9e17309ab458@github.com> Message-ID: On Wed, 3 Sep 2025 03:58:56 GMT, Prasanta Sadhukhan wrote: >> The GlassPaneOverlappingTestBase tests are not multi-frame tests, they do not use multiple frames where each frame has an AWT component to test Swing with that AWT component. If the frame is disposed in the SimpleOverlappingTestBase class, the frame will disappear and the test will fail. This applies only the the GlassPane tests (extending GlassPaneOverlappingTestBase) > > But the frame should be disposed *after* the test is executed, more specifically in finally block so am still not sure about this addition @prsadhuk My understanding is that test which extend `GlassPaneOverlappingTestBase` use only on frame for testing all AWT component. If you have a look at implementation of method `prepareControls` in both `GlassPaneOverlappingTestBase` and in `SimpleOverlappingTestBase`, you will notice that in `GlassPaneOverlappingTestBase` we create only one instance frame, and we use this same frame for the whole lifecycle of the test for all AWT component. `performTest` method will test an AWT component at a time, and if we dispose of the ancestor frame, the test fails, because the next AWT component is expected to run on the same ancestor frame. On the contrary, in tests extending `SimpleOverlappingTestBase` each AWT component runs on its own Frame which is created on `prepareControls` method, so disposing that frame at the end of the `performTest` method, does not affect the next AWT components, because they have their own frame. For this reason I introduced the flag `multiFramesTest` to differentiate between multi-frames tests (Extending `SimpleOverlappingTestBase`) and one frame tests (Extending `GlassPaneOverlappingTestBase`). On slightly different topic, parent class OverlappingTestBase have method `cleanup` which is never used, but we can use to dispose of frame created by `GlassPaneOverlappingTestBase`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2318328990 From duke at openjdk.org Wed Sep 3 09:22:17 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Wed, 3 Sep 2025 09:22:17 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: Message-ID: > 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 46 additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8158801 - Disposes frame at the end of testing. - Moves latch logic inside ancestor frame block - Merge branch 'openjdk:master' into jdk-8158801 - Disposes frames after each AWT component test - Removes redundant code for centring frames - 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 - ... and 36 more: https://git.openjdk.org/jdk/compare/ee7a9870...a62416a9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/bbeda980..a62416a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=28-29 Stats: 5843 lines in 607 files changed: 2964 ins; 1209 del; 1670 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 myankelevich at openjdk.org Wed Sep 3 13:16:42 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 3 Sep 2025 13:16:42 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v3] In-Reply-To: References: Message-ID: <9oev4uswx-rSqW5tzmkV9Kh6t2uL-78wMNx8kB4eTkI=.27b2e5b5-ed82-4300-8b97-d3e22780f1f5@github.com> On Wed, 3 Sep 2025 05:23:02 GMT, Manukumar V S wrote: >> Issue: >> java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." >> I have seen it failing in all platforms, but predominantly in macos platform. >> It fails sometimes in CI also. >> >> Fix: >> Added a countdownlatch for tracking focusGained >> Added screenshot logic >> >> Testing: >> Tested in all mach5 platforms and got all PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed: formatting changes test/jdk/java/awt/Focus/ComponentLostFocusTest.java line 35: > 33: import java.awt.EventQueue; > 34: import java.awt.FlowLayout; > 35: import java.awt.Frame; nit: copyright year :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27039#discussion_r2318942750 From dgredler at openjdk.org Wed Sep 3 14:00:46 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Wed, 3 Sep 2025 14:00:46 GMT Subject: RFR: 4138921: TextLayout handling of empty strings In-Reply-To: References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: On Wed, 3 Sep 2025 00:44:36 GMT, Sergey Bylokhov wrote: >> `TextLayout` should deal more gracefully with zero length strings. Currently the exception listed below is the one that is thrown. >> >> `new TextLayout("", f, new FontRenderContext(null, false, false));` >> >>> Exception in thread "main" java.lang.IllegalArgumentException: Zero length >>> string passed to TextLayout constructor. >>> at java.lang.Throwable.(Compiled Code) >>> at java.lang.Exception.(Compiled Code) >>> at java.lang.RuntimeException.(Compiled Code) >>> at java.lang.IllegalArgumentException.(Compiled Code) >>> at java.awt.font.TextLayout.(Compiled Code) >>> at test.main(Compiled Code) >> >> **REVIEWER NOTE:** Please check the empty-string `TextLayout` behavior documented in `TextLayoutConstructorTest` carefully; a badly-behaving empty `TextLayout` is probably worse than a `TextLayout` which doesn't allow empty strings... > > src/java.desktop/share/classes/java/awt/font/TextLayout.java line 516: > >> 514: >> 515: int start = text.getBeginIndex(); >> 516: int limit = text.getEndIndex(); > > Why do we call text.first() twice, on line 516 and in the loop init block? I'm not sure, I don't think it's necessary. The code has been this way since the first public commit, so there is no hint in the public git history. Should I remove it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26947#discussion_r2319077084 From prr at openjdk.org Wed Sep 3 17:42:42 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 3 Sep 2025 17:42:42 GMT Subject: RFR: 4138921: TextLayout handling of empty strings In-Reply-To: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: On Tue, 26 Aug 2025 17:40:12 GMT, Daniel Gredler wrote: > `TextLayout` should deal more gracefully with zero length strings. Currently the exception listed below is the one that is thrown. > > `new TextLayout("", f, new FontRenderContext(null, false, false));` > >> Exception in thread "main" java.lang.IllegalArgumentException: Zero length >> string passed to TextLayout constructor. >> at java.lang.Throwable.(Compiled Code) >> at java.lang.Exception.(Compiled Code) >> at java.lang.RuntimeException.(Compiled Code) >> at java.lang.IllegalArgumentException.(Compiled Code) >> at java.awt.font.TextLayout.(Compiled Code) >> at test.main(Compiled Code) > > **REVIEWER NOTE:** Please check the empty-string `TextLayout` behavior documented in `TextLayoutConstructorTest` carefully; a badly-behaving empty `TextLayout` is probably worse than a `TextLayout` which doesn't allow empty strings... Marked as reviewed by prr (Reviewer). I have updated the CSR and marked it as reviewed. You may now move it to 'finalized'. ------------- PR Review: https://git.openjdk.org/jdk/pull/26947#pullrequestreview-3181777334 PR Comment: https://git.openjdk.org/jdk/pull/26947#issuecomment-3250166233 From prr at openjdk.org Wed Sep 3 17:42:44 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 3 Sep 2025 17:42:44 GMT Subject: RFR: 4138921: TextLayout handling of empty strings In-Reply-To: References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: On Wed, 3 Sep 2025 13:57:41 GMT, Daniel Gredler wrote: >> src/java.desktop/share/classes/java/awt/font/TextLayout.java line 516: >> >>> 514: >>> 515: int start = text.getBeginIndex(); >>> 516: int limit = text.getEndIndex(); >> >> Why do we call text.first() twice, on line 516 and in the loop init block? > > I'm not sure, I don't think it's necessary. The code has been this way since the first public commit, so there is no hint in the public git history. Should I remove it? Looks to me like it can be safely removed (the one on line 516/518) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26947#discussion_r2319714886 From dgredler at openjdk.org Wed Sep 3 20:11:24 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Wed, 3 Sep 2025 20:11:24 GMT Subject: RFR: 4138921: TextLayout handling of empty strings [v2] In-Reply-To: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: > `TextLayout` should deal more gracefully with zero length strings. Currently the exception listed below is the one that is thrown. > > `new TextLayout("", f, new FontRenderContext(null, false, false));` > >> Exception in thread "main" java.lang.IllegalArgumentException: Zero length >> string passed to TextLayout constructor. >> at java.lang.Throwable.(Compiled Code) >> at java.lang.Exception.(Compiled Code) >> at java.lang.RuntimeException.(Compiled Code) >> at java.lang.IllegalArgumentException.(Compiled Code) >> at java.awt.font.TextLayout.(Compiled Code) >> at test.main(Compiled Code) > > **REVIEWER NOTE:** Please check the empty-string `TextLayout` behavior documented in `TextLayoutConstructorTest` carefully; a badly-behaving empty `TextLayout` is probably worse than a `TextLayout` which doesn't allow empty strings... Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary call to text.first() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26947/files - new: https://git.openjdk.org/jdk/pull/26947/files/2f3f2fbd..5f6b3ef5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26947&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26947&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26947.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26947/head:pull/26947 PR: https://git.openjdk.org/jdk/pull/26947 From prr at openjdk.org Wed Sep 3 22:30:46 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 3 Sep 2025 22:30:46 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v4] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 11:26:30 GMT, GennadiyKrivoshein wrote: >> The fix for the https://bugs.openjdk.org/browse/JDK-8251928. >> >> **Description**. >> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. >> >> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): >> 1. Convert the user-space point, size, or rectangle value to device space coordinates; >> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; >> 3. Convert the normalized value back to user space; >> 4. Draw your content using the adjusted value. >> >> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. >> The 2-nd step is a drawing process in the java code (without changes). >> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. >> The 4-th step is a drawing process in the native code (without changes). >> >> **Tests**. >> I run all tests from javax.print package and there is no any regression. >> New test covers macOS and Linux only because we know its default DPI - 300. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > remove setDevClip usage. Update names. Handle page format orientation. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 854: > 852: double scaleY = getYRes()/ USER_SPACE_DPI; > 853: PageFormat scaledPage = scalePageFormat(page, scaleX, scaleY); > 854: SurfaceData sd = CPrinterSurfaceData.createData(scaledPage, context); // Just stores page into an ivar This bleeds through in an application visible way. Take your test case and add this code to the print(..) method and you'll see what I mean. GraphicsConfiguration gc = g2.getDeviceConfiguration(); Rectangle bds = gc.getBounds(); System.out.println("bds="+bds); For me it then prints bds=java.awt.Rectangle[x=0,y=0,width=2550,height=3300] src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 904: > 902: new BufferedImage( > 903: (int)Math.round(scaledPageFormat.getWidth()), > 904: (int)Math.round(scaledPageFormat.getHeight()), Wow, that is going to be one big BufferedImage. This doesn't seem right or necessary for a PeekGraphics. Look at RasterPrinterGraphics. It uses a 1x1 image (!) It just sets things up so that when the app asks for the graphics config it gets the page dimensions back. src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.h line 29: > 27: * Some default values for invalid CoreGraphics display ID. > 28: */ > 29: #define DEFAULT_DEVICE_WIDTH 1024 You should revert adding this file and put these defines back into CGraphicsDevice.m. The only thing you us from here is DEFAULT_DEVICE_DPI and that appears to be because it is "72", but where you are using it in PrinterView.m it is really based on the 72 DPI default defined by Java 2D. See the class doc for Graphics2D. And also the size for java.awt.print.Paper is specified in points too. I suggest just creating a local variable in PrinterView.m src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m line 119: > 117: double scaleY = DEFAULT_DEVICE_DPI / vRes; > 118: if (scaleX != 1 || scaleY != 1) { > 119: if ([[[NSPrintOperation currentOperation] printInfo] orientation] == NSPortraitOrientation) { This fails to compile for me src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:119:79: error: comparison of different enumeration types ('NSPaperOrientation' (aka 'enum NSPaperOrientation') and 'enum NSPrintingOrientation') [-Werror,-Wenum-compare] 119 | if ([[[NSPrintOperation currentOperation] printInfo] orientation] == NSPortraitOrientation) { | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~ It should be NSPaperOrientationPortrait ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2320362696 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2320346423 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2319840369 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2319952392 From dnguyen at openjdk.org Thu Sep 4 00:02:43 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 4 Sep 2025 00:02:43 GMT Subject: RFR: 8364363: Update and automate jtreg manual test [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 10:13:04 GMT, Alexey Ivanov wrote: >> @aivanov-jdk Is problem-listing this test the ideal solution? > > @DamonGuy If you believe there's a bug on macOS, I agree with your evaluation, then problem-listing is a good solution. > > For completeness, post a link to the bug that you (will) submit. @aivanov-jdk I have filed [JDK-8366843](https://bugs.openjdk.org/browse/JDK-8366843) to track this bug. Can you re-review this otherwise? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2320499260 From liach at openjdk.org Thu Sep 4 00:15:49 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 00:15:49 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 00:24:01 GMT, Damon Nguyen wrote: >> Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Add finally block src/java.desktop/share/classes/java/awt/Robot.java line 792: > 790: /** > 791: * A convenience method that simulates clicking a mouse button by calling {@code mousePress}, {@code mouseRelease}, > 792: * and {@code waitForIdle}. Invokes {@code waitForIdle} with a default delay of 20 milliseconds after Suggestion: * and {@code waitForIdle}. Invokes {@code waitForIdle} with a default delay of {@value #DEFAULT_STEP_DELAY} milliseconds after This renders `20` as a link that links to the constant that users can use. src/java.desktop/share/classes/java/awt/Robot.java line 855: > 853: * > 854: * @implSpec Invokes {@link #mouseMove(int, int) mouseMove} with a default > 855: * {@link #DEFAULT_STEP_LENGTH step-length} and {@link #DEFAULT_STEP_DELAY step-delay}. You can use: * @implSpec Invokes {@link #mouseMove(int, int) mouseMove} with a step-length * of {@value #DEFAULT_STEP_LENGTH} and a step-delay of {@value #DEFAULT_STEP_DELAY}. Renders like: > Invokes [`mouseMove`]() with a step-length of [`2`]() and a a step-delay of [`20`](). Same for other sites. src/java.desktop/share/classes/java/awt/Robot.java line 977: > 975: public synchronized void type(int keycode) { > 976: keyPress(keycode); > 977: waitForIdle(20); Should this use `DEFAULT_STEP_DELAY` too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2320487184 PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2320510533 PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2320511282 From serb at openjdk.org Thu Sep 4 02:54:42 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 4 Sep 2025 02:54:42 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 05:23:02 GMT, Manukumar V S wrote: >> Issue: >> java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." >> I have seen it failing in all platforms, but predominantly in macos platform. >> It fails sometimes in CI also. >> >> Fix: >> Added a countdownlatch for tracking focusGained >> Added screenshot logic >> >> Testing: >> Tested in all mach5 platforms and got all PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed: formatting changes Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27039#pullrequestreview-3183225499 From mvs at openjdk.org Thu Sep 4 03:36:56 2025 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 4 Sep 2025 03:36:56 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v4] In-Reply-To: References: Message-ID: > Issue: > java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." > I have seen it failing in all platforms, but predominantly in macos platform. > It fails sometimes in CI also. > > Fix: > Added a countdownlatch for tracking focusGained > Added screenshot logic > > Testing: > Tested in all mach5 platforms and got all PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Copyright year changed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27039/files - new: https://git.openjdk.org/jdk/pull/27039/files/1ea3a8ae..172c088d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=02-03 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27039/head:pull/27039 PR: https://git.openjdk.org/jdk/pull/27039 From mvs at openjdk.org Thu Sep 4 03:40:25 2025 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 4 Sep 2025 03:40:25 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v5] In-Reply-To: References: Message-ID: <0ZhkX9_Rhl6vck_jDI37GaF6UaGvkkRoId36GKv75Cc=.ba414d24-537f-4785-8371-e17b4f39c09e@github.com> > Issue: > java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." > I have seen it failing in all platforms, but predominantly in macos platform. > It fails sometimes in CI also. > > Fix: > Added a countdownlatch for tracking focusGained > Added screenshot logic > > Testing: > Tested in all mach5 platforms and got all PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Removed unwanted changes from .gitignore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27039/files - new: https://git.openjdk.org/jdk/pull/27039/files/172c088d..a74a0af8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27039&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27039/head:pull/27039 PR: https://git.openjdk.org/jdk/pull/27039 From psadhukhan at openjdk.org Thu Sep 4 05:00:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 4 Sep 2025 05:00:49 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: Message-ID: <6C2R48akY19eZLs27YIAdstx7r1uY8SYtTiUUeS0Ic4=.1b00a731-5f08-448b-a0c2-d827b6f8f18d@github.com> On Wed, 3 Sep 2025 09:22:17 GMT, Khalid Boulanouare 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 46 additional commits since the last revision: > > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frame at the end of testing. > - Moves latch logic inside ancestor frame block > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frames after each AWT component test > - Removes redundant code for centring frames > - 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 > - ... and 36 more: https://git.openjdk.org/jdk/compare/fe5ff004...a62416a9 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3183424416 From psadhukhan at openjdk.org Thu Sep 4 05:00:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 4 Sep 2025 05:00:49 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v27] In-Reply-To: References: <3Vs91nphdprtkbEIA7PElDhEIyC8bO5lr0VxsXsrZp8=.dedd1ff4-c013-4bc5-bc83-9e17309ab458@github.com> Message-ID: On Wed, 3 Sep 2025 09:12:14 GMT, Khalid Boulanouare wrote: >> But the frame should be disposed *after* the test is executed, more specifically in finally block so am still not sure about this addition > > @prsadhuk My understanding is that test which extend `GlassPaneOverlappingTestBase` use only on frame for testing all AWT component. If you have a look at implementation of method `prepareControls` in both `GlassPaneOverlappingTestBase` and in `SimpleOverlappingTestBase`, you will notice that in `GlassPaneOverlappingTestBase` we create only one instance frame, and we use this same frame for the whole lifecycle of the test for all AWT component. `performTest` method will test an AWT component at a time, and if we dispose of the ancestor frame, the test fails, because the next AWT component is expected to run on the same ancestor frame. On the contrary, in tests extending `SimpleOverlappingTestBase` each AWT component runs on its own Frame which is created on `prepareControls` method, so disposing that frame at the end of the `performTest` method, does not affect the next AWT components, because they have their own frame. > > For this reason I introduced the flag `multiFramesTest` to differentiate between multi-frames tests (Extending `SimpleOverlappingTestBase`) and one frame tests (Extending `GlassPaneOverlappingTestBase`). > > > On slightly different topic, parent class OverlappingTestBase have method `cleanup` which is never used, but we can use to dispose of frame created by `GlassPaneOverlappingTestBase`. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2320832680 From duke at openjdk.org Thu Sep 4 06:54:56 2025 From: duke at openjdk.org (Sarvesh Kumar Jain) Date: Thu, 4 Sep 2025 06:54:56 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist Message-ID: The test is problem listed with incorrect bug JDK-6849371, The bug JDK-6849371 is for a different test and it is closed. A new bug has been raised for ChoiceMouseWheelTest.java test failure. ------------- Commit messages: - correct typographical error - 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist Changes: https://git.openjdk.org/jdk/pull/27085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27085&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366750 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27085/head:pull/27085 PR: https://git.openjdk.org/jdk/pull/27085 From aivanov at openjdk.org Thu Sep 4 08:09:43 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 08:09:43 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v2] In-Reply-To: References: <5e2QF5E4i1eeNe5DcRAU_9m-ezKUL0rKfJSjXYkSQ7A=.4c1510f3-3862-4994-842c-9e9859f6ae6b@github.com> Message-ID: <70r6uz458fax8W2EKDxuDJxbYb6tcKTcwMA1VxFbx_I=.a6d97f99-5242-4705-8fe8-c2e7379d1ae7@github.com> On Tue, 26 Aug 2025 22:36:33 GMT, Damon Nguyen wrote: > Do I have to differentiate between X11 and Wayland though? Do you think it's important? Unless proven otherwise, I say this applies to both modes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2321213794 From aivanov at openjdk.org Thu Sep 4 08:23:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 08:23:44 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v4] In-Reply-To: <_m2l5pTKApzMQM6zrtzdhKOuYFfttQGfpjjTaeTYYFE=.ffa5cc6d-f557-44a6-bb9c-3e46ee1e14ac@github.com> References: <_m2l5pTKApzMQM6zrtzdhKOuYFfttQGfpjjTaeTYYFE=.ffa5cc6d-f557-44a6-bb9c-3e46ee1e14ac@github.com> Message-ID: On Thu, 28 Aug 2025 05:51:40 GMT, Damon Nguyen wrote: >> When testing jtreg manual tests, some tests were out of date. This PR is an attempt at updating the test and automating it. >> >> `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. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Review comment edits Changes requested by aivanov (Reviewer). test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 85: > 83: System.out.println(me.toString()); > 84: throw new RuntimeException("Test failed. Mouse dragged " + > 85: "event detected."); Suggestion: throw new RuntimeException("Mouse dragged event detected."); Being concise is better, isn't it? An exception is already an indicator that the test failed, let's just provide the reason. test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 94: > 92: System.out.println(me.toString()); > 93: throw new RuntimeException("Test failed. Mouse pressed " + > 94: "event detected."); Suggestion: throw new RuntimeException("Mouse pressed event detected."); Similarly. test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 127: > 125: loc = p; > 126: }); > 127: robot.mouseMove(loc.x - 10, loc.y + 20); Suggestion: EventQueue.invokeAndWait(() -> { Point p = list.getLocationOnScreen(); p.translate(list.getWidth() - 10, 20); loc = p; }); robot.mouseMove(loc.x, loc.y); Prepare the correct location inside `invokeAndWait`. The offsets could be declared constants, which may result in clearer code. test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 131: > 129: for (int i = 0; i < 30; i++) { > 130: robot.mouseMove(loc.x, loc.y + 1); > 131: } Suggestion: for (int i = 0; i < 30; i++) { robot.mouseMove(loc.x, loc.y + i); } I forgot to replace `1` with `i` in my earlier suggestion. This for-loop depends on the fact that `loc` contains the initial location for dragging the mouse. That is, the initial `robot.mouseMove` has to have arguments `(loc.x, loc.y)`, otherwise the mouse jumps `(+10, -20)` pixels. ------------- PR Review: https://git.openjdk.org/jdk/pull/26636#pullrequestreview-3183967641 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2321219872 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2321221314 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2321230525 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2321244068 From smandalika at openjdk.org Thu Sep 4 08:32:23 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 4 Sep 2025 08:32:23 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v3] In-Reply-To: References: Message-ID: > 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. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review Feedback: Removed redundant RTEs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26471/files - new: https://git.openjdk.org/jdk/pull/26471/files/e7091014..d766b695 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26471&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26471&range=01-02 Stats: 44 lines in 1 file changed: 1 ins; 26 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26471/head:pull/26471 PR: https://git.openjdk.org/jdk/pull/26471 From smandalika at openjdk.org Thu Sep 4 08:57:42 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 4 Sep 2025 08:57:42 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v3] In-Reply-To: References: Message-ID: <9YIChkmLgi_0QWMeuw4zd2Bu0S3Xz6YYYPPyaA1H3EM=.6a59ff88-9f50-4dfd-be3d-ff45a3916fe7@github.com> On Thu, 4 Sep 2025 08:32:23 GMT, Srinivas Mandalika 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. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Feedback: Removed redundant RTEs Changed as suggested. All redudant RTEs were removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26471#issuecomment-3252579248 From duke at openjdk.org Thu Sep 4 11:24:53 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 11:24:53 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v31] In-Reply-To: References: Message-ID: > 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 47 additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8158801 - Merge branch 'openjdk:master' into jdk-8158801 - Disposes frame at the end of testing. - Moves latch logic inside ancestor frame block - Merge branch 'openjdk:master' into jdk-8158801 - Disposes frames after each AWT component test - Removes redundant code for centring frames - Merge branch 'openjdk:master' into jdk-8158801 - Merge branch 'openjdk:master' into jdk-8158801 - Centers missed frames in the middle of screen - ... and 37 more: https://git.openjdk.org/jdk/compare/99a2c001...54087fa9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/a62416a9..54087fa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=29-30 Stats: 2394 lines in 186 files changed: 1658 ins; 190 del; 546 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 Thu Sep 4 11:24:57 2025 From: duke at openjdk.org (duke) Date: Thu, 4 Sep 2025 11:24:57 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:22:17 GMT, Khalid Boulanouare 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 46 additional commits since the last revision: > > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frame at the end of testing. > - Moves latch logic inside ancestor frame block > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frames after each AWT component test > - Removes redundant code for centring frames > - 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 > - ... and 36 more: https://git.openjdk.org/jdk/compare/ac65d7e8...a62416a9 @kboulanou Your change (at version 54087fa9c47f55fbe62e9050f410de49bed58803) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3253220234 From aivanov at openjdk.org Thu Sep 4 11:29:57 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 11:29:57 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:22:17 GMT, Khalid Boulanouare 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 46 additional commits since the last revision: > > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frame at the end of testing. > - Moves latch logic inside ancestor frame block > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frames after each AWT component test > - Removes redundant code for centring frames > - 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 > - ... and 36 more: https://git.openjdk.org/jdk/compare/e79df9f1...a62416a9 Changes requested by aivanov (Reviewer). test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 63: > 61: { > 62: multiFramesTest = false; > 63: } I prefer this is done in a constructor rather than a simple initialiser, it just makes the intent clearer. The same applies to setting the initial value of `multiFramesTest` in `SimpleOverlappingTestBase`. `SimpleOverlappingTestBase` has constructors, `GlassPaneOverlappingTestBase` has constructors too. I believe `multiFramesTest` doesn't change, and if you initialise it in a constructor, you can make it `final`, and I'm always for using immutable fields. test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 125: > 123: final CountDownLatch latch = new CountDownLatch(1); > 124: f.addFocusListener(new FocusAdapter() { > 125: @Override public void focusGained(FocusEvent e) { Suggestion: f.addFocusListener(new FocusAdapter() { @Override public void focusGained(FocusEvent e) { I prefer a multi-line version of this. test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 129: > 127: } > 128: }); > 129: if (testResize) { Suggestion: }); if (testResize) { Let's add a blank line to introduce logical blocks in this long piece of code. test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 145: > 143: } else { > 144: f.requestFocusInWindow(); > 145: } Is it possible to add the listener earlier to ensure the latch is released in the focus listener? test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 148: > 146: } > 147: }); > 148: } catch (InterruptedException ex) { Although this is existing code, I propose merging the two catch block into one by using `InterruptedException | InvocationTargetException` as the type. test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 165: > 163: return wasLWClicked; > 164: } else { > 165: latch.countDown(); I believe this is not required, the test will not block even if the latch isn't released. test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 169: > 167: } > 168: } > 169: protected void cleanup(){ Suggestion: } @Override protected void cleanup(){ Add a blank line between methods, and add the `@Override` annotation. test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 1: > 1: /* Remove `import java.awt.Color;` test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java line 1: > 1: /* Remove `import java.awt.Color;` test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 1: > 1: /* Could you expand the wildcard imports, please? test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 1: > 1: /* Could you also move `TestPassedException` inside `MixingPanelsResizing` and make it `static`? This would resolve multiple definitions of `TestPassedException` when viewing source for AWT_Mixing in an IDE. test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 1: > 1: /* Could you also move `TestPassedException` inside `OverlappingTestBase` and make it `static`? This would resolve multiple definitions of `TestPassedException` when viewing source for AWT_Mixing in an IDE. test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 264: > 262: embedder.setPreferredSize(new Dimension(150, 150)); > 263: container.add(embedder); > 264: if(container instanceof Window){ Suggestion: if (container instanceof Window){ ------------- PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3184521964 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321616385 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321595814 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321636770 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321642154 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321646046 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321655342 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321652023 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321678210 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321679963 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321687965 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321703332 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321710616 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321711250 From aivanov at openjdk.org Thu Sep 4 11:29:58 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 11:29:58 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:19:10 GMT, Alexey Ivanov 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 46 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into jdk-8158801 >> - Disposes frame at the end of testing. >> - Moves latch logic inside ancestor frame block >> - Merge branch 'openjdk:master' into jdk-8158801 >> - Disposes frames after each AWT component test >> - Removes redundant code for centring frames >> - 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 >> - ... and 36 more: https://git.openjdk.org/jdk/compare/e79df9f1...a62416a9 > > test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 264: > >> 262: embedder.setPreferredSize(new Dimension(150, 150)); >> 263: container.add(embedder); >> 264: if(container instanceof Window){ > > Suggestion: > > if (container instanceof Window){ I didn't notice the missing space before the opening brace: if (container instanceof Window) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321731571 From aivanov at openjdk.org Thu Sep 4 11:30:02 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 11:30:02 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v31] In-Reply-To: References: Message-ID: <9X4fgBUY2K7ccS_0sjpamQUL04NlnIl82ykDIeXycSg=.53ff9fcd-1aa2-486e-8113-1a12210ca82f@github.com> On Thu, 4 Sep 2025 11:24:53 GMT, Khalid Boulanouare 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 47 additional commits since the last revision: > > - Merge branch 'openjdk:master' into jdk-8158801 > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frame at the end of testing. > - Moves latch logic inside ancestor frame block > - Merge branch 'openjdk:master' into jdk-8158801 > - Disposes frames after each AWT component test > - Removes redundant code for centring frames > - Merge branch 'openjdk:master' into jdk-8158801 > - Merge branch 'openjdk:master' into jdk-8158801 > - Centers missed frames in the middle of screen > - ... and 37 more: https://git.openjdk.org/jdk/compare/f4bbc310...54087fa9 test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 55: > 53: > 54: protected boolean multiFramesTest = true; > 55: /** Suggestion: protected boolean multiFramesTest = true; /** Leave a blank line between members of a class, especially if the members aren't closely related or have comments. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 179: > 177: > 178: clickAndBlink(robot, lLoc); > 179: if(ancestor != null && multiFramesTest){ Suggestion: if (ancestor != null && multiFramesTest) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321736151 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321732936 From aivanov at openjdk.org Thu Sep 4 11:32:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 11:32:55 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: Message-ID: <-c97OO0NEziJ2ymYpVKNADjqej86VmGgEmL3gtl1k64=.f486f038-cf3b-4f04-859c-e77a794fe717@github.com> On Thu, 4 Sep 2025 10:49:40 GMT, Alexey Ivanov 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 46 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into jdk-8158801 >> - Disposes frame at the end of testing. >> - Moves latch logic inside ancestor frame block >> - Merge branch 'openjdk:master' into jdk-8158801 >> - Disposes frames after each AWT component test >> - Removes redundant code for centring frames >> - 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 >> - ... and 36 more: https://git.openjdk.org/jdk/compare/3ec7180a...a62416a9 > > test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 63: > >> 61: { >> 62: multiFramesTest = false; >> 63: } > > I prefer this is done in a constructor rather than a simple initialiser, it just makes the intent clearer. > > The same applies to setting the initial value of `multiFramesTest` in `SimpleOverlappingTestBase`. > > `SimpleOverlappingTestBase` has constructors, `GlassPaneOverlappingTestBase` has constructors too. I believe `multiFramesTest` doesn't change, and if you initialise it in a constructor, you can make it `final`, and I'm always for using immutable fields. The above approach may require additional refactoring, and I see that class initialisers are used to set values of flags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321744283 From duke at openjdk.org Thu Sep 4 12:18:28 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 12:18:28 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v32] In-Reply-To: References: Message-ID: <3ZigyqfIZhJ-U-YXtqFVaFGGiasoNSkLw2Kf5u3uskk=.f1ae7bab-eaec-452a-b04b-d3eca373bc85@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/SimpleOverlappingTestBase.java Co-authored-by: Alexey Ivanov - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java Co-authored-by: Alexey Ivanov - Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/54087fa9..016ef8f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=30-31 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25971.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971 PR: https://git.openjdk.org/jdk/pull/25971 From duke at openjdk.org Thu Sep 4 12:26:47 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 12:26:47 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: <-c97OO0NEziJ2ymYpVKNADjqej86VmGgEmL3gtl1k64=.f486f038-cf3b-4f04-859c-e77a794fe717@github.com> References: <-c97OO0NEziJ2ymYpVKNADjqej86VmGgEmL3gtl1k64=.f486f038-cf3b-4f04-859c-e77a794fe717@github.com> Message-ID: On Thu, 4 Sep 2025 11:30:13 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 63: >> >>> 61: { >>> 62: multiFramesTest = false; >>> 63: } >> >> I prefer this is done in a constructor rather than a simple initialiser, it just makes the intent clearer. >> >> The same applies to setting the initial value of `multiFramesTest` in `SimpleOverlappingTestBase`. >> >> `SimpleOverlappingTestBase` has constructors, `GlassPaneOverlappingTestBase` has constructors too. I believe `multiFramesTest` doesn't change, and if you initialise it in a constructor, you can make it `final`, and I'm always for using immutable fields. > > The above approach may require additional refactoring, and I see that class initialisers are used to set values of flags. I suggest the following changes : public GlassPaneOverlappingTestBase() { this(true); } public GlassPaneOverlappingTestBase(boolean defaultClickValidation) { super(defaultClickValidation); multiFramesTest =false; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2321919151 From duke at openjdk.org Thu Sep 4 12:50:43 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 12:50:43 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v33] In-Reply-To: References: Message-ID: > 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: Makes multiFramesTest final and code readibility better ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/016ef8f6..a6f87e76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=31-32 Stats: 44 lines in 6 files changed: 22 ins; 12 del; 10 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 Thu Sep 4 12:53:03 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 12:53:03 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v34] In-Reply-To: References: Message-ID: > 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: Update test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/a6f87e76..68fc7361 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=32-33 Stats: 2 lines in 1 file changed: 2 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 Thu Sep 4 12:57:10 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 12:57:10 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v35] In-Reply-To: References: Message-ID: <40aR5O9zLGzYEzOP4Bc6MN2puowQL0b_Q2m9ybtEkXA=.36a61d6a-2857-4308-a24b-b58401df9eaa@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 uncessary latch count down ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/68fc7361..6fdad620 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=33-34 Stats: 1 line in 1 file changed: 0 ins; 1 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 Thu Sep 4 13:09:57 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 13:09:57 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: Message-ID: <8nYVsXIkWdaFEqNkvAQED8H6T6Fs61mM_NCL68-hBjI=.be85d887-d437-4188-a07d-50e0edb0a42b@github.com> On Thu, 4 Sep 2025 10:57:21 GMT, Alexey Ivanov 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 46 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into jdk-8158801 >> - Disposes frame at the end of testing. >> - Moves latch logic inside ancestor frame block >> - Merge branch 'openjdk:master' into jdk-8158801 >> - Disposes frames after each AWT component test >> - Removes redundant code for centring frames >> - 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 >> - ... and 36 more: https://git.openjdk.org/jdk/compare/d2fe5bd2...a62416a9 > > test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 145: > >> 143: } else { >> 144: f.requestFocusInWindow(); >> 145: } > > Is it possible to add the listener earlier to ensure the latch is released in the focus listener? @aivanov-jdk as you have suggested, the focus owner and the latch are not needed because the GlassPaneOverlappingTestBase is using only one frame. I will refactor the code based on this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322081059 From duke at openjdk.org Thu Sep 4 13:15:05 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 13:15:05 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v36] In-Reply-To: References: Message-ID: <0Bvw0sXgQaiYprqJms5U-Mo7mnCMyYFqlIU_DVAoV-4=.0bb8a0b7-5d0e-4b24-9f08-4306ee3b880d@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: Initialized MULTI_FRAMES_TEST using a method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/6fdad620..eeef198f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=35 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=34-35 Stats: 34 lines in 2 files changed: 8 ins; 23 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 Thu Sep 4 13:15:05 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 13:15:05 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v30] In-Reply-To: References: <-c97OO0NEziJ2ymYpVKNADjqej86VmGgEmL3gtl1k64=.f486f038-cf3b-4f04-859c-e77a794fe717@github.com> Message-ID: On Thu, 4 Sep 2025 12:24:29 GMT, Khalid Boulanouare wrote: >> The above approach may require additional refactoring, and I see that class initialisers are used to set values of flags. > > I suggest the following changes : > > > public GlassPaneOverlappingTestBase() { > this(true); > } > > public GlassPaneOverlappingTestBase(boolean defaultClickValidation) { > super(defaultClickValidation); > multiFramesTest =false; > } The previous suggestion will not work, please ignore it. I am looking at creating a method to set the value of MULTI_FRAMES_TEST, this will allow us to do the changes only in the 2 parent classes. I will try this and confirm if the tests pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322094431 From duke at openjdk.org Thu Sep 4 13:20:32 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 13:20:32 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: References: Message-ID: > 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: Organizes imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/eeef198f..8bb09e27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=35-36 Stats: 9 lines in 2 files changed: 2 ins; 7 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 aivanov at openjdk.org Thu Sep 4 14:33:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 14:33:54 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: References: Message-ID: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> On Thu, 4 Sep 2025 13:20:32 GMT, Khalid Boulanouare 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: > > Organizes imports Changes requested by aivanov (Reviewer). test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 28: > 26: import java.awt.event.MouseAdapter; > 27: import java.awt.event.MouseEvent; > 28: import java.lang.Override; All the classes from `java.lang.*` are imported implicitly. That is, remove `import java.lang.Override`. test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 100: > 98: protected boolean isMultiFramesTest(){ > 99: return false; > 100: } There should be no blank line before the closing brace of a method or constructor. That is the snippet should like this: public GlassPaneOverlappingTestBase(boolean defaultClickValidation) { super(defaultClickValidation); } @Override protected boolean isMultiFramesTest() { return false; } test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 115: > 113: > 114: if (testResize) { > 115: wasLWClicked = false; May I also suggest reversing the condition: if (!testResize) { return true; } This brings the shorter `else` section higher, and it's the end of the test if `testResize` is `false`. The testing for resize then is written with reduced indentation. test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 315: > 313: mainThread.interrupt(); > 314: }//fail() > 315: static class TestPassedException extends RuntimeException { Suggestion: }//fail() static class TestPassedException extends RuntimeException { test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 318: > 316: } > 317: }// class JButtonInGlassPane > 318: Just one blank line is enough. That is you should see only one blank line in your editor in the end of the file (some editors, like `vim`, hide this very last line). test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 692: > 690: }//fail() > 691: static class TestPassedException extends RuntimeException { > 692: } Suggestion: }//fail() static class TestPassedException extends RuntimeException { } Add blank lines between class members, it improves readability, the code is easier to scan quickly with eyes. test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 694: > 692: } > 693: }// class LWComboBox > 694: One blank line is enough. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 55: > 53: } > 54: > 55: protected final boolean MULTI_FRAMES_TEST ; Since you introduced a method that returns whether the current instance is a multi-frame test or not, you don't need a field for this ? just call the method instead of using a field, moreover it's used once only. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 73: > 71: } > 72: > 73: protected boolean isMultiFramesTest(){ Suggestion: protected boolean isMultiFramesTest() { test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 76: > 74: return true; > 75: } > 76: public SimpleOverlappingTestBase() { Suggestion: } public SimpleOverlappingTestBase() { test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 185: > 183: > 184: clickAndBlink(robot, lLoc); > 185: if (ancestor != null && MULTI_FRAMES_TEST) { Suggestion: if (ancestor != null && isMultiFramesTest()) { If you introduce the method to return the flag and the flag is used in one place only, call the method instead of storing its value in field. ------------- PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3185552759 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322334990 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322344365 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322371185 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322389259 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322380162 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322387677 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322384844 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322399919 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322396478 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322392789 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322395914 From aivanov at openjdk.org Thu Sep 4 14:41:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 14:41:51 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: References: Message-ID: <5fuaJG-TKPgLnBoXFq0gdc696lWgkfIDAyzkQBZ6PcM=.8bcef1cf-4ba1-416c-941a-39e507f034ac@github.com> On Thu, 4 Sep 2025 13:20:32 GMT, Khalid Boulanouare 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: > > Organizes imports test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 36: > 34: > 35: /** > 36: * Base class for testing overlapping of Swing and AWT component put into GlassPane. My IDE highlights that `ancestorLoc` is never used now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322423425 From duke at openjdk.org Thu Sep 4 15:49:47 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 15:49:47 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> References: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> Message-ID: On Thu, 4 Sep 2025 14:12:50 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Organizes imports > > test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 28: > >> 26: import java.awt.event.MouseAdapter; >> 27: import java.awt.event.MouseEvent; >> 28: import java.lang.Override; > > All the classes from `java.lang.*` are imported implicitly. > > That is, remove `import java.lang.Override`. lang package imports removed. > test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 100: > >> 98: protected boolean isMultiFramesTest(){ >> 99: return false; >> 100: } > > There should be no blank line before the closing brace of a method or constructor. That is the snippet should like this: > > > public GlassPaneOverlappingTestBase(boolean defaultClickValidation) { > super(defaultClickValidation); > } > > @Override > protected boolean isMultiFramesTest() { > return false; > } Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322618892 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322627072 From duke at openjdk.org Thu Sep 4 15:53:49 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 15:53:49 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> References: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> Message-ID: <3djp6C3enjOM_drz8ZcZS7ESYvevvmg2RU2yRLCxqdc=.cf178aaa-1465-4dbc-b980-cabff86bf406@github.com> On Thu, 4 Sep 2025 14:22:01 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Organizes imports > > test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 115: > >> 113: >> 114: if (testResize) { >> 115: wasLWClicked = false; > > May I also suggest reversing the condition: > > > if (!testResize) { > return true; > } > > > This brings the shorter `else` section higher, and it's the end of the test if `testResize` is `false`. > > The testing for resize then is written with reduced indentation. Looks better this way, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322640069 From duke at openjdk.org Thu Sep 4 15:56:47 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 15:56:47 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> References: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> Message-ID: On Thu, 4 Sep 2025 14:26:52 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Organizes imports > > test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 315: > >> 313: mainThread.interrupt(); >> 314: }//fail() >> 315: static class TestPassedException extends RuntimeException { > > Suggestion: > > }//fail() > > static class TestPassedException extends RuntimeException { Done. > test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 318: > >> 316: } >> 317: }// class JButtonInGlassPane >> 318: > > Just one blank line is enough. > > That is you should see only one blank line in your editor in the end of the file (some editors, like `vim`, hide this very last line). Done. > test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 692: > >> 690: }//fail() >> 691: static class TestPassedException extends RuntimeException { >> 692: } > > Suggestion: > > }//fail() > > static class TestPassedException extends RuntimeException { > } > > Add blank lines between class members, it improves readability, the code is easier to scan quickly with eyes. Done. > test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 76: > >> 74: return true; >> 75: } >> 76: public SimpleOverlappingTestBase() { > > Suggestion: > > } > > public SimpleOverlappingTestBase() { Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322648034 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322648676 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322649336 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322649974 From duke at openjdk.org Thu Sep 4 16:18:42 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 16:18:42 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v38] In-Reply-To: References: Message-ID: > 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 MULTI_FRAME_TEST instance variable and cleans up code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/8bb09e27..8ccfb76c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=37 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=36-37 Stats: 53 lines in 4 files changed: 22 ins; 29 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 Thu Sep 4 16:18:45 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 16:18:45 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: <5fuaJG-TKPgLnBoXFq0gdc696lWgkfIDAyzkQBZ6PcM=.8bcef1cf-4ba1-416c-941a-39e507f034ac@github.com> References: <5fuaJG-TKPgLnBoXFq0gdc696lWgkfIDAyzkQBZ6PcM=.8bcef1cf-4ba1-416c-941a-39e507f034ac@github.com> Message-ID: On Thu, 4 Sep 2025 14:38:59 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Organizes imports > > test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 36: > >> 34: >> 35: /** >> 36: * Base class for testing overlapping of Swing and AWT component put into GlassPane. > > My IDE highlights that `ancestorLoc` is never used now. Variable removed. > test/jdk/java/awt/Mixing/AWT_Mixing/OverlappingTestBase.java line 694: > >> 692: } >> 693: }// class LWComboBox >> 694: > > One blank line is enough. Done. > test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 73: > >> 71: } >> 72: >> 73: protected boolean isMultiFramesTest(){ > > Suggestion: > > protected boolean isMultiFramesTest() { Done. > test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 185: > >> 183: >> 184: clickAndBlink(robot, lLoc); >> 185: if (ancestor != null && MULTI_FRAMES_TEST) { > > Suggestion: > > if (ancestor != null && isMultiFramesTest()) { > > If you introduce the method to return the flag and the flag is used in one place only, call the method instead of storing its value in field. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322702924 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322696697 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322699561 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2322695966 From duke at openjdk.org Thu Sep 4 16:33:46 2025 From: duke at openjdk.org (lawrence.andrews) Date: Thu, 4 Sep 2025 16:33:46 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 08:32:23 GMT, Srinivas Mandalika 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. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Feedback: Removed redundant RTEs test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 116: > 114: button = new Button("Click me"); > 115: button.addActionListener(new ActionListener() { > 116: @Override Can this be converted to lambda test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 136: > 134: textField2 = new TextField("TextField"); > 135: button2.addActionListener(new ActionListener() { > 136: @Override Can this be converted to lambda test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 151: > 149: robot.setAutoDelay(150); > 150: robot.setAutoWaitForIdle(true); > 151: if (!windowFocusGainedLatch.await(1500, TimeUnit.MILLISECONDS)) { Once there is a timeout, we know the frame did not gain focus. Can we throw exception and stop execution ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2322738367 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2322739626 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2322745226 From duke at openjdk.org Thu Sep 4 17:42:20 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Thu, 4 Sep 2025 17:42:20 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v5] In-Reply-To: References: Message-ID: > The fix for the https://bugs.openjdk.org/browse/JDK-8251928. > > **Description**. > This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. > > As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): > 1. Convert the user-space point, size, or rectangle value to device space coordinates; > 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; > 3. Convert the normalized value back to user space; > 4. Draw your content using the adjusted value. > > The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. > The 2-nd step is a drawing process in the java code (without changes). > The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. > The 4-th step is a drawing process in the native code (without changes). > > **Tests**. > I run all tests from javax.print package and there is no any regression. > New test covers macOS and Linux only because we know its default DPI - 300. GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: revert CGraphicsDevice.m constants. Update orientation constant usage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25489/files - new: https://git.openjdk.org/jdk/pull/25489/files/f7d5f3f0..1e32943f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=03-04 Stats: 44 lines in 3 files changed: 7 ins; 33 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489 PR: https://git.openjdk.org/jdk/pull/25489 From duke at openjdk.org Thu Sep 4 17:42:21 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Thu, 4 Sep 2025 17:42:21 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v4] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 22:26:55 GMT, Phil Race wrote: >> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: >> >> remove setDevClip usage. Update names. Handle page format orientation. > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 854: > >> 852: double scaleY = getYRes()/ USER_SPACE_DPI; >> 853: PageFormat scaledPage = scalePageFormat(page, scaleX, scaleY); >> 854: SurfaceData sd = CPrinterSurfaceData.createData(scaledPage, context); // Just stores page into an ivar > > This bleeds through in an application visible way. > Take your test case and add this code to the print(..) method and you'll see what I mean. > > GraphicsConfiguration gc = g2.getDeviceConfiguration(); > Rectangle bds = gc.getBounds(); > System.out.println("bds="+bds); > > For me it then prints > bds=java.awt.Rectangle[x=0,y=0,width=2550,height=3300] This is the expected behavior, the same as on other OS. I checked the GraphicsConfiguration on Windows 11, Ubuntu 22.04 and macOS 10.15 with DPI 300 and A4 format. The device boundaries on macOS are 1 pixel different. The console output is below. **Windows 11** Page format size: 595.275574 x 841.889771 Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] Run: 1, Page index: 0 java.lang.Throwable at DevConfig$DevicePrintable.print(DevConfig.java:38) at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2212) at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1601) at DevConfig.main(DevConfig.java:23) Page format size: 595.275574 x 841.889771 Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] Run: 2, Page index: 0 java.lang.Throwable at DevConfig$DevicePrintable.print(DevConfig.java:38) at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2252) at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1601) at DevConfig.main(DevConfig.java:23) **Ubunut 22.04** Page format size: 595,275574 x 841,889771 Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] Run: 1, Page index: 0 java.lang.Throwable at DevConfig$DevicePrintable.print(DevConfig.java:41) at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2243) at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1632) at DevConfig.main(DevConfig.java:25) Page format size: 595,275574 x 841,889771 Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] Run: 2, Page index: 0 java.lang.Throwable at DevConfig$DevicePrintable.print(DevConfig.java:41) at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2283) at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1632) at DevConfig.main(DevConfig.java:25) **macOS 10.15** Page format size: 595.275567 x 841.889771 Device bounds: java.awt.Rectangle[x=0,y=0,width=2479,height=3508] Run: 1, Page index: 0 java.lang.Throwable at DevConfig$DevicePrintable.print(DevConfig.java:36) at java.desktop/sun.lwawt.macosx.CPrinterJob$4.run(CPrinterJob.java:919) at java.desktop/sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(CPrinterJob.java:938) at java.desktop/sun.lwawt.macosx.CPrinterJob.printLoop(Native Method) at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:383) at DevConfig.main(DevConfig.java:21) Page format size: 595.275567 x 841.889771 Device bounds: java.awt.Rectangle[x=0,y=0,width=2479,height=3508] run: 2, Page index: 0 java.lang.Throwable at DevConfig$DevicePrintable.print(DevConfig.java:36) at java.desktop/sun.lwawt.macosx.CPrinterJob$2.run(CPrinterJob.java:838) at java.desktop/sun.lwawt.macosx.CPrinterJob.printToPathGraphics(CPrinterJob.java:852) at java.desktop/sun.lwawt.macosx.CPrinterJob.printLoop(Native Method) at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:383) at DevConfig.main(DevConfig.java:21) > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 904: > >> 902: new BufferedImage( >> 903: (int)Math.round(scaledPageFormat.getWidth()), >> 904: (int)Math.round(scaledPageFormat.getHeight()), > > Wow, that is going to be one big BufferedImage. This doesn't seem right or necessary for a PeekGraphics. > > Look at RasterPrinterGraphics. It uses a 1x1 image (!) It just sets things up so that when the app asks for the graphics config it gets the page dimensions back. This is a good point, but I have not changed the existing approach to creating a PeekGraphics. A BufferedImage is created based on the paper format size and DPI. Does changing the approach to memory consumption align with the goals of this PR, to be able to set the document's DPI to match the printer's DPI? > src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.h line 29: > >> 27: * Some default values for invalid CoreGraphics display ID. >> 28: */ >> 29: #define DEFAULT_DEVICE_WIDTH 1024 > > You should revert adding this file and put these defines back into CGraphicsDevice.m. > > The only thing you us from here is DEFAULT_DEVICE_DPI and that appears to be because it is "72", but where you are using it in PrinterView.m it is really based on the 72 DPI default defined by Java 2D. See the class doc for Graphics2D. And also the size for java.awt.print.Paper is specified in points too. > > I suggest just creating a local variable in PrinterView.m Done > src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m line 119: > >> 117: double scaleY = DEFAULT_DEVICE_DPI / vRes; >> 118: if (scaleX != 1 || scaleY != 1) { >> 119: if ([[[NSPrintOperation currentOperation] printInfo] orientation] == NSPortraitOrientation) { > > This fails to compile for me > src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m:119:79: error: comparison of different enumeration types ('NSPaperOrientation' (aka 'enum NSPaperOrientation') and 'enum NSPrintingOrientation') [-Werror,-Wenum-compare] > 119 | if ([[[NSPrintOperation currentOperation] printInfo] orientation] == NSPortraitOrientation) { > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~ > It should be NSPaperOrientationPortrait Thanks, NSPortraitOrientation was deprecated for a long time. I replaced NSPortraitOrientation with NSPaperOrientationPortrait. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2322943014 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2322938418 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2322927603 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2322932711 From aivanov at openjdk.org Thu Sep 4 18:47:52 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 18:47:52 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v38] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 16:18:42 GMT, Khalid Boulanouare 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 MULTI_FRAME_TEST instance variable and cleans up code Changes requested by aivanov (Reviewer). test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 29: > 27: import java.awt.event.MouseEvent; > 28: import java.awt.event.InputEvent; > 29: import java.lang.reflect.InvocationTargetException; `InvocationTargetException` is still required. test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 98: > 96: return false; > 97: } > 98: /** Suggestion: } /** test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 44: > 42: import test.java.awt.regtesthelpers.Util; > 43: > 44: /** I wonder if `frameBorderCounter` needs to run another java process to get the result. It should be possible to get the same result by running the code in `FrameBorderCounter` class directly in this JVM. Anyway, it's for another time. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 70: > 68: } > 69: > 70: protected boolean isMultiFramesTest(){ Suggestion: @Override protected boolean isMultiFramesTest(){ test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 73: > 71: return true; > 72: } > 73: public SimpleOverlappingTestBase() { Suggestion: } public SimpleOverlappingTestBase() { Ensure there's a blank line around method declarations. (For modified / added methods.) test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 173: > 171: if (!await) { > 172: throw new RuntimeException("Ancestor frame didn't receive " + > 173: "focus"); Suggestion: throw new RuntimeException("Ancestor frame didn't receive focus"); I'm for breaking the rule of fitting into 80-column limit, wrapping this line doesn't improve readability. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 179: > 177: } > 178: > 179: } Suggestion: } } There shouldn't be a blank line between the closing braces. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 184: > 182: if (ancestor != null && isMultiFramesTest()) { > 183: ancestor.dispose(); > 184: } These four lines are indented inconsistently, the indentation should be reduced by four spaces. ------------- PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3186560693 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323061545 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323055693 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323082284 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323088480 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323091314 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323097562 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323102374 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323106519 From aivanov at openjdk.org Thu Sep 4 18:47:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 4 Sep 2025 18:47:53 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: References: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> Message-ID: On Thu, 4 Sep 2025 15:54:29 GMT, Khalid Boulanouare wrote: >> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 76: >> >>> 74: return true; >>> 75: } >>> 76: public SimpleOverlappingTestBase() { >> >> Suggestion: >> >> } >> >> public SimpleOverlappingTestBase() { > > Done. This is not done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323089174 From djgredler at gmail.com Thu Sep 4 20:37:22 2025 From: djgredler at gmail.com (Daniel Gredler) Date: Thu, 4 Sep 2025 22:37:22 +0200 Subject: Possible BufferedImage.getRGB optimization In-Reply-To: <4fwhGEI1vpght94ivpKadVGn0TOy7V3_3623KIp9ootVXDwH8UND6XpF7ERLKJ-gfNA-fbAyOBqmRexLj5mwmmAX8JAJOtk8Ovm94YW1i9U=@pm.me> References: <4fwhGEI1vpght94ivpKadVGn0TOy7V3_3623KIp9ootVXDwH8UND6XpF7ERLKJ-gfNA-fbAyOBqmRexLj5mwmmAX8JAJOtk8Ovm94YW1i9U=@pm.me> Message-ID: Hi Jeremy, Laurent, Thanks for having a look. What sorts of changes are you thinking of when you propose a separate project? For myself, I don't really have a bigger-picture vision of systematic changes that I'd like to make. Similar to JDK-8337681, JDK-8344668 and JDK-8356814, this suggestion is just an ad hoc optimization opportunity that came up based on spending some time with a profiler. My takeaway right now is that this specific suggestion doesn't look obviously stupid to anyone, and is worth triple checking on my end. If my local sanity checks all come back green, I would create a small issue in JBS and submit a PR, and then let the review process carry on as usual. It can take a little time, but it seems to me that useful optimizations, submitted individually, can be incorporated without too many issues. Which takes me back to my original question -- what type of change(s) are you thinking about, where proving things out in a separate project is necessary? Take care, Daniel On Sat, Aug 30, 2025 at 11:47?AM Laurent Bourg?s wrote: > Hi guys, > > I do love optimizing java2d, so Ido support & sponsor your buffered image > (ARGB PRE or not) changes. > > Let's start a github project to start this concrete patch... as I did for > the marlin renderer or we could use the marlin repository to host your > changes to java.awt or java2d packages. > > See jdk (25?) branch: > > https://github.com/bourgesl/marlin-renderer/tree/jdk/src/main/java/sun/java2d > > Cheers, > Laurent > > > -------- Message d'origine -------- > Le 22/08/2025 14:04, Daniel Gredler a ?crit : > > 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: From philip.race at oracle.com Thu Sep 4 21:54:06 2025 From: philip.race at oracle.com (Philip Race) Date: Thu, 4 Sep 2025 14:54:06 -0700 Subject: Possible BufferedImage.getRGB optimization In-Reply-To: References: <4fwhGEI1vpght94ivpKadVGn0TOy7V3_3623KIp9ootVXDwH8UND6XpF7ERLKJ-gfNA-fbAyOBqmRexLj5mwmmAX8JAJOtk8Ovm94YW1i9U=@pm.me> Message-ID: <7608a809-7e2d-4ed6-8d74-5d29bf5dea65@oracle.com> It doesn't seem like a change that needs a project. I would make sure that call to colorModel.getRGB(..) isn't needed and I think that you aren't doing that. Basically it needs to be sRGB already (as that is the target color space). -phil. On 9/4/25 1:37 PM, Daniel Gredler wrote: > Hi Jeremy, Laurent, > > Thanks for having a look. What sorts of changes are you thinking of > when you propose a separate project? > > For myself, I don't really have a bigger-picture vision of systematic > changes that I'd like to make. Similar to JDK-8337681, JDK-8344668 and > JDK-8356814, this suggestion is just an ad hoc optimization > opportunity that came up based on spending some time with?a profiler. > > My takeaway right now is that this specific suggestion doesn't look > obviously stupid to anyone, and is worth triple checking on my end. If > my local sanity checks all come back green, I would create a small > issue in JBS and submit a PR, and then let the review process carry on > as usual. It can take a little time, but it seems to me that useful > optimizations, submitted individually, can be incorporated without too > many issues. > > Which takes me back to my original question -- what type of change(s) > are you thinking about, where proving things out in a separate project > is necessary? > > Take care, > > Daniel > > > On Sat, Aug 30, 2025 at 11:47?AM Laurent Bourg?s > wrote: > > Hi guys, > > I do love optimizing java2d, so Ido support & sponsor your > buffered image (ARGB PRE or not) changes. > > Let's start a github project to start this concrete patch... as I > did for the marlin renderer or we could use the marlin repository > to host your changes to java.awt or java2d packages. > > See jdk (25?) branch: > https://github.com/bourgesl/marlin-renderer/tree/jdk/src/main/java/sun/java2d > > Cheers, > Laurent > > > > -------- Message d'origine -------- > Le 22/08/2025 14:04, Daniel Gredler a ?crit?: > > 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: From duke at openjdk.org Thu Sep 4 22:02:14 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 22:02:14 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v39] In-Reply-To: References: Message-ID: > 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: - Cleans up code for move visibility - Cleans up code and adds missed import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/8ccfb76c..c5fd2279 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=37-38 Stats: 11 lines in 2 files changed: 4 ins; 2 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 duke at openjdk.org Thu Sep 4 22:02:16 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 22:02:16 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v39] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 18:16:44 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision: >> >> - Cleans up code for move visibility >> - Cleans up code and adds missed import > > test/jdk/java/awt/Mixing/AWT_Mixing/GlassPaneOverlappingTestBase.java line 29: > >> 27: import java.awt.event.MouseEvent; >> 28: import java.awt.event.InputEvent; >> 29: import java.lang.reflect.InvocationTargetException; > > `InvocationTargetException` is still required. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323614336 From duke at openjdk.org Thu Sep 4 22:02:21 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 22:02:21 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v38] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 18:24:02 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Removes MULTI_FRAME_TEST instance variable and cleans up code > > test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 44: > >> 42: import test.java.awt.regtesthelpers.Util; >> 43: >> 44: /** > > I wonder if `frameBorderCounter` needs to run another java process to get the result. It should be possible to get the same result by running the code in `FrameBorderCounter` class directly in this JVM. Anyway, it's for another time. I have not tried this before, I will check this some time and share my findings. > test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 70: > >> 68: } >> 69: >> 70: protected boolean isMultiFramesTest(){ > > Suggestion: > > @Override > protected boolean isMultiFramesTest(){ This is done in class GlassPaneOverlappingTestBase.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323616834 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323619931 From duke at openjdk.org Thu Sep 4 22:02:22 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 4 Sep 2025 22:02:22 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v37] In-Reply-To: References: <5u8AlycVjimIs0a5bACAkkmMvXHxjbXbZC4Pc84IwYY=.86947501-2715-4dd5-8c56-ff2f9700c578@github.com> Message-ID: On Thu, 4 Sep 2025 18:26:21 GMT, Alexey Ivanov wrote: >> Done. > > This is not done. Sorry, I have missed this one. I have done it now. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2323603804 From prr at openjdk.org Thu Sep 4 22:15:09 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 4 Sep 2025 22:15:09 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v5] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:42:20 GMT, GennadiyKrivoshein wrote: >> The fix for the https://bugs.openjdk.org/browse/JDK-8251928. >> >> **Description**. >> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. >> >> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): >> 1. Convert the user-space point, size, or rectangle value to device space coordinates; >> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; >> 3. Convert the normalized value back to user space; >> 4. Draw your content using the adjusted value. >> >> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. >> The 2-nd step is a drawing process in the java code (without changes). >> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. >> The 4-th step is a drawing process in the native code (without changes). >> >> **Tests**. >> I run all tests from javax.print package and there is no any regression. >> New test covers macOS and Linux only because we know its default DPI - 300. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > revert CGraphicsDevice.m constants. Update orientation constant usage src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 470: > 468: @Override > 469: protected double getXRes() { > 470: return hRes; I have been unable to verify that this would be applied with a real printer device resolution, because my printer is not reporting PrinterResolution. Not sure why. I see it in the PPD but the call to the cups ppd API isn't finding it. Thinking about it, this is may be the "real" problem if something in this API used to work but has stopped working. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 795: > 793: return scaledPage; > 794: } > 795: This is something of an abuse of these APIs which are *specified* to have sizes in 1/72" This is all needed here because createData takes a PageFormat. I looked and unless I am missing something all it ever does is use the bounds to return those (now larger) device bounds. I would consider it a better approach to modify CPrinterSurfaceData.createData to accept what it really needs .. the device bounds. I don't see that it needs a page format. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2323636048 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2323180760 From prr at openjdk.org Thu Sep 4 22:15:12 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 4 Sep 2025 22:15:12 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v4] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 17:39:19 GMT, GennadiyKrivoshein wrote: > This is the expected behavior, the same as on other OS. I checked the GraphicsConfiguration on Windows 11, Ubuntu 22.04 and macOS 10.15 with DPI 300 and A4 format. The device boundaries on macOS are 1 pixel different. The console output is below. > > **Windows 11** > > ``` > Page format size: 595.275574 x 841.889771 > Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] > Run: 1, Page index: 0 > java.lang.Throwable > at DevConfig$DevicePrintable.print(DevConfig.java:38) > at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2212) > at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1601) > at DevConfig.main(DevConfig.java:23) > > Page format size: 595.275574 x 841.889771 > Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] > Run: 2, Page index: 0 > java.lang.Throwable > at DevConfig$DevicePrintable.print(DevConfig.java:38) > at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2252) > at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1601) > at DevConfig.main(DevConfig.java:23) > ``` > > **Ubunut 22.04** > > ``` > Page format size: 595,275574 x 841,889771 > Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] > Run: 1, Page index: 0 > java.lang.Throwable > at DevConfig$DevicePrintable.print(DevConfig.java:41) > at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2243) > at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1632) > at DevConfig.main(DevConfig.java:25) > > Page format size: 595,275574 x 841,889771 > Device bounds: java.awt.Rectangle[x=0,y=0,width=2480,height=3507] > Run: 2, Page index: 0 > java.lang.Throwable > at DevConfig$DevicePrintable.print(DevConfig.java:41) > at java.desktop/sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:2283) > at java.desktop/sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1632) > at DevConfig.main(DevConfig.java:25) > ``` > > **macOS 10.15** > > ``` > Page format size: 595.275567 x 841.889771 > Device bounds: java.awt.Rectangle[x=0,y=0,width=2479,height=3508] > Run: 1, Page index: 0 > java.lang.Throwable > at DevConfig$DevicePrintable.print(DevConfig.java:36) > at java.desktop/sun.lwawt.macosx.CPrinterJob$4.run(CPrinterJob.java:919) > at java.desktop/sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(CPrinterJob.java:938) > at java.desktop/sun.lwawt.macosx.CPrinterJob.printLoop(Native Method) > at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:383) > at DevConfig.main(DevConfig.java:21) > > Page format size: 595.275567 x 841.889771 > Device bounds: java.awt.Rectangle[x=0,y=0,width=2479,height=3508] > run: 2, Page index: 0 > java.lang.Throwable > at DevConfig$DevicePrintable.print(DevConfig.java:36) > at java.desktop/sun.lwawt.macosx.CPrinterJob$2.run(CPrinterJob.java:838) > at java.desktop/sun.lwawt.macosx.CPrinterJob.printToPathGraphics(CPrinterJob.java:852) > at java.desktop/sun.lwawt.macosx.CPrinterJob.printLoop(Native Method) > at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:383) > at DevConfig.main(DevConfig.java:21) > ``` Yes it is. I realized that afterwards but didn't get round to updating my comment. >> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 904: >> >>> 902: new BufferedImage( >>> 903: (int)Math.round(scaledPageFormat.getWidth()), >>> 904: (int)Math.round(scaledPageFormat.getHeight()), >> >> Wow, that is going to be one big BufferedImage. This doesn't seem right or necessary for a PeekGraphics. >> >> Look at RasterPrinterGraphics. It uses a 1x1 image (!) It just sets things up so that when the app asks for the graphics config it gets the page dimensions back. > > This is a good point, but I have not changed the existing approach to creating a PeekGraphics. A BufferedImage is created based on the paper format size and DPI. > Does changing the approach to memory consumption align with the goals of this PR, to be able to set the document's DPI to match the printer's DPI? supposing we have a 1200 dpi printer and someone prints to A3 paper. That's approx 12x16 inches and its ARGB so 12 * 1_200 * 16 * 1_200 * 4 .. that's over a Gigabyte ! So what you are doing isn't viable as well as unnecessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2323153257 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2323166219 From dnguyen at openjdk.org Fri Sep 5 01:50:44 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 Sep 2025 01:50:44 GMT Subject: RFR: 8366149: JNI exception pending in Java_sun_awt_X11GraphicsDevice_pGetBounds of awt_GraphicsEnv.c:1484 Message-ID: <23suWu7T8mP4QAs-wKAHZqW_L0ZrSqEa8ZDw8DE2yTg=.29cfda73-47b4-429a-ac9d-0dfd5cb6d409@github.com> In the scenario where AWT's UNLOCK API encounters a pendingException, the env pointer throws the pendingException (as seen in `awt.h`). However, in `Java_sun_awt_X11GraphicsDevice_pGetBounds`, after `AWT_UNLOCK`, the bounds var is set. The exception check does not occur until after the bounds is set, so the bounds may be set to an undesired value. This fix adds another exception check to look for this pendingException after `AWT_UNLOCK`. ------------- 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...f5e1521b Changes: https://git.openjdk.org/jdk/pull/27110/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27110&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366149 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27110/head:pull/27110 PR: https://git.openjdk.org/jdk/pull/27110 From prr at openjdk.org Fri Sep 5 04:38:23 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 5 Sep 2025 04:38:23 GMT Subject: RFR: 8366149: JNI exception pending in Java_sun_awt_X11GraphicsDevice_pGetBounds of awt_GraphicsEnv.c:1484 In-Reply-To: <23suWu7T8mP4QAs-wKAHZqW_L0ZrSqEa8ZDw8DE2yTg=.29cfda73-47b4-429a-ac9d-0dfd5cb6d409@github.com> References: <23suWu7T8mP4QAs-wKAHZqW_L0ZrSqEa8ZDw8DE2yTg=.29cfda73-47b4-429a-ac9d-0dfd5cb6d409@github.com> Message-ID: On Fri, 5 Sep 2025 01:43:30 GMT, Damon Nguyen wrote: > In the scenario where AWT's UNLOCK API encounters a pendingException, the env pointer throws the pendingException (as seen in `awt.h`). However, in `Java_sun_awt_X11GraphicsDevice_pGetBounds`, after `AWT_UNLOCK`, the bounds var is set. The exception check does not occur until after the bounds is set, so the bounds may be set to an undesired value. This fix adds another exception check to look for this pendingException after `AWT_UNLOCK`. src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1289: > 1287: AWT_UNLOCK (); > 1288: > 1289: if ((*env)->ExceptionCheck(env)) { Is the problem that we are here because bounds == null and one way this is possible is that the call at line 1265 failed? Meaning threw an unlikely exception. If so, maybe that is where we should just "return NULL". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27110#discussion_r2324068770 From prr at openjdk.org Fri Sep 5 04:42:23 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 5 Sep 2025 04:42:23 GMT Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 04:37:21 GMT, Tejesh R wrote: >> No it was not an error. This is content moved from another file. Files are an artificial division. It is the same content. > > Ok, so when we create a new file and move the contents from old file as part of refactoring we retain the copyright year too. Got it. So .. @TejeshR13 did you mean to approve this ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26784#discussion_r2324073050 From psadhukhan at openjdk.org Fri Sep 5 05:08:11 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Sep 2025 05:08:11 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 06:43:09 GMT, Sarvesh Kumar Jain wrote: > The test is problem listed with incorrect bug JDK-6849371, > The bug JDK-6849371 is for a different test and it is closed. > A new bug has been raised for ChoiceMouseWheelTest.java test failure. That new bugid 8366852 needs to be added in the problemlist for this bug then instead of removing the entry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27085#issuecomment-3257077171 From tr at openjdk.org Fri Sep 5 05:11:30 2025 From: tr at openjdk.org (Tejesh R) Date: Fri, 5 Sep 2025 05:11:30 GMT Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 17:27:09 GMT, Phil Race 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. LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26784#pullrequestreview-3188012577 From tr at openjdk.org Fri Sep 5 05:11:30 2025 From: tr at openjdk.org (Tejesh R) Date: Fri, 5 Sep 2025 05:11:30 GMT Subject: RFR: 8365569: Remove finalize from JavaSoundAudioClip.java In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 04:39:33 GMT, Phil Race wrote: >> Ok, so when we create a new file and move the contents from old file as part of refactoring we retain the copyright year too. Got it. > > So .. @TejeshR13 did you mean to approve this ? Yes, just missed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26784#discussion_r2324112058 From duke at openjdk.org Fri Sep 5 05:31:31 2025 From: duke at openjdk.org (Sarvesh Kumar Jain) Date: Fri, 5 Sep 2025 05:31:31 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: Message-ID: > The test is problem listed with incorrect bug JDK-6849371, > The bug JDK-6849371 is for a different test and it is closed. > A new bug has been raised for ChoiceMouseWheelTest.java test failure. Sarvesh Kumar Jain has updated the pull request incrementally with one additional commit since the last revision: Updated with new bugid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27085/files - new: https://git.openjdk.org/jdk/pull/27085/files/dba12499..bf04b8e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27085&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27085&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27085/head:pull/27085 PR: https://git.openjdk.org/jdk/pull/27085 From duke at openjdk.org Fri Sep 5 05:31:31 2025 From: duke at openjdk.org (Sarvesh Kumar Jain) Date: Fri, 5 Sep 2025 05:31:31 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 05:05:21 GMT, Prasanta Sadhukhan wrote: > That new bugid 8366852 needs to be added in the problemlist for this bug then instead of removing the entry. @prsadhuk Updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27085#issuecomment-3257117653 From psadhukhan at openjdk.org Fri Sep 5 05:50:15 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Sep 2025 05:50:15 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 05:31:31 GMT, Sarvesh Kumar Jain wrote: >> The test is problem listed with incorrect bug JDK-6849371, >> The bug JDK-6849371 is for a different test and it is closed. >> A new bug has been raised for ChoiceMouseWheelTest.java test failure. > > Sarvesh Kumar Jain has updated the pull request incrementally with one additional commit since the last revision: > > Updated with new bugid test/jdk/ProblemList.txt line 263: > 261: java/awt/print/PrinterJob/PSQuestionMark.java 7003378 generic-all > 262: java/awt/print/PrinterJob/GlyphPositions.java 7003378 generic-all > 263: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java 8366852 generic-all are you sure it's a generic-all problem? It was not problemlisted for windows and I dont think we see any problem in CI in mainline in windows.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27085#discussion_r2324159384 From duke at openjdk.org Fri Sep 5 05:56:11 2025 From: duke at openjdk.org (Sarvesh Kumar Jain) Date: Fri, 5 Sep 2025 05:56:11 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: Message-ID: <65AUIV09Mf4O177TyQIBeCHOC3WT7TnNPV_aUNpPXvg=.9236c53e-69f8-4efe-8933-358d51d55546@github.com> On Fri, 5 Sep 2025 05:47:08 GMT, Prasanta Sadhukhan wrote: >> Sarvesh Kumar Jain has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated with new bugid > > test/jdk/ProblemList.txt line 263: > >> 261: java/awt/print/PrinterJob/PSQuestionMark.java 7003378 generic-all >> 262: java/awt/print/PrinterJob/GlyphPositions.java 7003378 generic-all >> 263: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java 8366852 generic-all > > are you sure it's a generic-all problem? It was not problemlisted for windows and I dont think we see any problem in CI in mainline in windows.. I attached the test execution link in the bug 8366852, please check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27085#discussion_r2324165125 From psadhukhan at openjdk.org Fri Sep 5 05:56:11 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Sep 2025 05:56:11 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: <65AUIV09Mf4O177TyQIBeCHOC3WT7TnNPV_aUNpPXvg=.9236c53e-69f8-4efe-8933-358d51d55546@github.com> References: <65AUIV09Mf4O177TyQIBeCHOC3WT7TnNPV_aUNpPXvg=.9236c53e-69f8-4efe-8933-358d51d55546@github.com> Message-ID: On Fri, 5 Sep 2025 05:51:36 GMT, Sarvesh Kumar Jain wrote: >> test/jdk/ProblemList.txt line 263: >> >>> 261: java/awt/print/PrinterJob/PSQuestionMark.java 7003378 generic-all >>> 262: java/awt/print/PrinterJob/GlyphPositions.java 7003378 generic-all >>> 263: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java 8366852 generic-all >> >> are you sure it's a generic-all problem? It was not problemlisted for windows and I dont think we see any problem in CI in mainline in windows.. > > I attached the test execution link in the bug 8366852, please check. that was for 21 not mainline.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27085#discussion_r2324167983 From duke at openjdk.org Fri Sep 5 06:15:11 2025 From: duke at openjdk.org (Sarvesh Kumar Jain) Date: Fri, 5 Sep 2025 06:15:11 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: <65AUIV09Mf4O177TyQIBeCHOC3WT7TnNPV_aUNpPXvg=.9236c53e-69f8-4efe-8933-358d51d55546@github.com> Message-ID: On Fri, 5 Sep 2025 05:53:40 GMT, Prasanta Sadhukhan wrote: >> I attached the test execution link in the bug 8366852, please check. > > that was for 21 not mainline.. there are 2 links, first one is ML, 2nd is 21. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27085#discussion_r2324195947 From psadhukhan at openjdk.org Fri Sep 5 06:22:14 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Sep 2025 06:22:14 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 05:31:31 GMT, Sarvesh Kumar Jain wrote: >> The test is problem listed with incorrect bug JDK-6849371, >> The bug JDK-6849371 is for a different test and it is closed. >> A new bug has been raised for ChoiceMouseWheelTest.java test failure. > > Sarvesh Kumar Jain has updated the pull request incrementally with one additional commit since the last revision: > > Updated with new bugid Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27085#pullrequestreview-3188136882 From psadhukhan at openjdk.org Fri Sep 5 06:22:15 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Sep 2025 06:22:15 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: <65AUIV09Mf4O177TyQIBeCHOC3WT7TnNPV_aUNpPXvg=.9236c53e-69f8-4efe-8933-358d51d55546@github.com> Message-ID: On Fri, 5 Sep 2025 06:12:35 GMT, Sarvesh Kumar Jain wrote: >> that was for 21 not mainline.. > > there are 2 links, first one is ML, 2nd is 21. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27085#discussion_r2324205903 From duke at openjdk.org Fri Sep 5 06:30:15 2025 From: duke at openjdk.org (duke) Date: Fri, 5 Sep 2025 06:30:15 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 05:31:31 GMT, Sarvesh Kumar Jain wrote: >> The test is problem listed with incorrect bug JDK-6849371, >> The bug JDK-6849371 is for a different test and it is closed. >> A new bug has been raised for ChoiceMouseWheelTest.java test failure. > > Sarvesh Kumar Jain has updated the pull request incrementally with one additional commit since the last revision: > > Updated with new bugid @TheSarveshJain Your change (at version bf04b8e0284720ec7fabe62132068e4a6f3e5966) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27085#issuecomment-3257218842 From psadhukhan at openjdk.org Fri Sep 5 08:19:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Sep 2025 08:19:16 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v3] In-Reply-To: References: <0MDTPquVuMulH9tEnu_VEaKM7e6SPCpHh_19RhGWXMw=.56db997b-8a7e-48ea-bd07-e9721c5eea28@github.com> Message-ID: On Fri, 22 Aug 2025 22:16:48 GMT, Phil Race wrote: > And if the rectangle you pass in has a y that is = the height of the list, then scrolling in a positive direction also returns 0. > If it is GREATER than the height, then I get back a negative increment ! I tried Rectangle cell = list.getCellBounds(1, data.length); cell.y = list.getHeight() + 10; int unit = list.getScrollableUnitIncrement( cell, SwingConstants.VERTICAL, -1); System.out.println("Scrollable unit increment: " + unit); and I get 117 in upward (-1) direction and -99 in downward (1) direction.. so it seems `getScrollableUnitIncrement` finds from `locationToIndex` that it's last row so `r.y` points to TOP of last cell (90) but `visibleRect.y` points to height past the last cell(207) so it has to backtrack -99 pixels [last cell height=18 - (207-90) = 18-117] logically but I guess we need to restrict it to 0 since there is no incremental scrolling that can be done ------------- PR Comment: https://git.openjdk.org/jdk/pull/26500#issuecomment-3257481618 From smandalika at openjdk.org Fri Sep 5 09:20:38 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 5 Sep 2025 09:20:38 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 16:27:52 GMT, lawrence.andrews wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback: Removed redundant RTEs > > test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 116: > >> 114: button = new Button("Click me"); >> 115: button.addActionListener(new ActionListener() { >> 116: @Override > > Can this be converted to lambda Done > test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 136: > >> 134: textField2 = new TextField("TextField"); >> 135: button2.addActionListener(new ActionListener() { >> 136: @Override > > Can this be converted to lambda Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2324556660 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2324555024 From smandalika at openjdk.org Fri Sep 5 09:20:38 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 5 Sep 2025 09:20:38 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v4] In-Reply-To: References: Message-ID: > 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. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review feedback: Use lambda for ActionListener ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26471/files - new: https://git.openjdk.org/jdk/pull/26471/files/d766b695..bb90ed63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26471&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26471&range=02-03 Stats: 12 lines in 1 file changed: 0 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26471/head:pull/26471 PR: https://git.openjdk.org/jdk/pull/26471 From smandalika at openjdk.org Fri Sep 5 09:24:11 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 5 Sep 2025 09:24:11 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v3] In-Reply-To: References: Message-ID: <-nb8U6iT4ebHebd3ZVsPYpoSfRHBVS-bJX9A6x5aXXE=.506b6535-4cda-4969-8f32-9d8a59f1513b@github.com> On Thu, 4 Sep 2025 16:30:40 GMT, lawrence.andrews wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback: Removed redundant RTEs > > test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 151: > >> 149: robot.setAutoDelay(150); >> 150: robot.setAutoWaitForIdle(true); >> 151: if (!windowFocusGainedLatch.await(1500, TimeUnit.MILLISECONDS)) { > > Once there is a timeout, we know the frame did not gain focus. Can we throw exception and stop execution ? Yes, that was the code initially. The previous review suggested removal of the code as being redundant in the presence of the main method's throws Exception. There are pros and con to argue on both ways. Please let me know if you strong reason to not ok to not have in the current form. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2324570191 From psadhukhan at openjdk.org Fri Sep 5 09:32:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 5 Sep 2025 09:32:16 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v3] In-Reply-To: <-nb8U6iT4ebHebd3ZVsPYpoSfRHBVS-bJX9A6x5aXXE=.506b6535-4cda-4969-8f32-9d8a59f1513b@github.com> References: <-nb8U6iT4ebHebd3ZVsPYpoSfRHBVS-bJX9A6x5aXXE=.506b6535-4cda-4969-8f32-9d8a59f1513b@github.com> Message-ID: On Fri, 5 Sep 2025 09:21:58 GMT, Srinivas Mandalika wrote: >> test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 151: >> >>> 149: robot.setAutoDelay(150); >>> 150: robot.setAutoWaitForIdle(true); >>> 151: if (!windowFocusGainedLatch.await(1500, TimeUnit.MILLISECONDS)) { >> >> Once there is a timeout, we know the frame did not gain focus. Can we throw exception and stop execution ? > > Yes, that was the code initially. The previous review suggested removal of the code as being redundant in the presence of the main method's throws Exception. There are pros and con to argue on both ways. Please let me know if you strong reason to not ok to not have in the current form. No, the code I asked to remove was for catching InterruptedException and rethrowing..This is for throwing RTE upfront if timeout exceeded, not by setting `passed `to `false `and continuing..I guess it has its merit of not continuing.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2324586626 From aivanov at openjdk.org Fri Sep 5 11:46:24 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 Sep 2025 11:46:24 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v39] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 22:02:14 GMT, Khalid Boulanouare 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 two additional commits since the last revision: > > - Cleans up code for move visibility > - Cleans up code and adds missed import Minor formatting and unneeded imports left. test/jdk/java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java line 1: > 1: /* You may want to remove reference to an internal URL in the javadoc of this class? in another clean-up. test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java line 1: > 1: /* `java.awt.Color` can be removed from imports. You may also add blank lines between import blocks as you did for `JPopupMenuOverlapping`. test/jdk/java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java line 1: > 1: /* Line 59: - failMessage = "Opacity test mismatchs"; + failMessage = "Opacity test mismatches"; Could be postponed, I just noticed it in the errors reported when I ran these tests locally. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 30: > 28: import java.awt.event.MouseAdapter; > 29: import java.awt.event.MouseEvent; > 30: import java.lang.Override; Suggestion: Not needed. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 162: > 160: JFrame ancestor = (JFrame)(testedComponent.getTopLevelAncestor()); > 161: > 162: if (ancestor != null) { Suggestion: if (ancestor != null) { I won't add a blank line here, the `if` is closely related to the variable above, `ancestor`. test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 172: > 170: try { > 171: boolean await = latch.await(1L, TimeUnit.SECONDS); > 172: if (!await) { Suggestion: if (!latch.await(1L, TimeUnit.SECONDS)) { I don't see any value in saving the result of `await` in a variable; the call itself isn't long enough; calling `latch.await` in the condition is a common pattern. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25971#pullrequestreview-3188970244 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2324860875 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2324850151 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2324869518 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2324829844 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2324833304 PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2324838575 From aivanov at openjdk.org Fri Sep 5 11:46:25 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 5 Sep 2025 11:46:25 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v38] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 21:47:19 GMT, Khalid Boulanouare wrote: >> test/jdk/java/awt/Mixing/AWT_Mixing/SimpleOverlappingTestBase.java line 70: >> >>> 68: } >>> 69: >>> 70: protected boolean isMultiFramesTest(){ >> >> Suggestion: >> >> @Override >> protected boolean isMultiFramesTest(){ > > This is done in class GlassPaneOverlappingTestBase.java Yeah, you're right, it's the place where this method is first added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25971#discussion_r2324819957 From djgredler at gmail.com Fri Sep 5 14:05:41 2025 From: djgredler at gmail.com (Daniel Gredler) Date: Fri, 5 Sep 2025 16:05:41 +0200 Subject: Possible BufferedImage.getRGB optimization In-Reply-To: <7608a809-7e2d-4ed6-8d74-5d29bf5dea65@oracle.com> References: <4fwhGEI1vpght94ivpKadVGn0TOy7V3_3623KIp9ootVXDwH8UND6XpF7ERLKJ-gfNA-fbAyOBqmRexLj5mwmmAX8JAJOtk8Ovm94YW1i9U=@pm.me> <7608a809-7e2d-4ed6-8d74-5d29bf5dea65@oracle.com> Message-ID: OK, thanks -- I'll add a `colorModel.getColorSpace().isCS_sRGB()` check here as well. Take care, Daniel On Thu, Sep 4, 2025 at 11:55?PM Philip Race wrote: > It doesn't seem like a change that needs a project. > I would make sure that call to colorModel.getRGB(..) isn't needed and I > think that you aren't doing that. > Basically it needs to be sRGB already (as that is the target color space). > > -phil. > > On 9/4/25 1:37 PM, Daniel Gredler wrote: > > Hi Jeremy, Laurent, > > Thanks for having a look. What sorts of changes are you thinking of when > you propose a separate project? > > For myself, I don't really have a bigger-picture vision of systematic > changes that I'd like to make. Similar to JDK-8337681, JDK-8344668 and > JDK-8356814, this suggestion is just an ad hoc optimization opportunity > that came up based on spending some time with a profiler. > > My takeaway right now is that this specific suggestion doesn't look > obviously stupid to anyone, and is worth triple checking on my end. If my > local sanity checks all come back green, I would create a small issue in > JBS and submit a PR, and then let the review process carry on as usual. It > can take a little time, but it seems to me that useful optimizations, > submitted individually, can be incorporated without too many issues. > > Which takes me back to my original question -- what type of change(s) are > you thinking about, where proving things out in a separate project is > necessary? > > Take care, > > Daniel > > > On Sat, Aug 30, 2025 at 11:47?AM Laurent Bourg?s > wrote: > >> Hi guys, >> >> I do love optimizing java2d, so Ido support & sponsor your buffered image >> (ARGB PRE or not) changes. >> >> Let's start a github project to start this concrete patch... as I did for >> the marlin renderer or we could use the marlin repository to host your >> changes to java.awt or java2d packages. >> >> See jdk (25?) branch: >> >> https://github.com/bourgesl/marlin-renderer/tree/jdk/src/main/java/sun/java2d >> >> Cheers, >> Laurent >> >> >> -------- Message d'origine -------- >> Le 22/08/2025 14:04, Daniel Gredler a ?crit : >> >> 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: From prr at openjdk.org Fri Sep 5 17:18:16 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 5 Sep 2025 17:18:16 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v4] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 00:13:15 GMT, Chen Liang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Add finally block > > src/java.desktop/share/classes/java/awt/Robot.java line 977: > >> 975: public synchronized void type(int keycode) { >> 976: keyPress(keycode); >> 977: waitForIdle(20); > > Should this use `DEFAULT_STEP_DELAY` too? In the code this is based on (ExtendedRobot.java) it was called DEFAULT_SPEED and used by click and type as well as glide As 'named' now, DEFAULT_STEP_DELAY is only appropriate for glide(..). There's no "stepping" here. And yet click(..) uses it (internally) so long as we don't document the name DEFAULT_STEP_DELAY on click() or type() it isn't critical. I see a number of choices - Use literal 20 here and in click - Use DEFAULT_STEP_DELAY here and in click - do not document - Add a new (private) DEFAULT_DELAY - and use it in both cases - Add a new public DEFAULT_DELAY - and use it in both cases and document it - Rename DEFAULT_STEP_DELAY to DEFAULT_DELAY - and use it in click and type as well as glide I'm inclined to go with the last of these - CSR will need to be revised. But if we don't do that one now, it will be awkward to do later. Thoughts ? PS I can see the potential need for an overload of click() and type() which accepts an alternate delay but I don't propose it here, I just note that for click() it would not be possible for the default click() to just accept a delay since that would clash with click(int buttons). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2325646757 From prr at openjdk.org Fri Sep 5 17:48:22 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 5 Sep 2025 17:48:22 GMT Subject: Integrated: 8365569: Remove finalize from JavaSoundAudioClip.java In-Reply-To: References: Message-ID: On Thu, 14 Aug 2025 17:27:09 GMT, Phil Race 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. This pull request has now been integrated. Changeset: a17058b5 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/a17058b5bb2dcc89ed276600ceac905e7e986426 Stats: 848 lines in 2 files changed: 455 ins; 360 del; 33 mod 8365569: Remove finalize from JavaSoundAudioClip.java Reviewed-by: kizune, tr ------------- PR: https://git.openjdk.org/jdk/pull/26784 From serb at openjdk.org Fri Sep 5 17:51:11 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 5 Sep 2025 17:51:11 GMT Subject: RFR: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently [v5] In-Reply-To: <0ZhkX9_Rhl6vck_jDI37GaF6UaGvkkRoId36GKv75Cc=.ba414d24-537f-4785-8371-e17b4f39c09e@github.com> References: <0ZhkX9_Rhl6vck_jDI37GaF6UaGvkkRoId36GKv75Cc=.ba414d24-537f-4785-8371-e17b4f39c09e@github.com> Message-ID: <4X-vzuNP711270lb1iPvBNfozZbULRCmAdVC_F48_h0=.a91e59cf-a967-47a1-b8e5-1eb1bed6da10@github.com> On Thu, 4 Sep 2025 03:40:25 GMT, Manukumar V S wrote: >> Issue: >> java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." >> I have seen it failing in all platforms, but predominantly in macos platform. >> It fails sometimes in CI also. >> >> Fix: >> Added a countdownlatch for tracking focusGained >> Added screenshot logic >> >> Testing: >> Tested in all mach5 platforms and got all PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Removed unwanted changes from .gitignore Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27039#pullrequestreview-3190305073 From dnguyen at openjdk.org Fri Sep 5 18:37:03 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 Sep 2025 18:37:03 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v5] In-Reply-To: References: Message-ID: > When testing jtreg manual tests, some tests were out of date. This PR is an attempt at updating the test and automating it. > > `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. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update exceptions, point, and vars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26636/files - new: https://git.openjdk.org/jdk/pull/26636/files/ff38da89..bccc167d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26636&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26636&range=03-04 Stats: 15 lines in 1 file changed: 2 ins; 4 del; 9 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 Fri Sep 5 18:37:06 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 Sep 2025 18:37:06 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v4] In-Reply-To: References: <_m2l5pTKApzMQM6zrtzdhKOuYFfttQGfpjjTaeTYYFE=.ffa5cc6d-f557-44a6-bb9c-3e46ee1e14ac@github.com> Message-ID: On Thu, 4 Sep 2025 08:09:54 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment edits > > test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 85: > >> 83: System.out.println(me.toString()); >> 84: throw new RuntimeException("Test failed. Mouse dragged " + >> 85: "event detected."); > > Suggestion: > > throw new RuntimeException("Mouse dragged event detected."); > > Being concise is better, isn't it? An exception is already an indicator that the test failed, let's just provide the reason. True, updated. Thanks! > test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 127: > >> 125: loc = p; >> 126: }); >> 127: robot.mouseMove(loc.x - 10, loc.y + 20); > > Suggestion: > > EventQueue.invokeAndWait(() -> { > Point p = list.getLocationOnScreen(); > p.translate(list.getWidth() - 10, 20); > loc = p; > }); > robot.mouseMove(loc.x, loc.y); > > Prepare the correct location inside `invokeAndWait`. The offsets could be declared constants, which may result in clearer code. Updated this and tested again on ubuntu 24.04 to double-check point values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2325783958 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2325784722 From dnguyen at openjdk.org Fri Sep 5 18:45:59 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 Sep 2025 18:45:59 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v6] In-Reply-To: References: Message-ID: > When testing jtreg manual tests, some tests were out of date. This PR is an attempt at updating the test and automating it. > > `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. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update with final var and loop increment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26636/files - new: https://git.openjdk.org/jdk/pull/26636/files/bccc167d..54eb11d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26636&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26636&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Fri Sep 5 18:45:59 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 Sep 2025 18:45:59 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v4] In-Reply-To: References: <_m2l5pTKApzMQM6zrtzdhKOuYFfttQGfpjjTaeTYYFE=.ffa5cc6d-f557-44a6-bb9c-3e46ee1e14ac@github.com> Message-ID: On Thu, 4 Sep 2025 08:20:05 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment edits > > test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 131: > >> 129: for (int i = 0; i < 30; i++) { >> 130: robot.mouseMove(loc.x, loc.y + 1); >> 131: } > > Suggestion: > > for (int i = 0; i < 30; i++) { > robot.mouseMove(loc.x, loc.y + i); > } > > I forgot to replace `1` with `i` in my earlier suggestion. > > This for-loop depends on the fact that `loc` contains the initial location for dragging the mouse. That is, the initial `robot.mouseMove` has to have arguments `(loc.x, loc.y)`, otherwise the mouse jumps `(+10, -20)` pixels. Thanks! Still worked, but this is the correct intention so I updated it as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2325800849 From liach at openjdk.org Fri Sep 5 18:55:11 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 18:55:11 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 17:15:47 GMT, Phil Race wrote: >> src/java.desktop/share/classes/java/awt/Robot.java line 977: >> >>> 975: public synchronized void type(int keycode) { >>> 976: keyPress(keycode); >>> 977: waitForIdle(20); >> >> Should this use `DEFAULT_STEP_DELAY` too? > > In the code this is based on (ExtendedRobot.java) it was called DEFAULT_SPEED and used by click and type as well as glide > As 'named' now, DEFAULT_STEP_DELAY is only appropriate for glide(..). There's no "stepping" here. > > And yet click(..) uses it (internally) > > so long as we don't document the name DEFAULT_STEP_DELAY on click() or type() it isn't critical. > I see a number of choices > - Use literal 20 here and in click > - Use DEFAULT_STEP_DELAY here and in click - do not document > - Add a new (private) DEFAULT_DELAY - and use it in both cases > - Add a new public DEFAULT_DELAY - and use it in both cases and document it > - Rename DEFAULT_STEP_DELAY to DEFAULT_DELAY - and use it in click and type as well as glide > > I'm inclined to go with the last of these - CSR will need to be revised. > But if we don't do that one now, it will be awkward to do later. > Thoughts ? > > PS I can see the potential need for an overload of click() and type() which accepts an alternate delay but I don't propose it here, I just note that for click() it would not be possible for the default click() to just accept a delay since that would clash with click(int buttons). I recommend revising the CSR. Since the CSR already has reviewers, once it is updated, it can be directly finalized for re-approval. Just describe the changes in a comment, and it should proceed smoothly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2325818064 From mvs at openjdk.org Fri Sep 5 19:53:16 2025 From: mvs at openjdk.org (Manukumar V S) Date: Fri, 5 Sep 2025 19:53:16 GMT Subject: Integrated: 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 07:16:20 GMT, Manukumar V S wrote: > Issue: > java/awt/Focus/ComponentLostFocusTest.java fails intermittently(2/40) with an exception " Execution failed: `main' threw exception: java.lang.RuntimeException: TextField got no focus! Test failed." > I have seen it failing in all platforms, but predominantly in macos platform. > It fails sometimes in CI also. > > Fix: > Added a countdownlatch for tracking focusGained > Added screenshot logic > > Testing: > Tested in all mach5 platforms and got all PASS. This pull request has now been integrated. Changeset: e2a503e2 Author: Manukumar V S URL: https://git.openjdk.org/jdk/commit/e2a503e26ee2a3c428c5db0cd4cbe71cdc7d837f Stats: 32 lines in 1 file changed: 20 ins; 6 del; 6 mod 8347277: java/awt/Focus/ComponentLostFocusTest.java fails intermittently Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/27039 From serb at openjdk.org Fri Sep 5 20:28:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 5 Sep 2025 20:28:15 GMT Subject: RFR: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 05:31:31 GMT, Sarvesh Kumar Jain wrote: >> The test is problem listed with incorrect bug JDK-6849371, >> The bug JDK-6849371 is for a different test and it is closed. >> A new bug has been raised for ChoiceMouseWheelTest.java test failure. > > Sarvesh Kumar Jain has updated the pull request incrementally with one additional commit since the last revision: > > Updated with new bugid Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27085#pullrequestreview-3190700094 From duke at openjdk.org Fri Sep 5 20:38:15 2025 From: duke at openjdk.org (Sarvesh Kumar Jain) Date: Fri, 5 Sep 2025 20:38:15 GMT Subject: Integrated: 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist In-Reply-To: References: Message-ID: <7VHcNTmY_7qgpdNgFWCI8Tzg6lpN6zHRitGv3yQALvI=.7d242abe-3803-4e4a-b454-634d061af770@github.com> On Thu, 4 Sep 2025 06:43:09 GMT, Sarvesh Kumar Jain wrote: > The test is problem listed with incorrect bug JDK-6849371, > The bug JDK-6849371 is for a different test and it is closed. > A new bug has been raised for ChoiceMouseWheelTest.java test failure. This pull request has now been integrated. Changeset: b674a425 Author: Sarvesh Kumar Jain Committer: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/b674a425531974bb78c4622e0f1d9b46a117f575 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8366750: Remove test 'java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java' from problemlist Reviewed-by: psadhukhan, serb ------------- PR: https://git.openjdk.org/jdk/pull/27085 From dnguyen at openjdk.org Fri Sep 5 21:49:10 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 5 Sep 2025 21:49:10 GMT Subject: RFR: 8366149: JNI exception pending in Java_sun_awt_X11GraphicsDevice_pGetBounds of awt_GraphicsEnv.c:1484 In-Reply-To: References: <23suWu7T8mP4QAs-wKAHZqW_L0ZrSqEa8ZDw8DE2yTg=.29cfda73-47b4-429a-ac9d-0dfd5cb6d409@github.com> Message-ID: On Fri, 5 Sep 2025 04:35:07 GMT, Phil Race wrote: >> In the scenario where AWT's UNLOCK API encounters a pendingException, the env pointer throws the pendingException (as seen in `awt.h`). However, in `Java_sun_awt_X11GraphicsDevice_pGetBounds`, after `AWT_UNLOCK`, the bounds var is set. The exception check does not occur until after the bounds is set, so the bounds may be set to an undesired value. This fix adds another exception check to look for this pendingException after `AWT_UNLOCK`. > > src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1289: > >> 1287: AWT_UNLOCK (); >> 1288: >> 1289: if ((*env)->ExceptionCheck(env)) { > > Is the problem that we are here because bounds == null and one way this is possible is that the call at line 1265 failed? Meaning threw an unlikely exception. > If so, maybe that is where we should just "return NULL". My understanding of the issue is that there is a possible `pendingException` on line 1287. This is possible by `AWT_NOFLUSH_UNLOCK_IMPL()` in `awt.h` as you previously pointed me to. Seems like setting bounds by the code that was previously on lines 1289-1290 was unsafe due to the `AWT_UNLOCK` possibly throwing an exception right before it. I don't think bounds can be null in this area because line 1279 checks for this. But if the `AWT_UNLOCK` here is throwing a `pendingException`, I think returning null is what should be done here since the same is done on line 1297, except this won't be reached in this case until after bounds is unsafely set. I can just `return NULL` instead near line 1265 as you suggested, but from what I read, the exception would be at line 1287 (which is after). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27110#discussion_r2326105323 From prr at openjdk.org Fri Sep 5 22:29:13 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 5 Sep 2025 22:29:13 GMT Subject: RFR: 8361381: GlyphLayout behavior differs on JDK 11+ compared to JDK 8 [v4] In-Reply-To: References: <2Q-ErTOjqRhIM7ih4B-AQGAcDwUduFP-yl6eA9XOqr0=.923100ae-4788-45f5-9279-51072c51100f@github.com> Message-ID: On Tue, 26 Aug 2025 17:32:36 GMT, Volker Simonis 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 test which checks correct line breaks Approving. The test passes on all platforms. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26825#pullrequestreview-3190962575 From psadhukhan at openjdk.org Sun Sep 7 06:28:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Sun, 7 Sep 2025 06:28:16 GMT Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0 [v4] In-Reply-To: References: Message-ID: <0NVvZdS0KsRnRY58nzBcSTq-1-7G_H0by2fDp0VpI-E=.bd2a2783-80d3-45d2-89f6-17533c14b1aa@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: Restrict negative increment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26500/files - new: https://git.openjdk.org/jdk/pull/26500/files/b4d22ac9..ba88e12e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=02-03 Stats: 2 lines in 1 file changed: 1 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 serb at openjdk.org Sun Sep 7 06:35:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 7 Sep 2025 06:35:56 GMT Subject: RFR: 8367017: Remove legacy checks from WrappedToolkitTest and convert from bash Message-ID: The Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh test: - Checks the "XToolkit" environment property, which was removed a long time ago - Checks the "awt.toolkit" java property, which was also removed a long time ago Since both have been removed, we can simplify the test and additionally drop the use of the bash script. ------------- Commit messages: - 8367017: Remove legacy checks from WrappedToolkitTest and convert from bash Changes: https://git.openjdk.org/jdk/pull/27127/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367017 Stats: 265 lines in 2 files changed: 7 ins; 231 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/27127.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27127/head:pull/27127 PR: https://git.openjdk.org/jdk/pull/27127 From duke at openjdk.org Sun Sep 7 11:36:25 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 11:36:25 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:23:40 GMT, Alexey Ivanov wrote: >> 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 > > And use a lambda expression instead of explicit anonymous `Runnable`. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328644031 From duke at openjdk.org Sun Sep 7 11:48:28 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 11:48:28 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:35:43 GMT, Alexey Ivanov wrote: >> 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 > > test/jdk/javax/swing/text/html/bug8314731.java line 28: > >> 26: * @bug 8314731 >> 27: * @summary FormView doesn't support the alt attribute >> 28: * @key headful > > Suggestion: > > * @bug 8314731 > * @key headful > * @summary FormView doesn't support the alt attribute > > Usually, `@key` follows after `@bug`? for consistency with other tests. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328648442 From duke at openjdk.org Sun Sep 7 11:58:18 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 11:58:18 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:17:16 GMT, Alexey Ivanov wrote: >> 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 > > test/jdk/javax/swing/text/html/bug8314731.java line 111: > >> 109: } >> 110: >> 111: private boolean ContainsAlt(Container container) { > > Suggestion: > > private boolean containsAlt(Container container) { > > Method names starts with lower-case letter. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328652451 From duke at openjdk.org Sun Sep 7 12:03:25 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 12:03:25 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:18:13 GMT, Alexey Ivanov wrote: >> 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 > > test/jdk/javax/swing/text/html/bug8314731.java line 121: > >> 119: if (ContainsAlt(cont)) { >> 120: return true; >> 121: } > > Suggestion: > > return ContainsAlt(cont)); > > There's no need for the `if`-statement here, too. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328653980 From duke at openjdk.org Sun Sep 7 12:42:14 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 12:42:14 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:31:33 GMT, Alexey Ivanov wrote: >> 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 > > test/jdk/javax/swing/text/html/bug8314731.java line 64: > >> 62: try { >> 63: SwingUtilities.invokeAndWait(bug8314731::createAndSetVisibleUI); >> 64: testPassed = ContainsAlt(jEditorPane); > > Technically, `ContainsAlt` should be called on EDT, too. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328667473 From duke at openjdk.org Sun Sep 7 12:52:14 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 12:52:14 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:37:18 GMT, Alexey Ivanov wrote: >> 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. > > Remove `InvocationTargetException` from imports. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328671252 From duke at openjdk.org Sun Sep 7 12:52:15 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 12:52:15 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:08:56 GMT, Alexey Ivanov wrote: >> 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 > > test/jdk/javax/swing/text/html/bug8314731.java line 50: > >> 48: private static boolean testPassed; >> 49: private static JFrame jf; >> 50: private static JEditorPane jEditorPane; > > Suggestion: > > private static JFrame frame; > private static JEditorPane editorPane; > > I prefer not to have `j` from `JFrame` or `JEditorPane` in the name of a field, it doesn't add anything; `frame` is more descriptive than `jf`. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328670793 From duke at openjdk.org Sun Sep 7 13:03:15 2025 From: duke at openjdk.org (ScientificWare) Date: Sun, 7 Sep 2025 13:03:15 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:10:08 GMT, Alexey Ivanov wrote: >> 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 > > test/jdk/javax/swing/text/html/bug8314731.java line 66: > >> 64: testPassed = ContainsAlt(jEditorPane); >> 65: } finally { >> 66: SwingUtilities.invokeAndWait(new Runnable() { > > Put this code directly into the `main` method instead of using `bug8314731` constructor. > > Taking other comments into account, I expect the `main` method to look like this: > > > public static void main(String[] args) throws Exception { > try { > SwingUtilities.invokeAndWait(bug8314731::createAndSetVisibleUI); > SwingUtilities.invokeAndWait(() -> { > if (!ContainsAlt(jEditorPane)) { > throw new RuntimeException("FormView doesn't support the alt attribute."); > } > }); > } finally { > SwingUtilities.invokeAndWait(() -> { > if (jf != null) { > jf.dispose(); > } > }); > } > } > > > Declare `containsAlt` static to be able to call it directly from `main`, remove the `testPassed` field and the `bug8314731` constructor. Addressed. > test/jdk/javax/swing/text/html/bug8314731.java line 76: > >> 74: private static void createAndSetVisibleUI() { >> 75: >> 76: jEditorPane = new JEditorPane(); > > Suggestion: > > private static void createAndSetVisibleUI() { > jEditorPane = new JEditorPane(); > > There's no need for a blank line as the first line of a method. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328675305 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2328675880 From smandalika at openjdk.org Mon Sep 8 08:42:35 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 8 Sep 2025 08:42:35 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v5] In-Reply-To: References: Message-ID: > 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. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: review Feedback: simplified test failure conditions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26471/files - new: https://git.openjdk.org/jdk/pull/26471/files/bb90ed63..91c145f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26471&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26471&range=03-04 Stats: 43 lines in 1 file changed: 11 ins; 21 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/26471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26471/head:pull/26471 PR: https://git.openjdk.org/jdk/pull/26471 From smandalika at openjdk.org Mon Sep 8 08:42:35 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 8 Sep 2025 08:42:35 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v3] In-Reply-To: References: <-nb8U6iT4ebHebd3ZVsPYpoSfRHBVS-bJX9A6x5aXXE=.506b6535-4cda-4969-8f32-9d8a59f1513b@github.com> Message-ID: On Fri, 5 Sep 2025 09:29:32 GMT, Prasanta Sadhukhan wrote: >> Yes, that was the code initially. The previous review suggested removal of the code as being redundant in the presence of the main method's throws Exception. There are pros and con to argue on both ways. Please let me know if you strong reason to not ok to not have in the current form. > > No, the code I asked to remove was for catching InterruptedException and rethrowing..This is for throwing RTE upfront if timeout exceeded, not by setting `passed `to `false `and continuing..I guess it has its merit of not continuing.. I have made the changes accordingly. Removed the passed & eventType variable for test pass/fail assertion. Tweaked to assert test scenario only on based on latch. Removed boiler plate code for mouse Move & Click. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2329547280 From psadhukhan at openjdk.org Mon Sep 8 08:55:22 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 8 Sep 2025 08:55:22 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" Message-ID: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Test used to fail earlier with above message. Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting ------------- Commit messages: - 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1] Changes: https://git.openjdk.org/jdk/pull/27136/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27136&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8256289 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27136.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27136/head:pull/27136 PR: https://git.openjdk.org/jdk/pull/27136 From duke at openjdk.org Mon Sep 8 09:13:09 2025 From: duke at openjdk.org (ScientificWare) Date: Mon, 8 Sep 2025 09:13:09 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v11] In-Reply-To: References: Message-ID: > 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 = """ > > > >

> >

> Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. ------------- Commit messages: - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update - 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update Changes: https://git.openjdk.org/jdk/pull/27139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8068378 Stats: 35 lines in 2 files changed: 0 ins; 10 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/27139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27139/head:pull/27139 PR: https://git.openjdk.org/jdk/pull/27139 From aivanov at openjdk.org Mon Sep 8 11:52:21 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 8 Sep 2025 11:52:21 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v6] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 18:45:59 GMT, Damon Nguyen wrote: >> When testing jtreg manual tests, some tests were out of date. This PR is an attempt at updating the test and automating it. >> >> `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. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update with final var and loop increment Changes requested by aivanov (Reviewer). test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 47: > 45: private static Frame frame; > 46: private static volatile Point loc; > 47: private static volatile List list; Suggestion: private static List list; There's no reason for `list` to be volatile. test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 53: > 51: public static void main(String[] args) throws Exception { > 52: try { > 53: createUI(); Should `createUI` be called on EDT? test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 85: > 83: @Override > 84: public void mouseDragged(MouseEvent me){ > 85: System.out.println(me.toString()); Suggestion: System.out.println(me); `.toString()` is redundant for `println`. test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 93: > 91: new MouseAdapter() { > 92: public void mousePressed(MouseEvent me) { > 93: System.out.println(me.toString()); Suggestion: System.out.println(me); ------------- PR Review: https://git.openjdk.org/jdk/pull/26636#pullrequestreview-3196160889 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2330001941 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2330000948 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2329996596 PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2329998506 From simonis at openjdk.org Mon Sep 8 13:33:18 2025 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 8 Sep 2025 13:33:18 GMT Subject: Integrated: 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: On Mon, 18 Aug 2025 16:05:24 GMT, Volker Simonis 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'... This pull request has now been integrated. Changeset: bcff857b Author: Volker Simonis URL: https://git.openjdk.org/jdk/commit/bcff857ba09028cc43e856726b5c839cc6b1b0d9 Stats: 141 lines in 3 files changed: 133 ins; 5 del; 3 mod 8361381: GlyphLayout behavior differs on JDK 11+ compared to JDK 8 Reviewed-by: prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/26825 From jwaters at openjdk.org Mon Sep 8 14:17:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:17:52 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v7] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > build.log on release configuration: > > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] > 334 | bool freeData = false; > | ^~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] > 326 | DWORD retval = -1; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] > 379 | bool freeData = false; > | ^~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] > 367 | DWORD retval = -1; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibi... Julian Waters has updated the pull request incrementally with five additional commits since the last revision: - Fixup code in JavaAccessBridge.cpp - Mark unused code in AccessBridgeJavaVMInstance.cpp - Mark lastError in jaccessinspector.cpp - Remove other retval from jabswitch.cpp - Remove retval from jabswitch.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21656/files - new: https://git.openjdk.org/jdk/pull/21656/files/47b168a3..690daaf5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21656&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21656&range=05-06 Stats: 7 lines in 4 files changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21656/head:pull/21656 PR: https://git.openjdk.org/jdk/pull/21656 From jwaters at openjdk.org Mon Sep 8 14:17:53 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:17:53 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: <3WQWjPLR53Jw71ZT5CCNdiH5ERIyaoOIR5ulV1HwyV8=.74526f69-24a5-4988-8565-6382d9dcbc85@github.com> On Thu, 23 Jan 2025 05:34:00 GMT, Julian Waters wrote: >> src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp line 1212: >> >>> 1210: } >>> 1211: >>> 1212: static_cast(lastError); >> >> This falls into category that's useful for debugging only. The value of `lastError` is never used to report an error, yet one can use a debugger to inspect the value. >> >> There seems to be no way to report or log the error. >> >> Isn't it better to add a flag to suppress the warning? Casting `lastError` to `void` is cryptic. A comment would definitely be helpful here. > > I suppose I could do that yes, if that that is preferred [[maybe_unused]] has arrived! Let's all rejoice! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r2330378837 From jwaters at openjdk.org Mon Sep 8 14:17:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:17:52 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 17:33:42 GMT, Alexey Ivanov wrote: >> I'll submit a new bug to address this problem. >> >> It's not just a matter of an unused variables, it's the logic error: if the buffer is too small, *a new buffer is allocated*, yet this new buffer isn't deleted afterwards, nor is used to read the value retrieved from the registry. > > I submitted [JDK-8348872](https://bugs.openjdk.org/browse/JDK-8348872): _jabswitch.cpp: regEnable and regDeleteValue leak reallocated data buffer_. Hi, I'm back to trying to work on the JDK now. Should this issue depend on 8348872 and 8348876? Hopefully those can be fixed soon ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r2330364028 From jwaters at openjdk.org Mon Sep 8 14:17:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:17:52 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v6] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 05:37:29 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request incrementally with two additional commits since the last revision: > > - Typo in AccessBridgeCalls.c > - Fix AccessBridgeCalls.c I deeply apologize for waiting for so long to come back to this, life caught up with me in the meantime. Once I can get some of my HotSpot changes in I promise I'll fix this for good. In other news, we have C++17 now! [[maybe_unused]] is now on the table and will prove to be very helpful here ------------- PR Comment: https://git.openjdk.org/jdk/pull/21656#issuecomment-3266489106 From jwaters at openjdk.org Mon Sep 8 14:21:24 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:21:24 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 17:38:29 GMT, Alexey Ivanov wrote: >> I see no reason to keep it. >> >> If it's needed during debugging, there are many ways to find the handle. >> >> Otherwise, the edit control is accessed by its id: `cAccessInfoText`. > > It looks like this feature doesn't work: [JDK-8348882](https://bugs.openjdk.org/browse/JDK-8348882): )jaccesswalker: "Display Accessibility Information" doesn't work_ > > It's not related to your changes directly, it's just an observation after running `jaccesswalker.exe`; I'm still for removing `hwndEdit`. Paging @azuev-java can I remove hwndEdit? Asking since you were in favour of keeping it earlier ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r2330405896 From jwaters at openjdk.org Mon Sep 8 14:25:02 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:25:02 GMT Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt [v2] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > build.log on release configuration: > > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=] > 3560 | static const UINT _VKS_ALT_MASK = 0x04; > | ^~~~~~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs] > 1361 | } SUBTABLE, *PSUBTABLE; > | ^~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs] > 1588 | } HEAD, *PHEAD; > | ^~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs] > 1595 | } ENTRY, *PENTRY; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/... Julian Waters 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 awt - 8342869 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21655/files - new: https://git.openjdk.org/jdk/pull/21655/files/ee4d1bb5..90903171 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21655&range=00-01 Stats: 1560860 lines in 20249 files changed: 770956 ins; 654744 del; 135160 mod Patch: https://git.openjdk.org/jdk/pull/21655.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21655/head:pull/21655 PR: https://git.openjdk.org/jdk/pull/21655 From jwaters at openjdk.org Mon Sep 8 14:28:27 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Sep 2025 14:28:27 GMT Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 14:25:02 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=] >> 3560 | static const UINT _VKS_ALT_MASK = 0x04; >> | ^~~~~~~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs] >> 1361 | } SUBTABLE, *PSUBTABLE; >> | ^~~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs] >> 1588 | } HEAD, *PHEAD; >> | ^~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs] >> 1595 | } ENTRY, *PENTRY; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/w... > > Julian Waters 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 awt > - 8342869 Hi Phil, would it help if I split out the moving of DrawingStateProp to the C++ file to another Pull Request? Majority of this Pull Request is dead constants and the remainder are things that are needed but will raise an unused error anyway (Like the struct typedefs) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-3266585629 From azvegint at openjdk.org Mon Sep 8 16:37:51 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 8 Sep 2025 16:37:51 GMT Subject: RFR: 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux Message-ID: This changeset excludes the test from running on Linux. We receive a ConfigureNotify from the system (Gnome Shell) with the initial window size. However, this does not happen on Plasma. ------------- Commit messages: - 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux Changes: https://git.openjdk.org/jdk/pull/27149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321289 Stats: 4 lines in 2 files changed: 1 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27149/head:pull/27149 PR: https://git.openjdk.org/jdk/pull/27149 From duke at openjdk.org Mon Sep 8 16:48:13 2025 From: duke at openjdk.org (lawrence.andrews) Date: Mon, 8 Sep 2025 16:48:13 GMT Subject: RFR: 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux In-Reply-To: References: Message-ID: <1fyXbAUwaO6dAgDGnHqqxWw5O4R-95-7-_ZUSebDxtc=.19e79206-bba7-4fed-b6aa-97f94009df6b@github.com> On Mon, 8 Sep 2025 16:30:48 GMT, Alexander Zvegintsev wrote: > This changeset excludes the test from running on Linux. We receive a ConfigureNotify from the system (Gnome Shell) with the initial window size. However, this does not happen on Plasma. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/27149#issuecomment-3267128866 From serb at openjdk.org Mon Sep 8 16:54:11 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 Sep 2025 16:54:11 GMT Subject: RFR: 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 16:30:48 GMT, Alexander Zvegintsev wrote: > This changeset excludes the test from running on Linux. We receive a ConfigureNotify from the system (Gnome Shell) with the initial window size. However, this does not happen on Plasma. If the initial size is correct now, why do we receive a notification in Java when the size hasn't changed from the initial one? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27149#issuecomment-3267146478 From serb at openjdk.org Mon Sep 8 16:55:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 8 Sep 2025 16:55:10 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" In-Reply-To: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Mon, 8 Sep 2025 08:46:59 GMT, Prasanta Sadhukhan wrote: > Test used to fail earlier with above message. > Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27136#pullrequestreview-3197343912 From honkar at openjdk.org Mon Sep 8 17:54:14 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 8 Sep 2025 17:54:14 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" In-Reply-To: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Mon, 8 Sep 2025 08:46:59 GMT, Prasanta Sadhukhan wrote: > Test used to fail earlier with above message. > Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting Do we consider renaming the test in this or a separate PR since Applets usage is removed? Actually there are 2 Applet based tests in java/awt/Focus/AppletInitialFocusTest folder. These tests can be deleted if they are decided that they are no longer relevant. ------------- PR Review: https://git.openjdk.org/jdk/pull/27136#pullrequestreview-3197515321 From prr at openjdk.org Mon Sep 8 18:04:14 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 8 Sep 2025 18:04:14 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Mon, 8 Sep 2025 17:51:45 GMT, Harshitha Onkar wrote: > Do we consider renaming the test in this or a separate PR since Applets usage is removed? > > Actually there are 2 Applet based tests in java/awt/Focus/AppletInitialFocusTest folder. These tests can be deleted if they are decided that they are no longer relevant. They aren't "Applet based". Haven't been over over 6 years. I think we should remove the "Applet" prefix from the name and this is as good a time as any to do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27136#issuecomment-3267347452 From duke at openjdk.org Mon Sep 8 19:43:58 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Mon, 8 Sep 2025 19:43:58 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v6] In-Reply-To: References: Message-ID: > The fix for the https://bugs.openjdk.org/browse/JDK-8251928. > > **Description**. > This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. > > As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): > 1. Convert the user-space point, size, or rectangle value to device space coordinates; > 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; > 3. Convert the normalized value back to user space; > 4. Draw your content using the adjusted value. > > The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. > The 2-nd step is a drawing process in the java code (without changes). > The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. > The 4-th step is a drawing process in the native code (without changes). > > **Tests**. > I run all tests from javax.print package and there is no any regression. > New test covers macOS and Linux only because we know its default DPI - 300. GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: move scaling to GraphicsConfig, update PeekGraphics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25489/files - new: https://git.openjdk.org/jdk/pull/25489/files/1e32943f..4788612d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=04-05 Stats: 88 lines in 4 files changed: 37 ins; 35 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489 PR: https://git.openjdk.org/jdk/pull/25489 From duke at openjdk.org Mon Sep 8 21:56:14 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Mon, 8 Sep 2025 21:56:14 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v5] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 21:58:50 GMT, Phil Race wrote: >> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: >> >> revert CGraphicsDevice.m constants. Update orientation constant usage > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 470: > >> 468: @Override >> 469: protected double getXRes() { >> 470: return hRes; > > I have been unable to verify that this would be applied with a real printer device resolution, because my printer is not reporting PrinterResolution. Not sure why. I see it in the PPD but the call to the cups ppd API isn't finding it. > Thinking about it, this is may be the "real" problem if something in this API used to work but has stopped working. I'm able to choose and set resolution for a Zebra Label Printer, its PPD contains *DefaultResolution: 300dpi *Resolution 203dpi/203dpi: "<>setpagedevice" *Resolution 300dpi/300dpi: "<>setpagedevice" *Resolution 600dpi/600dpi: "<>setpagedevice" CUPS API returns nothing for Brother DCP-T720, and its PPD contains _DefaultResolution_ only. *TTRasterizer: Type42 *DefaultResolution: 300dpi *FreeVM: "1700000" I'm sure the reason is the lack of _Resolution_ options. The _DefaultResolution_ attribute is not read in Java_sun_print_CUPSPrinter_getResolutions function. I tried adding a _ppdFindAttr(ppd_file, "DefaultResolution", NULL)_ function call and it returned correct default value. > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 795: > >> 793: return scaledPage; >> 794: } >> 795: > > This is something of an abuse of these APIs which are *specified* to have sizes in 1/72" > > This is all needed here because createData takes a PageFormat. > I looked and unless I am missing something all it ever does is use the bounds to return those (now larger) device bounds. > > I would consider it a better approach to modify CPrinterSurfaceData.createData to accept what it really needs .. the device bounds. I don't see that it needs a page format. You absolutely right about the specified size. I moved the changes to the CPrinterGraphicsConfig. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2331457749 PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2331463639 From duke at openjdk.org Mon Sep 8 21:56:15 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Mon, 8 Sep 2025 21:56:15 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v4] In-Reply-To: References: Message-ID: <8j99l62hPWmo_I4zptUYJHn4Uh-f3pxzc2PZZ7_mjAw=.2c537097-3a70-4278-ba00-6f678fd6bab5@github.com> On Thu, 4 Sep 2025 18:51:23 GMT, Phil Race wrote: >> This is a good point, but I have not changed the existing approach to creating a PeekGraphics. A BufferedImage is created based on the paper format size and DPI. >> Does changing the approach to memory consumption align with the goals of this PR, to be able to set the document's DPI to match the printer's DPI? > > supposing we have a 1200 dpi printer and someone prints to A3 paper. > That's approx 12x16 inches and its ARGB so > 12 * 1_200 * 16 * 1_200 * 4 .. that's over a Gigabyte ! > > So what you are doing isn't viable as well as unnecessary. Changed BufferedImage size to 1x1. This peekGraphics and its configuration, matrix are visible to user and it would be better if the "peek" graphics was the same as "printing" graphics. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2331460942 From dnguyen at openjdk.org Mon Sep 8 23:31:47 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 Sep 2025 23:31:47 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v5] In-Reply-To: References: Message-ID: > Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Review comment updates after testing generation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26969/files - new: https://git.openjdk.org/jdk/pull/26969/files/a9f6f5b1..d324ea9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26969&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26969&range=03-04 Stats: 20 lines in 1 file changed: 4 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26969/head:pull/26969 PR: https://git.openjdk.org/jdk/pull/26969 From dnguyen at openjdk.org Mon Sep 8 23:31:51 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 Sep 2025 23:31:51 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 18:52:58 GMT, Chen Liang wrote: >> In the code this is based on (ExtendedRobot.java) it was called DEFAULT_SPEED and used by click and type as well as glide >> As 'named' now, DEFAULT_STEP_DELAY is only appropriate for glide(..). There's no "stepping" here. >> >> And yet click(..) uses it (internally) >> >> so long as we don't document the name DEFAULT_STEP_DELAY on click() or type() it isn't critical. >> I see a number of choices >> - Use literal 20 here and in click >> - Use DEFAULT_STEP_DELAY here and in click - do not document >> - Add a new (private) DEFAULT_DELAY - and use it in both cases >> - Add a new public DEFAULT_DELAY - and use it in both cases and document it >> - Rename DEFAULT_STEP_DELAY to DEFAULT_DELAY - and use it in click and type as well as glide >> >> I'm inclined to go with the last of these - CSR will need to be revised. >> But if we don't do that one now, it will be awkward to do later. >> Thoughts ? >> >> PS I can see the potential need for an overload of click() and type() which accepts an alternate delay but I don't propose it here, I just note that for click() it would not be possible for the default click() to just accept a delay since that would clash with click(int buttons). > > I recommend revising the CSR. Since the CSR already has reviewers, once it is updated, it can be directly finalized for re-approval. Just describe the changes in a comment, and it should proceed smoothly. I have chosen to go with Phil's last point as he suggested. I renamed all instances of `DEFAULT_STEP_DELAY` to `DEFAULT_DELAY`. I also updated the docs where needed. I generated the docs to view how it looks with all the suggestions implemented, and I believe it looks presentable now but let me know if anyone finds any issues. I will revise the CSR with the new updates. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2331580759 From dnguyen at openjdk.org Mon Sep 8 23:31:50 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 Sep 2025 23:31:50 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v4] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 23:46:50 GMT, Chen Liang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Add finally block > > src/java.desktop/share/classes/java/awt/Robot.java line 792: > >> 790: /** >> 791: * A convenience method that simulates clicking a mouse button by calling {@code mousePress}, {@code mouseRelease}, >> 792: * and {@code waitForIdle}. Invokes {@code waitForIdle} with a default delay of 20 milliseconds after > > Suggestion: > > * and {@code waitForIdle}. Invokes {@code waitForIdle} with a default delay of {@value #DEFAULT_STEP_DELAY} milliseconds after > > This renders `20` as a link that links to the constant that users can use. Updated, thanks. > src/java.desktop/share/classes/java/awt/Robot.java line 855: > >> 853: * >> 854: * @implSpec Invokes {@link #mouseMove(int, int) mouseMove} with a default >> 855: * {@link #DEFAULT_STEP_LENGTH step-length} and {@link #DEFAULT_STEP_DELAY step-delay}. > > You can use: > > * @implSpec Invokes {@link #mouseMove(int, int) mouseMove} with a step-length > * of {@value #DEFAULT_STEP_LENGTH} and a step-delay of {@value #DEFAULT_STEP_DELAY}. > > > Renders like: > >> Invokes [`mouseMove`]() with a step-length of [`2`]() and a a step-delay of [`20`](). > > Same for other sites. Updated this and in similar spots. Let me know if you see any other issues with this. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2331578071 PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2331579028 From dnguyen at openjdk.org Mon Sep 8 23:41:57 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 8 Sep 2025 23:41:57 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v6] In-Reply-To: References: Message-ID: > Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Add one missing source of default_delay value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26969/files - new: https://git.openjdk.org/jdk/pull/26969/files/d324ea9d..215ff9d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26969&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26969&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26969/head:pull/26969 PR: https://git.openjdk.org/jdk/pull/26969 From tr at openjdk.org Tue Sep 9 04:08:33 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 9 Sep 2025 04:08:33 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v11] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:13:09 GMT, ScientificWare 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 = """ >> >> >> >>

>> - 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. > - ... and 17 more: https://git.openjdk.org/jdk/compare/bea2b029...25965200 LGTM. ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-3199126239 From psadhukhan at openjdk.org Tue Sep 9 04:08:48 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 Sep 2025 04:08:48 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v2] In-Reply-To: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: > Test used to fail earlier with above message. > Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Rename applet test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27136/files - new: https://git.openjdk.org/jdk/pull/27136/files/2ca05f0d..8c5cb819 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27136&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27136&range=00-01 Stats: 146 lines in 2 files changed: 146 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27136.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27136/head:pull/27136 PR: https://git.openjdk.org/jdk/pull/27136 From psadhukhan at openjdk.org Tue Sep 9 04:08:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 Sep 2025 04:08:49 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v2] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Mon, 8 Sep 2025 18:01:49 GMT, Phil Race wrote: > > Do we consider renaming the test in this or a separate PR since Applets usage is removed? > > Actually there are 2 Applet based tests in java/awt/Focus/AppletInitialFocusTest folder. These tests can be deleted if they are decided that they are no longer relevant. > > They aren't "Applet based". Haven't been over over 6 years. I think we should remove the "Applet" prefix from the name and this is as good a time as any to do that. Renamed ------------- PR Comment: https://git.openjdk.org/jdk/pull/27136#issuecomment-3268793302 From psadhukhan at openjdk.org Tue Sep 9 05:00:17 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 Sep 2025 05:00:17 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components Message-ID: Test was failing due to lack of time between initializing graphics components and test start. Added robot delay and execution under EDT. Several iterations of test is passing so deproblemlisting, CI job link in JBS ------------- Commit messages: - 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components Changes: https://git.openjdk.org/jdk/pull/27156/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8023263 Stats: 28 lines in 2 files changed: 11 ins; 9 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27156.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27156/head:pull/27156 PR: https://git.openjdk.org/jdk/pull/27156 From rkannathpari at openjdk.org Tue Sep 9 05:15:41 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 9 Sep 2025 05:15:41 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results Message-ID: Hi Reviewers, I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code Please review and let me know your suggestions if any. ------------- Commit messages: - 8365379: SU3.applyInsets may produce wrong results Changes: https://git.openjdk.org/jdk/pull/27157/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365379 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27157.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27157/head:pull/27157 PR: https://git.openjdk.org/jdk/pull/27157 From duke at openjdk.org Tue Sep 9 05:18:25 2025 From: duke at openjdk.org (Disha Morye) Date: Tue, 9 Sep 2025 05:18:25 GMT Subject: RFR: 8366764: Deproblemlist java/awt/ScrollPane/ScrollPositionTest.java Message-ID: <_MYLhZbG8CeqFNFgkBGDwAEwap4499uL4Theq9duL9k=.9267f267-f6e7-45ff-a533-2cc81489eb86@github.com> The test is open sourced and is passing on linux. Hence, it can be removed from the Problem List. ------------- Commit messages: - 8366764: Deproblemlist java/awt/ScrollPane/ScrollPositionTest.java Changes: https://git.openjdk.org/jdk/pull/27111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366764 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27111/head:pull/27111 PR: https://git.openjdk.org/jdk/pull/27111 From azvegint at openjdk.org Tue Sep 9 06:35:23 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 Sep 2025 06:35:23 GMT Subject: RFR: 8366852: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java test is failing Message-ID: There are several major issues with the test: 1. The `frameExited` variable is set to true when the mouse pointer exits the frame. The test does not expect this to happen with the first mouse click on the `choice` when the mouse pointer is already over the test frame (frame mouseExited - > choice mouseEntered). A reset for the frameExited was added. 2. The test does not wait for the frame to appear after the call to `setVisible()`, so the test can start operating not on a fully visible window (e.g. one with an appearance animation). A delay has been added. 3. In macOS, the direction of rotation of the mouse wheel is different, which was not taken into account. Testing looks good. ------------- Commit messages: - remove System.exit() - fix enter drop-down condition - cleanup - actual fix Changes: https://git.openjdk.org/jdk/pull/27161/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27161&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366852 Stats: 105 lines in 2 files changed: 37 ins; 22 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/27161.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27161/head:pull/27161 PR: https://git.openjdk.org/jdk/pull/27161 From psadhukhan at openjdk.org Tue Sep 9 07:04:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 Sep 2025 07:04:52 GMT Subject: RFR: 8162380: [TEST_BUG]Failed the case just press the "fail" button on other platform except linux. Message-ID: Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". Modified the test to use PFJ and also clarified the instruction for Windows and Linux ------------- Commit messages: - title fix - 8162380: [TEST_BUG]Failed the case just press the fail button on other platform except linux. Changes: https://git.openjdk.org/jdk/pull/27162/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8162380 Stats: 240 lines in 2 files changed: 26 ins; 200 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27162/head:pull/27162 PR: https://git.openjdk.org/jdk/pull/27162 From duke at openjdk.org Tue Sep 9 09:06:34 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Tue, 9 Sep 2025 09:06:34 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out [v7] In-Reply-To: References: Message-ID: > The fix for the https://bugs.openjdk.org/browse/JDK-8251928. > > **Description**. > This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob. > > As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ): > 1. Convert the user-space point, size, or rectangle value to device space coordinates; > 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary; > 3. Convert the normalized value back to user space; > 4. Draw your content using the adjusted value. > > The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI. > The 2-nd step is a drawing process in the java code (without changes). > The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI. > The 4-th step is a drawing process in the native code (without changes). > > **Tests**. > I run all tests from javax.print package and there is no any regression. > New test covers macOS and Linux only because we know its default DPI - 300. GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'openjdk:master' into macOS_printing_DPI - move scaling to GraphicsConfig, update PeekGraphics - revert CGraphicsDevice.m constants. Update orientation constant usage - remove setDevClip usage. Update names. Handle page format orientation. - Merge branch 'openjdk:master' into macOS_printing_DPI - Merge branch 'openjdk:master' into macOS_printing_DPI - [macos] the printer DPI always be 72 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25489/files - new: https://git.openjdk.org/jdk/pull/25489/files/4788612d..4f2a0318 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25489&range=05-06 Stats: 18103 lines in 977 files changed: 8392 ins; 5814 del; 3897 mod Patch: https://git.openjdk.org/jdk/pull/25489.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489 PR: https://git.openjdk.org/jdk/pull/25489 From aivanov at openjdk.org Tue Sep 9 10:39:26 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 9 Sep 2025 10:39:26 GMT Subject: RFR: 8162380: [TEST_BUG]Failed the case just press the "fail" button on other platform except linux. In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 06:55:27 GMT, Prasanta Sadhukhan wrote: > Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". > > Modified the test to use PFJ and also clarified the instruction for Windows and Linux test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 46: > 44: Please check if Alt-Gr key is present on keyboard. > 45: If not present, press Pass. > 46: Window :- Suggestion: On Windows: There should be no space before colon? in English punctuation. test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 49: > 47: Press Alt-Gr or Right Alt key and simulataneously > 48: perform mouse click on the "TestWindow". > 49: Linux :- Suggestion: On Linux: test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 51: > 49: Linux :- > 50: Navigate to > 51: System Settings-> Keyboard-> Shortcuts->Typing. Suggestion: System Settings-> Keyboard-> Shortcuts-> Typing. Be consistent. test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 53: > 51: System Settings-> Keyboard-> Shortcuts->Typing. > 52: Select an option for the Alternative Characters Key > 53: For example. Right Alt The instructions are still unclear to me. There's no **Shortcut** settings in GNOME in Ubuntu 22.04. There is, however, **Keyboard Shortcuts** section with **View and customise shortcuts**. In the popup, there's a **Typing** section, but there's nothing like alternative keys. On the main **Keyboard** settings screen, there's an option **Alternate Characters Key**, it's set to **Layout default** in my settings. Is this the option to change? The original instructions make the tester *click twice*: before changing an option in the settings and after doing so. The new instructions ask to change the setting only. test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 75: > 73: mainFrame.addMouseListener(new MouseAdapter() { > 74: @Override > 75: public void mousePressed(MouseEvent e) { Suggestion: @Override public void mousePressed(MouseEvent e) { Correct the indentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2332952808 PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2332953456 PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2332955194 PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2332996463 PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2332997611 From azvegint at openjdk.org Tue Sep 9 10:54:24 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 Sep 2025 10:54:24 GMT Subject: RFR: 8366764: Deproblemlist java/awt/ScrollPane/ScrollPositionTest.java In-Reply-To: <_MYLhZbG8CeqFNFgkBGDwAEwap4499uL4Theq9duL9k=.9267f267-f6e7-45ff-a533-2cc81489eb86@github.com> References: <_MYLhZbG8CeqFNFgkBGDwAEwap4499uL4Theq9duL9k=.9267f267-f6e7-45ff-a533-2cc81489eb86@github.com> Message-ID: <90EtBsTyL4pBkGL__R9bjZohQbzRoIn6_UY5Jas7DBE=.37da7016-7472-47d8-b159-d8b0ff987f96@github.com> On Fri, 5 Sep 2025 05:59:21 GMT, Disha Morye wrote: > The test is open sourced and is passing on linux. Hence, it can be removed from the Problem List. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27111#pullrequestreview-3200874406 From psadhukhan at openjdk.org Tue Sep 9 11:53:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 Sep 2025 11:53:28 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v2] In-Reply-To: References: Message-ID: > Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". > > Modified the test to use PFJ and also clarified the instruction for Windows and Linux Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Clarify instruction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27162/files - new: https://git.openjdk.org/jdk/pull/27162/files/7d78a778..87957dbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27162&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27162&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27162/head:pull/27162 PR: https://git.openjdk.org/jdk/pull/27162 From psadhukhan at openjdk.org Tue Sep 9 11:53:33 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 9 Sep 2025 11:53:33 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:35:18 GMT, Alexey Ivanov wrote: > On the main Keyboard settings screen, there's an option Alternate Characters Key, it's set to Layout default in my settings. Is this the option to change? Yes, I modified the instruction keyboard-shortcut ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2333197419 From serb at openjdk.org Tue Sep 9 17:30:45 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 9 Sep 2025 17:30:45 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 05:08:42 GMT, Renjith Kannath Pariyangad wrote: > Hi Reviewers, > > I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code > > Please review and let me know your suggestions if any. Can this change covered by the new test? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27157#issuecomment-3271653651 From serb at openjdk.org Tue Sep 9 17:48:12 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 9 Sep 2025 17:48:12 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 04:34:13 GMT, Prasanta Sadhukhan wrote: > Test was failing due to lack of time between initializing graphics components and test start. > Added robot delay and execution under EDT. > > Several iterations of test is passing so deproblemlisting, CI job link in JBS test/jdk/java/awt/Focus/InactiveFocusRace.java line 109: > 107: } > 108: }); > 109: inactiveFrame.setVisible(true); The previous version used a Semaphore to wait until the frame became active or the button received focus, but it didn?t check the second inactive frame. I think what we should do is first show the "inactive" frame using the same Semaphore. Then, once it becomes visible, we should show another "active" frame. This will ensure that the frame we intend to click below remains inactive/unfocused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27156#discussion_r2334342651 From honkar at openjdk.org Tue Sep 9 18:04:13 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 9 Sep 2025 18:04:13 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v2] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Tue, 9 Sep 2025 04:08:48 GMT, Prasanta Sadhukhan wrote: >> Test used to fail earlier with above message. >> Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Rename applet test LGTM apart from minor rename suggestion. test/jdk/java/awt/Focus/FrameInitialFocusTest/FrameInitialFocusTest.java line 66: > 64: Util.waitForIdle(robot); > 65: if (!button.hasFocus()) { > 66: throw new RuntimeException("Appletviewer doesn't set default focus correctly."); AppletViewer => Frame ? ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27136#pullrequestreview-3202703456 PR Review Comment: https://git.openjdk.org/jdk/pull/27136#discussion_r2334374645 From prr at openjdk.org Tue Sep 9 18:37:57 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 9 Sep 2025 18:37:57 GMT Subject: RFR: 8366149: JNI exception pending in Java_sun_awt_X11GraphicsDevice_pGetBounds of awt_GraphicsEnv.c:1484 In-Reply-To: References: <23suWu7T8mP4QAs-wKAHZqW_L0ZrSqEa8ZDw8DE2yTg=.29cfda73-47b4-429a-ac9d-0dfd5cb6d409@github.com> Message-ID: On Fri, 5 Sep 2025 21:46:22 GMT, Damon Nguyen wrote: >> src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1289: >> >>> 1287: AWT_UNLOCK (); >>> 1288: >>> 1289: if ((*env)->ExceptionCheck(env)) { >> >> Is the problem that we are here because bounds == null and one way this is possible is that the call at line 1265 failed? Meaning threw an unlikely exception. >> If so, maybe that is where we should just "return NULL". > > My understanding of the issue is that there is a possible `pendingException` on line 1287. This is possible by `AWT_NOFLUSH_UNLOCK_IMPL()` in `awt.h` as you previously pointed me to. Seems like setting bounds by the code that was previously on lines 1289-1290 was unsafe due to the `AWT_UNLOCK` possibly throwing an exception right before it. > > I don't think bounds can be null in this area because line 1279 checks for this. But if the `AWT_UNLOCK` here is throwing a `pendingException`, I think returning null is what should be done here since the same is done on line 1297, except this won't be reached in this case until after bounds is unsafely set. > > I can just `return NULL` instead near line 1265 as you suggested, but from what I read, the exception would be at line 1287 (which is after). You are right - there is a check for !bounds. Although that is likely there because we might not be in the Xinerama case, not a concern about a pending exception, although it would also help in that case too. However if NewObject fails then bounds will be null and there will be a pending exception. So I think we should return immediately in that case. But my point is that this bug report is a result of static analysis, so we should be able to follow that same logic. Meaning AWT_UNLOCK isn't the source of the exception. It is rethrowing one it previously copied and cleared But it only does all of that IF there was such a pending exception. So I am looking back at where the exception might have come from. I missed this line (*env)->ThrowNew(env, exceptionClass, "Illegal screen index"); that seems likely to be it. If we are throwing an exception because of an illegal screen index, there is absolutely no point in returning a new object - the caller won't be able to receive it because they'll get an exception. And clearing it would be wrong - it is meant to be thrown. So there should also be a return after that ThrowNew. Once you've done that we can statically prove there are no possible pending exceptions and this call to ExceptionCheck isn't necessary. Basically a fix for this is to return immediately in both cases - failure of NewObject and ThrowNew. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27110#discussion_r2334443764 From prr at openjdk.org Tue Sep 9 18:42:52 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 9 Sep 2025 18:42:52 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v2] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Tue, 9 Sep 2025 18:00:50 GMT, Harshitha Onkar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename applet test > > test/jdk/java/awt/Focus/FrameInitialFocusTest/FrameInitialFocusTest.java line 66: > >> 64: Util.waitForIdle(robot); >> 65: if (!button.hasFocus()) { >> 66: throw new RuntimeException("Appletviewer doesn't set default focus correctly."); > > AppletViewer => Frame ? The frame isn't setting the focus. "Focus not set on button" might be better , but I do agree the word "Appletviewer" needs to be gone ! And I was suggesting to just make the test name "IntitialFocusTest" I thought about changing it to Frame IntitialFocusTest, but it isn't the Frame we expect to get focus. It's the button. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27136#discussion_r2334456604 From azvegint at openjdk.org Tue Sep 9 20:58:27 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 9 Sep 2025 20:58:27 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:53:28 GMT, Prasanta Sadhukhan wrote: >> Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". >> >> Modified the test to use PFJ and also clarified the instruction for Windows and Linux > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Clarify instruction test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 47: > 45: If not present, press Pass. > 46: On Windows: > 47: Press Alt-Gr or Right Alt key and simulataneously Suggestion: Press Alt-Gr or Right Alt key and simultaneously test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 52: > 50: Navigate to > 51: System Settings-> Keyboard-> Special Character Entry > 52: Select "Right Alt" option for the "Alternative Characters Key" Suggestion: Select "Right Alt" option for the "Alternate Characters Key" I guess we should add instructions for a test user to turn the setting back to default, or skip the test if their system does not have such a setting. We also use the `forcePass/forceFail` approach: * The test user may not have a chance to read the instructions all the way through if they are just following them. * If the user accidentally presses a mouse button with the wrong or missing modifier, there is no way to retry. So maybe we should add `logArea` and print theresults there, to allow the test user to make several attempts, and read the instructions till the end. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2334720398 PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2334723940 From dnguyen at openjdk.org Tue Sep 9 22:47:50 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 9 Sep 2025 22:47:50 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 11:45:39 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update with final var and loop increment > > test/jdk/java/awt/List/MouseDraggedOriginatedByScrollBarTest.java line 85: > >> 83: @Override >> 84: public void mouseDragged(MouseEvent me){ >> 85: System.out.println(me.toString()); > > Suggestion: > > System.out.println(me); > > `.toString()` is redundant for `println`. Updated all suggestions. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26636#discussion_r2334988920 From dnguyen at openjdk.org Tue Sep 9 22:47:47 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 9 Sep 2025 22:47:47 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v7] In-Reply-To: References: Message-ID: > When testing jtreg manual tests, some tests were out of date. This PR is an attempt at updating the test and automating it. > > `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. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Remove redundant toString and volatile. Add EDT. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26636/files - new: https://git.openjdk.org/jdk/pull/26636/files/54eb11d4..e1072c0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26636&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26636&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 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 serb at openjdk.org Wed Sep 10 00:19:11 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 Sep 2025 00:19:11 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 23:41:57 GMT, Damon Nguyen wrote: >> Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Add one missing source of default_delay value src/java.desktop/share/classes/java/awt/Robot.java line 129: > 127: private DirectColorModel screenCapCM = null; > 128: > 129: /** many new lines still longer than 80 chars. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2335144334 From serb at openjdk.org Wed Sep 10 00:26:16 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 10 Sep 2025 00:26:16 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 23:41:57 GMT, Damon Nguyen wrote: >> Some useful methods (click, glide, waitForIdle, type) in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using these ExtendedRobot methods will be handled separately. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Add one missing source of default_delay value src/java.desktop/share/classes/java/awt/Robot.java line 849: > 847: public synchronized void waitForIdle(int delayValue) { > 848: waitForIdle(); > 849: delay(delayValue); think we should recheck whether new methods like this one need to be synchronized. Some time ago, the synchronized keyword was removed from the delay method because synchronization could cause the delay to last longer than intended and unnecessarily block other methods. In this case, waitForIdle() might be in a synchronized block (but the method itself is already synchronized), but do we really want to call delay() while holding the lock? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2335152014 From psadhukhan at openjdk.org Wed Sep 10 02:11:48 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 02:11:48 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v3] In-Reply-To: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: > Test used to fail earlier with above message. > Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Remove old files - Rename tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27136/files - new: https://git.openjdk.org/jdk/pull/27136/files/8c5cb819..25d8673f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27136&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27136&range=01-02 Stats: 148 lines in 3 files changed: 73 ins; 73 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27136.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27136/head:pull/27136 PR: https://git.openjdk.org/jdk/pull/27136 From psadhukhan at openjdk.org Wed Sep 10 02:11:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 02:11:50 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v2] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Tue, 9 Sep 2025 18:40:31 GMT, Phil Race wrote: >> test/jdk/java/awt/Focus/FrameInitialFocusTest/FrameInitialFocusTest.java line 66: >> >>> 64: Util.waitForIdle(robot); >>> 65: if (!button.hasFocus()) { >>> 66: throw new RuntimeException("Appletviewer doesn't set default focus correctly."); >> >> AppletViewer => Frame ? > > The frame isn't setting the focus. "Focus not set on button" might be better , but I do agree the word "Appletviewer" needs to be gone ! > > And I was suggesting to just make the test name "IntitialFocusTest" > I thought about changing it to Frame IntitialFocusTest, but it isn't the Frame we expect to get focus. > It's the button. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27136#discussion_r2335301390 From psadhukhan at openjdk.org Wed Sep 10 02:28:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 02:28:04 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 20:41:06 GMT, Alexander Zvegintsev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarify instruction > > test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 52: > >> 50: Navigate to >> 51: System Settings-> Keyboard-> Special Character Entry >> 52: Select "Right Alt" option for the "Alternative Characters Key" > > Suggestion: > > Select "Right Alt" option for the "Alternate Characters Key" > > > I guess we should add instructions for a test user to turn the setting back to default, or skip the test if their system does not have such a setting. > > We also use the `forcePass/forceFail` approach: > * The test user may not have a chance to read the instructions all the way through if they are just following them. > * If the user accidentally presses a mouse button with the wrong or missing modifier, there is no way to retry. > > So maybe we should add `logArea` and print theresults there, to allow the test user to make several attempts, and read the instructions till the end. Usually user should read the instructions till the end and then only attempt the test, which is true for all the manual tests but I got the point. I have added logArea and let user press Pass/Fail depending on the result printed there.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2335318761 From psadhukhan at openjdk.org Wed Sep 10 02:28:00 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 02:28:00 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v3] In-Reply-To: References: Message-ID: > Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". > > Modified the test to use PFJ and also clarified the instruction for Windows and Linux 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/27162/files - new: https://git.openjdk.org/jdk/pull/27162/files/87957dbb..4ae6f962 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27162&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27162&range=01-02 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27162/head:pull/27162 PR: https://git.openjdk.org/jdk/pull/27162 From psadhukhan at openjdk.org Wed Sep 10 03:16:15 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 03:16:15 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components In-Reply-To: References: Message-ID: <4H8PvgBBE-_rc3N76pBQyEuJeAJirlM1SY180JriuRY=.4d827509-7b15-4fc9-a57c-70c83959a47b@github.com> On Tue, 9 Sep 2025 17:45:10 GMT, Sergey Bylokhov wrote: >> Test was failing due to lack of time between initializing graphics components and test start. >> Added robot delay and execution under EDT. >> >> Several iterations of test is passing so deproblemlisting, CI job link in JBS > > test/jdk/java/awt/Focus/InactiveFocusRace.java line 109: > >> 107: } >> 108: }); >> 109: inactiveFrame.setVisible(true); > > The previous version used a Semaphore to wait until the frame became active or the button received focus, but it didn?t check the second inactive frame. > I think what we should do is first show the "inactive" frame using the same Semaphore. Then, once it becomes visible, we should show another "active" frame. > This will ensure that the frame we intend to click below remains inactive/unfocused. I didn't get the "previous version"..I just added a delay between the UI creation and test start. Earlier also, init is called to do UI creation and then start is immediately called which sets inactiveFrame.setVisible(true); activeFrame.setVisible(true); All the semaphore logic is still the same after that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27156#discussion_r2335404741 From psadhukhan at openjdk.org Wed Sep 10 03:58:09 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 03:58:09 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components In-Reply-To: <4H8PvgBBE-_rc3N76pBQyEuJeAJirlM1SY180JriuRY=.4d827509-7b15-4fc9-a57c-70c83959a47b@github.com> References: <4H8PvgBBE-_rc3N76pBQyEuJeAJirlM1SY180JriuRY=.4d827509-7b15-4fc9-a57c-70c83959a47b@github.com> Message-ID: On Wed, 10 Sep 2025 03:13:53 GMT, Prasanta Sadhukhan wrote: >> test/jdk/java/awt/Focus/InactiveFocusRace.java line 109: >> >>> 107: } >>> 108: }); >>> 109: inactiveFrame.setVisible(true); >> >> The previous version used a Semaphore to wait until the frame became active or the button received focus, but it didn?t check the second inactive frame. >> I think what we should do is first show the "inactive" frame using the same Semaphore. Then, once it becomes visible, we should show another "active" frame. >> This will ensure that the frame we intend to click below remains inactive/unfocused. > > I didn't get the "previous version"..I just added a delay between the UI creation and test start. > Earlier also, init is called to do UI creation and then start is immediately called which sets > > inactiveFrame.setVisible(true); > activeFrame.setVisible(true); > > All the semaphore logic is still the same after that Test does - renders inactiveFrame - renders activeFrame - wait for active frame to be active - press on second button in inactive frame - wait for second button should be focus owner - Check Button2 should be the focus owner I think the current test is also doing the same even now.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27156#discussion_r2335482274 From psadhukhan at openjdk.org Wed Sep 10 04:21:22 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 04:21:22 GMT Subject: RFR: 8015444: closed/java/awt/Focus/KeyStrokeTest/KeyStrokeTest.html sometimes fails Message-ID: <1OVUdkv1qX8WudTbNhfPDyWkCeVq8PP8SxBZuv0wzjU=.5ef89380-5177-4aa6-9ce7-b1bf10ce6260@github.com> Although the test doesn't fail in recent run, test is updated to use CountDownLatch with proper delay and frame being made to render to screen centre. Several iterations of the test is ok, test job in JBS ------------- Commit messages: - 8015444: closed/java/awt/Focus/KeyStrokeTest/KeyStrokeTest.html sometimes fails Changes: https://git.openjdk.org/jdk/pull/27182/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27182&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8015444 Stats: 70 lines in 1 file changed: 32 ins; 29 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27182.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27182/head:pull/27182 PR: https://git.openjdk.org/jdk/pull/27182 From duke at openjdk.org Wed Sep 10 05:50:11 2025 From: duke at openjdk.org (duke) Date: Wed, 10 Sep 2025 05:50:11 GMT Subject: RFR: 8366764: Deproblemlist java/awt/ScrollPane/ScrollPositionTest.java In-Reply-To: <_MYLhZbG8CeqFNFgkBGDwAEwap4499uL4Theq9duL9k=.9267f267-f6e7-45ff-a533-2cc81489eb86@github.com> References: <_MYLhZbG8CeqFNFgkBGDwAEwap4499uL4Theq9duL9k=.9267f267-f6e7-45ff-a533-2cc81489eb86@github.com> Message-ID: On Fri, 5 Sep 2025 05:59:21 GMT, Disha Morye wrote: > The test is open sourced and is passing on linux. Hence, it can be removed from the Problem List. @disha-morye Your change (at version 9f697c8b1ced41c256bd33f52bdcb2cede2adbf9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27111#issuecomment-3273404554 From duke at openjdk.org Wed Sep 10 06:19:23 2025 From: duke at openjdk.org (Disha Morye) Date: Wed, 10 Sep 2025 06:19:23 GMT Subject: Integrated: 8366764: Deproblemlist java/awt/ScrollPane/ScrollPositionTest.java In-Reply-To: <_MYLhZbG8CeqFNFgkBGDwAEwap4499uL4Theq9duL9k=.9267f267-f6e7-45ff-a533-2cc81489eb86@github.com> References: <_MYLhZbG8CeqFNFgkBGDwAEwap4499uL4Theq9duL9k=.9267f267-f6e7-45ff-a533-2cc81489eb86@github.com> Message-ID: On Fri, 5 Sep 2025 05:59:21 GMT, Disha Morye wrote: > The test is open sourced and is passing on linux. Hence, it can be removed from the Problem List. This pull request has now been integrated. Changeset: 2705e880 Author: Disha Committer: Manukumar V S URL: https://git.openjdk.org/jdk/commit/2705e880b64825044e67487f01263121780d8f7a Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8366764: Deproblemlist java/awt/ScrollPane/ScrollPositionTest.java Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/27111 From psadhukhan at openjdk.org Wed Sep 10 06:53:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 06:53:52 GMT Subject: RFR: 8024419: Can not find the specified directory in the frame. Message-ID: <11QOOGkRuokjDJ4515zBPdeRv-X77C1m5Oqy81X_Qrc=.2cd308e0-f1ff-46b6-bf10-4f090c595a51@github.com> Test tests navigation on virtual file created on Virtual File System which is not supported in macos so restricting it for osx run. ------------- Commit messages: - 8024419: Can not find the specified directory in the frame. Changes: https://git.openjdk.org/jdk/pull/27185/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8024419 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27185/head:pull/27185 PR: https://git.openjdk.org/jdk/pull/27185 From azvegint at openjdk.org Wed Sep 10 08:08:10 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 Sep 2025 08:08:10 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:25:00 GMT, Prasanta Sadhukhan wrote: >> test/jdk/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java line 52: >> >>> 50: Navigate to >>> 51: System Settings-> Keyboard-> Special Character Entry >>> 52: Select "Right Alt" option for the "Alternative Characters Key" >> >> Suggestion: >> >> Select "Right Alt" option for the "Alternate Characters Key" >> >> >> I guess we should add instructions for a test user to turn the setting back to default, or skip the test if their system does not have such a setting. >> >> We also use the `forcePass/forceFail` approach: >> * The test user may not have a chance to read the instructions all the way through if they are just following them. >> * If the user accidentally presses a mouse button with the wrong or missing modifier, there is no way to retry. >> >> So maybe we should add `logArea` and print theresults there, to allow the test user to make several attempts, and read the instructions till the end. > > Usually user should read the instructions till the end and then only attempt the test, which is true for all the manual tests > but I got the point. > I have added logArea and let user press Pass/Fail depending on the result printed there.. What do you think about the following? > I guess we should add instructions for a test user to turn the setting back to default, or skip the test if their system does not have such a setting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2335924372 From psadhukhan at openjdk.org Wed Sep 10 08:20:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 08:20:28 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v4] In-Reply-To: References: Message-ID: > Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". > > Modified the test to use PFJ and also clarified the instruction for Windows and Linux Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: User instruction added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27162/files - new: https://git.openjdk.org/jdk/pull/27162/files/4ae6f962..96373680 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27162&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27162&range=02-03 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27162/head:pull/27162 PR: https://git.openjdk.org/jdk/pull/27162 From psadhukhan at openjdk.org Wed Sep 10 08:20:31 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 08:20:31 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:05:31 GMT, Alexander Zvegintsev wrote: >> Usually user should read the instructions till the end and then only attempt the test, which is true for all the manual tests >> but I got the point. >> I have added logArea and let user press Pass/Fail depending on the result printed there.. > > What do you think about the following? > >> I guess we should add instructions for a test user to turn the setting back to default, or skip the test if their system does not have such a setting. Usually it's implicit to change the setting back to original but I have added the instructions just in case.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27162#discussion_r2335952449 From dgredler at openjdk.org Wed Sep 10 09:33:21 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Wed, 10 Sep 2025 09:33:21 GMT Subject: RFR: 4138921: TextLayout handling of empty strings [v2] In-Reply-To: References: <09HFw_agwr0rcRL2HbLl0pggHvEKhTf69kSBseau6N8=.9bdd7f3d-4c51-44aa-af52-4dfa95663f4d@github.com> Message-ID: On Wed, 3 Sep 2025 20:11:24 GMT, Daniel Gredler wrote: >> `TextLayout` should deal more gracefully with zero length strings. Currently the exception listed below is the one that is thrown. >> >> `new TextLayout("", f, new FontRenderContext(null, false, false));` >> >>> Exception in thread "main" java.lang.IllegalArgumentException: Zero length >>> string passed to TextLayout constructor. >>> at java.lang.Throwable.(Compiled Code) >>> at java.lang.Exception.(Compiled Code) >>> at java.lang.RuntimeException.(Compiled Code) >>> at java.lang.IllegalArgumentException.(Compiled Code) >>> at java.awt.font.TextLayout.(Compiled Code) >>> at test.main(Compiled Code) >> >> **REVIEWER NOTE:** Please check the empty-string `TextLayout` behavior documented in `TextLayoutConstructorTest` carefully; a badly-behaving empty `TextLayout` is probably worse than a `TextLayout` which doesn't allow empty strings... > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary call to text.first() @mrserb I've removed the unnecessary call to `text.first()`. Is there anything else that caught your eye, or are you comfortable marking as reviewed? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26947#issuecomment-3274120060 From konstantin.kletschke at inside-m2m.de Wed Sep 10 09:54:10 2025 From: konstantin.kletschke at inside-m2m.de (Konstantin Kletschke) Date: Wed, 10 Sep 2025 11:54:10 +0200 Subject: Java crashes using musl-1.2.5 Message-ID: Hello, I am used to crosscompile openjdk for cortex-a[7|8|9] manually or using buildroot framework without severe Problems. ARM EABIhf 32Bit. However recently I got in contact with a customer's rootfs using musl-1.2.5 instead of musl-1.2.4 which I was used to and had no problems with. Severe debugging resulted in the crash whenever musl-1.2.5 was used in the target (regardeless what musl version was used to crosscompile and regardeless with java I tried, correto-24, openjdk-21, openjdk-24). I tested with a helloworld downloaded from github somewhere. "java -jar helloworld.jar" crashes. Unzippping the jar and using "java -cp . HelloWorld" works! Crashes looks something like those: # SIGSEGV (0xb) at pc=0x7693e018, pid=8026, tid=8027 # # JRE version: OpenJDK Runtime Environment (21.0+21) (build 21+21) # Java VM: OpenJDK Server VM (21+21, mixed mode, serial gc, linux-arm) # Problematic frame: # V [libjvm.so+0x61e018] FATAL ERROR in native method: Null object passed to JNI at sun.nio.fs.UnixNativeDispatcher.stat0(java.base at 21/Native Method) at sun.nio.fs.UnixNativeDispatcher.stat(java.base at 21/Unknown Source) at sun.nio.fs.UnixFileAttributes.get(java.base at 21/Unknown Source) at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(java.base at 21/Unknown Source) at sun.nio.fs.UnixFileSystemProvider.readAttributes(java.base at 21/Unknown Source) at sun.nio.fs.LinuxFileSystemProvider.readAttributes(java.base at 21/Unknown Source) at java.nio.file.Files.readAttributes(java.base at 21/Unknown Source) at java.util.zip.ZipFile$Source.get(java.base at 21/Unknown Source) at java.util.zip.ZipFile$CleanableResource.(java.base at 21/Unknown Source) at java.util.zip.ZipFile.(java.base at 21/Unknown Source) at java.util.zip.ZipFile.(java.base at 21/Unknown Source) at java.util.jar.JarFile.(java.base at 21/Unknown Source) at java.util.jar.JarFile.(java.base at 21/Unknown Source) at java.util.jar.JarFile.(java.base at 21/Unknown Source) at sun.launcher.LauncherHelper.getMainClassFromJar(java.base at 21/Unknown Source) at sun.launcher.LauncherHelper.loadMainClass(java.base at 21/Unknown Source) at sun.launcher.LauncherHelper.checkAndLoadMain(java.base at 21/Unknown Source) Aborted With 1.2.4 everything works fine. Farther debugging revealed that following fix in Java allowed to run it with 1.2.5: Index: openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c =================================================================== --- openjdk-21.0.9+6.orig/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c +++ openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c @@ -430,7 +430,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_ini capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; #endif #if defined(__linux__) - my_statx_func = (statx_func*) dlsym(RTLD_DEFAULT, "statx"); + my_statx_func = NULL; if (my_statx_func != NULL) { capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; } May be this has something to do with the stat ./. stat64 stuff or so. Should this be investigated to be repaired in musl or should I head to the java guys? Kind Regards Konstantin Kletschke -- INSIDE M2M GmbH Konstantin Kletschke Berenbosteler Stra?e 76 B 30823 Garbsen Telefon: +49 (0) 5137 90950136 Mobil: +49 (0) 151 15256238 Fax: +49 (0) 5137 9095010 konstantin.kletschke at inside-m2m.de http://www.inside-m2m.de Gesch?ftsf?hrung: Michael Emmert, Derek Uhlig HRB: 111204, AG Hannover From rkannathpari at openjdk.org Wed Sep 10 10:13:06 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 10 Sep 2025 10:13:06 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v2] In-Reply-To: References: Message-ID: > Hi Reviewers, > > I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code > > Please 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: Added test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27157/files - new: https://git.openjdk.org/jdk/pull/27157/files/5638737d..fae0e8ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=00-01 Stats: 52 lines in 1 file changed: 52 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27157.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27157/head:pull/27157 PR: https://git.openjdk.org/jdk/pull/27157 From rkannathpari at openjdk.org Wed Sep 10 10:13:07 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 10 Sep 2025 10:13:07 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 17:27:56 GMT, Sergey Bylokhov wrote: >> Hi Reviewers, >> >> I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code >> >> Please review and let me know your suggestions if any. > > Can this change covered by the new test? Thank you @mrserb for the valuable suggestion. I have added a verification test for this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27157#issuecomment-3274259491 From rkannathpari at openjdk.org Wed Sep 10 10:23:18 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 10 Sep 2025 10:23:18 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v3] In-Reply-To: References: Message-ID: > Hi Reviewers, > > I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code > > Please review and let me know your suggestions if any. Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: - Removed extra line - Fixed whitspace error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27157/files - new: https://git.openjdk.org/jdk/pull/27157/files/fae0e8ee..955297b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27157.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27157/head:pull/27157 PR: https://git.openjdk.org/jdk/pull/27157 From rkannathpari at openjdk.org Wed Sep 10 10:39:35 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 10 Sep 2025 10:39:35 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v4] In-Reply-To: References: Message-ID: <1gPGGKMsJZw5BzFLa5Io0AVvnimyprQrChg_iSg58Fo=.2ee7467d-1de1-4500-8baf-b4637c40d571@github.com> > Hi Reviewers, > > I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code > > Please review and let me know your suggestions if any. Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: - Fixed alignment - Fixed whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27157/files - new: https://git.openjdk.org/jdk/pull/27157/files/955297b1..da742883 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27157.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27157/head:pull/27157 PR: https://git.openjdk.org/jdk/pull/27157 From smandalika at openjdk.org Wed Sep 10 11:01:50 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 10 Sep 2025 11:01:50 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v5] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:42:35 GMT, Srinivas Mandalika 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. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > review Feedback: simplified test failure conditions. Removed the passed & eventType variable for test pass/fail assertion. Tweaked to assert test scenario only on based on latch. Removed boiler plate code for mouse Move & Click. I have incorporated the review suggestions. Can anyone provide feedback on these? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26471#issuecomment-3274430749 From smandalika at openjdk.org Wed Sep 10 11:02:48 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Wed, 10 Sep 2025 11:02:48 GMT Subject: RFR: 8068378: [TEST_BUG]The java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java instruction need to update In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:44:30 GMT, Srinivas Mandalika wrote: > Test Name: java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java > Updated the test instructions for better clarity, formatting and removed its entry from the ProblemList.txt. Can someone take a quick look and provide feedback on this simple instruction update MR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27139#issuecomment-3274433779 From rkannathpari at openjdk.org Wed Sep 10 11:09:10 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 10 Sep 2025 11:09:10 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v5] In-Reply-To: References: Message-ID: <8xooH0P5hHEoRogEGA4BOj_yIZ1jxJgPI3KzNST2OGw=.f8da0509-9e9c-47ee-8dd4-d9da66b37640@github.com> > Hi Reviewers, > > I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code > > Please review and let me know your suggestions if any. Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: - Replaced eol char - Replaced eol char ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27157/files - new: https://git.openjdk.org/jdk/pull/27157/files/da742883..6fca8bcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=03-04 Stats: 52 lines in 1 file changed: 0 ins; 0 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/27157.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27157/head:pull/27157 PR: https://git.openjdk.org/jdk/pull/27157 From azvegint at openjdk.org Wed Sep 10 11:20:25 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 10 Sep 2025 11:20:25 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:20:28 GMT, Prasanta Sadhukhan wrote: >> Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". >> >> Modified the test to use PFJ and also clarified the instruction for Windows and Linux > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > User instruction added Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27162#pullrequestreview-3205680456 From kevin.rushforth at oracle.com Wed Sep 10 12:34:21 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Sep 2025 05:34:21 -0700 Subject: Java crashes using musl-1.2.5 In-Reply-To: References: Message-ID: Given where it is crashing, I recommend sending your message to core-libs-dev 'at' openjdk.org instead. This isn't a Java client libs issue. -- Kevin On 9/10/2025 2:54 AM, Konstantin Kletschke wrote: > Hello, > > I am used to crosscompile openjdk for cortex-a[7|8|9] manually or using > buildroot framework without severe Problems. > ARM EABIhf 32Bit. > > However recently I got in contact with a customer's rootfs using > musl-1.2.5 instead of musl-1.2.4 which I was used to and had no problems with. > > Severe debugging resulted in the crash whenever musl-1.2.5 was used in > the target (regardeless what musl version was used to crosscompile and > regardeless with java I tried, correto-24, openjdk-21, openjdk-24). > > I tested with a helloworld downloaded from github somewhere. > "java -jar helloworld.jar" crashes. Unzippping the jar and using > "java -cp . HelloWorld" works! > > Crashes looks something like those: > > # SIGSEGV (0xb) at pc=0x7693e018, pid=8026, tid=8027 > # > # JRE version: OpenJDK Runtime Environment (21.0+21) (build 21+21) > # Java VM: OpenJDK Server VM (21+21, mixed mode, serial gc, linux-arm) > # Problematic frame: > # V [libjvm.so+0x61e018] > > FATAL ERROR in native method: Null object passed to JNI > at sun.nio.fs.UnixNativeDispatcher.stat0(java.base at 21/Native Method) > at sun.nio.fs.UnixNativeDispatcher.stat(java.base at 21/Unknown Source) > at sun.nio.fs.UnixFileAttributes.get(java.base at 21/Unknown Source) > at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(java.base at 21/Unknown Source) > at sun.nio.fs.UnixFileSystemProvider.readAttributes(java.base at 21/Unknown Source) > at sun.nio.fs.LinuxFileSystemProvider.readAttributes(java.base at 21/Unknown Source) > at java.nio.file.Files.readAttributes(java.base at 21/Unknown Source) > at java.util.zip.ZipFile$Source.get(java.base at 21/Unknown Source) > at java.util.zip.ZipFile$CleanableResource.(java.base at 21/Unknown Source) > at java.util.zip.ZipFile.(java.base at 21/Unknown Source) > at java.util.zip.ZipFile.(java.base at 21/Unknown Source) > at java.util.jar.JarFile.(java.base at 21/Unknown Source) > at java.util.jar.JarFile.(java.base at 21/Unknown Source) > at java.util.jar.JarFile.(java.base at 21/Unknown Source) > at sun.launcher.LauncherHelper.getMainClassFromJar(java.base at 21/Unknown Source) > at sun.launcher.LauncherHelper.loadMainClass(java.base at 21/Unknown Source) > at sun.launcher.LauncherHelper.checkAndLoadMain(java.base at 21/Unknown Source) > Aborted > > > With 1.2.4 everything works fine. > > > Farther debugging revealed that following fix in Java allowed to run it > with 1.2.5: > > Index: openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > =================================================================== > --- openjdk-21.0.9+6.orig/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > +++ openjdk-21.0.9+6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > @@ -430,7 +430,7 @@ Java_sun_nio_fs_UnixNativeDispatcher_ini > capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; > #endif > #if defined(__linux__) > - my_statx_func = (statx_func*) dlsym(RTLD_DEFAULT, "statx"); > + my_statx_func = NULL; > if (my_statx_func != NULL) { > capabilities |= sun_nio_fs_UnixNativeDispatcher_SUPPORTS_BIRTHTIME; > } > > > > May be this has something to do with the stat ./. stat64 stuff or so. > Should this be investigated to be repaired in musl or should I head to > the java guys? > > > Kind Regards > Konstantin Kletschke > From konstantin.kletschke at inside-m2m.de Wed Sep 10 12:51:01 2025 From: konstantin.kletschke at inside-m2m.de (Konstantin Kletschke) Date: Wed, 10 Sep 2025 14:51:01 +0200 Subject: Java crashes using musl-1.2.5 In-Reply-To: References: Message-ID: On Wed, Sep 10, 2025 at 05:34:21AM -0700, Kevin Rushforth wrote: > Given where it is crashing, I recommend sending your message to > core-libs-dev 'at' openjdk.org instead. This isn't a Java client libs issue. Thanks for the hint Kevin, I will do accordingly. Regards From myankelevich at openjdk.org Wed Sep 10 13:53:19 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Wed, 10 Sep 2025 13:53:19 GMT Subject: RFR: 8024419: Can not find the specified directory in the frame. In-Reply-To: <11QOOGkRuokjDJ4515zBPdeRv-X77C1m5Oqy81X_Qrc=.2cd308e0-f1ff-46b6-bf10-4f090c595a51@github.com> References: <11QOOGkRuokjDJ4515zBPdeRv-X77C1m5Oqy81X_Qrc=.2cd308e0-f1ff-46b6-bf10-4f090c595a51@github.com> Message-ID: On Wed, 10 Sep 2025 06:47:38 GMT, Prasanta Sadhukhan wrote: > Test tests navigation on virtual file created on Virtual File System which is not supported in macos so restricting it for osx run. test/jdk/javax/swing/JFileChooser/6698013/bug6698013.java line 29: > 27: import javax.swing.filechooser.FileSystemView; > 28: > 29: /* Nit: copyright year test/jdk/javax/swing/JFileChooser/6698013/bug6698013.java line 32: > 30: * @test > 31: * @bug 6698013 > 32: * @requires (os.family != "mac") Do you think explaining the reason behind the blocking of the macOS in `@summary` would be helpful? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27185#discussion_r2336831024 PR Review Comment: https://git.openjdk.org/jdk/pull/27185#discussion_r2336838406 From aivanov at openjdk.org Wed Sep 10 13:55:49 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Sep 2025 13:55:49 GMT Subject: RFR: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:20:28 GMT, Prasanta Sadhukhan wrote: >> Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". >> >> Modified the test to use PFJ and also clarified the instruction for Windows and Linux > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > User instruction added Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27162#pullrequestreview-3206279349 From aivanov at openjdk.org Wed Sep 10 15:02:52 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Sep 2025 15:02:52 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v11] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:13:09 GMT, ScientificWare 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 = """ >> >> >> >>

>> - 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. > - ... and 17 more: https://git.openjdk.org/jdk/compare/bea2b029...25965200 Looks good to me, except for two minor comments. I've run all client tests, all's green. test/jdk/javax/swing/text/html/bug8314731.java line 106: > 104: for (Component c : container.getComponents()) { > 105: if (c instanceof JButton butt) { > 106: return "Logo".equals(butt.getText()); Suggestion: if (c instanceof JButton button) { return "Logo".equals(button.getText()); Let's spell the word fully to avoid unwanted connotations; or use `btn`. test/jdk/javax/swing/text/html/bug8314731.java line 113: > 111: return false; > 112: } > 113: } And now the blank line at the end of the file is missing, like @TejeshR13 [commented previously](https://github.com/openjdk/jdk/pull/15319#discussion_r2292964065). Usually, files should end with a new line character. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-3206564981 PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-3275364988 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2337041323 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r2337048716 From duke at openjdk.org Wed Sep 10 15:19:22 2025 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 10 Sep 2025 15:19:22 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v5] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:42:35 GMT, Srinivas Mandalika 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. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > review Feedback: simplified test failure conditions. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/26471#issuecomment-3275430300 From weijun at openjdk.org Wed Sep 10 15:53:07 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 15:53:07 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep Message-ID: Allow password hiding even if there is no `System.console`. A manual test is included. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/27196/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354469 Stats: 278 lines in 3 files changed: 247 ins; 4 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From weijun at openjdk.org Wed Sep 10 15:53:08 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 15:53:08 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:43:52 GMT, Weijun Wang wrote: > Allow password hiding even if there is no `System.console`. A manual test is included. Adding `client` label, please confirm my change of `PassFailJFrame.java` is OK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27196#issuecomment-3275539946 From psadhukhan at openjdk.org Wed Sep 10 16:04:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 10 Sep 2025 16:04:30 GMT Subject: Integrated: 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button In-Reply-To: References: Message-ID: <_eWSCAgZx6HqNpl_7003tHPT9nlrIUtR3TW6a50X-Tc=.13561213-108d-4c63-b9f4-03be61b2f89b@github.com> On Tue, 9 Sep 2025 06:55:27 GMT, Prasanta Sadhukhan wrote: > Test was made to fail due to presence of only "Fail" button instead of both "Pass" and "Fail". > > Modified the test to use PFJ and also clarified the instruction for Windows and Linux This pull request has now been integrated. Changeset: 34c3ac03 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/34c3ac0316dbd29ae670db51bd9230a1e77382d9 Stats: 244 lines in 2 files changed: 31 ins; 200 del; 13 mod 8162380: [TEST_BUG] MouseEvent/.../AltGraphModifierTest.java has only "Fail" button Reviewed-by: azvegint, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/27162 From weijun at openjdk.org Wed Sep 10 16:23:25 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 16:23:25 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML Message-ID: Add HTML link processing ability in instructions. For example: PassFailJFrame.builder() .instructions(htmlWithLinks) .addHyperlinkListener(e -> { if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { performActionOnLink(e.getDescription()); } }) ------------- Commit messages: - the code change Changes: https://git.openjdk.org/jdk/pull/27197/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27197&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367348 Stats: 23 lines in 1 file changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27197/head:pull/27197 PR: https://git.openjdk.org/jdk/pull/27197 From naoto at openjdk.org Wed Sep 10 16:31:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 10 Sep 2025 16:31:54 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:43:52 GMT, Weijun Wang wrote: > Allow password hiding even if there is no `System.console`. A manual test is included. src/java.base/share/classes/sun/security/util/Password.java line 158: > 156: c2 = null; > 157: charset = null; > 158: } Can be simplified as: c2 = JdkConsoleImpl.passwordConsole().orElse(null); charset = (c2 != null) ? c2.charset() : null; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2337290982 From aivanov at openjdk.org Wed Sep 10 16:37:07 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Sep 2025 16:37:07 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:17:58 GMT, Weijun Wang wrote: > Add HTML link processing ability in instructions. For example: > > PassFailJFrame.builder() > .instructions(htmlWithLinks) > .addHyperlinkListener(e -> { > if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { > performActionOnLink(e.getDescription()); > } > }) > > I also take this chance to make a CSS change for fix-width text to show a light-gray background color. Changes requested by aivanov (Reviewer). test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 657: > 655: text.setBorder(createTextBorder()); > 656: text.setCaretPosition(0); > 657: text.getCaret().setVisible(false); Hiding the caret could be undesirable: if a tester wants to select text using keyboard, there's no way to see where the caret is. The caret used to be hidden for read-only text components, now it's displayed by default but it doesn't blink, see [JDK-8299077](https://bugs.openjdk.org/browse/JDK-8299077). test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1410: > 1408: private int columns; > 1409: private boolean screenCapture; > 1410: HyperlinkListener hyperlinkListener; Suggestion: private boolean screenCapture; private HyperlinkListener hyperlinkListener; Declare it `private` for consistency. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1492: > 1490: > 1491: /** > 1492: * Set the HyperlinkListener of links inside the instructions pane. Suggestion: * Sets a {@link HyperlinkListener} for navigating links inside the instructions pane. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1497: > 1495: * @return this builder > 1496: */ > 1497: public Builder addHyperlinkListener(HyperlinkListener hyperlinkListener) { Suggestion: public Builder hyperlinkListener(HyperlinkListener hyperlinkListener) { For consistency with other methods. ------------- PR Review: https://git.openjdk.org/jdk/pull/27197#pullrequestreview-3206921872 PR Review Comment: https://git.openjdk.org/jdk/pull/27197#discussion_r2337288137 PR Review Comment: https://git.openjdk.org/jdk/pull/27197#discussion_r2337295581 PR Review Comment: https://git.openjdk.org/jdk/pull/27197#discussion_r2337295086 PR Review Comment: https://git.openjdk.org/jdk/pull/27197#discussion_r2337290962 From weijun at openjdk.org Wed Sep 10 16:51:39 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 16:51:39 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML [v2] In-Reply-To: References: Message-ID: <8DZ6eem5adkYmwoA3bk9EaGOTb-4fuYRqW6rxZNF4Ms=.577ca6d4-984d-4cfe-86d0-2e9b7db575cb@github.com> On Wed, 10 Sep 2025 16:28:24 GMT, Alexey Ivanov wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> show the caret > > test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 657: > >> 655: text.setBorder(createTextBorder()); >> 656: text.setCaretPosition(0); >> 657: text.getCaret().setVisible(false); > > Hiding the caret could be undesirable: if a tester wants to select text using keyboard, there's no way to see where the caret is. > > The caret used to be hidden for read-only text components, now it's displayed by default but it doesn't blink, see [JDK-8299077](https://bugs.openjdk.org/browse/JDK-8299077). Sure, I'll show it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27197#discussion_r2337330550 From weijun at openjdk.org Wed Sep 10 16:51:37 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 16:51:37 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML [v2] In-Reply-To: References: Message-ID: > Add HTML link processing ability in instructions. For example: > > PassFailJFrame.builder() > .instructions(htmlWithLinks) > .addHyperlinkListener(e -> { > if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { > performActionOnLink(e.getDescription()); > } > }) > > I also take this chance to make a CSS change for fix-width text to show a light-gray background color. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: show the caret ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27197/files - new: https://git.openjdk.org/jdk/pull/27197/files/07dc4502..c8fd7845 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27197&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27197&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27197/head:pull/27197 PR: https://git.openjdk.org/jdk/pull/27197 From weijun at openjdk.org Wed Sep 10 16:57:20 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 16:57:20 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML [v3] In-Reply-To: References: Message-ID: > Add HTML link processing ability in instructions. For example: > > PassFailJFrame.builder() > .instructions(htmlWithLinks) > .addHyperlinkListener(e -> { > if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { > performActionOnLink(e.getDescription()); > } > }) > > I also take this chance to make a CSS change for fix-width text to show a light-gray background color. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: the link ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27197/files - new: https://git.openjdk.org/jdk/pull/27197/files/c8fd7845..408307a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27197&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27197&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27197/head:pull/27197 PR: https://git.openjdk.org/jdk/pull/27197 From aivanov at openjdk.org Wed Sep 10 17:04:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Sep 2025 17:04:47 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:57:20 GMT, Weijun Wang wrote: >> Add HTML link processing ability in instructions. For example: >> >> PassFailJFrame.builder() >> .instructions(htmlWithLinks) >> .addHyperlinkListener(e -> { >> if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { >> performActionOnLink(e.getDescription()); >> } >> }) >> >> I also take this chance to make a CSS change for fix-width text to show a light-gray background color. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > the link Changes requested by aivanov (Reviewer). test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 103: > 101: * instructions are displayed as HTML, as supported by Swing, which > 102: * provides richer formatting options. {@link Builder#hyperlinkListener} > 103: * can be called to add a listener to hyperlinks inside the HTML. Suggestion: * provides richer formatting options. To handle navigating links in the * instructions, call {@link Builder#hyperlinkListener} to install a listener. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1491: > 1489: > 1490: /** > 1491: * Sets a {@link HyperlinkListener} for navigating links inside the instructions pane. Suggestion: * Sets a {@link HyperlinkListener} for navigating links inside * the instructions pane. We usually keep the lines shorter than 80 columns. ------------- PR Review: https://git.openjdk.org/jdk/pull/27197#pullrequestreview-3207014958 PR Review Comment: https://git.openjdk.org/jdk/pull/27197#discussion_r2337362992 PR Review Comment: https://git.openjdk.org/jdk/pull/27197#discussion_r2337351149 From weijun at openjdk.org Wed Sep 10 17:15:47 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 17:15:47 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML [v4] In-Reply-To: References: Message-ID: > Add HTML link processing ability in instructions. For example: > > PassFailJFrame.builder() > .instructions(htmlWithLinks) > .addHyperlinkListener(e -> { > if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { > performActionOnLink(e.getDescription()); > } > }) > > I also take this chance to make a CSS change for fix-width text to show a light-gray background color. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: javadoc refine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27197/files - new: https://git.openjdk.org/jdk/pull/27197/files/408307a2..c71d110f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27197&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27197&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27197/head:pull/27197 PR: https://git.openjdk.org/jdk/pull/27197 From aivanov at openjdk.org Wed Sep 10 17:24:57 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 10 Sep 2025 17:24:57 GMT Subject: RFR: 8367348: Enhance PassFailJFrame to support links in HTML [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 17:15:47 GMT, Weijun Wang wrote: >> Add HTML link processing ability in instructions. For example: >> >> PassFailJFrame.builder() >> .instructions(htmlWithLinks) >> .addHyperlinkListener(e -> { >> if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { >> performActionOnLink(e.getDescription()); >> } >> }) >> >> I also take this chance to make a CSS change for fix-width text to show a light-gray background color. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > javadoc refine Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27197#pullrequestreview-3207127290 From weijun at openjdk.org Wed Sep 10 17:29:00 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 17:29:00 GMT Subject: Integrated: 8367348: Enhance PassFailJFrame to support links in HTML In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:17:58 GMT, Weijun Wang wrote: > Add HTML link processing ability in instructions. For example: > > PassFailJFrame.builder() > .instructions(htmlWithLinks) > .addHyperlinkListener(e -> { > if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) { > performActionOnLink(e.getDescription()); > } > }) > > I also take this chance to make a CSS change for fix-width text to show a light-gray background color. This pull request has now been integrated. Changeset: 7a3025e3 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/7a3025e3d7d33ed02db34c1485aa3c7b44b2d8ee Stats: 23 lines in 1 file changed: 21 ins; 0 del; 2 mod 8367348: Enhance PassFailJFrame to support links in HTML Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/27197 From weijun at openjdk.org Wed Sep 10 17:30:13 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 17:30:13 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v2] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: decouple PassFailJFrame.java change; simplify code flow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/9272e28f..3a5f9687 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=00-01 Stats: 32 lines in 3 files changed: 0 ins; 27 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From weijun at openjdk.org Wed Sep 10 17:33:05 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 17:33:05 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8354469 - decouple PassFailJFrame.java change; simplify code flow - the fix ------------- Changes: https://git.openjdk.org/jdk/pull/27196/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=02 Stats: 250 lines in 2 files changed: 221 ins; 5 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From prr at openjdk.org Wed Sep 10 18:27:59 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 10 Sep 2025 18:27:59 GMT Subject: RFR: 8361530: Test javax/swing/GraphicsConfigNotifier/StalePreferredSize.java timed out Message-ID: This test takes an insane amount of time on some systems. I just saw it take 1,042 seconds to PASS on an x64 Mac. It doesn't help that there are 3 @run commands. But also it loops over L&Fs, fonts, etc, testing many component types and created 4.600 top level frames and 2,300 popups I don't think we need all 3 run commands and I think testing with one font is fine for this. That would bring that successful run down to just under 3 minutes. And since each test is doing 1/3 of the work a slight reduction in timeout : 600 -> 420, seems appropriate. ------------- Commit messages: - 8361530 - StalePreferredSize.java Changes: https://git.openjdk.org/jdk/pull/27200/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27200&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361530 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27200.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27200/head:pull/27200 PR: https://git.openjdk.org/jdk/pull/27200 From fandreuzzi at openjdk.org Wed Sep 10 19:39:43 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 19:39:43 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 17:33:05 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8354469 > - decouple PassFailJFrame.java change; simplify code flow > - the fix src/java.base/share/classes/sun/security/util/Password.java line 167: > 165: if (c1 != null) { > 166: return c1.readPassword(); > 167: } else { The `else` clause is not needed, you could save an indentation level ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2337724730 From weijun at openjdk.org Wed Sep 10 19:58:55 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 10 Sep 2025 19:58:55 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 19:36:54 GMT, Francesco Andreuzzi wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into 8354469 >> - decouple PassFailJFrame.java change; simplify code flow >> - the fix > > src/java.base/share/classes/sun/security/util/Password.java line 167: > >> 165: if (c1 != null) { >> 166: return c1.readPassword(); >> 167: } else { > > The `else` clause is not needed, you could save an indentation level The indentation is not very deep, and I actually like the symmetry between 2 different kind of "consoles". As long as there is no performance gain, I'll keep my style. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2337761565 From jwood at openjdk.org Wed Sep 10 22:39:04 2025 From: jwood at openjdk.org (Jeremy Wood) Date: Wed, 10 Sep 2025 22:39:04 GMT Subject: RFR: 8367376: call setUpdatePending(false) in a finally block Message-ID: Previously: If DesktopProperty#updateAllUIs threw an exception, we would never reset the update-pending property to false. This means any subsequent call to `updateUI()` would not attempt to call `updateAllUIs()` With this change: Subsequent calls to DesktopProperty#updateUI() can still trigger at least one call to updateAllUIs(). ------------- Commit messages: - 8367376: call setUpdatePending(false) in a finally block Changes: https://git.openjdk.org/jdk/pull/27205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27205&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367376 Stats: 162 lines in 2 files changed: 159 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27205/head:pull/27205 PR: https://git.openjdk.org/jdk/pull/27205 From abaya at openjdk.org Wed Sep 10 23:11:38 2025 From: abaya at openjdk.org (Anass Baya) Date: Wed, 10 Sep 2025 23:11:38 GMT Subject: RFR: 8361606 : ConsumeNextMnemonicKeyTypedTest.java fails on Windows: character typed with VK_A: a [v3] In-Reply-To: <_1yXNCrYeLyBJRqWhP2kjkzUVBxWuZ1gTNmnhRGRrjw=.36be8e3b-12c9-41d4-8389-9bba991fe57f@github.com> References: <_1yXNCrYeLyBJRqWhP2kjkzUVBxWuZ1gTNmnhRGRrjw=.36be8e3b-12c9-41d4-8389-9bba991fe57f@github.com> Message-ID: On Mon, 25 Aug 2025 10:43:51 GMT, Anass Baya wrote: >> **Analysis :** >> When the problem occurrs, the key press event related to the mnemonic triggers 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; >> } >> ... > > Anass Baya has updated the pull request incrementally with one additional commit since the last revision: > > add Linux bug ID 8321303 it does not seem like Aqua L&F even touches `menuKeyPressed()` in `BasicPopupMenuUI.java`. Or at least, not that portion. Hello @DamonGuy , I used the same macOS version with the same Look & Feel, and it works fine on my end. Just to clarify, do you mean you can?t even see the 'a' key pressed, or are you referring specifically to the mnemonics for 'i' and 'f'? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/26790#issuecomment-3276800901 From serb at openjdk.org Thu Sep 11 02:37:20 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 11 Sep 2025 02:37:20 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v5] In-Reply-To: <8xooH0P5hHEoRogEGA4BOj_yIZ1jxJgPI3KzNST2OGw=.f8da0509-9e9c-47ee-8dd4-d9da66b37640@github.com> References: <8xooH0P5hHEoRogEGA4BOj_yIZ1jxJgPI3KzNST2OGw=.f8da0509-9e9c-47ee-8dd4-d9da66b37640@github.com> Message-ID: <6Zo4vgvK5pCk4IrIdrJnVz6gO-fNtF0yCrDS-pVJ-9g=.5e5fcf3b-0578-4457-ab77-87166e966a31@github.com> On Wed, 10 Sep 2025 11:09:10 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code >> >> Please review and let me know your suggestions if any. > > Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: > > - Replaced eol char > - Replaced eol char test/jdk/javax/swing/SwingUtilities/8365379/bug8365379.java line 33: > 31: * @bug 8365379 > 32: * @summary Verify LineBorder edges have the same width > 33: * @modules java.desktop/com.sun.java.swing Can we verify it w/o using internals? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27157#discussion_r2338355423 From serb at openjdk.org Thu Sep 11 02:44:14 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 11 Sep 2025 02:44:14 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components In-Reply-To: References: <4H8PvgBBE-_rc3N76pBQyEuJeAJirlM1SY180JriuRY=.4d827509-7b15-4fc9-a57c-70c83959a47b@github.com> Message-ID: On Wed, 10 Sep 2025 03:55:43 GMT, Prasanta Sadhukhan wrote: >> I didn't get the "previous version"..I just added a delay between the UI creation and test start. >> Earlier also, init is called to do UI creation and then start is immediately called which sets >> >> inactiveFrame.setVisible(true); >> activeFrame.setVisible(true); >> >> All the semaphore logic is still the same after that > > Test does > - renders inactiveFrame > - renders activeFrame > - wait for active frame to be active > - press on second button in inactive frame > - wait for second button should be focus owner > - Check Button2 should be the focus owner > > I think the current test is also doing the same even now.. >All the semaphore logic is still the same after that My point is that this logic is wrong. It should first check that the first window has become visible, then the second window, and only after that start the test execution. In this case, no additional changes would be necessary, or am I missing something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27156#discussion_r2338362586 From dnguyen at openjdk.org Thu Sep 11 03:13:13 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 11 Sep 2025 03:13:13 GMT Subject: RFR: 8366149: JNI exception pending in Java_sun_awt_X11GraphicsDevice_pGetBounds of awt_GraphicsEnv.c:1484 [v2] In-Reply-To: <23suWu7T8mP4QAs-wKAHZqW_L0ZrSqEa8ZDw8DE2yTg=.29cfda73-47b4-429a-ac9d-0dfd5cb6d409@github.com> References: <23suWu7T8mP4QAs-wKAHZqW_L0ZrSqEa8ZDw8DE2yTg=.29cfda73-47b4-429a-ac9d-0dfd5cb6d409@github.com> Message-ID: > In the scenario where AWT's UNLOCK API encounters a pendingException, the env pointer throws the pendingException (as seen in `awt.h`). However, in `Java_sun_awt_X11GraphicsDevice_pGetBounds`, after `AWT_UNLOCK`, the bounds var is set. The exception check does not occur until after the bounds is set, so the bounds may be set to an undesired value. This fix adds another exception check to look for this pendingException after `AWT_UNLOCK`. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Change fix to return NULLs instead. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27110/files - new: https://git.openjdk.org/jdk/pull/27110/files/f5e1521b..5b00dc81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27110&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27110&range=00-01 Stats: 10 lines in 1 file changed: 4 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27110/head:pull/27110 PR: https://git.openjdk.org/jdk/pull/27110 From rkannathpari at openjdk.org Thu Sep 11 03:51:52 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 11 Sep 2025 03:51:52 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v6] In-Reply-To: References: Message-ID: <775Ved3ubwdZkh3A3Hqs4AYDe3WhCrPdaMT9qbSQ3Jo=.1e545f99-d89f-4e06-9def-ce7d20ee1bbd@github.com> > Hi Reviewers, > > I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code > > Please 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 summary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27157/files - new: https://git.openjdk.org/jdk/pull/27157/files/6fca8bcd..4d4a2a5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27157&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27157.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27157/head:pull/27157 PR: https://git.openjdk.org/jdk/pull/27157 From rkannathpari at openjdk.org Thu Sep 11 03:58:09 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Thu, 11 Sep 2025 03:58:09 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v5] In-Reply-To: <6Zo4vgvK5pCk4IrIdrJnVz6gO-fNtF0yCrDS-pVJ-9g=.5e5fcf3b-0578-4457-ab77-87166e966a31@github.com> References: <8xooH0P5hHEoRogEGA4BOj_yIZ1jxJgPI3KzNST2OGw=.f8da0509-9e9c-47ee-8dd4-d9da66b37640@github.com> <6Zo4vgvK5pCk4IrIdrJnVz6gO-fNtF0yCrDS-pVJ-9g=.5e5fcf3b-0578-4457-ab77-87166e966a31@github.com> Message-ID: On Thu, 11 Sep 2025 02:34:40 GMT, Sergey Bylokhov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision: >> >> - Replaced eol char >> - Replaced eol char > > test/jdk/javax/swing/SwingUtilities/8365379/bug8365379.java line 33: > >> 31: * @bug 8365379 >> 32: * @summary Verify LineBorder edges have the same width >> 33: * @modules java.desktop/com.sun.java.swing > > Can we verify it w/o using internals? As you are aware existing calculation will go wrong only for non zero X & Y. As far my understanding existing calls passing 0,0 as X,Y. so I did not find any other way w/o using internals. Let me know if you have any suggestions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27157#discussion_r2338449293 From psadhukhan at openjdk.org Thu Sep 11 04:39:42 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Sep 2025 04:39:42 GMT Subject: RFR: 8361530: Test javax/swing/GraphicsConfigNotifier/StalePreferredSize.java timed out In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:20:13 GMT, Phil Race wrote: > This test takes an insane amount of time on some systems. I just saw it take 1,042 seconds to PASS on an x64 Mac. > It doesn't help that there are 3 @run commands. > But also it loops over L&Fs, fonts, etc, testing many component types and created 4.600 top level frames and 2,300 popups > > I don't think we need all 3 run commands and I think testing with one font is fine for this. > > That would bring that successful run down to just under 3 minutes. > And since each test is doing 1/3 of the work a slight reduction in timeout : 600 -> 420, seems appropriate. It seems bold and italic testing is removed.. I did try with only default and 2.25 uiScale factor when I was working on it but that also timed out after some iterations (say 6th iteration of 20) in that particular 14.7 host, so maybe we need to keep an eye on that host still even after this modification ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27200#pullrequestreview-3208683590 From duke at openjdk.org Thu Sep 11 05:00:38 2025 From: duke at openjdk.org (ScientificWare) Date: Thu, 11 Sep 2025 05:00:38 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v12] In-Reply-To: References: Message-ID: > 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 = """ > > > >

> >

> References: Message-ID: On Thu, 11 Sep 2025 04:37:19 GMT, Prasanta Sadhukhan wrote: > It seems bold and italic testing is removed.. Yes. That is the idea. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27200#issuecomment-3277584561 From prr at openjdk.org Thu Sep 11 05:01:32 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 11 Sep 2025 05:01:32 GMT Subject: Integrated: 8361530: Test javax/swing/GraphicsConfigNotifier/StalePreferredSize.java timed out In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:20:13 GMT, Phil Race wrote: > This test takes an insane amount of time on some systems. I just saw it take 1,042 seconds to PASS on an x64 Mac. > It doesn't help that there are 3 @run commands. > But also it loops over L&Fs, fonts, etc, testing many component types and created 4.600 top level frames and 2,300 popups > > I don't think we need all 3 run commands and I think testing with one font is fine for this. > > That would bring that successful run down to just under 3 minutes. > And since each test is doing 1/3 of the work a slight reduction in timeout : 600 -> 420, seems appropriate. This pull request has now been integrated. Changeset: eb9e0459 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/eb9e04598db7a70347ada005035644012026f902 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod 8361530: Test javax/swing/GraphicsConfigNotifier/StalePreferredSize.java timed out Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/27200 From psadhukhan at openjdk.org Thu Sep 11 05:15:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Sep 2025 05:15:47 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components [v2] In-Reply-To: References: Message-ID: <9rIXqCPFUFJz94nlGFHQEFgphxXHjutEYOKjuILE-k0=.13e54fb9-4e89-4ce8-b5b1-434fa0fbee1e@github.com> > Test was failing due to lack of time between initializing graphics components and test start. > Added robot delay and execution under EDT. > > Several iterations of test is passing so deproblemlisting, CI job link in JBS Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Wait for inactive frame to be visible before active frame ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27156/files - new: https://git.openjdk.org/jdk/pull/27156/files/cf60d90a..d7a048de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27156&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27156&range=00-01 Stats: 24 lines in 1 file changed: 23 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27156.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27156/head:pull/27156 PR: https://git.openjdk.org/jdk/pull/27156 From psadhukhan at openjdk.org Thu Sep 11 05:15:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Sep 2025 05:15:49 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components [v2] In-Reply-To: References: <4H8PvgBBE-_rc3N76pBQyEuJeAJirlM1SY180JriuRY=.4d827509-7b15-4fc9-a57c-70c83959a47b@github.com> Message-ID: On Thu, 11 Sep 2025 02:41:34 GMT, Sergey Bylokhov wrote: >> Test does >> - renders inactiveFrame >> - renders activeFrame >> - wait for active frame to be active >> - press on second button in inactive frame >> - wait for second button should be focus owner >> - Check Button2 should be the focus owner >> >> I think the current test is also doing the same even now.. > >>All the semaphore logic is still the same after that > > My point is that this logic is wrong. It should first check that the first window has become visible, then the second window, and only after that start the test execution. In this case, no additional changes would be necessary, or am I missing something? ok..updated.. Guess CountDownLatch would have been more apt but continues with existing semaphore logic.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27156#discussion_r2338597834 From psadhukhan at openjdk.org Thu Sep 11 05:21:26 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Sep 2025 05:21:26 GMT Subject: RFR: 8366852: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java test is failing In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 06:28:08 GMT, Alexander Zvegintsev wrote: > There are several major issues with the test: > > 1. The `frameExited` variable is set to true when the mouse pointer exits the frame. The test does not expect this to happen with the first mouse click on the `choice` when the mouse pointer is already over the test frame (frame mouseExited - > choice mouseEntered). A reset for the frameExited was added. > 2. The test does not wait for the frame to appear after the call to `setVisible()`, so the test can start operating not on a fully visible window (e.g. one with an appearance animation). A delay has been added. > 3. In macOS, the direction of rotation of the mouse wheel is different, which was not taken into account. > > Testing looks good. test/jdk/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java line 57: > 55: private volatile boolean wheelMoved = false; > 56: private volatile boolean frameExited = false; > 57: private final Choice choice = new Choice(); WHy not do the initialization in EDT in constructor? test/jdk/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java line 60: > 58: > 59: public static void main(String[] args) throws Exception { > 60: ChoiceMouseWheelTest test = Util.invokeOnEDT(ChoiceMouseWheelTest::new); Is there any need to have dependancy on Util..we can use EventQueue directly, right? That will help in running standalone too!! Also jtreg tags is not aligned with asterisks and author tag not removed|| test/jdk/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java line 121: > 119: > 120: // mouse wheel doesn't work for the choice on X11 and Mac, so skip it > 121: if (!isXtoolkit && !isLWCToolkit) { Is this block required? As in the description it is mentioned that the wheel rotation is taken care for macos down below and it seems test works ok without this block too.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27161#discussion_r2338608365 PR Review Comment: https://git.openjdk.org/jdk/pull/27161#discussion_r2335846378 PR Review Comment: https://git.openjdk.org/jdk/pull/27161#discussion_r2335845878 From psadhukhan at openjdk.org Thu Sep 11 05:23:54 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Sep 2025 05:23:54 GMT Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java [v5] In-Reply-To: References: Message-ID: <-Bi3E4o2YNkLpbMTdxa5i5hqWUInBY3bCWCYCcDLebI=.0a7f0e21-3e4f-4f9c-a268-96c9e8388e4a@github.com> On Mon, 8 Sep 2025 08:42:35 GMT, Srinivas Mandalika 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. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > review Feedback: simplified test failure conditions. test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 28: > 26: * @key headful > 27: * @summary To check proper WINDOW_EVENTS are triggered when Frame gains > 28: * or looses the focus align the summary..should be "loses" test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 220: > 218: "undecorated frame when another frame gains focus!"); > 219: } > 220: if (frame.hasFocus()) { why this check is removed? We dont have latch for windowLostFocus so I think this check would be required!! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2338614564 PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2338617407 From smarks at openjdk.org Thu Sep 11 06:30:20 2025 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 11 Sep 2025 06:30:20 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 17:33:05 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8354469 > - decouple PassFailJFrame.java change; simplify code flow > - the fix Marked as reviewed by smarks (Reviewer). src/java.base/share/classes/sun/security/util/Password.java line 193: > 191: ba[bb.position()] = '\n'; > 192: } > 193: return ba; Some random comments. This is all internal to this class, and it's all vaguely cleanup, so it's up to you whether to take any action on any of these points. It might be worth having a comment on this method that explains why it's doing this. The "obvious" way of encoding the characters is to use String.getBytes(), but you probably don't want to create a String, because (I think) you want to be able to erase the arrays afterwards. Worth explaining, if true. At lines 190-191 the mixture of buffer and array stuff is kind of confusing. I think you can check whether bb.remaining() > 0 and use bb.put(). There are actually three possibilities for what's in the returned byte array: 1) it's completely filled with encoded bytes from the input; 2) it contains the encoded input followed by an NL byte; or 3) it contains the encoded input, an NL byte, followed by an arbitrary number of zero bytes. The way that the returned array is processed by the caller handles this, but it seems a bit brittle. One possibility is always to return an array of the exact correct length, including an NL byte. Of course this entails an extra copy (and an extra array to erase) but there are fewer cases for the caller to handle. ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3209119549 PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2338827872 From jwood at openjdk.org Thu Sep 11 07:06:20 2025 From: jwood at openjdk.org (Jeremy Wood) Date: Thu, 11 Sep 2025 07:06:20 GMT Subject: RFR: 8367376: Bad ButtonUI prevents other components from updating when system changes desktop properties [v2] In-Reply-To: References: Message-ID: <45yYaFBp8GsR1DNzZQYvX686bgnY85jyBCZqdhe_GkU=.1596198a-3306-40f0-9670-526e146409c7@github.com> > Previously: > > If DesktopProperty#updateAllUIs threw an exception, we would never reset the update-pending property to false. This means any subsequent call to `updateUI()` would not attempt to call `updateAllUIs()` > > With this change: > Subsequent calls to DesktopProperty#updateUI() can still trigger at least one call to updateAllUIs(). Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8367376: trivial typos in comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27205/files - new: https://git.openjdk.org/jdk/pull/27205/files/abec6a4c..33937331 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27205&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27205&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27205/head:pull/27205 PR: https://git.openjdk.org/jdk/pull/27205 From psadhukhan at openjdk.org Thu Sep 11 10:12:08 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Sep 2025 10:12:08 GMT Subject: RFR: 6850365: closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails Message-ID: Test is made more robust by executing in EDT and cleanup done by frame dispose. Testing result is green. ------------- Commit messages: - 6850365: closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails - 6850365: closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails Changes: https://git.openjdk.org/jdk/pull/27214/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27214&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6850365 Stats: 43 lines in 1 file changed: 23 ins; 14 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27214.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27214/head:pull/27214 PR: https://git.openjdk.org/jdk/pull/27214 From psadhukhan at openjdk.org Thu Sep 11 10:27:38 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 11 Sep 2025 10:27:38 GMT Subject: RFR: 8144124: [macosx] The tabs can't be aligned when we pressing the key of 'R','B','L','C' or 'T'. Message-ID: Test is passing on macos following the instructions listed in the test so deproblemlisting ------------- Commit messages: - 8144124: [macosx] The tabs can't be aligned when we pressing the key of 'R','B','L','C' or 'T'. Changes: https://git.openjdk.org/jdk/pull/27216/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27216&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8144124 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27216.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27216/head:pull/27216 PR: https://git.openjdk.org/jdk/pull/27216 From azvegint at openjdk.org Thu Sep 11 14:51:27 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 11 Sep 2025 14:51:27 GMT Subject: RFR: 8366852: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java test is failing [v2] In-Reply-To: References: Message-ID: > There are several major issues with the test: > > 1. The `frameExited` variable is set to true when the mouse pointer exits the frame. The test does not expect this to happen with the first mouse click on the `choice` when the mouse pointer is already over the test frame (frame mouseExited - > choice mouseEntered). A reset for the frameExited was added. > 2. The test does not wait for the frame to appear after the call to `setVisible()`, so the test can start operating not on a fully visible window (e.g. one with an appearance animation). A delay has been added. > 3. In macOS, the direction of rotation of the mouse wheel is different, which was not taken into account. > > Testing looks good. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27161/files - new: https://git.openjdk.org/jdk/pull/27161/files/e6d3846f..f7c9bc09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27161&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27161&range=00-01 Stats: 11 lines in 1 file changed: 1 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27161.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27161/head:pull/27161 PR: https://git.openjdk.org/jdk/pull/27161 From azvegint at openjdk.org Thu Sep 11 14:51:30 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 11 Sep 2025 14:51:30 GMT Subject: RFR: 8366852: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java test is failing [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:17:16 GMT, Prasanta Sadhukhan wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > test/jdk/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java line 57: > >> 55: private volatile boolean wheelMoved = false; >> 56: private volatile boolean frameExited = false; >> 57: private final Choice choice = new Choice(); > > WHy not do the initialization in EDT in constructor? It is already on EDT, but moved to the constructor. > Is there any need to have dependancy on Util..we can use EventQueue directly, right? That will help in running standalone too!! It was already there, so I decided to use it. It greatly reduce the code amount. > Also jtreg tags is not aligned with asterisks and author tag not removed|| updated > test/jdk/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java line 121: > >> 119: >> 120: // mouse wheel doesn't work for the choice on X11 and Mac, so skip it >> 121: if (!isXtoolkit && !isLWCToolkit) { > > Is this block required? As in the description it is mentioned that the wheel rotation is taken care for macos down below and it seems test works ok without this block too.. This is a different case that only works on Windows. When the mouse cursor is above the choice, you should be able to change the items using the mouse wheel. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27161#discussion_r2341215416 PR Review Comment: https://git.openjdk.org/jdk/pull/27161#discussion_r2341222995 PR Review Comment: https://git.openjdk.org/jdk/pull/27161#discussion_r2341208632 From aivanov at openjdk.org Thu Sep 11 15:29:20 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 11 Sep 2025 15:29:20 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v12] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:00:38 GMT, ScientificWare 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 = """ >> >> >> >>

>> - Merge master > - ... and 19 more: https://git.openjdk.org/jdk/compare/134c3ef4...5e6a08bd Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-3212353396 From naoto at openjdk.org Thu Sep 11 16:03:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 Sep 2025 16:03:20 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: <2KENBWE0y3RP7icnmW5njdDVhjku9jIxuDCTHbHKSek=.5d70302f-df86-4b5a-a523-45e5216a77ff@github.com> On Wed, 10 Sep 2025 17:33:05 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8354469 > - decouple PassFailJFrame.java change; simplify code flow > - the fix Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3212536122 From prr at openjdk.org Thu Sep 11 17:27:14 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 11 Sep 2025 17:27:14 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v12] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:00:38 GMT, ScientificWare 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 = """ >> >> >> >>

>> - Merge master > - ... and 19 more: https://git.openjdk.org/jdk/compare/134c3ef4...5e6a08bd Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-3212936862 From prr at openjdk.org Thu Sep 11 17:33:58 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 11 Sep 2025 17:33:58 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v3] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Wed, 10 Sep 2025 02:11:48 GMT, Prasanta Sadhukhan wrote: >> Test used to fail earlier with above message. >> Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Remove old files > - Rename tests I don't understand why I can't see any evidence of the rename. There's no rename, and no deletion of the original files. Not here and not in the webrev. ------------- PR Review: https://git.openjdk.org/jdk/pull/27136#pullrequestreview-3212960020 From weijun at openjdk.org Thu Sep 11 17:52:33 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 Sep 2025 17:52:33 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 06:26:37 GMT, Stuart Marks wrote: >> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into 8354469 >> - decouple PassFailJFrame.java change; simplify code flow >> - the fix > > src/java.base/share/classes/sun/security/util/Password.java line 193: > >> 191: ba[bb.position()] = '\n'; >> 192: } >> 193: return ba; > > Some random comments. This is all internal to this class, and it's all vaguely cleanup, so it's up to you whether to take any action on any of these points. > > It might be worth having a comment on this method that explains why it's doing this. The "obvious" way of encoding the characters is to use String.getBytes(), but you probably don't want to create a String, because (I think) you want to be able to erase the arrays afterwards. Worth explaining, if true. > > At lines 190-191 the mixture of buffer and array stuff is kind of confusing. I think you can check whether bb.remaining() > 0 and use bb.put(). > > There are actually three possibilities for what's in the returned byte array: 1) it's completely filled with encoded bytes from the input; 2) it contains the encoded input followed by an NL byte; or 3) it contains the encoded input, an NL byte, followed by an arbitrary number of zero bytes. The way that the returned array is processed by the caller handles this, but it seems a bit brittle. One possibility is always to return an array of the exact correct length, including an NL byte. Of course this entails an extra copy (and an extra array to erase) but there are fewer cases for the caller to handle. Thanks. I'll add some comments and do not mix buffer and array. The `\n` trick as a stop sign will be kept to avoid too many changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2341920574 From weijun at openjdk.org Thu Sep 11 17:57:57 2025 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 11 Sep 2025 17:57:57 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v4] In-Reply-To: References: Message-ID: > Allow password hiding even if there is no `System.console`. A manual test is included. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: use ByteBuffer::put for newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27196/files - new: https://git.openjdk.org/jdk/pull/27196/files/3ecf2443..5fa7b2f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27196&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27196/head:pull/27196 PR: https://git.openjdk.org/jdk/pull/27196 From aivanov at openjdk.org Thu Sep 11 18:00:15 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 11 Sep 2025 18:00:15 GMT Subject: RFR: 8366844: Update and automate MouseDraggedOriginatedByScrollBarTest.java [v7] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 22:47:47 GMT, Damon Nguyen wrote: >> When testing jtreg manual tests, some tests were out of date. This PR is an attempt at updating the test and automating it. >> >> `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. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant toString and volatile. Add EDT. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26636#pullrequestreview-3213050050 From hchao at openjdk.org Thu Sep 11 23:52:13 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 11 Sep 2025 23:52:13 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v4] In-Reply-To: References: Message-ID: <8Hl8M2taWGiLBmqahDqgqsKD_T6n17_C7JONGAyLcvI=.5c282639-970e-4f8f-8105-5a2e97080b08@github.com> On Thu, 11 Sep 2025 17:57:57 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > use ByteBuffer::put for newline Marked as reviewed by hchao (Reviewer). Changes look good. I ran the newly created manual test on Mac and the test was running fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3214033002 PR Comment: https://git.openjdk.org/jdk/pull/27196#issuecomment-3282998016 From psadhukhan at openjdk.org Fri Sep 12 01:37:08 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Sep 2025 01:37:08 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v3] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Thu, 11 Sep 2025 17:31:29 GMT, Phil Race wrote: > I don't understand why I can't see any evidence of the rename. There's no rename, and no deletion of the original files. Not here and not in the webrev. I guess I forgot to commit the deleted files after renaming..Its done now.. @prrace Please check now.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27136#issuecomment-3283308498 From psadhukhan at openjdk.org Fri Sep 12 01:37:06 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Sep 2025 01:37:06 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v4] In-Reply-To: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: > Test used to fail earlier with above message. > Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - summary - Remove old files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27136/files - new: https://git.openjdk.org/jdk/pull/27136/files/25d8673f..c6b4d38b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27136&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27136&range=02-03 Stats: 147 lines in 3 files changed: 0 ins; 146 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27136.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27136/head:pull/27136 PR: https://git.openjdk.org/jdk/pull/27136 From azvegint at openjdk.org Fri Sep 12 02:46:09 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 12 Sep 2025 02:46:09 GMT Subject: RFR: 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 16:51:25 GMT, Sergey Bylokhov wrote: > If the initial size is correct now, why do we receive a notification in Java when the size hasn't changed from the initial one? It is coming from https://github.com/openjdk/jdk/blob/ec7432331ba09cc2d257af51abc494aab209d912/src/java.desktop/unix/classes/sun/awt/X11/XContentWindow.java#L159-L162 https://github.com/openjdk/jdk/blob/ec7432331ba09cc2d257af51abc494aab209d912/src/java.desktop/unix/classes/sun/awt/X11/XContentWindow.java#L128-L134 `!(newBounds.equals(getBounds())); ` check has actually different sizes. I'm not sure, though, why it compares all bounds instead of just size, like in other places. However, a more in-depth evaluation is beyond the scope of the current test sprint. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27149#issuecomment-3281351988 From serb at openjdk.org Fri Sep 12 02:46:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Sep 2025 02:46:10 GMT Subject: RFR: 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:15:38 GMT, Alexander Zvegintsev wrote: >However, a more in-depth evaluation is beyond the scope of the current test sprint. Then why the test changed and excluded using a tag, if it was already excluded via the problem list with a corresponding bugid? This bugid can be used to evaluate the issue later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27149#issuecomment-3283446920 From serb at openjdk.org Fri Sep 12 03:00:19 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Sep 2025 03:00:19 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v6] In-Reply-To: <775Ved3ubwdZkh3A3Hqs4AYDe3WhCrPdaMT9qbSQ3Jo=.1e545f99-d89f-4e06-9def-ce7d20ee1bbd@github.com> References: <775Ved3ubwdZkh3A3Hqs4AYDe3WhCrPdaMT9qbSQ3Jo=.1e545f99-d89f-4e06-9def-ce7d20ee1bbd@github.com> Message-ID: On Thu, 11 Sep 2025 03:51:52 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code >> >> Please 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 summary src/java.desktop/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java line 558: > 556: static void applyInsets(Rectangle rect, Insets insets, boolean leftToRight) { > 557: if (insets != null) { > 558: Insets newInsets = new Insets(insets.top, (leftToRight ? insets.left : insets.right), Maybe we can eliminate the creation of a new object on each paint event? Since neither method is part of the public API, how about changing the signature of SwingUtilities3.applyInsets and removing the corresponding method in SynthGraphicsUtils?" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27157#discussion_r2342815514 From smarks at openjdk.org Fri Sep 12 03:40:16 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 12 Sep 2025 03:40:16 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v4] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:57:57 GMT, Weijun Wang wrote: >> Allow password hiding even if there is no `System.console`. A manual test is included. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > use ByteBuffer::put for newline Marked as reviewed by smarks (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27196#pullrequestreview-3214475801 From smarks at openjdk.org Fri Sep 12 03:40:18 2025 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 12 Sep 2025 03:40:18 GMT Subject: RFR: 8354469: Keytool exposes the password in plain text when command is piped using | grep [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 17:50:10 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/Password.java line 193: >> >>> 191: ba[bb.position()] = '\n'; >>> 192: } >>> 193: return ba; >> >> Some random comments. This is all internal to this class, and it's all vaguely cleanup, so it's up to you whether to take any action on any of these points. >> >> It might be worth having a comment on this method that explains why it's doing this. The "obvious" way of encoding the characters is to use String.getBytes(), but you probably don't want to create a String, because (I think) you want to be able to erase the arrays afterwards. Worth explaining, if true. >> >> At lines 190-191 the mixture of buffer and array stuff is kind of confusing. I think you can check whether bb.remaining() > 0 and use bb.put(). >> >> There are actually three possibilities for what's in the returned byte array: 1) it's completely filled with encoded bytes from the input; 2) it contains the encoded input followed by an NL byte; or 3) it contains the encoded input, an NL byte, followed by an arbitrary number of zero bytes. The way that the returned array is processed by the caller handles this, but it seems a bit brittle. One possibility is always to return an array of the exact correct length, including an NL byte. Of course this entails an extra copy (and an extra array to erase) but there are fewer cases for the caller to handle. > > Thanks. I'll add some comments and do not mix buffer and array. The `\n` trick as a stop sign will be kept to avoid too many changes. Thanks for the updates. Re-approving in case it's necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27196#discussion_r2342858920 From psadhukhan at openjdk.org Fri Sep 12 03:50:23 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Sep 2025 03:50:23 GMT Subject: RFR: 8366852: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java test is failing [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:51:27 GMT, Alexander Zvegintsev wrote: >> There are several major issues with the test: >> >> 1. The `frameExited` variable is set to true when the mouse pointer exits the frame. The test does not expect this to happen with the first mouse click on the `choice` when the mouse pointer is already over the test frame (frame mouseExited - > choice mouseEntered). A reset for the frameExited was added. >> 2. The test does not wait for the frame to appear after the call to `setVisible()`, so the test can start operating not on a fully visible window (e.g. one with an appearance animation). A delay has been added. >> 3. In macOS, the direction of rotation of the mouse wheel is different, which was not taken into account. >> >> Testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27161#pullrequestreview-3214489752 From psadhukhan at openjdk.org Fri Sep 12 05:53:08 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Sep 2025 05:53:08 GMT Subject: RFR: 8299304: Test "java/awt/print/PrinterJob/PageDialogTest.java" fails on macOS 13 x64 because the Page Dialog blocks the Toolkit Message-ID: mac printer dialog blocks underlying window even on native platform so this is not applicable to the test so restricting to run on osx ------------- Commit messages: - 8299304: Test java/awt/print/PrinterJob/PageDialogTest.java fails on macOS 13 x64 because the Page Dialog blocks the Toolkit Changes: https://git.openjdk.org/jdk/pull/27243/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299304 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27243.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27243/head:pull/27243 PR: https://git.openjdk.org/jdk/pull/27243 From duke at openjdk.org Fri Sep 12 05:56:28 2025 From: duke at openjdk.org (Dmitry Kulikov) Date: Fri, 12 Sep 2025 05:56:28 GMT Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess [v2] In-Reply-To: References: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com> Message-ID: On Fri, 29 Aug 2025 04:42:24 GMT, Phil Race wrote: >> Yes, all 3 points are correct. Probably the native URL handler is installed during the startup of the bundled application in order to catch the first OpenURL event that might have launched the application in the first place (I'll conduct more tests to see how an early handler registration affects the startup behavior). Java code technically is not required to install any URL handlers even in case of a bundled application, however declaring the capability to handle OpenURL events in the application bundle requires some actions from the application developer. I guess it was thought of as a "common sense" not to declare OpenURL handling capability in the bundle without actually handling the URLs in the Java code. >> >> Searching the Internet so far did not show up any references to `[bundle _hasEAWTOverride:@"URLHandler"]` (or the respective keys in the property list file) except the JDK code itself. Under such circumstances I've decided to leave these checks intact. >> >> I'm investigating the possibility of composing a regression test for this change. It does not look straight impossible so far. I'll post an update on this matter shortly. > > @ProjectD8 any update on the regression test ? > Adding one (or not) is the only thing between this being a PR and a pushed fix. @prrace I've come up with some ideas on encapsulating the required testing actions into a JTReg test. I've tested these concepts separately, and the results look promising. When putting everything together, however, I've encountered some difficulties with the programmatically generated macOS bundle, which may take some more time to rectify. Please expect an update in the next few days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25967#issuecomment-3283809663 From azvegint at openjdk.org Fri Sep 12 07:13:22 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 12 Sep 2025 07:13:22 GMT Subject: RFR: 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux In-Reply-To: References: Message-ID: <5PmpMc7_p8omFNqNWaatSF0MpRiBQFc-MegSFLWKFUU=.6da4e0a5-67ba-42d9-913f-a135b2edc3a0@github.com> On Fri, 12 Sep 2025 02:43:02 GMT, Sergey Bylokhov wrote: > Then why the test changed and excluded using a tag, if it was already excluded via the problem list with a corresponding bugid? This bugid can be used to evaluate the issue later. Sure, so closing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27149#issuecomment-3284048503 From azvegint at openjdk.org Fri Sep 12 07:13:23 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 12 Sep 2025 07:13:23 GMT Subject: Withdrawn: 8321289: open/test/jdk/javax/swing/JFrame/MaximizeWindowTest.java fails on Linux In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 16:30:48 GMT, Alexander Zvegintsev wrote: > This changeset excludes the test from running on Linux. We receive a ConfigureNotify from the system (Gnome Shell) with the initial window size. However, this does not happen on Plasma. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27149 From psadhukhan at openjdk.org Fri Sep 12 08:42:55 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Sep 2025 08:42:55 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: References: Message-ID: On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann wrote: >> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS. >> >> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m. > > Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266 > - Merge branch 'master' into pr/11266 > - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS > In CPrinterJob there is a method called javaPrinterJobToNSPrintInfo() This is invoked from within the printing loop and has this code > > ``` > [printingDictionary setObject:[NSNumber numberWithInteger:fromPage] forKey:NSPrintFirstPage]; > [printingDictionary setObject:[NSNumber numberWithInteger:toPage] forKey:NSPrintLastPage]; > ``` > So deleting/commenting out these lines > [printingDictionary setObject:[NSNumber numberWithInteger:fromPage] forKey:NSPrintFirstPage]; > [printingDictionary setObject:[NSNumber numberWithInteger:toPage] forKey:NSPrintLastPage]; > and ensuring we always set > [printingDictionary setObject:[NSNumber numberWithBool:YES] forKey:NSPrintAllPages]; > Also fixes this bug. There is some issue with using `NSPrintAllPages`. If the number of pages to be printed is 0 i.e, `Pageable.getNumberOfPages()` is 0 and we made `[printingDictionary setObject:[NSNumber numberWithBool:NO] forKey:NSPrintAllPages];` it still selects "All Pages" option and doesn't disable the Page Ranges option Also, if we want to have `Pageable.getNumberOfPages()` 2 i.e, fromPage 1 to toPage 2 and do [printingDictionary setObject:[NSNumber numberWithBool:NO] forKey:NSPrintAllPages]; [printingDictionary setObject:[NSNumber numberWithBool:YES] forKey:NSPrintSelectionOnly]; it does not select any of the radiobutton and Page Ranges still has 1 to 1 despite firsPage and toPage is correctly being passed as 1 and 2 to printingDictionary It can be seen with test` java/awt/print/Dialog/PrintDlgPageable.java`..Not sure if it's an Apple bug.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3284327405 From azvegint at openjdk.org Fri Sep 12 10:29:10 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 12 Sep 2025 10:29:10 GMT Subject: RFR: 8144124: [macosx] The tabs can't be aligned when we pressing the key of 'R','B','L','C' or 'T'. In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 10:20:55 GMT, Prasanta Sadhukhan wrote: > Test is passing on macos following the instructions listed in the test so deproblemlisting Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27216#pullrequestreview-3215984514 From psadhukhan at openjdk.org Fri Sep 12 10:46:33 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 12 Sep 2025 10:46:33 GMT Subject: Integrated: 8144124: [macosx] The tabs can't be aligned when we pressing the key of 'R','B','L','C' or 'T'. In-Reply-To: References: Message-ID: <40nEUQoB3ab7z4t2Iyj0qKobTMoWUl07raE_6CGfivk=.6839f88f-d757-4cb6-8cfc-396190b71f3a@github.com> On Thu, 11 Sep 2025 10:20:55 GMT, Prasanta Sadhukhan wrote: > Test is passing on macos following the instructions listed in the test so deproblemlisting This pull request has now been integrated. Changeset: 15dd96f7 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/15dd96f7a68f634124c73d78659212e7f335230e Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8144124: [macosx] The tabs can't be aligned when we pressing the key of 'R','B','L','C' or 'T'. Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/27216 From honkar at openjdk.org Fri Sep 12 17:14:26 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Sep 2025 17:14:26 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v4] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: On Fri, 12 Sep 2025 01:37:06 GMT, Prasanta Sadhukhan wrote: >> Test used to fail earlier with above message. >> Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - summary > - Remove old files LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27136#pullrequestreview-3217949423 From prr at openjdk.org Fri Sep 12 17:57:26 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 12 Sep 2025 17:57:26 GMT Subject: RFR: 8256289: java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java failed with "RuntimeException: Wrong focus owner: java.awt.Button[button1,41,36,56x23,label=Button1]" [v4] In-Reply-To: References: <-4oYZPw88CCWck9PtpLhqdzM13LuIYfOBnxTOZ5yyZ4=.db9c834f-9d17-4a0b-afa9-2b01010145d7@github.com> Message-ID: <6NahDvVKHFAuFQ1u4SJQ8ZSjB9e9Dj7gl2wHdlmsQ80=.f9ce3a22-0ab2-4066-89ca-48414d0eacae@github.com> On Fri, 12 Sep 2025 01:37:06 GMT, Prasanta Sadhukhan wrote: >> Test used to fail earlier with above message. >> Execution of the test didn't cause any failure in recent run of this test for several iterations as seen in job listed in JBS so deproblemlisting > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - summary > - Remove old files Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27136#pullrequestreview-3218090929 From honkar at openjdk.org Fri Sep 12 18:10:20 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Sep 2025 18:10:20 GMT Subject: RFR: 6850365: closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails In-Reply-To: References: Message-ID: <_kdbYY3HUkT5i3UsgLsHqEeM4cNWb-hPyUyceRsApt4=.97041c4d-ea10-4c37-90f0-b394b1db83f9@github.com> On Thu, 11 Sep 2025 10:02:59 GMT, Prasanta Sadhukhan wrote: > Test is made more robust by executing in EDT and cleanup done by frame dispose. Testing result is green. @prsadhuk Do we consider renaming the JBS title since this is open-sourced and java test now? ------------- PR Review: https://git.openjdk.org/jdk/pull/27214#pullrequestreview-3218124472 From serb at openjdk.org Fri Sep 12 18:40:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 12 Sep 2025 18:40:15 GMT Subject: RFR: 8023263: [TESTBUG] Test closed/java/awt/Focus/InactiveWindowTest/InactiveFocusRace fails due to not enough time to initialize graphic components [v2] In-Reply-To: <9rIXqCPFUFJz94nlGFHQEFgphxXHjutEYOKjuILE-k0=.13e54fb9-4e89-4ce8-b5b1-434fa0fbee1e@github.com> References: <9rIXqCPFUFJz94nlGFHQEFgphxXHjutEYOKjuILE-k0=.13e54fb9-4e89-4ce8-b5b1-434fa0fbee1e@github.com> Message-ID: On Thu, 11 Sep 2025 05:15:47 GMT, Prasanta Sadhukhan wrote: >> Test was failing due to lack of time between initializing graphics components and test start. >> Added robot delay and execution under EDT. >> >> Several iterations of test is passing so deproblemlisting, CI job link in JBS > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Wait for inactive frame to be visible before active frame Looks fine, please confirm mach5 is green ------------- Marked as reviewed by serb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27156#pullrequestreview-3218305735 From aivanov at openjdk.org Fri Sep 12 18:56:14 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Sep 2025 18:56:14 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v6] In-Reply-To: <775Ved3ubwdZkh3A3Hqs4AYDe3WhCrPdaMT9qbSQ3Jo=.1e545f99-d89f-4e06-9def-ce7d20ee1bbd@github.com> References: <775Ved3ubwdZkh3A3Hqs4AYDe3WhCrPdaMT9qbSQ3Jo=.1e545f99-d89f-4e06-9def-ce7d20ee1bbd@github.com> Message-ID: On Thu, 11 Sep 2025 03:51:52 GMT, Renjith Kannath Pariyangad wrote: >> Hi Reviewers, >> >> I have updated the insets calculation, similar calculation observed in **SynthGraphicsUtils.java**. Reused the **SwingUtilities3.java** modified code >> >> Please 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 summary Changes requested by aivanov (Reviewer). test/jdk/javax/swing/SwingUtilities/8365379/bug8365379.java line 1: > 1: /* Since this test has nothing to do with the public API of `javax.swing.SwingUtilities`, it should reside in the folder structure that corresponds to `com/sun/java/swing/SwingUtilities3.java`, I propose `test/jdk/com/sun/java/swing/SwingUtilities3/ApplyInsetsTest.java`. We no longer create directories for each test and give meaningful names to test files rather than `bug####.java`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27157#pullrequestreview-3218340900 PR Review Comment: https://git.openjdk.org/jdk/pull/27157#discussion_r2345160797 From aivanov at openjdk.org Fri Sep 12 18:56:18 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Sep 2025 18:56:18 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v6] In-Reply-To: References: <775Ved3ubwdZkh3A3Hqs4AYDe3WhCrPdaMT9qbSQ3Jo=.1e545f99-d89f-4e06-9def-ce7d20ee1bbd@github.com> Message-ID: <-chAmudbnbOHr2lOOJPCEsguLUG9msV-EKkP1edb_Pg=.b8d4abb8-7762-4bf9-a924-4778e6490ea0@github.com> On Fri, 12 Sep 2025 02:57:27 GMT, Sergey Bylokhov wrote: >> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated summary > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java line 558: > >> 556: static void applyInsets(Rectangle rect, Insets insets, boolean leftToRight) { >> 557: if (insets != null) { >> 558: Insets newInsets = new Insets(insets.top, (leftToRight ? insets.left : insets.right), > > Maybe we can eliminate the creation of a new object on each paint event? Since neither method is part of the public API, how about changing the signature of SwingUtilities3.applyInsets and removing the corresponding method in SynthGraphicsUtils?" Agreed. `SwingUtilities3` can easily have two methods: `applyInsets(Rectangle rect, Insets insets)` as well as `applyInsets(Rectangle rect, Insets insets, boolean leftToRight)` where the former calls the latter with `leftToRight = true`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27157#discussion_r2345136670 From aivanov at openjdk.org Fri Sep 12 18:56:21 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 12 Sep 2025 18:56:21 GMT Subject: RFR: 8365379: SU3.applyInsets may produce wrong results [v5] In-Reply-To: References: <8xooH0P5hHEoRogEGA4BOj_yIZ1jxJgPI3KzNST2OGw=.f8da0509-9e9c-47ee-8dd4-d9da66b37640@github.com> <6Zo4vgvK5pCk4IrIdrJnVz6gO-fNtF0yCrDS-pVJ-9g=.5e5fcf3b-0578-4457-ab77-87166e966a31@github.com> Message-ID: On Thu, 11 Sep 2025 03:55:25 GMT, Renjith Kannath Pariyangad wrote: >> test/jdk/javax/swing/SwingUtilities/8365379/bug8365379.java line 33: >> >>> 31: * @bug 8365379 >>> 32: * @summary Verify LineBorder edges have the same width >>> 33: * @modules java.desktop/com.sun.java.swing >> >> Can we verify it w/o using internals? > > As you are aware existing calculation will go wrong only for non zero X & Y. As far as my understanding existing calls passing 0,0 as X,Y. so I did not find any other way w/o using internals. > > FYI : summary was wrong that I have corrected. > > Let me know if you have any suggestions. > Can we verify it w/o using internals? This method is used menu rendering. All the current usages pass rectangles where `x` and `y` are zeros, so the existing code works correctly. Yet the code in the method will produce wrong result if the `x` and `y` aren't equal to zero. Since there are no other usages, it's impossible to reproduce the bug. Now that the method resides in `SwingUtilities3`, it's not localised its current usages, and if anyone uses the method, the result may be wrong. This test is like a unit test that ensures the `applyInsets` method returns the correct and expected result with any parameters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27157#discussion_r2345150218 From honkar at openjdk.org Fri Sep 12 18:57:18 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Sep 2025 18:57:18 GMT Subject: RFR: 8366852: java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java test is failing [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:51:27 GMT, Alexander Zvegintsev wrote: >> There are several major issues with the test: >> >> 1. The `frameExited` variable is set to true when the mouse pointer exits the frame. The test does not expect this to happen with the first mouse click on the `choice` when the mouse pointer is already over the test frame (frame mouseExited - > choice mouseEntered). A reset for the frameExited was added. >> 2. The test does not wait for the frame to appear after the call to `setVisible()`, so the test can start operating not on a fully visible window (e.g. one with an appearance animation). A delay has been added. >> 3. In macOS, the direction of rotation of the mouse wheel is different, which was not taken into account. >> >> Testing looks good. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Changes LGTM. test/jdk/java/awt/Choice/ChoiceMouseWheelTest/ChoiceMouseWheelTest.java line 28: > 26: * @key headful > 27: * @bug 7050935 > 28: * @summary closed/java/awt/Choice/WheelEventsConsumed/WheelEventsConsumed.html fails on win32 Minor: You may want to change the test path in the summary ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27161#pullrequestreview-3218393787 PR Review Comment: https://git.openjdk.org/jdk/pull/27161#discussion_r2345163870 From honkar at openjdk.org Fri Sep 12 19:33:16 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 12 Sep 2025 19:33:16 GMT Subject: RFR: 8024419: Can not find the specified directory in the frame. In-Reply-To: <11QOOGkRuokjDJ4515zBPdeRv-X77C1m5Oqy81X_Qrc=.2cd308e0-f1ff-46b6-bf10-4f090c595a51@github.com> References: <11QOOGkRuokjDJ4515zBPdeRv-X77C1m5Oqy81X_Qrc=.2cd308e0-f1ff-46b6-bf10-4f090c595a51@github.com> Message-ID: On Wed, 10 Sep 2025 06:47:38 GMT, Prasanta Sadhukhan wrote: > Test tests navigation on virtual file created on Virtual File System which is not supported in macos so restricting it for osx run. LGTM apart from minor test instruction update for clarity. This test verifies navigating into subdir two ways: 1. Verify if you are able to go into subdir by double click and then return to "testdir" parent directory. 2. Next select 'subdir' folder and press the 'Open' button If both methods of navigating into the subdir work, press Pass else Fail. ------------- PR Review: https://git.openjdk.org/jdk/pull/27185#pullrequestreview-3218556470 From duke at openjdk.org Fri Sep 12 19:44:20 2025 From: duke at openjdk.org (duke) Date: Fri, 12 Sep 2025 19:44:20 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v12] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:00:38 GMT, ScientificWare 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 = """ >> >> >> >>

>> - Merge master > - ... and 19 more: https://git.openjdk.org/jdk/compare/134c3ef4...5e6a08bd @scientificware Your change (at version 5e6a08bde302f0f5156374ee6a9e1e6cd3f58899) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-3286603390 From duke at openjdk.org Sat Sep 13 05:10:46 2025 From: duke at openjdk.org (ScientificWare) Date: Sat, 13 Sep 2025 05:10:46 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v11] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:59:07 GMT, Alexey Ivanov wrote: >> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: >> >> - Merge master >> - Change the copyright year and apply the suggestions from the test code. >> >> bug8314731.java: >> - Bump the copyright year to 2025. >> - Rename or remove some methods. >> - Simplify the code. >> - Remove unused imports. >> - Replace the anonymous class with a lambda. >> >> FormView.java: >> - Fix misalignment. >> - 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. >> - ... and 17 more: https://git.openjdk.org/jdk/compare/bea2b029...25965200 > > I've run all client tests, all's green. @aivanov-jdk, could you please sponsor this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-3287591596