From serb at openjdk.org Sun Jun 1 02:19:58 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 1 Jun 2025 02:19:58 GMT Subject: RFR: 8357696: Enhance code consistency: java.desktop/unix [v2] In-Reply-To: References: Message-ID: > This is a request to update the remaining parts of the java.desktop/unix package. > The sun.awt subpackage under java.desktop/unix was previously addressed by https://github.com/openjdk/jdk/pull/24941. > > ==================================================== > > The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency. > > The public API was not affected so there is no need to worry about a CSR > > Note: I will submit additional patches in this area later because: > > 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797)) > 2. I skipped adding `@Override` for anonymous classes > > Any feedback or suggestions are welcome! > > Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff) to a simple diff file, it might be more convenient for reviewing the changes. > > To download the diff file and filter only the modified lines you can use the following script: > > > curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff -o d.txt && grep -E '^+|^-' d.txt > > > The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into over_all_unix - Merge branch 'openjdk:master' into over_all_unix - final in java.desktop/unix - override in java.desktop/unix ------------- Changes: https://git.openjdk.org/jdk/pull/25439/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25439&range=01 Stats: 393 lines in 64 files changed: 293 ins; 3 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/25439.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25439/head:pull/25439 PR: https://git.openjdk.org/jdk/pull/25439 From serb at openjdk.org Sun Jun 1 02:27:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 1 Jun 2025 02:27:50 GMT Subject: RFR: 8357696: Enhance code consistency: java.desktop/unix [v3] In-Reply-To: References: Message-ID: > This is a request to update the remaining parts of the java.desktop/unix package. > The sun.awt subpackage under java.desktop/unix was previously addressed by https://github.com/openjdk/jdk/pull/24941. > > ==================================================== > > The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency. > > The public API was not affected so there is no need to worry about a CSR > > Note: I will submit additional patches in this area later because: > > 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797)) > 2. I skipped adding `@Override` for anonymous classes > > Any feedback or suggestions are welcome! > > Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff) to a simple diff file, it might be more convenient for reviewing the changes. > > To download the diff file and filter only the modified lines you can use the following script: > > > curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff -o d.txt && grep -E '^+|^-' d.txt > > > The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: fix merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25439/files - new: https://git.openjdk.org/jdk/pull/25439/files/8447a789..fbdfb223 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25439&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25439&range=01-02 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25439.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25439/head:pull/25439 PR: https://git.openjdk.org/jdk/pull/25439 From serb at openjdk.org Sun Jun 1 02:38:00 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 1 Jun 2025 02:38:00 GMT Subject: RFR: 8357696: Enhance code consistency: java.desktop/unix [v3] In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 02:27:50 GMT, Sergey Bylokhov wrote: >> This is a request to update the remaining parts of the java.desktop/unix package. >> The sun.awt subpackage under java.desktop/unix was previously addressed by https://github.com/openjdk/jdk/pull/24941. >> >> ==================================================== >> >> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency. >> >> The public API was not affected so there is no need to worry about a CSR >> >> Note: I will submit additional patches in this area later because: >> >> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797)) >> 2. I skipped adding `@Override` for anonymous classes >> >> Any feedback or suggestions are welcome! >> >> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff) to a simple diff file, it might be more convenient for reviewing the changes. >> >> To download the diff file and filter only the modified lines you can use the following script: >> >> >> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff -o d.txt && grep -E '^+|^-' d.txt >> >> >> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > fix merge The merge conflict with [PR #24412](https://github.com/openjdk/jdk/pull/24412) has now been resolved in latest update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25439#issuecomment-2926315834 From duke at openjdk.org Sun Jun 1 06:43:44 2025 From: duke at openjdk.org (Jeremy Wood) Date: Sun, 1 Jun 2025 06:43:44 GMT Subject: RFR: 8356137: GifImageDecode can produce opaque image when disposal method changes [v9] In-Reply-To: References: Message-ID: > This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions: > > 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE") > 2. The transparent pixel is non-zero > 3. There's more than one such consecutive frame > > Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise. > > I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler: > > 1. [8357034](https://github.com/openjdk/jdk/pull/25264) > 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one) > 3. [8356320](https://github.com/openjdk/jdk/pull/25076) > 4. [8351913](https://github.com/openjdk/jdk/pull/24271) Jeremy Wood has updated the pull request incrementally with four additional commits since the last revision: - 8356137: adding copyright - 8356137: remove test file now that we use GifBuilder - 8356137: Use new GifBuilder for 8356137 test case This is in response to: https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750 - 8356137: Adding GifBuilder to dynamically create test file This can be used by multiple gif tests in this directory. This is in response to: https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25044/files - new: https://git.openjdk.org/jdk/pull/25044/files/e0546b1a..392a9e5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=07-08 Stats: 160 lines in 3 files changed: 154 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044 PR: https://git.openjdk.org/jdk/pull/25044 From duke at openjdk.org Sun Jun 1 07:02:52 2025 From: duke at openjdk.org (Jeremy Wood) Date: Sun, 1 Jun 2025 07:02:52 GMT Subject: RFR: 8356137: GifImageDecode can produce opaque image when disposal method changes [v6] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 14:18:13 GMT, Jayathirth D V wrote: > Also its better if we can actually create test gif file using ImageIO(There are examples in test/jdk/javax/imageio/plugins/gif/) programatically and use it instead of external GIF files for testing. I wrote a new class GifBuilder that programmatically creates the test gif file; and it can generate test files for some of the other related pending bugs. > I think we a need a gif with only 2 frames having transpixel>0 and disposal method save to reproduce this scenario. I think we need 3 frames. The test currently resembles: public static void main(String[] args) throws Throwable { GifBuilder.test( new GifBuilder.FrameDescription(GifBuilder.Disposal.restoreToBackgroundColor, false), new GifBuilder.FrameDescription(GifBuilder.Disposal.doNotDispose, false), new GifBuilder.FrameDescription(GifBuilder.Disposal.doNotDispose, false) ); } If I comment out any one of these three frames then this test passes when I run it against the master branch. For additional context: A. This file architecture was reverse engineered from https://free-gifs.org/gif/CC0-3D B. None of this weekend's changes alter the proposed change in GifImageDecoder ; this is all just refactoring the test ------------- PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-2926693285 From duke at openjdk.org Sun Jun 1 07:13:14 2025 From: duke at openjdk.org (Jeremy Wood) Date: Sun, 1 Jun 2025 07:13:14 GMT Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels [v4] In-Reply-To: References: Message-ID: > If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer. > > We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block. > > I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler: > > 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one) > 2. [8356137](https://github.com/openjdk/jdk/pull/25044) > 3. [8356320](https://github.com/openjdk/jdk/pull/25076) > 4. [8351913](https://github.com/openjdk/jdk/pull/24271) Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision: - 8356320: Use new GifBuilder and remove ukraine-flag.gif This is an extension of work for this PR: https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750 - 8356137: adding copyright - 8356137: Adding GifBuilder to dynamically create test file This can be used by multiple gif tests in this directory. This is in response to: https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750 - 8356137: trivial javadoc update - 8356137: only inspect last frame of gif This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.) This is in response to: https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25264/files - new: https://git.openjdk.org/jdk/pull/25264/files/3d94c434..3750e58e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=02-03 Stats: 262 lines in 4 files changed: 152 ins; 67 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/25264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25264/head:pull/25264 PR: https://git.openjdk.org/jdk/pull/25264 From prr at openjdk.org Sun Jun 1 19:10:51 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 1 Jun 2025 19:10:51 GMT Subject: RFR: 8356803: Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance In-Reply-To: References: Message-ID: On Fri, 30 May 2025 23:40:22 GMT, Daniel Gredler wrote: > Per discussion in JBS, adds the following chars to the list of ignorable whitespace chars: U+000B (Vertical Tab), U+000C (Form Feed), U+0085 (Next Line), U+2028 (Line Separator), U+2029 (Paragraph Separator). > > Adds the necessary testing in pre-existing automated test class `test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java`. > > Removes now-unnecessary manual test `test/jdk/java/awt/font/TextLayout/TestControls.java`. > > The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS. looks good. automated tests all pass. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25560#pullrequestreview-2885972150 From prr at openjdk.org Sun Jun 1 19:53:52 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 1 Jun 2025 19:53:52 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:18:06 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Correct the title of the test frames test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 58: > 56: The first file in the list has the following name: > 57: <html><h1 color=#ff00ff><font > 58: face="Comic Sans MS">Swing Rocks! I almost said this last time, but I think the instructions should use a different font name. On linux this will always just fall back to Dialog because this font doesn't exist. Better to just use "Serif". test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 128: > 126: jfc.setControlButtonsAreShown(false); > 127: > 128: JFrame frame = new JFrame((!htmlEnabled) ? "HTML enabled" : "HTML disabled"); I think this stems from a conflict in the name of the property (html.disable) and the variable (htmlEnabled) I suggest to rename the variable to htmlDisabled and re-organise the constructor line to JFrame frame = new JFrame((htmlDisabled) ? "HTML disabled" : "HTML enabled"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2119505070 PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2119504775 From prr at openjdk.org Sun Jun 1 20:02:51 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 1 Jun 2025 20:02:51 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:18:06 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Correct the title of the test frames @TejeshR13 we need your review here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25455#issuecomment-2927801495 From psadhukhan at openjdk.org Mon Jun 2 02:09:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 2 Jun 2025 02:09:10 GMT Subject: Integrated: 8356594: JSplitPane loses divider location when reopened via JOptionPane.createDialog() In-Reply-To: References: Message-ID: On Mon, 19 May 2025 06:06:17 GMT, Prasanta Sadhukhan wrote: > The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. > This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user. > Fixed by setting the divider location before rendering the left and right components.. This pull request has now been integrated. Changeset: 90d6ad01 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/90d6ad015714b81064dd16d0e64f1b774e68d4f3 Stats: 204 lines in 2 files changed: 188 ins; 0 del; 16 mod 8356594: JSplitPane loses divider location when reopened via JOptionPane.createDialog() Reviewed-by: kizune ------------- PR: https://git.openjdk.org/jdk/pull/25294 From vyazici at openjdk.org Mon Jun 2 08:23:56 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 2 Jun 2025 08:23:56 GMT Subject: RFR: 8357994: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [client] In-Reply-To: References: Message-ID: <4jXKW30RJ_7lcngUSHsGBBLo66P4ZDfJfdePhvnMiQ4=.7d0ba632-4923-483b-a0cb-6f34ec9ab4e3@github.com> On Fri, 30 May 2025 21:21:56 GMT, Phil Race wrote: >> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. >> >> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357994 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to client libraries. > > This is the first I've heard of it but it makes absolutely zero sense here. > The data transfer case is things like "drag and drop" between applications. You'll never see it coming from stdin > And the editor kits will read FILES with some content you want to edit. No one will ever type it in. > So in summary, withdraw this PR. @prrace, thanks so much for the prompt feedback. Closing this PR and the associated JBS issue right away... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25543#issuecomment-2929387627 From vyazici at openjdk.org Mon Jun 2 08:23:57 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 2 Jun 2025 08:23:57 GMT Subject: Withdrawn: 8357994: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [client] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 10:59:17 GMT, Volkan Yazici wrote: > Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. > > `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357994 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to client libraries. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25543 From psadhukhan at openjdk.org Mon Jun 2 09:05:53 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 2 Jun 2025 09:05:53 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out In-Reply-To: References: Message-ID: <7AkgGa4KJlleFPLCBwe9T4HtX0bDjX_oJ4UxAzsbQQw=.c3569211-7607-4078-aa08-e257d4e53f1e@github.com> On Wed, 28 May 2025 10:29:17 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. Looks good to me.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25489#pullrequestreview-2887433873 From duke at openjdk.org Mon Jun 2 09:19:41 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Mon, 2 Jun 2025 09:19:41 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v7] In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: > Fixes issue in which the test fails when run on multi-screen machine. > > Tested on Ubuntu 24.04, MacOS 15 and Windows 11 > > JTREG > > runner starting test: java/awt/Frame/MultiScreenTest.java > runner finished test: java/awt/Frame/MultiScreenTest.java > Passed. Execution successful 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 four additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8352149 - Adds Override for overriden methods - Merge branch 'openjdk:master' into jdk-8352149 - 8352149: test/jdk/java/awt/Frame/MultiScreenTest.java fails in MacOS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24752/files - new: https://git.openjdk.org/jdk/pull/24752/files/5ec8be63..8dff1089 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=05-06 Stats: 140344 lines in 2331 files changed: 78406 ins; 42679 del; 19259 mod Patch: https://git.openjdk.org/jdk/pull/24752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24752/head:pull/24752 PR: https://git.openjdk.org/jdk/pull/24752 From duke at openjdk.org Mon Jun 2 09:33:34 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Mon, 2 Jun 2025 09:33:34 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v8] In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: > Fixes issue in which the test fails when run on multi-screen machine. > > Tested on Ubuntu 24.04, MacOS 15 and Windows 11 > > JTREG > > runner starting test: java/awt/Frame/MultiScreenTest.java > runner finished test: java/awt/Frame/MultiScreenTest.java > Passed. Execution successful Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: Removes unnecessary lines and keep consistent code format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24752/files - new: https://git.openjdk.org/jdk/pull/24752/files/8dff1089..a2c27704 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=06-07 Stats: 7 lines in 1 file changed: 1 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24752/head:pull/24752 PR: https://git.openjdk.org/jdk/pull/24752 From duke at openjdk.org Mon Jun 2 09:33:34 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Mon, 2 Jun 2025 09:33:34 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> <0IkXQzTfHKgD2Zn6NLHlFZs6jpVi2ub7Zz-K74wObFA=.f53a3a43-53ec-41cd-a95b-d264fef102f8@github.com> <-SBD5rSWBUqG_5ToRe8BKD3uXVo9anMyso7nlishEW8=.bf332e96-18bd-4c11-849d-e26f2fbba5fd@github.com> Message-ID: <8bXmipk9K87MKYv8FUWP1j4mEksfibsBmQrQ3wO0XsA=.9d44a76c-e3bf-45e1-8cc1-59d54164c80d@github.com> On Tue, 13 May 2025 03:57:45 GMT, Abhishek Kumar wrote: >>> I ran the test (**without your fix**) on Windows, Mac and Linux platform. It failed on Windows and Mac but no issues on Linux. >> >> Why it fails on win/mac? > >> > I ran the test (**without your fix**) on Windows, Mac and Linux platform. It failed on Windows and Mac but no issues on Linux. >> >> Why it fails on win/mac? > > On Win/mac, graphic configuration return value is 1 and then there is no frame created as gc.length/2 evaluates to 0. @kumarabhi006 I made changes as you requested. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2929669616 From psadhukhan at openjdk.org Mon Jun 2 09:54:53 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 2 Jun 2025 09:54:53 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v5] In-Reply-To: <9OsgP7Nt-I4n_uqYEzVaNAbp-3rYf4ozSFmiWyDoF5Q=.5dc3cbc6-942d-490b-b086-c9803c92ee14@github.com> References: <9OsgP7Nt-I4n_uqYEzVaNAbp-3rYf4ozSFmiWyDoF5Q=.5dc3cbc6-942d-490b-b086-c9803c92ee14@github.com> Message-ID: <7C_922gw6YyrITP7jNbscW8Us16vSv6B3GKMvFs_XYE=.fca6f4f3-a101-4fcb-b032-e7934f82ac50@github.com> On Fri, 30 May 2025 17:13:24 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: fixing typo in summary > but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution. Does the accompanying testcase fails in Synth/Nimbus L&F, it seems not? Also, it will be useful to extend the test case to test all installed L&F since it it changing Basic L&F code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2929752779 From jdv at openjdk.org Mon Jun 2 11:24:53 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 2 Jun 2025 11:24:53 GMT Subject: RFR: 8357672: Extreme font sizes can cause font substitution In-Reply-To: References: Message-ID: On Wed, 28 May 2025 20:19:42 GMT, Phil Race wrote: > Instrumenting the existing ExtremeFontSizeTest.java, it was noted that the freetype code, when encountering a null return from getting a scaler context, would over-interpret this as a bad font. > The test was intended to check this wasn't happening by verifying metrics before and after using extreme sizes. > But the scenaro was not being detected by the test because a replacement font was substituted and it did not have zero metrics. > So the updated test checks that the metrics before and after are the same. > This new version of the test failed on Linux before the JDK source updates and passes afterwards. Apart from the added query, Change LGTM. test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java line 39: > 37: /* > 38: * @test > 39: * @bug 8328896 8357672 I thought Freetype rasterizer is used on all platforms(Linux, Windows & macOS) by default. Since Freetype is part of JDK. When i run this test on macOS without any updates from this PR on baseline code, i see that all Fontmetrics in System.out() are non-zero and match before and after extreme parameters. Is this behaviour okay? I was expecting mismatch in FontMetrics on macOS also. If this test is supposed to catch issues on particular platforms. Do we need to make it specific to some platforms? ------------- Marked as reviewed by jdv (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25511#pullrequestreview-2887934023 PR Review Comment: https://git.openjdk.org/jdk/pull/25511#discussion_r2120839304 From prr at openjdk.org Mon Jun 2 15:07:54 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 2 Jun 2025 15:07:54 GMT Subject: RFR: 8357672: Extreme font sizes can cause font substitution In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 11:19:48 GMT, Jayathirth D V wrote: >> Instrumenting the existing ExtremeFontSizeTest.java, it was noted that the freetype code, when encountering a null return from getting a scaler context, would over-interpret this as a bad font. >> The test was intended to check this wasn't happening by verifying metrics before and after using extreme sizes. >> But the scenaro was not being detected by the test because a replacement font was substituted and it did not have zero metrics. >> So the updated test checks that the metrics before and after are the same. >> This new version of the test failed on Linux before the JDK source updates and passes afterwards. > > test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java line 39: > >> 37: /* >> 38: * @test >> 39: * @bug 8328896 8357672 > > I thought Freetype rasterizer is used on all platforms(Linux, Windows & macOS) by default. Since Freetype is part of JDK. > > When i run this test on macOS without any updates from this PR on baseline code, i see that all Fontmetrics in System.out() are non-zero and match before and after extreme parameters. Is this behaviour okay? > > I was expecting mismatch in FontMetrics on macOS also. > If this test is supposed to catch issues on particular platforms. Do we need to make it specific to some platforms? On mac, freetype is only used in a few cases - Type1 fonts and Font.loadFont. The test is not Linux-specific, nor should it be constrained to Linux, the behaviour it validates applies to all platforms. And if you look at the PR that introduced this test, it did update macOS and the test did identify issues on macOS. So in short, no changes needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25511#discussion_r2121443937 From jdv at openjdk.org Mon Jun 2 15:19:58 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 2 Jun 2025 15:19:58 GMT Subject: RFR: 8357672: Extreme font sizes can cause font substitution In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 15:05:44 GMT, Phil Race wrote: >> test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java line 39: >> >>> 37: /* >>> 38: * @test >>> 39: * @bug 8328896 8357672 >> >> I thought Freetype rasterizer is used on all platforms(Linux, Windows & macOS) by default. Since Freetype is part of JDK. >> >> When i run this test on macOS without any updates from this PR on baseline code, i see that all Fontmetrics in System.out() are non-zero and match before and after extreme parameters. Is this behaviour okay? >> >> I was expecting mismatch in FontMetrics on macOS also. >> If this test is supposed to catch issues on particular platforms. Do we need to make it specific to some platforms? > > On mac, freetype is only used in a few cases - Type1 fonts and Font.loadFont. > The test is not Linux-specific, nor should it be constrained to Linux, the behaviour it validates applies to all platforms. > And if you look at the PR that introduced this test, it did update macOS and the test did identify issues on macOS. > > So in short, no changes needed. Thanks for the clarifications. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25511#discussion_r2121477508 From prr at openjdk.org Mon Jun 2 15:26:56 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 2 Jun 2025 15:26:56 GMT Subject: Integrated: 8357672: Extreme font sizes can cause font substitution In-Reply-To: References: Message-ID: <3QaAY3ebh381WfXnqOP4BjETwhVKEUqrBoB1P5FgJhY=.ca6b108d-4a96-4c7b-a00f-0c6551c59235@github.com> On Wed, 28 May 2025 20:19:42 GMT, Phil Race wrote: > Instrumenting the existing ExtremeFontSizeTest.java, it was noted that the freetype code, when encountering a null return from getting a scaler context, would over-interpret this as a bad font. > The test was intended to check this wasn't happening by verifying metrics before and after using extreme sizes. > But the scenaro was not being detected by the test because a replacement font was substituted and it did not have zero metrics. > So the updated test checks that the metrics before and after are the same. > This new version of the test failed on Linux before the JDK source updates and passes afterwards. This pull request has now been integrated. Changeset: a4eb1519 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/a4eb15195ceeadf311fe81e622a54f4733b90df2 Stats: 104 lines in 3 files changed: 92 ins; 2 del; 10 mod 8357672: Extreme font sizes can cause font substitution Reviewed-by: dmarkov, jdv ------------- PR: https://git.openjdk.org/jdk/pull/25511 From prr at openjdk.org Mon Jun 2 15:33:52 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 2 Jun 2025 15:33:52 GMT Subject: RFR: 8357696: Enhance code consistency: java.desktop/unix [v3] In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 02:27:50 GMT, Sergey Bylokhov wrote: >> This is a request to update the remaining parts of the java.desktop/unix package. >> The sun.awt subpackage under java.desktop/unix was previously addressed by https://github.com/openjdk/jdk/pull/24941. >> >> ==================================================== >> >> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency. >> >> The public API was not affected so there is no need to worry about a CSR >> >> Note: I will submit additional patches in this area later because: >> >> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797)) >> 2. I skipped adding `@Override` for anonymous classes >> >> Any feedback or suggestions are welcome! >> >> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff) to a simple diff file, it might be more convenient for reviewing the changes. >> >> To download the diff file and filter only the modified lines you can use the following script: >> >> >> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff -o d.txt && grep -E '^+|^-' d.txt >> >> >> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > fix merge I re-tested. All OK ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25439#pullrequestreview-2888960033 From achung at openjdk.org Mon Jun 2 16:55:07 2025 From: achung at openjdk.org (Alisen Chung) Date: Mon, 2 Jun 2025 16:55:07 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v4] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Thu, 29 May 2025 17:11:12 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Add headful key to the jtreg description src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java line 113: > 111: @Override > 112: public native void openClipboard(SunClipboard newOwner) throws IllegalStateException; > 113: /** was this comment accidentally deleted? test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 31: > 29: @run main ConcurrentClipboardAccessTest > 30: */ > 31: import java.awt.*; expand imports test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 58: > 56: public void run() { > 57: final Clipboard systemClipboard = Toolkit.getDefaultToolkit().getSystemClipboard(); > 58: while (true) { will this cause the test to run until timeout if the thread isn't interrupted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2121623003 PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2121693977 PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2121693822 From duke at openjdk.org Mon Jun 2 16:57:14 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 2 Jun 2025 16:57:14 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v6] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI, but the AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: - 8354646: remove redundant code in SynthPasswordFieldUI This is partially in response to: https://github.com/openjdk/jdk/pull/25443#issuecomment-2929752779 - 8354646: skip test for unexpected text field UI's Also I confirmed this test passes for Nimbus This is partially in response to: https://github.com/openjdk/jdk/pull/25443#issuecomment-2929752779 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/fe1b781c..0c299471 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=04-05 Stats: 21 lines in 2 files changed: 6 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Mon Jun 2 17:28:55 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 2 Jun 2025 17:28:55 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v5] In-Reply-To: <7C_922gw6YyrITP7jNbscW8Us16vSv6B3GKMvFs_XYE=.fca6f4f3-a101-4fcb-b032-e7934f82ac50@github.com> References: <9OsgP7Nt-I4n_uqYEzVaNAbp-3rYf4ozSFmiWyDoF5Q=.5dc3cbc6-942d-490b-b086-c9803c92ee14@github.com> <7C_922gw6YyrITP7jNbscW8Us16vSv6B3GKMvFs_XYE=.fca6f4f3-a101-4fcb-b032-e7934f82ac50@github.com> Message-ID: On Mon, 2 Jun 2025 09:52:04 GMT, Prasanta Sadhukhan wrote: > Does the accompanying testcase fails in Synth/Nimbus L&F, it seems not? No. I double-checked: A. If I explicitly set the L&F to Nimbus: this test does fail in this PR, and it does not fail in master. B. The SynthPasswordFieldUI descends from BasicTextUI, so it should not be impacted by this PR. ... and in reviewing the SynthPasswordFieldUI I found the same code (copied & pasted) from BasicPasswordFieldUI. I removed that, because with this PR it should not be necessary. (And I did NOT find other instances of the same code copied and pasted anywhere else.) > Also, it will be useful to extend the test case to test all installed L&F since it it changing Basic L&F code? I'm not sure what you're asking here. I tweaked the test so it aborts if it is NOT interacting with a BasicTextUI. (Off the top of my head I don't know of any JPasswordField UI's that don't subclass BasicTextUI, but they might exist somewhere.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2931693256 From duke at openjdk.org Mon Jun 2 17:31:53 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 2 Jun 2025 17:31:53 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v6] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 16:57:14 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: > > - 8354646: remove redundant code in SynthPasswordFieldUI > > This is partially in response to: > https://github.com/openjdk/jdk/pull/25443#issuecomment-2929752779 > - 8354646: skip test for unexpected text field UI's > > Also I confirmed this test passes for Nimbus > > This is partially in response to: > https://github.com/openjdk/jdk/pull/25443#issuecomment-2929752779 src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 665: > 663: } > 664: > 665: return map; This PR could produce weird results if anyone tried applying a BasicPasswordFieldUI (or SynthPasswordFieldUI or AquaTextPasswordFieldUI ) to a JTextField that is NOT a JPasswordField. Do we care about that use case? (If we do: then we could simply copy and paste the same known solution into AquaTextPasswordFieldUI ? That would make this PR less invasive, but it would involve more copied and pasted code.) Or instead of relying on `instanceof JPasswordField` would rely on `"PasswordField".equals(getPropertyPrefix()`. If anyone has any strong feelings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2121762115 From abhiscxk at openjdk.org Mon Jun 2 17:50:53 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 2 Jun 2025 17:50:53 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v8] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Mon, 2 Jun 2025 09:33:34 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Removes unnecessary lines and keep consistent code format LGTM ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2889406132 From serb at openjdk.org Mon Jun 2 18:47:00 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 2 Jun 2025 18:47:00 GMT Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java [v5] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 00:40:11 GMT, Harshitha Onkar wrote: >> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs. >> >> Test failure is not reproducible when the test is run individually (multiple times) on CI. >> >> Rewritten the test and added debug logs that will be helpful to figure out the issue. >> >> - Added code to capture screenshot (entire screen as well as the frame) in case of failure. >> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added testRegion back to paint() test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 84: > 82: } > 83: } finally { > 84: EventQueue.invokeAndWait(frame::dispose); you do not need to call it on EDT ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2121915015 From honkar at openjdk.org Mon Jun 2 19:16:43 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 19:16:43 GMT Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java [v6] In-Reply-To: References: Message-ID: > CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs. > > Test failure is not reproducible when the test is run individually (multiple times) on CI. > > Rewritten the test and added debug logs that will be helpful to figure out the issue. > > - Added code to capture screenshot (entire screen as well as the frame) in case of failure. > - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: frame dispose ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25279/files - new: https://git.openjdk.org/jdk/pull/25279/files/e9c5b3ac..7c288c91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=04-05 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25279.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25279/head:pull/25279 PR: https://git.openjdk.org/jdk/pull/25279 From honkar at openjdk.org Mon Jun 2 19:16:43 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 19:16:43 GMT Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java [v6] In-Reply-To: <1oCpyW01HIgsdailQXTvgyOi3EwZCpQvqvd6dMcYxzE=.958c3237-4786-4189-86d1-daf317d9e041@github.com> References: <-lBIVrQXyxII4hEx6bRTJaM9dtFYWTgu7ULBFS-5kOQ=.a653a92e-702d-48d2-b6fa-50d134d4996d@github.com> <1oCpyW01HIgsdailQXTvgyOi3EwZCpQvqvd6dMcYxzE=.958c3237-4786-4189-86d1-daf317d9e041@github.com> Message-ID: On Sat, 31 May 2025 00:59:49 GMT, Sergey Bylokhov wrote: >> @mrserb >> >> Added back Toolkit.sync() and canvas capture to paint method. Although I'm not sure if I understood _"each render frame"_ correctly. Can you please explain? >> >> >> BufferedImage capture = null; >> try { >> Thread.sleep(500); >> if (robot == null) robot = new Robot(); >> Point pt1 = getLocationOnScreen(); >> Rectangle rect = new Rectangle(pt1.x, pt1.y, 400, 400); >> capture = robot.createScreenCapture(rect); >> } catch (Exception e) { >> throw new RuntimeException("Problems handling Robot"); >> } >> // Test pixels >> testRegion(capture, "green", 0, 0, 400, 10, 0xff00ff00); >> testRegion(capture, "original red", 0, 10, 50, 400, 0xffff0000); >> testRegion(capture, "background", 50, 10, 60, 400, 0xff000000); >> testRegion(capture, "in-between", 60, 10, 110, 20, 0xff000000); >> testRegion(capture, "copied red", 60, 20, 110, 400, 0xffff0000); >> testRegion(capture, "background", 110, 10, 400, 400, 0xff000000); >> >> >> Isn't capture going to be the same image throughout? I'm not sure why it is passed as an extra argument to testRegion. It can be saved once as static BufferedImage var and the same can be used for testing or am I missing something? > >> Added back Toolkit.sync() and canvas capture to paint method. Although I'm not sure if I understood _"each render frame"_ correctly. Can you please explain? > > The paint method may be invoked multiple times after the frame becomes visible, so the validation logic inside paint will be executed for each rendering data. oh okay, although when I debug I don't see paint method being called multiple times. Probably the case when frame is resized or screen configuration changes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2121957234 From honkar at openjdk.org Mon Jun 2 19:16:44 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 19:16:44 GMT Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java [v5] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 18:44:40 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> added testRegion back to paint() > > test/jdk/java/awt/Graphics2D/CopyAreaOOB.java line 84: > >> 82: } >> 83: } finally { >> 84: EventQueue.invokeAndWait(frame::dispose); > > you do not need to call it on EDT Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2121952850 From honkar at openjdk.org Mon Jun 2 19:19:51 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 19:19:51 GMT Subject: RFR: 8358057: Update validation of ICC_Profile header data [v3] In-Reply-To: References: Message-ID: On Sat, 31 May 2025 04:21:41 GMT, Sergey Bylokhov wrote: >> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ValidateICCHeaderData.java > > test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData/ValidateICCHeaderData.java line 27: > >> 25: * @test >> 26: * @bug 8337703 8347377 8358057 >> 27: * @summary To verify if ICC_Profile's setData() and getInstance() methods > > I have added 8347377 where this test was added and 8358057 for the current issue. @honkar-jdk I cannot access the 8337703 is it a "closed bug" or it is a typo and we can drop that id? We can drop 8337703 and retain just the other two - 8347377 8358057. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25519#discussion_r2121877614 From serb at openjdk.org Mon Jun 2 19:28:09 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 2 Jun 2025 19:28:09 GMT Subject: RFR: 8358057: Update validation of ICC_Profile header data [v4] In-Reply-To: References: Message-ID: > The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class: > - getProfileClass(byte[]) > - getColorSpaceType(byte[]) > - getPCSType(byte[]) > - checkRenderingIntent(byte[]) > > These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()). > > It is possible to update implementation: > - The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods. > - The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs > > Tests: > - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent > - New RenderingIntentStressTest test is added to check the next part of the icc_spec: > > * ICC spec: only the least-significant 16 bits encode the rendering > * intent. The most significant 16 bits must be zero and can be ignored. > * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15. > > > > @honkar-jdk please take a look. > > Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately. Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: drop 8337703 bugid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25519/files - new: https://git.openjdk.org/jdk/pull/25519/files/43b88ff3..55d0fe2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25519&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25519&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25519.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25519/head:pull/25519 PR: https://git.openjdk.org/jdk/pull/25519 From serb at openjdk.org Mon Jun 2 20:11:57 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 2 Jun 2025 20:11:57 GMT Subject: RFR: 8356594: JSplitPane loses divider location when reopened via JOptionPane.createDialog() [v5] In-Reply-To: References: Message-ID: <_AB2rrf_fWKD7K1TnDbYwxKUv3FpyqJ4cWzsG8AF6nw=.d3e61c40-67d9-437d-ba30-1b121fb644de@github.com> On Wed, 28 May 2025 03:21:45 GMT, Prasanta Sadhukhan wrote: >> The issue is when a JSplitPane is embedded inside a lazily-initialized panel, and this panel is displayed using a dialog created via JOptionPane.createDialog(), the divider location is not preserved when reopening the dialog. >> This is because when we added support for ComponentOrientation for JSplitPane, even though the left and right compoent is drawn the divider location is not set and was set to initial value and not to the value set by user. >> Fixed by setting the divider location before rendering the left and right components.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Store current orientation for check You need to clarify and verify a few things: - When should the notification be sent? Currently, we fire the event before completing the orientation swap. Would not it make more sense to do this after all components have been added/removed? - What should happen if the application explicitly calls setComponentOrientation() to change the orientation? In this case, how should we handle the divider location?: 1. Reset the divider to its default position. 2. Reflect/mirror the divider location based on the new orientation. 3. Preserve the current divider position as-is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25294#issuecomment-2932307305 From serb at openjdk.org Mon Jun 2 20:25:57 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 2 Jun 2025 20:25:57 GMT Subject: Integrated: 8357696: Enhance code consistency: java.desktop/unix In-Reply-To: References: Message-ID: On Mon, 26 May 2025 03:10:07 GMT, Sergey Bylokhov wrote: > This is a request to update the remaining parts of the java.desktop/unix package. > The sun.awt subpackage under java.desktop/unix was previously addressed by https://github.com/openjdk/jdk/pull/24941. > > ==================================================== > > The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency. > > The public API was not affected so there is no need to worry about a CSR > > Note: I will submit additional patches in this area later because: > > 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797)) > 2. I skipped adding `@Override` for anonymous classes > > Any feedback or suggestions are welcome! > > Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff) to a simple diff file, it might be more convenient for reviewing the changes. > > To download the diff file and filter only the modified lines you can use the following script: > > > curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25439.diff -o d.txt && grep -E '^+|^-' d.txt > > > The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected. This pull request has now been integrated. Changeset: 0418b329 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/0418b3295a199af66700521f571c9b2c1051cac6 Stats: 391 lines in 64 files changed: 295 ins; 0 del; 96 mod 8357696: Enhance code consistency: java.desktop/unix Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/25439 From honkar at openjdk.org Mon Jun 2 20:53:59 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 20:53:59 GMT Subject: RFR: 8358057: Update validation of ICC_Profile header data [v4] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 19:28:09 GMT, Sergey Bylokhov wrote: >> The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class: >> - getProfileClass(byte[]) >> - getColorSpaceType(byte[]) >> - getPCSType(byte[]) >> - checkRenderingIntent(byte[]) >> >> These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()). >> >> It is possible to update implementation: >> - The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods. >> - The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs >> >> Tests: >> - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent >> - New RenderingIntentStressTest test is added to check the next part of the icc_spec: >> >> * ICC spec: only the least-significant 16 bits encode the rendering >> * intent. The most significant 16 bits must be zero and can be ignored. >> * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15. >> >> >> >> @honkar-jdk please take a look. >> >> Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately. > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > drop 8337703 bugid LGTM CI Testing looks good. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25519#pullrequestreview-2889900412 From honkar at openjdk.org Mon Jun 2 20:57:11 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 20:57:11 GMT Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java [v7] In-Reply-To: References: Message-ID: > CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs. > > Test failure is not reproducible when the test is run individually (multiple times) on CI. > > Rewritten the test and added debug logs that will be helpful to figure out the issue. > > - Added code to capture screenshot (entire screen as well as the frame) in case of failure. > - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25279/files - new: https://git.openjdk.org/jdk/pull/25279/files/7c288c91..f42399ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25279&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25279.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25279/head:pull/25279 PR: https://git.openjdk.org/jdk/pull/25279 From serb at openjdk.org Mon Jun 2 20:57:11 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 2 Jun 2025 20:57:11 GMT Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java [v7] In-Reply-To: References: Message-ID: On Mon, 2 Jun 2025 20:53:59 GMT, Harshitha Onkar wrote: >> CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs. >> >> Test failure is not reproducible when the test is run individually (multiple times) on CI. >> >> Rewritten the test and added debug logs that will be helpful to figure out the issue. >> >> - Added code to capture screenshot (entire screen as well as the frame) in case of failure. >> - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > unused import Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25279#pullrequestreview-2889904297 From serb at openjdk.org Mon Jun 2 20:57:11 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 2 Jun 2025 20:57:11 GMT Subject: RFR: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java [v7] In-Reply-To: References: <-lBIVrQXyxII4hEx6bRTJaM9dtFYWTgu7ULBFS-5kOQ=.a653a92e-702d-48d2-b6fa-50d134d4996d@github.com> <1oCpyW01HIgsdailQXTvgyOi3EwZCpQvqvd6dMcYxzE=.958c3237-4786-4189-86d1-daf317d9e041@github.com> Message-ID: <-7VR9nqdbKYvXD-MwGBszvg2OaiqmW0NlCb4apbUaUE=.3abe21c7-7375-41e3-9c4c-af423e32f7b6@github.com> On Mon, 2 Jun 2025 19:11:12 GMT, Harshitha Onkar wrote: >>> Added back Toolkit.sync() and canvas capture to paint method. Although I'm not sure if I understood _"each render frame"_ correctly. Can you please explain? >> >> The paint method may be invoked multiple times after the frame becomes visible, so the validation logic inside paint will be executed for each rendering data. > > oh okay, although when I debug I don't see paint method being called multiple times. Probably the case when frame is resized or screen configuration changes? Yes, and validation of each frame will confirm no garbage on the screen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25279#discussion_r2122130577 From honkar at openjdk.org Mon Jun 2 21:40:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 21:40:50 GMT Subject: RFR: 8356803: Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance In-Reply-To: References: Message-ID: On Fri, 30 May 2025 23:40:22 GMT, Daniel Gredler wrote: > Per discussion in JBS, adds the following chars to the list of ignorable whitespace chars: U+000B (Vertical Tab), U+000C (Form Feed), U+0085 (Next Line), U+2028 (Line Separator), U+2029 (Paragraph Separator). > > Adds the necessary testing in pre-existing automated test class `test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java`. > > Removes now-unnecessary manual test `test/jdk/java/awt/font/TextLayout/TestControls.java`. > > The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS. Tested the fix. It looks good to me. Not sure of the reason behind @aivanov-jdk suggestion in [JDK-8356812](https://bugs.openjdk.org/browse/JDK-8356812) to keep the manual test alongside the automated test. I'm okay with deleting the manual test since the automated one covers all the cases. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25560#pullrequestreview-2890009923 From honkar at openjdk.org Mon Jun 2 21:54:58 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Jun 2025 21:54:58 GMT Subject: Integrated: JDK-8357082 : Stabilize and add debug logs to CopyAreaOOB.java In-Reply-To: References: Message-ID: On Sat, 17 May 2025 00:03:23 GMT, Harshitha Onkar wrote: > CopyAreaOOB.java was failing intermittently on some platforms on CI but recently it started to fail more frequently on macos-aarch64 when the entire test suite runs. > > Test failure is not reproducible when the test is run individually (multiple times) on CI. > > Rewritten the test and added debug logs that will be helpful to figure out the issue. > > - Added code to capture screenshot (entire screen as well as the frame) in case of failure. > - Since it tests multiple regions added a StringBuffer to consolidate the error logs before throwing RuntimeException. This pull request has now been integrated. Changeset: e490b4f0 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/e490b4f04dd094db996cdc4f664c2ed1a7ea2ade Stats: 113 lines in 2 files changed: 63 ins; 10 del; 40 mod 8357082: Stabilize and add debug logs to CopyAreaOOB.java Reviewed-by: serb ------------- PR: https://git.openjdk.org/jdk/pull/25279 From dnguyen at openjdk.org Mon Jun 2 22:27:57 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 2 Jun 2025 22:27:57 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v3] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com> Message-ID: On Thu, 29 May 2025 17:13:51 GMT, Matthias Bl?sing wrote: >> src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java line 189: >> >>> 187: checkChange(formats); >>> 188: } catch (Throwable ex) { >>> 189: System.getLogger(WClipboard.class.getName()).log(Level.WARNING, "Failed to process handleContentsChanged", ex); >> >> I'm not saying not to necessarily change this, but what are we hoping to see with logging this warning here? > > The idea here is to not silently swallow exceptions. This code is called from `AwtToolkit::WndProc`, which from my reading will not report exceptions/throwables. Pushing the exception to the system logger gives a chance to detect problems here. Sounds reasonable but loggers don't seem to be used in `src` files as far as I can tell. They are used in tests to help detect issues as you mentioned, and I can find plenty of occurrences of loggers used in the `test` directory of the open JDK but I don't see any in `src`. Makes me think there's an alternative way to handle this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2122265091 From kizune at openjdk.org Tue Jun 3 03:30:51 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 3 Jun 2025 03:30:51 GMT Subject: RFR: 8357688: Remove unnecessary List.get before remove in PopupFactory In-Reply-To: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com> References: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com> Message-ID: On Sat, 17 May 2025 07:42:59 GMT, Andrey Turbanov wrote: > Instead of separate List.get+List.remove calls we can use single `removeFirst`. It's clearer. LGTM ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25283#pullrequestreview-2890481592 From azvegint at openjdk.org Tue Jun 3 03:44:19 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 3 Jun 2025 03:44:19 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) Message-ID: After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. ------------- Commit messages: - 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) Changes: https://git.openjdk.org/jdk/pull/25605/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25605&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358452 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25605/head:pull/25605 PR: https://git.openjdk.org/jdk/pull/25605 From azvegint at openjdk.org Tue Jun 3 03:58:55 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 3 Jun 2025 03:58:55 GMT Subject: RFR: 8347826: Introspector shows wrong method list after 8071693 [v16] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 11:20:39 GMT, Roman Marchenko wrote: >> Fixed `com.sun.beans.introspect.MethodInfo` and `com.sun.beans.introspect.PropertyInfo` to make `Introspector.addMethod()` working properly when filtering methods out. >> >> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java. >> >> --------- >> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses. >> >> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows: >> >> - In case of a clash with a class method, the class version will take precedence rather than interface's one. >> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected. >> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned. >> >> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter: >> >> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence. >> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen). >> * Gettters/setters declared and not implemented are not considered. > > Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: > > minor change Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23443#pullrequestreview-2890526841 From duke at openjdk.org Tue Jun 3 05:43:56 2025 From: duke at openjdk.org (duke) Date: Tue, 3 Jun 2025 05:43:56 GMT Subject: RFR: 8347826: Introspector shows wrong method list after 8071693 [v16] In-Reply-To: References: Message-ID: On Fri, 30 May 2025 11:20:39 GMT, Roman Marchenko wrote: >> Fixed `com.sun.beans.introspect.MethodInfo` and `com.sun.beans.introspect.PropertyInfo` to make `Introspector.addMethod()` working properly when filtering methods out. >> >> Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java. >> >> --------- >> `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses. >> >> When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows: >> >> - In case of a clash with a class method, the class version will take precedence rather than interface's one. >> - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected. >> - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned. >> >> `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter: >> >> * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence. >> * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen). >> * Gettters/setters declared and not implemented are not considered. > > Roman Marchenko has updated the pull request incrementally with one additional commit since the last revision: > > minor change @wkia Your change (at version 8d46a88d6d3b47484cccd587df83df1add67b4ae) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23443#issuecomment-2933545793 From psadhukhan at openjdk.org Tue Jun 3 05:46:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 3 Jun 2025 05:46:52 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v5] In-Reply-To: References: <9OsgP7Nt-I4n_uqYEzVaNAbp-3rYf4ozSFmiWyDoF5Q=.5dc3cbc6-942d-490b-b086-c9803c92ee14@github.com> <7C_922gw6YyrITP7jNbscW8Us16vSv6B3GKMvFs_XYE=.fca6f4f3-a101-4fcb-b032-e7934f82ac50@github.com> Message-ID: On Mon, 2 Jun 2025 17:26:23 GMT, Jeremy Wood wrote: > > Does the accompanying testcase fails in Synth/Nimbus L&F, it seems not? > > No. I double-checked: A. If I explicitly set the L&F to Nimbus: this test does fail in this PR, and it does not fail in master. B. The SynthPasswordFieldUI descends from BasicTextUI, so it should not be impacted by this PR. Since you mentioned at the beginning that` AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution`. so I assumed the regression testcase should fail in Aqua and Nimbus wiithout your fix but it fails in Aqua and not in Nimbus so I asked. It seems you have modified your initial PR description to NOT include Synth now so it means the problem exists only in Aqua L&F in JDK mainline, am i correct? > > Also, it will be useful to extend the test case to test all installed L&F since it it changing Basic L&F code? > > I'm not sure what you're asking here. I meant the present regression testcase only tests the system L&F of the platform it is run ie Metal in WIndows, Linux and Aqua in Mac and does not test all L&Fs like Nimbus, Motif, WIndows, GTK so you should check for `UIManager.getInstalledLookAndFeels() `and iterate and test all the installed L&Fs of the current platform..You will find many such example of the L&F testing in `test/javax/swing` folder ------------- PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2933556752 From rmarchenko at openjdk.org Tue Jun 3 06:03:01 2025 From: rmarchenko at openjdk.org (Roman Marchenko) Date: Tue, 3 Jun 2025 06:03:01 GMT Subject: Integrated: 8347826: Introspector shows wrong method list after 8071693 In-Reply-To: References: Message-ID: On Tue, 4 Feb 2025 16:14:44 GMT, Roman Marchenko wrote: > Fixed `com.sun.beans.introspect.MethodInfo` and `com.sun.beans.introspect.PropertyInfo` to make `Introspector.addMethod()` working properly when filtering methods out. > > Also, after PR discussion, added the approptiate test cases with corresponding fixes in MethodInfo.java and PropertyInfo.java. > > --------- > `getMethodDescriptors()` returns descriptors of public methods of a class and its parent classes, including default and static methods defined in interfaces. The result doesn't include methods which were declared and not implemented, bridge methods, or methods which were overriden in subclasses. > > When a subclass "overrides" a static method from a parent class `getMethodDescriptors()` behaves as follows: > > - In case of a clash with a class method, the class version will take precedence rather than interface's one. > - If the same method appears in multiple classes/interfaces within the same hierarchy, the version from the most specific sub-interface will be selected. > - If the method appears in classes/interfaces from different hierarchies, the result is undefined, either version can be returned. > > `getPropertyDescriptors()` returns descriptors of methods which were identified as getters or setters. As there can be the only method getter/setter per property, the following rules are applied when choosing a getter/setter: > > * Getters/setters for the same property defined (not necessarily overriden) in subclasses have higher precedence. > * If there are getters/setters for the same property defined in the same class and argument types are assignable one to another, the method with the Least Common Supertype has the lower priority. If argument types are not assignable, the result is undefined (any method will be chosen). > * Gettters/setters declared and not implemented are not considered. This pull request has now been integrated. Changeset: c5f235c0 Author: Roman Marchenko Committer: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/c5f235c000db6654493ea109008dbccf97f01678 Stats: 455 lines in 4 files changed: 398 ins; 8 del; 49 mod 8347826: Introspector shows wrong method list after 8071693 Reviewed-by: azvegint, serb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/23443 From psadhukhan at openjdk.org Tue Jun 3 07:00:58 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 3 Jun 2025 07:00:58 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out In-Reply-To: References: Message-ID: <-VMpAEScXud5FONRrlVj3yi5_Q_hNt7o_jMYW0PbqoQ=.55896ef7-a9d5-4bf1-ba7f-edcac5ced621@github.com> On Wed, 28 May 2025 10:29:17 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. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 742: > 740: private Rectangle2D getPageFormatArea(PageFormat page, double scaleX, double scaleY) { > 741: Rectangle2D.Double pageFormatArea; > 742: if (scaleX != 1 && scaleY != 1) { BTW, Do we need this check as if scaleX=scaleY=1 then also no issue in doing multiplying with 1 ie scaleX and scaleY and if one of them is not 1 then we need to multiply anyway..so it seems this check is not needed?!! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2122900262 From tr at openjdk.org Tue Jun 3 07:11:02 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 3 Jun 2025 07:11:02 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 19:48:35 GMT, Phil Race wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct the title of the test frames > > test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 128: > >> 126: jfc.setControlButtonsAreShown(false); >> 127: >> 128: JFrame frame = new JFrame((!htmlEnabled) ? "HTML enabled" : "HTML disabled"); > > I think this stems from a conflict in the name of the property (html.disable) and the variable (htmlEnabled) > I suggest to rename the variable to htmlDisabled and re-organise the constructor line to > JFrame frame = new JFrame((htmlDisabled) ? "HTML disabled" : "HTML enabled"); Yes, I agree to this point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2122922480 From tr at openjdk.org Tue Jun 3 07:18:54 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 3 Jun 2025 07:18:54 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:18:06 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Correct the title of the test frames test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 56: > 54:
    > 55:
  1. JFileChooser shows a virtual directory. > 56: The first file in the list has the following name: Here, we should mention that the directory name and first file name is ``` <html><h1 color=#ff00ff><font face="Comic Sans MS">Swing Rocks! ```. The directory name helps us to verify the name on `combobox` area in some L&F (Like aqua) and file name helps us to verify in `filepane` (In some L&F). test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 57: > 55:
  2. JFileChooser shows a virtual directory. > 56: The first file in the list has the following name: > 57: <html><h1 color=#ff00ff><font Should the file name be within `` tag or just `""` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2122940439 PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2122942906 From avu at openjdk.org Tue Jun 3 08:24:52 2025 From: avu at openjdk.org (Alexey Ushakov) Date: Tue, 3 Jun 2025 08:24:52 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 03:39:31 GMT, Alexander Zvegintsev wrote: > After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. LGTM ------------- Marked as reviewed by avu (Committer). PR Review: https://git.openjdk.org/jdk/pull/25605#pullrequestreview-2891255639 From psadhukhan at openjdk.org Tue Jun 3 08:37:56 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 3 Jun 2025 08:37:56 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 03:39:31 GMT, Alexander Zvegintsev wrote: > After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1209: > 1207: AWT_UNLOCK(); > 1208: > 1209: if (key == NoSymbol || (*env)->ExceptionCheck(env)) { I guess we normally call ExceptionCheck after we call some JNI methods like (*env)->NewString or (*env)->CallObjectMethod. Here before this check we are not calling any JNI method so I think we should do it after we call (*env)->GetStringUTFChars ie. after l1214 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2123135632 From dgredler at openjdk.org Tue Jun 3 09:40:53 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 3 Jun 2025 09:40:53 GMT Subject: RFR: 8356803: Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance In-Reply-To: References: Message-ID: On Fri, 30 May 2025 23:40:22 GMT, Daniel Gredler wrote: > Per discussion in JBS, adds the following chars to the list of ignorable whitespace chars: U+000B (Vertical Tab), U+000C (Form Feed), U+0085 (Next Line), U+2028 (Line Separator), U+2029 (Paragraph Separator). > > Adds the necessary testing in pre-existing automated test class `test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java`. > > Removes now-unnecessary manual test `test/jdk/java/awt/font/TextLayout/TestControls.java`. > > The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS. @aivanov-jdk Let me know if there are any concerns on your end. Otherwise, I plan to mark as ready for integration later today. As @honkar-jdk mentioned, the automated test is checking much more than the manual test was (and won't bitrot as easily), so I don't think there's a reason to keep the manual test around. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25560#issuecomment-2934383570 From azvegint at openjdk.org Tue Jun 3 12:16:56 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 3 Jun 2025 12:16:56 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 08:35:40 GMT, Prasanta Sadhukhan wrote: > we are not calling any JNI method We have the `AWT_LOCK()` / `AWT_UNLOCK();` macro expansions with JNI methods being called. https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L97-L110 This is exactly what static code analysis tool complains about. >JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2123634413 From psadhukhan at openjdk.org Tue Jun 3 12:31:54 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 3 Jun 2025 12:31:54 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 12:14:23 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 1209: >> >>> 1207: AWT_UNLOCK(); >>> 1208: >>> 1209: if (key == NoSymbol || (*env)->ExceptionCheck(env)) { >> >> I guess we normally call ExceptionCheck after we call some JNI methods like (*env)->NewString or (*env)->CallObjectMethod. Here before this check we are not calling any JNI method so I think we should do it after we call (*env)->GetStringUTFChars ie. after l1214 > >> we are not calling any JNI method > > We have the `AWT_LOCK()` / `AWT_UNLOCK();` macro expansions with JNI methods being called. > > https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L97-L110 > > This is exactly what static code analysis tool complains about. > >>JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 But we are calling ExceptionCheck in that macro in l104 so why do we again need to call? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2123668284 From azvegint at openjdk.org Tue Jun 3 13:25:51 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 3 Jun 2025 13:25:51 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 12:29:42 GMT, Prasanta Sadhukhan wrote: >>> we are not calling any JNI method >> >> We have the `AWT_LOCK()` / `AWT_UNLOCK();` macro expansions with JNI methods being called. >> >> https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L97-L110 >> >> This is exactly what static code analysis tool complains about. >> >>>JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 > > But we are calling ExceptionCheck in that macro in l104 so why do we again need to call? Please note the line 108 of the awt.h ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2123802031 From psadhukhan at openjdk.org Tue Jun 3 13:38:53 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 3 Jun 2025 13:38:53 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 13:23:27 GMT, Alexander Zvegintsev wrote: >> But we are calling ExceptionCheck in that macro in l104 so why do we again need to call? > > Please note the line 108 of the awt.h But then it should show JNI exception pending for all places where we call AWT_UNLOCK, why only this place? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2123845376 From azvegint at openjdk.org Tue Jun 3 14:07:52 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 3 Jun 2025 14:07:52 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 13:36:07 GMT, Prasanta Sadhukhan wrote: >> Please note the line 108 of the awt.h > > But then it should show JNI exception pending for all places where we call AWT_UNLOCK, why only this place? This is not the only place. Other cases are also covered by checking for pending exceptions or by returning to Java. If not, the code analysis tool may not detect it for some reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2123938059 From abaya at openjdk.org Tue Jun 3 15:55:44 2025 From: abaya at openjdk.org (Anass Baya) Date: Tue, 3 Jun 2025 15:55:44 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable Message-ID: **Analysis:** We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). The race condition between the execution paths of these two native methods sometimes causes an exception **Proposed Fix:** While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number public void updateGC() { int scrn = getScreenImOn(); if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { log.finer("Screen number: " + scrn); } // get current GD Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); Win32GraphicsDevice newDev; GraphicsDevice[] devs = GraphicsEnvironment .getLocalGraphicsEnvironment() .getScreenDevices(); // Occasionally during device addition/removal getScreenImOn can return // a non-existing screen number. Use the default device in this case. if (scrn >= devs.length) { newDev = (Win32GraphicsDevice) GraphicsEnvironment .getLocalGraphicsEnvironment().getDefaultScreenDevice(); } else { newDev = (Win32GraphicsDevice) devs[scrn]; } } Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : jint AwtWindow::_GetScreenImOn(void *param) { ... jboolean destroyed = JNI_GET_DESTROYED(self); if (destroyed == JNI_TRUE){ env->DeleteGlobalRef(self); return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); } ... **Tests Summary:** GetGraphicsStressTest (existing test): Fails intermittently without the fix Consistently passes with the fix NotifyStressTest (newly added test): Consistently fails without the fix Consistently passes with the fix ------------- Commit messages: - Handle white spaces - remove extra-space - Update copyright - Return the default device if the peer is beeing disposed - Add Test for JDK-8346952 Changes: https://git.openjdk.org/jdk/pull/25619/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346952 Stats: 66 lines in 2 files changed: 66 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From aivanov at openjdk.org Tue Jun 3 16:46:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Jun 2025 16:46:55 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: <8qBtHe3f5ANxTxIaFUHhV2-YEBt0ZTr8M05_iUNtfPI=.58d8ad99-1062-4e30-99d2-920376685ef0@github.com> On Tue, 3 Jun 2025 07:15:53 GMT, Tejesh R wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct the title of the test frames > > test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 56: > >> 54:
      >> 55:
    1. JFileChooser shows a virtual directory. >> 56: The first file in the list has the following name: > > Here, we should mention that the directory name and first file name is ``` > <html><h1 color=#ff00ff><font > face="Comic Sans MS">Swing Rocks! > ```. > The directory name helps us to verify the name on `combobox` area in some L&F (Like aqua) and file name helps us to verify in `filepane` (In some L&F). There are no directories ? you can't navigate this virtual file system. Since the `VirtualFileSystemView` returns the same files in its `getRoots`, the same files are displayed in the navigation combo box. > Should the file name be within `` tag or just `""` ? Yes, it should. It's a typographic standard to render class names, keywords, file names in a monospaced font. That's how the file name is rendered in HTML. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2124406379 PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2124409180 From aivanov at openjdk.org Tue Jun 3 17:11:12 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Jun 2025 17:11:12 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v3] In-Reply-To: References: Message-ID: > The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. > > The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. > > The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. > > The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. > > I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). > > In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. > > > In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision: - Align the title of frame with JFileChooser to htmlDisabled flag - Use Serif font instead of Comic Sans MS - Rename createFileChooser parameter htmlEnabled -> htmlDisabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25455/files - new: https://git.openjdk.org/jdk/pull/25455/files/f0633abd..fe63e02e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25455&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25455&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25455.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25455/head:pull/25455 PR: https://git.openjdk.org/jdk/pull/25455 From aivanov at openjdk.org Tue Jun 3 17:11:12 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Jun 2025 17:11:12 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Sun, 1 Jun 2025 19:49:57 GMT, Phil Race wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct the title of the test frames > > test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 58: > >> 56: The first file in the list has the following name: >> 57: <html><h1 color=#ff00ff><font >> 58: face="Comic Sans MS">Swing Rocks! > > I almost said this last time, but I think the instructions should use a different font name. > On linux this will always just fall back to Dialog because this font doesn't exist. > Better to just use "Serif". It's still clearly visible, because it uses a larger font and magenta color. I updated to "Serif" which makes it stand out even more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2124453666 From aivanov at openjdk.org Tue Jun 3 17:17:56 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Jun 2025 17:17:56 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 17:11:12 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision: > > - Align the title of frame with JFileChooser to htmlDisabled flag > - Use Serif font instead of Comic Sans MS > - Rename createFileChooser parameter htmlEnabled -> htmlDisabled The test `javax/swing/JFileChooser/HTMLFileName.java#system` fails on Linux in GTK Look and Feel: HTML is rendered in both frames. I submitted [JDK-8358532](https://bugs.openjdk.org/browse/JDK-8358532): _JFileChooser in GTK L&F still displays HTML filename_. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25455#issuecomment-2936373276 From aivanov at openjdk.org Tue Jun 3 17:18:00 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 3 Jun 2025 17:18:00 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 21:27:22 GMT, Harshitha Onkar wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct the title of the test frames > > test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 81: > >> 79: in the navigation combo box above is displayed >> 80: as HTML, then press Pass.
      >> 81: If it is in plain text, then press Fail. > > According to test instructions it states that the file name in the **file pane** and navigation combo box must be displayed as HTML. When I'm testing with system (Aqua) LaF on macOS the file name in file pane appears blank (with the original as well as updated test). > > HTML_Enabled Yes, you're right? Aqua L&F doesn't seem to support HTML rendering file pane of `JFileChooser`, and the file name looks empty. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2124461159 From prr at openjdk.org Tue Jun 3 17:25:55 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 3 Jun 2025 17:25:55 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v14] In-Reply-To: <-wufduQaG7bNR6MZksflsgCitkejQfKDFxXKNhB-2bQ=.998703db-0369-4d4c-98fc-1036e0479ed8@github.com> References: <-wufduQaG7bNR6MZksflsgCitkejQfKDFxXKNhB-2bQ=.998703db-0369-4d4c-98fc-1036e0479ed8@github.com> Message-ID: On Tue, 27 May 2025 17:35:17 GMT, Alisen Chung wrote: >> Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point. >> >> Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native. >> >> This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds. > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - add logging to test > - test require macos, spacing in crobot I applied the current fix to an up-to-date repo and ran all our automated tests and all looks good. I think it is time to push this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2936398556 From naoto at openjdk.org Tue Jun 3 17:52:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 3 Jun 2025 17:52:55 GMT Subject: RFR: 8356977: UTF-8 cleanups [v3] In-Reply-To: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com> References: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com> Message-ID: On Tue, 3 Jun 2025 17:42:37 GMT, Magnus Ihse Bursie wrote: >> I found a few other places in the code that can be cleaned up after the conversion to UTF-8. > > Magnus Ihse Bursie 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 'master' into utf8-minor-cleanup > - Revert changes in RotFontBoundsTest.java > - Restore MenuShortcut.java > - Restore LocaleDataTest.java > - Replace uncessary unicode characters with ASCII in instructions, and fix typo > - Seems like typos in the comments > - Fix unicode sequences in comments (previously missed) > @naotoj Are you happy with the other changes? Yes. Thank you for the cleanup! ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2893481166 From ihse at openjdk.org Tue Jun 3 17:52:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 17:52:55 GMT Subject: RFR: 8356977: UTF-8 cleanups [v3] In-Reply-To: References: Message-ID: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com> > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. Magnus Ihse Bursie 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 'master' into utf8-minor-cleanup - Revert changes in RotFontBoundsTest.java - Restore MenuShortcut.java - Restore LocaleDataTest.java - Replace uncessary unicode characters with ASCII in instructions, and fix typo - Seems like typos in the comments - Fix unicode sequences in comments (previously missed) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25228/files - new: https://git.openjdk.org/jdk/pull/25228/files/7184e685..c3027c1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25228&range=01-02 Stats: 125596 lines in 1865 files changed: 71361 ins; 38692 del; 15543 mod Patch: https://git.openjdk.org/jdk/pull/25228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228 PR: https://git.openjdk.org/jdk/pull/25228 From ihse at openjdk.org Tue Jun 3 17:52:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 3 Jun 2025 17:52:57 GMT Subject: RFR: 8356977: UTF-8 cleanups [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie wrote: >> I found a few other places in the code that can be cleaned up after the conversion to UTF-8. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Restore MenuShortcut.java > - Restore LocaleDataTest.java @naotoj Are you happy with the other changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25228#issuecomment-2936435086 From achung at openjdk.org Tue Jun 3 18:06:27 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 3 Jun 2025 18:06:27 GMT Subject: Integrated: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 01:01:55 GMT, Alisen Chung wrote: > Currently on macOS when mouseMove is given an offscreen coordinate to move the mouse to, mouseMove will physically clamp to the edge of the screen, but if you try to grab the mouse location immediately after by using MouseInfo.getPointerInfo().getLocation() you will get the value of the offscreen point. > > Windows and linux do this clamping and coordinate handling for us, but new distributions may not necessarily handle clamping the same way, so Robot should be checking for clamping rather than delegating it to native. > > This fix updates shared code to cache the screen bounds and adds a check to not exceed the bounds in mouseMove. The caching is done in the Robot constructor, so if the screen bounds changes the constructor must be called again to update to the new bounds. This pull request has now been integrated. Changeset: 461cb842 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/461cb84277b40d01c5d04be3c74f25d8667a207c Stats: 121 lines in 2 files changed: 119 ins; 0 del; 2 mod 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen Reviewed-by: honkar, prr ------------- PR: https://git.openjdk.org/jdk/pull/22781 From serb at openjdk.org Tue Jun 3 18:14:47 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 3 Jun 2025 18:14:47 GMT Subject: RFR: 8358468: Enhance code consistency: java.desktop/macos Message-ID: This PR updates the last (!!) remaining platform-specific part of the java.desktop module: macos. The unix/windows were previously addressed in: https://github.com/openjdk/jdk/pull/24170 , https://github.com/openjdk/jdk/pull/24941 and https://github.com/openjdk/jdk/pull/25439. Note: Unlike on other platforms, the initial change for macOS caused the "BadSerializationTest" to fail. This test relies on internal details of the Aqua Look & Feel that were previously exposed via serialized data (and already [fails](https://bugs.openjdk.org/browse/JDK-8277817) on other platforms). Adding the final modifier to the class changes its serialVersionUID, which triggered the failure even on macOS. To avoid this issue, I have reverted the changes to those internal classes for now, see https://github.com/openjdk/jdk/pull/25607/commits/ff7e64b6e38a1a809d434628f304e49408135697 To download the diff file and filter only the modified lines you can use the following script: curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff -o d.txt && grep -E '^+|^-' d.txt | grep -vE '^+++|^---' ==================================================== The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency. The public API was not affected so there is no need to worry about a CSR Note: I will submit additional patches in this area later because: 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797)) 2. I skipped adding `@Override` for anonymous classes Any feedback or suggestions are welcome! Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff) to a simple diff file, it might be more convenient for reviewing the changes. The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected by these changes. It would be good to verify this by mach5 to ensure everything works as expected. ------------- Commit messages: - Fix java/awt/dnd/BadSerializationTest/BadSerializationTest.java test - restore formatting - final in java.desktop/macos - override in java.desktop/macos Changes: https://git.openjdk.org/jdk/pull/25607/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25607&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358468 Stats: 1216 lines in 169 files changed: 859 ins; 0 del; 357 mod Patch: https://git.openjdk.org/jdk/pull/25607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25607/head:pull/25607 PR: https://git.openjdk.org/jdk/pull/25607 From prr at openjdk.org Tue Jun 3 19:07:16 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 3 Jun 2025 19:07:16 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 15:32:01 GMT, Anass Baya wrote: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2515: > 2513: return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > 2514: } > 2515: The code you referred to in the description is handling the case of when a *device* (ie screen) is disconnected. This is the window peer being destroyed. Assuming that what you described is correct - some other thread is in a race with this thread - this change looks to me to greatly reduce the likelihood but not eliminate it - ie between the call at line 2510 above and 2516 below, the destruction could happen. So isn't the right fix to not create the Throwable in this case ? And just do the default return. ie maybe the above check goes after the pData == NULL case and if destroyed, do the default return, and if its something else, do the throw. And perhaps (not sure) that line 2521 should always have returned the default device, not 0 ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2124684731 From serb at openjdk.org Tue Jun 3 19:25:18 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 3 Jun 2025 19:25:18 GMT Subject: RFR: 8357688: Remove unnecessary List.get before remove in PopupFactory In-Reply-To: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com> References: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com> Message-ID: On Sat, 17 May 2025 07:42:59 GMT, Andrey Turbanov wrote: > Instead of separate List.get+List.remove calls we can use single `removeFirst`. It's clearer. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25283#pullrequestreview-2893804084 From mblaesing at openjdk.org Tue Jun 3 20:35:37 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 3 Jun 2025 20:35:37 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v5] In-Reply-To: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: > - Introduce a lock into WClipboard that protects the code between > openClipboard/closeClipboard invocations. > The native side does not allow to open the clipboard multiple > times or share the opened clipboard between multiple threads. > > - Remove of need to call openClipboard/closeClipboard from > getClipboardFormats by using the win32 call > GetUpdatedClipboardFormats > > - Prevent a race-condition by not registering the connection > between java and native side of clipboard multiple time, but > just at construction time. Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Address review comments: - reduce log level in WClipboard#handleContentsChanged to DEBUG, so that in normal operation it will not be visible - restore comment on WClipboard#closeClipboard - adjust comment on WClipboard#openClipboard - Ensure ConcurrentClipboardAccessTest shutsdown on its own when not run in an environment with an external timeout handling. - Added finishing message to ConcurrentClipboardAccessTest, so that correct termination can be determined visually if run manually ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24614/files - new: https://git.openjdk.org/jdk/pull/24614/files/bfa99a71..50ccf766 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24614&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24614&range=03-04 Stats: 18 lines in 2 files changed: 13 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24614.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24614/head:pull/24614 PR: https://git.openjdk.org/jdk/pull/24614 From mblaesing at openjdk.org Tue Jun 3 20:35:37 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 3 Jun 2025 20:35:37 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v4] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Thu, 29 May 2025 17:11:12 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Add headful key to the jtreg description @alisenchung @DamonGuy thank you both for comments, pushed an update, that hopefully addresses your concerns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2937102842 From mblaesing at openjdk.org Tue Jun 3 20:35:37 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 3 Jun 2025 20:35:37 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v5] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Mon, 2 Jun 2025 16:19:25 GMT, Alisen Chung wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments: >> >> - reduce log level in WClipboard#handleContentsChanged to DEBUG, so that >> in normal operation it will not be visible >> - restore comment on WClipboard#closeClipboard >> - adjust comment on WClipboard#openClipboard >> - Ensure ConcurrentClipboardAccessTest shutsdown on its own when not >> run in an environment with an external timeout handling. >> - Added finishing message to ConcurrentClipboardAccessTest, so that >> correct termination can be determined visually if run manually > > src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java line 113: > >> 111: @Override >> 112: public native void openClipboard(SunClipboard newOwner) throws IllegalStateException; >> 113: /** > > was this comment accidentally deleted? Restored the comment and adjusted the comment on `openClipboard` to better address the required calling sequence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2124869380 From mblaesing at openjdk.org Tue Jun 3 20:35:37 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 3 Jun 2025 20:35:37 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v3] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> <4WgqjhL3ZIJAYKUp8CHG-mQDyvfp8wmWIaGqlkjpLOs=.914fd1b8-de37-4386-96a5-98cc0f8b2052@github.com> Message-ID: <1TZt4UoznoNZdGud65FNS_-a8t1H0U7Byk1DNhKsDCc=.410cc1d5-8c8e-40bd-8822-0d22a7cd21b0@github.com> On Mon, 2 Jun 2025 22:25:14 GMT, Damon Nguyen wrote: >> The idea here is to not silently swallow exceptions. This code is called from `AwtToolkit::WndProc`, which from my reading will not report exceptions/throwables. Pushing the exception to the system logger gives a chance to detect problems here. > > Sounds reasonable but loggers don't seem to be used in `src` files as far as I can tell. They are used in tests to help detect issues as you mentioned, and I can find plenty of occurrences of loggers used in the `test` directory of the open JDK but I don't see any in `src`. Makes me think there's an alternative way to handle this. I dropped the log level to `DEBUG` that way in normal operation this will not visible (and shut not affect performance). I think this might be a way to address the concern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2124867413 From mblaesing at openjdk.org Tue Jun 3 20:35:38 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 3 Jun 2025 20:35:38 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v4] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Mon, 2 Jun 2025 16:52:26 GMT, Alisen Chung wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Add headful key to the jtreg description > > test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 31: > >> 29: @run main ConcurrentClipboardAccessTest >> 30: */ >> 31: import java.awt.*; > > expand imports Done > test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 58: > >> 56: public void run() { >> 57: final Clipboard systemClipboard = Toolkit.getDefaultToolkit().getSystemClipboard(); >> 58: while (true) { > > will this cause the test to run until timeout if the thread isn't interrupted? Valid point. Adjusted test to use daemon threads for the concurrent access tests. I reran the tests on the baseline JDK and after the changes to verify the findings from https://github.com/openjdk/jdk/pull/24614#issuecomment-2884495131. Did not notice this as the jtreg harness indeed seems to terminate the JVM and not report that as a failure, tested now also manually (without jtreg). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2124872594 PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2124872455 From dnguyen at openjdk.org Tue Jun 3 22:23:20 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 3 Jun 2025 22:23:20 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v5] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: <3D6hNptNe_z8k03YyGeatJTC755hjkenCkb-6lqubKc=.52147e6c-e0be-473b-9332-ce38e20fea8d@github.com> On Tue, 3 Jun 2025 20:35:37 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > > - reduce log level in WClipboard#handleContentsChanged to DEBUG, so that > in normal operation it will not be visible > - restore comment on WClipboard#closeClipboard > - adjust comment on WClipboard#openClipboard > - Ensure ConcurrentClipboardAccessTest shutsdown on its own when not > run in an environment with an external timeout handling. > - Added finishing message to ConcurrentClipboardAccessTest, so that > correct termination can be determined visually if run manually I think this looks fair to me now. But, you still need a Reviewer to look at this. Maybe @kumarabhi006 ? ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/24614#pullrequestreview-2894267992 From duke at openjdk.org Tue Jun 3 23:05:15 2025 From: duke at openjdk.org (duke) Date: Tue, 3 Jun 2025 23:05:15 GMT Subject: RFR: 8356803: Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance In-Reply-To: References: Message-ID: On Fri, 30 May 2025 23:40:22 GMT, Daniel Gredler wrote: > Per discussion in JBS, adds the following chars to the list of ignorable whitespace chars: U+000B (Vertical Tab), U+000C (Form Feed), U+0085 (Next Line), U+2028 (Line Separator), U+2029 (Paragraph Separator). > > Adds the necessary testing in pre-existing automated test class `test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java`. > > Removes now-unnecessary manual test `test/jdk/java/awt/font/TextLayout/TestControls.java`. > > The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS. @gredler Your change (at version 0b91df644ef6d3d40fdd11649ec4e9eda83db197) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25560#issuecomment-2937648203 From dgredler at openjdk.org Tue Jun 3 23:30:21 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 3 Jun 2025 23:30:21 GMT Subject: Integrated: 8356803: Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance In-Reply-To: References: Message-ID: On Fri, 30 May 2025 23:40:22 GMT, Daniel Gredler wrote: > Per discussion in JBS, adds the following chars to the list of ignorable whitespace chars: U+000B (Vertical Tab), U+000C (Form Feed), U+0085 (Next Line), U+2028 (Line Separator), U+2029 (Paragraph Separator). > > Adds the necessary testing in pre-existing automated test class `test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java`. > > Removes now-unnecessary manual test `test/jdk/java/awt/font/TextLayout/TestControls.java`. > > The `test/jdk/java/awt/font`, `test/jdk/java/awt/print` and `test/jdk/java/awt/Graphics2D/DrawString` tests all pass for me locally on Windows, Linux and macOS. This pull request has now been integrated. Changeset: 93975357 Author: Daniel Gredler Committer: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/939753579b80d2910c78d8bbb1c97bd56afa21ba Stats: 215 lines in 3 files changed: 40 ins; 161 del; 14 mod 8356803: Test TextLayout/TestControls fails on windows & linux: line and paragraph separator show non-zero advance 8356812: Create an automated version of TextLayout/TestControls Reviewed-by: prr, honkar ------------- PR: https://git.openjdk.org/jdk/pull/25560 From psadhukhan at openjdk.org Wed Jun 4 03:51:15 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Jun 2025 03:51:15 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: <-tW8DaWe-R0y-jrJ2mBFwMkm09lAXhps4OrrxTP0cVY=.6986d1d5-6267-4064-b6f8-9f81ba41e30c@github.com> On Tue, 3 Jun 2025 14:05:24 GMT, Alexander Zvegintsev wrote: >> But then it should show JNI exception pending for all places where we call AWT_UNLOCK, why only this place? > > This is not the only place. Other cases are also covered by checking for pending exceptions or by returning to Java. If not, the code analysis tool may not detect it for some reason. We call AWT_UNLOCK in awt_Robot.c, gtk3_interface.c, awt_GraphicsEnv.c where there's no ExceptionCheck after the call. For example, here ExceptionCheck is called not after AWT_UNLOCK but after the next JNI call `(*env)->NewObject` https://github.com/openjdk/jdk/blob/ebd85288ce309b7dc7ff8b36558dd9f2a2300209/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c#L1281-L1290 Normally we do ExceptionCheck after GetStringUTFChars https://github.com/openjdk/jdk/blob/ebd85288ce309b7dc7ff8b36558dd9f2a2300209/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L1192-L1193 Did you verify the warning goes off only by this PR change? If not, I will also recommend doing CHECK_EXCEPTION after GetStringUTFChars too.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2125538565 From abhiscxk at openjdk.org Wed Jun 4 04:31:19 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 4 Jun 2025 04:31:19 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v5] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Tue, 3 Jun 2025 20:35:37 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > > - reduce log level in WClipboard#handleContentsChanged to DEBUG, so that > in normal operation it will not be visible > - restore comment on WClipboard#closeClipboard > - adjust comment on WClipboard#openClipboard > - Ensure ConcurrentClipboardAccessTest shutsdown on its own when not > run in an environment with an external timeout handling. > - Added finishing message to ConcurrentClipboardAccessTest, so that > correct termination can be determined visually if run manually test/jdk/java/awt/Clipboard/ConcurrentClipboardAccessTest.java line 1: > 1: /* Test passed even without the fix on macOS. Is the fix applicable only on Windows ? If yes, then I think you should restrict the test to run only on required platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24614#discussion_r2125609656 From azvegint at openjdk.org Wed Jun 4 05:39:36 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 4 Jun 2025 05:39:36 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: Message-ID: > After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: JNU_CHECK_EXCEPTION_RETURN for GetStringUTFChars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25605/files - new: https://git.openjdk.org/jdk/pull/25605/files/5f49dc30..f40cd179 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25605&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25605&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25605/head:pull/25605 PR: https://git.openjdk.org/jdk/pull/25605 From azvegint at openjdk.org Wed Jun 4 05:39:36 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 4 Jun 2025 05:39:36 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: <-tW8DaWe-R0y-jrJ2mBFwMkm09lAXhps4OrrxTP0cVY=.6986d1d5-6267-4064-b6f8-9f81ba41e30c@github.com> References: <-tW8DaWe-R0y-jrJ2mBFwMkm09lAXhps4OrrxTP0cVY=.6986d1d5-6267-4064-b6f8-9f81ba41e30c@github.com> Message-ID: On Wed, 4 Jun 2025 03:49:05 GMT, Prasanta Sadhukhan wrote: > We call AWT_UNLOCK in awt_Robot.c, gtk3_interface.c, awt_GraphicsEnv.c where there's no ExceptionCheck after the call. Neither awt_Robot.c nor gtk3_interface.c calls any JNI functions afterwards. I'm not sure why the tool didn't trigger regarding the awt_GraphicsEnv.c case. > Normally we do ExceptionCheck after GetStringUTFChars I added it just in case, but the GetStringUTFChars [documentation](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#getstringutfchars) doesn't mention any exceptions being thrown. > Did you verify the warning goes off only by this PR change? it is the only reported line by the tool: `JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214` so it should resolve the issue. But now I think it might be a false positive: 1. `AWT_LOCK()` clears all exceptions: https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L86-L95 2. `awt_getX11KeySym` doesn't call JNI at all 3. `AWT_UNLOCK()` also clears an exception, and rethrows a previously pending exception, if any. https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L97-L110 Since neither 1. nor 2. produces an exception, no exception will be thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2125687104 From srutjay1 at in.ibm.com Wed Jun 4 05:42:01 2025 From: srutjay1 at in.ibm.com (Sruthy Jayan) Date: Wed, 4 Jun 2025 05:42:01 +0000 Subject: Security Concern: JPasswordField Revealing Passwords in Memory Message-ID: Hi Team , We are encountering a potential security issue with JPasswordField in the latest version of OpenJDK. While the issue is not present in OpenJ9 version 0.40.0, it becomes reproducible in version 0.41.0. Specifically, after typing or pasting a password into the field, memory inspection tools can reveal the password in plain text?even before the password is submitted or any action is triggered. This behaviour is reproducible and raises concerns about sensitive data being exposed unintentionally. We have attached a detailed document ( [https://res.public.onecdn.static.microsoft/assets/mail/file-icon/png/docx_16x16.png] ClearPasswordInMemoryIssue 1.docx) outlining the issue, steps to reproduce, and our observations. Could someone from the community assist us in investigating or addressing this issue? Please let us know if any additional information is needed. Thank you for your time and support. Best Regards, Sruthy Jayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Wed Jun 4 05:49:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Jun 2025 05:49:16 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: <-tW8DaWe-R0y-jrJ2mBFwMkm09lAXhps4OrrxTP0cVY=.6986d1d5-6267-4064-b6f8-9f81ba41e30c@github.com> Message-ID: <06lSBlfuM9g3jDaiR6hPM90JhVB5384Ls9pQJj1lNgY=.4528b1df-2028-49a0-9220-9ee64a292d55@github.com> On Wed, 4 Jun 2025 05:34:21 GMT, Alexander Zvegintsev wrote: >> We call AWT_UNLOCK in awt_Robot.c, gtk3_interface.c, awt_GraphicsEnv.c where there's no ExceptionCheck after the call. >> For example, here ExceptionCheck is called not after AWT_UNLOCK but after the next JNI call `(*env)->NewObject` >> https://github.com/openjdk/jdk/blob/ebd85288ce309b7dc7ff8b36558dd9f2a2300209/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c#L1281-L1290 >> >> Normally we do ExceptionCheck after GetStringUTFChars >> https://github.com/openjdk/jdk/blob/ebd85288ce309b7dc7ff8b36558dd9f2a2300209/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L1192-L1193 >> >> Did you verify the warning goes off only by this PR change? If not, I will also recommend doing CHECK_EXCEPTION after GetStringUTFChars too.. > >> We call AWT_UNLOCK in awt_Robot.c, gtk3_interface.c, awt_GraphicsEnv.c where there's no ExceptionCheck after the call. > > Neither awt_Robot.c nor gtk3_interface.c calls any JNI functions afterwards. > the awt_GraphicsEnv.c case doesn't call JNI functions between `AWT_LOCK` / `AWT_UNLOCK` (see explanation below about false positive). > >> Normally we do ExceptionCheck after GetStringUTFChars > > I added it just in case, but the GetStringUTFChars [documentation](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#getstringutfchars) doesn't mention any exceptions being thrown. > >> Did you verify the warning goes off only by this PR change? > > it is the only reported line by the tool: > > `JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214` > > so it should resolve the issue. > > But now I think it might be a false positive: > > 1. `AWT_LOCK()` clears all exceptions: > https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L86-L95 > 2. `awt_getX11KeySym` doesn't call JNI at all > 3. `AWT_UNLOCK()` also clears an exception, and rethrows a previously pending exception, if any. > https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L97-L110 > > Since neither 1. nor 2. produces an exception, no exception will be thrown. 3 rethrows the exception, maybe tool is complaining about that..maybe we should find out what that exception is and who is throwing? Should we call EXCEPTION_CHECK_DESCRIBE instead to find out what exception it is complaining about by running the tool? Also, dont we need to do ExceptionClear too in addition to ExcepionCheck to clear out the exception else it will keep it pending? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2125699271 From azvegint at openjdk.org Wed Jun 4 06:08:18 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 4 Jun 2025 06:08:18 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: <06lSBlfuM9g3jDaiR6hPM90JhVB5384Ls9pQJj1lNgY=.4528b1df-2028-49a0-9220-9ee64a292d55@github.com> References: <-tW8DaWe-R0y-jrJ2mBFwMkm09lAXhps4OrrxTP0cVY=.6986d1d5-6267-4064-b6f8-9f81ba41e30c@github.com> <06lSBlfuM9g3jDaiR6hPM90JhVB5384Ls9pQJj1lNgY=.4528b1df-2028-49a0-9220-9ee64a292d55@github.com> Message-ID: On Wed, 4 Jun 2025 05:45:43 GMT, Prasanta Sadhukhan wrote: >>> We call AWT_UNLOCK in awt_Robot.c, gtk3_interface.c, awt_GraphicsEnv.c where there's no ExceptionCheck after the call. >> >> Neither awt_Robot.c nor gtk3_interface.c calls any JNI functions afterwards. >> the awt_GraphicsEnv.c case doesn't call JNI functions between `AWT_LOCK` / `AWT_UNLOCK` (see explanation below about false positive). >> >>> Normally we do ExceptionCheck after GetStringUTFChars >> >> I added it just in case, but the GetStringUTFChars [documentation](https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#getstringutfchars) doesn't mention any exceptions being thrown. >> >>> Did you verify the warning goes off only by this PR change? >> >> it is the only reported line by the tool: >> >> `JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214` >> >> so it should resolve the issue. >> >> But now I think it might be a false positive: >> >> 1. `AWT_LOCK()` clears all exceptions: >> https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L86-L95 >> 2. `awt_getX11KeySym` doesn't call JNI at all >> 3. `AWT_UNLOCK()` also clears an exception, and rethrows a previously pending exception, if any. >> https://github.com/openjdk/jdk/blob/78a392aa3b0cda52cfacfa15250fa61010519424/src/java.desktop/unix/native/common/awt/awt.h#L97-L110 >> >> Since neither 1. nor 2. produces an exception, no exception will be thrown. > > 3 rethrows the exception, maybe tool is complaining about that..maybe we should find out what that exception is and who is throwing? > Should we call EXCEPTION_CHECK_DESCRIBE instead to find out what exception it is complaining about by running the tool? > > Also, dont we need to do ExceptionClear too in addition to ExcepionCheck to clear out the exception else it will keep it pending? I don't think so. Let Java catch it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2125723089 From psadhukhan at openjdk.org Wed Jun 4 07:04:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Jun 2025 07:04:16 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: Message-ID: <6z1UONWVseue15ZfSayFgT_-KK4b2VrKfEjOGOEKqXA=.626ba9fd-dc19-444d-945e-38d76fdbcbcb@github.com> On Wed, 4 Jun 2025 05:39:36 GMT, Alexander Zvegintsev wrote: >> After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > JNU_CHECK_EXCEPTION_RETURN for GetStringUTFChars Looks good to me.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25605#pullrequestreview-2895518703 From psadhukhan at openjdk.org Wed Jun 4 07:04:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Jun 2025 07:04:16 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: <-tW8DaWe-R0y-jrJ2mBFwMkm09lAXhps4OrrxTP0cVY=.6986d1d5-6267-4064-b6f8-9f81ba41e30c@github.com> <06lSBlfuM9g3jDaiR6hPM90JhVB5384Ls9pQJj1lNgY=.4528b1df-2028-49a0-9220-9ee64a292d55@github.com> Message-ID: On Wed, 4 Jun 2025 06:06:06 GMT, Alexander Zvegintsev wrote: >> 3 rethrows the exception, maybe tool is complaining about that..maybe we should find out what that exception is and who is throwing? >> Should we call EXCEPTION_CHECK_DESCRIBE instead to find out what exception it is complaining about by running the tool? >> >> Also, dont we need to do ExceptionClear too in addition to ExcepionCheck to clear out the exception else it will keep it pending? > > I don't think so. Let Java catch it. ok..but checkReturnValue in ScreenCastHelper.java doesnt handle the exception for RESULT_ERROR case so it will be left to application to handle and am not sure if they will expect this internal exception.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2125827673 From duke at openjdk.org Wed Jun 4 07:45:19 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Wed, 4 Jun 2025 07:45:19 GMT Subject: RFR: 8251928: [macos] the printer DPI always be 72, cause some content lost when print out In-Reply-To: <-VMpAEScXud5FONRrlVj3yi5_Q_hNt7o_jMYW0PbqoQ=.55896ef7-a9d5-4bf1-ba7f-edcac5ced621@github.com> References: <-VMpAEScXud5FONRrlVj3yi5_Q_hNt7o_jMYW0PbqoQ=.55896ef7-a9d5-4bf1-ba7f-edcac5ced621@github.com> Message-ID: On Tue, 3 Jun 2025 06:57:21 GMT, Prasanta Sadhukhan 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. > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 742: > >> 740: private Rectangle2D getPageFormatArea(PageFormat page, double scaleX, double scaleY) { >> 741: Rectangle2D.Double pageFormatArea; >> 742: if (scaleX != 1 && scaleY != 1) { > > BTW, Do we need this check as if scaleX=scaleY=1 then also no issue in doing multiplying with 1 ie scaleX and scaleY and if one of them is not 1 then we need to multiply anyway..so it seems this check is not needed?!! @prsadhuk This is a little bit faster. Calling the scale method with 1 does not change the affine transform, but performs unnecessary invalidation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2125909292 From ihse at openjdk.org Wed Jun 4 08:14:23 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 4 Jun 2025 08:14:23 GMT Subject: Integrated: 8356977: UTF-8 cleanups In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie wrote: > I found a few other places in the code that can be cleaned up after the conversion to UTF-8. This pull request has now been integrated. Changeset: edf92721 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/edf92721c2db4cfba091cf4901af603db8486951 Stats: 15 lines in 13 files changed: 0 ins; 0 del; 15 mod 8356977: UTF-8 cleanups Reviewed-by: naoto, prr ------------- PR: https://git.openjdk.org/jdk/pull/25228 From serb at openjdk.org Wed Jun 4 08:39:18 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 4 Jun 2025 08:39:18 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 19:05:06 GMT, Phil Race wrote: >> **Analysis:** >> >> We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). >> The race condition between the execution paths of these two native methods sometimes causes an exception >> >> **Proposed Fix:** >> >> While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number >> >> >> public void updateGC() { >> >> int scrn = getScreenImOn(); >> >> if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { >> log.finer("Screen number: " + scrn); >> } >> >> // get current GD >> Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); >> >> Win32GraphicsDevice newDev; >> GraphicsDevice[] devs = GraphicsEnvironment >> .getLocalGraphicsEnvironment() >> .getScreenDevices(); >> >> // Occasionally during device addition/removal getScreenImOn can return >> // a non-existing screen number. Use the default device in this case. >> if (scrn >= devs.length) { >> newDev = (Win32GraphicsDevice) GraphicsEnvironment >> .getLocalGraphicsEnvironment().getDefaultScreenDevice(); >> } else { >> newDev = (Win32GraphicsDevice) devs[scrn]; >> } >> } >> >> >> Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : >> >> jint AwtWindow::_GetScreenImOn(void *param) >> { >> ... >> jboolean destroyed = JNI_GET_DESTROYED(self); >> if (destroyed == JNI_TRUE){ >> env->DeleteGlobalRef(self); >> return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> } >> ... >> >> >> **Tests Summary:** >> >> GetGraphicsStressTest (existing test): >> >> Fails intermittently without the fix >> >> Consistently passes with the fix >> >> NotifyStressTest (newly added test): >> >> Consistently fails without the fix >> >> Consistently passes with the fix > > src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2515: > >> 2513: return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> 2514: } >> 2515: > > The code you referred to in the description is handling the case of when a *device* (ie screen) is disconnected. > This is the window peer being destroyed. > Assuming that what you described is correct - some other thread is in a race with this thread - this change looks to me to greatly reduce the likelihood but not eliminate it - ie between the call at line 2510 above and 2516 below, the destruction could happen. > > So isn't the right fix to not create the Throwable in this case ? And just do the default return. > ie maybe the above check goes after the pData == NULL case and if destroyed, do the default return, and if its something else, do the throw. > And perhaps (not sure) that line 2521 should always have returned the default device, not 0 ? This looks suspicious that we might call these methods in the wrong order. But what's potentially even worse is if they are executed in parallel, can we destroy the peer at the exact moment another thread is working with it natively? Is it similar to [this](https://github.com/openjdk/jdk/commit/cc944dde29f14b9bfa4d1437a55ad54f5523cd91) and [this](https://github.com/openjdk/jdk/commit/d9bb0f0d39ed322b29c1807991e82fa28c4807f0) bugs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2126021940 From serb at openjdk.org Wed Jun 4 08:43:22 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 4 Jun 2025 08:43:22 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: Message-ID: <58X15m7TAOi5t1uB1tXMIppF0Q1mfCiIe_7Skkep7OY=.e26b55ed-427c-42f3-82d9-0519f3ed3229@github.com> On Wed, 4 Jun 2025 05:39:36 GMT, Alexander Zvegintsev wrote: >> After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > JNU_CHECK_EXCEPTION_RETURN for GetStringUTFChars It is still unclear why an exception is reported just in this line and others like mention below, can we narrow down what exact line in the code/macro caused that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25605#issuecomment-2939142709 From azvegint at openjdk.org Wed Jun 4 13:26:50 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 4 Jun 2025 13:26:50 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: <58X15m7TAOi5t1uB1tXMIppF0Q1mfCiIe_7Skkep7OY=.e26b55ed-427c-42f3-82d9-0519f3ed3229@github.com> References: <58X15m7TAOi5t1uB1tXMIppF0Q1mfCiIe_7Skkep7OY=.e26b55ed-427c-42f3-82d9-0519f3ed3229@github.com> Message-ID: On Wed, 4 Jun 2025 08:40:59 GMT, Sergey Bylokhov wrote: > It is still unclear why an exception is reported just in this line and others like mention below, can we narrow down what exact line in the code/macro caused that? It is `AWT_UNLOCK();` and `Throw` in it, but it just rethrows earlier pending exception. It seems to be a false positive because neither `AWT_LOCK` nor `awt_getX11KeySym` leaves any pending exceptions. https://github.com/openjdk/jdk/pull/25605#discussion_r2125687104 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25605#issuecomment-2940032504 From mblaesing at openjdk.org Wed Jun 4 17:14:15 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Wed, 4 Jun 2025 17:14:15 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v6] In-Reply-To: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: > - Introduce a lock into WClipboard that protects the code between > openClipboard/closeClipboard invocations. > The native side does not allow to open the clipboard multiple > times or share the opened clipboard between multiple threads. > > - Remove of need to call openClipboard/closeClipboard from > getClipboardFormats by using the win32 call > GetUpdatedClipboardFormats > > - Prevent a race-condition by not registering the connection > between java and native side of clipboard multiple time, but > just at construction time. Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: Limit running test only on windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24614/files - new: https://git.openjdk.org/jdk/pull/24614/files/50ccf766..b9307454 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24614&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24614&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24614.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24614/head:pull/24614 PR: https://git.openjdk.org/jdk/pull/24614 From mblaesing at openjdk.org Wed Jun 4 17:18:01 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Wed, 4 Jun 2025 17:18:01 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v6] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Wed, 4 Jun 2025 17:14:15 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Limit running test only on windows @kumarabhi006 my thinking was, that the JVM should not crash on any platform when clipboard is accessed concurrently, but you are right, that the crash is observed windows only. Only that platform (see implementation class `WClipboard`) requires the `openClipboard`, `closeClipboard` calls. For all other platforms these calls are no-ops. Pushed an update adding the test requirement to the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2940800471 From serb at openjdk.org Wed Jun 4 17:56:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 4 Jun 2025 17:56:04 GMT Subject: Integrated: 8358057: Update validation of ICC_Profile header data In-Reply-To: References: Message-ID: <-VCWqCMwOc__GxgQUVajN2u2Q5PJ0AP-LwNhWDlfvHA=.7dea1725-3095-4233-9b94-75c051c2f3d5@github.com> On Thu, 29 May 2025 10:22:39 GMT, Sergey Bylokhov wrote: > The [next PR](https://github.com/openjdk/jdk/pull/23044) introduces several new methods to the ICC_Profile class: > - getProfileClass(byte[]) > - getColorSpaceType(byte[]) > - getPCSType(byte[]) > - checkRenderingIntent(byte[]) > > These new methods extract data directly from the provided byte array rather than relying on the profile instance. The first three methods essentially duplicate the existing ones (getProfileClass(), getColorSpaceType(), getPCSType()). > > It is possible to update implementation: > - The existing methods getColorSpaceType() and getPCSType() could delegate to the new getColorSpaceType(byte[]) and getPCSType(byte[]) methods. > - The checkRenderingIntent(byte[]) method could be updated to report the actual invalid intent value when an error occurs > > Tests: > - Old ValidateICCHeaderData test is update to verify the new output of the checkRenderingIntent > - New RenderingIntentStressTest test is added to check the next part of the icc_spec: > > * ICC spec: only the least-significant 16 bits encode the rendering > * intent. The most significant 16 bits must be zero and can be ignored. > * See https://www.color.org/ICC1v42_2006-05.pdf, section 7.2.15. > > > > @honkar-jdk please take a look. > > Note: There is currently an inconsistency in the usage of `getData(icSigHead)` vs `getData(cmmProfile(), icSigHead)` throughout the codebase. I plan to address this separately. This pull request has now been integrated. Changeset: 8939acc8 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/8939acc8ab0e45b82252f0f2de37e9bd5c3e1493 Stats: 150 lines in 4 files changed: 112 ins; 15 del; 23 mod 8358057: Update validation of ICC_Profile header data Reviewed-by: honkar ------------- PR: https://git.openjdk.org/jdk/pull/25519 From aivanov at openjdk.org Wed Jun 4 18:52:00 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Jun 2025 18:52:00 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v8] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Mon, 2 Jun 2025 09:33:34 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Removes unnecessary lines and keep consistent code format There are other code clean-up that can be done, but these issues are close to lines which are modified. test/jdk/java/awt/Frame/MultiScreenTest.java line 1: > 1: /* throw new SkippedException("You have only one monitor in your system - test passed"); Please remove `" - test passed"`, the test is skipped. test/jdk/java/awt/Frame/MultiScreenTest.java line 1: > 1: /* Could you make the other classes nested inside `MultiScreenTest`? test/jdk/java/awt/Frame/MultiScreenTest.java line 85: > 83: "Actively drag the DitherTest frames on the secondary screen and " + > 84: "if you see garbage appearing on your primary screen " + > 85: "test failed otherwise it passed.";; Suggestion: "test failed otherwise it passed."; test/jdk/java/awt/Frame/MultiScreenTest.java line 103: > 101: JFrame f = new JFrame(gc[i]); // test JFrame( gc ) > 102: GCCanvas c = new GCCanvas(gc[i]); // test canvas( gc ) > 103: Rectangle gcBounds = gc[i].getBounds(); // test getBounds() I suggest removing the comments altogether ? they don't add anything to what's in the code. Suggestion: JFrame f = new JFrame(gc[i]); GCCanvas c = new GCCanvas(gc[i]); Rectangle gcBounds = gc[i].getBounds(); test/jdk/java/awt/Frame/MultiScreenTest.java line 108: > 106: > 107: f.getContentPane().add(c); > 108: f.setTitle("Screen# " + Integer.toString(j) + ", GC#" + Integer.toString(i)); Can be simplified: Suggestion: f.setTitle("Screen# " + j + ", GC#" + i); test/jdk/java/awt/Frame/MultiScreenTest.java line 111: > 109: f.setSize(300, 200); > 110: f.setLocation(400 + xoffs, (i * 150) + yoffs); // test > 111: // displaying in right location Suggestion: // test displaying in right location f.setLocation(400 + xoffs, (i * 150) + yoffs); The comment applies to this line, however, does it add anything, does it clarify anything? Should we remove the comment? test/jdk/java/awt/Frame/MultiScreenTest.java line 114: > 112: list.add(f); > 113: > 114: Frame ditherfs = new Frame("DitherTest GC#" + Integer.toString(i), gc[i]); Can be simplified: Suggestion: Frame ditherfs = new Frame("DitherTest GC#" + i, gc[i]); test/jdk/java/awt/Frame/MultiScreenTest.java line 115: > 113: > 114: Frame ditherfs = new Frame("DitherTest GC#" + Integer.toString(i), gc[i]); > 115: ditherfs.setLayout(new BorderLayout()); // showDitherTest The comment is misleading: setting a layout doesn't show anything. Suggestion: ditherfs.setLayout(new BorderLayout()); test/jdk/java/awt/Frame/MultiScreenTest.java line 140: > 138: super(gc); > 139: this.gc = gc; > 140: bounds = gc.getBounds(); Remove Graphics g = this.getGraphics(); This field is unused. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2897710693 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127210738 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127220721 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127225063 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127197384 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127201901 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127200491 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127203043 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127204010 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127224690 From aivanov at openjdk.org Wed Jun 4 19:09:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Jun 2025 19:09:54 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v8] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: <3lGnjn3R3swqqZWUVEdPP3Pqcurkwq-l15wPM4_gnOs=.94cc6cb2-2bd6-409a-9dbe-9535edb3d28b@github.com> On Mon, 2 Jun 2025 09:33:34 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Removes unnecessary lines and keep consistent code format Changes requested by aivanov (Reviewer). test/jdk/java/awt/Frame/MultiScreenTest.java line 91: > 89: .columns(40) > 90: .testUI(obj::init) > 91: .build() Suggestion: .testUI(obj::init) .positionTestUI(MultiScreenTest::positionTestWindows) .build() where private static void positionTestWindows(List testWindows, PassFailJFrame.InstructionUI instructionUI) { // Do nothing - the location of each window is set when they're created } This allows keeping both created frames / windows `Screen#` and `DitherTest GC#` together for each screen. Perhaps, such a null layout should be added as library method into [`WindowLayouts.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/regtesthelpers/WindowLayouts.java). ------------- PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2897811132 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2127258166 From duke at openjdk.org Wed Jun 4 19:51:11 2025 From: duke at openjdk.org (Jeremy Wood) Date: Wed, 4 Jun 2025 19:51:11 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v7] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8354646: run test on all available look and feels This is in response to: https://github.com/openjdk/jdk/pull/25443#issuecomment-2933556752 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/0c299471..660028bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=05-06 Stats: 45 lines in 1 file changed: 22 ins; 1 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Wed Jun 4 19:51:11 2025 From: duke at openjdk.org (Jeremy Wood) Date: Wed, 4 Jun 2025 19:51:11 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v5] In-Reply-To: References: <9OsgP7Nt-I4n_uqYEzVaNAbp-3rYf4ozSFmiWyDoF5Q=.5dc3cbc6-942d-490b-b086-c9803c92ee14@github.com> <7C_922gw6YyrITP7jNbscW8Us16vSv6B3GKMvFs_XYE=.fca6f4f3-a101-4fcb-b032-e7934f82ac50@github.com> Message-ID: On Tue, 3 Jun 2025 05:44:21 GMT, Prasanta Sadhukhan wrote: > am i correct? Yes. > you should check for UIManager.getInstalledLookAndFeels() and iterate and test all the installed L&Fs of the current platform OK, thanks. This is updated. On my Mac the test output now resembles: Testing LAF: javax.swing.plaf.metal.MetalLookAndFeel Testing javax.swing.plaf.basic.BasicPasswordFieldUI at 146e76c selectionStart = 0 selectionEnd = 13 Testing LAF: javax.swing.plaf.nimbus.NimbusLookAndFeel Testing javax.swing.plaf.synth.SynthPasswordFieldUI at 6268e29 selectionStart = 0 selectionEnd = 13 Testing LAF: com.sun.java.swing.plaf.motif.MotifLookAndFeel Testing com.sun.java.swing.plaf.motif.MotifPasswordFieldUI at 76498661 selectionStart = 0 selectionEnd = 13 Testing LAF: com.apple.laf.AquaLookAndFeel Testing com.apple.laf.AquaTextPasswordFieldUI at 508545fe selectionStart = 0 selectionEnd = 13 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2941271168 From aivanov at openjdk.org Wed Jun 4 21:03:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Jun 2025 21:03:53 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v7] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 19:51:11 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: run test on all available look and feels > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#issuecomment-2933556752 test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 76: > 74: return; > 75: } > 76: System.out.println("Testing "+ field.getUI()); Suggestion: System.out.println("Testing " + field.getUI()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2127432532 From duke at openjdk.org Wed Jun 4 21:09:37 2025 From: duke at openjdk.org (Jeremy Wood) Date: Wed, 4 Jun 2025 21:09:37 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v8] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/660028bc..0c0b417a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From serb at openjdk.org Wed Jun 4 23:47:49 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 4 Jun 2025 23:47:49 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: Message-ID: <9GQHdNpGb6IOnPhe-LSyp0KOtX7C6DgzboTDvzyOC5M=.116a3ef0-5756-4ebf-9394-3e69629084f1@github.com> On Wed, 4 Jun 2025 05:39:36 GMT, Alexander Zvegintsev wrote: >> After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > JNU_CHECK_EXCEPTION_RETURN for GetStringUTFChars Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25605#pullrequestreview-2898367238 From duke at openjdk.org Thu Jun 5 07:57:14 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 07:57:14 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v9] In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: <3dhs3vz-J2muJ2LNKQ4_vV1HPiml7bif9_qty-f95AU=.e3d6a0a0-9d3e-4d37-a824-ef2863ac61a6@github.com> > Fixes issue in which the test fails when run on multi-screen machine. > > Tested on Ubuntu 24.04, MacOS 15 and Windows 11 > > JTREG > > runner starting test: java/awt/Frame/MultiScreenTest.java > runner finished test: java/awt/Frame/MultiScreenTest.java > Passed. Execution successful 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 six additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8352149 - Removes unnecessary lines and keep consistent code format - Merge branch 'openjdk:master' into jdk-8352149 - Adds Override for overriden methods - Merge branch 'openjdk:master' into jdk-8352149 - 8352149: test/jdk/java/awt/Frame/MultiScreenTest.java fails in MacOS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24752/files - new: https://git.openjdk.org/jdk/pull/24752/files/a2c27704..2830acc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=07-08 Stats: 18082 lines in 426 files changed: 15026 ins; 1324 del; 1732 mod Patch: https://git.openjdk.org/jdk/pull/24752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24752/head:pull/24752 PR: https://git.openjdk.org/jdk/pull/24752 From duke at openjdk.org Thu Jun 5 08:16:59 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 08:16:59 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v8] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Wed, 4 Jun 2025 18:37:02 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Removes unnecessary lines and keep consistent code format > > test/jdk/java/awt/Frame/MultiScreenTest.java line 1: > >> 1: /* > > throw new SkippedException("You have only one monitor in your system - test passed"); > > Please remove `" - test passed"`, the test is skipped. message updated. > test/jdk/java/awt/Frame/MultiScreenTest.java line 85: > >> 83: "Actively drag the DitherTest frames on the secondary screen and " + >> 84: "if you see garbage appearing on your primary screen " + >> 85: "test failed otherwise it passed.";; > > Suggestion: > > "test failed otherwise it passed."; semicolon removed. > test/jdk/java/awt/Frame/MultiScreenTest.java line 103: > >> 101: JFrame f = new JFrame(gc[i]); // test JFrame( gc ) >> 102: GCCanvas c = new GCCanvas(gc[i]); // test canvas( gc ) >> 103: Rectangle gcBounds = gc[i].getBounds(); // test getBounds() > > I suggest removing the comments altogether ? they don't add anything to what's in the code. > Suggestion: > > JFrame f = new JFrame(gc[i]); > GCCanvas c = new GCCanvas(gc[i]); > Rectangle gcBounds = gc[i].getBounds(); comments removed. > test/jdk/java/awt/Frame/MultiScreenTest.java line 108: > >> 106: >> 107: f.getContentPane().add(c); >> 108: f.setTitle("Screen# " + Integer.toString(j) + ", GC#" + Integer.toString(i)); > > Can be simplified: > Suggestion: > > f.setTitle("Screen# " + j + ", GC#" + i); code updated. > test/jdk/java/awt/Frame/MultiScreenTest.java line 111: > >> 109: f.setSize(300, 200); >> 110: f.setLocation(400 + xoffs, (i * 150) + yoffs); // test >> 111: // displaying in right location > > Suggestion: > > // test displaying in right location > f.setLocation(400 + xoffs, (i * 150) + yoffs); > > The comment applies to this line, however, does it add anything, does it clarify anything? Should we remove the comment? Comment cleanup done, pending decision about its removal. > test/jdk/java/awt/Frame/MultiScreenTest.java line 114: > >> 112: list.add(f); >> 113: >> 114: Frame ditherfs = new Frame("DitherTest GC#" + Integer.toString(i), gc[i]); > > Can be simplified: > Suggestion: > > Frame ditherfs = new Frame("DitherTest GC#" + i, gc[i]); code updated. > test/jdk/java/awt/Frame/MultiScreenTest.java line 115: > >> 113: >> 114: Frame ditherfs = new Frame("DitherTest GC#" + Integer.toString(i), gc[i]); >> 115: ditherfs.setLayout(new BorderLayout()); // showDitherTest > > The comment is misleading: setting a layout doesn't show anything. > Suggestion: > > ditherfs.setLayout(new BorderLayout()); comment removed. > test/jdk/java/awt/Frame/MultiScreenTest.java line 140: > >> 138: super(gc); >> 139: this.gc = gc; >> 140: bounds = gc.getBounds(); > > Remove > > Graphics g = this.getGraphics(); > > This field is unused. line removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128224893 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128227891 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128228950 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128232394 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128231557 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128232848 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128222035 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128226551 From duke at openjdk.org Thu Jun 5 08:20:55 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 08:20:55 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v8] In-Reply-To: <3lGnjn3R3swqqZWUVEdPP3Pqcurkwq-l15wPM4_gnOs=.94cc6cb2-2bd6-409a-9dbe-9535edb3d28b@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> <3lGnjn3R3swqqZWUVEdPP3Pqcurkwq-l15wPM4_gnOs=.94cc6cb2-2bd6-409a-9dbe-9535edb3d28b@github.com> Message-ID: On Wed, 4 Jun 2025 19:06:57 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Removes unnecessary lines and keep consistent code format > > test/jdk/java/awt/Frame/MultiScreenTest.java line 91: > >> 89: .columns(40) >> 90: .testUI(obj::init) >> 91: .build() > > Suggestion: > > .testUI(obj::init) > .positionTestUI(MultiScreenTest::positionTestWindows) > .build() > > > where > > > private static void positionTestWindows(List testWindows, > PassFailJFrame.InstructionUI instructionUI) { > // Do nothing - the location of each window is set when they're created > } > > This allows keeping both created frames / windows `Screen#` and `DitherTest GC#` together for each screen. > > Perhaps, such a null layout should be added as library method into [`WindowLayouts.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/regtesthelpers/WindowLayouts.java). Method created and code updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128241063 From duke at openjdk.org Thu Jun 5 08:25:53 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 08:25:53 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v8] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Wed, 4 Jun 2025 18:43:14 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Removes unnecessary lines and keep consistent code format > > test/jdk/java/awt/Frame/MultiScreenTest.java line 1: > >> 1: /* > > Could you make the other classes nested inside `MultiScreenTest`? Classes made static and nested inside MultiScreenTest ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2128249267 From duke at openjdk.org Thu Jun 5 09:35:16 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 09:35:16 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v10] In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: > Fixes issue in which the test fails when run on multi-screen machine. > > Tested on Ubuntu 24.04, MacOS 15 and Windows 11 > > JTREG > > runner starting test: java/awt/Frame/MultiScreenTest.java > runner finished test: java/awt/Frame/MultiScreenTest.java > Passed. Execution successful Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision: - Nests classes inside test class - Cleans up code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24752/files - new: https://git.openjdk.org/jdk/pull/24752/files/2830acc4..1546069b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=08-09 Stats: 458 lines in 1 file changed: 139 ins; 135 del; 184 mod Patch: https://git.openjdk.org/jdk/pull/24752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24752/head:pull/24752 PR: https://git.openjdk.org/jdk/pull/24752 From duke at openjdk.org Thu Jun 5 09:41:56 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 09:41:56 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v2] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Wed, 30 Apr 2025 17:21:21 GMT, Alexey Ivanov wrote: >>> #21942 >> >> Thanks @aivanov-jdk for suggesting the correct route. >> >> @kboulanou Please modify the test to run for all platforms and you can limit the number of graphics configuration to 10 for linux. > >> @kumarabhi006 I am aware that I should not force push to PR. But, I made the mistake of pushing updates (sync) from master to this PR so it added 200 commits to this PR, which will make the PR confusing. I should have updated master and fork and rebased my branch on it and then push to PR. I will be more careful in the future. Please suggest if this is OK. Thanks. > > @kboulanou Merging master is safe. > > **Don't use `git rebase`**, though. Never use `git rebase` after you published your branch for PR. > > If you merge (sync) changes from master, Git won't show them as differences. The PR compares your branch to master. By merging, you add more commits that already exist in master, which means no changes between master and your branch are added. @aivanov-jdk updates made as suggested. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2943470994 From psadhukhan at openjdk.org Thu Jun 5 12:48:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 5 Jun 2025 12:48:52 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v8] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 21:09:37 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > Update test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java > > Co-authored-by: Alexey Ivanov test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 52: > 50: UIManager.getInstalledLookAndFeels()) { > 51: System.out.println("Testing LAF: " + laf.getClassName()); > 52: SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf)); If setLookAndFeel finds UnsupportedLookAndFeelException then the runTest here is still executed here whereas it shouldn't continue for that L&F...guess you can use a boolean return value for setLookAndFeel. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2128771448 From aivanov at openjdk.org Thu Jun 5 12:55:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 5 Jun 2025 12:55:54 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v8] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 12:46:01 GMT, Prasanta Sadhukhan wrote: >> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java >> >> Co-authored-by: Alexey Ivanov > > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 52: > >> 50: UIManager.getInstalledLookAndFeels()) { >> 51: System.out.println("Testing LAF: " + laf.getClassName()); >> 52: SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf)); > > If setLookAndFeel finds UnsupportedLookAndFeelException then the runTest here is still executed here whereas it shouldn't continue for that L&F...guess you can use a boolean return value for setLookAndFeel. Many tests do this kind of thing? the worse thing that happen is that the test code is run again where it's not required. I'm pretty sure `UnsupportedLookAndFeelException` is a rare situation, and it shouldn't happen for Look and Feels provided by JDK. Shall we treat `UnsupportedLookAndFeelException` as an error and see how it goes? This will makes the code simpler. If it's ever encountered and proved to be a common case, the test will need updating. Otherwise, I'm for keeping it as simple as possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2128785407 From duke at openjdk.org Thu Jun 5 16:56:50 2025 From: duke at openjdk.org (Jeremy Wood) Date: Thu, 5 Jun 2025 16:56:50 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: References: Message-ID: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/JDK-8354646' into JDK-8354646 - 8354646: make UnsupportedLookAndFeelException fail test This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2128771448 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/0c0b417a..30940aa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=07-08 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Thu Jun 5 16:56:52 2025 From: duke at openjdk.org (Jeremy Wood) Date: Thu, 5 Jun 2025 16:56:52 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v8] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 12:53:01 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 52: >> >>> 50: UIManager.getInstalledLookAndFeels()) { >>> 51: System.out.println("Testing LAF: " + laf.getClassName()); >>> 52: SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf)); >> >> If setLookAndFeel finds UnsupportedLookAndFeelException then the runTest here is still executed here whereas it shouldn't continue for that L&F...guess you can use a boolean return value for setLookAndFeel. > > Many tests do this kind of thing? the worse thing that happen is that the test code is run again where it's not required. > > I'm pretty sure `UnsupportedLookAndFeelException` is a rare situation, and it shouldn't happen for Look and Feels provided by JDK. > > Shall we treat `UnsupportedLookAndFeelException` as an error and see how it goes? This will makes the code simpler. If it's ever encountered and proved to be a common case, the test will need updating. Otherwise, I'm for keeping it as simple as possible. This is updated. (I have no preference on the behavior; this was copied and pasted from other test files.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2129319844 From aivanov at openjdk.org Thu Jun 5 17:08:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 5 Jun 2025 17:08:54 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java generates too many frames on Linux [v10] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Thu, 5 Jun 2025 09:35:16 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision: > > - Nests classes inside test class > - Cleans up code Just minor comments. Update the subject of the PR to align with the JBS subject. test/jdk/java/awt/Frame/MultiScreenTest.java line 134: > 132: return list; > 133: } > 134: static class GCCanvas extends Canvas { Leave a blank line between the method and the following class. You may even have two blank lines here. test/jdk/java/awt/Frame/MultiScreenTest.java line 496: > 494: } > 495: } > 496: } Please keep line break as the last character in the file. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2901120947 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2129372187 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2129330758 From duke at openjdk.org Thu Jun 5 17:19:54 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 17:19:54 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v10] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Thu, 5 Jun 2025 09:35:16 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision: > > - Nests classes inside test class > - Cleans up code Title updated as requested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2945348360 From duke at openjdk.org Thu Jun 5 17:19:55 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 17:19:55 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v10] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: <0qrFGDkzCjx4FoT3LhdkPVBvz5Hos84UnBrPM5YyCLY=.f56ba893-e69b-4095-9a22-55d22ef91ecc@github.com> On Thu, 5 Jun 2025 17:05:34 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision: >> >> - Nests classes inside test class >> - Cleans up code > > test/jdk/java/awt/Frame/MultiScreenTest.java line 134: > >> 132: return list; >> 133: } >> 134: static class GCCanvas extends Canvas { > > Leave a blank line between the method and the following class. You may even have two blank lines here. updated as requested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2129426886 From duke at openjdk.org Thu Jun 5 17:23:09 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 5 Jun 2025 17:23:09 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v11] In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: > Fixes issue in which the test fails when run on multi-screen machine. > > Tested on Ubuntu 24.04, MacOS 15 and Windows 11 > > JTREG > > runner starting test: java/awt/Frame/MultiScreenTest.java > runner finished test: java/awt/Frame/MultiScreenTest.java > Passed. Execution successful Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: Adds extra blank lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24752/files - new: https://git.openjdk.org/jdk/pull/24752/files/1546069b..2b5c89a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=09-10 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24752/head:pull/24752 PR: https://git.openjdk.org/jdk/pull/24752 From aturbanov at openjdk.org Thu Jun 5 20:22:57 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 5 Jun 2025 20:22:57 GMT Subject: Integrated: 8357688: Remove unnecessary List.get before remove in PopupFactory In-Reply-To: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com> References: <3fcUgHLShP5HamE2sRaXGbXg2gJzO9xOu28IQ_eVZyo=.1de88e4f-9519-4160-97b8-41072221fc07@github.com> Message-ID: On Sat, 17 May 2025 07:42:59 GMT, Andrey Turbanov wrote: > Instead of separate List.get+List.remove calls we can use single `removeFirst`. It's clearer. This pull request has now been integrated. Changeset: 15178aa2 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/15178aa298e43be3e27121343432f25884db4e5d Stats: 13 lines in 1 file changed: 0 ins; 6 del; 7 mod 8357688: Remove unnecessary List.get before remove in PopupFactory Reviewed-by: azvegint, kizune, serb ------------- PR: https://git.openjdk.org/jdk/pull/25283 From aivanov at openjdk.org Thu Jun 5 22:43:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 5 Jun 2025 22:43:55 GMT Subject: RFR: 8355904: Use variadic macros for J2dTrace [v6] In-Reply-To: References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> Message-ID: On Thu, 22 May 2025 20:44:30 GMT, Nikita Gubarkov wrote: >> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead. >> >> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style. > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > Update D3DShaderGen.c Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24949#pullrequestreview-2902785474 From aivanov at openjdk.org Thu Jun 5 22:45:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 5 Jun 2025 22:45:55 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v11] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Thu, 5 Jun 2025 17:23:09 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Adds extra blank lines Changes requested by aivanov (Reviewer). test/jdk/java/awt/Frame/MultiScreenTest.java line 499: > 497: } > 498: } > 499: Suggestion: } One is enough. ------------- PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2902796150 PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2130747995 From aivanov at openjdk.org Thu Jun 5 22:52:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 5 Jun 2025 22:52:53 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v11] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: <0ejRDp_u_cHb1-bkR8y-6icRzjrVDgpcxTG9iWbGr1s=.9cc8f9f4-525f-4700-ad8a-27ff8af5696c@github.com> On Thu, 5 Jun 2025 22:42:52 GMT, Alexey Ivanov wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Adds extra blank lines > > test/jdk/java/awt/Frame/MultiScreenTest.java line 499: > >> 497: } >> 498: } >> 499: > > Suggestion: > > } > > One is enough. You shouldn't see any diff at the very end of the file, at the last line of the file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2130775435 From mickleness at gmail.com Fri Jun 6 01:14:18 2025 From: mickleness at gmail.com (Jeremy Wood) Date: Fri, 06 Jun 2025 01:14:18 +0000 Subject: Security Concern: JPasswordField Revealing Passwords in Memory In-Reply-To: References: Message-ID: Should this be written up at https://bugreport.java.com/bugreport/ , or does it deserve special treatment as a security vulnerability (and if so, what is that protocol)? I was unable to review the document without an ibm account, so I can?t comment further on the problem or any potential resolution(s). Sruthy: if you are an Oracle customer or partner there may be other faster channels to discuss this. Regards, - Jeremy ------ Original Message ------ >From "Sruthy Jayan" To "client-libs-dev at openjdk.org" Cc "Swathi Kalahastri" ; "Syed Moinudeen" Date 6/4/2025 1:42:01?AM Subject Security Concern: JPasswordField Revealing Passwords in Memory >Hi Team , > >We are encountering a potential security issue with JPasswordField in >the latest version of OpenJDK. While the issue is not present in OpenJ9 >version 0.40.0, it becomes reproducible in version 0.41.0. >Specifically, after typing or pasting a password into the field, memory >inspection tools can reveal the password in plain text?even before the >password is submitted or any action is triggered. >This behaviour is reproducible and raises concerns about sensitive data >being exposed unintentionally. >We have attached a detailed document ( ClearPasswordInMemoryIssue >1.docx >) >outlining the issue, steps to reproduce, and our observations. >Could someone from the community assist us in investigating or >addressing this issue? Please let us know if any additional information >is needed. >Thank you for your time and support. >Best Regards, >Sruthy Jayan -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.org Fri Jun 6 03:25:01 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 03:25:01 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> Message-ID: <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> On Thu, 5 Jun 2025 16:56:50 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/JDK-8354646' into JDK-8354646 > - 8354646: make UnsupportedLookAndFeelException fail test > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2128771448 test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 27: > 25: * @test > 26: * @key headful > 27: * @bug 4231444 8354646 This bugid needs to be added to java/awt/TextField/SetEchoCharWordOpsTest.java also as that is the original test which raises this issue. test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 33: > 31: * identify spaces in the password. 8354646 is an offshoot of 4231444 that > 32: * reproduced in Aqua because AquaTextPasswordFieldUI does NOT extend > 33: * BasicPasswordFieldUI. Please align the text below "Password" word not to be in same line as jtreg tag.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131430468 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131431316 From psadhukhan at openjdk.org Fri Jun 6 03:25:01 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 03:25:01 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v8] In-Reply-To: References: Message-ID: On Thu, 5 Jun 2025 16:53:37 GMT, Jeremy Wood wrote: >> Many tests do this kind of thing? the worse thing that happen is that the test code is run again where it's not required. >> >> I'm pretty sure `UnsupportedLookAndFeelException` is a rare situation, and it shouldn't happen for Look and Feels provided by JDK. >> >> Shall we treat `UnsupportedLookAndFeelException` as an error and see how it goes? This will makes the code simpler. If it's ever encountered and proved to be a common case, the test will need updating. Otherwise, I'm for keeping it as simple as possible. > > This is updated. (I have no preference on the behavior regarding UnsupportedLookAndFeelExceptions; this was copied and pasted from other test files.) I guess I am for not treating UnsupportedLookAndFeelException as an error. It will cause the test to stop executing the next L&F if there is one in the list after the unsupported L&F. I have seen this exception in CI testing for GTK L&F but I guess it's for headless environment so I agree it's rare and will not happen in normal case..I was just thinking why to cause unnecessary execution..It maynot matter much for this test but for tests which uses Robot and has delay/waitForIdle executing already run L&F because of UnsupportedException will cause additional cycle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131429289 From psadhukhan at openjdk.org Fri Jun 6 03:27:56 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 03:27:56 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> Message-ID: On Thu, 5 Jun 2025 16:56:50 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/JDK-8354646' into JDK-8354646 > - 8354646: make UnsupportedLookAndFeelException fail test > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2128771448 src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java line 116: > 114: */ > 115: @Override > 116: protected void installKeyboardActions() { Please update the copyright year ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131433167 From psadhukhan at openjdk.org Fri Jun 6 03:35:46 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 03:35:46 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow Message-ID: ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" Made sure there is no overflow and treat that loadImage as ABORTED No regression testcase as it addresses theoretical possibility.. ------------- Commit messages: - getNextID in ImageIcon class can lead to overflow Changes: https://git.openjdk.org/jdk/pull/25666/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25666&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8055461 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25666.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25666/head:pull/25666 PR: https://git.openjdk.org/jdk/pull/25666 From abhiscxk at openjdk.org Fri Jun 6 05:32:02 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 6 Jun 2025 05:32:02 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v6] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Wed, 4 Jun 2025 17:14:15 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Limit running test only on windows LGTM. Verified the test case with the fix and don't see any assertions hit on Windows 11. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24614#pullrequestreview-2903824031 From serb at openjdk.org Fri Jun 6 05:47:47 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 6 Jun 2025 05:47:47 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile Message-ID: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> This PR simplifies several aspects of the ICC_Profile class: - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30): The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377). - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe): In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation. - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c): After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code. @prrace @honkar-jdk please take a look ------------- Commit messages: - Update CheckVersions.java - Create CheckVersions.java - ICC -> CMM - Eliminate possible NPE when getData is used - Replace getData(icSigHead) by the getData(cmmProfile(), icSigHead) - Avoid arraycopy in getInstance(byte[]) Changes: https://git.openjdk.org/jdk/pull/25650/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25650&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358623 Stats: 124 lines in 4 files changed: 89 ins; 18 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/25650.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25650/head:pull/25650 PR: https://git.openjdk.org/jdk/pull/25650 From serb at openjdk.org Fri Jun 6 05:47:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 6 Jun 2025 05:47:48 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile In-Reply-To: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: On Wed, 4 Jun 2025 23:39:05 GMT, Sergey Bylokhov wrote: > This PR simplifies several aspects of the ICC_Profile class: > > - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30): > The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377). > > - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe): > In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation. > > - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c): > After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code. > > @prrace @honkar-jdk please take a look src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 814: > 812: if (type == ColorSpace.TYPE_GRAY) { > 813: return new ICC_ProfileGray(p); > 814: } else if (type == ColorSpace.TYPE_RGB) { The above checks are moved to the corresponding constructors. test/jdk/java/awt/color/ICC_Profile/CheckVersions.java line 61: > 59: } > 60: } > 61: } Also added a test for the changed methods, since they were not covered by any jtreg tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2130946342 PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2130957346 From serb at openjdk.org Fri Jun 6 05:47:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 6 Jun 2025 05:47:50 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile In-Reply-To: References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: On Thu, 5 Jun 2025 23:44:18 GMT, Sergey Bylokhov wrote: >> This PR simplifies several aspects of the ICC_Profile class: >> >> - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30): >> The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377). >> >> - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe): >> In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation. >> >> - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c): >> After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code. >> >> @prrace @honkar-jdk please take a look > > test/jdk/java/awt/color/ICC_Profile/CheckVersions.java line 61: > >> 59: } >> 60: } >> 61: } > > Also added a test for the changed methods, since they were not covered by any jtreg tests. Interestingly, ICC_Profile.getMinorVersion() does not return just the minor version as specified, but instead returns the raw byte, which includes both the minor and patch versions. Perhaps the specification should be updated to reflect this behavior? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2130961674 From duke at openjdk.org Fri Jun 6 05:58:43 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 05:58:43 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v10] In-Reply-To: References: Message-ID: <5tqSZqCC5WdsF8SvV4ddN2e9aYNOaUZPeA0UqFTAxAk=.6eff18d8-99e0-45de-85a1-337059d4f979@github.com> > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with three additional commits since the last revision: - 8354646: skip L&F for UnsupportedLookAndFeelException This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131429289 - 8354646: update copyright year This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131433167 - 8354646: align text below "Password" Also shorten comment to better match the brevity observed with other @summary tags. This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131431316 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/30940aa9..b004f89f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=08-09 Stats: 20 lines in 2 files changed: 10 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Fri Jun 6 05:58:44 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 05:58:44 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v10] In-Reply-To: References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> Message-ID: On Fri, 6 Jun 2025 03:25:20 GMT, Prasanta Sadhukhan wrote: >> Jeremy Wood has updated the pull request incrementally with three additional commits since the last revision: >> >> - 8354646: skip L&F for UnsupportedLookAndFeelException >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131429289 >> - 8354646: update copyright year >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131433167 >> - 8354646: align text below "Password" >> >> Also shorten comment to better match the brevity observed with other @summary tags. >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131431316 > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java line 116: > >> 114: */ >> 115: @Override >> 116: protected void installKeyboardActions() { > > Please update the copyright year OK; this is updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131554911 From duke at openjdk.org Fri Jun 6 05:58:45 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 05:58:45 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> Message-ID: On Fri, 6 Jun 2025 03:21:47 GMT, Prasanta Sadhukhan wrote: >> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/JDK-8354646' into JDK-8354646 >> - 8354646: make UnsupportedLookAndFeelException fail test >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2128771448 > > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 33: > >> 31: * identify spaces in the password. 8354646 is an offshoot of 4231444 that >> 32: * reproduced in Aqua because AquaTextPasswordFieldUI does NOT extend >> 33: * BasicPasswordFieldUI. > > Please align the text below "Password" word not to be in same line as jtreg tag.. OK; this is updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131555013 From duke at openjdk.org Fri Jun 6 05:58:46 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 05:58:46 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v8] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:18:15 GMT, Prasanta Sadhukhan wrote: >> This is updated. (I have no preference on the behavior regarding UnsupportedLookAndFeelExceptions; this was copied and pasted from other test files.) > > I guess I am for not treating UnsupportedLookAndFeelException as an error. It will cause the test to stop executing the next L&F if there is one in the list after the unsupported L&F. Previous one is still better in my opinion if we do not want to check for setLookAndFeel return.. > > I have seen this exception in CI testing for GTK L&F but I guess it's for headless environment so I agree it's rare and will not happen in normal case..I was just thinking why to cause unnecessary execution..It maynot matter much for this test but for tests which uses Robot and has delay/waitForIdle executing already run L&F because of UnsupportedException will cause additional cycle. I updated this so a UnsupportedLookAndFeelException logs an error but does not abort the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131555608 From duke at openjdk.org Fri Jun 6 06:41:56 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 06:41:56 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> Message-ID: On Fri, 6 Jun 2025 03:20:19 GMT, Prasanta Sadhukhan wrote: >> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/JDK-8354646' into JDK-8354646 >> - 8354646: make UnsupportedLookAndFeelException fail test >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2128771448 > > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 27: > >> 25: * @test >> 26: * @key headful >> 27: * @bug 4231444 8354646 > > This bugid needs to be added to java/awt/TextField/SetEchoCharWordOpsTest.java also as that is the original test which raises this issue. I'm confused by this ask. Are you asking me to update SetEchoCharWordOpsTest.java to include this line: ` * @bug 6191897 4231444 8354646` I understand topically these tickets are all related, but I ran SetEchoCharWordOpsTest in Aqua using master and this branch: I didn't perceive any difference. (For context: the git history doesn't really show me if any changes accompanied SetEchoCharWordOpsTest , but I think it passes because of code like this: `"PasswordField.focusInputMap", aquaKeyBindings.getPasswordFieldInputMap()` ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131602888 From psadhukhan at openjdk.org Fri Jun 6 07:15:53 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 07:15:53 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> Message-ID: On Fri, 6 Jun 2025 06:39:22 GMT, Jeremy Wood wrote: >> test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 27: >> >>> 25: * @test >>> 26: * @key headful >>> 27: * @bug 4231444 8354646 >> >> This bugid needs to be added to java/awt/TextField/SetEchoCharWordOpsTest.java also as that is the original test which raises this issue. > > I'm confused by this ask. Are you asking me to update SetEchoCharWordOpsTest.java to include this line: > > ` * @bug 6191897 4231444 8354646` > > I understand topically these tickets are all related, but I ran SetEchoCharWordOpsTest in Aqua using master and this branch: I didn't perceive any difference. > > (For context: the git history doesn't really show me if any changes accompanied SetEchoCharWordOpsTest , but I think it passes because of code like this: `"PasswordField.focusInputMap", aquaKeyBindings.getPasswordFieldInputMap()` ) I am asking to add "this bugid" 8354646 in SetEchoCharWordOpsTest.java... I see if we double click at beginning and/or at the end it will identify "One" and "Three" separately which is not desirable and it will fail the test checkpoint "if you are able to move the caret word-by-word press Fail" as caret can be placed in between those words before the fix.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131645722 From duke at openjdk.org Fri Jun 6 07:28:37 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 07:28:37 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v11] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8354646: update SetEchoCharWordOpsTest to refer to 8354646 This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131645722 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/b004f89f..39d19f27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Fri Jun 6 07:33:52 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 07:33:52 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> Message-ID: On Fri, 6 Jun 2025 07:12:52 GMT, Prasanta Sadhukhan wrote: >> I'm confused by this ask. Are you asking me to update SetEchoCharWordOpsTest.java to include this line: >> >> ` * @bug 6191897 4231444 8354646` >> >> I understand topically these tickets are all related, but I ran SetEchoCharWordOpsTest in Aqua using master and this branch: I didn't perceive any difference. >> >> (For context: the git history doesn't really show me if any changes accompanied SetEchoCharWordOpsTest , but I think it passes because of code like this: `"PasswordField.focusInputMap", aquaKeyBindings.getPasswordFieldInputMap()` ) > > I am asking to add "this bugid" 8354646 in SetEchoCharWordOpsTest.java... > I see if we double click at beginning and/or at the end it will identify "One" and "Three" separately which is not desirable and it will fail the test checkpoint "if you are able to move the caret word-by-word press Fail" as caret can be placed in between those words before the fix.. Hmm. Sorry; I feel like I'm still not quite understanding the ask. Is this what you're asking for? https://github.com/openjdk/jdk/pull/25443/commits/39d19f2772cd980f0ee8b812de1b748de858ef56 IMO this feels weird: A. We'd also need to update the instructions in that test, yes? B. If we want that test to cover 8354646, then we can delete PasswordSelectionWordTest from this PR, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131671179 From duke at openjdk.org Fri Jun 6 07:41:51 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 07:41:51 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v5] In-Reply-To: References: <9OsgP7Nt-I4n_uqYEzVaNAbp-3rYf4ozSFmiWyDoF5Q=.5dc3cbc6-942d-490b-b086-c9803c92ee14@github.com> <7C_922gw6YyrITP7jNbscW8Us16vSv6B3GKMvFs_XYE=.fca6f4f3-a101-4fcb-b032-e7934f82ac50@github.com> Message-ID: On Tue, 3 Jun 2025 05:44:21 GMT, Prasanta Sadhukhan wrote: >>> Does the accompanying testcase fails in Synth/Nimbus L&F, it seems not? >> >> No. I double-checked: >> A. If I explicitly set the L&F to Nimbus: this test does fail in this PR, and it does not fail in master. >> B. The SynthPasswordFieldUI descends from BasicTextUI, so it should not be impacted by this PR. >> >> ... and in reviewing the SynthPasswordFieldUI I found the same code (copied & pasted) from BasicPasswordFieldUI. I removed that, because with this PR it should not be necessary. (And I did NOT find other instances of the same code copied and pasted anywhere else.) >> >>> Also, it will be useful to extend the test case to test all installed L&F since it it changing Basic L&F code? >> >> I'm not sure what you're asking here. >> >> I tweaked the test so it aborts if it is NOT interacting with a BasicTextUI. (Off the top of my head I don't know of any JPasswordField UI's that don't subclass BasicTextUI, but they might exist somewhere.) > >> > Does the accompanying testcase fails in Synth/Nimbus L&F, it seems not? >> >> No. I double-checked: A. If I explicitly set the L&F to Nimbus: this test does fail in this PR, and it does not fail in master. B. The SynthPasswordFieldUI descends from BasicTextUI, so it should not be impacted by this PR. > > Since you mentioned at the beginning that` AquaTextPasswordFieldUI (and SynthPasswordFieldUI) do NOT extend the BasicPasswordFieldUI, so they weren't inheriting this solution`. > so I assumed the regression testcase should fail in Aqua and Nimbus wiithout your fix but it fails in Aqua and not in Nimbus so I asked. > It seems you have modified your initial PR description to NOT include Synth now so it means the problem exists only in Aqua L&F in JDK mainline, am i correct? > > >> >> Also, it will be useful to extend the test case to test all installed L&F since it it changing Basic L&F code? >> >> I'm not sure what you're asking here. > > I meant the present regression testcase only tests the system L&F of the platform it is run ie Metal in WIndows, Linux and Aqua in Mac and does not test all L&Fs like Nimbus, Motif, WIndows, GTK so you should check for `UIManager.getInstalledLookAndFeels() `and iterate and test all the installed L&Fs of the current platform..You will find many such example of the L&F testing in `test/javax/swing` folder (@prsadhuk on a related note: your comments about SetEchoCharWordOpsTest led me to more research which resulted in writing up bug report 9078598 .) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2948367723 From psadhukhan at openjdk.org Fri Jun 6 07:41:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 07:41:52 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v9] In-Reply-To: References: <_6dST_7IND1ObQU9NWwf-zntTWN_SCdHm3TbHhNBgd4=.24e47914-a485-4797-b95f-135bfea3f4d7@github.com> <4z4PEMhbOWt81WeoknORfBRtmXO2bDL8HIN4HtB0avs=.b9df9734-9740-49eb-9585-cb573a3b393c@github.com> Message-ID: On Fri, 6 Jun 2025 07:31:15 GMT, Jeremy Wood wrote: > Is this what you're asking for yes > If we want that test to cover [8354646](https://github.com/openjdk/jdk/commit/8354646387b87f643935d7372061b8a5eb2db7a1), then we can delete PasswordSelectionWordTest from this PR, right? No, that is manual..This is automated which is more desirable.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131677419 From psadhukhan at openjdk.org Fri Jun 6 07:41:54 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 07:41:54 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v11] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 07:28:37 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: update SetEchoCharWordOpsTest to refer to 8354646 > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131645722 test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 64: > 62: e.printStackTrace(); > 63: return false; > 64: } catch (RuntimeException e) { guess this catch block is not needed test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 94: > 92: if (selectionStart != 0 || selectionEnd != str.length()) { > 93: throw new Error("selectionStart = " + selectionStart + > 94: " and selectionEnd = " + selectionEnd); please change to RuntimeException to make it consistent with other tests ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131680454 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131681790 From duke at openjdk.org Fri Jun 6 07:51:11 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 07:51:11 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: - 8354646: change Error to RuntimeException This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131681790 - 8354646: removing catching RuntimeException This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131680454 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/39d19f27..c4c47d89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=10-11 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From psadhukhan at openjdk.org Fri Jun 6 07:51:11 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Jun 2025 07:51:11 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 07:48:18 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: > > - 8354646: change Error to RuntimeException > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131681790 > - 8354646: removing catching RuntimeException > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131680454 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2904082424 From duke at openjdk.org Fri Jun 6 08:00:34 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Fri, 6 Jun 2025 08:00:34 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v12] In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: > Fixes issue in which the test fails when run on multi-screen machine. > > Tested on Ubuntu 24.04, MacOS 15 and Windows 11 > > JTREG > > runner starting test: java/awt/Frame/MultiScreenTest.java > runner finished test: java/awt/Frame/MultiScreenTest.java > Passed. Execution successful 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 11 additional commits since the last revision: - Removes extra blank line - Merge branch 'openjdk:master' into jdk-8352149 - Adds extra blank lines - Nests classes inside test class - Cleans up code - Merge branch 'openjdk:master' into jdk-8352149 - Removes unnecessary lines and keep consistent code format - Merge branch 'openjdk:master' into jdk-8352149 - Adds Override for overriden methods - Merge branch 'openjdk:master' into jdk-8352149 - ... and 1 more: https://git.openjdk.org/jdk/compare/3e7a4429...44a839b2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24752/files - new: https://git.openjdk.org/jdk/pull/24752/files/2b5c89a2..44a839b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24752&range=10-11 Stats: 7684 lines in 227 files changed: 6277 ins; 940 del; 467 mod Patch: https://git.openjdk.org/jdk/pull/24752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24752/head:pull/24752 PR: https://git.openjdk.org/jdk/pull/24752 From duke at openjdk.org Fri Jun 6 08:00:34 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Fri, 6 Jun 2025 08:00:34 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v11] In-Reply-To: <0ejRDp_u_cHb1-bkR8y-6icRzjrVDgpcxTG9iWbGr1s=.9cc8f9f4-525f-4700-ad8a-27ff8af5696c@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> <0ejRDp_u_cHb1-bkR8y-6icRzjrVDgpcxTG9iWbGr1s=.9cc8f9f4-525f-4700-ad8a-27ff8af5696c@github.com> Message-ID: On Thu, 5 Jun 2025 22:50:25 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/Frame/MultiScreenTest.java line 499: >> >>> 497: } >>> 498: } >>> 499: >> >> Suggestion: >> >> } >> >> One is enough. > > You shouldn't see any diff at the very end of the file, at the last line of the file. Extra blank line removed. I will pay attention to this detail in the future. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24752#discussion_r2131708128 From duke at openjdk.org Fri Jun 6 08:04:54 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 08:04:54 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v11] In-Reply-To: References: Message-ID: <_Cw1TdraYCRvPJk4KNMTDq2552VVXzE0KfWHS99Ry1E=.2b6f0970-c7d4-4e89-b4a1-6062647f69f2@github.com> On Fri, 6 Jun 2025 07:37:54 GMT, Prasanta Sadhukhan wrote: >> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354646: update SetEchoCharWordOpsTest to refer to 8354646 >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131645722 > > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 64: > >> 62: e.printStackTrace(); >> 63: return false; >> 64: } catch (RuntimeException e) { > > guess this catch block is not needed OK; this is updated > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 94: > >> 92: if (selectionStart != 0 || selectionEnd != str.length()) { >> 93: throw new Error("selectionStart = " + selectionStart + >> 94: " and selectionEnd = " + selectionEnd); > > please change to RuntimeException to make it consistent with other tests OK; this is updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131716706 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131716615 From ngubarkov at openjdk.org Fri Jun 6 08:36:40 2025 From: ngubarkov at openjdk.org (Nikita Gubarkov) Date: Fri, 6 Jun 2025 08:36:40 GMT Subject: RFR: 8355904: Use variadic macros for J2dTrace [v7] In-Reply-To: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> Message-ID: > J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead. > > Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style. Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8355904 - Update D3DShaderGen.c - fixup! 8355904: Use variadic macros for J2dTrace - fixup! 8355904: Use variadic macros for J2dTrace - fixup! 8355904: Use variadic macros for J2dTrace - Apply suggestions from code review Co-authored-by: Alexey Ivanov - fixup! 8355904: Use variadic macros for J2dTrace - 8355904: Use variadic macros for J2dTrace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24949/files - new: https://git.openjdk.org/jdk/pull/24949/files/41ce75f2..a4f9d118 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24949&range=05-06 Stats: 202333 lines in 3676 files changed: 124546 ins; 52157 del; 25630 mod Patch: https://git.openjdk.org/jdk/pull/24949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24949/head:pull/24949 PR: https://git.openjdk.org/jdk/pull/24949 From duke at openjdk.org Fri Jun 6 08:49:53 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 08:49:53 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:29:47 GMT, Prasanta Sadhukhan wrote: > ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. > > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" > > Made sure there is no overflow and treat that loadImage as ABORTED > > No regression testcase as it addresses theoretical possibility.. src/java.desktop/share/classes/javax/swing/ImageIcon.java line 305: > 303: return; > 304: } > 305: mTracker.addImage(image, id); Hmm. Is there any acceptable logging we could use here? (I'm just thinking: from the perspective of a developer trying to debug a customer complaint, this would be a lot easier to identify in System.err mentioned it...? Otherwise I'd start by trying to look for potential memory leaks or other red herrings.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2131791117 From ngubarkov at openjdk.org Fri Jun 6 09:44:56 2025 From: ngubarkov at openjdk.org (Nikita Gubarkov) Date: Fri, 6 Jun 2025 09:44:56 GMT Subject: RFR: 8355904: Use variadic macros for J2dTrace [v7] In-Reply-To: References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> Message-ID: On Wed, 28 May 2025 02:42:28 GMT, Sergey Bylokhov wrote: >> Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8355904 >> - Update D3DShaderGen.c >> - fixup! 8355904: Use variadic macros for J2dTrace >> - fixup! 8355904: Use variadic macros for J2dTrace >> - fixup! 8355904: Use variadic macros for J2dTrace >> - Apply suggestions from code review >> >> Co-authored-by: Alexey Ivanov >> - fixup! 8355904: Use variadic macros for J2dTrace >> - 8355904: Use variadic macros for J2dTrace > > Please confirm that you have built the debug versions on all platforms and checked the output for at least some of these methods. @mrserb confirmed, I have built debug versions on 3 platforms and tested the output, did that again after the merge. @prrace done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24949#issuecomment-2948681633 From aivanov at openjdk.org Fri Jun 6 09:50:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Jun 2025 09:50:54 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v12] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Fri, 6 Jun 2025 08:00:34 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > 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 11 additional commits since the last revision: > > - Removes extra blank line > - Merge branch 'openjdk:master' into jdk-8352149 > - Adds extra blank lines > - Nests classes inside test class > - Cleans up code > - Merge branch 'openjdk:master' into jdk-8352149 > - Removes unnecessary lines and keep consistent code format > - Merge branch 'openjdk:master' into jdk-8352149 > - Adds Override for overriden methods > - Merge branch 'openjdk:master' into jdk-8352149 > - ... and 1 more: https://git.openjdk.org/jdk/compare/c66e4726...44a839b2 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24752#pullrequestreview-2904416225 From duke at openjdk.org Fri Jun 6 09:54:52 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Fri, 6 Jun 2025 09:54:52 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v2] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Wed, 30 Apr 2025 17:21:21 GMT, Alexey Ivanov wrote: >>> #21942 >> >> Thanks @aivanov-jdk for suggesting the correct route. >> >> @kboulanou Please modify the test to run for all platforms and you can limit the number of graphics configuration to 10 for linux. > >> @kumarabhi006 I am aware that I should not force push to PR. But, I made the mistake of pushing updates (sync) from master to this PR so it added 200 commits to this PR, which will make the PR confusing. I should have updated master and fork and rebased my branch on it and then push to PR. I will be more careful in the future. Please suggest if this is OK. Thanks. > > @kboulanou Merging master is safe. > > **Don't use `git rebase`**, though. Never use `git rebase` after you published your branch for PR. > > If you merge (sync) changes from master, Git won't show them as differences. The PR compares your branch to master. By merging, you add more commits that already exist in master, which means no changes between master and your branch are added. @aivanov-jdk May I go ahead and issue integrate command to this PR ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2948708575 From aivanov at openjdk.org Fri Jun 6 09:59:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Jun 2025 09:59:50 GMT Subject: RFR: 8355904: Use variadic macros for J2dTrace [v6] In-Reply-To: References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> Message-ID: On Fri, 30 May 2025 21:32:42 GMT, Phil Race wrote: > I would like to run this through our build system - which will build the debug builds as well as product but I find that a recent change means the patch doesn't apply.\ > So pls merge the change with latest master and I will try after you've done that I pulled the branch locally, merged it with master and ran the client CI overnight. **All's green.** ------------- PR Comment: https://git.openjdk.org/jdk/pull/24949#issuecomment-2948720912 From aivanov at openjdk.org Fri Jun 6 10:06:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Jun 2025 10:06:55 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v2] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: <8-5k8RjhbVXgYXjMNcXNEzHJG1PHHJZbdnyLZxECHiU=.2b6244db-64c7-4d5b-82e3-00b3ff8651be@github.com> On Wed, 30 Apr 2025 17:21:21 GMT, Alexey Ivanov wrote: >>> #21942 >> >> Thanks @aivanov-jdk for suggesting the correct route. >> >> @kboulanou Please modify the test to run for all platforms and you can limit the number of graphics configuration to 10 for linux. > >> @kumarabhi006 I am aware that I should not force push to PR. But, I made the mistake of pushing updates (sync) from master to this PR so it added 200 commits to this PR, which will make the PR confusing. I should have updated master and fork and rebased my branch on it and then push to PR. I will be more careful in the future. Please suggest if this is OK. Thanks. > > @kboulanou Merging master is safe. > > **Don't use `git rebase`**, though. Never use `git rebase` after you published your branch for PR. > > If you merge (sync) changes from master, Git won't show them as differences. The PR compares your branch to master. By merging, you add more commits that already exist in master, which means no changes between master and your branch are added. > @aivanov-jdk May I go ahead and issue integrate command to this PR ? Yes. I'll leave the PR open for a while before I sponsor it to give anyone else to look at the updated code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2948738191 From duke at openjdk.org Fri Jun 6 10:06:57 2025 From: duke at openjdk.org (duke) Date: Fri, 6 Jun 2025 10:06:57 GMT Subject: RFR: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty [v12] In-Reply-To: References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Fri, 6 Jun 2025 08:00:34 GMT, Khalid Boulanouare wrote: >> Fixes issue in which the test fails when run on multi-screen machine. >> >> Tested on Ubuntu 24.04, MacOS 15 and Windows 11 >> >> JTREG >> >> runner starting test: java/awt/Frame/MultiScreenTest.java >> runner finished test: java/awt/Frame/MultiScreenTest.java >> Passed. Execution successful > > 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 11 additional commits since the last revision: > > - Removes extra blank line > - Merge branch 'openjdk:master' into jdk-8352149 > - Adds extra blank lines > - Nests classes inside test class > - Cleans up code > - Merge branch 'openjdk:master' into jdk-8352149 > - Removes unnecessary lines and keep consistent code format > - Merge branch 'openjdk:master' into jdk-8352149 > - Adds Override for overriden methods > - Merge branch 'openjdk:master' into jdk-8352149 > - ... and 1 more: https://git.openjdk.org/jdk/compare/dd800238...44a839b2 @kboulanou Your change (at version 44a839b242f0f9995499659bdfc7bf74ed5d8a36) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24752#issuecomment-2948743768 From aivanov at openjdk.org Fri Jun 6 10:20:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Jun 2025 10:20:54 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 07:51:11 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: > > - 8354646: change Error to RuntimeException > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131681790 > - 8354646: removing catching RuntimeException > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131680454 src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 654: > 652: // Create the action map for Password Field. This map provides > 653: // same actions for double mouse click and > 654: // and for triple mouse click (see bugs 4231444, 8354646). Replace ?create? with ?edit?? src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 662: > 660: map.put(DefaultEditorKit.selectWordAction, a); > 661: } > 662: } I think we should still remove `selectWordAction` even if `selectLineAction` doesn't exist. test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 76: > 74: "because the JPasswordField UI was " + field.getUI()); > 75: return; > 76: } I'd say that this is unexpected, and it's better to throw an exception and fail the test. If not fail the test, then throw `jtreg.SkippedException` to indicate the test doesn't run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131918285 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131922909 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131930548 From aivanov at openjdk.org Fri Jun 6 15:02:05 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Jun 2025 15:02:05 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: <-tW8DaWe-R0y-jrJ2mBFwMkm09lAXhps4OrrxTP0cVY=.6986d1d5-6267-4064-b6f8-9f81ba41e30c@github.com> <06lSBlfuM9g3jDaiR6hPM90JhVB5384Ls9pQJj1lNgY=.4528b1df-2028-49a0-9220-9ee64a292d55@github.com> Message-ID: On Wed, 4 Jun 2025 07:00:33 GMT, Prasanta Sadhukhan wrote: >> I don't think so. Let Java catch it. > > ok..but checkReturnValue in ScreenCastHelper.java doesnt handle the exception for RESULT_ERROR case so it will be left to application to handle and am not sure if they will expect this internal exception.. So, `AWT_UNLOCK()` clears the exception if it occurs during unlocking, and throws any pending exception if it occurred before entering `AWT_UNLOCK()`. Re-throwing `pendingException` creates a pending exception again? Therefore, the code has to bail out with `RESULT_ERROR` and to let Java deal with that exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25605#discussion_r2132347158 From aivanov at openjdk.org Fri Jun 6 15:02:05 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Jun 2025 15:02:05 GMT Subject: RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) [v2] In-Reply-To: References: Message-ID: On Wed, 4 Jun 2025 05:39:36 GMT, Alexander Zvegintsev wrote: >> After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > JNU_CHECK_EXCEPTION_RETURN for GetStringUTFChars Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25605#pullrequestreview-2905176786 From prr at openjdk.org Fri Jun 6 18:41:38 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 6 Jun 2025 18:41:38 GMT Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java Message-ID: The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration removed use of AppContext from java/util/logging/LogManager.java. That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed. There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted. Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass. ------------- Commit messages: - 8358731 Changes: https://git.openjdk.org/jdk/pull/25677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25677&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358731 Stats: 1110 lines in 6 files changed: 0 ins; 1110 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25677/head:pull/25677 PR: https://git.openjdk.org/jdk/pull/25677 From prr at openjdk.org Fri Jun 6 18:41:38 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 6 Jun 2025 18:41:38 GMT Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote: > The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration > removed use of AppContext from java/util/logging/LogManager.java. > That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed. > > There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted. > > Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass. @dfuch please review this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25677#issuecomment-2950146654 From dfuchs at openjdk.org Fri Jun 6 21:28:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 6 Jun 2025 21:28:49 GMT Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote: > The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration > removed use of AppContext from java/util/logging/LogManager.java. > That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed. > > There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted. > > Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25677#pullrequestreview-2906178505 From duke at openjdk.org Fri Jun 6 21:50:44 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 21:50:44 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v13] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI and SynthPasswordFieldUI, but the AquaTextPasswordFieldUI does NOT extend the BasicPasswordFieldUI, so it wasn't inheriting this solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an instanceof to make sure it is only applied to JPasswordFields. > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision: - 8354646: add missing import - 8354646: fixing compiler error typo - 8354646: fail test with exception for unexpected UI This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131930548 - 8354646: remove selectWordAction whether or not selectLineAction exists This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131922909 - 8354646: change "create" to "edit" in comment This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131918285 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/c4c47d89..7aff3231 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=11-12 Stats: 8 lines in 2 files changed: 2 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Fri Jun 6 22:03:56 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 6 Jun 2025 22:03:56 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 10:07:06 GMT, Alexey Ivanov wrote: >> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8354646: change Error to RuntimeException >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131681790 >> - 8354646: removing catching RuntimeException >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131680454 > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 654: > >> 652: // Create the action map for Password Field. This map provides >> 653: // same actions for double mouse click and >> 654: // and for triple mouse click (see bugs 4231444, 8354646). > > Replace ?create? with ?edit?? This is updated > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 662: > >> 660: map.put(DefaultEditorKit.selectWordAction, a); >> 661: } >> 662: } > > I think we should still remove `selectWordAction` even if `selectLineAction` doesn't exist. OK, this is updated > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 76: > >> 74: "because the JPasswordField UI was " + field.getUI()); >> 75: return; >> 76: } > > I'd say that this is unexpected, and it's better to throw an exception and fail the test. If not fail the test, then throw `jtreg.SkippedException` to indicate the test doesn't run. OK, now we throw a RuntimeException to fail the test ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2132955551 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2132955569 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2132955895 From serb at openjdk.org Sat Jun 7 12:52:51 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 7 Jun 2025 12:52:51 GMT Subject: RFR: 8358731: Remove jdk.internal.access.JavaAWTAccess.java In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote: > The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration > removed use of AppContext from java/util/logging/LogManager.java. > That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed. > > There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted. > > Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25677#pullrequestreview-2907352143 From psadhukhan at openjdk.org Mon Jun 9 02:16:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 9 Jun 2025 02:16:50 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 08:47:33 GMT, Jeremy Wood wrote: >> ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. >> >> Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" >> >> Made sure there is no overflow and treat that loadImage as ABORTED >> >> No regression testcase as it addresses theoretical possibility.. > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 305: > >> 303: return; >> 304: } >> 305: mTracker.addImage(image, id); > > Hmm. Is there any acceptable logging we could use here? > > (I'm just thinking: from the perspective of a developer trying to debug a customer complaint, this would be a lot easier to identify in System.err mentioned it...? Otherwise I'd start by trying to look for potential memory leaks or other red herrings.) I dont think there is any logging for this nor do we want to log...In all probability, the image will consume the heap memory so practically OOM will be raised by the time this overflow happens but it can happen if maybe all 1x1 images are used and subsequent needed memory reserved for Java process ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2134929127 From tr at openjdk.org Mon Jun 9 05:45:54 2025 From: tr at openjdk.org (Tejesh R) Date: Mon, 9 Jun 2025 05:45:54 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v13] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 21:50:44 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision: > > - 8354646: add missing import > - 8354646: fixing compiler error typo > - 8354646: fail test with exception for unexpected UI > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131930548 > - 8354646: remove selectWordAction whether or not selectLineAction exists > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131922909 > - 8354646: change "create" to "edit" in comment > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131918285 Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2908975012 From tr at openjdk.org Mon Jun 9 05:45:55 2025 From: tr at openjdk.org (Tejesh R) Date: Mon, 9 Jun 2025 05:45:55 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 07:51:11 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: > > - 8354646: change Error to RuntimeException > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131681790 > - 8354646: removing catching RuntimeException > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131680454 test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 45: > 43: public class PasswordSelectionWordTest { > 44: public static void main(String[] args) throws Exception { > 45: for (UIManager.LookAndFeelInfo laf : Now since the test is for all the look and feel, should it be inside `test/jdk/javax/swing/JPasswordField` folder? Other than this it looks good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2131872951 From duke at openjdk.org Mon Jun 9 06:12:04 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 9 Jun 2025 06:12:04 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 02:14:09 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 305: >> >>> 303: return; >>> 304: } >>> 305: mTracker.addImage(image, id); >> >> Hmm. Is there any acceptable logging we could use here? >> >> (I'm just thinking: from the perspective of a developer trying to debug a customer complaint, this would be a lot easier to identify in System.err mentioned it...? Otherwise I'd start by trying to look for potential memory leaks or other red herrings.) > > I dont think there is any logging for this nor do we want to log...In all probability, the image will consume the heap memory so practically OOM will be raised by the time this overflow happens but it can happen if maybe all 1x1 images are used and subsequent needed memory reserved for Java process OK. I don't feel like I really understand this fix (or the need for it), but I also am not too worried about it. FWIW I was able to trigger this condition in an app that ran for about 30 minutes. (Maybe if I turned up the thread priority it could be faster?) I'm not going to keep exploring this, though, unless a pointed question comes up. import javax.swing.*; import java.awt.*; public class ImageIconTest { public static void main(String[] args) { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { JFrame f = new JFrame(); ImageIcon icon = new ImageIcon(); Image image = Toolkit.getDefaultToolkit().createImage("onepixel.gif"); icon.setImage(image); JLabel label = new JLabel(icon); f.getContentPane().add(label); f.pack(); f.setVisible(true); Thread t = new Thread(new Runnable() { @Override public void run() { while (true) { icon.setImage(image); } } }); t.start(); } }); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2135090608 From duke at openjdk.org Mon Jun 9 06:22:57 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 9 Jun 2025 06:22:57 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v14] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8354646: moving test file to new package This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2131872951 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/7aff3231..19af4e31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=12-13 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Mon Jun 9 06:22:58 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 9 Jun 2025 06:22:58 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: References: Message-ID: <4JeTbApLJF17K76rvlOkhoGJ5BqWNlhpf7JeHszMV_k=.32c417e0-0b22-42cd-a7fa-0b96dc9d0640@github.com> On Fri, 6 Jun 2025 09:36:09 GMT, Tejesh R wrote: >> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8354646: change Error to RuntimeException >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131681790 >> - 8354646: removing catching RuntimeException >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2131680454 > > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 45: > >> 43: public class PasswordSelectionWordTest { >> 44: public static void main(String[] args) throws Exception { >> 45: for (UIManager.LookAndFeelInfo laf : > > Now since the test is for all the look and feel, should it be inside `test/jdk/javax/swing/JPasswordField` folder? > Other than this it looks good to me. Okay; this is moved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2135102051 From ihse at openjdk.org Mon Jun 9 13:33:39 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 13:33:39 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 [v2] In-Reply-To: References: Message-ID: > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into utf8-sequences-in-src - 8356978: Convert unicode sequences in Java source code to UTF-8 ------------- Changes: https://git.openjdk.org/jdk/pull/25229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=01 Stats: 6776 lines in 79 files changed: 0 ins; 0 del; 6776 mod Patch: https://git.openjdk.org/jdk/pull/25229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229 PR: https://git.openjdk.org/jdk/pull/25229 From azvegint at openjdk.org Mon Jun 9 13:37:58 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 9 Jun 2025 13:37:58 GMT Subject: Integrated: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 03:39:31 GMT, Alexander Zvegintsev wrote: > After calling `AWT_UNLOCK()`, `GetStringUTFChars` may be called with a pending exception. This pull request has now been integrated. Changeset: 2103dc15 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) Reviewed-by: psadhukhan, serb, aivanov, avu ------------- PR: https://git.openjdk.org/jdk/pull/25605 From ihse at openjdk.org Mon Jun 9 13:41:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 13:41:10 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 [v3] In-Reply-To: References: Message-ID: > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Reverting fixes in java.xml and jdk.jdi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25229/files - new: https://git.openjdk.org/jdk/pull/25229/files/37bf474c..5a5d7b7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=01-02 Stats: 6759 lines in 76 files changed: 0 ins; 0 del; 6759 mod Patch: https://git.openjdk.org/jdk/pull/25229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229 PR: https://git.openjdk.org/jdk/pull/25229 From ihse at openjdk.org Mon Jun 9 13:41:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 13:41:10 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: On Tue, 27 May 2025 16:31:47 GMT, Justin Lu wrote: >> @justin-curtis-lu Are these files handled by the translation team? > > @magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change. I have now reverted the changes in java.xml and jdk.jdi. I still think these changes should be made, but it should apparently go through the translation team. @justin-curtis-lu Can you help me file a bug report so this gets done? I'm not sure how to do that. Basically, they will need to revert 5a5d7b7b13158c3b35ed9c433e6fdc34aa20b73d. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955820392 From ihse at openjdk.org Mon Jun 9 13:41:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 13:41:10 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: On Tue, 27 May 2025 17:01:13 GMT, Naoto Sato wrote: >> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. > > Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them. @naotoj You okay with this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955822435 From aivanov at openjdk.org Mon Jun 9 14:25:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 9 Jun 2025 14:25:55 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 [v3] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie wrote: >> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Reverting fixes in java.xml and jdk.jdi src/demo/share/jfc/Stylepad/HelloWorld.java line 196: > 194: + "???????" > 195: + "??? ???" > 196: + "?!") Maybe we can merge the string now: Suggestion: new Run("none", "?????? ?????????? ????!") // Greek At least two words seem to be split between the wrapped lines. src/demo/share/jfc/Stylepad/HelloWorld.java line 203: > 201: new Paragraph("title", new Run[] { > 202: new Run("none", "???? ????" > 203: + "????") Suggestion: new Run("none", "???? ????????") src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java line 90: > 88: { "japanese.FirstYear", > 89: new String[] { // first year name > 90: "?", // "Gan"-nen Suggestion: "?", // "Gan"-nen Preserve comment alignment? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135817539 PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135819248 PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135821435 From ihse at openjdk.org Mon Jun 9 15:52:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 15:52:24 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 [v4] In-Reply-To: References: Message-ID: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com> > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision: - Fix comment indentation Co-authored-by: Alexey Ivanov - Concatenate string literals Co-authored-by: Alexey Ivanov - Concatenate string literals Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25229/files - new: https://git.openjdk.org/jdk/pull/25229/files/5a5d7b7b..a9f7acc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=02-03 Stats: 7 lines in 2 files changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229 PR: https://git.openjdk.org/jdk/pull/25229 From ihse at openjdk.org Mon Jun 9 15:52:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 15:52:24 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 [v3] In-Reply-To: References: Message-ID: <800l9jY8WcERDH6cBd9Jiw-TXxDWjjsn2kJhxK32HYA=.9eae1609-b9f8-4485-af6c-1808a5735cd0@github.com> On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie wrote: >> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Reverting fixes in java.xml and jdk.jdi Thanks @aivanov-jdk! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2956185963 From prr at openjdk.org Mon Jun 9 16:04:00 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 16:04:00 GMT Subject: Integrated: 8358731: Remove jdk.internal.access.JavaAWTAccess.java In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote: > The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration > removed use of AppContext from java/util/logging/LogManager.java. > That was the only place in the JDK that used jdk.internal.access.JavaAWTAccess.java so it can be removed. > > There are 3 tests that use it (digging into internals) but those tests are pointless now that LogManager doesn't use AppContext, so they should be deleted. > > Automated client tests and logging tests (JDK tier1 for the latter it seems) all pass. This pull request has now been integrated. Changeset: eb8ee8bd Author: Phil Race URL: https://git.openjdk.org/jdk/commit/eb8ee8bdc7c170910abc9aa18de1e22677160358 Stats: 1110 lines in 6 files changed: 0 ins; 1110 del; 0 mod 8358731: Remove jdk.internal.access.JavaAWTAccess.java Reviewed-by: dfuchs, serb ------------- PR: https://git.openjdk.org/jdk/pull/25677 From naoto at openjdk.org Mon Jun 9 16:09:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 9 Jun 2025 16:09:53 GMT Subject: RFR: 8356978: Convert unicode sequences in Java source code to UTF-8 [v4] In-Reply-To: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com> References: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com> Message-ID: On Mon, 9 Jun 2025 15:52:24 GMT, Magnus Ihse Bursie wrote: >> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. > > Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision: > > - Fix comment indentation > > Co-authored-by: Alexey Ivanov > - Concatenate string literals > > Co-authored-by: Alexey Ivanov > - Concatenate string literals > > Co-authored-by: Alexey Ivanov LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2910543905 From ihse at openjdk.org Mon Jun 9 18:01:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 9 Jun 2025 18:01:56 GMT Subject: Integrated: 8356978: Convert unicode sequences in Java source code to UTF-8 In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie wrote: > After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains. This pull request has now been integrated. Changeset: 156187ac Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/156187accc1c3e2a897ced011727a5c8d8e1b0cf Stats: 17 lines in 3 files changed: 0 ins; 4 del; 13 mod 8356978: Convert unicode sequences in Java source code to UTF-8 Co-authored-by: Alexey Ivanov Reviewed-by: naoto, prr, joehw ------------- PR: https://git.openjdk.org/jdk/pull/25229 From prr at openjdk.org Mon Jun 9 18:15:07 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 18:15:07 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API Message-ID: This is the implementation of JEP 504 - Remove the Applet API. API changes are - Remove the entire java.applet package - Remove the javax/swing/JApplet class - Remove applet related APIs in java.beans - Update javadoc referring to applets, including one gif image - now changed to an svg image - Other changes are - Remove references to the removed classes - Remove obsolete tests - Update obsolete code comments sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same release as this JEP is integrated. I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. ------------- Commit messages: - 8359053 Changes: https://git.openjdk.org/jdk/pull/25698/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359053 Stats: 3120 lines in 74 files changed: 114 ins; 2867 del; 139 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Mon Jun 9 18:19:54 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 18:19:54 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 18:11:13 GMT, Phil Race wrote: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. test/jdk/ProblemList.txt line 782: > 780: > 781: jdk/internal/loader/URLClassPath/ClassnameCharTest.java 8358729 generic-all > 782: A fix for this test is being worked on - so this problem list addition may be withdrawn later if it is fixed before this PR is integrated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136231123 From abaya at openjdk.org Mon Jun 9 18:22:20 2025 From: abaya at openjdk.org (Anass Baya) Date: Mon, 9 Jun 2025 18:22:20 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v8] In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: > **Analysis :** > > Whether the test passes on the main line or fails, the behavior is still incorrect. > This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly. > > However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. > > This causes the test to proceed immediately to the validation step: > > if (fd.isVisible()) { > throw new RuntimeException("File Dialog is not closed"); > } > > At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet) > > To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation. > > **Proposed fix:** > > set the CountDownLatch to 2 > > **Proposed enhancements :** > > Remove unnecessary threads (Thread and Thread-2) > Properly handle delays and robot.waitForIdle() > Avoid indefinite blocking on latch.await() > > With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds > > The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details Anass Baya has updated the pull request incrementally with six additional commits since the last revision: - The bug id is not needed Co-authored-by: Abhishek Kumar - No need to add bug id Co-authored-by: Abhishek Kumar - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java Co-authored-by: Abhishek Kumar - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java Co-authored-by: Abhishek Kumar - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java Co-authored-by: Abhishek Kumar - Increased the latch timeout to ensure the test doesn't fail incorrectly. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25184/files - new: https://git.openjdk.org/jdk/pull/25184/files/5d7644b4..50bc3103 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=06-07 Stats: 11 lines in 2 files changed: 0 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25184/head:pull/25184 PR: https://git.openjdk.org/jdk/pull/25184 From abhiscxk at openjdk.org Mon Jun 9 18:22:21 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 9 Jun 2025 18:22:21 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v8] In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: <2aM1AIcEJnXVjxpsUozesEt0v7DxkhMz8K52fJQVoaA=.ccfb4ceb-19f3-4f00-8c5b-6dcfa2a1a4c7@github.com> On Mon, 9 Jun 2025 18:17:56 GMT, Anass Baya wrote: >> **Analysis :** >> >> Whether the test passes on the main line or fails, the behavior is still incorrect. >> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly. >> >> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >> >> This causes the test to proceed immediately to the validation step: >> >> if (fd.isVisible()) { >> throw new RuntimeException("File Dialog is not closed"); >> } >> >> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet) >> >> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation. >> >> **Proposed fix:** >> >> set the CountDownLatch to 2 >> >> **Proposed enhancements :** >> >> Remove unnecessary threads (Thread and Thread-2) >> Properly handle delays and robot.waitForIdle() >> Avoid indefinite blocking on latch.await() >> >> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds >> >> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details > > Anass Baya has updated the pull request incrementally with six additional commits since the last revision: > > - The bug id is not needed > > Co-authored-by: Abhishek Kumar > - No need to add bug id > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Increased the latch timeout to ensure the test doesn't fail incorrectly. LGTM. test/jdk/java/awt/FileDialog/DoubleActionESC.java line 41: > 39: /* > 40: * @test > 41: * @bug 5097243 8355478 No need to add bug id. We add the bug id only if there is any product change. Suggestion: * @bug 5097243 test/jdk/java/awt/FileDialog/DoubleActionESC.java line 89: > 87: > 88: if (!latch.await(LATCH_TIMEOUT, SECONDS)) > 89: { Suggestion: if (!latch.await(LATCH_TIMEOUT, SECONDS)) { test/jdk/java/awt/FileDialog/DoubleActionESC.java line 90: > 88: if (!latch.await(LATCH_TIMEOUT, SECONDS)) > 89: { > 90: throw new RuntimeException("Test failed: Latch timout reached"); Suggestion: throw new RuntimeException("Test failed: Latch timeout reached"); test/jdk/java/awt/FileDialog/DoubleActionESC.java line 94: > 92: EventQueue.invokeAndWait(() -> { > 93: if (fd.isVisible()) > 94: { Suggestion: if (fd.isVisible()) { test/jdk/java/awt/FileDialog/DoubleActionESCWithGtkDisabled.java line 26: > 24: /* > 25: * @test > 26: * @bug 5097243 8355478 Don't think bug id is needed here as well. Suggestion: * @bug 5097243 ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25184#pullrequestreview-2882250966 PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2116379043 PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2116382966 PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2116384670 PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2116383654 PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2116436779 From abaya at openjdk.org Mon Jun 9 18:22:21 2025 From: abaya at openjdk.org (Anass Baya) Date: Mon, 9 Jun 2025 18:22:21 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: On Thu, 15 May 2025 16:36:28 GMT, Alexey Ivanov wrote: >>>However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >> This causes the test to proceed immediately to the validation step: >> if (fd.isVisible()) { >> throw new RuntimeException("File Dialog is not closed"); >> } >> >> I don't see the existing code ignores the second attempt, that is due to longer delay put after the robot operations. >> You can add print statements and observe the behavior. >> >> However, I agree the countdown latch should be initialize to 2 to behave correctly. > >> > However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >> > This causes the test to proceed immediately to the validation step: >> > if (fd.isVisible()) { >> > throw new RuntimeException("File Dialog is not closed"); >> > } >> >> I don't see the existing code ignores the second attempt, that is due to longer delay put after the robot operations. You can add print statements and observe the behavior. >> >> However, I agree the countdown latch should be initialize to 2 to behave correctly. > > Technically, longer delays do add up, yet if it takes longer to display the dialog and hide it, it's well possible that the dialog isn't hidden by the time the main thread reaches the point where it calls `fd.isVisible()`. Hello @aivanov-jdk, I also added the test DoubleActionESCWithGtkDisabled to ensure that the old fix is still working Hello @aivanov-jdk, Please let me know if you're good with the recent changes ------------- PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2922435910 PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2956574585 From abhiscxk at openjdk.org Mon Jun 9 18:22:21 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 9 Jun 2025 18:22:21 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: On Fri, 30 May 2025 13:42:08 GMT, Anass Baya wrote: >>> > However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >>> > This causes the test to proceed immediately to the validation step: >>> > if (fd.isVisible()) { >>> > throw new RuntimeException("File Dialog is not closed"); >>> > } >>> >>> I don't see the existing code ignores the second attempt, that is due to longer delay put after the robot operations. You can add print statements and observe the behavior. >>> >>> However, I agree the countdown latch should be initialize to 2 to behave correctly. >> >> Technically, longer delays do add up, yet if it takes longer to display the dialog and hide it, it's well possible that the dialog isn't hidden by the time the main thread reaches the point where it calls `fd.isVisible()`. > > Hello @aivanov-jdk, > I also added the test DoubleActionESCWithGtkDisabled to ensure that the old fix is still working @anass-baya You could have made the changes under single commit and pushed. No need to add multiple commits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-2923128668 From abaya at openjdk.org Mon Jun 9 18:22:22 2025 From: abaya at openjdk.org (Anass Baya) Date: Mon, 9 Jun 2025 18:22:22 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v2] In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: <8ixfF-OiYYeEwZBZUKdkhcPYBqv_5XSRoWQtri4kATY=.944f9001-d45c-4a22-a564-61cffdbeb119@github.com> On Thu, 15 May 2025 16:23:34 GMT, Alexey Ivanov wrote: >> Anass Baya has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test/jdk/ProblemList.txt >> >> Co-authored-by: Abhishek Kumar > > test/jdk/java/awt/FileDialog/DoubleActionESC.java line 81: > >> 79: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); >> 80: robot.waitForIdle(); >> 81: robot.delay(1000); > > Can the delay be reduced to `500`? hello @aivanov-jdk, I left it as is to ensure that if the test fails, it's due to a bug and not an issue with the test itself ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2115949018 From duke at openjdk.org Mon Jun 9 19:56:31 2025 From: duke at openjdk.org (duke) Date: Mon, 9 Jun 2025 19:56:31 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v6] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Wed, 4 Jun 2025 17:14:15 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Limit running test only on windows @matthiasblaesing Your change (at version b9307454b05da44c2ce572d81b60cd91bebfea9b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2956855452 From mblaesing at openjdk.org Mon Jun 9 20:01:41 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Mon, 9 Jun 2025 20:01:41 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v5] In-Reply-To: <3D6hNptNe_z8k03YyGeatJTC755hjkenCkb-6lqubKc=.52147e6c-e0be-473b-9332-ce38e20fea8d@github.com> References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> <3D6hNptNe_z8k03YyGeatJTC755hjkenCkb-6lqubKc=.52147e6c-e0be-473b-9332-ce38e20fea8d@github.com> Message-ID: On Tue, 3 Jun 2025 22:20:45 GMT, Damon Nguyen wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments: >> >> - reduce log level in WClipboard#handleContentsChanged to DEBUG, so that >> in normal operation it will not be visible >> - restore comment on WClipboard#closeClipboard >> - adjust comment on WClipboard#openClipboard >> - Ensure ConcurrentClipboardAccessTest shutsdown on its own when not >> run in an environment with an external timeout handling. >> - Added finishing message to ConcurrentClipboardAccessTest, so that >> correct termination can be determined visually if run manually > > I think this looks fair to me now. But, you still need a Reviewer to look at this. Maybe @kumarabhi006 ? @DamonGuy @kumarabhi006 would be one of you kind enough to act as a sponsor for this change? I have an author status, but not a committer status. Before issuing `/integate` I created a local test branch by merging master from 2-3 days ago into a copy of this branch. That merged cleanly. I reran the application level reproducer with the JDK image from that build and JDK-24. The problem on the application level was reproducible with JDK-24, but not anymore with this changeset in. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2956868219 From aivanov at openjdk.org Mon Jun 9 20:29:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 9 Jun 2025 20:29:36 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 18:11:13 GMT, Phil Race wrote: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Changes requested by aivanov (Reviewer). src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 437: > 435: styleBits = SET(styleBits, TEXTURED, false); > 436: styleBits = SET(styleBits, NONACTIVATING, true); > 437: styleBits = SET(styleBits, IS_POPUP, true); Is the code below the comment still required? It looks it was relevant to applets only. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 716: > 714: execute(ptr -> { > 715: if (isPopup) { > 716: CWrapper.NSWindow.orderFrontRegardless(ptr); Is this still relevant without applets? src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 108: > 106: * Checks if vsync painting is requested for {@code rootContainer} > 107: * > 108: * @param rootContainer topmost container. Should be Window Suggestion: * @param rootContainer topmost container. Should be {@code Window} src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 116: > 114: } > 115: > 116: public static JavaSoundAudioClip create(final URL url) { Does this method need to be removed? src/java.desktop/share/classes/java/awt/Component.java line 3938: > 3936: /** > 3937: * Inner class for flipping buffers on a component. That component must > 3938: * be a {@code Canvas} or {@code Window} Suggestion: * be a {@code Canvas} or {@code Window}. It ended with a full stop, and the full stop should be preserved. src/java.desktop/share/classes/java/awt/Component.java line 3988: > 3986: /** > 3987: * Creates a new flipping buffer strategy for this component. > 3988: * The component must be a {@code Canvas} or {@code Window} Suggestion: * The component must be a {@code Canvas} or {@code Window}. src/java.desktop/share/classes/java/awt/Container.java line 1561: > 1559: *

      > 1560: * The {@code Window} class is the validate root in AWT. > 1561: * Swing introduces more validate roots. Suggestion: * Swing introduces more validate roots. src/java.desktop/share/classes/java/awt/Dialog.java line 174: > 172: * from the same toolkit except those from its own child hierarchy. > 173: */ > 174: TOOLKIT_MODAL Should we add a note that `APPLICATION_MODAL` and `TOOLKIT_MODAL` mean the same thing in the absence of applets or even remove one of them? src/java.desktop/share/classes/java/awt/Toolkit.java line 1353: > 1351: > 1352: /** > 1353: * {@return the EventQueue for this application} Suggestion: * {@return the {@code EventQueue} for this application} src/java.desktop/share/classes/java/awt/Toolkit.java line 1360: > 1358: > 1359: /** > 1360: * A method used by toolkit subclasses to get the EventQueue. Suggestion: * A method used by toolkit subclasses to get the {@code EventQueue}. src/java.desktop/share/classes/java/awt/Toolkit.java line 1362: > 1360: * A method used by toolkit subclasses to get the EventQueue. > 1361: * This may be more direct or more efficient than calling > 1362: * {@code getSystemEventQueue()} Suggestion: * {@code getSystemEventQueue()}. src/java.desktop/share/classes/javax/swing/JComponent.java line 4684: > 4682: > 4683: /** > 4684: * Returns the top-level ancestor of this component (either the Suggestion: * Returns the top-level ancestor of this component (the There's only one option left in the parentheses. src/java.desktop/share/classes/javax/swing/JRootPane.java line 51: > 49: * component on the host system) are shown with a heavier box. AWT components in red, > 50: * Swing heavyweights in blue. > 51: * The three heavyweight JFC/Swing containers ({@code JFrame}, {@code JDialog}, and Shall we drop _?JFC?_? src/java.desktop/share/classes/javax/swing/KeyboardManager.java line 135: > 133: > 134: /** > 135: * Find the top focusable Window, or InternalFrame Suggestion: * Find the top focusable Window, or JInternalFrame Update to the real type used in the condition? src/java.desktop/share/classes/javax/swing/RepaintManager.java line 55: > 53: * As of 1.6 RepaintManager handles repaint requests > 54: * for Swing's top level components ( > 55: * JWindow, JFrame and JDialog). Suggestion: * for Swing's top level components * (JWindow, JFrame and JDialog). Avoid a space after the opening parenthesis. src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 2196: > 2194: *

      > 2195: * The component hierarchy must be displayable up to the toplevel component > 2196: * (a {@code Frame}) Otherwise this method returns {@code null}. Suggestion: * (a {@code Frame}). Otherwise this method returns {@code null}. src/java.desktop/share/classes/javax/swing/UIManager.java line 1457: > 1455: * This method is called before any code that depends on the > 1456: * AppContext specific LAFState object runs. > 1457: In some AppContext cases it's possible for this method Suggestion: * AppContext specific LAFState object runs. * In some AppContext cases, it's possible for this method src/java.desktop/share/classes/sun/awt/AppContext.java line 110: > 108: * wants to peek all of the key events on the EventQueue to listen for > 109: * passwords; if separate EventQueues are used for each ThreadGroup > 110: * using AppContexts, the only key events that code will be able to Suggestion: * using AppContexts, the only key events that the code will be able to Definite article? src/java.desktop/share/classes/sun/awt/AppContext.java line 114: > 112: * change the Swing default look-and-feel; with that default stored in > 113: * an AppContext, the look-and-feel will change without > 114: * disrupting other contexts.

      Suggestion: * disrupting other contexts. The empty paragraph can be dropped. src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java line 51: > 49: > 50: /** > 51: * A generic container used for embedding Java components, Suggestion: * A generic container used for embedding Java components. src/java.desktop/share/classes/sun/font/SunFontManager.java line 2484: > 2482: * that code is already written to be able to perform properly if called > 2483: * to duplicate work. The main difference is that if we detect we are > 2484: * An AppContext environment these new fonts Suggestion: * in an AppContext environment these new fonts ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2910990216 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136277388 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136278266 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136281766 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136284478 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136289738 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136290785 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136295472 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136313003 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136343274 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136344490 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136346033 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136365994 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136376363 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136380810 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136390053 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136399517 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136406164 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136419051 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136421035 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136425427 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136436524 From abaya at openjdk.org Mon Jun 9 20:33:49 2025 From: abaya at openjdk.org (Anass Baya) Date: Mon, 9 Jun 2025 20:33:49 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v2] In-Reply-To: References: Message-ID: <_0eG19ItdVvMClPWXn8mV30RcBHxh7Dfzk3yF1mjNJU=.45afbc28-a308-474f-8550-1699c5769cef@github.com> > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya 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 six additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8346952 - Handle white spaces - remove extra-space - Update copyright - Return the default device if the peer is beeing disposed - Add Test for JDK-8346952 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/268e79c1..78319571 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=00-01 Stats: 52807 lines in 939 files changed: 27588 ins; 15699 del; 9520 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From aivanov at openjdk.org Mon Jun 9 20:40:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 9 Jun 2025 20:40:39 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v14] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 06:22:57 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: moving test file to new package > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2131872951 Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 658: > 656: if (map.get(DefaultEditorKit.selectWordAction) != null) { > 657: Action a = map.get(DefaultEditorKit.selectLineAction); > 658: map.remove(DefaultEditorKit.selectWordAction); Suggestion: if (map.get(DefaultEditorKit.selectWordAction) != null) { map.remove(DefaultEditorKit.selectWordAction); Action a = map.get(DefaultEditorKit.selectLineAction); This would be clearer: remove first, then if there's a `selectLineAction` replace with it. ------------- PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2911298891 PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2136469152 From duke at openjdk.org Mon Jun 9 20:44:57 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 9 Jun 2025 20:44:57 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v15] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/19af4e31..4bc3c344 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=13-14 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From aivanov at openjdk.org Mon Jun 9 20:44:57 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 9 Jun 2025 20:44:57 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: <4JeTbApLJF17K76rvlOkhoGJ5BqWNlhpf7JeHszMV_k=.32c417e0-0b22-42cd-a7fa-0b96dc9d0640@github.com> References: <4JeTbApLJF17K76rvlOkhoGJ5BqWNlhpf7JeHszMV_k=.32c417e0-0b22-42cd-a7fa-0b96dc9d0640@github.com> Message-ID: On Mon, 9 Jun 2025 06:18:46 GMT, Jeremy Wood wrote: >> test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 45: >> >>> 43: public class PasswordSelectionWordTest { >>> 44: public static void main(String[] args) throws Exception { >>> 45: for (UIManager.LookAndFeelInfo laf : >> >> Now since the test is for all the look and feel, should it be inside `test/jdk/javax/swing/JPasswordField` folder? >> Other than this it looks good to me. > > Okay; this is moved. I don't agree. The test belongs in `BasicPasswordFieldUI`, or rather under `BasicTextUI` where the main change is made. The fix is in UI class, not in the `JPasswordField`, moreover the subject of the issue refers to an AWT component `java.awt.TextField`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2136478249 From jlu at openjdk.org Mon Jun 9 20:45:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 9 Jun 2025 20:45:30 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 18:17:45 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > test/jdk/ProblemList.txt line 782: > >> 780: >> 781: jdk/internal/loader/URLClassPath/ClassnameCharTest.java 8358729 generic-all >> 782: > > A fix for this test is being worked on - so this problem list addition may be withdrawn later if it is fixed before this PR is integrated. PR for this issue has been created here: https://github.com/openjdk/jdk/pull/25703. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136480341 From aivanov at openjdk.org Mon Jun 9 20:49:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 9 Jun 2025 20:49:32 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v15] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 20:44:57 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java > > Co-authored-by: Alexey Ivanov Marked as reviewed by aivanov (Reviewer). I'm for moving the test under `BasicTextUI`. ------------- PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2911326011 PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2956995265 From dnguyen at openjdk.org Mon Jun 9 21:23:49 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 9 Jun 2025 21:23:49 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java Message-ID: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. ------------- 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 - Initial commit for backout Changes: https://git.openjdk.org/jdk/pull/25705/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359061 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From duke at openjdk.org Mon Jun 9 21:41:12 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 9 Jun 2025 21:41:12 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v16] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8354646: moving test file back to basic package This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2136478249 https://github.com/openjdk/jdk/pull/25443#issuecomment-2956995265 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/4bc3c344..1c836ac5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=14-15 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Mon Jun 9 21:41:12 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 9 Jun 2025 21:41:12 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v12] In-Reply-To: References: <4JeTbApLJF17K76rvlOkhoGJ5BqWNlhpf7JeHszMV_k=.32c417e0-0b22-42cd-a7fa-0b96dc9d0640@github.com> Message-ID: On Mon, 9 Jun 2025 20:41:31 GMT, Alexey Ivanov wrote: >> Okay; this is moved. > > I don't agree. The test belongs in `BasicPasswordFieldUI`, or rather under `BasicTextUI` where the main change is made. > > The fix is in UI class, not in the `JPasswordField`, moreover the subject of the issue refers to an AWT component `java.awt.TextField`. OK, I moved it back. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2136549787 From prr at openjdk.org Mon Jun 9 21:48:59 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 21:48:59 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/604d78c9..82f0ee55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=00-01 Stats: 13 lines in 9 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Mon Jun 9 21:49:01 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 21:49:01 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> On Mon, 9 Jun 2025 18:51:17 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 437: > >> 435: styleBits = SET(styleBits, TEXTURED, false); >> 436: styleBits = SET(styleBits, NONACTIVATING, true); >> 437: styleBits = SET(styleBits, IS_POPUP, true); > > Is the code below the comment still required? It looks it was relevant to applets only. Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR > src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 716: > >> 714: execute(ptr -> { >> 715: if (isPopup) { >> 716: CWrapper.NSWindow.orderFrontRegardless(ptr); > > Is this still relevant without applets? Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR > src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 108: > >> 106: * Checks if vsync painting is requested for {@code rootContainer} >> 107: * >> 108: * @param rootContainer topmost container. Should be Window > > Suggestion: > > * @param rootContainer topmost container. Should be {@code Window} This isn't public API doc, so I'm not inclined to go updating it any more than I have to. > src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 116: > >> 114: } >> 115: >> 116: public static JavaSoundAudioClip create(final URL url) { > > Does this method need to be removed? It was used by AudioClip. I removed it, nothing broke, so it must now be un-used. So why not remove it ? > src/java.desktop/share/classes/java/awt/Component.java line 3938: > >> 3936: /** >> 3937: * Inner class for flipping buffers on a component. That component must >> 3938: * be a {@code Canvas} or {@code Window} > > Suggestion: > > * be a {@code Canvas} or {@code Window}. > > It ended with a full stop, and the full stop should be preserved. added back > src/java.desktop/share/classes/java/awt/Component.java line 3988: > >> 3986: /** >> 3987: * Creates a new flipping buffer strategy for this component. >> 3988: * The component must be a {@code Canvas} or {@code Window} > > Suggestion: > > * The component must be a {@code Canvas} or {@code Window}. full stop added. > src/java.desktop/share/classes/java/awt/Container.java line 1561: > >> 1559: *

      >> 1560: * The {@code Window} class is the validate root in AWT. >> 1561: * Swing introduces more validate roots. > > Suggestion: > > * Swing introduces more validate roots. space removed > src/java.desktop/share/classes/java/awt/Dialog.java line 174: > >> 172: * from the same toolkit except those from its own child hierarchy. >> 173: */ >> 174: TOOLKIT_MODAL > > Should we add a note that `APPLICATION_MODAL` and `TOOLKIT_MODAL` mean the same thing in the absence of applets or even remove one of them? Yes, It didn't escape me that they mean essentially the same thing, even more so than they did before Theoretically there can be more than one toolkit, although it is not really possible. Addressing the nuances of that is outside the scope of this change, so I made the minimum doc change and removing applet isn't the right time to add advice about which to use. So future work there. And very unlikely to remove either of them as I suspect the similarities mean that developers probably are 50:50 in which they used, so we'd just break (more) apps if we did. > src/java.desktop/share/classes/java/awt/Toolkit.java line 1353: > >> 1351: >> 1352: /** >> 1353: * {@return the EventQueue for this application} > > Suggestion: > > * {@return the {@code EventQueue} for this application} ok > src/java.desktop/share/classes/java/awt/Toolkit.java line 1360: > >> 1358: >> 1359: /** >> 1360: * A method used by toolkit subclasses to get the EventQueue. > > Suggestion: > > * A method used by toolkit subclasses to get the {@code EventQueue}. ok > src/java.desktop/share/classes/java/awt/Toolkit.java line 1362: > >> 1360: * A method used by toolkit subclasses to get the EventQueue. >> 1361: * This may be more direct or more efficient than calling >> 1362: * {@code getSystemEventQueue()} > > Suggestion: > > * {@code getSystemEventQueue()}. full stop added > src/java.desktop/share/classes/javax/swing/KeyboardManager.java line 135: > >> 133: >> 134: /** >> 135: * Find the top focusable Window, or InternalFrame > > Suggestion: > > * Find the top focusable Window, or JInternalFrame > > Update to the real type used in the condition? a private method in an internal class and the same the same is elsewhere in this file. Not worth changing. > src/java.desktop/share/classes/javax/swing/RepaintManager.java line 55: > >> 53: * As of 1.6 RepaintManager handles repaint requests >> 54: * for Swing's top level components ( >> 55: * JWindow, JFrame and JDialog). > > Suggestion: > > * for Swing's top level components > * (JWindow, JFrame and JDialog). > > Avoid a space after the opening parenthesis. ok > src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 2196: > >> 2194: *

      >> 2195: * The component hierarchy must be displayable up to the toplevel component >> 2196: * (a {@code Frame}) Otherwise this method returns {@code null}. > > Suggestion: > > * (a {@code Frame}). Otherwise this method returns {@code null}. full stop added. > src/java.desktop/share/classes/javax/swing/UIManager.java line 1457: > >> 1455: * This method is called before any code that depends on the >> 1456: * AppContext specific LAFState object runs. >> 1457: In some AppContext cases it's possible for this method > > Suggestion: > > * AppContext specific LAFState object runs. > * In some AppContext cases, it's possible for this method fixed > src/java.desktop/share/classes/sun/awt/AppContext.java line 110: > >> 108: * wants to peek all of the key events on the EventQueue to listen for >> 109: * passwords; if separate EventQueues are used for each ThreadGroup >> 110: * using AppContexts, the only key events that code will be able to > > Suggestion: > > * using AppContexts, the only key events that the code will be able to > > Definite article? not here. > src/java.desktop/share/classes/sun/awt/AppContext.java line 114: > >> 112: * change the Swing default look-and-feel; with that default stored in >> 113: * an AppContext, the look-and-feel will change without >> 114: * disrupting other contexts.

      > > Suggestion: > > * disrupting other contexts. > > The empty paragraph can be dropped. ok > src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java line 51: > >> 49: >> 50: /** >> 51: * A generic container used for embedding Java components, > > Suggestion: > > * A generic container used for embedding Java components. ok > src/java.desktop/share/classes/sun/font/SunFontManager.java line 2484: > >> 2482: * that code is already written to be able to perform properly if called >> 2483: * to duplicate work. The main difference is that if we detect we are >> 2484: * An AppContext environment these new fonts > > Suggestion: > > * in an AppContext environment these new fonts fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136487935 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136488391 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136490304 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136492907 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136494512 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136495544 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136496455 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136509376 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136544801 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136545330 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136546411 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136515250 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136548505 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136517418 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136526160 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136526991 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136549954 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136550460 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136551402 From prr at openjdk.org Mon Jun 9 21:49:01 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 9 Jun 2025 21:49:01 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 20:43:01 GMT, Justin Lu wrote: >> test/jdk/ProblemList.txt line 782: >> >>> 780: >>> 781: jdk/internal/loader/URLClassPath/ClassnameCharTest.java 8358729 generic-all >>> 782: >> >> A fix for this test is being worked on - so this problem list addition may be withdrawn later if it is fixed before this PR is integrated. > > PR for this issue has been created here: https://github.com/openjdk/jdk/pull/25703. noted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136551774 From mblaesing at openjdk.org Tue Jun 10 00:24:37 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 10 Jun 2025 00:24:37 GMT Subject: Integrated: 8353950: Clipboard interaction on Windows is unstable In-Reply-To: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Sun, 13 Apr 2025 16:08:40 GMT, Matthias Bl?sing wrote: > - Introduce a lock into WClipboard that protects the code between > openClipboard/closeClipboard invocations. > The native side does not allow to open the clipboard multiple > times or share the opened clipboard between multiple threads. > > - Remove of need to call openClipboard/closeClipboard from > getClipboardFormats by using the win32 call > GetUpdatedClipboardFormats > > - Prevent a race-condition by not registering the connection > between java and native side of clipboard multiple time, but > just at construction time. This pull request has now been integrated. Changeset: 92be7821 Author: Matthias Bl?sing Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/92be7821f5d5cbf5fe0244b41b2b7b1ada898df0 Stats: 174 lines in 4 files changed: 128 ins; 24 del; 22 mod 8353950: Clipboard interaction on Windows is unstable 8332271: Reading data from the clipboard from multiple threads crashes the JVM Reviewed-by: abhiscxk, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/24614 From honkar at openjdk.org Tue Jun 10 00:45:35 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 10 Jun 2025 00:45:35 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Mon, 9 Jun 2025 21:17:22 GMT, Damon Nguyen wrote: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. test/jdk/ProblemList.txt line 837: > 835: java/awt/Menu/MenuVisibilityTest.java 8161110 macosx-all > 836: java/awt/Modal/NativeDialogToFrontBackTest.java 7188049 windows-all,linux-all > 837: java/awt/Cursor/CursorDragTest/ListDragCursor.java 8359061 macosx-all Do you mean to use [7177297](https://bugs.openjdk.org/browse/JDK-7177297) in problemlist entry? test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52: > 50: pass the test. This test fails if the cursor updates > 51: when pointing over the different components before > 52: dragging is complete. The new instructions doesn't seem to hold true when I tested on windows. Additionally the instructions require rephrasing for clarity? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2136712774 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2136716949 From abaya at openjdk.org Tue Jun 10 02:17:01 2025 From: abaya at openjdk.org (Anass Baya) Date: Tue, 10 Jun 2025 02:17:01 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: Fix - 2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/78319571..c3348d77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=01-02 Stats: 35 lines in 4 files changed: 11 ins; 20 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From abaya at openjdk.org Tue Jun 10 02:18:33 2025 From: abaya at openjdk.org (Anass Baya) Date: Tue, 10 Jun 2025 02:18:33 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: References: Message-ID: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> On Tue, 3 Jun 2025 19:05:06 GMT, Phil Race wrote: >> Anass Baya has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix - 2 > > src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2515: > >> 2513: return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> 2514: } >> 2515: > > The code you referred to in the description is handling the case of when a *device* (ie screen) is disconnected. > This is the window peer being destroyed. > Assuming that what you described is correct - some other thread is in a race with this thread - this change looks to me to greatly reduce the likelihood but not eliminate it - ie between the call at line 2510 above and 2516 below, the destruction could happen. > > So isn't the right fix to not create the Throwable in this case ? And just do the default return. > ie maybe the above check goes after the pData == NULL case and if destroyed, do the default return, and if its something else, do the throw. > And perhaps (not sure) that line 2521 should always have returned the default device, not 0 ? Hello @prrace, @mrserb, Thank you for your review. @prrace, regarding line 2521, perhaps they were returning 0 because they assumed the default device always has index 0, which is not true. I also agree with you ? with proper synchronization, checking pData after verifying whether the peer is destroyed is unnecessary. @mrserb, yes ? both situations can happen. For the second case (i.e. parallel execution), I verified it using a volatile flag. A race condition between the EDT and the AWT-Window thread is indeed possible. I didn?t add synchronization in the first fix to avoid impacting performance since I was not running into issues by just verfying if the peer is destroyed. However, the proper and complete fix would be: - Add synchronization between UnlinkObjects() (which, in this case, is invoked by the AWT-Window thread) and _GetScreenImOn() (which is called on the EDT thread). - Ensure that the peer is not destroyed inside _GetScreenImOn(). By doing both, we can be sure that no race condition occurs between _GetScreenImOn() and UnlinkObjects() that could corrupt pData, and we also protect _GetScreenImOn() from accessing a peer that has just been destroyed (as you assumed in your first point, @mrserb) I have added that proposal so you can take a look at it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2136786438 From psadhukhan at openjdk.org Tue Jun 10 02:29:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 10 Jun 2025 02:29:30 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 06:09:37 GMT, Jeremy Wood wrote: > trigger this condition in an app that ran for about 30 minutes. What condition? I couldnt get OOM even after running several hours in Windows and Mac...id didnt reach 2147483647 This issue was not raised by me so clearly somebody felt the need for it..Also, I think it is better to get ABORTED status for the image to let the user know so that corrective action can be taken, instead of aborting the application with OOM or whatever exception it gets thrown ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2136795367 From serb at openjdk.org Tue Jun 10 03:10:28 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 10 Jun 2025 03:10:28 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> References: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> Message-ID: <75OuyVW6WtTSZXoiqmN1lUBIDkxY2b_1aRO9YR_tWqE=.4370795e-36db-45fc-8e26-95eb69d4415a@github.com> On Tue, 10 Jun 2025 02:15:40 GMT, Anass Baya wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2515: >> >>> 2513: return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >>> 2514: } >>> 2515: >> >> The code you referred to in the description is handling the case of when a *device* (ie screen) is disconnected. >> This is the window peer being destroyed. >> Assuming that what you described is correct - some other thread is in a race with this thread - this change looks to me to greatly reduce the likelihood but not eliminate it - ie between the call at line 2510 above and 2516 below, the destruction could happen. >> >> So isn't the right fix to not create the Throwable in this case ? And just do the default return. >> ie maybe the above check goes after the pData == NULL case and if destroyed, do the default return, and if its something else, do the throw. >> And perhaps (not sure) that line 2521 should always have returned the default device, not 0 ? > > Hello @prrace, @mrserb, > Thank you for your review. > > @prrace, regarding line 2521, perhaps they were returning 0 because they assumed the default device always has index 0, which is not true. I also agree with you ? with proper synchronization, checking pData after verifying whether the peer is destroyed is unnecessary. > > @mrserb, yes ? both situations can happen. > For the second case (i.e. parallel execution), I verified it using a volatile flag. A race condition between the EDT and the AWT-Window thread is indeed possible. I didn?t add synchronization in the first fix to avoid impacting performance since I was not running into issues by just verfying if the peer is destroyed. > > However, the proper and complete fix would be: > > - Add synchronization between UnlinkObjects() (which, in this case, is invoked by the AWT-Window thread) and _GetScreenImOn() (which is called on the EDT thread). > > - Ensure that the peer is not destroyed inside _GetScreenImOn(). > > By doing both, we can be sure that no race condition occurs between _GetScreenImOn() and UnlinkObjects() that could corrupt pData, and we also protect _GetScreenImOn() from accessing a peer that has just been destroyed (as you assumed in your first point, @mrserb) > > I have added that proposal so you can take a look at it. Do we actually need a new lock? can we reuse the AwtToolkit::GetInstance().InvokeFunction or AwtToolkit::GetInstance().SyncCall in a similar way it was done in https://github.com/openjdk/jdk/commit/d9bb0f0d39ed322b29c1807991e82fa28c4807f0? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2136828315 From abaya at openjdk.org Tue Jun 10 03:21:27 2025 From: abaya at openjdk.org (Anass Baya) Date: Tue, 10 Jun 2025 03:21:27 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: <75OuyVW6WtTSZXoiqmN1lUBIDkxY2b_1aRO9YR_tWqE=.4370795e-36db-45fc-8e26-95eb69d4415a@github.com> References: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> <75OuyVW6WtTSZXoiqmN1lUBIDkxY2b_1aRO9YR_tWqE=.4370795e-36db-45fc-8e26-95eb69d4415a@github.com> Message-ID: On Tue, 10 Jun 2025 03:07:55 GMT, Sergey Bylokhov wrote: >> Hello @prrace, @mrserb, >> Thank you for your review. >> >> @prrace, regarding line 2521, perhaps they were returning 0 because they assumed the default device always has index 0, which is not true. I also agree with you ? with proper synchronization, checking pData after verifying whether the peer is destroyed is unnecessary. >> >> @mrserb, yes ? both situations can happen. >> For the second case (i.e. parallel execution), I verified it using a volatile flag. A race condition between the EDT and the AWT-Window thread is indeed possible. I didn?t add synchronization in the first fix to avoid impacting performance since I was not running into issues by just verfying if the peer is destroyed. >> >> However, the proper and complete fix would be: >> >> - Add synchronization between UnlinkObjects() (which, in this case, is invoked by the AWT-Window thread) and _GetScreenImOn() (which is called on the EDT thread). >> >> - Ensure that the peer is not destroyed inside _GetScreenImOn(). >> >> By doing both, we can be sure that no race condition occurs between _GetScreenImOn() and UnlinkObjects() that could corrupt pData, and we also protect _GetScreenImOn() from accessing a peer that has just been destroyed (as you assumed in your first point, @mrserb) >> >> I have added that proposal so you can take a look at it. > > Do we actually need a new lock? can we reuse the > AwtToolkit::GetInstance().InvokeFunction or AwtToolkit::GetInstance().SyncCall in a similar way it was done in https://github.com/openjdk/jdk/commit/d9bb0f0d39ed322b29c1807991e82fa28c4807f0? Hello @mrserb, Yes, we can do that. I had the idea to use it so that UnlinkObjects() would be invoked by the EDT, which would eliminate the race condition. I didn?t proceed with it initially because I saw in that file that this pattern is only used in the JNI function calls, so I wanted to preserve the existing coding style paradigm. However, if you agree, I can move forward with this proposal. I actually prefer this approach, as it carries a lower risk of deadlocks and performance degradation as the codebase evolves and becomes more complex. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2136835388 From tr at openjdk.org Tue Jun 10 04:46:44 2025 From: tr at openjdk.org (Tejesh R) Date: Tue, 10 Jun 2025 04:46:44 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename Message-ID: [JDK-8139228](https://bugs.openjdk.org/browse/JDK-8139228) fix missed GTK updates for the same issue where file/directory name renders as `HTML text` instead of `plain text`. Adding the same fix for GTK L&F. Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java ------------- Commit messages: - GTK fix Changes: https://git.openjdk.org/jdk/pull/25707/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25707&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358532 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25707.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25707/head:pull/25707 PR: https://git.openjdk.org/jdk/pull/25707 From duke at openjdk.org Tue Jun 10 06:01:52 2025 From: duke at openjdk.org (Jeremy Wood) Date: Tue, 10 Jun 2025 06:01:52 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 02:26:22 GMT, Prasanta Sadhukhan wrote: > What condition? I just meant the int overflow condition. That test is not meant to demonstrate an OOM. I understand why an OOM feels related to this ticket (and maybe that really is the compelling concern here), but I don't think that ticket mentioned memory consumption. Here's a recording that (I think?) shows I reached the int overflow in about 15 minutes: https://go.screenpal.com/watch/cT16h0nX6xx (You may need to look at the system clock in top-right to accurately track time; parts of the video are sped up 10x. It should be pretty clear when the text cursor blinks super fast.) We could expand that test to: A. use an animated gif, or B. try to load a new non-trivial image once we cross into a negative ID ... but that circles back around to the broader "what are we really trying to solve" question. (And I don't think I know the answer to that question.) > This issue was not raised by me so clearly somebody felt the need for it. Sure. > Also, I think it is better to get ABORTED status for the image to let the user know so that corrective action can be taken, instead of aborting the application with OOM or whatever exception it gets thrown OK. This feels too theoretical for me to invest strongly in a recommendation. On the one hand: what you're saying makes sense, and obviously avoiding an OOM is a good thing to do. On the other hand: if the integer overflow occurs in a non-trivial real-world usage: I'm guessing the images/icons already *are* actually being responsibly disposed of/garbage collected over time. So what we really need is to reset the counter or use a new MediaTracker if the int overflow condition is reached. For example, suppose we use all 2147483647 images IDs, and each image is 100x100px and 3 color channels. That's going to require about 60,000 GB of data (in terms of pixels). If those images are kept in memory, then we will reach an OOM long before we reach an integer overflow. So the fact that we get here (to the integer overflow) at all may (?) mean the application is responsibly discarding images and it's able to handle thousands more over time. Most of all I'd like to see a real-world use case explaining how this impacts a user. Until then: this PR looks good/harmless (IMO). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2136974078 From serb at openjdk.org Tue Jun 10 07:16:27 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 10 Jun 2025 07:16:27 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: References: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> <75OuyVW6WtTSZXoiqmN1lUBIDkxY2b_1aRO9YR_tWqE=.4370795e-36db-45fc-8e26-95eb69d4415a@github.com> Message-ID: On Tue, 10 Jun 2025 03:18:25 GMT, Anass Baya wrote: > Yes, we can do that. I had the idea to use it so that UnlinkObjects() would be invoked by the EDT, which would eliminate the race condition. Looks like the UnlinkObjects and _GetScreenImOn is already executed under the same lock: - WComponentPeer.dispose->AwtObject::_Dispose()->Lock on SyncCS->WM_AWT_DISPOSEPDATA->awt_Component.cpp.dispose()->UnlinkObjects() - WWindowPeer.getScreenImOn()->SyncCall()->Lock on SyncCS->AwtWindow._GetScreenImOn() I think the only thing you should do is to replace the usage of JNI_GET_PDATA by the JNI_CHECK_PEER_GOTO and add a label "ret" at the end so default value of "result" will be returned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2137095842 From psadhukhan at openjdk.org Tue Jun 10 07:30:31 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 10 Jun 2025 07:30:31 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 05:59:07 GMT, Jeremy Wood wrote: > OK. This feels too theoretical for me to invest strongly in a recommendation. That's why I mentioned in the description itself > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2137120597 From serb at openjdk.org Tue Jun 10 07:42:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 10 Jun 2025 07:42:31 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: References: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> <75OuyVW6WtTSZXoiqmN1lUBIDkxY2b_1aRO9YR_tWqE=.4370795e-36db-45fc-8e26-95eb69d4415a@github.com> Message-ID: On Tue, 10 Jun 2025 07:14:06 GMT, Sergey Bylokhov wrote: >> Hello @mrserb, >> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would be invoked by the EDT, which would eliminate the race condition. >> I didn?t proceed with it initially because I saw in that file that this pattern is only used in the JNI function calls, so I wanted to preserve the existing coding style paradigm. >> However, if you agree, I can move forward with this proposal. >> I actually prefer this approach, as it carries a lower risk of deadlocks and performance degradation as the codebase evolves and becomes more complex. > >> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would be invoked by the EDT, which would eliminate the race condition. > > Looks like the UnlinkObjects and _GetScreenImOn is already executed under the same lock: > - WComponentPeer.dispose->AwtObject::_Dispose()->Lock on SyncCS->WM_AWT_DISPOSEPDATA->awt_Component.cpp.dispose()->UnlinkObjects() > - WWindowPeer.getScreenImOn()->SyncCall()->Lock on SyncCS->AwtWindow._GetScreenImOn() > > I think the only thing you should do is to replace the usage of JNI_GET_PDATA by the JNI_CHECK_PEER_GOTO and add a label "ret" at the end so default value of "result" will be returned. check how the _SetFocusableWindow is implemented below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2137143608 From abaya at openjdk.org Tue Jun 10 11:35:28 2025 From: abaya at openjdk.org (Anass Baya) Date: Tue, 10 Jun 2025 11:35:28 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: References: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> <75OuyVW6WtTSZXoiqmN1lUBIDkxY2b_1aRO9YR_tWqE=.4370795e-36db-45fc-8e26-95eb69d4415a@github.com> Message-ID: On Tue, 10 Jun 2025 07:40:07 GMT, Sergey Bylokhov wrote: >>> Yes, we can do that. I had the idea to use it so that UnlinkObjects() would be invoked by the EDT, which would eliminate the race condition. >> >> Looks like the UnlinkObjects and _GetScreenImOn is already executed under the same lock: >> - WComponentPeer.dispose->AwtObject::_Dispose()->Lock on SyncCS->WM_AWT_DISPOSEPDATA->awt_Component.cpp.dispose()->UnlinkObjects() >> - WWindowPeer.getScreenImOn()->SyncCall()->Lock on SyncCS->AwtWindow._GetScreenImOn() >> >> I think the only thing you should do is to replace the usage of JNI_GET_PDATA by the JNI_CHECK_PEER_GOTO and add a label "ret" at the end so default value of "result" will be returned. > > check how the _SetFocusableWindow is implemented below. Hello @mrserb, > I think the only thing you should do is to replace the usage of JNI_GET_PDATA by the JNI_CHECK_PEER_GOTO and add a label "ret" at the end so default value of "result" will be returned. Yes, In the latest changes, I followed that approach to ensure that the peer is not yet destroyed in _GetScreenImOn() as explain in my latest comment. So if you agree I will remove the lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2137650714 From aivanov at openjdk.org Tue Jun 10 11:43:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 11:43:31 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> References: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> Message-ID: On Mon, 9 Jun 2025 20:48:47 GMT, Phil Race wrote: >> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 437: >> >>> 435: styleBits = SET(styleBits, TEXTURED, false); >>> 436: styleBits = SET(styleBits, NONACTIVATING, true); >>> 437: styleBits = SET(styleBits, IS_POPUP, true); >> >> Is the code below the comment still required? It looks it was relevant to applets only. > > Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR Shall I submit a bug to consider removing this code? Without the comment and an issue to track it, no one will ever remember to look into it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2137663905 From aivanov at openjdk.org Tue Jun 10 11:51:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 11:51:30 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> References: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> Message-ID: <0pcnXdSjrCcQNZJtt0UgAY0a2yWItZEq30BcJFdbGF8=.83799898-1d0a-4d24-93fd-cd618b108c5f@github.com> On Mon, 9 Jun 2025 20:50:24 GMT, Phil Race wrote: >> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 108: >> >>> 106: * Checks if vsync painting is requested for {@code rootContainer} >>> 107: * >>> 108: * @param rootContainer topmost container. Should be Window >> >> Suggestion: >> >> * @param rootContainer topmost container. Should be {@code Window} > > This isn't public API doc, so I'm not inclined to go updating it any more than I have to. You have kept `@code` for [`setVsyncRequested`](https://github.com/openjdk/jdk/pull/25698/files/604d78c9e465abe6853f97b328a0c6f13c276a53#diff-52524c1d4891d53a8f9acc07e5e266ea7a07ee5ac3f84c41c240c26409719453R91); for consistency `isVsyncRequested` should have `{@code Window}` too. >> src/java.desktop/share/classes/java/awt/Component.java line 3938: >> >>> 3936: /** >>> 3937: * Inner class for flipping buffers on a component. That component must >>> 3938: * be a {@code Canvas} or {@code Window} >> >> Suggestion: >> >> * be a {@code Canvas} or {@code Window}. >> >> It ended with a full stop, and the full stop should be preserved. > > added back Still missing here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2137673477 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2137677189 From aivanov at openjdk.org Tue Jun 10 12:00:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 12:00:38 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 04:41:54 GMT, Tejesh R wrote: > Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java I add 8358532 to the `@bug` tag of `HTMLFileName.java`. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25707#pullrequestreview-2913230714 From aivanov at openjdk.org Tue Jun 10 12:01:58 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 12:01:58 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 17:11:12 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision: > > - Align the title of frame with JFileChooser to htmlDisabled flag > - Use Serif font instead of Comic Sans MS > - Rename createFileChooser parameter htmlEnabled -> htmlDisabled Any other comments on this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25455#issuecomment-2958927049 From aivanov at openjdk.org Tue Jun 10 12:31:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 12:31:30 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2913352529 From aivanov at openjdk.org Tue Jun 10 13:14:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 13:14:32 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 07:27:41 GMT, Prasanta Sadhukhan wrote: >>> What condition? >> >> I just meant the int overflow condition. That test is not meant to demonstrate an OOM. >> >> I understand why an OOM feels related to this ticket (and maybe that really is the compelling concern here), but I don't think that ticket mentioned memory consumption. >> >> Here's a recording that (I think?) shows I reached the int overflow in about 15 minutes: >> https://go.screenpal.com/watch/cT16h0nX6xx >> >> (You may need to look at the system clock in top-right to accurately track time; parts of the video are sped up 10x. It should be pretty clear when the text cursor blinks super fast.) >> >> We could expand that test to: >> A. use an animated gif, or >> B. try to load a new non-trivial image once we cross into a negative ID >> >> ... but that circles back around to the broader "what are we really trying to solve" question. (And I don't think I know the answer to that question.) >> >>> This issue was not raised by me so clearly somebody felt the need for it. >> >> Sure. >> >>> Also, I think it is better to get ABORTED status for the image to let the user know so that corrective action can be taken, instead of aborting the application with OOM or whatever exception it gets thrown >> >> OK. This feels too theoretical for me to invest strongly in a recommendation. >> >> On the one hand: what you're saying makes sense, and obviously avoiding an OOM is a good thing to do. >> >> On the other hand: if the integer overflow occurs in a non-trivial real-world usage: I'm guessing the images/icons already *are* actually being responsibly disposed of/garbage collected over time. So what we really need is to reset the counter or use a new MediaTracker if the int overflow condition is reached. For example, suppose we use all 2147483647 images IDs, and each image is 100x100px and 3 color channels. That's going to require about 60,000 GB of data (in terms of pixels). If those images are kept in memory, then we will reach an OOM long before we reach an integer overflow. So the fact that we get here (to the integer overflow) at all may (?) mean the application is responsibly discarding images and it's able to handle thousands more over time. >> >> Most of all I'd like to see a real-world use case explaining how this impacts a user. Until then: this PR looks good/harmless (IMO). > >> OK. This feels too theoretical for me to invest strongly in a recommendation. > > That's why I mentioned in the description itself > >> Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" What's the deal with OOM at all? If the application doesn't keep all the images it loads, no OOM will occur. Throwing OOM has nothing to do with the stated problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2137862532 From aivanov at openjdk.org Tue Jun 10 13:14:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 13:14:31 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:29:47 GMT, Prasanta Sadhukhan wrote: > ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. > > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" > > Made sure there is no overflow and treat that loadImage as ABORTED > > No regression testcase as it addresses theoretical possibility.. I think a better solution is to create a new `MediaTracker`, and start anew with id of zero. The `TRACKER_KEY` is used only by `ImageIcon`, so it shouldn't break any apps. src/java.desktop/share/classes/javax/swing/ImageIcon.java line 304: > 302: height = image.getHeight(imageObserver); > 303: return; > 304: } This means that the application won't be able to load images using `MediaTracker`. Is it really a problem that the id becomes negative? Does anything stop working? ~~I can't see that anything breaks because of that. The id is just an id, and it's compared for equality. (Although having a negative id could look suspicious.)~~ It may break at `MediaEntry` insertion, although it would still work probably? Another problem may occur if and when the id wraps around again to positive numbers and 0, 1? _are still being used_. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25666#pullrequestreview-2913496159 PR Review Comment: https://git.openjdk.org/jdk/pull/25666#discussion_r2137855023 From aivanov at openjdk.org Tue Jun 10 13:24:34 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 13:24:34 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> On Tue, 10 Jun 2025 00:36:24 GMT, Harshitha Onkar wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > test/jdk/ProblemList.txt line 837: > >> 835: java/awt/Menu/MenuVisibilityTest.java 8161110 macosx-all >> 836: java/awt/Modal/NativeDialogToFrontBackTest.java 7188049 windows-all,linux-all >> 837: java/awt/Cursor/CursorDragTest/ListDragCursor.java 8359061 macosx-all > > Do you mean to use [7177297](https://bugs.openjdk.org/browse/JDK-7177297) in problemlist entry? Doesn't seem right either. There's a warning about this from the Skara bot. > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52: > >> 50: pass the test. This test fails if the cursor updates >> 51: when pointing over the different components before >> 52: dragging is complete. > > The new instructions doesn't seem to hold true when I tested on windows. > Additionally the instructions require rephrasing for clarity? Perhaps, the instructions need to be adjusted for each OS, or the test should be limited to a specific OS only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2137896092 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2137889078 From aivanov at openjdk.org Tue Jun 10 13:24:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 13:24:35 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Mon, 9 Jun 2025 21:17:22 GMT, Damon Nguyen wrote: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 48: > 46: > 47: If the mouse cursor starts as a Text Line Cursor (I-beam), > 48: and does not change until you reached the List and Is it really how native applications behave on macOS? At least on Windows, the cursor changes as soon as drag operation is started. The cursor shouldn't remain the I-beam when you drag from one component to another. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2137893328 From aivanov at openjdk.org Tue Jun 10 13:27:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 13:27:32 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v16] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 21:41:12 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: moving test file back to basic package > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2136478249 > https://github.com/openjdk/jdk/pull/25443#issuecomment-2956995265 test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 1: > 1: /* I think the test belongs now *under `BasicTextUI`*, although it tests the behaviour related to `JPasswordField` and `PasswordFieldUI`, but the code that handles password fields is in `BasicTextUI`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2137904314 From kizune at openjdk.org Tue Jun 10 14:51:31 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 10 Jun 2025 14:51:31 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2913923933 From mblaesing at openjdk.org Tue Jun 10 15:50:42 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Tue, 10 Jun 2025 15:50:42 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v6] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Wed, 4 Jun 2025 17:14:15 GMT, Matthias Bl?sing wrote: >> - Introduce a lock into WClipboard that protects the code between >> openClipboard/closeClipboard invocations. >> The native side does not allow to open the clipboard multiple >> times or share the opened clipboard between multiple threads. >> >> - Remove of need to call openClipboard/closeClipboard from >> getClipboardFormats by using the win32 call >> GetUpdatedClipboardFormats >> >> - Prevent a race-condition by not registering the connection >> between java and native side of clipboard multiple time, but >> just at construction time. > > Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: > > Limit running test only on windows Thank you all for helping to get this in! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2959785333 From duke at openjdk.org Tue Jun 10 16:06:43 2025 From: duke at openjdk.org (Antonio Vieiro) Date: Tue, 10 Jun 2025 16:06:43 GMT Subject: RFR: 8353950: Clipboard interaction on Windows is unstable [v6] In-Reply-To: References: <5TFAUj4XaWqfrY9eWepypDQlUoLp4UXrKf29neAYIc4=.03ccc530-b287-4496-af89-943d603e81b8@github.com> Message-ID: On Tue, 10 Jun 2025 15:48:17 GMT, Matthias Bl?sing wrote: >> Matthias Bl?sing has updated the pull request incrementally with one additional commit since the last revision: >> >> Limit running test only on windows > > Thank you all for helping to get this in! Thank you @matthiasblaesing for having this integrated after a long review!! Congratulations!! Are you planning to backport this to other JDK versions? I think I may help if you want. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24614#issuecomment-2959845479 From rkannathpari at openjdk.org Tue Jun 10 16:14:04 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 10 Jun 2025 16:14:04 GMT Subject: [jdk25] RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) Message-ID: Hi all, This pull request contains a backport of commit [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Alexander Zvegintsev on 9 Jun 2025 and was reviewed by Prasanta Sadhukhan, Sergey Bylokhov, Alexey Ivanov and Alexey Ushakov. Thanks! ------------- Commit messages: - Backport 2103dc15cb662fd8795b1b51d9cb61c389bed7a0 Changes: https://git.openjdk.org/jdk/pull/25731/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25731&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358452 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25731/head:pull/25731 PR: https://git.openjdk.org/jdk/pull/25731 From duke at openjdk.org Tue Jun 10 16:22:52 2025 From: duke at openjdk.org (Jeremy Wood) Date: Tue, 10 Jun 2025 16:22:52 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v17] In-Reply-To: References: Message-ID: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: 8354646: moving test file to BasicTextUI package This is in response to: https://github.com/openjdk/jdk/pull/25443#discussion_r2137904314 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25443/files - new: https://git.openjdk.org/jdk/pull/25443/files/1c836ac5..d0317fa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25443&range=15-16 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25443/head:pull/25443 PR: https://git.openjdk.org/jdk/pull/25443 From duke at openjdk.org Tue Jun 10 16:22:52 2025 From: duke at openjdk.org (Jeremy Wood) Date: Tue, 10 Jun 2025 16:22:52 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v16] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 13:25:20 GMT, Alexey Ivanov wrote: >> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354646: moving test file back to basic package >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/25443#discussion_r2136478249 >> https://github.com/openjdk/jdk/pull/25443#issuecomment-2956995265 > > test/jdk/javax/swing/plaf/basic/BasicPasswordFieldUI/PasswordSelectionWordTest.java line 1: > >> 1: /* > > I think the test belongs now *under `BasicTextUI`*, although it tests the behaviour related to `JPasswordField` and `PasswordFieldUI`, but the code that handles password fields is in `BasicTextUI`. Ah, sorry. Moved it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25443#discussion_r2138314854 From azvegint at openjdk.org Tue Jun 10 16:23:32 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 10 Jun 2025 16:23:32 GMT Subject: [jdk25] RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad wrote: > Hi all, > > This pull request contains a backport of commit [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Alexander Zvegintsev on 9 Jun 2025 and was reviewed by Prasanta Sadhukhan, Sergey Bylokhov, Alexey Ivanov and Alexey Ushakov. > > Thanks! Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25731#pullrequestreview-2914286932 From rkannathpari at openjdk.org Tue Jun 10 16:27:33 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 10 Jun 2025 16:27:33 GMT Subject: [jdk25] RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 16:20:58 GMT, Alexander Zvegintsev wrote: >> Hi all, >> >> This pull request contains a backport of commit [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Alexander Zvegintsev on 9 Jun 2025 and was reviewed by Prasanta Sadhukhan, Sergey Bylokhov, Alexey Ivanov and Alexey Ushakov. >> >> Thanks! > > Marked as reviewed by azvegint (Reviewer). Thanks @azvegint for your quick approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25731#issuecomment-2959914429 From duke at openjdk.org Tue Jun 10 16:27:33 2025 From: duke at openjdk.org (duke) Date: Tue, 10 Jun 2025 16:27:33 GMT Subject: [jdk25] RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad wrote: > Hi all, > > This pull request contains a backport of commit [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Alexander Zvegintsev on 9 Jun 2025 and was reviewed by Prasanta Sadhukhan, Sergey Bylokhov, Alexey Ivanov and Alexey Ushakov. > > Thanks! @Renjithkannath Your change (at version 8a92e3da51d7651f9b061c284216fe56fb3a788c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25731#issuecomment-2959917370 From aivanov at openjdk.org Tue Jun 10 17:27:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 17:27:38 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v17] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 16:22:52 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: moving test file to BasicTextUI package > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2137904314 Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2914462375 From prr at openjdk.org Tue Jun 10 17:58:27 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 10 Jun 2025 17:58:27 GMT Subject: [jdk25] RFR: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: <8K5be5PrjUVIBshwITMo4UXhWcXITg8xjGqjBrEz_t0=.b8907e57-e358-44d5-9e2b-12c5d5ea959b@github.com> On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad wrote: > Hi all, > > This pull request contains a backport of commit [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Alexander Zvegintsev on 9 Jun 2025 and was reviewed by Prasanta Sadhukhan, Sergey Bylokhov, Alexey Ivanov and Alexey Ushakov. > > Thanks! Why are you proposing a backport ? We are done with JDK 25 and this is not by any means an important fix. I need to hear a really good reason or I will veto this. Also you seem to think you only need one reviewer, I don't know why, since our rules clearly say 2 and especially so for a fix being backported into a stabilisation forest. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25731#issuecomment-2960151719 From prr at openjdk.org Tue Jun 10 18:02:31 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 10 Jun 2025 18:02:31 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> Message-ID: On Tue, 10 Jun 2025 11:41:15 GMT, Alexey Ivanov wrote: >> Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR > > Shall I submit a bug to consider removing this code? > > Without the comment and an issue to track it, no one will ever remember to look into it. yes, go ahead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138490633 From duke at openjdk.org Tue Jun 10 19:04:49 2025 From: duke at openjdk.org (duke) Date: Tue, 10 Jun 2025 19:04:49 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v17] In-Reply-To: References: Message-ID: <7tGJivNfpav6EOvZ1SS3XF6gmy1D3jkCfGD7DSHR4WU=.7a4ea52e-cbeb-443a-a12b-f10c595ca891@github.com> On Tue, 10 Jun 2025 16:22:52 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: moving test file to BasicTextUI package > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2137904314 @mickleness Your change (at version d0317fa9469e3ba4afdab5d19cd15b508b6cab27) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25443#issuecomment-2960310270 From dnguyen at openjdk.org Tue Jun 10 19:28:28 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 10 Jun 2025 19:28:28 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 10 Jun 2025 13:21:14 GMT, Alexey Ivanov wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 48: > >> 46: >> 47: If the mouse cursor starts as a Text Line Cursor (I-beam), >> 48: and does not change until you reached the List and > > Is it really how native applications behave on macOS? > > At least on Windows, the cursor changes as soon as drag operation is started. The cursor shouldn't remain the I-beam when you drag from one component to another. In Windows 11, I tried using the `file explorer's` search text field. It turns into an I-beam and stays one until I let go of the left mouse button. I also tried with `Cisco's VPN` settings button (cog wheel) that is a hand cursor and it behaves the same way. I also tried dragging from the `file explorer's` search field to `Cisco's` cog wheel and it stays an I-beam throughout. In macOS, I used the search bar in `Finder` to get an I-beam and drag. It also stays an I-beam until released. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138625236 From dnguyen at openjdk.org Tue Jun 10 19:35:33 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 10 Jun 2025 19:35:33 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: On Tue, 10 Jun 2025 13:19:40 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52: >> >>> 50: pass the test. This test fails if the cursor updates >>> 51: when pointing over the different components before >>> 52: dragging is complete. >> >> The new instructions doesn't seem to hold true when I tested on windows. >> Additionally the instructions require rephrasing for clarity? > > Perhaps, the instructions need to be adjusted for each OS, or the test should be limited to a specific OS only. It seems like there's a bug with this test when using it in a `PassFailJFrame`. When I move the `createUI` logic into a standalone java class's main method and add `setVisible(true)`, the test works as expected for all OS's except macOS. In this `PassFailJFrame` it looks like it "works" correctly for 1 second, and then the cursor updates anyway afterwards. I'm going to try to look into why this is, but is this what you are seeing too @honkar-jdk ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138635507 From dnguyen at openjdk.org Tue Jun 10 19:38:28 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 10 Jun 2025 19:38:28 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: On Tue, 10 Jun 2025 13:21:58 GMT, Alexey Ivanov wrote: >> test/jdk/ProblemList.txt line 837: >> >>> 835: java/awt/Menu/MenuVisibilityTest.java 8161110 macosx-all >>> 836: java/awt/Modal/NativeDialogToFrontBackTest.java 7188049 windows-all,linux-all >>> 837: java/awt/Cursor/CursorDragTest/ListDragCursor.java 8359061 macosx-all >> >> Do you mean to use [7177297](https://bugs.openjdk.org/browse/JDK-7177297) in problemlist entry? > > Doesn't seem right either. There's a warning about this from the Skara bot. Should I update the issue number here to [7177297](https://bugs.openjdk.org/browse/JDK-7177297)? I'm not fully grasping the Skara bot's error message. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138639421 From mblaesing at doppel-helix.eu Tue Jun 10 19:54:07 2025 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Tue, 10 Jun 2025 21:54:07 +0200 Subject: Backport Candidate: JDK-8332271/ JDK-8353950 (PR #24614) Message-ID: Hello, I'd like to ask whether a backport of: https://github.com/openjdk/jdk/pull/24614 to the stabilisation branch of JDK-25 would have a chance to be accepted. The PR fixes two issues: JDK-8332271: Reading data from the clipboard from multiple threads crashes the JVM (P3) JDK-8353950: Clipboard interaction on Windows is unstable (P4) The fix is pretty self contained in four files (one being a new test) and while changes are done in common code, they only affect windows clipboard implementation as on all other platforms the called methods are no-ops. While JDK-8353950 is a P4, for Apache NetBeans users made it clear, that they consider a usable clipboard essential. I already did a local cherry-pick from master to jdk25 and that applied cleanly. Building the JDK though is a multi-hour project for me and before starting that quest I wanted to gather feedback here. Thank you Matthias From dnguyen at openjdk.org Tue Jun 10 19:58:27 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 10 Jun 2025 19:58:27 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: On Tue, 10 Jun 2025 19:32:51 GMT, Damon Nguyen wrote: >> Perhaps, the instructions need to be adjusted for each OS, or the test should be limited to a specific OS only. > > It seems like there's a bug with this test when using it in a `PassFailJFrame`. When I move the `createUI` logic into a standalone java class's main method and add `setVisible(true)`, the test works as expected for all OS's except macOS. > > In this `PassFailJFrame` it looks like it "works" correctly for 1 second, and then the cursor updates anyway afterwards. I'm going to try to look into why this is, but is this what you are seeing too @honkar-jdk ? I have attached the standalone test to the issue. I tried altering how `ListDragCursor.java` creates the UI but it seems that no matter what I do, the cursor still updates after 1 second. I'm looking into what `PassFailJFrame` does differently at the moment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138668421 From achung at openjdk.org Tue Jun 10 20:59:31 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 10 Jun 2025 20:59:31 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 src/java.desktop/share/classes/java/awt/Polygon.java line 163: > 161: throw new NegativeArraySizeException("npoints < 0"); > 162: } > 163: // Fix 6343431: compatibility problems if arrays are not should this comment just be removed entirely? src/java.desktop/share/classes/java/awt/Toolkit.java line 1353: > 1351: > 1352: /** > 1353: * {@return the {@code EventQueue} for this application} why is this specification in brackets? src/java.desktop/share/classes/javax/swing/JComponent.java line 108: > 106: * whose root is a top-level Swing container. > 107: * Top-level Swing containers -- > 108: * such as JFrame, JDialog -- "and" instead of comma maybe? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138745729 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138747196 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138750561 From aivanov at openjdk.org Tue Jun 10 21:12:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 21:12:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: On Tue, 10 Jun 2025 19:35:45 GMT, Damon Nguyen wrote: >> Doesn't seem right either. There's a warning about this from the Skara bot. > > Should I update the issue number here to [7177297](https://bugs.openjdk.org/browse/JDK-7177297)? I'm not fully grasping the Skara bot's error message. Currently, you problem-listing the test referencing the bug JDK-8359061, which is being fixed by this PR. Once you integrate it, JDK-8359061 will be resolved. Thus, the problem-list entry refers to the bug that's already resolved, which implies the problem why the test is problem-listed is addressed. Yes, `ListDragCursor.java` is problem-listed because of [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297). When JDK-7177297 is fixed, the test will be removed from the problem list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138773297 From prr at openjdk.org Tue Jun 10 21:13:33 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 10 Jun 2025 21:13:33 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 The CSR is now ready for a review : https://bugs.openjdk.org/browse/JDK-8359058 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960591023 From aivanov at openjdk.org Tue Jun 10 21:17:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 21:17:30 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: On Tue, 10 Jun 2025 19:56:13 GMT, Damon Nguyen wrote: >> It seems like there's a bug with this test when using it in a `PassFailJFrame`. When I move the `createUI` logic into a standalone java class's main method and add `setVisible(true)`, the test works as expected for all OS's except macOS. >> >> In this `PassFailJFrame` it looks like it "works" correctly for 1 second, and then the cursor updates anyway afterwards. I'm going to try to look into why this is, but is this what you are seeing too @honkar-jdk ? > > I have attached the standalone test to the issue. I tried altering how `ListDragCursor.java` creates the UI but it seems that no matter what I do, the cursor still updates after 1 second. I'm looking into what `PassFailJFrame` does differently at the moment. I guess it's not the first time that we've encountered such an issue where using `PassFailJFrame` changes the behaviour of the test. Was it @TejeshR13's test? I'm confused because `PassFailJFrame` does nothing more than provides a standard UI. It uses Swing components to display UI. Could this affect AWT components? We have to look into what may cause the differences in behaviour. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138779127 From achung at openjdk.org Tue Jun 10 21:20:30 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 10 Jun 2025 21:20:30 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v17] In-Reply-To: References: Message-ID: > Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564 - remove specified numbers in constant fields, add exception to documentation in glide - merge - update specifications, replace default values in specifications with links to default var - update glide in test - merge - fix test with removed robot.glide using points - add code tag to specifications in Robot - fix syncdelay in ER - removing lesser used overridden methods - ... and 14 more: https://git.openjdk.org/jdk/compare/38b877e9...cbcf3fbe ------------- Changes: https://git.openjdk.org/jdk/pull/22044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=16 Stats: 827 lines in 236 files changed: 213 ins; 434 del; 180 mod Patch: https://git.openjdk.org/jdk/pull/22044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044 PR: https://git.openjdk.org/jdk/pull/22044 From dnguyen at openjdk.org Tue Jun 10 21:22:47 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 10 Jun 2025 21:22:47 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update PL num. Clarify instructions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/467957ac..b2f2fc54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From aivanov at openjdk.org Tue Jun 10 21:22:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 21:22:48 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: On Tue, 10 Jun 2025 21:10:09 GMT, Alexey Ivanov wrote: >> Should I update the issue number here to [7177297](https://bugs.openjdk.org/browse/JDK-7177297)? I'm not fully grasping the Skara bot's error message. > > Currently, you problem-listing the test referencing the bug JDK-8359061, which is being fixed by this PR. Once you integrate it, JDK-8359061 will be resolved. Thus, the problem-list entry refers to the bug that's already resolved, which implies the problem why the test is problem-listed is addressed. > > Yes, `ListDragCursor.java` is problem-listed because of [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297). When JDK-7177297 is fixed, the test will be removed from the problem list. In other words, the bug id in the problem list refers to a JBS issue where the test failure is described, and that issue has to be *open*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138782772 From dnguyen at openjdk.org Tue Jun 10 21:22:48 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 10 Jun 2025 21:22:48 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: On Tue, 10 Jun 2025 21:17:46 GMT, Alexey Ivanov wrote: >> Currently, you problem-listing the test referencing the bug JDK-8359061, which is being fixed by this PR. Once you integrate it, JDK-8359061 will be resolved. Thus, the problem-list entry refers to the bug that's already resolved, which implies the problem why the test is problem-listed is addressed. >> >> Yes, `ListDragCursor.java` is problem-listed because of [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297). When JDK-7177297 is fixed, the test will be removed from the problem list. > > In other words, the bug id in the problem list refers to a JBS issue where the test failure is described, and that issue has to be *open*. Makes sense. Thanks. I have updated the bugID in the PL. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138785855 From dnguyen at openjdk.org Tue Jun 10 21:26:31 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 10 Jun 2025 21:26:31 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> Message-ID: <9brisppAbJL-cS2_qPcaDdOzVVMA6CAGMBHAbKiuqgM=.285db865-c736-46ef-b15f-5897df7a74e1@github.com> On Tue, 10 Jun 2025 21:14:38 GMT, Alexey Ivanov wrote: >> I have attached the standalone test to the issue. I tried altering how `ListDragCursor.java` creates the UI but it seems that no matter what I do, the cursor still updates after 1 second. I'm looking into what `PassFailJFrame` does differently at the moment. > > I guess it's not the first time that we've encountered such an issue where using `PassFailJFrame` changes the behaviour of the test. Was it @TejeshR13's test? > > I'm confused because `PassFailJFrame` does nothing more than provides a standard UI. It uses Swing components to display UI. Could this affect AWT components? > > We have to look into what may cause the differences in behaviour. I have been looking at it and fiddling with the standalone (non-PassFailJFrame) test to see if I can re-create the behavior without `PassFailJFrame`. I suspected AWT components being the issue but I can't see why. I tried using EventQueue and SwingUtilities `invokeAndWait()` method to see if either made a difference, but to no success. I tried different layouts for the frame but I got the same result. I'll keep looking but I may also append `windows` to the ProblemList temporarily if I cannot find the source in a reasonable amount of time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138790736 From prr at openjdk.org Tue Jun 10 21:28:56 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 10 Jun 2025 21:28:56 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v3] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/82f0ee55..a5b4ca5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Tue Jun 10 21:28:56 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 10 Jun 2025 21:28:56 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v2] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 20:50:07 GMT, Alisen Chung wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > src/java.desktop/share/classes/java/awt/Polygon.java line 163: > >> 161: throw new NegativeArraySizeException("npoints < 0"); >> 162: } >> 163: // Fix 6343431: compatibility problems if arrays are not > > should this comment just be removed entirely? The bug wasn't specific to applets. > src/java.desktop/share/classes/java/awt/Toolkit.java line 1353: > >> 1351: >> 1352: /** >> 1353: * {@return the {@code EventQueue} for this application} > > why is this specification in brackets? It's a nice feature I only learned about recently. It generates a comment as well as an @return line. > src/java.desktop/share/classes/javax/swing/JComponent.java line 108: > >> 106: * whose root is a top-level Swing container. >> 107: * Top-level Swing containers -- >> 108: * such as JFrame, JDialog -- > > "and" instead of comma maybe? oh yes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138781413 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138782561 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138784961 From serb at openjdk.org Tue Jun 10 21:31:28 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 10 Jun 2025 21:31:28 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v3] In-Reply-To: References: <6Jt6nEjG_EklC1lfJ1ZynQrlrY0bM4ZYQ4YwIlvOpJM=.ff7bc05f-c85d-49d9-b9fb-b5db049341b9@github.com> <75OuyVW6WtTSZXoiqmN1lUBIDkxY2b_1aRO9YR_tWqE=.4370795e-36db-45fc-8e26-95eb69d4415a@github.com> Message-ID: On Tue, 10 Jun 2025 11:32:58 GMT, Anass Baya wrote: >> check how the _SetFocusableWindow is implemented below. > > Hello @mrserb, > >> I think the only thing you should do is to replace the usage of JNI_GET_PDATA by the JNI_CHECK_PEER_GOTO and add a label "ret" at the end so default value of "result" will be returned. > > Yes, In the latest changes, I followed that approach to ensure that the peer is not yet destroyed in _GetScreenImOn() as explain in my latest comment. So if you agree I will remove the lock. Yes, the new lock is not needed. You can verify this by adding delays/Sleep calls into the methods and confirming that they wait for each other. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2138797641 From achung at openjdk.org Tue Jun 10 21:33:10 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 10 Jun 2025 21:33:10 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v18] In-Reply-To: References: Message-ID: > Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: migrate type(char) method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22044/files - new: https://git.openjdk.org/jdk/pull/22044/files/cbcf3fbe..7eab183c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=16-17 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044 PR: https://git.openjdk.org/jdk/pull/22044 From kcr at openjdk.org Tue Jun 10 21:36:30 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 21:36:30 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v3] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 21:28:56 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 The following files still reference the now-removed applet classes and will fail to compile. Are they not included in any tier testing? test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphPanel.java test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/layout.java test/jdk/java/beans/Performance/TestIntrospector.java The following javadoc tests reference the java.applet package. I don't know whether or not this will cause test failures: test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/package-list test/langtools/jdk/javadoc/doclet/testLinkOption/jdk/package-list test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list The following refer to applets in API documentation, so you might consider updating the docs: src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html src/java.desktop/share/classes/java/awt/doc-files/Modality.html In addition, I found several references to applets in comments. Many / most of these seem OK, but you might want to look at a few to see if you think they might worth modifying. The last two in particular might be good candidates for renaming, although that is just cosmetic at this point: src/demo/share/jfc/J2Ddemo/java2d/RunWindow.java src/demo/share/jfc/J2Ddemo/java2d/Tools.java src/demo/share/jfc/SwingSet2/SwingSet2.java src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960635068 From achung at openjdk.org Tue Jun 10 21:42:44 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 10 Jun 2025 21:42:44 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v18] In-Reply-To: References: Message-ID: On Mon, 24 Feb 2025 21:22:48 GMT, Alexander Zvegintsev wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> migrate type(char) method > > test/jdk/lib/client/ExtendedRobot.java line 368: > >> 366: * @see java.awt.event.KeyEvent >> 367: */ >> 368: public void type(char c) { > > Those `type(char...` are not migrated also. > > At least one test uses it: > > https://github.com/alisenchung/jdk/blob/8150564/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java#L178 > > With your change, it now calls `type(int)` directly, which has a different implementation. i've now also migrated type(int) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2138809883 From achung at openjdk.org Tue Jun 10 21:47:26 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 10 Jun 2025 21:47:26 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v19] In-Reply-To: References: Message-ID: > Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: synchronized for type(char) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22044/files - new: https://git.openjdk.org/jdk/pull/22044/files/7eab183c..a46b067b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044 PR: https://git.openjdk.org/jdk/pull/22044 From kcr at openjdk.org Tue Jun 10 22:08:30 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 22:08:30 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v3] In-Reply-To: References: Message-ID: <8QmPnxKuGngAFBvxSK5dnSA80ov_jWggUQ3LOgQdGGQ=.33c8c638-d602-487f-aa61-acd683a32cf7@github.com> On Tue, 10 Jun 2025 21:28:56 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 One more use of java/applet that should be looked at is in `src/jdk.compiler/share/data/symbols/include.list` although I don't know whether that matters. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960689077 From abaya at openjdk.org Tue Jun 10 22:17:13 2025 From: abaya at openjdk.org (Anass Baya) Date: Tue, 10 Jun 2025 22:17:13 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: Remove global lock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/c3348d77..af7209e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=02-03 Stats: 7 lines in 4 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From aivanov at openjdk.org Tue Jun 10 22:27:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 10 Jun 2025 22:27:27 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: <9brisppAbJL-cS2_qPcaDdOzVVMA6CAGMBHAbKiuqgM=.285db865-c736-46ef-b15f-5897df7a74e1@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> <9brisppAbJL-cS2_qPcaDdOzVVMA6CAGMBHAbKiuqgM=.285db865-c736-46ef-b15f-5897df7a74e1@github.com> Message-ID: On Tue, 10 Jun 2025 21:23:42 GMT, Damon Nguyen wrote: >> I guess it's not the first time that we've encountered such an issue where using `PassFailJFrame` changes the behaviour of the test. Was it @TejeshR13's test? >> >> I'm confused because `PassFailJFrame` does nothing more than provides a standard UI. It uses Swing components to display UI. Could this affect AWT components? >> >> We have to look into what may cause the differences in behaviour. > > I have been looking at it and fiddling with the standalone (non-PassFailJFrame) test to see if I can re-create the behavior without `PassFailJFrame`. I suspected AWT components being the issue but I can't see why. > > I tried using EventQueue and SwingUtilities `invokeAndWait()` method to see if either made a difference, but to no success. I tried different layouts for the frame but I got the same result. I'll keep looking but I may also append `windows` to the ProblemList temporarily if I cannot find the source in a reasonable amount of time. Could it be that mere existence of other windows created by the same Java process somehow changes the cursors? I mean `PassFailJFrame` displays another window. What if you create a second window (that may display nothing inside) in your stand-alone test? Does it change what cursors you see when dragging? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2138860812 From prr at openjdk.org Tue Jun 10 22:44:16 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 10 Jun 2025 22:44:16 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v4] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/a5b4ca5e..0b5235e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=02-03 Stats: 41 lines in 6 files changed: 0 ins; 33 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From kcr at openjdk.org Tue Jun 10 22:52:29 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Jun 2025 22:52:29 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 22:44:16 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 All looks good to me. I didn't build / look at the generated docs. ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2915211163 From prr at openjdk.org Tue Jun 10 22:52:30 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 10 Jun 2025 22:52:30 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v3] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 21:33:22 GMT, Kevin Rushforth wrote: > The following files still reference the now-removed applet classes and will fail to compile. Are they not included in any tier testing? > > ``` > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphPanel.java > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/layout.java I didn't notice those. It can't be run by any standard task. TEST.groups has it under # Just-In-Time compiler tests vmTestbase_vm_compiler = \ vmTestbase/vm/compiler \ vmTestbase/jit \ vmTestbase/vm/jit but I can't find anything that runs vmTestbase_vm_compiler Also it is HEADFUL and no hotspot tests run today in such a mode. So I am sure it isn't run on a regular basis. I'll file a hotspot bug on this, but first I'll ask if anyone knows about it. > test/jdk/java/beans/Performance/TestIntrospector.java That was on "my list" at some point - I lost it ! I will update it. > ``` > > The following javadoc tests reference the java.applet package. I don't know whether or not this will cause test failures: > > ``` > test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/package-list > test/langtools/jdk/javadoc/doclet/testLinkOption/jdk/package-list > test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list These tests are run in tier1. They don't really use the applet api. They just have some data in the test directory that they work on that lists java.applet as a package name. The tests pass so I don't think I need to do anything, but it is probably still worth filing a bug to see if the owners want to remove applet from the package-list > ``` > > The following refer to applets in API documentation, so you might consider updating the docs: > > ``` > src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html > src/java.desktop/share/classes/java/awt/doc-files/Modality.html Will do. > ``` > > In addition, I found several references to applets in comments. Many / most of these seem OK, but you might want to look at a few to see if you think they might worth modifying. The last two in particular might be good candidates for renaming, although that is just cosmetic at this point: > > ``` > src/demo/share/jfc/J2Ddemo/java2d/RunWindow.java > src/demo/share/jfc/J2Ddemo/java2d/Tools.java > src/demo/share/jfc/SwingSet2/SwingSet2.java > src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java > test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java > test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java > ``` I know about the last 3 and left them. The demos previously had applet options removed. Some comments must have been missed I will update. > One more use of java/applet that should be looked at is in `src/jdk.compiler/share/data/symbols/include.list` although I don't know whether that matters. I saw that one. It wasn't clear to me how it was used, and since I didn't see any test failures I left it. Another one to file a component team bug about. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960752780 PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960755451 From serb at openjdk.org Tue Jun 10 23:56:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 10 Jun 2025 23:56:31 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 22:17:13 GMT, Anass Baya wrote: >> **Analysis:** >> >> We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). >> The race condition between the execution paths of these two native methods sometimes causes an exception >> >> **Proposed Fix:** >> >> While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number >> >> >> public void updateGC() { >> >> int scrn = getScreenImOn(); >> >> if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { >> log.finer("Screen number: " + scrn); >> } >> >> // get current GD >> Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); >> >> Win32GraphicsDevice newDev; >> GraphicsDevice[] devs = GraphicsEnvironment >> .getLocalGraphicsEnvironment() >> .getScreenDevices(); >> >> // Occasionally during device addition/removal getScreenImOn can return >> // a non-existing screen number. Use the default device in this case. >> if (scrn >= devs.length) { >> newDev = (Win32GraphicsDevice) GraphicsEnvironment >> .getLocalGraphicsEnvironment().getDefaultScreenDevice(); >> } else { >> newDev = (Win32GraphicsDevice) devs[scrn]; >> } >> } >> >> >> Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : >> >> jint AwtWindow::_GetScreenImOn(void *param) >> { >> ... >> jboolean destroyed = JNI_GET_DESTROYED(self); >> if (destroyed == JNI_TRUE){ >> env->DeleteGlobalRef(self); >> return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> } >> ... >> >> >> **Tests Summary:** >> >> GetGraphicsStressTest (existing test): >> >> Fails intermittently without the fix >> >> Consistently passes with the fix >> >> NotifyStressTest (newly added test): >> >> Consistently fails without the fix >> >> Consistently passes with the fix > > Anass Baya has updated the pull request incrementally with one additional commit since the last revision: > > Remove global lock src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2505: > 2503: > 2504: // It's entirely possible that our native resources have been destroyed > 2505: // before our java peer - if we're dispose()d, for instance. You can merge this text and "// Return the default screen." to something like: // Our native resources may have been destroyed before the Java peer, // e.g., if dispose() was called. In that case, return the default screen. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2507: > 2505: // before our java peer - if we're dispose()d, for instance. > 2506: // Return the default screen. > 2507: JNI_CHECK_PEER_GOTO(self, ret); I suggest reordering it slightly - this pattern is commonly used in most cases where JNI_CHECK_PEER_GOTO is used: result...; AwtWindow *window = NULL; PDATA pData; JNI_CHECK_PEER_GOTO(self, ret); window = (AwtWindow *)pData; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2138935690 PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2138934388 From abaya at openjdk.org Wed Jun 11 00:13:05 2025 From: abaya at openjdk.org (Anass Baya) Date: Wed, 11 Jun 2025 00:13:05 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v5] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: Enhance comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/af7209e0..3175a0f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From abaya at openjdk.org Wed Jun 11 00:13:05 2025 From: abaya at openjdk.org (Anass Baya) Date: Wed, 11 Jun 2025 00:13:05 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: <07Ib59TCwZW2RVNeqhHno-_39FWFF5aDHzyWCK3HVWI=.3801a9f7-5241-4b9a-b4fc-65c03da14097@github.com> On Tue, 10 Jun 2025 23:53:04 GMT, Sergey Bylokhov wrote: >> Anass Baya has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove global lock > > src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2505: > >> 2503: >> 2504: // It's entirely possible that our native resources have been destroyed >> 2505: // before our java peer - if we're dispose()d, for instance. > > You can merge this text and "// Return the default screen." to something like: > > // Our native resources may have been destroyed before the Java peer, > // e.g., if dispose() was called. In that case, return the default screen. Okay Thank you ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2138945426 From serb at openjdk.org Wed Jun 11 02:08:38 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 02:08:38 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 23:51:09 GMT, Sergey Bylokhov wrote: >> Anass Baya has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove global lock > > src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2507: > >> 2505: // before our java peer - if we're dispose()d, for instance. >> 2506: // Return the default screen. >> 2507: JNI_CHECK_PEER_GOTO(self, ret); > > I suggest reordering it slightly - this pattern is commonly used in most cases where JNI_CHECK_PEER_GOTO is used: > > result...; > AwtWindow *window = NULL; > > PDATA pData; > JNI_CHECK_PEER_GOTO(self, ret); > window = (AwtWindow *)pData; I still suggest this order. Also, please add the new bug ID to the GetGraphicsStressTest. btw I'm still looking into the new test - it always passes for me. Can we tweak it to reproduce the bug more reliably? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2139042941 From abaya at openjdk.org Wed Jun 11 02:42:15 2025 From: abaya at openjdk.org (Anass Baya) Date: Wed, 11 Jun 2025 02:42:15 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v6] In-Reply-To: References: Message-ID: <8tJ8kus-HKD1pJXJ0AiWnA5q6A_65-FfuBPWsZ9tozM=.3ad851a4-9ca3-4b4b-ab49-8dee47804efc@github.com> > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with two additional commits since the last revision: - Add the new bug ID to the old test - Reorder declaration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/3175a0f2..bfc4ac18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=04-05 Stats: 12 lines in 2 files changed: 4 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From abaya at openjdk.org Wed Jun 11 02:42:15 2025 From: abaya at openjdk.org (Anass Baya) Date: Wed, 11 Jun 2025 02:42:15 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 02:05:33 GMT, Sergey Bylokhov wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2507: >> >>> 2505: // before our java peer - if we're dispose()d, for instance. >>> 2506: // Return the default screen. >>> 2507: JNI_CHECK_PEER_GOTO(self, ret); >> >> I suggest reordering it slightly - this pattern is commonly used in most cases where JNI_CHECK_PEER_GOTO is used: >> >> result...; >> AwtWindow *window = NULL; >> >> PDATA pData; >> JNI_CHECK_PEER_GOTO(self, ret); >> window = (AwtWindow *)pData; > > I still suggest this order. > > Also, please add the new bug ID to the GetGraphicsStressTest. > btw I'm still looking into the new test - it always passes for me. Can we tweak it to reproduce the bug more reliably? I cant reproduce it locally. I can see it only on CI 20/20 with the new test and 2/20 with the old one ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2139064354 From serb at openjdk.org Wed Jun 11 03:01:27 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 03:01:27 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 02:34:04 GMT, Anass Baya wrote: >> I still suggest this order. >> >> Also, please add the new bug ID to the GetGraphicsStressTest. >> btw I'm still looking into the new test - it always passes for me. Can we tweak it to reproduce the bug more reliably? > > I cant reproduce it locally. > I can see it only on CI 20/20 with the new test and 2/20 with the old one what is the stack trace when the new test fails? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2139100969 From rkannathpari at openjdk.org Wed Jun 11 03:07:37 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Wed, 11 Jun 2025 03:07:37 GMT Subject: [jdk25] Withdrawn: 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119) In-Reply-To: References: Message-ID: <3hyZcNcR1xtx4jLvzacSwGOWW3LQmZmz4DDkcL2OH78=.0d483d68-d413-4e56-9d51-7db5e7d888ae@github.com> On Tue, 10 Jun 2025 16:09:13 GMT, Renjith Kannath Pariyangad wrote: > Hi all, > > This pull request contains a backport of commit [2103dc15](https://github.com/openjdk/jdk/commit/2103dc15cb662fd8795b1b51d9cb61c389bed7a0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Alexander Zvegintsev on 9 Jun 2025 and was reviewed by Prasanta Sadhukhan, Sergey Bylokhov, Alexey Ivanov and Alexey Ushakov. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25731 From psadhukhan at openjdk.org Wed Jun 11 03:11:29 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 11 Jun 2025 03:11:29 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 13:12:20 GMT, Alexey Ivanov wrote: > I think a better solution is to create a new `MediaTracker`, and start anew with id of zero. > > The `TRACKER_KEY` is used only by `ImageIcon`, so it shouldn't break any apps. If we create a new MediaTracker in ImageIcon and start anew with id of zero, then if application is having its own MediaTracker to track then when it calls for tracker.checkID(0) or tracker.statusID(0) then it will be confusing to which image it is referring to, so I guess this current PR is more simpler in the sense it will notify ABORTED status for all images which overflows so that application can start anew with new ImageIcon and then use their MediaTracker to track this new ImageIcon. Other thing that can be done is to modify "int" to "long" for all ids to further the overflow goalpost whereby `MediaTracker.checkID,addImage, statusID` signature will be changed..I dont think it will break any application but it will require CSR and since this issue is earmarked as Enhancement, maybe submitter also wanted that but I am not sure of going that route unless there is consensus on it.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2961114635 From philip.race at oracle.com Wed Jun 11 04:43:54 2025 From: philip.race at oracle.com (Philip Race) Date: Tue, 10 Jun 2025 21:43:54 -0700 Subject: Backport Candidate: JDK-8332271/ JDK-8353950 (PR #24614) In-Reply-To: References: Message-ID: <67dd91bc-6216-4abc-8ce7-dc68cb0891c8@oracle.com> It seems to me like a candidate based on being a recent 'regression' and the use case and potential impact. I just have not looked at or tested the code myself, and clipboard tests are at least in some part manual, so I don't know how well it has been tested. Did anyone run at least the automated jtreg tests for you on our CI system ? ?-phil On 6/10/25 12:54 PM, Matthias Bl?sing wrote: > Hello, > > I'd like to ask whether a backport of: > > https://github.com/openjdk/jdk/pull/24614 > > to the stabilisation branch of JDK-25 would have a chance to be > accepted. The PR fixes two issues: > > JDK-8332271: Reading data from the clipboard from multiple threads crashes the JVM (P3) > JDK-8353950: Clipboard interaction on Windows is unstable (P4) > > The fix is pretty self contained in four files (one being a new test) > and while changes are done in common code, they only affect windows > clipboard implementation as on all other platforms the called methods > are no-ops. > > While JDK-8353950 is a P4, for Apache NetBeans users made it clear, > that they consider a usable clipboard essential. > > I already did a local cherry-pick from master to jdk25 and that applied > cleanly. Building the JDK though is a multi-hour project for me and > before starting that quest I wanted to gather feedback here. > > Thank you > > Matthias From dnguyen at openjdk.org Wed Jun 11 04:53:27 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 11 Jun 2025 04:53:27 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> <9brisppAbJL-cS2_qPcaDdOzVVMA6CAGMBHAbKiuqgM=.285db865-c736-46ef-b15f-5897df7a74e1@github.com> Message-ID: On Tue, 10 Jun 2025 22:23:32 GMT, Alexey Ivanov wrote: >> I have been looking at it and fiddling with the standalone (non-PassFailJFrame) test to see if I can re-create the behavior without `PassFailJFrame`. I suspected AWT components being the issue but I can't see why. >> >> I tried using EventQueue and SwingUtilities `invokeAndWait()` method to see if either made a difference, but to no success. I tried different layouts for the frame but I got the same result. I'll keep looking but I may also append `windows` to the ProblemList temporarily if I cannot find the source in a reasonable amount of time. > > Could it be that mere existence of other windows created by the same Java process somehow changes the cursors? > > I mean `PassFailJFrame` displays another window. What if you create a second window (that may display nothing inside) in your stand-alone test? Does it change what cursors you see when dragging? Oh I forgot to mention it, but I did check that as well. I made another empty frame with nothing inside to see if it was a focusing issue or something similar. Same results however, so I still can't pinpoint the issue. You mentioned @TejeshR13 had a similar issue with `PassFailJFrame` causing a difference in a test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2139184210 From honkar at openjdk.org Wed Jun 11 05:11:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 05:11:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> On Tue, 10 Jun 2025 00:42:21 GMT, Harshitha Onkar wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update PL num. Clarify instructions. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52: > >> 50: pass the test. This test fails if the cursor updates >> 51: when pointing over the different components before >> 52: dragging is complete. > > The new instructions doesn't seem to hold true when I tested on windows. > Additionally the instructions require rephrasing for clarity? > In this PassFailJFrame it looks like it "works" correctly for 1 second, and then the cursor updates anyway afterwards. I'm going to try to look into why this is, but is this what you are seeing too @honkar-jdk ? Looks like there are 3 scenarios here and based on how fast or slow the cursor is moved and cursor update. 1) Move the cursor without mouse drag (i.e without clicking left mouse btn). The cursor update is immediate. 2) Move the cursor quickly across the components with mouse drag (i.e with left mouse btn pressed) The cursor updates when you are midway into the components which implies cursor update is slow but it ultimately shows the correct cursor. 3) Move the cursor slowly across the components with mouse drag (i.e with left mouse btn pressed) cursor does get updated on entering the components as expected similar to case 1. I'm probably guessing the mouse drag action creates a delay in how soon the cursor is updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2139201442 From honkar at openjdk.org Wed Jun 11 05:18:27 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 05:18:27 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> Message-ID: On Wed, 11 Jun 2025 05:08:29 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52: >> >>> 50: pass the test. This test fails if the cursor updates >>> 51: when pointing over the different components before >>> 52: dragging is complete. >> >> The new instructions doesn't seem to hold true when I tested on windows. >> Additionally the instructions require rephrasing for clarity? > >> In this PassFailJFrame it looks like it "works" correctly for 1 second, and then the cursor updates anyway afterwards. I'm going to try to look into why this is, but is this what you are seeing too @honkar-jdk ? > > Looks like there are 3 scenarios here and based on how fast or slow the cursor is moved and cursor update. > > 1) Move the cursor without mouse drag (i.e without clicking left mouse btn). The cursor update is immediate. > > 2) Move the cursor quickly across the components with mouse drag (i.e with left mouse btn pressed) The cursor updates when you are midway into the components which implies cursor update is slow but it ultimately shows the correct cursor. > > 3) Move the cursor slowly across the components with mouse drag (i.e with left mouse btn pressed) cursor does get updated on entering the components as expected similar to case 1. > > I'm probably guessing the mouse drag action creates a delay in how soon the cursor is updated. In addition to that the cursor type gets updated irrespective of whether the left mouse button is released or pressed when it is dragged from text area to list. I'm not sure if this is the expected behavior or a bug? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2139212467 From duke at openjdk.org Wed Jun 11 10:28:42 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Wed, 11 Jun 2025 10:28:42 GMT Subject: Integrated: 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty In-Reply-To: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> References: <-t5iRw5c31W0E-mPWTvHk9PoP819SUA9xrAwMZfJEDc=.c61d9c20-5397-4ab2-89ac-dab4b50b2a0e@github.com> Message-ID: On Fri, 18 Apr 2025 13:10:10 GMT, Khalid Boulanouare wrote: > Fixes issue in which the test fails when run on multi-screen machine. > > Tested on Ubuntu 24.04, MacOS 15 and Windows 11 > > JTREG > > runner starting test: java/awt/Frame/MultiScreenTest.java > runner finished test: java/awt/Frame/MultiScreenTest.java > Passed. Execution successful This pull request has now been integrated. Changeset: 5ae32c4c Author: Khalid Boulanouare Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/5ae32c4c86916120d2a337be9765cb6e14f3f443 Stats: 498 lines in 1 file changed: 186 ins; 173 del; 139 mod 8352149: Test java/awt/Frame/MultiScreenTest.java fails: Window list is empty Reviewed-by: aivanov, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/24752 From tr at openjdk.org Wed Jun 11 10:41:09 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 11 Jun 2025 10:41:09 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: > [JDK-8139228](https://bugs.openjdk.org/browse/JDK-8139228) fix missed GTK updates for the same issue where file/directory name renders as `HTML text` instead of `plain text`. > Adding the same fix for GTK L&F. > Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java Tejesh R has updated the pull request incrementally with one additional commit since the last revision: updating test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25707/files - new: https://git.openjdk.org/jdk/pull/25707/files/77d8fb61..44328ffc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25707&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25707&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25707.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25707/head:pull/25707 PR: https://git.openjdk.org/jdk/pull/25707 From aivanov at openjdk.org Wed Jun 11 11:08:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Jun 2025 11:08:30 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 03:09:16 GMT, Prasanta Sadhukhan wrote: > > I think a better solution is to create a new `MediaTracker`, and start anew with id of zero. > > The `TRACKER_KEY` is used only by `ImageIcon`, so it shouldn't break any apps. > > If we create a new MediaTracker in ImageIcon and start anew with id of zero, then if application is having its own MediaTracker to track then when it calls for tracker.checkID(0) or tracker.statusID(0) then it will be confusing to which image it is referring to Why is it? `ImageIcon` has its own instance of `MediaTracker`. Yes, technically, it's possible to get this instance from `AppContext` but no application should do it. If an application needs to load images, it has to create its own instance of `MediaTracker`. Since `MediaTracker` API requires a caller provided id, the instance of `MediaTracker` can't be shared, otherwise there's a clash in ids. > ?so I guess this current PR is more simpler in the sense it will notify ABORTED status for all images which overflows so that application can start anew with new ImageIcon and then use their MediaTracker to track this new ImageIcon. Could you elaborate please? The `mediaTrackerID` is a static field in `ImageIcon`; `MediaTracker` is also a static-like shared instance that's stored in `AppContext`. This means if `mediaTrackerID` overflows, the application can't use `new ImageIcon` to load any more images ? the application can no longer work. The application can do nothing about it. > Other thing that can be done is to modify "int" to "long" for all ids to further the overflow goalpost whereby `MediaTracker.checkID,addImage, statusID` signature will be changed..I dont think it will break any application but it will require CSR and since this issue is earmarked as Enhancement, maybe submitter also wanted that but I am not sure of going that route unless there is consensus on it.. I thought about it, and using `long` instead of `int` was my first idea. Yet `MediaTracker` API needs to be modified. But it won't solve the underlying problem: `long` can also wrap around into negative numbers. It'll take much longer, but `long` will wrap around. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962253908 From psadhukhan at openjdk.org Wed Jun 11 12:33:27 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 11 Jun 2025 12:33:27 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 11:06:10 GMT, Alexey Ivanov wrote: > Could you elaborate please? > > The `mediaTrackerID` is a static field in `ImageIcon`; `MediaTracker` is also a static-like shared instance that's stored in `AppContext`. > > This means if `mediaTrackerID` overflows, the application can't use `new ImageIcon` to load any more images ? the application can no longer work. The application can do nothing about it. WHy application cant use new ImageIcon I didnt understand? I meant if application creates/instantiates a new ImageIcon (seeing the previous ImageIcon is giving ABORTED status for all images), the `mediaTrackerID` will reset from 0, this field will have no bearing from previous ImageIcon instance..am I missing something? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962504035 From psadhukhan at openjdk.org Wed Jun 11 12:40:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 11 Jun 2025 12:40:28 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:29:47 GMT, Prasanta Sadhukhan wrote: > ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. > > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" > > Made sure there is no overflow and treat that loadImage as ABORTED > > No regression testcase as it addresses theoretical possibility.. Something like this ImageIcon icon = new ImageIcon(); Image image = Toolkit.getDefaultToolkit().createImage("onepixel.gif"); icon.setImage(image); if (icon.getImageLoadStatus == MediaTracker.ABORTED) { ImageIcon newIcon = new ImageIcon(); } in this case wont mediaTrackerId starts from 0 again for "newIcon"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962527159 From aivanov at openjdk.org Wed Jun 11 12:49:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Jun 2025 12:49:30 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: <2QBDkdaBtP4jRdPWUXi99z4irdsW682_WPwG1lZDQr0=.eb1c4d04-5ee3-49f9-80d2-3d91d3f07732@github.com> On Wed, 11 Jun 2025 12:37:25 GMT, Prasanta Sadhukhan wrote: > Something like this > > ``` > ImageIcon icon = new ImageIcon(); > Image image = Toolkit.getDefaultToolkit().createImage("onepixel.gif"); > icon.setImage(image); > if (icon.getImageLoadStatus == MediaTracker.ABORTED) { > ImageIcon newIcon = new ImageIcon(); > } > ``` > > in this case wont mediaTrackerId starts from 0 again for "newIcon"? No, it won't. Why will it? `mediaTrackerId` is a static field, that is its value grows with each image loaded by a new instance of `ImageIcon`, and the value of `mediaTrackerId` is never reset. That's exactly the problem described in the [JDK-8055461](https://bugs.openjdk.org/browse/JDK-8055461) bug report. https://github.com/openjdk/jdk/blob/bf7d40d0486b7b4e4820bb5d08a63c446ea3291d/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L129 https://github.com/openjdk/jdk/blob/bf7d40d0486b7b4e4820bb5d08a63c446ea3291d/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L322-L326 With the change that you propose, it will be impossible to load images with `ImageIcon` once the value of `mediaTrackerId` reaches `Integer.MAX_VALUE`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962554490 From aivanov at openjdk.org Wed Jun 11 12:53:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Jun 2025 12:53:29 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:29:47 GMT, Prasanta Sadhukhan wrote: > ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. > > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" > > Made sure there is no overflow and treat that loadImage as ABORTED > > No regression testcase as it addresses theoretical possibility.. I wonder why [JDK-8055461](https://bugs.openjdk.org/browse/JDK-8055461) is an enhancement. It's *a bug*. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962568721 From psadhukhan at openjdk.org Wed Jun 11 13:28:29 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 11 Jun 2025 13:28:29 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: <2QBDkdaBtP4jRdPWUXi99z4irdsW682_WPwG1lZDQr0=.eb1c4d04-5ee3-49f9-80d2-3d91d3f07732@github.com> References: <2QBDkdaBtP4jRdPWUXi99z4irdsW682_WPwG1lZDQr0=.eb1c4d04-5ee3-49f9-80d2-3d91d3f07732@github.com> Message-ID: On Wed, 11 Jun 2025 12:46:54 GMT, Alexey Ivanov wrote: > With the change that you propose, it will be impossible to load images with `ImageIcon` once the value of `mediaTrackerId` reaches `Integer.MAX_VALUE`. OK. > I think a better solution is to create a new MediaTracker, and start anew with id of zero. So, we need to have mediaTrackerID1 and use that but then what about when next Integer.MAX_VALUE is reached, create another MediaTracker and again use another mediaTrackerID2 ? it will be a loop then... Won;t it better and simpler to make the id "long" which will make it use 2*64 images in one application? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962704818 From aivanov at openjdk.org Wed Jun 11 13:34:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Jun 2025 13:34:29 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: <2QBDkdaBtP4jRdPWUXi99z4irdsW682_WPwG1lZDQr0=.eb1c4d04-5ee3-49f9-80d2-3d91d3f07732@github.com> Message-ID: On Wed, 11 Jun 2025 13:24:57 GMT, Prasanta Sadhukhan wrote: > > I think a better solution is to create a new MediaTracker, and start anew with id of zero. > > So, we need to have mediaTrackerID1 and use that but then what about when next Integer.MAX_VALUE is reached, create another MediaTracker and again use another mediaTrackerID2 ? it will be a loop then... Won;t it better and simpler to make the id "long" which will make it use 2*64 images in one application? No, just one. When `mediaTrackerID` reaches `Integer.MAX_VALUE`, the `ImageIcon.getTracker` method will create a new `MediaTracker` and put it into `AppContext`, then it will reset the value of `mediaTrackerID` to 0 before returning the new instance of the media tracker. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962726712 From aivanov at openjdk.org Wed Jun 11 14:05:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Jun 2025 14:05:28 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: <2QBDkdaBtP4jRdPWUXi99z4irdsW682_WPwG1lZDQr0=.eb1c4d04-5ee3-49f9-80d2-3d91d3f07732@github.com> Message-ID: On Wed, 11 Jun 2025 13:31:37 GMT, Alexey Ivanov wrote: > Won;t it better and simpler to make the id "long" which will make it use 2*64 images in one application? Likely no application loads more than 2 billion images; it's even less likely that an application will load more than 2?? images which is closed more than 10??. In fact, it seems to me that nothing will actually break when the integer counter in `mediaTrackerId` overflows into negative numbers and then overflows back to positive numbers again. This id is used to identify an image in the loading queue. Because of negative id, the order of `MediaEntry` elements in the list may be broken. https://github.com/openjdk/jdk/blob/c98dffa186d48c41e76fd3a60e0129a8da60310f/src/java.desktop/share/classes/java/awt/MediaTracker.java#L884-L887 It may result in malfunctioning? or not. If not, nothing bad will happen. Having said that, I think that *no fix is necessary*. Yes, `mediaTrackerId` may overflow and wrap around in an application that loads billions of images, but is it really a problem if everything continue to work? A problem would occur if and only if an image with id of 1, 2? still exists in the `MediaTracker` queue, which is ***highly* unlikely**. `ImageIcon` removes itself from the `MediaTracker` as soon as the image loads, successfully or not, which means by the time `mediaTrackerId` wraps around into positive numbers again, the first images are long gone from the `MediaTracker` queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2962945456 From psadhukhan at openjdk.org Wed Jun 11 14:30:29 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 11 Jun 2025 14:30:29 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:29:47 GMT, Prasanta Sadhukhan wrote: > ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. > > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" > > Made sure there is no overflow and treat that loadImage as ABORTED > > No regression testcase as it addresses theoretical possibility.. > > Won;t it better and simpler to make the id "long" which will make it use 2*64 images in one application? > > Likely no application loads more than 2 billion images; it's even less likely that an application will load more than 2?? images which is closed more than 10??. > > In fact, it seems to me that nothing will actually break when the integer counter in `mediaTrackerId` overflows into negative numbers and then overflows back to positive numbers again. This id is used to identify an image in the loading queue. > > Because of negative id, the order of `MediaEntry` elements in the list may be broken. > > https://github.com/openjdk/jdk/blob/c98dffa186d48c41e76fd3a60e0129a8da60310f/src/java.desktop/share/classes/java/awt/MediaTracker.java#L884-L887 > > It may result in malfunctioning? or not. If not, nothing bad will happen. > > Having said that, I think that _no fix is necessary_. Yes, `mediaTrackerId` may overflow and wrap around in an application that loads billions of images, but is it really a problem if everything continue to work? > > A problem would occur if and only if an image with id of 1, 2? still exists in the `MediaTracker` queue, which is **_highly_ unlikely**. `ImageIcon` removes itself from the `MediaTracker` as soon as the image loads, successfully or not, which means by the time `mediaTrackerId` wraps around into positive numbers again, the first images are long gone from the `MediaTracker` queue. If mediaTrackerId overflows then id will increment backwards without any fix like -2147483648, -2147483647, -2147483646, -2147483645, -2147483644 etc so it will take another Integer.MAX_VALUE+1 images to gain positive numbers..Not sure having overflown negative ids for all these images will cause any issues or not? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2963063787 From psadhukhan at openjdk.org Wed Jun 11 15:04:21 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 11 Jun 2025 15:04:21 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow [v2] In-Reply-To: References: Message-ID: > ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. > > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" > > Made sure there is no overflow and treat that loadImage as ABORTED > > No regression testcase as it addresses theoretical possibility.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Reset mediaTrackerID if it overflows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25666/files - new: https://git.openjdk.org/jdk/pull/25666/files/f79b4ca9..fd2ad261 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25666&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25666&range=00-01 Stats: 13 lines in 1 file changed: 3 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25666.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25666/head:pull/25666 PR: https://git.openjdk.org/jdk/pull/25666 From mblaesing at doppel-helix.eu Wed Jun 11 15:59:32 2025 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Wed, 11 Jun 2025 17:59:32 +0200 Subject: Backport Candidate: JDK-8332271/ JDK-8353950 (PR #24614) In-Reply-To: <67dd91bc-6216-4abc-8ce7-dc68cb0891c8@oracle.com> References: <67dd91bc-6216-4abc-8ce7-dc68cb0891c8@oracle.com> Message-ID: <02ee74ad3e2ed92b3c481670e78c37db42e4ad39.camel@doppel-helix.eu> Hi, Am Dienstag, dem 10.06.2025 um 21:43 -0700 schrieb Philip Race: > It seems to me like a candidate based on being a recent 'regression' and > the use case and potential impact. > I just have not looked at or tested the code myself, and clipboard tests > are at least in some part manual, > so I don't know how well it has been tested. > > Did anyone run at least the automated jtreg tests for you on our CI system ? to my knowledge this was not yet done. I ran the jtreg tests from `test/jdk/java/awt/Clipboard` locally including the new crash reproducer. In addition I used the application level reproducer to verify that the issue also covers that. That test copy-and-pastes text between NetBeans and notepad in a loop, while adding the loop index on each invocation. That looked sane for 20-100 iterations. > On 6/10/25 12:54 PM, Matthias Bl?sing wrote: > > [Backport proposal https://github.com/openjdk/jdk/pull/24614] > > > > JDK-8332271: Reading data from the clipboard from multiple threads crashes the JVM (P3) > > JDK-8353950: Clipboard interaction on Windows is unstable (P4) Thanks for considering Matthias From aivanov at openjdk.org Wed Jun 11 16:14:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 11 Jun 2025 16:14:32 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 15:04:21 GMT, Prasanta Sadhukhan wrote: >> ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. >> >> Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" >> >> Made sure there is no overflow and treat that loadImage as ABORTED >> >> No regression testcase as it addresses theoretical possibility.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reset mediaTrackerID if it overflows I've been trying to verify whether the fix is even necessary. My test case has been running for a few hours, and it reached only 0x30000000. I will need to update the test case to cause the overflow from negative number to positive again. Let's see. I still like the idea of not touching anything better than fixing this potential issue which doesn't seem to cause much trouble, at least from analysing the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2963415320 From dnguyen at openjdk.org Wed Jun 11 16:15:30 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 11 Jun 2025 16:15:30 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> Message-ID: On Wed, 11 Jun 2025 05:15:26 GMT, Harshitha Onkar wrote: > In addition to that the cursor type gets updated irrespective of whether the left mouse button is released or pressed when it is dragged from text area to list. Are you saying there's a scenario where the cursor type gets updated when dragging and not releasing in an OS other than macOS? For macOS, it is a bug ([JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)) but it seems to work correctly for other OS's AFAIK and tested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2140593486 From dnguyen at openjdk.org Wed Jun 11 16:32:29 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 11 Jun 2025 16:32:29 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 10:41:09 GMT, Tejesh R wrote: >> [JDK-8139228](https://bugs.openjdk.org/browse/JDK-8139228) fix missed GTK updates for the same issue where file/directory name renders as `HTML text` instead of `plain text`. >> Adding the same fix for GTK L&F. >> Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > updating test Opposite results of what's instructed. Attached screenshot. Seems slightly off if I understand it correctly because when testing it myself, it looks like the fix is backwards since the HTML enabled/disabled test shows the opposite results that I expect. I would expect "HTML disabled" to not have the magenta "Swing Rocks!". Screenshot 2025-06-11 at 9 26 08?AM ------------- Changes requested by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/25707#pullrequestreview-2917937246 PR Comment: https://git.openjdk.org/jdk/pull/25707#issuecomment-2963469319 From djelinski at openjdk.org Wed Jun 11 16:33:38 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Jun 2025 16:33:38 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski wrote: > Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. > > I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. src/java.base/share/native/libnet/net_util.c line 77: > 75: CHECK_NULL_RETURN(s, JNI_VERSION_1_2); > 76: preferIPv4Stack = (*env)->CallStaticBooleanMethod(env, iCls, mid, s); > 77: JNU_CHECK_EXCEPTION_RETURN(env, JNI_VERSION_1_2); The exception check is technically not necessary because no other JNI methods are called before the function exits, but it wasn't always the case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2140117524 From djelinski at openjdk.org Wed Jun 11 16:33:38 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 11 Jun 2025 16:33:38 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code Message-ID: Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. ------------- Commit messages: - Fix JNICheck issue Changes: https://git.openjdk.org/jdk/pull/25754/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25754&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8131136 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25754/head:pull/25754 PR: https://git.openjdk.org/jdk/pull/25754 From honkar at openjdk.org Wed Jun 11 16:55:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 16:55:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> Message-ID: On Wed, 11 Jun 2025 16:13:16 GMT, Damon Nguyen wrote: >> In addition to that the cursor type gets updated irrespective of whether the left mouse button is released or pressed when it is dragged from text area to list. >> I'm not sure if this is the expected behavior or a bug? > >> In addition to that the cursor type gets updated irrespective of whether the left mouse button is released or pressed when it is dragged from text area to list. > > Are you saying there's a scenario where the cursor type gets updated when dragging and not releasing in an OS other than macOS? For macOS, it is a bug ([JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)) but it seems to work correctly for other OS's AFAIK and tested. Yes, I noticed it on windows OS, I haven't tested on macOS yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2140660365 From dnguyen at openjdk.org Wed Jun 11 17:04:38 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 11 Jun 2025 17:04:38 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> Message-ID: On Wed, 11 Jun 2025 16:51:34 GMT, Harshitha Onkar wrote: >>> In addition to that the cursor type gets updated irrespective of whether the left mouse button is released or pressed when it is dragged from text area to list. >> >> Are you saying there's a scenario where the cursor type gets updated when dragging and not releasing in an OS other than macOS? For macOS, it is a bug ([JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)) but it seems to work correctly for other OS's AFAIK and tested. > > Yes, I noticed it on windows OS, I haven't tested on macOS yet. On Windows in PassFailJFrame, I get the correct behavior for a short period of time before it updates. Is that what you're seeing too? Or does it immediately update? @honkar-jdk Can you try that other test I attached to the JBS issue? It does not use PFJFrame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2140675188 From honkar at openjdk.org Wed Jun 11 17:52:49 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 17:52:49 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v19] In-Reply-To: References: Message-ID: <0bHZatSlUNefQ0pP4-nrrQxJq3cqFh5PkP-bWfj-85M=.cb9f8784-c145-460d-8038-a4181189b7da@github.com> On Tue, 10 Jun 2025 21:47:26 GMT, Alisen Chung wrote: >> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > synchronized for type(char) I see couple of tests that use ExtendedRobot which can be changed to use Robot. Can you double check these tests. java/awt/Frame/DisposeParentGC/DisposeParentGC.java java/awt/List/SetBackgroundTest/SetBackgroundTest.java java/awt/Modal/ToBack/ToBackFDFTest.java test/jdk/lib/client/ExtendedRobot.java line 237: > 235: public void glide(Point src, Point dest) { > 236: glide(src.x, src.y, dest.x, dest.y, DEFAULT_STEP_LENGTH, DEFAULT_SPEED); > 237: } @alisenchung Shouldn't `glide(Point src, Point dest)` and `glide(Point dest)` be retained in ExtendedRobot In [previous comment](https://github.com/openjdk/jdk/pull/22044/files#r2085671341) it was mentioned that these methods won't be migrated so do they need to be retained in ExtendedRobot ? I see `MultipleMouseButtonsTest.java` using `glide(Point src, Point dest)`. There are two options here: 1) Either update the test to use Robot's glide() change the line `robot.glide(origin, center)` to `robot.glide(origin.x, origin.y, center.x, center.y);` and completely remove ExtendedRobot versions of glide. 2) Or retain these two convenience methods in ExtendedRobot. ------------- PR Review: https://git.openjdk.org/jdk/pull/22044#pullrequestreview-2918163191 PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2140751723 From honkar at openjdk.org Wed Jun 11 18:15:46 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 18:15:46 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v19] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 21:47:26 GMT, Alisen Chung wrote: >> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > synchronized for type(char) There are couple of tests failing due to compilation error. I have added the list to JBS please take a look. ------------- Changes requested by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22044#pullrequestreview-2918229860 From honkar at openjdk.org Wed Jun 11 18:15:47 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 18:15:47 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v19] In-Reply-To: <0bHZatSlUNefQ0pP4-nrrQxJq3cqFh5PkP-bWfj-85M=.cb9f8784-c145-460d-8038-a4181189b7da@github.com> References: <0bHZatSlUNefQ0pP4-nrrQxJq3cqFh5PkP-bWfj-85M=.cb9f8784-c145-460d-8038-a4181189b7da@github.com> Message-ID: On Wed, 11 Jun 2025 17:45:30 GMT, Harshitha Onkar wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> synchronized for type(char) > > test/jdk/lib/client/ExtendedRobot.java line 237: > >> 235: public void glide(Point src, Point dest) { >> 236: glide(src.x, src.y, dest.x, dest.y, DEFAULT_STEP_LENGTH, DEFAULT_SPEED); >> 237: } > > @alisenchung > > Shouldn't `glide(Point src, Point dest)` and `glide(Point dest)` be retained in ExtendedRobot > In [previous comment](https://github.com/openjdk/jdk/pull/22044/files#r2085671341) it was mentioned that these methods won't be migrated so do they need to be retained in ExtendedRobot ? > > I see `MultipleMouseButtonsTest.java` using `glide(Point src, Point dest)`. There are two options here: > > 1) Either update the test to use Robot's glide() > change the line `robot.glide(origin, center)` to `robot.glide(origin.x, origin.y, center.x, center.y);` and completely remove ExtendedRobot versions of glide. > > 2) Or retain these two convenience methods in ExtendedRobot. There are couple of other tests that use ExtendedRobot version of glide() so probably option 2 (retaining the two convenience methods in ExtendedRobot) might be a better option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2140796563 From honkar at openjdk.org Wed Jun 11 18:36:48 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 18:36:48 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v19] In-Reply-To: References: Message-ID: <0I2H4jGdPKkhXxZZ_S8VtdUDXP08y0WstLkeZMMTjns=.002a2053-39f9-4817-96b3-fadf72db2ddb@github.com> On Tue, 10 Jun 2025 21:47:26 GMT, Alisen Chung wrote: >> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > synchronized for type(char) test/jdk/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java line 64: > 62: > 63: TrayIcon icon; > 64: Robot robot; This test still builds ExtendedRobot which is no longer needed. Applicable for other tests as well. @library /lib/client @build ExtendedRobot ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2140831788 From prr at openjdk.org Wed Jun 11 18:42:22 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 11 Jun 2025 18:42:22 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v5] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/0b5235e9..ed610209 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=03-04 Stats: 381 lines in 6 files changed: 0 ins; 381 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Wed Jun 11 18:42:22 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 11 Jun 2025 18:42:22 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v3] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 22:47:21 GMT, Phil Race wrote: > > The following files still reference the now-removed applet classes and will fail to compile. Are they not included in any tier testing? > > ``` > > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java > > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphPanel.java > > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/layout.java > > ``` > > I didn't notice those. It can't be run by any standard task. TEST.groups has it under It isn't run because it is marked headful and hotspot excludes headful tests. Not sure it is ever run and probably is not adding value. After some off-line discussion with the hotspot lead, I will remove this test as part of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2963811726 From serb at openjdk.org Wed Jun 11 19:03:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 19:03:30 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: References: Message-ID: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com> On Wed, 11 Jun 2025 13:19:39 GMT, Daniel Jeli?ski wrote: >> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. >> >> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. > > src/java.base/share/native/libnet/net_util.c line 77: > >> 75: CHECK_NULL_RETURN(s, JNI_VERSION_1_2); >> 76: preferIPv4Stack = (*env)->CallStaticBooleanMethod(env, iCls, mid, s); >> 77: JNU_CHECK_EXCEPTION_RETURN(env, JNI_VERSION_1_2); > > The exception check is technically not necessary because no other JNI methods are called before the function exits, but it wasn't always the case. If this check is not needed, then why are we adding it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2140875632 From prr at openjdk.org Wed Jun 11 19:18:15 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 11 Jun 2025 19:18:15 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/ed610209..27c6eebd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From serb at openjdk.org Wed Jun 11 19:24:33 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 19:24:33 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 src/java.desktop/share/classes/java/awt/Window.java line 3864: > 3862: content.setOpaque(isOpaque); > 3863: > 3864: // Iterate down one level to see whether we have (eg) a JInternalFrame I think it is more related to top level windows like JWindow/JDialog etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140906732 From serb at openjdk.org Wed Jun 11 19:30:33 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 19:30:33 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 113: > 111: * registry functions. > 112: * > 113: *

      Each {@code ThreadGroup} will receive its own instance. Note that this new specification is not tied to AppContext. Do we still want to support ThreadGroup sandboxing even if AppContext will be removed? Can we drop it now, since current spec clearly tied to applets and AppContext usage? src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java line 796: > 794: BufferStrategy bs = null; > 795: try { > 796: ((Window)root).createBufferStrategy(2, caps); We probably can change the type of "root" to "Window". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140913064 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140914921 From serb at openjdk.org Wed Jun 11 19:34:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 19:34:31 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1656: > 1654: * @return the first ancestor of c that's a Window > 1655: */ > 1656: @SuppressWarnings("removal") @SuppressWarnings("removal") can be deleted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140920183 From serb at openjdk.org Wed Jun 11 19:40:36 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 19:40:36 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java line 33: > 31: * @library /vmTestbase > 32: * /test/lib > 33: * @run main/othervm jit.misctests.fpustack.GraphApplet Why do we delete this test? it is better to update it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140929171 From serb at openjdk.org Wed Jun 11 19:45:38 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 19:45:38 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 44: > 42: * @bug 8202264 > 43: */ > 44: public final class AutoCloseTimeCheck { This test should be updated to use SoundClip instead. test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 48: > 46: public class DataPusherThreadCheck { > 47: > 48: public static void main(String[] args) throws Exception { This test should be updated to use SoundClip instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140936074 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140936963 From serb at openjdk.org Wed Jun 11 19:49:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 11 Jun 2025 19:49:32 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 51: > 49: * @run main/othervm -Xmx128m AudioContentHandlers > 50: */ > 51: public final class AudioContentHandlers { I see the src/java.desktop/share/classes/sun/awt/www/content/audio/ are not updated, so what will be the replacement of AudioClip? I guess we should return SoundClip now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140942251 From achung at openjdk.org Wed Jun 11 20:58:32 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 11 Jun 2025 20:58:32 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Marked as reviewed by achung (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2918694517 From honkar at openjdk.org Wed Jun 11 21:35:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 21:35:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> Message-ID: On Wed, 11 Jun 2025 17:00:39 GMT, Damon Nguyen wrote: >> Yes, I noticed it on windows OS, I haven't tested on macOS yet. > > On Windows in PassFailJFrame, I get the correct behavior for a short period of time before it updates. Is that what you're seeing too? Or does it immediately update? > > @honkar-jdk Can you try that other test I attached to the JBS issue? It does not use PFJFrame. @DamonGuy > It seems like there's a bug with this test when using it in a PassFailJFrame. When I move the createUI logic into a standalone java class's main method and add setVisible(true), the test works as expected for all OS's except macOS. I missed your earlier comment. Yes this seems to be true. Interestingly the cursor does not update when dragging across components until the left button is released with the standalone test on windows but with PFJ it does. I tried with PFJ's splitUI() & JPanel but the issue persists. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2141153132 From dnguyen at openjdk.org Wed Jun 11 21:41:27 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 11 Jun 2025 21:41:27 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <9RGR8Y0bXWmjSmjHCliHvSMWWQeC7d4q0cRPj1bqhcI=.25619625-4650-4f91-bb87-1ba352f8040a@github.com> Message-ID: <-l3ouwnPlccK_YnaSZBz0ocWuMUK_GV7RQUOVddzdY8=.9328c894-6ffc-4e53-9f48-7c8fce5248e3@github.com> On Wed, 11 Jun 2025 21:33:02 GMT, Harshitha Onkar wrote: >> On Windows in PassFailJFrame, I get the correct behavior for a short period of time before it updates. Is that what you're seeing too? Or does it immediately update? >> >> @honkar-jdk Can you try that other test I attached to the JBS issue? It does not use PFJFrame. > > @DamonGuy >> It seems like there's a bug with this test when using it in a PassFailJFrame. When I move the createUI logic into a standalone java class's main method and add setVisible(true), the test works as expected for all OS's except macOS. > > I missed your earlier comment. Yes this seems to be true. Interestingly the cursor does not update when dragging across components until the left button is released with the standalone test on windows but with PFJ it does. I tried with PFJ's splitUI() & JPanel but the issue persists. Thanks for checking. I spent some time looking through the PFJFrame class and the standalone changing the test to better represent the PFJFrame version better, but I can't determine the exact cause. I will update this PR to include windows in the problem list and create a new JBS issue for windows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2141159607 From honkar at openjdk.org Wed Jun 11 21:56:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 21:56:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> <9brisppAbJL-cS2_qPcaDdOzVVMA6CAGMBHAbKiuqgM=.285db865-c736-46ef-b15f-5897df7a74e1@github.com> Message-ID: <43LyfYQNmBScaQ476GyowJntTSkqKMgtkgG_Lo8iwoQ=.a75ea871-87bc-4ffe-8792-f58772683695@github.com> On Tue, 10 Jun 2025 22:23:32 GMT, Alexey Ivanov wrote: >> I have been looking at it and fiddling with the standalone (non-PassFailJFrame) test to see if I can re-create the behavior without `PassFailJFrame`. I suspected AWT components being the issue but I can't see why. >> >> I tried using EventQueue and SwingUtilities `invokeAndWait()` method to see if either made a difference, but to no success. I tried different layouts for the frame but I got the same result. I'll keep looking but I may also append `windows` to the ProblemList temporarily if I cannot find the source in a reasonable amount of time. > > Could it be that mere existence of other windows created by the same Java process somehow changes the cursors? > > I mean `PassFailJFrame` displays another window. What if you create a second window (that may display nothing inside) in your stand-alone test? Does it change what cursors you see when dragging? Since the standalone test works as expected on windows, I'm not sure if we need to problemlist it on windows, as @aivanov-jdk mentioned earlier it must a side-effect of PFJ. I used the standalone test and added another dummy frame, even with extra frame the test works as expected. (cursor remains a I-beam until the left mouse btn is released) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2141174989 From honkar at openjdk.org Wed Jun 11 22:15:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 11 Jun 2025 22:15:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 10 Jun 2025 21:22:47 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update PL num. Clarify instructions. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52: > 50: pass the test. This test fails if the cursor updates > 51: when pointing over the different components before > 52: releasing the left mouse button. Suggestion: The mouse cursor appears as an I-beam cursor and stays the same while dragging across the components. Once you reach the list release the left mouse button, at that moment the cursor should change to a Hand Cursor. If the above is true press pass. The test fails if the cursor updates while dragging over the different components before releasing the left mouse button. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2141194037 From psadhukhan at openjdk.org Thu Jun 12 03:28:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 12 Jun 2025 03:28:41 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter Message-ID: When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. It's better to not go through all MediaTracker usage and bail out initially itself for null image.. ------------- Commit messages: - COpyright - ImageIcon.setImage can't handle null parameter Changes: https://git.openjdk.org/jdk/pull/25767/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8159055 Stats: 47 lines in 2 files changed: 46 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From abaya at openjdk.org Thu Jun 12 04:10:00 2025 From: abaya at openjdk.org (Anass Baya) Date: Thu, 12 Jun 2025 04:10:00 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v7] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: Remove whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/bfc4ac18..577ba84a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From abaya at openjdk.org Thu Jun 12 04:10:00 2025 From: abaya at openjdk.org (Anass Baya) Date: Thu, 12 Jun 2025 04:10:00 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 02:59:15 GMT, Sergey Bylokhov wrote: >> I cant reproduce it locally. >> I can see it only on CI 20/20 with the new test and 2/20 with the old one > > what is the stack trace when the new test fails? the same stack as the old test. However let me try to enhance it and come back to you ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2141672275 From tr at openjdk.org Thu Jun 12 05:02:33 2025 From: tr at openjdk.org (Tejesh R) Date: Thu, 12 Jun 2025 05:02:33 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v3] In-Reply-To: References: Message-ID: <2sEQU-ftc6NnYAW9esUjvKPfTCyMmcieEHAephH-vKY=.80246b1f-5e09-4732-8fcd-f78050a9f763@github.com> On Tue, 3 Jun 2025 17:11:12 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision: > > - Align the title of frame with JFileChooser to htmlDisabled flag > - Use Serif font instead of Comic Sans MS > - Rename createFileChooser parameter htmlEnabled -> htmlDisabled LGTM. ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25455#pullrequestreview-2919548476 From abhiscxk at openjdk.org Thu Jun 12 06:04:27 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 12 Jun 2025 06:04:27 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 03:23:30 GMT, Prasanta Sadhukhan wrote: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Does it require to update the doc as well to explicitly mention about NULL parameter ? Otherwise fix looks ok to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2965225362 From psadhukhan at openjdk.org Thu Jun 12 06:34:09 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 12 Jun 2025 06:34:09 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: References: Message-ID: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/4be55ab3..bcdef9b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From psadhukhan at openjdk.org Thu Jun 12 06:34:09 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 12 Jun 2025 06:34:09 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 03:23:30 GMT, Prasanta Sadhukhan wrote: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. I feel it's better to inform the user in the spec otherwise application may not know what will be done with NULL image ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2965288096 From tr at openjdk.org Thu Jun 12 06:57:39 2025 From: tr at openjdk.org (Tejesh R) Date: Thu, 12 Jun 2025 06:57:39 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 16:29:30 GMT, Damon Nguyen wrote: > Opposite results of what's instructed. Attached screenshot. It is addressed in [JDK-8357799](https://bugs.openjdk.org/browse/JDK-8357799) fix. So didn't address here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25707#issuecomment-2965352727 From abhiscxk at openjdk.org Thu Jun 12 06:59:29 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 12 Jun 2025 06:59:29 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 06:31:04 GMT, Prasanta Sadhukhan wrote: > I feel it's better to inform the user in the spec otherwise application may not know what will be done with NULL image CSR needed ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2965347161 From psadhukhan at openjdk.org Thu Jun 12 06:59:31 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 12 Jun 2025 06:59:31 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Thu, 12 Jun 2025 06:34:09 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc yes..i will raise it once we are done with this PR approval.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2965352618 From abhiscxk at openjdk.org Thu Jun 12 06:59:32 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 12 Jun 2025 06:59:32 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Thu, 12 Jun 2025 06:55:12 GMT, Prasanta Sadhukhan wrote: > yes..i will raise it once we are done with this PR approval.. Ok... Can't we just mention in the javadoc that `null image will throw an NPE` and then the code changes are not required? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2965357216 From psadhukhan at openjdk.org Thu Jun 12 07:03:29 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 12 Jun 2025 07:03:29 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: <8uOLu23AR3teJkHsn132J9aE0ASC-DJo0Irlm3EPvE0=.798d7432-f8d6-4ed7-9d91-03c08ac3a8a7@github.com> On Thu, 12 Jun 2025 06:57:20 GMT, Abhishek Kumar wrote: > > yes..i will raise it once we are done with this PR approval.. > > Ok... Can't we just mention in the javadoc that `null image will throw an NPE` and then the code changes are not required? No, as I mentioned in the description the MediaTracker creation and id addition, tracking and removal is supposedly not required for null image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2965365027 From abhiscxk at openjdk.org Thu Jun 12 07:41:27 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 12 Jun 2025 07:41:27 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Thu, 12 Jun 2025 06:34:09 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc LGTM ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2919898621 From david.briemann at sap.com Thu Jun 12 08:12:22 2025 From: david.briemann at sap.com (Briemann, David) Date: Thu, 12 Jun 2025 08:12:22 +0000 Subject: Windows AWT: support for running applications without display? Message-ID: Hi, I was recently asked to investigate this issue: https://bugs.openjdk.org/browse/JDK-8341294 Let me give a summary of the problem here (copied from newest comment in this ticket): # The problem A bugfix (https://bugs.openjdk.org/browse/JDK-8185862) changed the behavior of AWT applications on Windows when no display is available. ## Status Quo (HEAD, > jdk21) If an AWT application is started on a Windows system that does NOT have a display available it will run into: ``` Exception in thread "main" java.lang.InternalError: Could not update the devices array. ``` Setting `-Djava.awt.headless=false` does not affect this outcome. ## Earlier behavior (<= jdk 21) If an AWT application is started on a Windows system that does not have a display available it will just start / continue to run. ## Expectations Some JDK users were affected by this change because they run applications in Windows VMs without display. They want the old behavior back. Maybe by (ab)using setting the flag `-Djava.awt.headless=false` explicitly on startup. ## Observations The often mentioned old behavior may be sufficient to "just run" the application without display, however it is bugged. If you actually observe what is drawn to the screen when it reappears (e.g. by reconnecting to a remote host), then it can be observed that some UI elements are silently not drawn to the window, e.g. the "label" of a `ProgressMonitor`. ## What to do? Since I am neither a Windows user nor a an AWT expert I bring this up here for discussion. My current opinion is that the JVM should not revert to the old behavior. As stated above the old behavior is buggy. That certain old tests/workflows rely on this buggy behavior does not warrant going back in newer JVM versions in my opinion. I know there are all kinds of historically grown software stacks out there but if these tests / workflows really cannot be changed, maybe using a virtual display driver would be a workaround ( see e.g. https://github.com/VirtualDrivers/Virtual-Display-Driver ). I wanted to bring this to the attention of AWT devs. I was in contact with a Windows dev who is affected by this problem and his scenario boils down to this: * They are using AWT components in the backend to draw things to buffered images which are then delivered to customers as PNG. * They use a framework called BIRT, to create PDFs and Word documents, which in turn uses AWT components. * They cannot run their program because it runs into exceptions when e.g. creating the window. (in a windows container, without display) Since I am neither a Windows nor AWT dev I wanted to ask for your input here. Do you think these scenarios should be supported? If yes how? Because just ?reverting? to the old behavior does not seem like a good idea (at least to me). To my understanding this would mean that silently some things are just not drawn. Thanks for reading, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Thu Jun 12 11:05:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 12 Jun 2025 11:05:31 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 06:55:15 GMT, Tejesh R wrote: > > Opposite results of what's instructed. Attached screenshot. > > It is addressed in [JDK-8357799](https://bugs.openjdk.org/browse/JDK-8357799) fix. So didn't address here. @DamonGuy Yes, this issue is resolved in https://git.openjdk.org/jdk/pull/25455. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25707#issuecomment-2966159414 From kcr at openjdk.org Thu Jun 12 12:17:37 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Jun 2025 12:17:37 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: <-98ilvtpvMl9P2an6nnDN_X3rMei2hviJeHx4Pu6hPM=.1a64ab58-71ae-43ea-a826-959e2d0f0701@github.com> On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Marked as reviewed by kcr (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2920890018 From djelinski at openjdk.org Thu Jun 12 12:46:29 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 12 Jun 2025 12:46:29 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com> References: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com> Message-ID: On Wed, 11 Jun 2025 19:00:45 GMT, Sergey Bylokhov wrote: >> src/java.base/share/native/libnet/net_util.c line 77: >> >>> 75: CHECK_NULL_RETURN(s, JNI_VERSION_1_2); >>> 76: preferIPv4Stack = (*env)->CallStaticBooleanMethod(env, iCls, mid, s); >>> 77: JNU_CHECK_EXCEPTION_RETURN(env, JNI_VERSION_1_2); >> >> The exception check is technically not necessary because no other JNI methods are called before the function exits, but it wasn't always the case. > > If this check is not needed, then why are we adding it? just so we don't forget to add it when we modify the enclosing function. The call to `CallStaticBooleanMethod` is located pretty far from the end of the function, and can be easy to miss. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2142645794 From aivanov at openjdk.org Thu Jun 12 15:09:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 12 Jun 2025 15:09:31 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 10:41:09 GMT, Tejesh R wrote: >> [JDK-8139228](https://bugs.openjdk.org/browse/JDK-8139228) fix missed GTK updates for the same issue where file/directory name renders as `HTML text` instead of `plain text`. >> Adding the same fix for GTK L&F. >> Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > updating test Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25707#pullrequestreview-2921610481 From dnguyen at openjdk.org Thu Jun 12 15:45:32 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 12 Jun 2025 15:45:32 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 10:41:09 GMT, Tejesh R wrote: >> [JDK-8139228](https://bugs.openjdk.org/browse/JDK-8139228) fix missed GTK updates for the same issue where file/directory name renders as `HTML text` instead of `plain text`. >> Adding the same fix for GTK L&F. >> Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > updating test Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25707#pullrequestreview-2921745317 From dnguyen at openjdk.org Thu Jun 12 15:45:32 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 12 Jun 2025 15:45:32 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 11:02:59 GMT, Alexey Ivanov wrote: > > Opposite results of what's instructed. Attached screenshot. > > It is addressed in [JDK-8357799](https://bugs.openjdk.org/browse/JDK-8357799) fix. So didn't address here. Thanks, missed this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25707#issuecomment-2967350079 From kizune at openjdk.org Thu Jun 12 16:09:33 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 16:09:33 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Thu, 12 Jun 2025 06:34:09 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2921818254 From kizune at openjdk.org Thu Jun 12 16:09:34 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 16:09:34 GMT Subject: RFR: 8358532: JFileChooser in GTK L&F still displays HTML filename [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 10:41:09 GMT, Tejesh R wrote: >> [JDK-8139228](https://bugs.openjdk.org/browse/JDK-8139228) fix missed GTK updates for the same issue where file/directory name renders as `HTML text` instead of `plain text`. >> Adding the same fix for GTK L&F. >> Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > updating test Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25707#pullrequestreview-2921819964 From kizune at openjdk.org Thu Jun 12 16:11:31 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 16:11:31 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v3] In-Reply-To: References: Message-ID: On Tue, 3 Jun 2025 17:11:12 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision: > > - Align the title of frame with JFileChooser to htmlDisabled flag > - Use Serif font instead of Comic Sans MS > - Rename createFileChooser parameter htmlEnabled -> htmlDisabled Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25455#pullrequestreview-2921824680 From kizune at openjdk.org Thu Jun 12 16:14:50 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 12 Jun 2025 16:14:50 GMT Subject: RFR: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text [v17] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 16:22:52 GMT, Jeremy Wood wrote: >> Make sure AquaTextPasswordFieldUI can't use selectWordAction. >> >> The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. >> >> So the problem is partially about multiple inheritance. >> >> My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). >> >> There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8354646: moving test file to BasicTextUI package > > This is in response to: > https://github.com/openjdk/jdk/pull/25443#discussion_r2137904314 Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25443#pullrequestreview-2921827306 From duke at openjdk.org Thu Jun 12 16:14:53 2025 From: duke at openjdk.org (Jeremy Wood) Date: Thu, 12 Jun 2025 16:14:53 GMT Subject: Integrated: 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text In-Reply-To: References: Message-ID: On Mon, 26 May 2025 08:32:26 GMT, Jeremy Wood wrote: > Make sure AquaTextPasswordFieldUI can't use selectWordAction. > > The core problem here was we could call selectWordAction in the Aqua LAF on a JPasswordField. This problem was already solved in the BasicPasswordFieldUI . The same solution was copied and pasted into the SynthPasswordFieldUI . But the AquaTextPasswordFieldUI does NOT extend either class with the solution. > > So the problem is partially about multiple inheritance. > > My first response at solving the problem is just to move the existing solution to the parent BasicTextUI class and use an `instanceof` to make sure it is only applied to JPasswordFields. This should benefit all the PasswordFieldUI's (that I know about). > > There may be many different philosophies/recommendations on how to resolve this; I'm open to suggestions. This pull request has now been integrated. Changeset: 8d33ea73 Author: jeremy Committer: Alexander Zuev URL: https://git.openjdk.org/jdk/commit/8d33ea7395e5dd504b899d8972617f6696546d84 Stats: 149 lines in 5 files changed: 110 ins; 34 del; 5 mod 8354646: java.awt.TextField allows to identify the spaces in a password when double clicked at the starting and end of the text Reviewed-by: aivanov, kizune, tr, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/25443 From honkar at openjdk.org Thu Jun 12 16:26:30 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 12 Jun 2025 16:26:30 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile In-Reply-To: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: On Wed, 4 Jun 2025 23:39:05 GMT, Sergey Bylokhov wrote: > This PR simplifies several aspects of the ICC_Profile class: > > - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30): > The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377). > > - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe): > In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation. > > - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c): > After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code. > > @prrace @honkar-jdk please take a look src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 802: > 800: public static ICC_Profile getInstance(byte[] data) { > 801: ProfileDataVerifier.verify(data); > 802: verifyHeader(data); [verifyHeader(byte[] data)](https://github.com/openjdk/jdk/blob/3b32f6a8ec37338764d3e6713247ff96e49bf5b3/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java#L1176C2-L1184C6), expects header byte array and not the entire profile array, is it technically correct to send the entire profile byte array? Please note verifyHeader() is called from two places from `getInstance(byte[] data)` and `setData(int tagSignature, byte[] tagData)`, With the current fix, logically all the checks within verifyHeader() work (getProfileClass(data), getColorSpaceType(data) ...) because the data is extracted at specified index from the superset - entire profile byte array instead of the header byte array. If it is decided to send only header byte array to `verifyHeader() ` then changing the method param name to **header** instead of **data** may be clearer. private static void verifyHeader(byte[] header) { if (header == null || header.length < HEADER_SIZE) { throw new IllegalArgumentException("Invalid header data"); } getProfileClass(header); getColorSpaceType(header); getPCSType(header); checkRenderingIntent(header); } src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 807: > 805: System.arraycopy(data, 0, theHeader, 0, HEADER_SIZE); > 806: verifyHeader(theHeader); > 807: In reference to the above comment , these lines may need to be reverted as verifyHeader(byte[] header) expects the header array and not the entire profile byte array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2141743069 PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2141747655 From honkar at openjdk.org Thu Jun 12 16:38:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 12 Jun 2025 16:38:29 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile In-Reply-To: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: On Wed, 4 Jun 2025 23:39:05 GMT, Sergey Bylokhov wrote: > This PR simplifies several aspects of the ICC_Profile class: > > - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30): > The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377). > > - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe): > In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation. > > - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c): > After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code. > > @prrace @honkar-jdk please take a look @prrace @jayathirthrao You may want to take a look at this PR changes when you get a chance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25650#issuecomment-2967516227 From dnguyen at openjdk.org Thu Jun 12 17:53:12 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 12 Jun 2025 17:53:12 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v3] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update instructions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/b2f2fc54..154574ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=01-02 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From dnguyen at openjdk.org Thu Jun 12 17:53:13 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 12 Jun 2025 17:53:13 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v2] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Wed, 11 Jun 2025 22:09:27 GMT, Harshitha Onkar wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update PL num. Clarify instructions. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 52: > >> 50: pass the test. This test fails if the cursor updates >> 51: when pointing over the different components before >> 52: releasing the left mouse button. > > Suggestion: > > The mouse cursor appears as an I-beam cursor > and stays the same while dragging across the components. > Once you reach the list release the left mouse button, at that > moment the cursor should change to a Hand Cursor. > If the above is true press pass. > > The test fails if the cursor updates while dragging > over the different components before releasing > the left mouse button. Updated with some slight edits. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2143324510 From serb at openjdk.org Thu Jun 12 17:59:29 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 12 Jun 2025 17:59:29 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Thu, 12 Jun 2025 06:34:09 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc src/java.desktop/share/classes/javax/swing/ImageIcon.java line 374: > 372: */ > 373: public void setImage(Image image) { > 374: if (image == null) { don't we need to update the actual image icon of imageicon to null? similar to how constructor/and other methods works when they get "null-image"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2143336731 From achung at openjdk.org Thu Jun 12 18:07:48 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 12 Jun 2025 18:07:48 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v19] In-Reply-To: References: <0bHZatSlUNefQ0pP4-nrrQxJq3cqFh5PkP-bWfj-85M=.cb9f8784-c145-460d-8038-a4181189b7da@github.com> Message-ID: On Wed, 11 Jun 2025 18:12:22 GMT, Harshitha Onkar wrote: >> test/jdk/lib/client/ExtendedRobot.java line 237: >> >>> 235: public void glide(Point src, Point dest) { >>> 236: glide(src.x, src.y, dest.x, dest.y, DEFAULT_STEP_LENGTH, DEFAULT_SPEED); >>> 237: } >> >> @alisenchung >> >> Shouldn't `glide(Point src, Point dest)` and `glide(Point dest)` be retained in ExtendedRobot >> In [previous comment](https://github.com/openjdk/jdk/pull/22044/files#r2085671341) it was mentioned that these methods won't be migrated so do they need to be retained in ExtendedRobot ? >> >> I see `MultipleMouseButtonsTest.java` using `glide(Point src, Point dest)`. There are two options here: >> >> 1) Either update the test to use Robot's glide() >> change the line `robot.glide(origin, center)` to `robot.glide(origin.x, origin.y, center.x, center.y);` and completely remove ExtendedRobot versions of glide. >> >> 2) Or retain these two convenience methods in ExtendedRobot. > > There are few other tests that use ExtendedRobot version of glide() so probably option 2 (retaining the two convenience methods in ExtendedRobot) might be a better option. I think ideally ER will be removed in the future so depending on the number of tests using glide(point), I will either change the tests or readd glide(point) to Robot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2143350122 From serb at openjdk.org Thu Jun 12 18:10:40 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 12 Jun 2025 18:10:40 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile In-Reply-To: References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: <5ERPBtcxhHw0lkJNSelnAAIHk3kOLM1rDvA_Y7PJZCA=.2a224780-a5e6-4722-b26e-bf1c311adbc1@github.com> On Thu, 12 Jun 2025 05:26:54 GMT, Harshitha Onkar wrote: > [verifyHeader(byte[] data)](https://github.com/openjdk/jdk/blob/3b32f6a8ec37338764d3e6713247ff96e49bf5b3/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java#L1176C2-L1184C6), expects header byte array and not the entire profile array, is it technically correct to send the entire profile byte array? Validating the header directly without cloning is fine and actually better. The old code effectively skipped the "header.length < HEADER_SIZE" check because it always created a "new byte[HEADER_SIZE]". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2143354144 From philip.race at oracle.com Thu Jun 12 18:49:25 2025 From: philip.race at oracle.com (Philip Race) Date: Thu, 12 Jun 2025 11:49:25 -0700 Subject: Does anyone still want netbeans project files for building/running client demos ? Message-ID: I just submitted https://bugs.openjdk.org/browse/JDK-8359381 ----- There are netbeans projects for the client demos. % ls src/demo/share/nbproject README.txt jfc project.xml % ls src/demo/share/nbproject/jfc FileChooserDemo Notepad TransparentRuler Font2DTest SampleTree Metalworks TableExample ----- The question, as posed in the subject line, is do we really need to keep these? I'd like to delete them if there's no one who is interested and willing to maintain them -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Thu Jun 12 21:29:52 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 12 Jun 2025 21:29:52 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v7] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/27c6eebd..af967ded Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=05-06 Stats: 24 lines in 11 files changed: 0 ins; 23 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Thu Jun 12 21:29:52 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 12 Jun 2025 21:29:52 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:31:39 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1656: > >> 1654: * @return the first ancestor of c that's a Window >> 1655: */ >> 1656: @SuppressWarnings("removal") > > @SuppressWarnings("removal") can be deleted? That's a very good point. I had forgotten that the JDK build does not warn about *unneeded* suppressions. Only missing ones. And all those little instanceof checks means there's a bunch of them. I'll try to spot them all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143690414 From prr at openjdk.org Thu Jun 12 22:20:01 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 12 Jun 2025 22:20:01 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/af967ded..0e921237 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=06-07 Stats: 224 lines in 3 files changed: 223 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Thu Jun 12 22:37:35 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 12 Jun 2025 22:37:35 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:22:02 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > src/java.desktop/share/classes/java/awt/Window.java line 3864: > >> 3862: content.setOpaque(isOpaque); >> 3863: >> 3864: // Iterate down one level to see whether we have (eg) a JInternalFrame > > I think it is more related to top level windows like JWindow/JDialog etc. I am not sure that's the case. I think it best to leave the comment as it is - minus mention of applet. > src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 113: > >> 111: * registry functions. >> 112: * >> 113: *

      Each {@code ThreadGroup} will receive its own instance. > > Note that this new specification is not tied to AppContext. Do we still want to support ThreadGroup sandboxing even if AppContext will be removed? Can we drop it now, since current spec clearly tied to applets and AppContext usage? AppContext is really a ThreadGroup so it will behave as specified. Changing this needs to be done in a separate follow-up bug likely with a CSR-specific to ImageIO, removing the ThreadGroup support. Not in this PR. I submitted https://bugs.openjdk.org/browse/JDK-8359391 > src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java line 796: > >> 794: BufferStrategy bs = null; >> 795: try { >> 796: ((Window)root).createBufferStrategy(2, caps); > > We probably can change the type of "root" to "Window". There would be quite a ripple effect because callers are handed a container from other methods. Adds risk I don't need here. Seems like a possible follow-on clean up bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143723251 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143714809 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143708779 From prr at openjdk.org Thu Jun 12 22:37:36 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 12 Jun 2025 22:37:36 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 19:39:11 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > src/java.desktop/share/classes/javax/swing/JComponent.java line 4684: > >> 4682: >> 4683: /** >> 4684: * Returns the top-level ancestor of this component (either the > > Suggestion: > > * Returns the top-level ancestor of this component (the > > There's only one option left in the parentheses. OK. > src/java.desktop/share/classes/javax/swing/JRootPane.java line 51: > >> 49: * component on the host system) are shown with a heavier box. AWT components in red, >> 50: * Swing heavyweights in blue. >> 51: * The three heavyweight JFC/Swing containers ({@code JFrame}, {@code JDialog}, and > > Shall we drop _?JFC?_? Out of scope of what I need to do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143700859 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143697200 From prr at openjdk.org Thu Jun 12 22:37:38 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 12 Jun 2025 22:37:38 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 19:38:01 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java line 33: > >> 31: * @library /vmTestbase >> 32: * /test/lib >> 33: * @run main/othervm jit.misctests.fpustack.GraphApplet > > Why do we delete this test? it is better to update it. I discussed this test at length with the VM team and it was their request to delete it as they do not want to invest in updating it. It has been on the "to be deleted" list (removal_candidates.txt) for at least 7 and likely more than 10 years and it is never run and never will be. At least not by Oracle. > test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 51: > >> 49: * @run main/othervm -Xmx128m AudioContentHandlers >> 50: */ >> 51: public final class AudioContentHandlers { > > I see the src/java.desktop/share/classes/sun/awt/www/content/audio/ are not updated, so what will be the replacement of AudioClip? I guess we should return SoundClip now? I looked into this when I was doing SoundClip. What is actually returned by contract is a ContentHandler which returns an Object from its getContent() method That Object happens to be a com.sun.media.sound.JavaSoundAudioClip which previously implemented AudioClip This implements relationship isn't there for SoundClip, so the expectation of the test that it knows of an exported type that will actually be returned is no longer valid. I don't think it is worth testing that JavaSoundAudioClip is returned. Possibly we could jsut verify that a non-null handler is returned ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143693619 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143762913 From prr at openjdk.org Thu Jun 12 22:37:39 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 12 Jun 2025 22:37:39 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v5] In-Reply-To: References: Message-ID: <62Mly_ZNNzq86rWPqCuHivuO3YPQeFAV33GGPAWVZ0o=.e0d63be4-65e2-4044-a05e-a8a8333bc272@github.com> On Wed, 11 Jun 2025 19:42:38 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 44: > >> (failed to retrieve contents of file, check the PR for context) > This test should be updated to use SoundClip instead. I think I can do that > test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 48: > >> (failed to retrieve contents of file, check the PR for context) > This test should be updated to use SoundClip instead. I think I can do that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143746596 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143741448 From serb at openjdk.org Thu Jun 12 22:50:40 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 12 Jun 2025 22:50:40 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 22:34:51 GMT, Phil Race wrote: >> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 51: >> >>> 49: * @run main/othervm -Xmx128m AudioContentHandlers >>> 50: */ >>> 51: public final class AudioContentHandlers { >> >> I see the src/java.desktop/share/classes/sun/awt/www/content/audio/ are not updated, so what will be the replacement of AudioClip? I guess we should return SoundClip now? > > I looked into this when I was doing SoundClip. > What is actually returned by contract is a ContentHandler which returns an Object from its getContent() method > That Object happens to be a com.sun.media.sound.JavaSoundAudioClip which previously implemented AudioClip > > This implements relationship isn't there for SoundClip, so the expectation of the test that it knows of an exported type that will actually be returned is no longer valid. > > I don't think it is worth testing that JavaSoundAudioClip is returned. > > Possibly we could jsut verify that a non-null handler is returned ? As far as I understand, this method should return something that the application can actually use. Previously, the application could access the audio data via the AudioClip interface - it wasn?t important that it was specifically implemented by JavaSoundAudioClip. Now, I believe we should return a SoundClip object, which can be created (not necessarily via the public API of the SoundClip/JavaSoundAudioClip classes). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143777885 From serb at openjdk.org Thu Jun 12 22:56:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 12 Jun 2025 22:56:48 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: <5pD0bFEqR2qiBSXsKWL8cyEL1WR9crFRE1lMejNsb8g=.bb1c734c-50d1-42c9-8539-2d102c62a9fb@github.com> On Thu, 12 Jun 2025 21:45:50 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 113: >> >>> 111: * registry functions. >>> 112: * >>> 113: *

      Each {@code ThreadGroup} will receive its own instance. >> >> Note that this new specification is not tied to AppContext. Do we still want to support ThreadGroup sandboxing even if AppContext will be removed? Can we drop it now, since current spec clearly tied to applets and AppContext usage? > > AppContext is really a ThreadGroup so it will behave as specified. > Changing this needs to be done in a separate follow-up bug likely with a CSR-specific to ImageIO, removing the ThreadGroup support. > Not in this PR. I submitted https://bugs.openjdk.org/browse/JDK-8359391 I would like to confirm that we treat ThreadGroup based sandboxing as equivalent to AppContext based sandboxing. There are a few places where we still use ThreadGroup instead of AppContext, and I believe we can drop that usage at the same time AppContext is removed, even if the specification includes statements like "Each {@code ThreadGroup} will receive its own instance." - correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143782847 From serb at openjdk.org Thu Jun 12 23:02:34 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 12 Jun 2025 23:02:34 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: Message-ID: <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com> On Thu, 12 Jun 2025 22:20:01 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 73: > 71: > 72: private static void checkThread(File file) throws Exception { > 73: SoundClip clip = SoundClip.createSoundClip(file); I think we should either support content handlers via the new SoundClip object or remove the existing implementation, as it is currently tied to AudioClip. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143788994 From serb at openjdk.org Thu Jun 12 23:11:33 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 12 Jun 2025 23:11:33 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 21:54:03 GMT, Phil Race wrote: >> src/java.desktop/share/classes/java/awt/Window.java line 3864: >> >>> 3862: content.setOpaque(isOpaque); >>> 3863: >>> 3864: // Iterate down one level to see whether we have (eg) a JInternalFrame >> >> I think it is more related to top level windows like JWindow/JDialog etc. > > I am not sure that's the case. I think it best to leave the comment as it is - minus mention of applet. After the applet removal, this could be dead code. It might be better not to mention JInternalFrame unless we have prove that the code actually works for it, add a TODO? or something? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143797148 From serb at openjdk.org Thu Jun 12 23:11:33 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 12 Jun 2025 23:11:33 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 23:06:41 GMT, Sergey Bylokhov wrote: >> I am not sure that's the case. I think it best to leave the comment as it is - minus mention of applet. > > After the applet removal, this could be dead code. It might be better not to mention JInternalFrame unless we have prove that the code actually works for it, add a TODO? or something? it could be related to appletviewer ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143798449 From dnguyen at openjdk.org Thu Jun 12 23:33:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 12 Jun 2025 23:33:46 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v4] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Update test to avoid PFJ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/154574ec..88d9cea1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=02-03 Stats: 89 lines in 1 file changed: 59 ins; 13 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From dnguyen at openjdk.org Thu Jun 12 23:33:53 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 12 Jun 2025 23:33:53 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v3] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Thu, 12 Jun 2025 17:53:12 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update instructions. I updated the test on @TejeshR13 's recommendation to refer to https://github.com/openjdk/jdk/pull/22026 to work around having to use PFJFrame. Tested and this test works on Windows as expected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25705#issuecomment-2968435721 From honkar at openjdk.org Fri Jun 13 00:37:37 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 13 Jun 2025 00:37:37 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v4] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Thu, 12 Jun 2025 23:33:46 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update test to avoid PFJ The custom manual test frame changes LGTM apart for minor inline suggestions and works as expected on windows. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 31: > 29: */ > 30: > 31: import java.awt.Button; Copyright year needs to be updated test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 80: > 78: frame.add(panel); > 79: frame.setSize(300, 150); > 80: frame.setLocation(450, 400); Allows more space between the windows Suggestion: frame.setLocation(450, 500); test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 85: > 83: > 84: static void createInstructionsFrame() { > 85: String INSTRUCTIONS = """ Since it is local var (non-static & non-final var) Suggestion: String instructions = """ test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 124: > 122: instructionsFrame.pack(); > 123: instructionsFrame.setLocation(300, 100); > 124: instructionsFrame.setVisible(true); Rearranging the lines provides better clarity. mainPanel layout can be set to BorderLayout for better placement of the instruction panel and button panel. Suggestion: instructionsFrame = new Frame("Test Instructions"); Panel mainPanel = new Panel(new BorderLayout()); TextArea textArea = new TextArea(instructions, 15, 60, TextArea.SCROLLBARS_NONE); Panel btnPanel = new Panel(); Button passBtn = new Button("PASS"); Button failBtn = new Button("FAIL"); btnPanel.add(passBtn); btnPanel.add(failBtn); passBtn.addActionListener(e -> disposeFrames()); failBtn.addActionListener(e -> { disposeFrames(); throw new RuntimeException("Test Failed"); }); mainPanel.add(textArea, BorderLayout.CENTER); mainPanel.add(btnPanel, BorderLayout.SOUTH); instructionsFrame.add(mainPanel); instructionsFrame.pack(); instructionsFrame.setLocation(300, 100); instructionsFrame.setVisible(true); ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25705#pullrequestreview-2923069668 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2143974229 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2143967233 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2143975147 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2143964455 From achung at openjdk.org Fri Jun 13 00:40:30 2025 From: achung at openjdk.org (Alisen Chung) Date: Fri, 13 Jun 2025 00:40:30 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v20] In-Reply-To: References: Message-ID: > Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: - update tests, remove extended robot from some tests - update tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22044/files - new: https://git.openjdk.org/jdk/pull/22044/files/a46b067b..9aa82019 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=18-19 Stats: 53 lines in 12 files changed: 7 ins; 16 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/22044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044 PR: https://git.openjdk.org/jdk/pull/22044 From honkar at openjdk.org Fri Jun 13 00:50:31 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 13 Jun 2025 00:50:31 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v4] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Thu, 12 Jun 2025 23:33:46 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Update test to avoid PFJ test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 49: > 47: public static CountDownLatch createCountDownLatch() { > 48: return new CountDownLatch(1); > 49: } `countDownLatch = new CountDownLatch(1);` can be directly assigned in main, no need of the extra method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2143997558 From psadhukhan at openjdk.org Fri Jun 13 03:44:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 13 Jun 2025 03:44:30 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Thu, 12 Jun 2025 06:34:09 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc Raised CSR https://bugs.openjdk.org/browse/JDK-8359398 @azuev-java @kumarabhi006 Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2968928183 From psadhukhan at openjdk.org Fri Jun 13 03:48:35 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 13 Jun 2025 03:48:35 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Thu, 12 Jun 2025 17:56:50 GMT, Sergey Bylokhov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 374: > >> 372: */ >> 373: public void setImage(Image image) { >> 374: if (image == null) { > > don't we need to update the actual image icon of imageicon to null? similar to how constructor/and other methods works when they get "null-image"? In constructor also, it returns https://github.com/openjdk/jdk/blob/991097b7bf08cc1a4ceedb0c555b12948ae71885/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L146-L148 https://github.com/openjdk/jdk/blob/991097b7bf08cc1a4ceedb0c555b12948ae71885/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L185-L187 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2144148400 From aivanov at openjdk.org Fri Jun 13 05:06:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 13 Jun 2025 05:06:27 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 15:04:21 GMT, Prasanta Sadhukhan wrote: >> ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. >> >> Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" >> >> Made sure there is no overflow and treat that loadImage as ABORTED >> >> No regression testcase as it addresses theoretical possibility.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reset mediaTrackerID if it overflows Here's the test case that I used. (Thanks to @mickleness for the code, setting an image significantly increased the performance of the test; my initial test loaded an image from the disk for each instance of `ImageIcon`, and it took more than 6 hours to overflow `mediaTrackerId` into negative values.)

      ImageIconOverflow.java import java.awt.Graphics; import java.awt.Image; import java.awt.Toolkit; import java.awt.image.BufferedImage; import java.io.File; import java.io.IOException; import java.util.stream.IntStream; import javax.imageio.ImageIO; import javax.swing.ImageIcon; import static java.awt.image.BufferedImage.TYPE_INT_RGB; public class ImageIconOverflow { private static final String IMAGE_FILENAME = "image.png"; public static void main(String[] args) throws IOException { createImage(); final Image image = Toolkit.getDefaultToolkit().createImage("onepixel.gif"); IntStream.range(0, Integer.MAX_VALUE - 1) .forEach((c) -> new ImageIcon(image)); System.out.println("---"); new ImageIcon(IMAGE_FILENAME); System.out.println("+++"); new ImageIcon(IMAGE_FILENAME); new ImageIcon(IMAGE_FILENAME); System.out.println("###"); IntStream.range(0, Integer.MAX_VALUE - 1) .forEach((c) -> new ImageIcon(image)); System.out.println("---"); new ImageIcon(IMAGE_FILENAME); System.out.println("+++"); new ImageIcon(IMAGE_FILENAME); new ImageIcon(IMAGE_FILENAME); } private static void createImage() throws IOException { BufferedImage image = new BufferedImage(1, 1, TYPE_INT_RGB); Graphics g = image.getGraphics(); g.fillRect(0, 0, image.getWidth(), image.getHeight()); g.dispose(); File file = new File(IMAGE_FILENAME); ImageIO.write(image, "png", file); file.deleteOnExit(); } }
      I also modified `IconImage.java` to print the id.
      Diff for ImageIcon.java diff --git a/src/java.desktop/share/classes/javax/swing/ImageIcon.java b/src/java.desktop/share/classes/javax/swing/ImageIcon.java index 2bae31ba31f..8638da90567 100644 --- a/src/java.desktop/share/classes/javax/swing/ImageIcon.java +++ b/src/java.desktop/share/classes/javax/swing/ImageIcon.java @@ -296,6 +296,13 @@ protected void loadImage(Image image) { synchronized(mTracker) { int id = getNextID(); + if (id <= 0x8000000F + || (id >= 0 && id <= 0x0000000F) + || id > 0x7ffffff0) { + System.out.println("ImageIcon.id=" + String.format("%08x", id) + + " " + id); + } + mTracker.addImage(image, id); try { mTracker.waitForID(id, 0);
      In 25 minutes, the case overflowed twice: from positive into negative, and then from negative into positive. ImageIcon.id=00000001 1 ImageIcon.id=00000002 2 ... ImageIcon.id=7ffffffd 2147483645 ImageIcon.id=7ffffffe 2147483646 --- ImageIcon.id=7fffffff 2147483647 +++ ImageIcon.id=80000000 -2147483648 ImageIcon.id=80000001 -2147483647 ### ImageIcon.id=80000002 -2147483646 ... ImageIcon.id=8000000f -2147483633 --- ImageIcon.id=00000000 0 +++ ImageIcon.id=00000001 1 ImageIcon.id=00000002 2 Thus, I think there's nothing to fix. Yes, `IconImage.mediaTrackerId` can overflow, but it's not an issue. Therefore, I propose to close the bug as *?Not an Issue?* or *?Won't Fix?*. Prasanta's second [commit fd2ad26](https://github.com/openjdk/jdk/pull/25666/commits/fd2ad261356ec85585fe2f838ccc1273dd90b390) resolves the problem with overflow the way that [I suggested](https://github.com/openjdk/jdk/pull/25666#issuecomment-2962726712). But it fixes the potential problem that doesn't affect the behaviour of `ImageIcon` that is proved by the test in this comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2967332196 From psadhukhan at openjdk.org Fri Jun 13 05:06:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 13 Jun 2025 05:06:28 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 15:04:21 GMT, Prasanta Sadhukhan wrote: >> ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. >> >> Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" >> >> Made sure there is no overflow and treat that loadImage as ABORTED >> >> No regression testcase as it addresses theoretical possibility.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reset mediaTrackerID if it overflows But if the fix doesnt hamper anything and still fixes the problem of overflow (even if overflow itself doesn't apparently cause any issue) maybe we should consider it.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2969048202 From avieirov at redhat.com Fri Jun 13 08:54:45 2025 From: avieirov at redhat.com (Antonio Vieiro) Date: Fri, 13 Jun 2025 10:54:45 +0200 Subject: Does anyone still want netbeans project files for building/running client demos ? In-Reply-To: References: Message-ID: <68775206-ad33-4485-a097-5a08e10a3f8b@redhat.com> Hi all, Yes, those "nbproject" files are very outdated and can't even be opened with the latest NetBeans versions. Demos are still shipped by different people [1]. I think it's worth updating and keeping them around, because it makes it easier for newbies to open them in an IDE and experiment with them. I can update them to the latest NetBeans versions if you want. Cheers, Antonio [1] https://packages.debian.org/es/sid/amd64/openjdk-23-demo https://packages.fedoraproject.org/pkgs/java-25-openjdk/java-25-openjdk-demo/index.html El 12/6/25 a las 20:49, Philip Race escribi?: > > I just submitted https://bugs.openjdk.org/browse/JDK-8359381 > ----- > There are netbeans projects for the client demos. > > % ls src/demo/share/nbproject > README.txt jfc project.xml > % ls src/demo/share/nbproject/jfc > FileChooserDemo Notepad TransparentRuler > Font2DTest SampleTree > Metalworks TableExample > ----- > > The question, as posed in the subject line, is do we really need to keep these? > I'd like to delete them if there's no one who is interested and willing to maintain them > > -phil. From duke at openjdk.org Fri Jun 13 09:43:31 2025 From: duke at openjdk.org (ExE Boss) Date: Fri, 13 Jun 2025 09:43:31 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Fri, 13 Jun 2025 03:46:05 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 374: >> >>> 372: */ >>> 373: public void setImage(Image image) { >>> 374: if (image == null) { >> >> don't we need to update the actual image icon of imageicon to null? similar to how constructor/and other methods works when they get "null-image"? > > In constructor also, it returns > > https://github.com/openjdk/jdk/blob/991097b7bf08cc1a4ceedb0c555b12948ae71885/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L146-L148 > https://github.com/openjdk/jdk/blob/991097b7bf08cc1a4ceedb0c555b12948ae71885/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L185-L187 Yes, but?only after the?`this.image` field?is?set to?`null`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2144623394 From serb at openjdk.org Fri Jun 13 10:01:33 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 13 Jun 2025 10:01:33 GMT Subject: RFR: 8357686: Remove unnecessary Map.get from AWTAutoShutdown.unregisterPeer In-Reply-To: References: Message-ID: <0J8rQ8Ump7ebIc-TBck4fRvsEHtMjFgZfiktlWv-vOc=.c1703d69-0e31-4fef-ab70-59adf728af86@github.com> On Thu, 24 Apr 2025 20:18:01 GMT, Andrey Turbanov wrote: > Instead of separate `.get(Key)`+`.remove(Key)` calls we can call `.remove(Key, Value)`. > `peerMap` is an `IdentityHashMap`. IdentityHashMap.remove compares values with == since Java 20 ([JDK-8178355](https://bugs.openjdk.org/browse/JDK-8178355)) Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24858#pullrequestreview-2924156759 From psadhukhan at openjdk.org Fri Jun 13 10:02:21 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 13 Jun 2025 10:02:21 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v3] In-Reply-To: References: Message-ID: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Update image instance before returning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/bcdef9b4..43d43c63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From psadhukhan at openjdk.org Fri Jun 13 10:02:21 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 13 Jun 2025 10:02:21 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Fri, 13 Jun 2025 09:37:42 GMT, ExE Boss wrote: >> In constructor also, it returns >> >> https://github.com/openjdk/jdk/blob/991097b7bf08cc1a4ceedb0c555b12948ae71885/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L146-L148 >> https://github.com/openjdk/jdk/blob/991097b7bf08cc1a4ceedb0c555b12948ae71885/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L185-L187 > > Yes, but?only after the?`this.image` field?is?set to?`null`. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2144671599 From aivanov at openjdk.org Fri Jun 13 10:11:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 13 Jun 2025 10:11:29 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 05:03:46 GMT, Prasanta Sadhukhan wrote: > But if the fix doesnt hamper anything and still fixes the problem of overflow The fix makes the code more complicated for no reason because? in your own words > ?**overflow itself doesn't apparently cause any issue** > but I get popular sentiment of not fixing what ain't broke (or not proven yet to be broken) Exactly! If it ain't broken and it works, don't fix it. > maybe we should consider it.. We *may* consider it? Let's see if anyone else has an opinion. Yet I'm strongly inclined to *not touching it* because **it works as expected** even when `IconImage.mediaTrackerId` overflows from positive into negative values and then back to positive values. (There's nothing wrong with a negative id.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2969834510 From ihse at openjdk.org Fri Jun 13 13:52:39 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 13 Jun 2025 13:52:39 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 21:25:42 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1656: >> >>> 1654: * @return the first ancestor of c that's a Window >>> 1655: */ >>> 1656: @SuppressWarnings("removal") >> >> @SuppressWarnings("removal") can be deleted? > > That's a very good point. I had forgotten that the JDK build does not warn about *unneeded* suppressions. Only missing ones. And all those little instanceof checks means there's a bunch of them. I'll try to spot them all. I wish there were a way to do that, but I can't see how that could be done. At the core of the problem lies the fact that the specification of `@SuppressWarnings` does not specify what you can give as strings, and different compilers can behave differently and have any arbitrary strings. So javac cannot say "this string is invalid" or "this warning does not apply here so nothing is suppressed". Or, well, it *could* do but that but then it would complain on code that is "technically" correct. I don't think I'd be very successful in persuading the langtools team to do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2145147941 From dnguyen at openjdk.org Fri Jun 13 17:11:17 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 13 Jun 2025 17:11:17 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Rearrange and update test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/88d9cea1..39efefcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=03-04 Stats: 27 lines in 1 file changed: 8 ins; 11 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From dnguyen at openjdk.org Fri Jun 13 17:11:17 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 13 Jun 2025 17:11:17 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: <43LyfYQNmBScaQ476GyowJntTSkqKMgtkgG_Lo8iwoQ=.a75ea871-87bc-4ffe-8792-f58772683695@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> <9brisppAbJL-cS2_qPcaDdOzVVMA6CAGMBHAbKiuqgM=.285db865-c736-46ef-b15f-5897df7a74e1@github.com> <43LyfYQNmBScaQ476GyowJntTSkqKMgtkgG_Lo8iwoQ=.a75ea871-87bc-4ffe-8792-f58772683695@github.com> Message-ID: <3LFxkmmwNkxzGawQG6Q-ClaxGeqEnin3Vr8oSTWdJds=.35b6d964-6ea6-4bfc-8116-87823d63caf1@github.com> On Wed, 11 Jun 2025 21:53:37 GMT, Harshitha Onkar wrote: >> Could it be that mere existence of other windows created by the same Java process somehow changes the cursors? >> >> I mean `PassFailJFrame` displays another window. What if you create a second window (that may display nothing inside) in your stand-alone test? Does it change what cursors you see when dragging? > > Since the standalone test works as expected on windows, I'm not sure if the test needs to be problemlisted on windows, as @aivanov-jdk mentioned earlier it may be a side-effect of PFJ. > > I used the standalone test and added another dummy frame, even with extra frame the test works as expected. (cursor remains a I-beam until the left mouse btn is released) Since I reworked the test to avoid using PFJ, I don't need to do anything like PL the test for windows anymore. I'll just file a new bug for PFJ instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2145551473 From dnguyen at openjdk.org Fri Jun 13 17:11:18 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 13 Jun 2025 17:11:18 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v4] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <_jnj9hOA5Lmce5xT_CdQIzZibcigMRzmjv4cqFb2SEY=.5e5af215-cb35-4225-adb7-5cd6adad50c5@github.com> On Fri, 13 Jun 2025 00:31:03 GMT, Harshitha Onkar wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test to avoid PFJ > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 124: > >> 122: instructionsFrame.pack(); >> 123: instructionsFrame.setLocation(300, 100); >> 124: instructionsFrame.setVisible(true); > > Rearranging the lines provides better clarity. mainPanel layout can be set to BorderLayout for better placement of the instruction panel and button panel. > > Suggestion: > > instructionsFrame = new Frame("Test Instructions"); > Panel mainPanel = new Panel(new BorderLayout()); > TextArea textArea = new TextArea(instructions, 15, 60, > TextArea.SCROLLBARS_NONE); > > Panel btnPanel = new Panel(); > Button passBtn = new Button("PASS"); > Button failBtn = new Button("FAIL"); > btnPanel.add(passBtn); > btnPanel.add(failBtn); > > passBtn.addActionListener(e -> disposeFrames()); > failBtn.addActionListener(e -> { > disposeFrames(); > throw new RuntimeException("Test Failed"); > }); > > mainPanel.add(textArea, BorderLayout.CENTER); > mainPanel.add(btnPanel, BorderLayout.SOUTH); > > instructionsFrame.add(mainPanel); > instructionsFrame.pack(); > instructionsFrame.setLocation(300, 100); > instructionsFrame.setVisible(true); Thanks for the suggestion. Updated the test with the list of changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2145549781 From philip.race at oracle.com Fri Jun 13 17:17:35 2025 From: philip.race at oracle.com (Philip Race) Date: Fri, 13 Jun 2025 10:17:35 -0700 Subject: Does anyone still want netbeans project files for building/running client demos ? In-Reply-To: <68775206-ad33-4485-a097-5a08e10a3f8b@redhat.com> References: <68775206-ad33-4485-a097-5a08e10a3f8b@redhat.com> Message-ID: <0905548e-0530-437f-b818-e51f5c4b0ccf@oracle.com> I am definitely up for a volunteer for this ! J2Demo, Stylepad and SwingSet2 are completely missing netbeans projects. As I think I mentioned in the bug report, that's because when they were open-sourced, the project files, because they live in a parallel directory, were overlooked. I don't think it is worth open-sourcing those non-working projects now as a starter unless you absolutely need them but I doubt you do. Same pattern as all the others. You can use the bug ID 8359381? I submitted in your PR -phil On 6/13/25 1:54 AM, Antonio Vieiro wrote: > Hi all, > > Yes, those "nbproject" files are very outdated and can't even be > opened with the latest NetBeans versions. > > Demos are still shipped by different people [1]. > > I think it's worth updating and keeping them around, because it makes > it easier for newbies to open them in an IDE and experiment with them. > > I can update them to the latest NetBeans versions if you want. > > Cheers, > Antonio > > [1] > https://packages.debian.org/es/sid/amd64/openjdk-23-demo > https://packages.fedoraproject.org/pkgs/java-25-openjdk/java-25-openjdk-demo/index.html > > > El 12/6/25 a las 20:49, Philip Race escribi?: >> >> I just submitted https://bugs.openjdk.org/browse/JDK-8359381 >> ----- >> There are netbeans projects for the client demos. >> >> % ls src/demo/share/nbproject >> README.txt jfc project.xml >> % ls src/demo/share/nbproject/jfc >> FileChooserDemo Notepad TransparentRuler >> Font2DTest SampleTree >> Metalworks TableExample >> ----- >> >> The question, as posed in the subject line, is do we really need to >> keep these? >> I'd like to delete them if there's no one who is interested and >> willing to maintain them >> >> -phil. > > From honkar at openjdk.org Fri Jun 13 17:24:39 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 13 Jun 2025 17:24:39 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <9OXBtymd_zKoLbRUKcKEemVwXlyOEMgA03cWKDAnlSc=.3752c115-3dcb-49d4-b03f-cbcc3b9334d2@github.com> On Fri, 13 Jun 2025 17:11:17 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Rearrange and update test. Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25705#pullrequestreview-2925581979 From honkar at openjdk.org Fri Jun 13 17:24:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 13 Jun 2025 17:24:40 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: <3LFxkmmwNkxzGawQG6Q-ClaxGeqEnin3Vr8oSTWdJds=.35b6d964-6ea6-4bfc-8116-87823d63caf1@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <4mhv1iJXwD1JDKRqpfoGzmDYU9E5Rv-txuQTDjkHIqc=.eb0163cb-e851-40e9-9e5c-2e88f1bed0b3@github.com> <9brisppAbJL-cS2_qPcaDdOzVVMA6CAGMBHAbKiuqgM=.285db865-c736-46ef-b15f-5897df7a74e1@github.com> <43LyfYQNmBScaQ476GyowJntTSkqKMgtkgG_Lo8iwoQ=.a75ea871-87bc-4ffe-8792-f58772683695@github.com> <3LFxkmmwNkxzGawQG6Q-ClaxGeqEnin3Vr8oSTWdJds=.35b6d964-6ea6-4bfc-8116-87823d63caf1@github.com> Message-ID: On Fri, 13 Jun 2025 17:08:09 GMT, Damon Nguyen wrote: >> Since the standalone test works as expected on windows, I'm not sure if the test needs to be problemlisted on windows, as @aivanov-jdk mentioned earlier it may be a side-effect of PFJ. >> >> I used the standalone test and added another dummy frame, even with extra frame the test works as expected. (cursor remains a I-beam until the left mouse btn is released) > > Since I reworked the test to avoid using PFJ, I don't need to do anything like PL the test for windows anymore. I'll just file a new bug for PFJ instead. Yes, that is correct. The cursor issue that was observed is specific to PFJ. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2145571913 From avieirov at redhat.com Fri Jun 13 18:28:37 2025 From: avieirov at redhat.com (Antonio Vieiro) Date: Fri, 13 Jun 2025 20:28:37 +0200 Subject: Does anyone still want netbeans project files for building/running client demos ? In-Reply-To: <0905548e-0530-437f-b818-e51f5c4b0ccf@oracle.com> References: <68775206-ad33-4485-a097-5a08e10a3f8b@redhat.com> <0905548e-0530-437f-b818-e51f5c4b0ccf@oracle.com> Message-ID: Hi, No need to open-source anything, no. I'll take a look at the demos as time permits. We may want to exploit JEP-330 when possible too. Cheers, Antonio El 13/6/25 a las 19:17, Philip Race escribi?: > I am definitely up for a volunteer for this ! > > J2Demo, Stylepad and SwingSet2 are completely missing netbeans projects. > As I think I mentioned in the bug report, that's because when they were open-sourced, > the project files, because they live in a parallel directory, were overlooked. > I don't think it is worth open-sourcing those non-working projects now as a starter unless > you absolutely need them but I doubt you do. Same pattern as all the others. > > You can use the bug ID 8359381? I submitted in your PR > > -phil > > On 6/13/25 1:54 AM, Antonio Vieiro wrote: >> Hi all, >> >> Yes, those "nbproject" files are very outdated and can't even be opened with the latest NetBeans versions. >> >> Demos are still shipped by different people [1]. >> >> I think it's worth updating and keeping them around, because it makes it easier for newbies to open them in an IDE and experiment with them. >> >> I can update them to the latest NetBeans versions if you want. >> >> Cheers, >> Antonio >> >> [1] >> https://packages.debian.org/es/sid/amd64/openjdk-23-demo >> https://packages.fedoraproject.org/pkgs/java-25-openjdk/java-25-openjdk-demo/index.html >> >> El 12/6/25 a las 20:49, Philip Race escribi?: >>> >>> I just submitted https://bugs.openjdk.org/browse/JDK-8359381 >>> ----- >>> There are netbeans projects for the client demos. >>> >>> % ls src/demo/share/nbproject >>> README.txt jfc project.xml >>> % ls src/demo/share/nbproject/jfc >>> FileChooserDemo Notepad TransparentRuler >>> Font2DTest SampleTree >>> Metalworks TableExample >>> ----- >>> >>> The question, as posed in the subject line, is do we really need to keep these? >>> I'd like to delete them if there's no one who is interested and willing to maintain them >>> >>> -phil. >> >> > -- Antonio Vieiro SSE - Sustaining Engineering Red Hat, Inc. (https://www.redhat.com) PGP key : https://keys.openpgp.org/vks/v1/by-fingerprint/9A0CE286F22F7CCF2BC045FB1163A4EF861302B0 Fingerprint: 9A0C E286 F22F 7CCF 2BC0 45FB 1163 A4EF 8613 02B0 From philip.race at oracle.com Fri Jun 13 18:30:30 2025 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Jun 2025 11:30:30 -0700 Subject: Does anyone still want netbeans project files for building/running client demos ? In-Reply-To: References: <68775206-ad33-4485-a097-5a08e10a3f8b@redhat.com> <0905548e-0530-437f-b818-e51f5c4b0ccf@oracle.com> Message-ID: Most aren't single file but OK. -phil On 6/13/2025 11:28, Antonio Vieiro wrote: > Hi, > > No need to open-source anything, no. > > I'll take a look at the demos as time permits. We may want to exploit > JEP-330 when possible too. > > Cheers, > Antonio > > El 13/6/25 a las 19:17, Philip Race escribi?: >> I am definitely up for a volunteer for this ! >> >> J2Demo, Stylepad and SwingSet2 are completely missing netbeans projects. >> As I think I mentioned in the bug report, that's because when they >> were open-sourced, >> the project files, because they live in a parallel directory, were >> overlooked. >> I don't think it is worth open-sourcing those non-working projects >> now as a starter unless >> you absolutely need them but I doubt you do. Same pattern as all the >> others. >> >> You can use the bug ID 8359381? I submitted in your PR >> >> -phil >> >> On 6/13/25 1:54 AM, Antonio Vieiro wrote: >>> Hi all, >>> >>> Yes, those "nbproject" files are very outdated and can't even be >>> opened with the latest NetBeans versions. >>> >>> Demos are still shipped by different people [1]. >>> >>> I think it's worth updating and keeping them around, because it >>> makes it easier for newbies to open them in an IDE and experiment >>> with them. >>> >>> I can update them to the latest NetBeans versions if you want. >>> >>> Cheers, >>> Antonio >>> >>> [1] >>> https://packages.debian.org/es/sid/amd64/openjdk-23-demo >>> https://packages.fedoraproject.org/pkgs/java-25-openjdk/java-25-openjdk-demo/index.html >>> >>> >>> El 12/6/25 a las 20:49, Philip Race escribi?: >>>> >>>> I just submitted https://bugs.openjdk.org/browse/JDK-8359381 >>>> ----- >>>> There are netbeans projects for the client demos. >>>> >>>> % ls src/demo/share/nbproject >>>> README.txt jfc project.xml >>>> % ls src/demo/share/nbproject/jfc >>>> FileChooserDemo Notepad TransparentRuler >>>> Font2DTest SampleTree >>>> Metalworks TableExample >>>> ----- >>>> >>>> The question, as posed in the subject line, is do we really need to >>>> keep these? >>>> I'd like to delete them if there's no one who is interested and >>>> willing to maintain them >>>> >>>> -phil. >>> >>> >> > From honkar at openjdk.org Fri Jun 13 19:21:42 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 13 Jun 2025 19:21:42 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile In-Reply-To: <5ERPBtcxhHw0lkJNSelnAAIHk3kOLM1rDvA_Y7PJZCA=.2a224780-a5e6-4722-b26e-bf1c311adbc1@github.com> References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> <5ERPBtcxhHw0lkJNSelnAAIHk3kOLM1rDvA_Y7PJZCA=.2a224780-a5e6-4722-b26e-bf1c311adbc1@github.com> Message-ID: On Thu, 12 Jun 2025 18:07:53 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 802: >> >>> 800: public static ICC_Profile getInstance(byte[] data) { >>> 801: ProfileDataVerifier.verify(data); >>> 802: verifyHeader(data); >> >> [verifyHeader(byte[] data)](https://github.com/openjdk/jdk/blob/3b32f6a8ec37338764d3e6713247ff96e49bf5b3/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java#L1176C2-L1184C6), expects header byte array and not the entire profile array, is it technically correct to send the entire profile byte array? >> >> Please note verifyHeader() is called from two places from `getInstance(byte[] data)` and `setData(int tagSignature, byte[] tagData)`, >> >> With the current fix, logically all the checks within verifyHeader() work (getProfileClass(data), getColorSpaceType(data) ...) because the data is extracted at specified index from the superset - entire profile byte array instead of the header byte array. >> >> If it is decided to send only header byte array to `verifyHeader() ` then changing the method param name to **header** instead of **data** may be clearer. >> >> >> private static void verifyHeader(byte[] header) { >> if (header == null || header.length < HEADER_SIZE) { >> throw new IllegalArgumentException("Invalid header data"); >> } >> getProfileClass(header); >> getColorSpaceType(header); >> getPCSType(header); >> checkRenderingIntent(header); >> } > >> [verifyHeader(byte[] data)](https://github.com/openjdk/jdk/blob/3b32f6a8ec37338764d3e6713247ff96e49bf5b3/src/java.desktop/share/classes/java/awt/color/ICC_Profile.java#L1176C2-L1184C6), expects header byte array and not the entire profile array, is it technically correct to send the entire profile byte array? > > Validating the header directly without cloning is fine and actually better. The old code effectively skipped the "header.length < HEADER_SIZE" check because it always created a "new byte[HEADER_SIZE]". I see your point. I do think renaming the param name for the following checks to something more generic such as `data` or `profileData` instead of header will cause less confusion then. private static void checkRenderingIntent(**byte[] header**) private static int getColorSpaceType(**byte[] theHeader**) private static int getProfileClass(**byte[] theHeader**) private static int getPCSType(**byte[] theHeader**) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2145917397 From prr at openjdk.org Fri Jun 13 19:29:44 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 13 Jun 2025 19:29:44 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: <5pD0bFEqR2qiBSXsKWL8cyEL1WR9crFRE1lMejNsb8g=.bb1c734c-50d1-42c9-8539-2d102c62a9fb@github.com> References: <5pD0bFEqR2qiBSXsKWL8cyEL1WR9crFRE1lMejNsb8g=.bb1c734c-50d1-42c9-8539-2d102c62a9fb@github.com> Message-ID: On Thu, 12 Jun 2025 22:54:02 GMT, Sergey Bylokhov wrote: > I would like to confirm that we treat ThreadGroup based sandboxing as equivalent to AppContext based sandboxing. There are a few places where we still use ThreadGroup instead of AppContext, and I believe we can drop that usage at the same time AppContext is removed, even if the specification includes statements like "Each {@code ThreadGroup} will receive its own instance." - correct? I *think* that is true. The word/name AppContext probably should never be in API doc and saying ThreadGroup is a decent substitute, but wherever we did either of these for the sake of applet partitioning they can probably all go away. I hope spec. appearances are rare. Eliminating AppContext is going to be a good size piece by piece project even without that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2145928751 From prr at openjdk.org Fri Jun 13 20:02:43 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 13 Jun 2025 20:02:43 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v6] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 23:08:38 GMT, Sergey Bylokhov wrote: >> After the applet removal, this could be dead code. It might be better not to mention JInternalFrame unless we have prove that the code actually works for it, add a TODO? or something? > > it could be related to appletviewer Unlikely. JInternalFrame is a RootPaneContainer and validate root. It has a set size and stuff resized within it do NOT make the containing Container revalidate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2145955172 From prr at openjdk.org Fri Jun 13 20:02:43 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 13 Jun 2025 20:02:43 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com> References: <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com> Message-ID: On Thu, 12 Jun 2025 23:00:19 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 73: > >> 71: >> 72: private static void checkThread(File file) throws Exception { >> 73: SoundClip clip = SoundClip.createSoundClip(file); > > I think we should either support content handlers via the new SoundClip object or remove the existing implementation, as it is currently tied to AudioClip. was this comment meant to be on some other (test) code ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146001842 From serb at openjdk.org Fri Jun 13 20:20:33 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 13 Jun 2025 20:20:33 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com> Message-ID: On Fri, 13 Jun 2025 19:59:36 GMT, Phil Race wrote: >> test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 73: >> >>> 71: >>> 72: private static void checkThread(File file) throws Exception { >>> 73: SoundClip clip = SoundClip.createSoundClip(file); >> >> I think we should either support content handlers via the new SoundClip object or remove the existing implementation, as it is currently tied to AudioClip. > > was this comment meant to be on some other (test) code ? It is about content handlers we discussed above and its implementation in awt/www/content/audio/. If we want to support content handlers then it is not necessary to change this in the test: >SoundClip clip = (SoundClip) file.toURL().getContent(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146024244 From serb at openjdk.org Fri Jun 13 20:24:49 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 13 Jun 2025 20:24:49 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile [v2] In-Reply-To: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: > This PR simplifies several aspects of the ICC_Profile class: > > - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30): > The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377). > > - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe): > In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation. > > - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c): > After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code. > > @prrace @honkar-jdk please take a look Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: theHeader -> data ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25650/files - new: https://git.openjdk.org/jdk/pull/25650/files/450f35e9..97d01fc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25650&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25650&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25650.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25650/head:pull/25650 PR: https://git.openjdk.org/jdk/pull/25650 From prr at openjdk.org Fri Jun 13 21:14:39 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 13 Jun 2025 21:14:39 GMT Subject: RFR: 8055461: getNextID in ImageIcon class can lead to overflow [v2] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 15:04:21 GMT, Prasanta Sadhukhan wrote: >> ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. >> >> Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" >> >> Made sure there is no overflow and treat that loadImage as ABORTED >> >> No regression testcase as it addresses theoretical possibility.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reset mediaTrackerID if it overflows Interesting that the MediaTracker is managed via an AppContext, but the id a static field. Ah I see that there was a static field MediaTracker too, but it was deprecated in 1.8 and no longer used. Probably being a protected field in a non-final class was the bigger issue there. I don't see using a long as helping because aside from being able to still wrap around you need an int to pass to MediaTracker and that isn't going to change. New API and a ton of work would be needed to not fundamentally fix the issue. I don't see a problem with a negative ID. MediaTracker doesn't require a positive value. So the overflow doesn't matter. The only issue is if one particular loadImage stalls and we cycle through and would re-use the ID. restricting it to >=0 on its own just makes that problem more likely as you only have half the values. I think that stalling is an unlikely problem. But if it does happen then a new MediaTracker when we hit overflow would be a solution. However then you need to manage a map of MediaTrackers .. it seems like a lot to do upfront. I would just close this as will not fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25666#issuecomment-2971696281 From prr at openjdk.org Fri Jun 13 21:53:33 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 13 Jun 2025 21:53:33 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: Message-ID: On Thu, 12 Jun 2025 22:48:14 GMT, Sergey Bylokhov wrote: >> I looked into this when I was doing SoundClip. >> What is actually returned by contract is a ContentHandler which returns an Object from its getContent() method >> That Object happens to be a com.sun.media.sound.JavaSoundAudioClip which previously implemented AudioClip >> >> This implements relationship isn't there for SoundClip, so the expectation of the test that it knows of an exported type that will actually be returned is no longer valid. >> >> I don't think it is worth testing that JavaSoundAudioClip is returned. >> >> Possibly we could jsut verify that a non-null handler is returned ? > > As far as I understand, this method should return something that the application can actually use. Previously, the application could access the audio data via the AudioClip interface - it wasn?t important that it was specifically implemented by JavaSoundAudioClip. Now, I believe we should return a SoundClip object, which can be created (not necessarily via the public API of the SoundClip/JavaSoundAudioClip classes). I have no idea how applications (or applets) could really have used this URL.getContent() API that just returns an Object. It seems like it was meant to be used by some other part of the larger JDK that was aware of how this was implemented. I am inclined to ask the networking API owners what the purpose and future should be. I also don't particularly like the java.base module (even via this private SPI) calling into the desktop module. When the desktop module isn't present in a jlinked image it will not find a handler and have to do some default thing such as return raw bytes or null. So I can probably return a SoundClip but any code out there that used this was always taking a chance. OTOH we are removing Applet entirely so anyone who was relying on this is out of luck anyway. >> was this comment meant to be on some other (test) code ? > > It is about content handlers we discussed above and its implementation in awt/www/content/audio/. If we want to support content handlers then it is not necessary to change this in the test: >>SoundClip clip = (SoundClip) file.toURL().getContent(); Not sure I would do that anyway here. It seems like an unnecessary file->url->file roundtrip with a cast to a type you have to "know". And it was never specified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146175203 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146141458 From psadhukhan at openjdk.org Sat Jun 14 11:10:45 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Sat, 14 Jun 2025 11:10:45 GMT Subject: Withdrawn: 8055461: getNextID in ImageIcon class can lead to overflow In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 03:29:47 GMT, Prasanta Sadhukhan wrote: > ImageIcon.getNextID uses `mediaTrackerID ` which do not detect overflow. > > Theoretically there is a possibility that there can be overflow in the long time run or for large number of created "imageIcon" > > Made sure there is no overflow and treat that loadImage as ABORTED > > No regression testcase as it addresses theoretical possibility.. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25666 From duke at openjdk.org Sun Jun 15 21:53:36 2025 From: duke at openjdk.org (ExE Boss) Date: Sun, 15 Jun 2025 21:53:36 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v3] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 10:02:21 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Update image instance before returning src/java.desktop/share/classes/javax/swing/ImageIcon.java line 371: > 369: * Sets the image displayed by this icon. > 370: * A null image is ignored. > 371: * @param image the image The?`image` can?be?set to?`null` to?mean ?no?image?: Suggestion: * Sets the image displayed by this icon. * @param image the image, may be null ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2148836518 From psadhukhan at openjdk.org Mon Jun 16 02:17:34 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 02:17:34 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v3] In-Reply-To: References: Message-ID: On Sun, 15 Jun 2025 21:50:09 GMT, ExE Boss wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Update image instance before returning > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 371: > >> 369: * Sets the image displayed by this icon. >> 370: * A null image is ignored. >> 371: * @param image the image > > The?`image` can?be?set to?`null` to?mean ?no?image?: > Suggestion: > > * Sets the image displayed by this icon. > * @param image the image, may be null I dont think so..Till now, it was throwing NPE so it was not expected so it cannot be "may be null", which is we are telling the application to avoid.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2148934817 From psadhukhan at openjdk.org Mon Jun 16 05:24:23 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 05:24:23 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v4] In-Reply-To: References: Message-ID: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/43d43c63..d082a35a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From tr at openjdk.org Mon Jun 16 05:30:35 2025 From: tr at openjdk.org (Tejesh R) Date: Mon, 16 Jun 2025 05:30:35 GMT Subject: Integrated: 8358532: JFileChooser in GTK L&F still displays HTML filename In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 04:41:54 GMT, Tejesh R wrote: > [JDK-8139228](https://bugs.openjdk.org/browse/JDK-8139228) fix missed GTK updates for the same issue where file/directory name renders as `HTML text` instead of `plain text`. > Adding the same fix for GTK L&F. > Test for the fix : test/jdk/javax/swing/JFileChooser/HTMLFileName.java This pull request has now been integrated. Changeset: 6fe9143b Author: Tejesh R URL: https://git.openjdk.org/jdk/commit/6fe9143bbbe269af62d2084834fc0c9afc51b5f3 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod 8358532: JFileChooser in GTK L&F still displays HTML filename Reviewed-by: aivanov, dnguyen, kizune ------------- PR: https://git.openjdk.org/jdk/pull/25707 From psadhukhan at openjdk.org Mon Jun 16 09:34:39 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 09:34:39 GMT Subject: RFR: 8359428: Test 'javax/swing/JTabbedPane/bug4499556.java' failed because after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again Message-ID: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> It is seen that this test (which was opensourced in [JDK-8353304](https://bugs.openjdk.org/browse/JDK-8353304)) when run with NimbusLookAndFeel, after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again. It is because while switching to another L&F say platform(WindowsL&F) from Metal/Nimbus LookAndFeel, if testcase was originally run in Nimbus L&F, `SynthMenuItemLayoutHelper()` calls `MenuItemLayoutHelper.reset` where `style.getFont(context) `return null font so when it calls `getFontMetrics(font)` it calls `font.hashCode `which fails with > Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null This is happening because the test calls `SwingUtilities.updateComponentTreeUI `on tabbedpane. So, when L&F is changed inside the test via "L&F Menu" option 1st time say Metal to Platform, it changes the L&F of the tabbed pane to Windows L&F, but not for the "L&F Menu" font itself which is still in Nimbus L&F, but style context is reset so when next time "L&F Menu" is clicked to change the L&F, SynthMenuItemLayoutHelper gets null font from invalid context and then it crashes. Fix is to ensure the `updateComponentTreeUI `should be for entire frame which consists of "L&F Menu" and the tabs so L&F is changed consistently for all nodes. ------------- Commit messages: - 8359428: Test 'javax/swing/JTabbedPane/bug4499556.java' failed because after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again Changes: https://git.openjdk.org/jdk/pull/25822/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25822&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359428 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25822/head:pull/25822 PR: https://git.openjdk.org/jdk/pull/25822 From aivanov at openjdk.org Mon Jun 16 14:50:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 14:50:30 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v4] In-Reply-To: References: Message-ID: <1APXsscjt3n2TrN8XZhXyLuKJVyClyirFfGRtzS4Kqc=.cfe8c41c-d9b3-4603-af48-efe3079d1745@github.com> On Mon, 16 Jun 2025 05:24:23 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > javadoc The `ImageIcon` constructor that accepts `Image` has the same problem, or a similar problem. https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L224-L226 It throws `NullPointerException` if a `null` parameter is passed. Other constructors handle `null` values, so you should unify handling of `null` images. test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 40: > 38: ImageIcon icon = new ImageIcon(); > 39: icon.setImage(null); > 40: }); `invokeAndWait` isn't needed here, you can run the test code on the main thread. A comment that no NPE is expected would be good to clarify what the test expects. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2932316002 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150117727 From psadhukhan at openjdk.org Mon Jun 16 14:59:13 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 14:59:13 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v5] In-Reply-To: References: Message-ID: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix for constructor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/d082a35a..5d32ca5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=03-04 Stats: 8 lines in 2 files changed: 3 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From psadhukhan at openjdk.org Mon Jun 16 14:59:13 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 14:59:13 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v4] In-Reply-To: <1APXsscjt3n2TrN8XZhXyLuKJVyClyirFfGRtzS4Kqc=.cfe8c41c-d9b3-4603-af48-efe3079d1745@github.com> References: <1APXsscjt3n2TrN8XZhXyLuKJVyClyirFfGRtzS4Kqc=.cfe8c41c-d9b3-4603-af48-efe3079d1745@github.com> Message-ID: On Mon, 16 Jun 2025 14:14:05 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc > > test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 40: > >> 38: ImageIcon icon = new ImageIcon(); >> 39: icon.setImage(null); >> 40: }); > > `invokeAndWait` isn't needed here, you can run the test code on the main thread. > > A comment that no NPE is expected would be good to clarify what the test expects. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150226985 From aivanov at openjdk.org Mon Jun 16 15:01:56 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 15:01:56 GMT Subject: RFR: 8357686: Remove unnecessary Map.get from AWTAutoShutdown.unregisterPeer In-Reply-To: References: Message-ID: <1XvArvPzZQzZHwGPiCleNj7sABDh3gVZKk41PcgyFWg=.c2e9294b-47b0-4ca5-85dd-7786c904cae4@github.com> On Thu, 24 Apr 2025 20:18:01 GMT, Andrey Turbanov wrote: > Instead of separate `.get(Key)`+`.remove(Key)` calls we can call `.remove(Key, Value)`. > `peerMap` is an `IdentityHashMap`. IdentityHashMap.remove compares values with == since Java 20 ([JDK-8178355](https://bugs.openjdk.org/browse/JDK-8178355)) Looks fine. The code now depends on the fact that `peerMap` is an `IdentityHashMap` which may be not such a good thing. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24858#pullrequestreview-2932501820 From aivanov at openjdk.org Mon Jun 16 15:08:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 15:08:31 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 14:59:13 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix for constructor Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/ImageIcon.java line 224: > 222: * @see java.awt.Image#getProperty > 223: */ > 224: public ImageIcon (Image image) { Does it make sense to expand the javadoc for all the constructors to specify how `null` is handled? src/java.desktop/share/classes/javax/swing/ImageIcon.java line 380: > 378: if (image == null) { > 379: return; > 380: } Should `setImage` clear / update the description automatically? test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 40: > 38: // Setting null image shouldn't cause NPE > 39: icon.setImage(null); > 40: } Add the test for `new ImageIcon((Image) null)`: currently it throws `NullPointerException` but it won't throw it after your fix. ------------- PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2932514833 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150241193 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150249349 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150245194 From psadhukhan at openjdk.org Mon Jun 16 15:24:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 15:24:47 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v6] In-Reply-To: References: Message-ID: <53NJkbPwZ-WoAkUJhW3JIvuuBEZh5v1wb-ZIOpgJb6A=.d3ee7fc1-27f9-4232-90e2-ab12e8308507@github.com> > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/5d32ca5d..fb4a0e2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=04-05 Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From psadhukhan at openjdk.org Mon Jun 16 15:24:48 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 15:24:48 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 15:01:37 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix for constructor > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 224: > >> 222: * @see java.awt.Image#getProperty >> 223: */ >> 224: public ImageIcon (Image image) { > > Does it make sense to expand the javadoc for all the constructors to specify how `null` is handled? I have expanded for those methods where there is code change for NULL interception....Not sure about others.. > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 380: > >> 378: if (image == null) { >> 379: return; >> 380: } > > Should `setImage` clear / update the description automatically? > > It's up for discussion? What do you think? Update the description from where? Its not overridden method.. > test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 40: > >> 38: // Setting null image shouldn't cause NPE >> 39: icon.setImage(null); >> 40: } > > Add the test for `new ImageIcon((Image) null)`: currently it throws `NullPointerException` but it won't throw it after your fix. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150276928 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150282841 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150277162 From aivanov at openjdk.org Mon Jun 16 15:24:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 15:24:48 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 14:59:13 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix for constructor src/java.desktop/share/classes/javax/swing/ImageIcon.java line 373: > 371: /** > 372: * Sets the image displayed by this icon. > 373: * Setting null image will not render any image icon. Suggestion: * Setting a {@code null} image will not render any image icon. Will it sound clearer if the text stated, _?Setting a `{@code null}` image will remove the icon??_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150283021 From aivanov at openjdk.org Mon Jun 16 15:29:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 15:29:30 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 15:21:27 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 380: >> >>> 378: if (image == null) { >>> 379: return; >>> 380: } >> >> Should `setImage` clear / update the description automatically? >> >> It's up for discussion? What do you think? > > Update the description from where? Its not overridden method.. Set it to `null` if the image is `null` or load it from the `"comment"` property as the constructor does. However, it's safer to leave it untouched. After all, constructors are used to initialise the fields of the object so it makes sense to try to set a description whereas changing the icon doesn't necessarily mean the description needs to change; if it does, call `setDescription` explicitly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150290867 From aivanov at openjdk.org Mon Jun 16 15:29:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 15:29:32 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v6] In-Reply-To: <53NJkbPwZ-WoAkUJhW3JIvuuBEZh5v1wb-ZIOpgJb6A=.d3ee7fc1-27f9-4232-90e2-ab12e8308507@github.com> References: <53NJkbPwZ-WoAkUJhW3JIvuuBEZh5v1wb-ZIOpgJb6A=.d3ee7fc1-27f9-4232-90e2-ab12e8308507@github.com> Message-ID: On Mon, 16 Jun 2025 15:24:47 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 38: > 36: public static void main(String[] args) throws Exception { > 37: testImageIconNULL(); > 38: testSetImageNULL(); I particularly don't like the upper-case for `null`, in my opinion, `-Null` is better and aligns with Java naming conventions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2150294198 From psadhukhan at openjdk.org Mon Jun 16 15:40:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 15:40:50 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v7] In-Reply-To: References: Message-ID: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: javadoc, testmethod ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/fb4a0e2d..2114de9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=05-06 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From psadhukhan at openjdk.org Mon Jun 16 15:43:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Jun 2025 15:43:47 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v8] In-Reply-To: References: Message-ID: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/2114de9c..6f6320ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From yzheng at openjdk.org Mon Jun 16 16:13:31 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Mon, 16 Jun 2025 16:13:31 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v8] In-Reply-To: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> References: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> Message-ID: On Mon, 16 Jun 2025 15:43:47 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix Since the base is before the branch off, could you please merge master before integration and see if GHA still passes? This also helps us testing libgraal compilation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2977233053 From aivanov at openjdk.org Mon Jun 16 16:51:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 16:51:30 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v8] In-Reply-To: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> References: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> Message-ID: On Mon, 16 Jun 2025 15:43:47 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix Looks good to me. I still have doubts about the description of how `null` is handled? ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2932834393 From duke at openjdk.org Mon Jun 16 18:15:30 2025 From: duke at openjdk.org (lawrence.andrews) Date: Mon, 16 Jun 2025 18:15:30 GMT Subject: RFR: 8359428: Test 'javax/swing/JTabbedPane/bug4499556.java' failed because after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again In-Reply-To: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> References: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> Message-ID: On Mon, 16 Jun 2025 09:21:24 GMT, Prasanta Sadhukhan wrote: > It is seen that this test (which was opensourced in [JDK-8353304](https://bugs.openjdk.org/browse/JDK-8353304)) when run with NimbusLookAndFeel, after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again. > It is because while switching to another L&F say platform(WindowsL&F) from Metal/Nimbus LookAndFeel, if testcase was originally run in Nimbus L&F, `SynthMenuItemLayoutHelper()` calls `MenuItemLayoutHelper.reset` where `style.getFont(context) `return null font so when it calls `getFontMetrics(font)` it calls `font.hashCode `which fails with > >> Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null > > This is happening because the test calls `SwingUtilities.updateComponentTreeUI `on tabbedpane. > So, when L&F is changed inside the test via "L&F Menu" option 1st time say Metal to Platform, it changes the L&F of the tabbed pane to Windows L&F, but not for the "L&F Menu" font itself which is still in Nimbus L&F, but style context is reset so when next time "L&F Menu" is clicked to change the L&F, SynthMenuItemLayoutHelper gets null font from invalid context and then it crashes. > Fix is to ensure the `updateComponentTreeUI `should be for entire frame which consists of "L&F Menu" and the tabs so L&F is changed consistently for all nodes. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/25822#issuecomment-2977567753 From aivanov at openjdk.org Mon Jun 16 20:43:20 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 20:43:20 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v4] In-Reply-To: References: Message-ID: > The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. > > The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. > > The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. > > The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. > > I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). > > In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. > > > In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Add note for macOS and Aqua L&F - Merge master - Align the title of frame with JFileChooser to htmlDisabled flag - Use Serif font instead of Comic Sans MS - Rename createFileChooser parameter htmlEnabled -> htmlDisabled - Correct the title of the test frames - Improve instructions for HTMLFileName.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25455/files - new: https://git.openjdk.org/jdk/pull/25455/files/fe63e02e..56f557f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25455&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25455&range=02-03 Stats: 102416 lines in 1730 files changed: 64757 ins; 24017 del; 13642 mod Patch: https://git.openjdk.org/jdk/pull/25455.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25455/head:pull/25455 PR: https://git.openjdk.org/jdk/pull/25455 From aivanov at openjdk.org Mon Jun 16 20:43:22 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 16 Jun 2025 20:43:22 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 21:27:22 GMT, Harshitha Onkar wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct the title of the test frames > > test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 81: > >> 79: in the navigation combo box above is displayed >> 80: as HTML, then press Pass.
      >> 81: If it is in plain text, then press Fail. > > According to test instructions it states that the file name in the **file pane** and navigation combo box must be displayed as HTML. When I'm testing with system (Aqua) LaF on macOS the file name in file pane appears blank (with the original as well as updated test). > > HTML_Enabled @honkar-jdk I added a note about macOS and Aqua L&F to the instructions. I thought it was a problem in `JTable`, but putting this HTML code in SwingSet2 into a table cell renders HTML. I guess I should submit a low priority bug to investigate why HTML displays as an empty file name in `JFileChooser` in Aqua Look-and-Feel. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2150837839 From honkar at openjdk.org Mon Jun 16 21:12:34 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 16 Jun 2025 21:12:34 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v4] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 20:43:20 GMT, Alexey Ivanov wrote: >> The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. >> >> The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. >> >> The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. >> >> The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. >> >> I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). >> >> In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. >> >> >> In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. > > Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Add note for macOS and Aqua L&F > - Merge master > - Align the title of frame with JFileChooser to htmlDisabled flag > - Use Serif font instead of Comic Sans MS > - Rename createFileChooser parameter htmlEnabled -> htmlDisabled > - Correct the title of the test frames > - Improve instructions for HTMLFileName.java Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25455#pullrequestreview-2933528325 From honkar at openjdk.org Mon Jun 16 21:12:35 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 16 Jun 2025 21:12:35 GMT Subject: RFR: 8357799: Improve instructions for JFileChooser/HTMLFileName.java [v2] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 20:40:07 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JFileChooser/HTMLFileName.java line 81: >> >>> 79: in the navigation combo box above is displayed >>> 80: as HTML, then press Pass.
      >>> 81: If it is in plain text, then press Fail. >> >> According to test instructions it states that the file name in the **file pane** and navigation combo box must be displayed as HTML. When I'm testing with system (Aqua) LaF on macOS the file name in file pane appears blank (with the original as well as updated test). >> >> HTML_Enabled > > @honkar-jdk I added a note about macOS and Aqua L&F to the instructions. > > I thought it was a problem in `JTable`, but putting this HTML code in SwingSet2 into a table cell renders HTML. > > I guess I should submit a low priority bug to investigate why HTML displays as an empty file name in `JFileChooser` in Aqua Look-and-Feel. Instructions sounds clearer now. LGTM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25455#discussion_r2150894205 From honkar at openjdk.org Mon Jun 16 21:54:30 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 16 Jun 2025 21:54:30 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Fri, 13 Jun 2025 17:11:17 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Rearrange and update test. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 53: > 51: }); > 52: countDownLatch.await(); > 53: System.out.println("Test Passed"); @DamonGuy Test continues to run if the user does not click on Pass/Fail buttons. It can be avoided by adding a timeout for the countdown latch as below and calling disposeFrames() in finally block. Suggestion: countDownLatch = new CountDownLatch(1); try { EventQueue.invokeAndWait(() -> { createTestFrame(); createInstructionsFrame(); }); if (!countDownLatch.await(2, TimeUnit.MINUTES)) { throw new RuntimeException("Test timeout : No action was" + " taken on the test."); } System.out.println("Test passed."); } finally { EventQueue.invokeAndWait(ListDragCursor::disposeFrames); } test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 113: > 111: disposeFrames(); > 112: throw new RuntimeException("Test Failed"); > 113: }); With the test timeout changes the following lines requires an update Suggestion: passBtn.addActionListener(e -> { countDownLatch.countDown(); }); failBtn.addActionListener(e -> { throw new RuntimeException("Test Failed"); }); test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 125: > 123: > 124: static void disposeFrames() { > 125: countDownLatch.countDown(); countDownLatch.countDown(); needs to be removed from disposeFrames(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2150945523 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2150947869 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2150948842 From philip.race at oracle.com Mon Jun 16 22:46:29 2025 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Jun 2025 15:46:29 -0700 Subject: Backport Candidate: JDK-8332271/ JDK-8353950 (PR #24614) In-Reply-To: <02ee74ad3e2ed92b3c481670e78c37db42e4ad39.camel@doppel-helix.eu> References: <67dd91bc-6216-4abc-8ce7-dc68cb0891c8@oracle.com> <02ee74ad3e2ed92b3c481670e78c37db42e4ad39.camel@doppel-helix.eu> Message-ID: I've looked at the code and I think overall it is an improvement in a few ways such as fewer calls to open/close and getting the formats not requiring that. I didn't spot anything that looks suspicious and we've been running it in CI since it was pushed, and given that it fixes crashes (etc) it seems like a reasonable RDP 1 fix. -phil. On 6/11/25 8:59 AM, Matthias Bl?sing wrote: > Hi, > > Am Dienstag, dem 10.06.2025 um 21:43 -0700 schrieb Philip Race: >> It seems to me like a candidate based on being a recent 'regression' and >> the use case and potential impact. >> I just have not looked at or tested the code myself, and clipboard tests >> are at least in some part manual, >> so I don't know how well it has been tested. >> >> Did anyone run at least the automated jtreg tests for you on our CI system ? > to my knowledge this was not yet done. > > I ran the jtreg tests from `test/jdk/java/awt/Clipboard` locally > including the new crash reproducer. In addition I used the application > level reproducer to verify that the issue also covers that. That test > copy-and-pastes text between NetBeans and notepad in a loop, while > adding the loop index on each invocation. That looked sane for 20-100 > iterations. > >> On 6/10/25 12:54 PM, Matthias Bl?sing wrote: >>> [Backport proposal https://github.com/openjdk/jdk/pull/24614] >>> >>> JDK-8332271: Reading data from the clipboard from multiple threads crashes the JVM (P3) >>> JDK-8353950: Clipboard interaction on Windows is unstable (P4) > Thanks for considering > > Matthias From abaya at openjdk.org Mon Jun 16 23:57:09 2025 From: abaya at openjdk.org (Anass Baya) Date: Mon, 16 Jun 2025 23:57:09 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v8] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: Enhance the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/577ba84a..9103d253 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=06-07 Stats: 32 lines in 1 file changed: 19 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From abaya at openjdk.org Tue Jun 17 00:05:29 2025 From: abaya at openjdk.org (Anass Baya) Date: Tue, 17 Jun 2025 00:05:29 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 02:59:15 GMT, Sergey Bylokhov wrote: >> I cant reproduce it locally. >> I can see it only on CI 20/20 with the new test and 2/20 with the old one > > what is the stack trace when the new test fails? Hello @mrserb, I've enhanced the new test. It now reproduces the issue consistently (5/5) locally, but only intermittently (6/20) on CI ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2151084326 From psadhukhan at openjdk.org Tue Jun 17 02:49:31 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 17 Jun 2025 02:49:31 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 15:21:33 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix for constructor > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 373: > >> 371: /** >> 372: * Sets the image displayed by this icon. >> 373: * Setting null image will not render any image icon. > > Suggestion: > > * Setting a {@code null} image will not render any image icon. > > > Will it sound clearer if the text stated, _?Setting a `{@code null}` image will remove the icon??_ I didnt use "remove the icon" as there are 2 possibilities. - Already there is existing ImageIcon with image set so if now ImageIcon.setImage(null) is called, it will remove the existing icon and thereafter will not render any image icon - If there is no ImageIcon set, calling ImageIcon.setImage(null) will not render any image icon so no question of removing the icon so in both possibilities, there is no imageicon rendered for null image so I chose that phrase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2151212528 From serb at openjdk.org Tue Jun 17 03:21:34 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 17 Jun 2025 03:21:34 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v8] In-Reply-To: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> References: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> Message-ID: On Mon, 16 Jun 2025 15:43:47 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2934017848 From serb at openjdk.org Tue Jun 17 03:35:39 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 17 Jun 2025 03:35:39 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v8] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 21:51:05 GMT, Phil Race wrote: > I am inclined to ask the networking API owners what the purpose and future should be. Yeah, that will be useful to know the future of this api, we have similar handlers for images. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2151250650 From smandalika at openjdk.org Tue Jun 17 05:01:07 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 17 Jun 2025 05:01:07 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java Message-ID: Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. ------------- Commit messages: - 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java Changes: https://git.openjdk.org/jdk/pull/25842/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359687 Stats: 59 lines in 1 file changed: 20 ins; 10 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From abhiscxk at openjdk.org Tue Jun 17 05:47:34 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 17 Jun 2025 05:47:34 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v8] In-Reply-To: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> References: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> Message-ID: <_LcbYR0Gc_IcIMByis8AsA_nFmBAnM3eLyf5um4cYsY=.da166617-fea0-4e60-8508-879ccb75daa6@github.com> On Mon, 16 Jun 2025 15:43:47 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 27: > 25: * @test > 26: * @bug 8159055 > 27: * @summary Verifies ImageIcon.setImage handles null parameter Does it need to modify the summary as well ? Apart from setImage method, null parameter is handled in constructor also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2151368759 From abhiscxk at openjdk.org Tue Jun 17 05:57:35 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 17 Jun 2025 05:57:35 GMT Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v2] In-Reply-To: References: <-YjizBKwzuk78Ywdge0SzTQVssPlueHwO5lSGtHrNM0=.f6e92605-830c-49d7-9a29-f0506f04d4b4@github.com> Message-ID: On Fri, 13 Jun 2025 03:42:15 GMT, Prasanta Sadhukhan wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> javadoc > > Raised CSR https://bugs.openjdk.org/browse/JDK-8359398 > @azuev-java @kumarabhi006 Please review. @prsadhuk I think JBS title should be modified to not to be specific to `setImage` method only and then CSR should be updated as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2979038358 From smandalika at openjdk.org Tue Jun 17 09:09:42 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Tue, 17 Jun 2025 09:09:42 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Added SkippedException when Printer is unavailable. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/f61631f0..223c0e11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From psadhukhan at openjdk.org Tue Jun 17 10:08:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 17 Jun 2025 10:08:49 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v9] In-Reply-To: References: Message-ID: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: SUmmary fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/6f6320ac..8e1938b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From psadhukhan at openjdk.org Tue Jun 17 10:08:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 17 Jun 2025 10:08:49 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v8] In-Reply-To: <_LcbYR0Gc_IcIMByis8AsA_nFmBAnM3eLyf5um4cYsY=.da166617-fea0-4e60-8508-879ccb75daa6@github.com> References: <_zkXY48dez_LYuNyoqtduJAN9QYxXsEQl8hydypn8bA=.7584c056-3086-4f2c-87c1-db6d1c65336d@github.com> <_LcbYR0Gc_IcIMByis8AsA_nFmBAnM3eLyf5um4cYsY=.da166617-fea0-4e60-8508-879ccb75daa6@github.com> Message-ID: <0zJWE50JtWHpFOjDCG_yd8p_Akw-vzJYEQAE1crSJpY=.5c83e42a-b343-4a91-aa74-1efdccfd2493@github.com> On Tue, 17 Jun 2025 05:44:09 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix > > test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 27: > >> 25: * @test >> 26: * @bug 8159055 >> 27: * @summary Verifies ImageIcon.setImage handles null parameter > > Does it need to modify the summary as well ? > > Apart from setImage method, null parameter is handled in constructor also. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2151869489 From abhiscxk at openjdk.org Tue Jun 17 12:25:29 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 17 Jun 2025 12:25:29 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 10:08:49 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > SUmmary fix Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2935437506 From psadhukhan at openjdk.org Tue Jun 17 12:48:05 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 17 Jun 2025 12:48:05 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording Message-ID: BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". ------------- Commit messages: - 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording Changes: https://git.openjdk.org/jdk/pull/25850/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25850&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6955128 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25850/head:pull/25850 PR: https://git.openjdk.org/jdk/pull/25850 From psadhukhan at openjdk.org Tue Jun 17 13:02:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 17 Jun 2025 13:02:41 GMT Subject: RFR: 6798061: The removal of System.out.println from KeyboardManager Message-ID: Internal debugging code is removed. ------------- Commit messages: - 6798061: The removal of System.out.println from KeyboardManager Changes: https://git.openjdk.org/jdk/pull/25851/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25851&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6798061 Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25851.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25851/head:pull/25851 PR: https://git.openjdk.org/jdk/pull/25851 From aivanov at openjdk.org Tue Jun 17 14:12:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 17 Jun 2025 14:12:38 GMT Subject: Integrated: 8357799: Improve instructions for JFileChooser/HTMLFileName.java In-Reply-To: References: Message-ID: On Mon, 26 May 2025 17:00:15 GMT, Alexey Ivanov wrote: > The instructions for the `javax/swing/JFileChooser/HTMLFileName.java` test are still not as clear. > > The file name in the instructions is rendered as HTML, which, I believe, is unexpected. It should be displayed as the plain text. > > The instructions also say about file and directory which have HTML in their name; this was true in the initial version of the test in #24439 that created files and directories on the real file system. > > The final version of test uses a virtual file system that displays *three files*, there's no way to navigate. > > I also clarified the instructions: look at how the file name of the first file is rendered in _the file pane_ and _the navigation combo box_ (**Look in** in Metal L&F). > > In the `VirtualFileSystemView` class, I changed the name of the third file from `virtualFolder` to `virtualFile2.log`, and made the file array a field which ensures `getRoots` and `getFiles` return the same list. > > > In addition to this, I reduced the number of rows allocated for the instructions. Since the instructions are in HTML format, the number of lines of HTML code makes no sense for determining the size. This pull request has now been integrated. Changeset: 53a83d15 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/53a83d15a1b5686ed0f2aeb3d30cd46b73f80733 Stats: 48 lines in 1 file changed: 19 ins; 10 del; 19 mod 8357799: Improve instructions for JFileChooser/HTMLFileName.java Reviewed-by: honkar, tr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/25455 From aivanov at openjdk.org Tue Jun 17 15:15:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 17 Jun 2025 15:15:36 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Fri, 13 Jun 2025 17:11:17 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Rearrange and update test. Changes requested by aivanov (Reviewer). test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 44: > 42: static Frame testFrame; > 43: static Frame instructionsFrame; > 44: static CountDownLatch countDownLatch; Suggestion: private static final CountDownLatch countDownLatch = new CountDownLatch(1); test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 57: > 55: > 56: static void createTestFrame() { > 57: Frame frame = new Frame("Cursor change after drag"); You didn't assign it to `testFrame`, therefore this frame is never disposed of, and the test doesn't exit cleanly if run without jtreg. In fact, I suggest returning the frame from `createTestFrame` and assigning it to the variable in the `main` method in the lambda expression that calls the method. The same applies to the `createInstructionsFrame` method. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 80: > 78: > 79: static void createInstructionsFrame() { > 80: String instructions = """ I suggest moving the instructions outside of method and placing at the top of the file as static constant. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 91: > 89: left mouse button. Immediately after, the cursor > 90: should change to a Hand cursor. If true, this test > 91: passes. I still see different behaviour on macOS. For me, the cursor remains I-beam over the text area, then it changes to the arrow when the mouse hovers over the scrollbars, and immediately changes to the hand as soon as it enter the list. I observe the same behaviour with `PassFailJFrame` on macOS. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 105: > 103: Panel btnPanel = new Panel(); > 104: Button passBtn = new Button("PASS"); > 105: Button failBtn = new Button("FAIL"); Suggestion: Button passBtn = new Button("Pass"); Button failBtn = new Button("Fail"); There's no reason ?scream?. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 121: > 119: instructionsFrame.pack(); > 120: instructionsFrame.setLocation(300, 100); > 121: instructionsFrame.setVisible(true); I suggest displaying the frame in the centre of the screen instructionsFrame.setLocationRelativeTo(null); and then position the test frame to the right of the instruction frame. This would align to the most common layout of manual tests and would adjust positioning to the size of the current screen. Create the instruction frame first to be able to use its location to position the test frame. ------------- PR Review: https://git.openjdk.org/jdk/pull/25705#pullrequestreview-2935842249 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152379965 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152508702 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152463455 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152524180 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152474594 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152491026 From aivanov at openjdk.org Tue Jun 17 15:15:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 17 Jun 2025 15:15:37 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Mon, 16 Jun 2025 21:43:00 GMT, Harshitha Onkar wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Rearrange and update test. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 53: > >> 51: }); >> 52: countDownLatch.await(); >> 53: System.out.println("Test Passed"); > > @DamonGuy > > Test continues to run if the user does not click on Pass/Fail buttons. It can be avoided by adding a timeout for the countdown latch as below and calling disposeFrames() in finally block. > > Suggestion: > > countDownLatch = new CountDownLatch(1); > try { > EventQueue.invokeAndWait(() -> { > createTestFrame(); > createInstructionsFrame(); > }); > > if (!countDownLatch.await(2, TimeUnit.MINUTES)) { > throw new RuntimeException("Test timeout : No action was" > + " taken on the test."); > } > System.out.println("Test passed."); > } finally { > EventQueue.invokeAndWait(ListDragCursor::disposeFrames); > } I'm for introducing the timeout, thank you! The default timeout could be 5 minutes. > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 125: > >> 123: >> 124: static void disposeFrames() { >> 125: countDownLatch.countDown(); > > countDownLatch.countDown(); needs to be removed from disposeFrames(). ~~Why does it?~~ Got it! Pressing the buttons should just release the latch, then the main method disposes of the frames. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152503540 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152492207 From honkar at openjdk.org Tue Jun 17 16:07:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 16:07:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 17 Jun 2025 15:08:19 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Rearrange and update test. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 91: > >> 89: left mouse button. Immediately after, the cursor >> 90: should change to a Hand cursor. If true, this test >> 91: passes. > > I still see different behaviour on macOS. For me, the cursor remains I-beam over the text area, then it changes to the arrow when the mouse hovers over the scrollbars, and immediately changes to the hand as soon as it enter the list. > > I observe the same behaviour with `PassFailJFrame` on macOS. Correct, hence this test is being problemlisted on macOS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152645061 From aivanov at openjdk.org Tue Jun 17 16:11:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 17 Jun 2025 16:11:31 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 17 Jun 2025 16:04:03 GMT, Harshitha Onkar wrote: > Correct, hence this test is being problemlisted on macOS. I see. I haven't been able to run the test on Windows or Linux today. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152653679 From aivanov at openjdk.org Tue Jun 17 16:14:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 17 Jun 2025 16:14:31 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Fri, 13 Jun 2025 17:11:17 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Rearrange and update test. In fact, I also misinterpreted the scenario. I implied a text is dragged, but in this scenario no drag'n'drop operation happens, just text selection? as mouse is dragged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25705#issuecomment-2980981428 From dnguyen at openjdk.org Tue Jun 17 16:36:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:36:46 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v6] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <0Wz8Gh1zkZqcoS91EOElXExTCkrUW1scIpQ_uhs-6Ss=.8e548a66-f54c-445e-8d0a-52e3e95a5e51@github.com> > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/39efefcc..605f6d97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=04-05 Stats: 62 lines in 1 file changed: 26 ins; 20 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From dnguyen at openjdk.org Tue Jun 17 16:36:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:36:46 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 17 Jun 2025 14:08:44 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Rearrange and update test. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 44: > >> 42: static Frame testFrame; >> 43: static Frame instructionsFrame; >> 44: static CountDownLatch countDownLatch; > > Suggestion: > > private static final CountDownLatch countDownLatch = new CountDownLatch(1); Updated > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 57: > >> 55: >> 56: static void createTestFrame() { >> 57: Frame frame = new Frame("Cursor change after drag"); > > You didn't assign it to `testFrame`, therefore this frame is never disposed of, and the test doesn't exit cleanly if run without jtreg. > > In fact, I suggest returning the frame from `createTestFrame` and assigning it to the variable in the `main` method in the lambda expression that calls the method. The same applies to the `createInstructionsFrame` method. Thanks for catching this! > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 105: > >> 103: Panel btnPanel = new Panel(); >> 104: Button passBtn = new Button("PASS"); >> 105: Button failBtn = new Button("FAIL"); > > Suggestion: > > Button passBtn = new Button("Pass"); > Button failBtn = new Button("Fail"); > > There's no reason ?scream?. Very true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152702112 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152704839 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152703824 From dnguyen at openjdk.org Tue Jun 17 16:36:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:36:46 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 17 Jun 2025 14:59:55 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 53: >> >>> 51: }); >>> 52: countDownLatch.await(); >>> 53: System.out.println("Test Passed"); >> >> @DamonGuy >> >> Test continues to run if the user does not click on Pass/Fail buttons. It can be avoided by adding a timeout for the countdown latch as below and calling disposeFrames() in finally block. >> >> Suggestion: >> >> countDownLatch = new CountDownLatch(1); >> try { >> EventQueue.invokeAndWait(() -> { >> createTestFrame(); >> createInstructionsFrame(); >> }); >> >> if (!countDownLatch.await(2, TimeUnit.MINUTES)) { >> throw new RuntimeException("Test timeout : No action was" >> + " taken on the test."); >> } >> System.out.println("Test passed."); >> } finally { >> EventQueue.invokeAndWait(ListDragCursor::disposeFrames); >> } > > I'm for introducing the timeout, thank you! > > The default timeout could be 5 minutes. Thanks! Implemented. >> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 125: >> >>> 123: >>> 124: static void disposeFrames() { >>> 125: countDownLatch.countDown(); >> >> countDownLatch.countDown(); needs to be removed from disposeFrames(). > > ~~Why does it?~~ > > Got it! Pressing the buttons should just release the latch, then the main method disposes of the frames. Understood. Updated! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152699472 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152703480 From dnguyen at openjdk.org Tue Jun 17 16:36:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:36:46 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <-gV3LfIEAKi7VBxkcuiKuj7RB6c2GRs4_KxRQPoJPsA=.edc64e19-e8f4-40a2-aa70-9fcb6cb63e56@github.com> On Tue, 17 Jun 2025 16:08:43 GMT, Alexey Ivanov wrote: >> Correct, hence this test is being problemlisted on macOS. > >> Correct, hence this test is being problemlisted on macOS. > > I see. > > I haven't been able to run the test on Windows or Linux today. Yes, Harshitha is correct. MacOS is PL'ed for this reason. The Windows test failing in PFJ was a separate issue that was found through this update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152706167 From dnguyen at openjdk.org Tue Jun 17 16:40:15 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:40:15 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v7] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Assign frames in main ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/605f6d97..33624112 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=05-06 Stats: 16 lines in 1 file changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From dnguyen at openjdk.org Tue Jun 17 16:44:03 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:44:03 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v8] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Move frame ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/33624112..8105ad65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=06-07 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From dnguyen at openjdk.org Tue Jun 17 16:44:03 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:44:03 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 17 Jun 2025 14:54:46 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Rearrange and update test. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 121: > >> 119: instructionsFrame.pack(); >> 120: instructionsFrame.setLocation(300, 100); >> 121: instructionsFrame.setVisible(true); > > I suggest displaying the frame in the centre of the screen > > > instructionsFrame.setLocationRelativeTo(null); > > > and then position the test frame to the right of the instruction frame. This would align to the most common layout of manual tests and would adjust positioning to the size of the current screen. > > Create the instruction frame first to be able to use its location to position the test frame. Updated! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2152716941 From honkar at openjdk.org Tue Jun 17 16:51:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 16:51:50 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v20] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 00:40:30 GMT, Alisen Chung wrote: >> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - update tests, remove extended robot from some tests > - update tests Since there are many test changes it is good to run CI on latest update. test/jdk/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java line 56: > 54: * jdk.test.lib.Platform > 55: * jtreg.SkippedException > 56: * ExtendedRobot Since ExtendedRobot is removed /lib/client is no longer required in `@library` tag. Applicable for other tests as well. ------------- Changes requested by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22044#pullrequestreview-2925692169 PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2152727259 From honkar at openjdk.org Tue Jun 17 16:51:51 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 16:51:51 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v19] In-Reply-To: References: Message-ID: On Tue, 10 Jun 2025 21:47:26 GMT, Alisen Chung wrote: >> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > synchronized for type(char) test/jdk/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java line 71: > 69: final Object actionLock = new Object(); > 70: > 71: >>>>>>> 10791477cf0a0a31d2703fc718a7a649d494d534 You might have accidently pushed this test changes without resolving a merge conflict. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2145643279 From dnguyen at openjdk.org Tue Jun 17 16:58:26 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 17 Jun 2025 16:58:26 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 12:43:23 GMT, Prasanta Sadhukhan wrote: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2936421139 From honkar at openjdk.org Tue Jun 17 17:03:48 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 17:03:48 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v20] In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 00:40:30 GMT, Alisen Chung wrote: >> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). > > Alisen Chung has updated the pull request incrementally with two additional commits since the last revision: > > - update tests, remove extended robot from some tests > - update tests test/jdk/java/awt/Modal/ModalBlockingTests/BlockingDDModelessTest.java line 36: > 34: * > 35: * @library ../helpers /lib/client/ > 36: * @library /test/lib Same here /lib/client is no longer required. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2152755206 From honkar at openjdk.org Tue Jun 17 17:07:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 17:07:36 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile [v2] In-Reply-To: References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: <4Ymgg0xaFAJNmlcugCzD_RLvBu-1uPEx_cvZnPvMC78=.603f08a9-e5f1-4e1d-92a2-a700fd70bb80@github.com> On Fri, 13 Jun 2025 20:24:49 GMT, Sergey Bylokhov wrote: >> This PR simplifies several aspects of the ICC_Profile class: >> >> - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30): >> The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377). >> >> - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe): >> In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation. >> >> - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c): >> After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code. >> >> @prrace @honkar-jdk please take a look > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > theHeader -> data Changes LGTM. CI Testing looks good. Please wait until @prrace or @jayathirthrao has had a chance to review these changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/25650#pullrequestreview-2936453443 From honkar at openjdk.org Tue Jun 17 17:14:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 17:14:29 GMT Subject: RFR: 6798061: The removal of System.out.println from KeyboardManager In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 12:56:50 GMT, Prasanta Sadhukhan wrote: > Internal debugging code is removed. src/java.desktop/share/classes/javax/swing/KeyboardManager.java line 215: > 213: Thread.dumpStack(); > 214: } > 215: Since we are removing Thread.dumpStack() is it required to add debug logger? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25851#discussion_r2152773217 From honkar at openjdk.org Tue Jun 17 17:16:30 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 17:16:30 GMT Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile [v2] In-Reply-To: References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com> Message-ID: On Thu, 12 Jun 2025 05:31:19 GMT, Harshitha Onkar wrote: >> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: >> >> theHeader -> data > > src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 807: > >> 805: System.arraycopy(data, 0, theHeader, 0, HEADER_SIZE); >> 806: verifyHeader(theHeader); >> 807: > > In reference to the above comment , these lines may need to be reverted as verifyHeader(byte[] header) expects the header array and not the entire profile byte array. This change is no longer applicable after the latest changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25650#discussion_r2152777040 From prr at openjdk.org Tue Jun 17 18:23:30 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 17 Jun 2025 18:23:30 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/0e921237..253d2bc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=07-08 Stats: 134 lines in 2 files changed: 128 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Tue Jun 17 19:22:38 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 17 Jun 2025 19:22:38 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 03:33:05 GMT, Sergey Bylokhov wrote: > > I am inclined to ask the networking API owners what the purpose and future should be. > > Yeah, that will be useful to know the future of this api, we have similar handlers for images. Discussion here https://mail.openjdk.org/pipermail/net-dev/2025-June/027254.html The suggestion was to return null. That might be a long-term direction but for now I'm going with the idea to return SoundClip. It is a little more usable for migration than null. We might some day get rid of the MultimediaContentHandlers but not here/yet FYI: my testing, there's nothing that relies on the audio handlers *except* for tests explicitly for these. The image case is however used in the java.beans implementation I submitted https://bugs.openjdk.org/browse/JDK-8359727 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153010836 From duke at openjdk.org Tue Jun 17 20:18:00 2025 From: duke at openjdk.org (lawrence.andrews) Date: Tue, 17 Jun 2025 20:18:00 GMT Subject: RFR: 8359418: Test "javax/swing/text/GlyphView/bug4188841.java" failed because the phrase of text pane does not match the instructions Message-ID: Test instruction had "the quick brown fox jumps over the lazy dog" but the actual "the\tslow\tbrown\tfox\tjumps\tover\tthe\tlazy\tdog!" Replaced slow with quick word to match the test instruction. ------------- Commit messages: - 8359418: Test javax/swing/text/GlyphView/bug4188841.java failed because the phrase of text pane does not match the instructions Changes: https://git.openjdk.org/jdk/pull/25809/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25809&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359418 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25809.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25809/head:pull/25809 PR: https://git.openjdk.org/jdk/pull/25809 From honkar at openjdk.org Tue Jun 17 20:18:01 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 17 Jun 2025 20:18:01 GMT Subject: RFR: 8359418: Test "javax/swing/text/GlyphView/bug4188841.java" failed because the phrase of text pane does not match the instructions In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 21:16:37 GMT, lawrence.andrews wrote: > Test instruction had "the quick brown fox jumps over the lazy dog" but the actual "the\tslow\tbrown\tfox\tjumps\tover\tthe\tlazy\tdog!" > > Replaced slow with quick word to match the test instruction. Marked as reviewed by honkar (Reviewer). @lawrence-andrew Please update the JBS bug so that it is accessible. ------------- PR Review: https://git.openjdk.org/jdk/pull/25809#pullrequestreview-2936818915 PR Comment: https://git.openjdk.org/jdk/pull/25809#issuecomment-2981569440 From duke at openjdk.org Tue Jun 17 20:35:34 2025 From: duke at openjdk.org (duke) Date: Tue, 17 Jun 2025 20:35:34 GMT Subject: RFR: 8359418: Test "javax/swing/text/GlyphView/bug4188841.java" failed because the phrase of text pane does not match the instructions In-Reply-To: References: Message-ID: On Fri, 13 Jun 2025 21:16:37 GMT, lawrence.andrews wrote: > Test instruction had "the quick brown fox jumps over the lazy dog" but the actual "the\tslow\tbrown\tfox\tjumps\tover\tthe\tlazy\tdog!" > > Replaced slow with quick word to match the test instruction. @lawrence-andrew Your change (at version 5e5169873c3bf51e9b4f2015479a87fb990f3473) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25809#issuecomment-2981752930 From duke at openjdk.org Tue Jun 17 20:45:33 2025 From: duke at openjdk.org (lawrence.andrews) Date: Tue, 17 Jun 2025 20:45:33 GMT Subject: Integrated: 8359418: Test "javax/swing/text/GlyphView/bug4188841.java" failed because the phrase of text pane does not match the instructions In-Reply-To: References: Message-ID: <6PMRFlzKTBYgrDCYOKwdgn6_huXpJ2bEEJp-8l3UpT4=.5937c600-3330-471c-b361-545381c11f1e@github.com> On Fri, 13 Jun 2025 21:16:37 GMT, lawrence.andrews wrote: > Test instruction had "the quick brown fox jumps over the lazy dog" but the actual "the\tslow\tbrown\tfox\tjumps\tover\tthe\tlazy\tdog!" > > Replaced slow with quick word to match the test instruction. This pull request has now been integrated. Changeset: 8c760e78 Author: lawrence.andrews Committer: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/8c760e78b9e3851d40f8036105666e9c451b09a1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8359418: Test "javax/swing/text/GlyphView/bug4188841.java" failed because the phrase of text pane does not match the instructions Reviewed-by: honkar ------------- PR: https://git.openjdk.org/jdk/pull/25809 From prr at openjdk.org Tue Jun 17 20:46:38 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 17 Jun 2025 20:46:38 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: <8KKHE4cyjH7CDtwpoJphiaxqqhxkYezchgwnOfXOZw0=.94a281fb-ce58-4ef2-8fdf-677399220e6b@github.com> On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 I think I have responded to all substantial issues, and in most cases updated the PR according to the feedback. Specification questions that have been raised are resolved and the CSR is approved. Unless someone identifies a new problem, I am not expecting to make any changes that would be significant to the CSR or JEP. So I will wait a few days to give people a chance to have a last look but I believe we are getting very close to PTT (Propose To Target) for this JEP - with the target being JDK 26. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2981779647 From prr at openjdk.org Tue Jun 17 21:00:32 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 17 Jun 2025 21:00:32 GMT Subject: RFR: 6798061: The removal of System.out.println from KeyboardManager In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 12:56:50 GMT, Prasanta Sadhukhan wrote: > Internal debugging code is removed. I presume we haven't had lots of people complaining about seeing these messages ? So they would seem to be conditions that rarely-to-never actually happen and so there's no point in logging them. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25851#pullrequestreview-2937075425 From aivanov at openjdk.org Tue Jun 17 21:51:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 17 Jun 2025 21:51:40 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 123: > 121: try { > 122: return SoundClip.createSoundClip(tmpFile); > 123: } catch (IOException e) { Suggestion: } catch (IOException ignored) { To explicitly document that we ignore the exception, and to avoid warnings in IDE. src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 352: > 350: Dialog(owner, true), etc. Prior to JDK 6 > 351: the default type was toolkit-modal, > 352: and now with single application per-VM there is no Suggestion: and now with single application per VM there is no src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 353: > 351: the default type was toolkit-modal, > 352: and now with single application per-VM there is no > 353: distinction between application- and toolkit-modality Suggestion: distinction between application- and toolkit-modality. End the sentence with a full stop? test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 87: > 85: generateOOME(); > 86: } finally { > 87: Files.delete(file.toPath()); Suggestion: file.delete(); Other parts of the test don't use NIO. test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 54: > 52: AudioSystem.write(getStream(format), Type.WAVE, file); > 53: } catch (final Exception ignored) { > 54: return; // the test is not applicable I suggest throwing `jtreg.SkippedException`, such tests aren't handled as passed. test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 60: > 58: testBigDelay(file); > 59: } finally { > 60: Files.delete(file.toPath()); Suggestion: file.delete(); Should work just as good. test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 115: > 113: > 114: private static long count() { > 115: for (final Thread t : Thread.getAllStackTraces().keySet()) { Why are stack traces are needed? Thread[] threads = new Thread[Thread.activeCount()]; Thread.enumerate(threads); would give the same estimate and use less resources. [`Thread.enumerate`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#enumerate(java.lang.Thread%5B%5D)) fills the provided array with currently active threads, and [`Thread.activeCount`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#activeCount()) provides an estimate on the number of live threads. test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 25: > 23: > 24: import static javax.sound.sampled.AudioFormat.Encoding.PCM_SIGNED; > 25: import static javax.sound.sampled.AudioSystem.NOT_SPECIFIED; Static imports usually follow the regular imports, and both `test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java` and `test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java` follow this convention. And the two other tests import `java.*` packages first and then `javax.*` packages, whereas this test reverses the (common) order of imports. test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 63: > 61: AudioSystem.write(audioStream, AudioFileFormat.Type.WAVE, file); > 62: } catch (Exception ignored) { > 63: return; // the test is not applicable Throw `jtreg.SkippedException`? The test didn't run. test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 68: > 66: checkThread(file); > 67: } finally { > 68: Files.delete(file.toPath()); Suggestion: file.delete(); test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 87: > 85: > 86: private static boolean isDataPushedThreadExist() { > 87: for (Thread t : Thread.getAllStackTraces().keySet()) { Can [Thread.enumerate](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#enumerate(java.lang.Thread%5B%5D)) be used instead? ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2937108877 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153180466 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153183860 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153183390 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153193516 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153196462 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153198451 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153218422 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153222545 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153223792 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153223055 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153226754 From achung at openjdk.org Tue Jun 17 23:11:15 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 17 Jun 2025 23:11:15 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update Message-ID: This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. ------------- Commit messages: - empty commit - redo ws fixes, add manual changes Changes: https://git.openjdk.org/jdk/pull/25839/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359761 Stats: 1574 lines in 76 files changed: 810 ins; 93 del; 671 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From achung at openjdk.org Tue Jun 17 23:18:27 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 17 Jun 2025 23:18:27 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <-07gTVUiE_k1Kfc5m2OgDlX6fj1hUMYWZqsSK2YFlYc=.0fc07185-3be2-4f7c-b24f-fca061924170@github.com> On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. whitespace changes are fixed, PR is ready for review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2982077742 From jlu at openjdk.org Tue Jun 17 23:18:29 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 17 Jun 2025 23:18:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 2: > 1: # > 2: # Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved. Same as my comment in `src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java` src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26: > 24: # > 25: > 26: main.usage=Verwendung: jdeprscan [Optionen] ''{dir|jar|class}'' ...\n\nOptionen:\n --class-path PATH\n --for-removal\n --full-version\n -? -h --help\n -l --list\n --release {0}\n -v --verbose\n --version Extra quotes, applies to other localized versions as well. (Usual change we revert) src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2: > 1: /* > 2: * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved. Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314389 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153313105 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314152 From jlu at openjdk.org Tue Jun 17 23:24:28 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 17 Jun 2025 23:24:28 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update In-Reply-To: References: Message-ID: <41BnI9ePFiQiYk_COU-Rrpz0qzr33GN0p9AfF38Fkmk=.0d9c1020-d538-41b2-a939-f7e296029ae0@github.com> On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 30: > 28: STARNN=*******************************************\n\n > 29: # keytool: Help part > 30: .OPTION.=\ [OPTION]... We spoke about this offline. This is fine, property file values need to either start with a `\ `or `\u0020` to denote intentional leading white space. In this case, since we convert to UTF-8 native characters from escape sequences this gets included as well. Functionally, they are equivalent and the new form works well with the translation process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153321343 From achung at openjdk.org Tue Jun 17 23:34:52 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 17 Jun 2025 23:34:52 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: fix unicode escapes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25839/files - new: https://git.openjdk.org/jdk/pull/25839/files/2dfac379..d8027691 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00-01 Stats: 459 lines in 3 files changed: 0 ins; 0 del; 459 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From almatvee at openjdk.org Tue Jun 17 23:43:28 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 17 Jun 2025 23:43:28 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix unicode escapes jdk.jpackage changes looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2937331933 From naoto at openjdk.org Wed Jun 18 01:56:30 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 18 Jun 2025 01:56:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix unicode escapes src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1: > 1: # Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153463170 From serb at openjdk.org Wed Jun 18 02:42:40 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 18 Jun 2025 02:42:40 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 21:24:51 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 87: > >> 85: generateOOME(); >> 86: } finally { >> 87: Files.delete(file.toPath()); > > Suggestion: > > file.delete(); > > Other parts of the test don't use NIO. it is done intentionally to throw an exception if the file is locked. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153520113 From psadhukhan at openjdk.org Wed Jun 18 03:00:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 18 Jun 2025 03:00:41 GMT Subject: Integrated: 6798061: The removal of System.out.println from KeyboardManager In-Reply-To: References: Message-ID: <7sQo569Hi907pcVs38SHrhqHrc_j3VG164mBLSl9ElA=.466592b8-4e0d-42c6-bd5c-83a623b90094@github.com> On Tue, 17 Jun 2025 12:56:50 GMT, Prasanta Sadhukhan wrote: > Internal debugging code is removed. This pull request has now been integrated. Changeset: 1130c1bc Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/1130c1bc33cc9ab4acc6862d7738297afa017e8b Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod 6798061: The removal of System.out.println from KeyboardManager Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/25851 From psadhukhan at openjdk.org Wed Jun 18 03:24:36 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 18 Jun 2025 03:24:36 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 10:08:49 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > SUmmary fix Can the PR reviewers review and approve the CSR https://bugs.openjdk.org/browse/JDK-8359398 please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2982518210 From psadhukhan at openjdk.org Wed Jun 18 03:27:31 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 18 Jun 2025 03:27:31 GMT Subject: RFR: 8359428: Test 'javax/swing/JTabbedPane/bug4499556.java' failed because after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again In-Reply-To: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> References: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> Message-ID: On Mon, 16 Jun 2025 09:21:24 GMT, Prasanta Sadhukhan wrote: > It is seen that this test (which was opensourced in [JDK-8353304](https://bugs.openjdk.org/browse/JDK-8353304)) when run with NimbusLookAndFeel, after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again. > It is because while switching to another L&F say platform(WindowsL&F) from Metal/Nimbus LookAndFeel, if testcase was originally run in Nimbus L&F, `SynthMenuItemLayoutHelper()` calls `MenuItemLayoutHelper.reset` where `style.getFont(context) `return null font so when it calls `getFontMetrics(font)` it calls `font.hashCode `which fails with > >> Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null > > This is happening because the test calls `SwingUtilities.updateComponentTreeUI `on tabbedpane. > So, when L&F is changed inside the test via "L&F Menu" option 1st time say Metal to Platform, it changes the L&F of the tabbed pane to Windows L&F, but not for the "L&F Menu" font itself which is still in Nimbus L&F, but style context is reset so when next time "L&F Menu" is clicked to change the L&F, SynthMenuItemLayoutHelper gets null font from invalid context and then it crashes. > Fix is to ensure the `updateComponentTreeUI `should be for entire frame which consists of "L&F Menu" and the tabs so L&F is changed consistently for all nodes. Any reviewers? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25822#issuecomment-2982525816 From serb at openjdk.org Wed Jun 18 03:34:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 18 Jun 2025 03:34:30 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 15:18:34 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 224: >> >>> 222: * @see java.awt.Image#getProperty >>> 223: */ >>> 224: public ImageIcon (Image image) { >> >> Does it make sense to expand the javadoc for all the constructors to specify how `null` is handled? > > I have expanded for those methods where there is code change for NULL interception....Not sure about others.. Note that "ImageIcon(URL location)" will throw npe as well, do we want to ignore it or specify NPE? That is actually interesting question since initially some of methods throw NPE and another ignore the image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2153565938 From psadhukhan at openjdk.org Wed Jun 18 03:44:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 18 Jun 2025 03:44:28 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 03:31:49 GMT, Sergey Bylokhov wrote: >> I have expanded for those methods where there is code change for NULL interception....Not sure about others.. > > Note that "ImageIcon(URL location)" will throw npe as well, do we want to ignore it or specify NPE? That is actually interesting question since initially some of methods throw NPE and another ignore the image. ImageIcon(URL) will call ImageIcon(URL, String) where already image null check was there so I guess it will not throw NPE before fix too.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2153572809 From psadhukhan at openjdk.org Wed Jun 18 04:06:38 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 18 Jun 2025 04:06:38 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible Message-ID: RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. Modified the color so that they are visible.. ------------- Commit messages: - 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible. Changes: https://git.openjdk.org/jdk/pull/25864/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25864&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335986 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25864.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25864/head:pull/25864 PR: https://git.openjdk.org/jdk/pull/25864 From abhiscxk at openjdk.org Wed Jun 18 04:42:27 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 18 Jun 2025 04:42:27 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 12:43:23 GMT, Prasanta Sadhukhan wrote: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2937702311 From duke at openjdk.org Wed Jun 18 04:46:28 2025 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 18 Jun 2025 04:46:28 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 03:56:13 GMT, Prasanta Sadhukhan wrote: > RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. > Modified the color so that they are visible.. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/25864#issuecomment-2982666871 From abhiscxk at openjdk.org Wed Jun 18 04:58:27 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 18 Jun 2025 04:58:27 GMT Subject: RFR: 8359428: Test 'javax/swing/JTabbedPane/bug4499556.java' failed because after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again In-Reply-To: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> References: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> Message-ID: <4YUe-qCNP3p9bZGUsFkeCCssTjJ3W0m8YwuIXSbdOok=.c21ef7be-6c5b-4d47-9f63-ead44cc4047e@github.com> On Mon, 16 Jun 2025 09:21:24 GMT, Prasanta Sadhukhan wrote: > It is seen that this test (which was opensourced in [JDK-8353304](https://bugs.openjdk.org/browse/JDK-8353304)) when run with NimbusLookAndFeel, after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again. > It is because while switching to another L&F say platform(WindowsL&F) from Metal/Nimbus LookAndFeel, if testcase was originally run in Nimbus L&F, `SynthMenuItemLayoutHelper()` calls `MenuItemLayoutHelper.reset` where `style.getFont(context) `return null font so when it calls `getFontMetrics(font)` it calls `font.hashCode `which fails with > >> Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null > > This is happening because the test calls `SwingUtilities.updateComponentTreeUI `on tabbedpane. > So, when L&F is changed inside the test via "L&F Menu" option 1st time say Metal to Platform, it changes the L&F of the tabbed pane to Windows L&F, but not for the "L&F Menu" font itself which is still in Nimbus L&F, but style context is reset so when next time "L&F Menu" is clicked to change the L&F, SynthMenuItemLayoutHelper gets null font from invalid context and then it crashes. > Fix is to ensure the `updateComponentTreeUI `should be for entire frame which consists of "L&F Menu" and the tabs so L&F is changed consistently for all nodes. Verified the fix on mac machine and it behaves correct with the fix. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25822#pullrequestreview-2937725298 From abhiscxk at openjdk.org Wed Jun 18 05:04:28 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 18 Jun 2025 05:04:28 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 12:43:23 GMT, Prasanta Sadhukhan wrote: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25850#issuecomment-2982692781 From psadhukhan at openjdk.org Wed Jun 18 05:11:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 18 Jun 2025 05:11:30 GMT Subject: Integrated: 8359428: Test 'javax/swing/JTabbedPane/bug4499556.java' failed because after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again In-Reply-To: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> References: <7XTv1ZO9apykp25b8RJPyS6sMbCEYnBOjqn5qWlsVU8=.a2510a28-c825-4deb-8617-925c4edc974a@github.com> Message-ID: On Mon, 16 Jun 2025 09:21:24 GMT, Prasanta Sadhukhan wrote: > It is seen that this test (which was opensourced in [JDK-8353304](https://bugs.openjdk.org/browse/JDK-8353304)) when run with NimbusLookAndFeel, after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again. > It is because while switching to another L&F say platform(WindowsL&F) from Metal/Nimbus LookAndFeel, if testcase was originally run in Nimbus L&F, `SynthMenuItemLayoutHelper()` calls `MenuItemLayoutHelper.reset` where `style.getFont(context) `return null font so when it calls `getFontMetrics(font)` it calls `font.hashCode `which fails with > >> Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null > > This is happening because the test calls `SwingUtilities.updateComponentTreeUI `on tabbedpane. > So, when L&F is changed inside the test via "L&F Menu" option 1st time say Metal to Platform, it changes the L&F of the tabbed pane to Windows L&F, but not for the "L&F Menu" font itself which is still in Nimbus L&F, but style context is reset so when next time "L&F Menu" is clicked to change the L&F, SynthMenuItemLayoutHelper gets null font from invalid context and then it crashes. > Fix is to ensure the `updateComponentTreeUI `should be for entire frame which consists of "L&F Menu" and the tabs so L&F is changed consistently for all nodes. This pull request has now been integrated. Changeset: 2b94b70e Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/2b94b70ef50675f7853c0cb6a61e60e6eb7d92ed Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8359428: Test 'javax/swing/JTabbedPane/bug4499556.java' failed because after selecting one of L&F items, the test case automatically failed when clicking on L&F Menu button again Reviewed-by: abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/25822 From tr at openjdk.org Wed Jun 18 05:16:28 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 18 Jun 2025 05:16:28 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 12:43:23 GMT, Prasanta Sadhukhan wrote: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1034: > 1032: * Gets the allocation to give the root View. > 1033: * The Rectangle returned has nothing to do with visibility but > 1034: * the method is thus named to preserve backward compatibility. Suggestion: * the method name is preserved for backward compatibility. If method name is retained from past then this sentence would be right ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2153658561 From tr at openjdk.org Wed Jun 18 05:34:27 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 18 Jun 2025 05:34:27 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 03:56:13 GMT, Prasanta Sadhukhan wrote: > RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. > Modified the color so that they are visible.. test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 192: > 190: > 191: b.setOpaque(true); > 192: b.setBackground(Color.red); The test is specifically for background color black, I think you need to retain background color. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25864#discussion_r2153676999 From abhiscxk at openjdk.org Wed Jun 18 05:55:29 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 18 Jun 2025 05:55:29 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 09:09:42 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Added SkippedException when Printer is unavailable. test/jdk/java/awt/print/Dialog/DialogType.java line 47: > 45: > 46: private static final String INSTRUCTIONS = """ > 47: This test assumes and requires that you have a printer installed Suggestion: This test assumes and requires that you have a printer installed. test/jdk/java/awt/print/Dialog/DialogType.java line 53: > 51: The test passes as long as no exceptions are thrown, *AND* > 52: if running on Windows only, the first dialog is a native windows > 53: control which differs in appearance from the second dialog Suggestion: The test passes as long as no exceptions are thrown. Platform specific instructions can be added as a NOTE. It would be better if it is mentioned at the start of instruction. The first and second dialog differs on MacOS as well. Not checked on Linux. Current instruction says only about Windows, better to verify and modify the instruction. test/jdk/java/awt/print/Dialog/DialogType.java line 59: > 57: job = PrinterJob.getPrinterJob(); > 58: if (job.getPrintService() == null) { > 59: throw new SkippedException("Printer not configured or not available"); Suggestion: throw new SkippedException("Test Skipped, Printer not configured or not available"); test/jdk/java/awt/print/Dialog/DialogType.java line 62: > 60: } > 61: PassFailJFrame passFailJFrame = PassFailJFrame.builder() > 62: .title("DialogType Test Instructions") Default title is : "File name" followed by " - Test Instructions" Title can be removed. test/jdk/java/awt/print/Dialog/DialogType.java line 64: > 62: .title("DialogType Test Instructions") > 63: .instructions(INSTRUCTIONS) > 64: .rows((int)INSTRUCTIONS.lines().count() + 2) No need to set `rows` explicitly. test/jdk/java/awt/print/Dialog/DialogType.java line 84: > 82: for (int i = 0; i < attrs.length; i++) { > 83: System.out.println(attrs[i]); > 84: } Move the duplicate code to helper method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153688263 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153692463 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153692940 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153694549 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153696026 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153701206 From tr at openjdk.org Wed Jun 18 06:01:35 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 18 Jun 2025 06:01:35 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 09:09:42 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Added SkippedException when Printer is unavailable. test/jdk/java/awt/print/Dialog/DialogType.java line 52: > 50: Two dialogs are shown in succession. > 51: The test passes as long as no exceptions are thrown, *AND* > 52: if running on Windows only, the first dialog is a native windows Windows specific can be as note or even you can append it to instructions on Windows OS check condition. test/jdk/java/awt/print/Dialog/DialogType.java line 62: > 60: } > 61: PassFailJFrame passFailJFrame = PassFailJFrame.builder() > 62: .title("DialogType Test Instructions") Not required. test/jdk/java/awt/print/Dialog/DialogType.java line 64: > 62: .title("DialogType Test Instructions") > 63: .instructions(INSTRUCTIONS) > 64: .rows((int)INSTRUCTIONS.lines().count() + 2) Not required. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153708020 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153703117 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2153703273 From nbenalla at openjdk.org Wed Jun 18 09:08:29 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 18 Jun 2025 09:08:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix unicode escapes I'm unable to confirm the accuracy of the translations, since I don't speak the target languages. I've only reviewed the `jdk.javadoc` sources. All keys in the English property files match one-to-one with those in the non-English files: there are no missing or extra entries. The only changes are to the `.properties` files, exactly as the PR title suggests. >From the `jdk.javadoc` perspective, this looks good, so I'm happy to approve this PR. ------------- Marked as reviewed by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2938377311 From mvs at openjdk.org Wed Jun 18 09:39:02 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 09:39:02 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar Message-ID: Issue: In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. Fix: Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). Testing: Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. ------------- Commit messages: - 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar Changes: https://git.openjdk.org/jdk/pull/25868/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25868&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359889 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25868/head:pull/25868 PR: https://git.openjdk.org/jdk/pull/25868 From jsikstro at openjdk.org Wed Jun 18 09:50:30 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 18 Jun 2025 09:50:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix unicode escapes Should the other localizations for the launcher help text (in `launcher_.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2983504760 From serb at openjdk.org Wed Jun 18 09:56:37 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 18 Jun 2025 09:56:37 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2938561283 From aivanov at openjdk.org Wed Jun 18 14:07:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 14:07:38 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 02:39:53 GMT, Sergey Bylokhov wrote: > it is done intentionally to throw an exception if the file is locked. A comment would've clarified the intention. This also means that if the test fails for whatever reason and `Files.delete` throws the exception, the original exception gets replaced with `IOException` from deleting the file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154701920 From aivanov at openjdk.org Wed Jun 18 14:19:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 14:19:41 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 353: > 351: the default type was toolkit-modal, > 352: and now with single application per-VM there is no > 353: distinction between application- and toolkit-modality Suggestion: and now with single application per VM there is no distinction between application- and toolkit-modality. There should be a space between a preposition and a noun and a full stop in the end of the sentence. ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2939418360 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154723332 From aivanov at openjdk.org Wed Jun 18 14:19:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 14:19:42 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: <8KKHE4cyjH7CDtwpoJphiaxqqhxkYezchgwnOfXOZw0=.94a281fb-ce58-4ef2-8fdf-677399220e6b@github.com> References: <8KKHE4cyjH7CDtwpoJphiaxqqhxkYezchgwnOfXOZw0=.94a281fb-ce58-4ef2-8fdf-677399220e6b@github.com> Message-ID: On Tue, 17 Jun 2025 20:43:24 GMT, Phil Race wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > I think I have responded to all substantial issues, and in most cases updated the PR according to the feedback. > Specification questions that have been raised are resolved and the CSR is approved. > Unless someone identifies a new problem, I am not expecting to make any changes that would be significant to the CSR or JEP. > > So I will wait a few days to give people a chance to have a last look but I believe we are getting very close to PTT (Propose To Target) for this JEP - with the target being JDK 26. @prrace, @mrserb I see the tests aren't new, they're updated. I viewed only the changes since the last time I'd reviewed the changes and all these tests were displayed as new. Ignoring all the comments to the tests, this leaves only a comment for `src/java.desktop/share/classes/java/awt/doc-files/Modality.html`: - and now with single application per-VM there is no - distinction between application- and toolkit-modality + and now with single application per VM there is no + distinction between application- and toolkit-modality. The fix can be applied in GitHub interface by accepting [my suggestion](https://github.com/openjdk/jdk/pull/25698#discussion_r2154723332). (I've removed yesterday's comments for `Modality.html`.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2984405779 From aivanov at openjdk.org Wed Jun 18 14:36:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 14:36:38 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> Message-ID: On Tue, 10 Jun 2025 17:59:41 GMT, Phil Race wrote: >> Shall I submit a bug to consider removing this code? >> >> Without the comment and an issue to track it, no one will ever remember to look into it. > > yes, go ahead. Submitted [JDK-8359932](https://bugs.openjdk.org/browse/JDK-8359932): _[macosx] Popups don't activate applet's process - unused code?_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154771290 From aivanov at openjdk.org Wed Jun 18 14:36:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 14:36:39 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> References: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com> Message-ID: <2YdJt4vSc6EfRJckAlQKn-eoyuv4JeIUJ-w1PNeSyuQ=.be6cefad-b0a9-4299-b35d-363226bd8ce0@github.com> On Mon, 9 Jun 2025 21:03:55 GMT, Phil Race wrote: >> src/java.desktop/share/classes/java/awt/Dialog.java line 174: >> >>> 172: * from the same toolkit except those from its own child hierarchy. >>> 173: */ >>> 174: TOOLKIT_MODAL >> >> Should we add a note that `APPLICATION_MODAL` and `TOOLKIT_MODAL` mean the same thing in the absence of applets or even remove one of them? > > Yes, It didn't escape me that they mean essentially the same thing, even more so than they did before > Theoretically there can be more than one toolkit, although it is not really possible. > > Addressing the nuances of that is outside the scope of this change, so I made the minimum doc change and removing applet isn't the right time to add advice about which to use. So future work there. > And very unlikely to remove either of them as I suspect the similarities mean that developers probably are 50:50 in which they used, so we'd just break (more) apps if we did. A bug to clarify the usage [JDK-8359499](https://bugs.openjdk.org/browse/JDK-8359499): _Clarify spec around `TOOLKIT_MODAL` and `APPLICATION_MODAL`_. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154776375 From kizune at openjdk.org Wed Jun 18 15:02:29 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 18 Jun 2025 15:02:29 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:33:50 GMT, Manukumar V S wrote: > Issue: > In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. > > Fix: > Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). > > Testing: > Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25868#pullrequestreview-2939604886 From duke at openjdk.org Wed Jun 18 15:15:28 2025 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 18 Jun 2025 15:15:28 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar In-Reply-To: References: Message-ID: <5UVYAe9xffQfkJXF9dEqxefuHn5Luf_Y6MJ-S4hLGe4=.242a4fce-5100-411c-acba-c112d87b63f7@github.com> On Wed, 18 Jun 2025 09:33:50 GMT, Manukumar V S wrote: > Issue: > In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. > > Fix: > Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). > > Testing: > Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/25868#issuecomment-2984628938 From duke at openjdk.org Wed Jun 18 15:15:28 2025 From: duke at openjdk.org (duke) Date: Wed, 18 Jun 2025 15:15:28 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:33:50 GMT, Manukumar V S wrote: > Issue: > In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. > > Fix: > Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). > > Testing: > Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. @manukumarvs Your change (at version 25a679de173ec1076113c868b09e30e360867dc6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25868#issuecomment-2984636310 From aivanov at openjdk.org Wed Jun 18 15:25:33 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 15:25:33 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:33:50 GMT, Manukumar V S wrote: > Issue: > In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. > > Fix: > Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). > > Testing: > Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. Update the copyright year. Otherwise, it looks good. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25868#pullrequestreview-2939705760 From aivanov at openjdk.org Wed Jun 18 15:38:13 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 15:38:13 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 15:35:27 GMT, Manukumar V S wrote: >> Issue: >> In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. >> >> Fix: >> Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). >> >> Testing: >> Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Copyright changes Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25868#pullrequestreview-2939750179 From mvs at openjdk.org Wed Jun 18 15:38:13 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 15:38:13 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar [v2] In-Reply-To: References: Message-ID: > Issue: > In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. > > Fix: > Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). > > Testing: > Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Copyright changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25868/files - new: https://git.openjdk.org/jdk/pull/25868/files/25a679de..92179537 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25868&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25868&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25868.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25868/head:pull/25868 PR: https://git.openjdk.org/jdk/pull/25868 From duke at openjdk.org Wed Jun 18 15:41:27 2025 From: duke at openjdk.org (duke) Date: Wed, 18 Jun 2025 15:41:27 GMT Subject: RFR: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 15:38:13 GMT, Manukumar V S wrote: >> Issue: >> In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. >> >> Fix: >> Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). >> >> Testing: >> Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Copyright changes @manukumarvs Your change (at version 9217953754c70f60020613fdb7cb04258cd522cd) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25868#issuecomment-2984742046 From aivanov at openjdk.org Wed Jun 18 16:15:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 16:15:35 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > fix unicode escapes src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1: > 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved. Shall the copyright year be updated? src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460: > 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler > 459: SliderDemo.majorticks=Grobteilungen > 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen Should the translation of `SliderDemo.majorticks` also be updated? src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462: > 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen > 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels > 462: SliderDemo.minorticks=Feinteilungen The following description uses different words now: Feinteilungen -> Teilstrichen Teilungen -> Teilstrichen src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183: > 181: size.bit.alg=%1$d-Bit-%2$s > 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3} > 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4} It feels as if there's something missing after _?einem?_. src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46: > 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben > 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben > 46: Subject.=Subject:\n Is it correct? German usually uses `k`. src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56: > 54: > 55: # javax.security.auth.login.AppConfigurationEntry > 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020 Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently. src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220: > 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert > 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert > 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen: Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229: > 227: doclet.search_in_documentation=In Dokumentation suchen > 228: doclet.search_reset=Zur?cksetzen > 229: doclet.Member=Member Is `Member` translated? Should it be _?Mitglied?_? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154931256 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154807291 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154813672 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154907979 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154905960 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154915395 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154968902 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154985100 From jlu at openjdk.org Wed Jun 18 16:24:29 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 18 Jun 2025 16:24:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 15:28:49 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56: > >> 54: >> 55: # javax.security.auth.login.AppConfigurationEntry >> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020 > > Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently. There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155032074 From mvs at openjdk.org Wed Jun 18 16:26:13 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 16:26:13 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result on headless machines Message-ID: Issue: java/awt/font/TextLayout/MyanmarTextTest.java passes on headless machines even though it creates GUI components. Ideally, when you create some GUI components in your code in a headless machine, it should through HeadlessException, but MyanmarTextTest.java seems to suppress it and gives a positive result. Fix: Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. Testing: Tested using mach5 in all available platforms and got full PASS. ------------- Commit messages: - 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result on headless machines Changes: https://git.openjdk.org/jdk/pull/25879/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358697 Stats: 9 lines in 1 file changed: 4 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25879/head:pull/25879 PR: https://git.openjdk.org/jdk/pull/25879 From jlu at openjdk.org Wed Jun 18 16:28:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 18 Jun 2025 16:28:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 15:34:38 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1: > >> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved. > > Shall the copyright year be updated? In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155038247 From aivanov at openjdk.org Wed Jun 18 16:29:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 16:29:32 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 03:41:32 GMT, Prasanta Sadhukhan wrote: >> Note that "ImageIcon(URL location)" will throw npe as well, do we want to ignore it or specify NPE? That is actually interesting question since initially some of methods throw NPE and another ignore the image. > > ImageIcon(URL) will call ImageIcon(URL, String) where already image null check was there so I guess it will not throw NPE before fix too.. Indeed, it throws `NullPointerException`: jshell> import javax.swing.ImageIcon; jshell> import java.net.URL; jshell> new ImageIcon((URL) null); | Exception java.lang.NullPointerException: Cannot invoke "java.net.URL.toExternalForm()" because "location" is null | at ImageIcon. (ImageIcon.java:234) | at (#3:1) https://github.com/openjdk/jdk/blob/984d7f9cdfb0d75ea906ce32df0b6c447f4d5954/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L202-L204 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155041323 From mvs at openjdk.org Wed Jun 18 16:44:33 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 16:44:33 GMT Subject: Integrated: 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 09:33:50 GMT, Manukumar V S wrote: > Issue: > In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine. > > Fix: > Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null). > > Testing: > Tested manually and using Mach5(20 times in 3 machines) and got all PASS and never triggered unwanted clicks on taskbar. This pull request has now been integrated. Changeset: b7fcd0b2 Author: Manukumar V S Committer: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/b7fcd0b2351cee8d3d18abaf0bf5905d20c9d46c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar Reviewed-by: aivanov, kizune ------------- PR: https://git.openjdk.org/jdk/pull/25868 From aivanov at openjdk.org Wed Jun 18 16:45:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 16:45:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 16:25:29 GMT, Justin Lu wrote: >> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1: >> >>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved. >> >> Shall the copyright year be updated? > > In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version". This is weird? Usually, the copyright year is bumped up whenever the file is edited. >> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56: >> >>> 54: >>> 55: # javax.security.auth.login.AppConfigurationEntry >>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020 >> >> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently. > > There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language. Thank you for clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071387 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071915 From naoto at openjdk.org Wed Jun 18 16:58:34 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 18 Jun 2025 16:58:34 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 09:47:57 GMT, Joel Sikstr?m wrote: > Should the other localizations for the launcher help text (in `launcher_.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far. Those languages (de/ja/zh-CN) are the ones we (Oracle) support. Other entities would be welcome to provide l10n for other languages (not a sporadic l10n, but commit to update/maintain). > > Edit: I see that the other localizations haven't been updated for the last few releases, so maybe this is intentional. Still interested to know why we have the other localizations if they aren't updated. Usuallly l10n resource updates are additions, so those old l10ns still have values for those languages. New additions will simply fall back to English. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2985038815 From prr at openjdk.org Wed Jun 18 17:03:28 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 17:03:28 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result on headless machines In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 16:20:14 GMT, Manukumar V S wrote: > Issue: > java/awt/font/TextLayout/MyanmarTextTest.java passes on headless machines even though it creates GUI components. Ideally, when you create some GUI components in your code in a headless machine, it should through HeadlessException, but MyanmarTextTest.java seems to suppress it and gives a positive result. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. I don't understand how what you changed related to the stated problem. In fact I don't see the point of this PR at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25879#issuecomment-2985052413 From aivanov at openjdk.org Wed Jun 18 17:45:33 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 17:45:33 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v9] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 10:08:49 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > SUmmary fix Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/ImageIcon.java line 218: > 216: /** > 217: * Creates an ImageIcon from an image object. > 218: * Setting a {@code null} image will not render any image icon. Suggestion: * Passing a {@code null} image renders no icon. src/java.desktop/share/classes/javax/swing/ImageIcon.java line 374: > 372: /** > 373: * Sets the image displayed by this icon. > 374: * Setting a {@code null} image will not render any image icon. Suggestion: * Setting a {@code null} image renders no icon. I think this is better: it's shorter, it uses the present tense because it's fact and it doesn't depend on anything. test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 27: > 25: * @test > 26: * @bug 8159055 > 27: * @summary Verifies ImageIcon setImage and constructor handles null parameter Suggestion: * @summary Verifies ImageIcon setImage and ImageIcon(Image) constructor handle null parameter Let's be more specific. test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 42: > 40: > 41: private static void testImageIconNull() { > 42: // Setting null image shouldn't cause NPE Suggestion: // Passing null image shouldn't cause NPE ------------- PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2939948842 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155166397 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155163642 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155170970 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155043719 From aivanov at openjdk.org Wed Jun 18 17:45:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 17:45:35 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 02:46:37 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 373: >> >>> 371: /** >>> 372: * Sets the image displayed by this icon. >>> 373: * Setting null image will not render any image icon. >> >> Suggestion: >> >> * Setting a {@code null} image will not render any image icon. >> >> >> Will it sound clearer if the text stated, _?Setting a `{@code null}` image will remove the icon??_ > > I didnt use "remove the icon" as there are 2 possibilities. > - Already there is existing ImageIcon with image set so if now ImageIcon.setImage(null) is called, it will remove the existing icon and thereafter will not render any image icon > - If there is no ImageIcon set, calling ImageIcon.setImage(null) will not render any image icon so no question of removing the icon > so in both possibilities, there is no imageicon rendered for null image so I chose that phrase. I agree that ?remove the icon? is confusing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155066882 From aivanov at openjdk.org Wed Jun 18 17:48:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 17:48:30 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v5] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 16:27:03 GMT, Alexey Ivanov wrote: >> ImageIcon(URL) will call ImageIcon(URL, String) where already image null check was there so I guess it will not throw NPE before fix too.. > > Indeed, it throws `NullPointerException`: > > > jshell> import javax.swing.ImageIcon; > > jshell> import java.net.URL; > > jshell> new ImageIcon((URL) null); > | Exception java.lang.NullPointerException: Cannot invoke "java.net.URL.toExternalForm()" because "location" is null > | at ImageIcon. (ImageIcon.java:234) > | at (#3:1) > > > https://github.com/openjdk/jdk/blob/984d7f9cdfb0d75ea906ce32df0b6c447f4d5954/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L202-L204 It also throws an exception this way: jshell> new ImageIcon((URL) null, ""); | Exception java.lang.NullPointerException: Cannot invoke "java.net.URL.toString()" because "url" is null | at SunToolkit.getImageFromHash (SunToolkit.java:699) | at SunToolkit.getImage (SunToolkit.java:735) | at ImageIcon. (ImageIcon.java:215) | at (#4:1) Thus, `ImageIcon(URL)` constructors have to be updated? under a new issue, maybe? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155174950 From prr at openjdk.org Wed Jun 18 18:04:16 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 18:04:16 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args Message-ID: Clarify the behaviour of new HeadlessException().getMessage() The spec. is updated to be clear that empty means null, not an empty string. ------------- Commit messages: - 8358526 Changes: https://git.openjdk.org/jdk/pull/25881/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25881&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358526 Stats: 52 lines in 2 files changed: 51 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25881.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25881/head:pull/25881 PR: https://git.openjdk.org/jdk/pull/25881 From prr at openjdk.org Wed Jun 18 18:09:28 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 18:09:28 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. CSR to be reviewed https://bugs.openjdk.org/browse/JDK-8359951 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25881#issuecomment-2985249478 From mvs at openjdk.org Wed Jun 18 18:13:28 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 18:13:28 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:00:53 GMT, Phil Race wrote: > I don't understand how what you changed related to the stated problem. In fact I don't see the point of this PR at all. Sorry @prrace, my earlier description was ambiguous. I have updated it. In fact, the issue is about reporting a false positive 'PASSED' result when it should return a 'SKIPPED' result if the preconditions for running the test are not met. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25879#issuecomment-2985258938 From aivanov at openjdk.org Wed Jun 18 18:21:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 18:21:32 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met In-Reply-To: References: Message-ID: <-84fxJAa8X4PPdGH1fL9QfUhWL8geAuLiUqjUk6uYyQ=.5073f7f7-da86-4e70-ac3d-9c28c21babf9@github.com> On Wed, 18 Jun 2025 16:20:14 GMT, Manukumar V S wrote: > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. Changes requested by aivanov (Reviewer). test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 58: > 56: private static final String FONT_LINUX = "Padauk"; > 57: private static final String FONT_MACOS = "Myanmar MN"; > 58: private static final String osName = System.getProperty("os.name").toLowerCase(); I would put this above the font names, and a blank line before and after its declaration. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 69: > 67: if (FONT_NAME == null) { > 68: System.err.println("Unsupported OS: exiting"); > 69: throw new SkippedException("Unsupported OS: "+osName); Suggestion: throw new SkippedException("Unsupported OS: " + osName); ------------- PR Review: https://git.openjdk.org/jdk/pull/25879#pullrequestreview-2940248798 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155225389 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155225704 From prr at openjdk.org Wed Jun 18 18:34:27 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 18:34:27 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 16:20:14 GMT, Manukumar V S wrote: > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 56: > 54: > 55: private static final String FONT_WINDOWS = "Myanmar Text"; > 56: private static final String FONT_LINUX = "Padauk"; A more useful update might be to update the test to look for more fonts on Linux. I don't see Padauk on my Ubuntu 24.04 system. I do have various Noto ones - eg "Noto Sans Myanmar" So on Linux I would look for BOTH fonts before giving up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155245925 From aivanov at openjdk.org Wed Jun 18 18:37:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 18:37:29 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: <7msLzwvMwfJkPqTL23_V0Wx2w_1Y13CxTFnDbfV9zOk=.1ac1dac7-1f43-4d23-abdc-42a63ddab6cf@github.com> On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. Should each constructor specify how the message returned by `getMessage` is constructed instead of _directing to the specification of `getMessage` for details_? src/java.desktop/share/classes/java/awt/HeadlessException.java line 56: > 54: * For such {@code HeadlessException} the default headless error message > 55: * may be auto-generated for some platforms. > 56: * The text of the default headless message may depend on This doesn't align, the following text has to be modified too. The first sentence of the second paragraph, ?For such `{@code HeadlessException}` the default headless error message may be auto-generated for some platforms,? should be replaced with the slightly edited text from the `HeadlessException(String)` constructor: ?For some platforms, the `{@code null}` detail message may be replaced with the default headless error message.? ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25881#pullrequestreview-2940277056 PR Review Comment: https://git.openjdk.org/jdk/pull/25881#discussion_r2155243664 From dnguyen at openjdk.org Wed Jun 18 18:38:45 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 18 Jun 2025 18:38:45 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Change timeout and instructions columns. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/8105ad65..da207f30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From mvs at openjdk.org Wed Jun 18 18:39:43 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 18:39:43 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v2] In-Reply-To: References: Message-ID: <0nYww0RiJy4tp5kBhDdQp9uty21fLG2nIkxyhgCWdqA=.5914a4b6-0f37-4a29-b38f-4d1f5842db5f@github.com> > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full 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/25879/files - new: https://git.openjdk.org/jdk/pull/25879/files/b368eece..74a5c027 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25879/head:pull/25879 PR: https://git.openjdk.org/jdk/pull/25879 From honkar at openjdk.org Wed Jun 18 18:41:32 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 18 Jun 2025 18:41:32 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Wed, 18 Jun 2025 18:38:45 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change timeout and instructions columns. Updated changes LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25705#pullrequestreview-2940297684 From achung at openjdk.org Wed Jun 18 18:42:54 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 18 Jun 2025 18:42:54 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3] In-Reply-To: References: Message-ID: <3Sb_Nj53MtMZRoKypbBFn0yumsFtiGJzY5fv60CilwA=.4ee9201b-0657-484b-8e69-01306c131b39@github.com> > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: remove double quotes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25839/files - new: https://git.openjdk.org/jdk/pull/25839/files/d8027691..66c34e7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From honkar at openjdk.org Wed Jun 18 18:48:31 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 18 Jun 2025 18:48:31 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:14:08 GMT, Tejesh R wrote: >> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1034: > >> 1032: * Gets the allocation to give the root View. >> 1033: * The Rectangle returned has nothing to do with visibility but >> 1034: * the method is thus named to preserve backward compatibility. > > Suggestion: > > * the method name is preserved for backward compatibility. > > If method name is retained from past then this sentence would be right ? I agree. The above rephrasing sounds clearer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2155265661 From dnguyen at openjdk.org Wed Jun 18 18:50:29 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 18 Jun 2025 18:50:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 23:15:05 GMT, Justin Lu wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> remove double quotes > > src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2: > >> 1: /* >> 2: * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved. > > Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year. Is there any way to prevent this or do we just change it back when we do a drop and explain why each time? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155272483 From honkar at openjdk.org Wed Jun 18 18:52:30 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 18 Jun 2025 18:52:30 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: <7vOiqZSh67Pkd1Io8GOQldYtoWkEAPhJAHYhvBLrv3o=.43d1064b-4847-482e-a7ff-611978d78726@github.com> On Wed, 18 Jun 2025 05:01:53 GMT, Abhishek Kumar wrote: >> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". > > CSR? @kumarabhi006 > CSR? javadoc change is for a protected method so I think CSR is not required for this change ------------- PR Comment: https://git.openjdk.org/jdk/pull/25850#issuecomment-2985363354 From aivanov at openjdk.org Wed Jun 18 19:07:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 19:07:31 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Wed, 18 Jun 2025 18:38:45 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change timeout and instructions columns. Changes requested by aivanov (Reviewer). test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 46: > 44: static Frame instructionsFrame; > 45: private static final CountDownLatch countDownLatch = new CountDownLatch(1); > 46: static String INSTRUCTIONS = """ I'd place the fields in this order: INSTRUCTIONS testFrame instructionsFrame countDownLatch The blank lines are explicit for the code, too. This way the fields come in groups: the instructions describe what the tester will do, so it's reasonable to put them at the top, and this aligns to the most common way in manual tests; then go the two frames of the test; the latch which controls the test follows. Personally, I'd also declare all of them `private`. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 55: > 53: and should stay the same while dragging across the > 54: components. Once you reach the list, release the > 55: left mouse button. Immediately after, the cursor ~~Immediately after~~ As soon as you release the left mouse button, the cursor? test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 114: > 112: Panel btnPanel = new Panel(); > 113: Button passBtn = new Button("PASS"); > 114: Button failBtn = new Button("FAIL"); Suggestion: Button passBtn = new Button("Pass"); Button failBtn = new Button("Fail"); Title case is good enough. test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 123: > 121: failBtn.addActionListener(e -> { > 122: throw new RuntimeException("Test Failed"); > 123: }); You have to release the latch, otherwise the test doesn't exit if it's run without jtreg. ------------- PR Review: https://git.openjdk.org/jdk/pull/25705#pullrequestreview-2940332720 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155279444 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155281655 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155286080 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155289355 From aivanov at openjdk.org Wed Jun 18 19:07:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 19:07:32 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v5] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Tue, 17 Jun 2025 16:32:54 GMT, Damon Nguyen wrote: >> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 105: >> >>> 103: Panel btnPanel = new Panel(); >>> 104: Button passBtn = new Button("PASS"); >>> 105: Button failBtn = new Button("FAIL"); >> >> Suggestion: >> >> Button passBtn = new Button("Pass"); >> Button failBtn = new Button("Fail"); >> >> There's no reason ?scream?. > > Very true. The code hasn't been updated, though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155286653 From mvs at openjdk.org Wed Jun 18 19:13:07 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 19:13:07 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v3] In-Reply-To: References: Message-ID: <3NcpK9TjAyXBOc-PVd9jKX588ybNmL5mwmsHgTnoMU4=.545061ac-61e5-43bb-b984-19cd0fdafd8d@github.com> > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed : Reworked the code to check for more fonts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25879/files - new: https://git.openjdk.org/jdk/pull/25879/files/74a5c027..ebd9bc33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=01-02 Stats: 33 lines in 1 file changed: 14 ins; 2 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/25879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25879/head:pull/25879 PR: https://git.openjdk.org/jdk/pull/25879 From mvs at openjdk.org Wed Jun 18 19:18:06 2025 From: mvs at openjdk.org (Manukumar V S) Date: Wed, 18 Jun 2025 19:18:06 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v4] In-Reply-To: References: Message-ID: <2e8UF6GWbEa5P94W_BUk_JSk_UXMv_C9vzKcQYoJwio=.aa619959-2e94-4b0c-8557-2460bcbc495c@github.com> > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Added blank line before OS_NAME ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25879/files - new: https://git.openjdk.org/jdk/pull/25879/files/ebd9bc33..bdc40569 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25879/head:pull/25879 PR: https://git.openjdk.org/jdk/pull/25879 From honkar at openjdk.org Wed Jun 18 19:18:30 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 18 Jun 2025 19:18:30 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <0jUkeeMbe6IjqpMi3yMRnDj9htjrKIFDQNG0v3ueJMI=.f778512b-fc63-44cc-b57b-6e6842117f45@github.com> On Wed, 18 Jun 2025 18:59:08 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change timeout and instructions columns. > > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 123: > >> 121: failBtn.addActionListener(e -> { >> 122: throw new RuntimeException("Test Failed"); >> 123: }); > > You have to release the latch, otherwise the test doesn't exit if it's run without jtreg. Good point. Missed it since I ran it as jtreg test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155330691 From aivanov at openjdk.org Wed Jun 18 19:23:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 19:23:29 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <1MzKmGwV4zAOAKLmqpp_sDfUJ2yKCGvkjEQi2UkJ1R4=.b2846225-95d7-446a-8009-6b6518136545@github.com> On Wed, 18 Jun 2025 18:38:45 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Change timeout and instructions columns. **Funny!** > The Windows test failing in PFJ was a separate issue that was found through this update. You submitted [JDK-8359469](https://bugs.openjdk.org/browse/JDK-8359469) to find the problem? What `PassFailJFrame` has in addition to a static frame that doesn't display anything is a **timer**. The timer updates each second, which sends additional messages ? the dragged cursor changes as soon as the displayed time updates. Pause the timer, and the drag cursor doesn't change until you release the left mouse button. Harshitha was close to discovering it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25705#issuecomment-2985440963 From dnguyen at openjdk.org Wed Jun 18 19:32:38 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 18 Jun 2025 19:32:38 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" Message-ID: Compilation error on windows with `WindowsButtonUI` used. Replaced it with `BasicButtonUI` to maintain overriding the `paintText` method but this was not the same as Windows L&F buttons. I attempted to import `WindowsButtonUI` and extending it, but the class is `final`. Instead, I chose to add a LineBorder in the same way as when a Rectangle was drawn to keep the same test behavior. It seems the extra 1 pixel width is unnecessary now when testing, so the changes only include removing `MyButtonUI` and adding a LineBorder. ------------- Commit messages: - Update test to not extend ButtonUI - 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 - ... and 1 more: https://git.openjdk.org/jdk/compare/a377773f...63255619 Changes: https://git.openjdk.org/jdk/pull/25883/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25883&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359430 Stats: 20 lines in 1 file changed: 0 ins; 17 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25883.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25883/head:pull/25883 PR: https://git.openjdk.org/jdk/pull/25883 From aivanov at openjdk.org Wed Jun 18 20:07:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 20:07:29 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v4] In-Reply-To: <2e8UF6GWbEa5P94W_BUk_JSk_UXMv_C9vzKcQYoJwio=.aa619959-2e94-4b0c-8557-2460bcbc495c@github.com> References: <2e8UF6GWbEa5P94W_BUk_JSk_UXMv_C9vzKcQYoJwio=.aa619959-2e94-4b0c-8557-2460bcbc495c@github.com> Message-ID: On Wed, 18 Jun 2025 19:18:06 GMT, Manukumar V S wrote: >> Issue: >> MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. >> >> Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. >> >> Fix: >> Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. >> >> Testing: >> Tested using mach5 in all available platforms and got full PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Added blank line before OS_NAME Changes requested by aivanov (Reviewer). test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 59: > 57: private static final String[] FONTS_WINDOWS = {"Myanmar Text", "Noto Sans Myanmar"}; > 58: private static final String[] FONTS_LINUX = {"Padauk", "Noto Sans Myanmar", "Myanmar Text"}; > 59: private static final String[] FONTS_MACOS = {"Myanmar MN", "Noto Sans Myanmar", "Myanmar Text"}; I'm unsure if Noto Sans fonts are installed by default on Windows or macOS. Similarly, "Myanmar Text" is unlikely to be installed on Linux. Since there's a list of possible fonts, the list could well be *platform-independent* ? just look for a first match. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 61: > 59: private static final String[] FONTS_MACOS = {"Myanmar MN", "Noto Sans Myanmar", "Myanmar Text"}; > 60: > 61: private static final String[] FONT_CANDIDATES = selectFontCandidates(); Suggestion: private static final List FONT_CANDIDATES = List.of("Myanmar MN", "Padauk", "Myanmar Text", "Noto Sans Myanmar"); test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 74: > 72: throw new SkippedException("Unsupported OS: " + OS_NAME); > 73: } > 74: if (FONT_NAME == null) { With the changes that I propose, `FONT_NAME = selectFontName()`, this will be the only condition: if the font name is `null`, no suitable font is found ? skip the test. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 105: > 103: main.setLayout(new BoxLayout(main, BoxLayout.Y_AXIS)); > 104: main.add(myanmarTF); > 105: main.setBorder(BorderFactory.createEmptyBorder(7, 7, 7, 7)); I see no reason for removing this blank line. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 153: > 151: } > 152: > 153: private static String selectAvailableFont() { private static String selectFontName() { return Arrays.stream(GraphicsEnvironment .getLocalGraphicsEnvironment() .getAvailableFontFamilyNames()) .filter(FONT_CANDIDATES::contains) .findFirst() .orElse(null); } ------------- PR Review: https://git.openjdk.org/jdk/pull/25879#pullrequestreview-2940458706 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155365237 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155390963 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155402010 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155366028 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155392324 From aivanov at openjdk.org Wed Jun 18 20:20:33 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 20:20:33 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 12:43:23 GMT, Prasanta Sadhukhan wrote: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1032: > 1030: > 1031: /** > 1032: * Gets the allocation to give the root View. Suggestion: * Gets the allocation for the root view. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1033: > 1031: /** > 1032: * Gets the allocation to give the root View. > 1033: * The Rectangle returned has nothing to do with visibility but Suggestion: * The rectangle returned has nothing to do with visibility but I suggest going lower case unless you specifically refer to the rectangle as the type in which case, it should be `{@code Rectangle}`. ------------- PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2940543621 PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2155421060 PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2155423236 From prr at openjdk.org Wed Jun 18 20:21:33 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 20:21:33 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v4] In-Reply-To: References: <2e8UF6GWbEa5P94W_BUk_JSk_UXMv_C9vzKcQYoJwio=.aa619959-2e94-4b0c-8557-2460bcbc495c@github.com> Message-ID: On Wed, 18 Jun 2025 19:39:09 GMT, Alexey Ivanov wrote: >> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: >> >> Added blank line before OS_NAME > > test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 59: > >> 57: private static final String[] FONTS_WINDOWS = {"Myanmar Text", "Noto Sans Myanmar"}; >> 58: private static final String[] FONTS_LINUX = {"Padauk", "Noto Sans Myanmar", "Myanmar Text"}; >> 59: private static final String[] FONTS_MACOS = {"Myanmar MN", "Noto Sans Myanmar", "Myanmar Text"}; > > I'm unsure if Noto Sans fonts are installed by default on Windows or macOS. > > Similarly, "Myanmar Text" is unlikely to be installed on Linux. > > Since there's a list of possible fonts, the list could well be *platform-independent* ? just look for a first match. My comment was ONLY about Linux. I definitely didn't expect to see the fonts for other platforms updated. They can be a list of one font. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155424813 From aivanov at openjdk.org Wed Jun 18 20:25:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 20:25:28 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:01:53 GMT, Abhishek Kumar wrote: >> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". > > CSR? > @kumarabhi006 > > > CSR? > > javadoc change is for a protected method so I think CSR is not required for this change A protected method is part of the public API contract, see [`BasicTextUI.getVisibleEditorRect`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/plaf/basic/BasicTextUI.html#getVisibleEditorRect()) in Java 24. However, I say a CSR is not needed because the meaning hasn't changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25850#issuecomment-2985586562 From aivanov at openjdk.org Wed Jun 18 20:29:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 18 Jun 2025 20:29:30 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v4] In-Reply-To: References: <2e8UF6GWbEa5P94W_BUk_JSk_UXMv_C9vzKcQYoJwio=.aa619959-2e94-4b0c-8557-2460bcbc495c@github.com> Message-ID: On Wed, 18 Jun 2025 20:18:29 GMT, Phil Race wrote: >> test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 59: >> >>> 57: private static final String[] FONTS_WINDOWS = {"Myanmar Text", "Noto Sans Myanmar"}; >>> 58: private static final String[] FONTS_LINUX = {"Padauk", "Noto Sans Myanmar", "Myanmar Text"}; >>> 59: private static final String[] FONTS_MACOS = {"Myanmar MN", "Noto Sans Myanmar", "Myanmar Text"}; >> >> I'm unsure if Noto Sans fonts are installed by default on Windows or macOS. >> >> Similarly, "Myanmar Text" is unlikely to be installed on Linux. >> >> Since there's a list of possible fonts, the list could well be *platform-independent* ? just look for a first match. > > My comment was ONLY about Linux. I definitely didn't expect to see the fonts for other platforms updated. > They can be a list of one font. That's how I read your suggestion too. Yet I like the idea of a platform-independent list of fonts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2155436504 From prr at openjdk.org Wed Jun 18 20:36:27 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 20:36:27 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: Message-ID: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> On Tue, 17 Jun 2025 12:43:23 GMT, Prasanta Sadhukhan wrote: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". This may yet need a CSR depending on where the wording ends up. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1033: > 1031: /** > 1032: * Gets the allocation to give the root View. > 1033: * The Rectangle returned has nothing to do with visibility but "nothing to do with" -> "unrelated to" But what I'd really like to see is an explanation of what the return from this method ACTUALLY means / is used for. What does "the allocation" mean ? Too woolly for me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25850#issuecomment-2985613082 PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2155444301 From prr at openjdk.org Wed Jun 18 20:40:29 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 20:40:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 14:45:32 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460: > >> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler >> 459: SliderDemo.majorticks=Grobteilungen >> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen > > Should the translation of `SliderDemo.majorticks` also be updated? I agree. I'd expect consistency here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155451453 From prr at openjdk.org Wed Jun 18 20:43:30 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 20:43:30 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski wrote: > Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. > > I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2940598911 From prr at openjdk.org Wed Jun 18 20:45:34 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 20:45:34 GMT Subject: RFR: 8355904: Use variadic macros for J2dTrace [v7] In-Reply-To: References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> Message-ID: <_calldKusYB1pBRvGq6_Q0pNJDhZZabJ_6-ORfwyqUk=.33ec5d91-fc34-4349-8588-a70846a5e09d@github.com> On Fri, 6 Jun 2025 08:36:40 GMT, Nikita Gubarkov wrote: >> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead. >> >> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style. > > Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8355904 > - Update D3DShaderGen.c > - fixup! 8355904: Use variadic macros for J2dTrace > - fixup! 8355904: Use variadic macros for J2dTrace > - fixup! 8355904: Use variadic macros for J2dTrace > - Apply suggestions from code review > > Co-authored-by: Alexey Ivanov > - fixup! 8355904: Use variadic macros for J2dTrace > - 8355904: Use variadic macros for J2dTrace Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24949#pullrequestreview-2940603838 From aturbanov at openjdk.org Wed Jun 18 21:01:33 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 18 Jun 2025 21:01:33 GMT Subject: Integrated: 8357686: Remove unnecessary Map.get from AWTAutoShutdown.unregisterPeer In-Reply-To: References: Message-ID: On Thu, 24 Apr 2025 20:18:01 GMT, Andrey Turbanov wrote: > Instead of separate `.get(Key)`+`.remove(Key)` calls we can call `.remove(Key, Value)`. > `peerMap` is an `IdentityHashMap`. IdentityHashMap.remove compares values with == since Java 20 ([JDK-8178355](https://bugs.openjdk.org/browse/JDK-8178355)) This pull request has now been integrated. Changeset: 5a62e995 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/5a62e99523904e89caf561d4c1068c1565a97450 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8357686: Remove unnecessary Map.get from AWTAutoShutdown.unregisterPeer Reviewed-by: serb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/24858 From prr at openjdk.org Wed Jun 18 21:24:33 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 21:24:33 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v26] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <646Z36-0EEtGu9wFEZE4n8SwmazfA3duCT4dAWOh8PI=.6e4cfed1-5224-4f60-8ed6-928905a7077c@github.com> On Wed, 28 May 2025 05:47:06 GMT, Prasanta Sadhukhan wrote: > In SwingSet2, now there will be gap between bullet and text to accomodate non-existing imageicon That gap should only be there if *at least one* menu item has an image icon. It shoudn't be there if none have an icon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2985729661 From serb at openjdk.org Wed Jun 18 22:06:27 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 18 Jun 2025 22:06:27 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski wrote: > Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. > > I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2940808857 From prr at openjdk.org Wed Jun 18 22:27:31 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 22:27:31 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v9] In-Reply-To: References: Message-ID: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> On Tue, 17 Jun 2025 10:08:49 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > SUmmary fix src/java.desktop/share/classes/javax/swing/ImageIcon.java line 232: > 230: Object o = image.getProperty("comment", imageObserver); > 231: if (o instanceof String) { > 232: description = (String) o; Hmm. This is wasted work if the app calls ImageIcon(Image, String) because that promptly over-writes whatever was obtained via this code. Also that other constructor (which github won't let me comment on) installs the description even if the image is null. That seems to be inconsistent with everything else that has a null description for a null image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155610976 From prr at openjdk.org Wed Jun 18 22:27:32 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 22:27:32 GMT Subject: RFR: 8159055: ImageIcon setImage and constructor can't handle null parameter [v9] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:38:22 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> SUmmary fix > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 374: > >> 372: /** >> 373: * Sets the image displayed by this icon. >> 374: * Setting a {@code null} image will not render any image icon. > > Suggestion: > > * Setting a {@code null} image renders no icon. > > I think this is better: it's shorter, it uses the present tense because it's fact and it doesn't depend on anything. I think the existing text was OK. And "will" is better because it hasn't happened yet. Rendering will happen later. Not when you construct this object. My personally preferred wording would be something like Setting a {@code null} image means any existing image will be removed and no image will be rendered. Now .. what should happen to an existing description when you set a new image ? Apps can call setDescription() but in what order ? The only thing I can say here is that I think if the image is null we probably should clear the description. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155602006 From prr at openjdk.org Wed Jun 18 22:30:27 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 18 Jun 2025 22:30:27 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: <7msLzwvMwfJkPqTL23_V0Wx2w_1Y13CxTFnDbfV9zOk=.1ac1dac7-1f43-4d23-abdc-42a63ddab6cf@github.com> References: <7msLzwvMwfJkPqTL23_V0Wx2w_1Y13CxTFnDbfV9zOk=.1ac1dac7-1f43-4d23-abdc-42a63ddab6cf@github.com> Message-ID: On Wed, 18 Jun 2025 18:34:32 GMT, Alexey Ivanov wrote: > Should each constructor specify how the message returned by `getMessage` is constructed instead of _directing to the specification of `getMessage` for details_? 100% no. I am not wasting time on that. This whole spec. is getting revamped again in JDK 26 in very short order after this minimal fix is backported to JDK 25 > src/java.desktop/share/classes/java/awt/HeadlessException.java line 56: > >> 54: * For such {@code HeadlessException} the default headless error message >> 55: * may be auto-generated for some platforms. >> 56: * The text of the default headless message may depend on > > This doesn't align, the following text has to be modified too. > > The first sentence of the second paragraph, ?For such `{@code HeadlessException}` the default headless error message may be auto-generated for some platforms,? should be replaced with the slightly edited text from the `HeadlessException(String)` constructor: ?For some platforms, the `{@code null}` detail message may be replaced with the default headless error message.? I don't see why. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25881#issuecomment-2985884731 PR Review Comment: https://git.openjdk.org/jdk/pull/25881#discussion_r2155631076 From serb at openjdk.org Wed Jun 18 22:31:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 18 Jun 2025 22:31:30 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 19:28:18 GMT, Damon Nguyen wrote: > Compilation error on windows with `WindowsButtonUI` used. Replaced it with `BasicButtonUI` to maintain overriding the `paintText` method but this was not the same as Windows L&F buttons. I attempted to import `WindowsButtonUI` and extending it, but the class is `final`. Instead, I chose to add a LineBorder in the same way as when a Rectangle was drawn to keep the same test behavior. It seems the extra 1 pixel width is unnecessary now when testing, so the changes only include removing `MyButtonUI` and adding a LineBorder. Please confirm that you can reproduce JDK-4991587 by the updated test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25883#issuecomment-2985890870 From dnguyen at openjdk.org Wed Jun 18 22:55:12 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 18 Jun 2025 22:55:12 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v10] In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Additional review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25705/files - new: https://git.openjdk.org/jdk/pull/25705/files/da207f30..7c852156 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25705&range=08-09 Stats: 18 lines in 1 file changed: 7 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25705/head:pull/25705 PR: https://git.openjdk.org/jdk/pull/25705 From dnguyen at openjdk.org Wed Jun 18 22:55:12 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 18 Jun 2025 22:55:12 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: <1MzKmGwV4zAOAKLmqpp_sDfUJ2yKCGvkjEQi2UkJ1R4=.b2846225-95d7-446a-8009-6b6518136545@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <1MzKmGwV4zAOAKLmqpp_sDfUJ2yKCGvkjEQi2UkJ1R4=.b2846225-95d7-446a-8009-6b6518136545@github.com> Message-ID: On Wed, 18 Jun 2025 19:20:32 GMT, Alexey Ivanov wrote: >The timer updates each second, which sends additional messages ? the dragged cursor changes as soon as the displayed time updates. > > Pause the timer, and the drag cursor doesn't change until you release the left mouse button. > > Harshitha was close to discovering it. That makes a lot of sense. I saw your updates on that issue as well. I guess we can use this workaround in this niche case if necessary. Thanks @aivanov-jdk and @honkar-jdk for your help in looking into this! > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 46: > >> 44: static Frame instructionsFrame; >> 45: private static final CountDownLatch countDownLatch = new CountDownLatch(1); >> 46: static String INSTRUCTIONS = """ > > I'd place the fields in this order: > > > INSTRUCTIONS > > testFrame > instructionsFrame > > countDownLatch > > > The blank lines are explicit for the code, too. This way the fields come in groups: the instructions describe what the tester will do, so it's reasonable to put them at the top, and this aligns to the most common way in manual tests; then go the two frames of the test; the latch which controls the test follows. > > Personally, I'd also declare all of them `private`. Implemented and noted! > test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 114: > >> 112: Panel btnPanel = new Panel(); >> 113: Button passBtn = new Button("PASS"); >> 114: Button failBtn = new Button("FAIL"); > > Suggestion: > > Button passBtn = new Button("Pass"); > Button failBtn = new Button("Fail"); > > Title case is good enough. I thought I updated this already. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25705#issuecomment-2985950371 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155664742 PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155657589 From dnguyen at openjdk.org Wed Jun 18 22:55:12 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 18 Jun 2025 22:55:12 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: <0jUkeeMbe6IjqpMi3yMRnDj9htjrKIFDQNG0v3ueJMI=.f778512b-fc63-44cc-b57b-6e6842117f45@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <0jUkeeMbe6IjqpMi3yMRnDj9htjrKIFDQNG0v3ueJMI=.f778512b-fc63-44cc-b57b-6e6842117f45@github.com> Message-ID: On Wed, 18 Jun 2025 19:16:09 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/Cursor/CursorDragTest/ListDragCursor.java line 123: >> >>> 121: failBtn.addActionListener(e -> { >>> 122: throw new RuntimeException("Test Failed"); >>> 123: }); >> >> You have to release the latch, otherwise the test doesn't exit if it's run without jtreg. > > Good point. Missed it since I ran it as jtreg test. Moved the pass message into the passBtn listener. Added `countDown` to the failBtn to release the latch. Tested it with and without jtreg and it works now. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25705#discussion_r2155660041 From dnguyen at openjdk.org Wed Jun 18 22:55:27 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 18 Jun 2025 22:55:27 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 22:28:46 GMT, Sergey Bylokhov wrote: > Please confirm that you can reproduce JDK-4991587 by the updated test. The updated test does contain all of the text within the blue border now as expected (instead of overlapping or being outside the borders of the textRect, as described in the original issue). I have updated the summary to this PR as well. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25883#issuecomment-2985954660 From serb at openjdk.org Thu Jun 19 00:39:26 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 19 Jun 2025 00:39:26 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 19:28:18 GMT, Damon Nguyen wrote: > Compilation error on windows with `WindowsButtonUI` used. Replaced it with `BasicButtonUI` to maintain overriding the `paintText` method but this was not the same as Windows L&F buttons. I attempted to import `WindowsButtonUI` and extending it, but the class is `final`. Instead, I chose to add a LineBorder in the same way as when a Rectangle was drawn to keep the same test behavior. It seems the extra 1 pixel width is unnecessary now when testing, so the changes only include removing `MyButtonUI` and adding a LineBorder. > > This updated test now compiles and runs as expected. The test has all of the text within the blue button border. There does not seem to be any overlapping or out of bounds text as originally described with the original test. You could also take this opportunity to automate the test. I believe it should be possible to verify that the border is not distorted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25883#issuecomment-2986139755 From honkar at openjdk.org Thu Jun 19 00:42:33 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 19 Jun 2025 00:42:33 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v10] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <9wiO9gjaY9AKroKNQBX2Q-MMavzUk46MDkkq0pUfxoE=.1cc579e6-6d3b-4113-82ce-011947a032fe@github.com> On Wed, 18 Jun 2025 22:55:12 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Additional review comments. Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25705#pullrequestreview-2941102617 From honkar at openjdk.org Thu Jun 19 00:53:33 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 19 Jun 2025 00:53:33 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v9] In-Reply-To: <1MzKmGwV4zAOAKLmqpp_sDfUJ2yKCGvkjEQi2UkJ1R4=.b2846225-95d7-446a-8009-6b6518136545@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> <1MzKmGwV4zAOAKLmqpp_sDfUJ2yKCGvkjEQi2UkJ1R4=.b2846225-95d7-446a-8009-6b6518136545@github.com> Message-ID: On Wed, 18 Jun 2025 19:20:32 GMT, Alexey Ivanov wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Change timeout and instructions columns. > > **Funny!** > >> The Windows test failing in PFJ was a separate issue that was found through this update. > > You submitted [JDK-8359469](https://bugs.openjdk.org/browse/JDK-8359469) to find the problem? What `PassFailJFrame` has in addition to a static frame that doesn't display anything is a **timer**. The timer updates each second, which sends additional messages ? the dragged cursor changes as soon as the displayed time updates. > > Pause the timer, and the drag cursor doesn't change until you release the left mouse button. > > Harshitha was close to discovering it. @aivanov-jdk > What PassFailJFrame has in addition to a static frame that doesn't display anything is a timer. The timer updates each second, which sends additional messages ? the dragged cursor changes as soon as the displayed time updates. > > Pause the timer, and the drag cursor doesn't change until you release the left mouse button Nice find ! Finally an answer to the strange behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25705#issuecomment-2986166545 From serb at openjdk.org Thu Jun 19 01:09:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 19 Jun 2025 01:09:15 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice Message-ID: This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. Notes: GraphicsDevice provides two methods for handling full-screen windows: - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. ------------- Commit messages: - Create FullScreenWindowRace.java - 8359266: Delete the usage of AppContext in the GraphicsDevice Changes: https://git.openjdk.org/jdk/pull/25818/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25818&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359266 Stats: 93 lines in 2 files changed: 65 ins; 23 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25818/head:pull/25818 PR: https://git.openjdk.org/jdk/pull/25818 From psadhukhan at openjdk.org Thu Jun 19 02:38:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 02:38:10 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v2] In-Reply-To: References: Message-ID: > RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. > Modified the color so that they are visible.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Window L&F fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25864/files - new: https://git.openjdk.org/jdk/pull/25864/files/57eb73ff..92aed6eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25864&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25864&range=00-01 Stats: 23 lines in 1 file changed: 18 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25864.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25864/head:pull/25864 PR: https://git.openjdk.org/jdk/pull/25864 From psadhukhan at openjdk.org Thu Jun 19 02:38:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 02:38:10 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:31:53 GMT, Tejesh R wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Window L&F fix > > test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 192: > >> 190: >> 191: b.setOpaque(true); >> 192: b.setBackground(Color.red); > > The test is specifically for background color black, I think you need to retain background color. The original issue JDK-4449413 was for JCheckBox for black background in MetalLookAndFeel when not using OceanTheme..There was no issue found for JRadioButton, JCheckboxMenuItem, JRadioButtonMenuItem... JDK-8075915 found issue with other L&F where it fails with "NullPointerException: Can't have null theme" because "Default Metal Theme" is not present in other L&F so initially it was set explicitly to MetalL&F but later setOpaque was added and explicit MetalL&F was removed but there was an issue with WindowL&F which was overlooked and it can be seen in the screenshot pasted in that review. So, either we can set explicit Metal L&F but I have chosen to allow other L&F with gray background for WIndows L&F (only for RB and CB MenuItem) which is because for these 2 widgets, WIndowsL&F uses [skin](https://github.com/openjdk/jdk/blob/ba32b78bfaf83f69003f83333ab6975b35343fde/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L904-L912) which is pre-formatted to black and cannot be color-changed based on foreground/background ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25864#discussion_r2155926707 From psadhukhan at openjdk.org Thu Jun 19 03:01:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 03:01:16 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v9] In-Reply-To: References: Message-ID: <_D4PPSxvarco1pXyzwcsMTlX12s76K7GkLUrauQw3rQ=.19f46011-41d2-4828-a3dc-2a2911e4b13b@github.com> On Wed, 18 Jun 2025 22:18:45 GMT, Phil Race wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 374: >> >>> 372: /** >>> 373: * Sets the image displayed by this icon. >>> 374: * Setting a {@code null} image will not render any image icon. >> >> Suggestion: >> >> * Setting a {@code null} image renders no icon. >> >> I think this is better: it's shorter, it uses the present tense because it's fact and it doesn't depend on anything. > > I think the existing text was OK. And "will" is better because it hasn't happened yet. > Rendering will happen later. Not when you construct this object. > My personally preferred wording would be something like > Setting a {@code null} image means any existing image will be removed and no image will be rendered. > > Now .. what should happen to an existing description when you set a new image ? > > Apps can call setDescription() but in what order ? > > The only thing I can say here is that I think if the image is null we probably should clear the description. I have modified the wording as per suggestion and also clearing the description now if image is null.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2155944533 From psadhukhan at openjdk.org Thu Jun 19 03:01:15 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 03:01:15 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Test fix - javadoc wording..clear image desscription if image is null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/8e1938b6..f6237741 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=08-09 Stats: 16 lines in 2 files changed: 11 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From mvs at openjdk.org Thu Jun 19 03:42:21 2025 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 19 Jun 2025 03:42:21 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v5] In-Reply-To: References: Message-ID: > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Combined the fonts in to one list, formatting changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25879/files - new: https://git.openjdk.org/jdk/pull/25879/files/bdc40569..b5a3f894 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=03-04 Stats: 38 lines in 1 file changed: 2 ins; 23 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/25879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25879/head:pull/25879 PR: https://git.openjdk.org/jdk/pull/25879 From mvs at openjdk.org Thu Jun 19 03:42:21 2025 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 19 Jun 2025 03:42:21 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v4] In-Reply-To: References: <2e8UF6GWbEa5P94W_BUk_JSk_UXMv_C9vzKcQYoJwio=.aa619959-2e94-4b0c-8557-2460bcbc495c@github.com> Message-ID: On Wed, 18 Jun 2025 20:26:51 GMT, Alexey Ivanov wrote: >> My comment was ONLY about Linux. I definitely didn't expect to see the fonts for other platforms updated. >> They can be a list of one font. > > That's how I read your suggestion too. > > Yet I like the idea of a platform-independent list of fonts. Combined all the fonts in to one list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2156018484 From tr at openjdk.org Thu Jun 19 04:01:33 2025 From: tr at openjdk.org (Tejesh R) Date: Thu, 19 Jun 2025 04:01:33 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 02:38:10 GMT, Prasanta Sadhukhan wrote: >> RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. >> Modified the color so that they are visible.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Window L&F fix Can remove `@author` jtreg tag. Can use PassFailJFrame. ------------- PR Review: https://git.openjdk.org/jdk/pull/25864#pullrequestreview-2941468394 PR Review: https://git.openjdk.org/jdk/pull/25864#pullrequestreview-2941470004 From tr at openjdk.org Thu Jun 19 04:01:34 2025 From: tr at openjdk.org (Tejesh R) Date: Thu, 19 Jun 2025 04:01:34 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 02:34:22 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JCheckBox/4449413/bug4449413.java line 192: >> >>> 190: >>> 191: b.setOpaque(true); >>> 192: b.setBackground(Color.red); >> >> The test is specifically for background color black, I think you need to retain background color. > > The original issue JDK-4449413 was for JCheckBox for black background in MetalLookAndFeel when not using OceanTheme..There was no issue found for JRadioButton, JCheckboxMenuItem, JRadioButtonMenuItem... > > JDK-8075915 found issue with other L&F where it fails with "NullPointerException: Can't have null theme" because "Default Metal Theme" is not present in other L&F so initially it was set explicitly to MetalL&F but later setOpaque was added and explicit MetalL&F was removed but there was an issue with WindowL&F which was overlooked and it can be seen in the screenshot pasted in that review. > > So, either we can set explicit Metal L&F > but I have chosen to allow other L&F with gray background for WIndows L&F (only for RB and CB MenuItem) which is because for these 2 widgets, WIndowsL&F uses [skin](https://github.com/openjdk/jdk/blob/ba32b78bfaf83f69003f83333ab6975b35343fde/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L904-L912) which is pre-formatted to black and cannot be color-changed based on foreground/background Ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25864#discussion_r2156047549 From psadhukhan at openjdk.org Thu Jun 19 04:06:18 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 04:06:18 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Wed, 18 Jun 2025 20:32:26 GMT, Phil Race wrote: >> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1033: > >> 1031: /** >> 1032: * Gets the allocation to give the root View. >> 1033: * The Rectangle returned has nothing to do with visibility but > > "nothing to do with" -> "unrelated to" > > > But what I'd really like to see is an explanation of what the return from this method ACTUALLY means / is used for. > What does "the allocation" mean ? Too woolly for me. getVisibleEditorRect() return the bounds of the text editor and the return value is used to to set-size/paint the `javax.swing.text.View` of this text editor component. "the allocation" refers to what allocated area the view needs to paint, it seems to be a common phrase used in context of View class which says > "The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with. " In that regard, probably getAllocatedViewRect() would have been better choice of the method name ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2156050700 From psadhukhan at openjdk.org Thu Jun 19 04:06:18 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 04:06:18 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Thu, 19 Jun 2025 04:01:49 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1033: >> >>> 1031: /** >>> 1032: * Gets the allocation to give the root View. >>> 1033: * The Rectangle returned has nothing to do with visibility but >> >> "nothing to do with" -> "unrelated to" >> >> >> But what I'd really like to see is an explanation of what the return from this method ACTUALLY means / is used for. >> What does "the allocation" mean ? Too woolly for me. > > getVisibleEditorRect() return the bounds of the text editor and the return value is used to to set-size/paint the > `javax.swing.text.View` of this text editor component. > "the allocation" refers to what allocated area the view needs to paint, it seems to be a common phrase used in context of View class which says > >> "The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with. " > > In that regard, probably getAllocatedViewRect() would have been better choice of the method name getVisibleEditorRect() return the bounds of the text editor and the return value is used to to set-size/paint the `javax.swing.text.View` of this text editor component. "the allocation" refers to what allocated area the view needs to paint, it seems to be a common phrase used in context of View class which says > "The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with. " In that regard, probably getAllocatedViewRect() would have been better choice of the method name ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2156051371 From psadhukhan at openjdk.org Thu Jun 19 04:10:20 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 04:10:20 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v3] In-Reply-To: References: Message-ID: > RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. > Modified the color so that they are visible.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Remove author tag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25864/files - new: https://git.openjdk.org/jdk/pull/25864/files/92aed6eb..d00892d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25864&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25864&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25864.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25864/head:pull/25864 PR: https://git.openjdk.org/jdk/pull/25864 From psadhukhan at openjdk.org Thu Jun 19 04:10:20 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 04:10:20 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 02:38:10 GMT, Prasanta Sadhukhan wrote: >> RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. >> Modified the color so that they are visible.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Window L&F fix author tag removed..PFJ not required for this time, want to limit this for the fix only.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25864#issuecomment-2986529044 From duke at openjdk.org Thu Jun 19 04:16:34 2025 From: duke at openjdk.org (ExE Boss) Date: Thu, 19 Jun 2025 04:16:34 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 03:01:15 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Test fix > - javadoc wording..clear image desscription if image is null These?are not?needed as?the?initial?value of?`description` is?`null`: src/java.desktop/share/classes/javax/swing/ImageIcon.java line 147: > 145: image = Toolkit.getDefaultToolkit().getImage(filename); > 146: if (image == null) { > 147: this.description = null; Suggestion: src/java.desktop/share/classes/javax/swing/ImageIcon.java line 187: > 185: image = Toolkit.getDefaultToolkit().getImage(location); > 186: if (image == null) { > 187: this.description = null; Suggestion: src/java.desktop/share/classes/javax/swing/ImageIcon.java line 232: > 230: this.image = image; > 231: if (image == null) { > 232: this.description = null; Suggestion: src/java.desktop/share/classes/javax/swing/ImageIcon.java line 258: > 256: this.image = Toolkit.getDefaultToolkit().createImage(imageData); > 257: if (image == null) { > 258: this.description = null; Suggestion: src/java.desktop/share/classes/javax/swing/ImageIcon.java line 284: > 282: this.image = Toolkit.getDefaultToolkit().createImage(imageData); > 283: if (image == null) { > 284: this.description = null; Suggestion: ------------- PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2941485697 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156059910 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156059678 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156059447 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156059116 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156059228 From psadhukhan at openjdk.org Thu Jun 19 04:38:01 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 04:38:01 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 04:12:25 GMT, ExE Boss wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Test fix >> - javadoc wording..clear image desscription if image is null > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 147: > >> 145: image = Toolkit.getDefaultToolkit().getImage(filename); >> 146: if (image == null) { >> 147: this.description = null; > > Suggestion: We dont know the exact order of setDescription call..If that is called before setImage or constructor (unlikely but can be called), the description would not be null, so it's better to clear the description for null image to be safe.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156090007 From tr at openjdk.org Thu Jun 19 05:43:55 2025 From: tr at openjdk.org (Tejesh R) Date: Thu, 19 Jun 2025 05:43:55 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v3] In-Reply-To: References: Message-ID: <-ZQ_bnZdDABU4vFwQcASB5W7b_eMVYFWNRKX4iZXgaQ=.2cefcc1d-9f3a-4591-91d2-fb8c280f428e@github.com> On Thu, 19 Jun 2025 04:10:20 GMT, Prasanta Sadhukhan wrote: >> RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. >> Modified the color so that they are visible.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove author tag LGTM ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25864#pullrequestreview-2941629669 From psadhukhan at openjdk.org Thu Jun 19 06:09:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 06:09:41 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v26] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Wed, 28 May 2025 05:38:17 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Text alignment fix > > In SwingSet2, now there will be gap between bullet and text to accomodate non-existing imageicon > > That gap should only be there if _at least one_ menu item has an image icon. It shoudn't be there if none have an icon. That will require to find out if current menuItem is part of ButtonGroup and then reiterate each menuitems of the ButtonGroup and see if anyone has an imageicon..It does not seem possible to find out from current menuItem if it part of ButtonGroup as that info is not passed to each MenuItemUI (ButtonGroup info is only known to application/user) Also, assuming if we do find a way to get if this menuItem is part of a ButtonGroup, then iterating everytime to find out if any menu item has imageicon will affect performance. Probably it's better to reserve space for imageicon even if not present.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2986746474 From aturbanov at openjdk.org Thu Jun 19 07:34:44 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 19 Jun 2025 07:34:44 GMT Subject: RFR: 8357687: Remove unnecessary Map.containsKey from GraphicsEnvironment implementations In-Reply-To: <1nYamt71cfy9hTc1IsaAjrMFQmP4EBMPW2pdHm4KHhk=.63abbeb6-6b90-4dfc-a166-e326c86cd228@github.com> References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com> <1nYamt71cfy9hTc1IsaAjrMFQmP4EBMPW2pdHm4KHhk=.63abbeb6-6b90-4dfc-a166-e326c86cd228@github.com> Message-ID: On Thu, 29 May 2025 22:21:12 GMT, Phil Race wrote: >it is one succinct line But it's not one line - it's 2 lines https://github.com/openjdk/jdk/blob/08b1fa4cb39e56497052e3ee13e679c8734cf7c5/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java#L174-L175 >there is nothing wrong with it When I see `.containsKey` + `.get` instead of single `.get` - I always question: is this map can contain `null` values? (Because it's the only reason why I can choose to have separate `.containsKey` call). So, it's always makes _reading_ code require a bit more brain activity, than it should be. When we use `.get` + null check - it's more _obvious_ that we expect only non-null values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24907#issuecomment-2987027909 From aturbanov at openjdk.org Thu Jun 19 07:38:55 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 19 Jun 2025 07:38:55 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove Message-ID: No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. `eventsList` is an ArrayList. ------------- Commit messages: - [PATCH] Remove unnecessary List.indexOf key from Track.remove Changes: https://git.openjdk.org/jdk/pull/24818/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24818&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359996 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24818/head:pull/24818 PR: https://git.openjdk.org/jdk/pull/24818 From duke at openjdk.org Thu Jun 19 07:38:56 2025 From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac) Date: Thu, 19 Jun 2025 07:38:56 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove In-Reply-To: References: Message-ID: <3-HOByltbViqB8Pel99peTImR6psDZMw0l15ywzJFXc=.d6f16a2a-92c5-448e-b875-e77c576921f3@github.com> On Wed, 23 Apr 2025 17:26:38 GMT, Chen Liang wrote: >> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. >> `eventsList` is an ArrayList. > > src/java.desktop/share/classes/javax/sound/midi/Track.java line 202: > >> 200: synchronized(eventsList) { >> 201: if (set.remove(event)) { >> 202: if (eventsList.remove(event)) { > > Can be rewritten as `if (set.remove(event) && eventsList.remove(event))`. `return set.remove(event) && eventsList.remove(event);` even... And remove the return statement coming after ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24818#discussion_r2130352907 From liach at openjdk.org Thu Jun 19 07:38:55 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 19 Jun 2025 07:38:55 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 08:53:57 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. > `eventsList` is an ArrayList. src/java.desktop/share/classes/javax/sound/midi/Track.java line 202: > 200: synchronized(eventsList) { > 201: if (set.remove(event)) { > 202: if (eventsList.remove(event)) { Can be rewritten as `if (set.remove(event) && eventsList.remove(event))`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24818#discussion_r2056560123 From psadhukhan at openjdk.org Thu Jun 19 08:23:19 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 19 Jun 2025 08:23:19 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF Message-ID: There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY)..... Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead No regression test as it can be verified through SwingSet2 demo as below.. With ctrl+shift+down Screenshot 2025-06-19 at 1 41 39?PM another ctrl+shift+down Screenshot 2025-06-19 at 1 42 39?PM Now, ctrl+shift+up Screenshot 2025-06-19 at 1 44 51?PM ------------- Commit messages: - Add shortcut Changes: https://git.openjdk.org/jdk/pull/25892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8008222 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25892/head:pull/25892 PR: https://git.openjdk.org/jdk/pull/25892 From smandalika at openjdk.org Thu Jun 19 08:45:09 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 08:45:09 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v3] In-Reply-To: References: Message-ID: <7yI_O4XC-MY-k_PLmDAHh63ZQWIbQU-ksfJr482WJDI=.2df42e17-8a02-4124-b6a5-8b4fdc5101d6@github.com> > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: - Review Feedback: Tweaked instructions,exception message,Removed title,row calls,Common method for DialogTypeSelection - Review Feedback: Tweaked instructions,exception message,Removed title,row calls,Common method for DialogTypeSelection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/223c0e11..ce433368 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=01-02 Stats: 17 lines in 1 file changed: 5 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From smandalika at openjdk.org Thu Jun 19 08:47:42 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 08:47:42 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:42:05 GMT, Abhishek Kumar wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Added SkippedException when Printer is unavailable. > > test/jdk/java/awt/print/Dialog/DialogType.java line 47: > >> 45: >> 46: private static final String INSTRUCTIONS = """ >> 47: This test assumes and requires that you have a printer installed > > Suggestion: > > This test assumes and requires that you have a printer installed. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156480815 From smandalika at openjdk.org Thu Jun 19 08:51:31 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 08:51:31 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:45:53 GMT, Abhishek Kumar wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Added SkippedException when Printer is unavailable. > > test/jdk/java/awt/print/Dialog/DialogType.java line 53: > >> 51: The test passes as long as no exceptions are thrown, *AND* >> 52: if running on Windows only, the first dialog is a native windows >> 53: control which differs in appearance from the second dialog > > Suggestion: > > The test passes as long as no exceptions are thrown. > > Platform specific instructions can be added as a NOTE. It would be better if it is mentioned at the start of instruction. > > The first and second dialog differs on MacOS as well. Not checked on Linux. > > Current instruction says only about Windows, better to verify and modify the instruction. Reconfirmed by testing on Mac OS and Linux as well - both of these have different dialogs for first and second. As suggested, added a note. But I have added it at the end as it seemed to be better to first step through the instructions and then give an OS specific context for those instructions. > test/jdk/java/awt/print/Dialog/DialogType.java line 62: > >> 60: } >> 61: PassFailJFrame passFailJFrame = PassFailJFrame.builder() >> 62: .title("DialogType Test Instructions") > > Default title is : "File name" followed by " - Test Instructions" > Title can be removed. Removed. > test/jdk/java/awt/print/Dialog/DialogType.java line 64: > >> 62: .title("DialogType Test Instructions") >> 63: .instructions(INSTRUCTIONS) >> 64: .rows((int)INSTRUCTIONS.lines().count() + 2) > > No need to set `rows` explicitly. Removed. > test/jdk/java/awt/print/Dialog/DialogType.java line 84: > >> 82: for (int i = 0; i < attrs.length; i++) { >> 83: System.out.println(attrs[i]); >> 84: } > > Move the duplicate code to helper method Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156486862 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156487908 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156487570 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156488310 From smandalika at openjdk.org Thu Jun 19 08:51:32 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 08:51:32 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:54:40 GMT, Tejesh R wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Added SkippedException when Printer is unavailable. > > test/jdk/java/awt/print/Dialog/DialogType.java line 64: > >> 62: .title("DialogType Test Instructions") >> 63: .instructions(INSTRUCTIONS) >> 64: .rows((int)INSTRUCTIONS.lines().count() + 2) > > Not required. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156488693 From smandalika at openjdk.org Thu Jun 19 08:55:32 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 08:55:32 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: <2n4De7GgHCAXdPWp2f_GSm7tWSgJWn_if5pMfjb0U58=.3410db14-a6c2-481c-a996-e071a944cb5b@github.com> On Wed, 18 Jun 2025 05:58:22 GMT, Tejesh R wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Added SkippedException when Printer is unavailable. > > test/jdk/java/awt/print/Dialog/DialogType.java line 52: > >> 50: Two dialogs are shown in succession. >> 51: The test passes as long as no exceptions are thrown, *AND* >> 52: if running on Windows only, the first dialog is a native windows > > Windows specific can be as note or even you can append it to instructions on Windows OS check condition. Reconfirmed by testing on Mac OS and Linux as well - both of these have different dialogs for first and second. As suggested, added a note. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156494972 From smandalika at openjdk.org Thu Jun 19 09:02:11 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 09:02:11 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:46:14 GMT, Abhishek Kumar wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Added SkippedException when Printer is unavailable. > > test/jdk/java/awt/print/Dialog/DialogType.java line 59: > >> 57: job = PrinterJob.getPrinterJob(); >> 58: if (job.getPrintService() == null) { >> 59: throw new SkippedException("Printer not configured or not available"); > > Suggestion: > > throw new SkippedException("Test Skipped, Printer not configured or not available"); Done with a minor tweak throw new SkippedException("Test skipped, printer is unavailable"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156503727 From smandalika at openjdk.org Thu Jun 19 09:02:16 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 09:02:16 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 05:54:30 GMT, Tejesh R wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Added SkippedException when Printer is unavailable. > > test/jdk/java/awt/print/Dialog/DialogType.java line 62: > >> 60: } >> 61: PassFailJFrame passFailJFrame = PassFailJFrame.builder() >> 62: .title("DialogType Test Instructions") > > Not required. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156508816 From smandalika at openjdk.org Thu Jun 19 09:15:08 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Thu, 19 Jun 2025 09:15:08 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v4] In-Reply-To: References: Message-ID: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review Feedback: Instructions Update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/ce433368..f43ad7d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From aivanov at openjdk.org Thu Jun 19 09:22:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 09:22:29 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Thu, 19 Jun 2025 04:02:30 GMT, Prasanta Sadhukhan wrote: >> getVisibleEditorRect() return the bounds of the text editor and the return value is used to to set-size/paint the >> `javax.swing.text.View` of this text editor component. >> "the allocation" refers to what allocated area the view needs to paint, it seems to be a common phrase used in context of View class which says >> >>> "The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with. " >> >> In that regard, probably getAllocatedViewRect() would have been better choice of the method name > > getVisibleEditorRect() return the bounds of the text editor and the return value is used to to set-size/paint the > `javax.swing.text.View` of this text editor component. > "the allocation" refers to what allocated area the view needs to paint, it seems to be a common phrase used in context of View class which says > >> "The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with. " > > In that regard, probably getAllocatedViewRect() would have been better choice of the method name The term _allocation_ is commonly used in [javax.swing.text.View](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/text/View.html) and its subclasses, for example, The view gets its *allocation* from the parent at paint time, and While a view may render into its entire *allocation*, typically a view does not. (Emphasis mine.) The `View` class has a method [`getChildAllocation`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/text/View.html#getChildAllocation(int,java.awt.Shape)). Essentially, the allocation for text view means the **size and position** of the view. In this case, the returned rectangle is used an allocation for the root view to perform painting. https://github.com/openjdk/jdk/blob/0dce98b71648f270dca7395e7ab5451011b14b45/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java#L767-L771 I do **not** think this method should explain what the *allocation* means; it may point to the `View` class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2156547023 From aivanov at openjdk.org Thu Jun 19 09:28:49 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 09:28:49 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: <7msLzwvMwfJkPqTL23_V0Wx2w_1Y13CxTFnDbfV9zOk=.1ac1dac7-1f43-4d23-abdc-42a63ddab6cf@github.com> Message-ID: On Wed, 18 Jun 2025 22:26:46 GMT, Phil Race wrote: > > Should each constructor specify how the message returned by `getMessage` is constructed instead of _directing to the specification of `getMessage` for details_? > > 100% no. I am not wasting time on that. This whole spec. is getting revamped again in JDK 26 in very short order after this minimal fix is backported to JDK 25 I see, thank you for your clarification. So, this is a minimal update to the specification to quickly address the problem with `null` vs. *empty* message, which is being backported to JDK 25; the specification for JDK 26 is going to be overhauled shortly. Is my understanding correct now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25881#issuecomment-2987385598 From aivanov at openjdk.org Thu Jun 19 09:49:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 09:49:40 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 19:28:18 GMT, Damon Nguyen wrote: > Compilation error on windows with `WindowsButtonUI` used. Replaced it with `BasicButtonUI` to maintain overriding the `paintText` method but this was not the same as Windows L&F buttons. I attempted to import `WindowsButtonUI` and extending it, but the class is `final`. Instead, I chose to add a LineBorder in the same way as when a Rectangle was drawn to keep the same test behavior. It seems the extra 1 pixel width is unnecessary now when testing, so the changes only include removing `MyButtonUI` and adding a LineBorder. > > This updated test now compiles and runs as expected. The test has all of the text within the blue button border. There does not seem to be any overlapping or out of bounds text as originally described with the original test. test/jdk/javax/swing/plaf/windows/bug4991587.java line 83: > 81: } > 82: > 83: static class MyButtonUI extends WindowsButtonUI { Use composition here: extend `BasicButtonUI`, create a `WindowsButtonUI`? object and forward *all the methods*? to the instance of `WindowsButtonUI`. In the `paintText` method, draw the rectangle and then call the implementation of your `WindowsButtonUI`. ? Use `WindowsButtonUI.createUI` to create an instance. ? All the overridden methods in `WindowsButtonUI`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25883#discussion_r2156600650 From aivanov at openjdk.org Thu Jun 19 09:53:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 09:53:36 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 22:53:20 GMT, Damon Nguyen wrote: > > Please confirm that you can reproduce JDK-4991587 by the updated test. > > The updated test does contain all of the text within the blue border now as expected (instead of overlapping or being outside the borders of the textRect, as described in the original issue). I have updated the summary to this PR as well. Thanks! Did you run the test with Java 5 where [JDK-4991587](https://bugs.openjdk.org/browse/JDK-4991587) isn't fixed? I don't expect a border added to a button will reproduce the problem. I may be wrong. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25883#issuecomment-2987466683 From aivanov at openjdk.org Thu Jun 19 10:06:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 10:06:55 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v5] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 03:42:21 GMT, Manukumar V S wrote: >> Issue: >> MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. >> >> Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. >> >> Fix: >> Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. >> >> Testing: >> Tested using mach5 in all available platforms and got full PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Combined the fonts in to one list, formatting changes Changes requested by aivanov (Reviewer). test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 56: > 54: private static final String TEXT = "\u1000\u103C"; > 55: > 56: private static final String OS_NAME = System.getProperty("os.name").toLowerCase(); The OS name isn't needed any longer. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 63: > 61: "Myanmar Text", > 62: "Noto Sans Myanmar"); > 63: private static final String FONT_NAME = selectFontName(); Suggestion: "Noto Sans Myanmar"); private static final String FONT_NAME = selectFontName(); A blank line. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 76: > 74: System.err.println("Checked fonts: " + fontList); > 75: throw new SkippedException("Required fonts not installed for OS: " > 76: + OS_NAME + ". Checked fonts: " + fontList); Suggestion: throw new SkippedException("No suitable font found out of the list: " + String.join(", ", FONT_CANDIDATES)); I see no value in printing the same information twice, the exception message is *always* printed, and it contains all the required details. test/jdk/java/awt/font/TextLayout/MyanmarTextTest.java line 145: > 143: .filter(FONT_CANDIDATES::contains) > 144: .findFirst() > 145: .orElse(null); I'm for preserving the original wrapping style where `.` align: Suggestion: return Arrays.stream(GraphicsEnvironment .getLocalGraphicsEnvironment() .getAvailableFontFamilyNames()) .filter(FONT_CANDIDATES::contains) .findFirst() .orElse(null); ------------- PR Review: https://git.openjdk.org/jdk/pull/25879#pullrequestreview-2942345012 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2156613372 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2156614008 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2156624016 PR Review Comment: https://git.openjdk.org/jdk/pull/25879#discussion_r2156627677 From aivanov at openjdk.org Thu Jun 19 10:13:34 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 10:13:34 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v9] In-Reply-To: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> References: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> Message-ID: <3A5j30xOMedOYEwuO9Z6t4BxSOoA_NnDFi7mUW0o4Sk=.27d172ae-4921-490c-b503-4dcffb173ba2@github.com> On Wed, 18 Jun 2025 22:21:22 GMT, Phil Race wrote: > Also that other constructor (which github won't let me comment on) installs the description even if the image is null. I don't see it as a problem. If the app developer wants to initialise the object with `null` image and a description, why don't we let them do it? The image may be auto-generated and while it's generated, the image in `ImageIcon` remains `null`; when the image is read the app calls `ImageIcon.setImage` to the set now available image and *expects the description being preserved*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156636895 From serb at openjdk.org Thu Jun 19 10:13:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 19 Jun 2025 10:13:32 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 09:47:28 GMT, Alexey Ivanov wrote: >> Compilation error on windows with `WindowsButtonUI` used. Replaced it with `BasicButtonUI` to maintain overriding the `paintText` method but this was not the same as Windows L&F buttons. I attempted to import `WindowsButtonUI` and extending it, but the class is `final`. Instead, I chose to add a LineBorder in the same way as when a Rectangle was drawn to keep the same test behavior. It seems the extra 1 pixel width is unnecessary now when testing, so the changes only include removing `MyButtonUI` and adding a LineBorder. >> >> This updated test now compiles and runs as expected. The test has all of the text within the blue button border. There does not seem to be any overlapping or out of bounds text as originally described with the original test. > > test/jdk/javax/swing/plaf/windows/bug4991587.java line 83: > >> 81: } >> 82: >> 83: static class MyButtonUI extends WindowsButtonUI { > > Use composition here: extend `BasicButtonUI`, create a `WindowsButtonUI`? object and forward *all the methods*? to the instance of `WindowsButtonUI`. In the `paintText` method, draw the rectangle and then call the implementation of your `WindowsButtonUI`. > > ? Use `WindowsButtonUI.createUI` to create an instance. > ? All the overridden methods in `WindowsButtonUI`. It would be good if we could eliminate the reference to WindowsButtonUI. It might also be useful to check the behavior across all L&Fs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25883#discussion_r2156645107 From aivanov at openjdk.org Thu Jun 19 10:13:34 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 10:13:34 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v9] In-Reply-To: <3A5j30xOMedOYEwuO9Z6t4BxSOoA_NnDFi7mUW0o4Sk=.27d172ae-4921-490c-b503-4dcffb173ba2@github.com> References: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> <3A5j30xOMedOYEwuO9Z6t4BxSOoA_NnDFi7mUW0o4Sk=.27d172ae-4921-490c-b503-4dcffb173ba2@github.com> Message-ID: On Thu, 19 Jun 2025 10:06:17 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 232: >> >>> 230: Object o = image.getProperty("comment", imageObserver); >>> 231: if (o instanceof String) { >>> 232: description = (String) o; >> >> Hmm. This is wasted work if the app calls ImageIcon(Image, String) because that promptly over-writes whatever was obtained via this code. >> >> Also that other constructor (which github won't let me comment on) installs the description even if the image is null. >> That seems to be inconsistent with everything else that has a null description for a null image. > >> Also that other constructor (which github won't let me comment on) installs the description even if the image is null. > > I don't see it as a problem. > > If the app developer wants to initialise the object with `null` image and a description, why don't we let them do it? > > The image may be auto-generated and while it's generated, the image in `ImageIcon` remains `null`; when the image is read the app calls `ImageIcon.setImage` to the set now available image and *expects the description being preserved*. > Now .. what should happen to an existing description when you set a new image ? > > Apps can call setDescription() but in what order ? > > The only thing I can say here is that I think if the image is null we probably should clear the description. Nothing should happen to the description. These are two fields which can be changed independently now, why would we enforce an order on method calls? Changing the image shouldn't change the description; similarly, changing description doesn't change the image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156641174 From aivanov at openjdk.org Thu Jun 19 10:19:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 10:19:46 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 03:01:15 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Test fix > - javadoc wording..clear image desscription if image is null Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/ImageIcon.java line 147: > 145: image = Toolkit.getDefaultToolkit().getImage(filename); > 146: if (image == null) { > 147: this.description = null; I do not think we have to enforce setting `description` to `null` if the image is `null` ? **it is up to the developer to decide**. src/java.desktop/share/classes/javax/swing/ImageIcon.java line 222: > 220: * Setting a {@code null} image means > 221: * any existing image will be removed > 222: * and no image will be rendered. It doesn't apply to the constructor ? there ***can't** be an existing image*! src/java.desktop/share/classes/javax/swing/ImageIcon.java line 389: > 387: this.image = image; > 388: if (image == null) { > 389: this.description = null; We must not change the description. Why do we enforce resetting the description to `null`? The app is still free to change the description to an arbitrary value using `setDescription` even if the image is `null`. src/java.desktop/share/classes/javax/swing/ImageIcon.java line 391: > 389: this.description = null; > 390: return; > 391: } We must not change the description, but we should reset `width` and `height` to `-1`. Suggestion: width = -1; height = -1; return; } ------------- PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2942389792 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156647302 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156649370 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156652325 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156655243 From aivanov at openjdk.org Thu Jun 19 10:19:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 10:19:46 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 04:35:17 GMT, Prasanta Sadhukhan wrote: > We dont know the exact order of setDescription call.. What do you mean? It's a constructor, nothing else has been called on the instance yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2156644398 From aivanov at openjdk.org Thu Jun 19 10:26:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 10:26:35 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 10:10:46 GMT, Sergey Bylokhov wrote: > It would be good if we could eliminate the reference to WindowsButtonUI. But we want the regression to reproduce the original problem. The problem was specific to `WindowsButtonUI`, in `WindowsGraphicsUtils` according to comments in the bug. It may be impossible to reproduce the problem without referencing `WindowsButtonUI`. If it's possible, I'm all for it. > It might also be useful to check the behavior across all L&Fs. The bug was in Windows L&F, I don't think it's applicable to other L&F. On Windows, the disabled text was painted with ?shadow? with offset of (1, 1) which could be painted over another part of the button. Other L&Fs are free to paint the button differently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25883#discussion_r2156668056 From abhiscxk at openjdk.org Thu Jun 19 10:31:31 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 19 Jun 2025 10:31:31 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v4] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 09:15:08 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Feedback: Instructions Update test/jdk/java/awt/print/Dialog/DialogType.java line 52: > 50: Two dialogs are shown in succession. > 51: The test passes as long as no exceptions are thrown. > 52: Note: On Mac OS & on Windows, the first dialog is a native May add a blank line before Note. Suggestion: The test passes as long as no exceptions are thrown. Note: On Mac OS & on Windows, the first dialog is a native test/jdk/java/awt/print/Dialog/DialogType.java line 80: > 78: Attribute[] attrs = aset.toArray(); > 79: for (int i = 0; i < attrs.length; i++) { > 80: System.out.println(attrs[i]); Is it better to log the attributes using PFJ log area ? or is it really require to log the output ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156677323 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2156673475 From mvs at openjdk.org Thu Jun 19 11:11:32 2025 From: mvs at openjdk.org (Manukumar V S) Date: Thu, 19 Jun 2025 11:11:32 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v6] In-Reply-To: References: Message-ID: <1dLK-TdHycvdgZ63-6WXfDQF-m-00Ra1N-Vlbqd96UU=.fe0c34b9-5d00-4551-8745-2f5746d80354@github.com> > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Formatting changes, removed unwanted code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25879/files - new: https://git.openjdk.org/jdk/pull/25879/files/b5a3f894..f38a51a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25879&range=04-05 Stats: 13 lines in 1 file changed: 1 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25879/head:pull/25879 PR: https://git.openjdk.org/jdk/pull/25879 From mblaesing at openjdk.org Thu Jun 19 13:36:46 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Thu, 19 Jun 2025 13:36:46 GMT Subject: [jdk25] RFR: 8353950: Clipboard interaction on Windows is unstable Message-ID: 8353950: Clipboard interaction on Windows is unstable ------------- Commit messages: - Backport 92be7821f5d5cbf5fe0244b41b2b7b1ada898df0 Changes: https://git.openjdk.org/jdk/pull/25897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25897&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353950 Stats: 174 lines in 4 files changed: 128 ins; 24 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/25897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25897/head:pull/25897 PR: https://git.openjdk.org/jdk/pull/25897 From aivanov at openjdk.org Thu Jun 19 16:36:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 16:36:31 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v10] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Wed, 18 Jun 2025 22:55:12 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Additional review comments. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25705#pullrequestreview-2943615398 From aivanov at openjdk.org Thu Jun 19 16:47:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 16:47:29 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Thu, 19 Jun 2025 04:01:49 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1033: >> >>> 1031: /** >>> 1032: * Gets the allocation to give the root View. >>> 1033: * The Rectangle returned has nothing to do with visibility but >> >> "nothing to do with" -> "unrelated to" >> >> >> But what I'd really like to see is an explanation of what the return from this method ACTUALLY means / is used for. >> What does "the allocation" mean ? Too woolly for me. > > getVisibleEditorRect() return the bounds of the text editor and the return value is used to to set-size/paint the > `javax.swing.text.View` of this text editor component. > "the allocation" refers to what allocated area the view needs to paint, it seems to be a common phrase used in context of View class which says > >> "The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with. " > > In that regard, probably getAllocatedViewRect() would have been better choice of the method name @prsadhuk @prrace Does this description work? /** * Gets the allocation for the root view. * The returned rectangle is unrelated to visibility, * it is passed as the {@code allocation} parameter to * the {@link View#paint(Graphics, Shape) View.paint} method. * The component must have a non-zero positive size for * this translation to be computed. * * @return the bounding box for the root view */ protected Rectangle getVisibleEditorRect() { This renders like this: > Gets the allocation for the root view. The returned rectangle is unrelated to visibility, it is passed as the allocation parameter to the [`View.paint`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/text/View.html#paint(java.awt.Graphics,java.awt.Shape)) method. The component must have a non-zero positive size for this translation to be computed. We can also add @TejeshR13's [suggestion](https://github.com/openjdk/jdk/pull/25850/files#r2153658561): ?The method name is preserved for backward compatibility.? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2157389675 From aivanov at openjdk.org Thu Jun 19 16:51:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 16:51:29 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v6] In-Reply-To: <1dLK-TdHycvdgZ63-6WXfDQF-m-00Ra1N-Vlbqd96UU=.fe0c34b9-5d00-4551-8745-2f5746d80354@github.com> References: <1dLK-TdHycvdgZ63-6WXfDQF-m-00Ra1N-Vlbqd96UU=.fe0c34b9-5d00-4551-8745-2f5746d80354@github.com> Message-ID: On Thu, 19 Jun 2025 11:11:32 GMT, Manukumar V S wrote: >> Issue: >> MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. >> >> Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. >> >> Fix: >> Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. >> >> Testing: >> Tested using mach5 in all available platforms and got full PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes, removed unwanted code Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25879#pullrequestreview-2943642434 From duke at openjdk.org Thu Jun 19 16:54:28 2025 From: duke at openjdk.org (duke) Date: Thu, 19 Jun 2025 16:54:28 GMT Subject: RFR: 8358697: java/awt/font/TextLayout/MyanmarTextTest.java gives false positive result when preconditions not met [v6] In-Reply-To: <1dLK-TdHycvdgZ63-6WXfDQF-m-00Ra1N-Vlbqd96UU=.fe0c34b9-5d00-4551-8745-2f5746d80354@github.com> References: <1dLK-TdHycvdgZ63-6WXfDQF-m-00Ra1N-Vlbqd96UU=.fe0c34b9-5d00-4551-8745-2f5746d80354@github.com> Message-ID: On Thu, 19 Jun 2025 11:11:32 GMT, Manukumar V S wrote: >> Issue: >> MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. >> >> Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. >> >> Fix: >> Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. >> >> Testing: >> Tested using mach5 in all available platforms and got full PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes, removed unwanted code @manukumarvs Your change (at version f38a51a5bcbcdd5e4715791eadfbd7fd69caa096) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25879#issuecomment-2988689225 From prr at openjdk.org Thu Jun 19 17:03:34 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 19 Jun 2025 17:03:34 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v9] In-Reply-To: References: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> <3A5j30xOMedOYEwuO9Z6t4BxSOoA_NnDFi7mUW0o4Sk=.27d172ae-4921-490c-b503-4dcffb173ba2@github.com> Message-ID: On Thu, 19 Jun 2025 10:08:33 GMT, Alexey Ivanov wrote: >>> Also that other constructor (which github won't let me comment on) installs the description even if the image is null. >> >> I don't see it as a problem. >> >> If the app developer wants to initialise the object with `null` image and a description, why don't we let them do it? >> >> The image may be auto-generated and while it's generated, the image in `ImageIcon` remains `null`; when the image is read the app calls `ImageIcon.setImage` to the set now available image and *expects the description being preserved*. > >> Now .. what should happen to an existing description when you set a new image ? >> >> Apps can call setDescription() but in what order ? >> >> The only thing I can say here is that I think if the image is null we probably should clear the description. > > Nothing should happen to the description. These are two fields which can be changed independently now, why would we enforce an order on method calls? > > Changing the image shouldn't change the description; similarly, changing description doesn't change the image. > > Also that other constructor (which github won't let me comment on) installs the description even if the image is null. > > I don't see it as a problem. > > If the app developer wants to initialise the object with `null` image and a description, why don't we let them do it? > Because that would be inconsistent with every other constructor. See ImagIcon(String filename) ImageIcon(String filename, String description) ImageIcon(String URL) ImageIcon(String URL, String description) ImageIcon(byte[] imageData) ImageIcon(byte[] imageData, String description) None of these set the description if the image resolves to null. Also clearly ImageIcon(Image image) and ImageIcon(Image image, String description) where image == null can't be doing it today because a NPE is thrown before it gets there. So we can have that case do whatever we want if we allow a null image. And consistency seems the best choice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2157405880 From aivanov at openjdk.org Thu Jun 19 17:08:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 17:08:27 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25881#pullrequestreview-2943669064 From prr at openjdk.org Thu Jun 19 17:08:27 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 19 Jun 2025 17:08:27 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. > > > Should each constructor specify how the message returned by `getMessage` is constructed instead of _directing to the specification of `getMessage` for details_? > > > > > > 100% no. I am not wasting time on that. This whole spec. is getting revamped again in JDK 26 in very short order after this minimal fix is backported to JDK 25 > > I see, thank you for your clarification. > > So, this is a minimal update to the specification to quickly address the problem with `null` vs. _empty_ message, which is being backported to JDK 25; the specification for JDK 26 is going to be overhauled shortly. > > Is my understanding correct now? Right. What I am obliged to do in order to satisfy one specific TCK test. Nothing more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25881#issuecomment-2988708586 From aivanov at openjdk.org Thu Jun 19 17:08:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 17:08:28 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 17:03:13 GMT, Phil Race wrote: > Right. What I am obliged to do in order to satisfy one specific TCK test. Nothing more. Thank you! It makes perfect sense. Looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25881#issuecomment-2988718647 From mblaesing at doppel-helix.eu Thu Jun 19 17:23:41 2025 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Thu, 19 Jun 2025 19:23:41 +0200 Subject: Backport Candidate: JDK-8332271/ JDK-8353950 (PR #24614) In-Reply-To: References: <67dd91bc-6216-4abc-8ce7-dc68cb0891c8@oracle.com> <02ee74ad3e2ed92b3c481670e78c37db42e4ad39.camel@doppel-helix.eu> Message-ID: Hi, thanks for testing and checking. I created: https://github.com/openjdk/jdk/pull/25897 And tested the changes prior to opening the PR locally. Thank you Matthias Am Montag, dem 16.06.2025 um 15:46 -0700 schrieb Philip Race: > I've looked at the code and I think overall it is an improvement in a > few ways such as fewer calls to open/close > and getting the formats not requiring that. > > I didn't spot anything that looks suspicious and we've been running it > in CI since it was pushed, > and given that it fixes crashes (etc) it seems like a reasonable RDP 1 fix. > > -phil. > > > On 6/11/25 8:59 AM, Matthias Bl?sing wrote: > > Hi, > > > > Am Dienstag, dem 10.06.2025 um 21:43 -0700 schrieb Philip Race: > > > It seems to me like a candidate based on being a recent 'regression' and > > > the use case and potential impact. > > > I just have not looked at or tested the code myself, and clipboard tests > > > are at least in some part manual, > > > so I don't know how well it has been tested. > > > > > > Did anyone run at least the automated jtreg tests for you on our CI system ? > > to my knowledge this was not yet done. > > > > I ran the jtreg tests from `test/jdk/java/awt/Clipboard` locally > > including the new crash reproducer. In addition I used the application > > level reproducer to verify that the issue also covers that. That test > > copy-and-pastes text between NetBeans and notepad in a loop, while > > adding the loop index on each invocation. That looked sane for 20-100 > > iterations. > > > > > On 6/10/25 12:54 PM, Matthias Bl?sing wrote: > > > > [Backport proposal https://github.com/openjdk/jdk/pull/24614] > > > > > > > > JDK-8332271: Reading data from the clipboard from multiple threads crashes the JVM (P3) > > > > JDK-8353950: Clipboard interaction on Windows is unstable (P4) > > Thanks for considering > > > > Matthias From mblaesing at openjdk.org Thu Jun 19 17:24:27 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Thu, 19 Jun 2025 17:24:27 GMT Subject: [jdk25] RFR: 8353950: Clipboard interaction on Windows is unstable In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 13:27:50 GMT, Matthias Bl?sing wrote: > 8353950: Clipboard interaction on Windows is unstable Testing: - Tests from `test/jdk/java/awt/Clipboard` were successfully run with fastdebug and release configuration. It was verified, that the new test fails before the change and succeeds afterwards. - Application level test already done with the original change were repeated and verified ------------- PR Comment: https://git.openjdk.org/jdk/pull/25897#issuecomment-2988758424 From duke at openjdk.org Thu Jun 19 17:42:30 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 19 Jun 2025 17:42:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 15:25:42 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183: > >> 181: size.bit.alg=%1$d-Bit-%2$s >> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3} >> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4} > > It feels as if there's something missing after _?einem?_. seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2157444024 From aivanov at openjdk.org Thu Jun 19 17:50:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 17:50:30 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v9] In-Reply-To: References: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> <3A5j30xOMedOYEwuO9Z6t4BxSOoA_NnDFi7mUW0o4Sk=.27d172ae-4921-490c-b503-4dcffb173ba2@github.com> Message-ID: On Thu, 19 Jun 2025 17:00:09 GMT, Phil Race wrote: > And consistency seems the best choice. Then our best choice is not to touch `ImageIcon(Image)` and leave it to throw `NullPointerException`. All the constructors except for `ImageIcon((String) null)` throw `NullPointerException` if the first argument is `null`. Strangely enough, `ImageIcon((String) null)` creates a non-`null` image. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2157454838 From ludwig.mark at siemens.com Thu Jun 19 18:04:00 2025 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Thu, 19 Jun 2025 18:04:00 +0000 Subject: Is Java System Property "swing.defaultlaf" actually referenced in source? Message-ID: Greetings, We are in the process of (finally) completing a migration from AWT-based windows and dialogs to Swing-based that was started in the 1990s. Testing the external Swing controls on Linux, we find nothing seems to happen as a result of setting the "swing.defaultlaf" System Property. This is documented in multiple places - at least the javax.swing.UIManager doc, and the How to Set the Look and Feel tutorial (and is mentioned in https://bugs.openjdk.org/browse/JDK-8159164). We find the "swing.systemlaf" System Property is effective in changing the returned value from UIManager.getSystemLookAndFeelClassName(), but does not by itself change the look-and-feel -- only with something like UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()), which is documented. We would appreciate clarity on this discrepancy regarding the "default" look-and-feel for Swing on Linux. Thanks, Mark Ludwig -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Thu Jun 19 19:07:43 2025 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 19 Jun 2025 20:07:43 +0100 Subject: Is Java System Property "swing.defaultlaf" actually referenced in source? In-Reply-To: References: Message-ID: Hi Mark, The default look and feel is Metal on all OS except for macOS where the default is Aqua. You can modify the default look and feel using the the |swing.defaultlaf| property, and it works for me as expected. The default look and feel of an application is initialised to the class in the |swing.defaultlaf| property. I ran a simple Java program on Windows: > java DefaultLookAndFeel.java [*The Java(tm) Look and Feel* - javax.swing.plaf.metal.MetalLookAndFeel] com.sun.java.swing.plaf.windows.WindowsLookAndFeel javax.swing.plaf.metal.MetalLookAndFeel > java -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel DefaultLookAndFeel.java [*The Microsoft Windows Look and Feel* - com.sun.java.swing.plaf.windows.WindowsLookAndFeel] com.sun.java.swing.plaf.windows.WindowsLookAndFeel javax.swing.plaf.metal.MetalLookAndFeel The |swing.defaultlaf| property is documented and is used in the tutorial How to Set the Look and Feel , specifically the section Specifying the Look and Feel: Command Line has two examples how to modify the default look and feel. If set the value to a class that doesn't exist, I'll get an exception: > java -Dswing.defaultlaf=NimbusLookAndFeel DefaultLookAndFeel.java Exception in thread "main" java.lang.Error: Cannot load NimbusLookAndFeel at java.desktop/javax.swing.UIManager.initializeDefaultLAF(UIManager.java:1390) at java.desktop/javax.swing.UIManager.initialize(UIManager.java:1501) at java.desktop/javax.swing.UIManager.maybeInitialize(UIManager.java:1467) at java.desktop/javax.swing.UIManager.getLookAndFeel(UIManager.java:492) at DefaultLookAndFeel.main(DefaultLookAndFeel.java:5) You can use these line numbers to study how default look and feel is initialised. Please note the client-libs-dev mailing list is not a support forum, it is place to discuss /development of client libraries/. -- Regards, Alexey On 2025-06-19 19:04, Ludwig, Mark wrote: > > Greetings, > > We are in the process of (finally) completing a migration from > AWT-based windows and dialogs to Swing-based that was started in the > 1990s. > > Testing the external Swing controls on Linux, we find nothing seems to > happen as a result of setting the ?swing.defaultlaf? System Property.? > This is documented in multiple places ? at least the > javax.swing.UIManager doc, and the *How to Set the Look and Feel* > tutorial (and is mentioned in > https://bugs.openjdk.org/browse/JDK-8159164). > > We find the ?swing.systemlaf? System Property is effective in changing > the returned value from UIManager.getSystemLookAndFeelClassName(), but > does not by itself change the look-and-feel -- only with something > like > UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()), > which is documented. > > We would appreciate clarity on this discrepancy regarding the > ?default? look-and-feel for Swing on Linux. > > Thanks, > > Mark Ludwig > The source of the sample app: |import javax.swing.UIManager; public class DefaultLookAndFeel { public static void main(String[] args) { System.out.println(UIManager.getLookAndFeel()); System.out.println(UIManager.getSystemLookAndFeelClassName()); System.out.println(UIManager.getCrossPlatformLookAndFeelClassName()); } }| -------------- next part -------------- An HTML attachment was scrubbed... URL: From aivanov at openjdk.org Thu Jun 19 19:16:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:16:29 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v4] In-Reply-To: References: Message-ID: <0AMWpQiMBEsQ7VK16J8HDx1Jx0lf7VnmbaxK7uTDA7g=.2a9c1557-483a-4c5a-a268-33de92851bba@github.com> On Thu, 19 Jun 2025 09:15:08 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Feedback: Instructions Update test/jdk/java/awt/print/Dialog/DialogType.java line 52: > 50: Two dialogs are shown in succession. > 51: The test passes as long as no exceptions are thrown. > 52: Note: On Mac OS & on Windows, the first dialog is a native Suggestion: Note: On macOS & on Windows, the first dialog is a native Apple refers its OS as *macOS*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2157537962 From aivanov at openjdk.org Thu Jun 19 19:16:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:16:30 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v4] In-Reply-To: References: Message-ID: <3_3b8vxB0QRabUfSI9u2BuXF4vex-Sd-SJT4ExFlLMM=.855a1813-d757-4baf-b50f-5e7c8961d551@github.com> On Thu, 19 Jun 2025 10:26:39 GMT, Abhishek Kumar wrote: >> Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback: Instructions Update > > test/jdk/java/awt/print/Dialog/DialogType.java line 80: > >> 78: Attribute[] attrs = aset.toArray(); >> 79: for (int i = 0; i < attrs.length; i++) { >> 80: System.out.println(attrs[i]); > > Is it better to log the attributes using PFJ log area ? > or is it really require to log the output ? I believe this logging is done for the purpose of debugging and it not useful for the person running the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2157540417 From aivanov at openjdk.org Thu Jun 19 19:27:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:27:28 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v3] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 04:10:20 GMT, Prasanta Sadhukhan wrote: >> RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. >> Modified the color so that they are visible.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove author tag Is this fix needed? You're working on modifying menu rendering on Windows in #23324 so that both check marks and icons are displayed. The test will be fixed as soon as that fix for [JDK-8348760](https://bugs.openjdk.org/browse/JDK-8348760) is integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25864#issuecomment-2988969593 From aivanov at openjdk.org Thu Jun 19 19:35:26 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:35:26 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski wrote: > Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. > > I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. You should bump the copyright year in `JNICheck.sh`. ------------- PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2943885449 From aivanov at openjdk.org Thu Jun 19 19:35:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:35:27 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: References: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com> Message-ID: On Thu, 12 Jun 2025 12:44:12 GMT, Daniel Jeli?ski wrote: >> If this check is not needed, then why are we adding it? > > just so we don't forget to add it when we modify the enclosing function. The call to `CallStaticBooleanMethod` is located pretty far from the end of the function, and can be easy to miss. > it wasn't always the case Does it mean that there was another up-call into Java before this method returns? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2157560846 From aivanov at openjdk.org Thu Jun 19 19:48:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:48:30 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 06:17:32 GMT, Sergey Bylokhov wrote: > This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. > > Notes: GraphicsDevice provides two methods for handling full-screen windows: > - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). > - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. src/java.desktop/share/classes/java/awt/GraphicsDevice.java line 306: > 304: } > 305: // Set the full screen window > 306: synchronized (fsAppContextLock) { A `synchronized` block has stronger memory consistency guarantees than a `volatile` modifier. Did you consider leaving the synchronized block but removing the usage of `AppContext`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2157579620 From aivanov at openjdk.org Thu Jun 19 19:51:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:51:29 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 08:53:57 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. > `eventsList` is an ArrayList. Changes requested by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24818#pullrequestreview-2943916437 From aivanov at openjdk.org Thu Jun 19 19:51:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:51:30 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove In-Reply-To: <3-HOByltbViqB8Pel99peTImR6psDZMw0l15ywzJFXc=.d6f16a2a-92c5-448e-b875-e77c576921f3@github.com> References: <3-HOByltbViqB8Pel99peTImR6psDZMw0l15ywzJFXc=.d6f16a2a-92c5-448e-b875-e77c576921f3@github.com> Message-ID: On Thu, 5 Jun 2025 20:58:19 GMT, Jean-No?l Rouvignac wrote: >> src/java.desktop/share/classes/javax/sound/midi/Track.java line 202: >> >>> 200: synchronized(eventsList) { >>> 201: if (set.remove(event)) { >>> 202: if (eventsList.remove(event)) { >> >> Can be rewritten as `if (set.remove(event) && eventsList.remove(event))`. > > `return set.remove(event) && eventsList.remove(event);` even... > > And remove the return statement coming after This is *cleaner*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24818#discussion_r2157582518 From aivanov at openjdk.org Thu Jun 19 19:54:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:54:31 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 10:11:57 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Test fix >> - javadoc wording..clear image desscription if image is null > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 147: > >> 145: image = Toolkit.getDefaultToolkit().getImage(filename); >> 146: if (image == null) { >> 147: this.description = null; > > I do not think we have to enforce setting `description` to `null` if the image is `null` ? **it is up to the developer to decide**. And this code is in constructor, therefore `description` still has its default value of `null`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2157585327 From aivanov at openjdk.org Thu Jun 19 19:58:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 19 Jun 2025 19:58:37 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: <0AjBQg7E18cGIAiGrreBzL_dAbfL1aq1cVt5feRbTUE=.700badca-71fa-4c73-b4c6-b6b150f679a2@github.com> On Wed, 18 Jun 2025 14:13:19 GMT, Alexey Ivanov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8359053 > > src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 353: > >> 351: the default type was toolkit-modal, >> 352: and now with single application per-VM there is no >> 353: distinction between application- and toolkit-modality > > Suggestion: > > and now with single application per VM there is no > distinction between application- and toolkit-modality. > > There should be a space between a preposition and a noun and a full stop in the end of the sentence. @prrace Are you going to accept this suggestion? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2157589041 From aturbanov at openjdk.org Thu Jun 19 20:28:42 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 19 Jun 2025 20:28:42 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove [v2] In-Reply-To: References: Message-ID: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. > `eventsList` is an ArrayList. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8359996: Remove unnecessary List.indexOf key from Track.remove apply suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24818/files - new: https://git.openjdk.org/jdk/pull/24818/files/83c1e794..1cb93d6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24818&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24818&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24818/head:pull/24818 PR: https://git.openjdk.org/jdk/pull/24818 From prr at openjdk.org Thu Jun 19 20:31:29 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 19 Jun 2025 20:31:29 GMT Subject: [jdk25] RFR: 8353950: Clipboard interaction on Windows is unstable In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 13:27:50 GMT, Matthias Bl?sing wrote: > 8353950: Clipboard interaction on Windows is unstable Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25897#pullrequestreview-2943976568 From serb at openjdk.org Fri Jun 20 01:26:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 20 Jun 2025 01:26:31 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 19:45:48 GMT, Alexey Ivanov wrote: >> This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. >> >> Notes: GraphicsDevice provides two methods for handling full-screen windows: >> - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). >> - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. > > src/java.desktop/share/classes/java/awt/GraphicsDevice.java line 306: > >> 304: } >> 305: // Set the full screen window >> 306: synchronized (fsAppContextLock) { > > A `synchronized` block has stronger memory consistency guarantees than a `volatile` modifier. > > Did you consider leaving the synchronized block but removing the usage of `AppContext`? What do you mean by stronger in this use case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2157863506 From psadhukhan at openjdk.org Fri Jun 20 03:12:32 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 20 Jun 2025 03:12:32 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v3] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 04:10:20 GMT, Prasanta Sadhukhan wrote: >> RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. >> Modified the color so that they are visible.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove author tag No, that is different..In #23324 those are not displayed if imageicon is used, otherwise it is ok..In this, checkmark is not displayed because of the background. I feel this fix is needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25864#issuecomment-2989674311 From psadhukhan at openjdk.org Fri Jun 20 03:12:32 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 20 Jun 2025 03:12:32 GMT Subject: Integrated: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 03:56:13 GMT, Prasanta Sadhukhan wrote: > RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. > Modified the color so that they are visible.. This pull request has now been integrated. Changeset: c51bed73 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/c51bed739d97167ae768e204dd8666d078d2e607 Stats: 24 lines in 1 file changed: 18 ins; 1 del; 5 mod 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible Reviewed-by: tr ------------- PR: https://git.openjdk.org/jdk/pull/25864 From serb at openjdk.org Fri Jun 20 03:25:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 20 Jun 2025 03:25:32 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: Message-ID: <414k9GtbyCEvEah6rhM_FpKzk2NXPBucKeWFl2PXz9E=.57a79e6c-5fa4-4528-87e2-749097d16558@github.com> On Thu, 19 Jun 2025 10:23:46 GMT, Alexey Ivanov wrote: > It may be impossible to reproduce the problem without referencing WindowsButtonUI. If it's possible, I'm all for it. That should be checked on old jdk build. > The bug was in Windows L&F, I don't think it's applicable to other L&F. It depends on how these offsets were used previously, maybe we displayed the text outside the button, which shouldn't happen for all L&Fs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25883#discussion_r2157964624 From psadhukhan at openjdk.org Fri Jun 20 03:29:38 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 20 Jun 2025 03:29:38 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel Message-ID: Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F. This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon. Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F.. ------------- Commit messages: - 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel Changes: https://git.openjdk.org/jdk/pull/25907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346753 Stats: 8 lines in 1 file changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25907/head:pull/25907 PR: https://git.openjdk.org/jdk/pull/25907 From psadhukhan at openjdk.org Fri Jun 20 03:39:27 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 20 Jun 2025 03:39:27 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Thu, 19 Jun 2025 16:45:11 GMT, Alexey Ivanov wrote: >> getVisibleEditorRect() return the bounds of the text editor and the return value is used to to set-size/paint the >> `javax.swing.text.View` of this text editor component. >> "the allocation" refers to what allocated area the view needs to paint, it seems to be a common phrase used in context of View class which says >> >>> "The view gets its allocation from the parent at paint time, so it must be prepared to redo layout if the allocated area is different from what it is prepared to deal with. " >> >> In that regard, probably getAllocatedViewRect() would have been better choice of the method name > > @prsadhuk @prrace Does this description work? > > > /** > * Gets the allocation for the root view. > * The returned rectangle is unrelated to visibility, > * it is passed as the {@code allocation} parameter to > * the {@link View#paint(Graphics, Shape) View.paint} method. > * The component must have a non-zero positive size for > * this translation to be computed. > * > * @return the bounding box for the root view > */ > protected Rectangle getVisibleEditorRect() { > > > This renders like this: > >> Gets the allocation for the root view. The returned rectangle is unrelated to visibility, it is passed as the allocation parameter to the [`View.paint`](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/text/View.html#paint(java.awt.Graphics,java.awt.Shape)) method. The component must have a non-zero positive size for this translation to be computed. > > We can also add @TejeshR13's [suggestion](https://github.com/openjdk/jdk/pull/25850/files#r2153658561): ?The method name is preserved for backward compatibility.? It is passed to `View.setSize` also so just mentioning one may not be right..and I guess {@code allocation} is a no-op as it is not a class.. Maybe we can mention "The returned rectangle is unrelated to visibility, and is used as an allocation parameter in javax.swing.text.View class to set the size and paint the allocated View" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2157975053 From psadhukhan at openjdk.org Fri Jun 20 03:51:16 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 20 Jun 2025 03:51:16 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v11] In-Reply-To: References: Message-ID: > When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. > The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. > > It's better to not go through all MediaTracker usage and bail out initially itself for null image.. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Remove resetting description from constructor as it is already null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25767/files - new: https://git.openjdk.org/jdk/pull/25767/files/f6237741..e76c4ff1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=09-10 Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767 PR: https://git.openjdk.org/jdk/pull/25767 From psadhukhan at openjdk.org Fri Jun 20 03:53:31 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 20 Jun 2025 03:53:31 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: <2dIopwXUm7OLyZN5qdLhnIDWOpZHvLMghTqxbefmQlA=.23edb79f-6aec-4768-9abb-b951937f23ab@github.com> On Thu, 19 Jun 2025 03:01:15 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Test fix > - javadoc wording..clear image desscription if image is null I have removed resetting "description" from constructor as it is already null there..Retained in setImage and reset width/height also.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-2989719370 From psadhukhan at openjdk.org Fri Jun 20 05:06:35 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 20 Jun 2025 05:06:35 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v9] In-Reply-To: References: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> <3A5j30xOMedOYEwuO9Z6t4BxSOoA_NnDFi7mUW0o4Sk=.27d172ae-4921-490c-b503-4dcffb173ba2@github.com> Message-ID: On Thu, 19 Jun 2025 17:48:08 GMT, Alexey Ivanov wrote: >>> > Also that other constructor (which github won't let me comment on) installs the description even if the image is null. >>> >>> I don't see it as a problem. >>> >>> If the app developer wants to initialise the object with `null` image and a description, why don't we let them do it? >>> >> >> Because that would be inconsistent with every other constructor. >> >> See >> ImagIcon(String filename) >> ImageIcon(String filename, String description) >> ImageIcon(String URL) >> ImageIcon(String URL, String description) >> ImageIcon(byte[] imageData) >> ImageIcon(byte[] imageData, String description) >> >> None of these set the description if the image resolves to null. >> >> Also clearly >> ImageIcon(Image image) >> and >> ImageIcon(Image image, String description) >> where image == null can't be doing it today >> because a NPE is thrown before it gets there. >> So we can have that case do whatever we want if we allow a null image. >> And consistency seems the best choice. > >> And consistency seems the best choice. > > Then our best choice is not to touch `ImageIcon(Image)` and leave it to throw `NullPointerException`. > > All the constructors except for `ImageIcon((String) null)` throw `NullPointerException` if the first argument is `null`. > > Strangely enough, `ImageIcon((String) null)` creates a non-`null` image. If we leave it to throw NPE, then JCK might crib, if at some point they decide to add test to test null image and since javadoc doesn't mention it can throw NPE, it will result in non-compliance and then we have to modify javadoc to clarify it, so I guess it's best to take preventive action now.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2158053632 From smandalika at openjdk.org Fri Jun 20 05:09:10 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 20 Jun 2025 05:09:10 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v5] In-Reply-To: References: Message-ID: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Fixed a type in the instructions. Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/f43ad7d5..bf6a2541 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From smandalika at openjdk.org Fri Jun 20 05:09:11 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 20 Jun 2025 05:09:11 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v4] In-Reply-To: <3_3b8vxB0QRabUfSI9u2BuXF4vex-Sd-SJT4ExFlLMM=.855a1813-d757-4baf-b50f-5e7c8961d551@github.com> References: <3_3b8vxB0QRabUfSI9u2BuXF4vex-Sd-SJT4ExFlLMM=.855a1813-d757-4baf-b50f-5e7c8961d551@github.com> Message-ID: On Thu, 19 Jun 2025 19:13:10 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/print/Dialog/DialogType.java line 80: >> >>> 78: Attribute[] attrs = aset.toArray(); >>> 79: for (int i = 0; i < attrs.length; i++) { >>> 80: System.out.println(attrs[i]); >> >> Is it better to log the attributes using PFJ log area ? >> or is it really require to log the output ? > > I believe this logging is done for the purpose of debugging and it not useful for the person running the test. Yes, that is correct. The log area is useful when there is a verification step - such as 'live events' tracking and validation that needs to be displayed on the UI and the test is marked as Pass or Fail as per that. Here, if the test fails for any reason - identifying that will be in the scope of the debugging the test by looking closely into the JTR - and hence we have the SOP to log it into the jtr file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2158055216 From abhiscxk at openjdk.org Fri Jun 20 10:35:29 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 20 Jun 2025 10:35:29 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v5] In-Reply-To: References: Message-ID: <-3rLlc2mTz4FY8HKvOCm4ENXDEmXmpuLcK9swo9RReQ=.e5545adf-72e3-45ab-8f2d-d40c4fac3972@github.com> On Fri, 20 Jun 2025 05:09:10 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a type in the instructions. > > Co-authored-by: Alexey Ivanov LGTM ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25842#pullrequestreview-2945518193 From aivanov at openjdk.org Fri Jun 20 11:28:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 11:28:28 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording In-Reply-To: References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Fri, 20 Jun 2025 03:36:33 GMT, Prasanta Sadhukhan wrote: > It is passed to `View.setSize` also so just mentioning one may not be right? Right. Both uses cases fall into the same category: the allocation controls the size of the root view. The returned allocation rectangle is also used in handling mutations to the text model. I'd rather leave it without any explanation why it's called *allocation*. Anyone who dealt with Swing text components and their implementation of the view classes is expected to roughly understand what allocation means. Searching for usages of `getVisibleEditorRect` reveals the usages. > `{@code allocation}` is a no-op as it is not a class.. Yes, it is an op: it refers to `allocation` the parameter of the `paint` method. > Maybe we can mention "The returned rectangle is unrelated to visibility, and is used as an allocation parameter in javax.swing.text.View class to set the size and paint the allocated View" If we stick to explaining *allocation*, your suggestion makes sense, I edited it a bit: ?The returned rectangle is unrelated to visibility, it is used to set the size of the root view.? This is what it means? without going too deep into the details. We could add `@see` links to `View.paint` and/or `View.setSize`, the link to paint could be the most useful because it has a parameter called `allocation`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2158735071 From aivanov at openjdk.org Fri Jun 20 11:53:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 11:53:30 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v9] In-Reply-To: References: <8Q1E6jkBiYiDYl6bjIqnrrpXOo7LouR2X1RBL6m2s_I=.0eadaa62-25a1-47ba-89b0-e91394ba1db2@github.com> <3A5j30xOMedOYEwuO9Z6t4BxSOoA_NnDFi7mUW0o4Sk=.27d172ae-4921-490c-b503-4dcffb173ba2@github.com> Message-ID: On Fri, 20 Jun 2025 05:04:12 GMT, Prasanta Sadhukhan wrote: > If we leave it to throw NPE, then JCK might crib, if at some point they decide to add test to test null image and since javadoc doesn't mention it can throw NPE, it will result in non-compliance and then we have to modify javadoc to clarify it, so I guess it's best to take preventive action now.. But it is *consistent* with the current behaviour and it is not specified at the moment. If we explicitly specify the constructors throw NPE if a `null` parameter is passed, then JCK will add a test that confirms the specified behaviour. All the constructors come into picture then, which seems out of scope for this issue? If we don't change the behaviour of constructors and JCK challenges the implementation, then such a JCK test has no foundation in the API specification; yet it also leads to JCK challenge of the clarity of the specification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2158779998 From aivanov at openjdk.org Fri Jun 20 12:17:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 12:17:31 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v11] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 03:51:16 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove resetting description from constructor as it is already null Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/ImageIcon.java line 219: > 217: * Creates an ImageIcon from an image object. > 218: * Setting a {@code null} image means > 219: * no image will be rendered. Suggestion: * If the image is {@code null}, no icon will be rendered. src/java.desktop/share/classes/javax/swing/ImageIcon.java line 230: > 228: if (image == null) { > 229: return; > 230: } So, are we changing the constructors that accept `Image`? ------------- PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2945815220 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2158785184 PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2158787404 From aivanov at openjdk.org Fri Jun 20 12:17:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 12:17:32 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 10:14:42 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Test fix >> - javadoc wording..clear image desscription if image is null > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 389: > >> 387: this.image = image; >> 388: if (image == null) { >> 389: this.description = null; > > We must not change the description. Why do we enforce resetting the description to `null`? > > The app is still free to change the description to an arbitrary value using `setDescription` even if the image is `null`. **I *strongly* disagree to changing the value of `description`** here, even though [I brought up this concern](https://github.com/openjdk/jdk/pull/25767#discussion_r2150249349). This does not make sense. Consider the following code snippet: ImageIcon im = new ImageIcon(); // Both image and description are null im.setDescription("whatever"); // Now image is null, and description isn't null im.setImage(null); // Why does description change to null? Both `image` and `description` are two independent fields of `ImageIcon` object, each has its own getter and setter, and each can be changed independently. We should not enforce the order of calls: if an app developer wants to set the image to `null`, temporarily or not, the value of the description has to be preserved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2158820017 From aivanov at openjdk.org Fri Jun 20 12:30:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 12:30:31 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v5] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 05:09:10 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a type in the instructions. > > Co-authored-by: Alexey Ivanov Changes requested by aivanov (Reviewer). test/jdk/java/awt/print/Dialog/DialogType.java line 47: > 45: > 46: private static final String INSTRUCTIONS = """ > 47: This test assumes and requires that you have a printer installed. The test will not start if there's no printer now, so the first sentence can be safely removed from the instructions. test/jdk/java/awt/print/Dialog/DialogType.java line 51: > 49: to optionally select a native dialog where one is present. > 50: Two dialogs are shown in succession. > 51: The test passes as long as no exceptions are thrown. In fact, the instructions could be improved too. Suggestion: Two print dialogs are shown in succession. Click Cancel in the dialogs to close them. On macOS & on Windows, the first dialog is a native dialog provided by the OS, the second dialog is implemented in Swing, the dialog differ in appearance. The test passes as long as no exceptions are thrown. (If there's an exception, the test will fail automatically.) The test verifies that the dialogs behave properly when using new API to optionally select a native dialog where one is present. test/jdk/java/awt/print/Dialog/DialogType.java line 53: > 51: The test passes as long as no exceptions are thrown. > 52: Note: On macOS & on Windows, the first dialog is a native > 53: control which differs in appearance from the second dialog Suggestion: The test passes as long as no exceptions are thrown. Note: On macOS & on Windows, the first dialog is a native control which differs in appearance from the second dialog. I agree with Abhishek suggestion, a blank here would make the instructions easier to parse. End the last sentence with a full stop, too. ------------- PR Review: https://git.openjdk.org/jdk/pull/25842#pullrequestreview-2945899214 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2158830452 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2158847752 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2158832386 From aivanov at openjdk.org Fri Jun 20 12:37:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 12:37:30 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: <414k9GtbyCEvEah6rhM_FpKzk2NXPBucKeWFl2PXz9E=.57a79e6c-5fa4-4528-87e2-749097d16558@github.com> References: <414k9GtbyCEvEah6rhM_FpKzk2NXPBucKeWFl2PXz9E=.57a79e6c-5fa4-4528-87e2-749097d16558@github.com> Message-ID: On Fri, 20 Jun 2025 03:22:46 GMT, Sergey Bylokhov wrote: > > It may be impossible to reproduce the problem without referencing WindowsButtonUI. If it's possible, I'm all for it. > > That should be checked on old jdk build. Exactly! We have to reproduce the original bug first to see what was wrong. > > The bug was in Windows L&F, I don't think it's applicable to other L&F. > > It depends on how these offsets were used previously, maybe we displayed the text outside the button, which shouldn't happen for all L&Fs. Yes, but? This specific bug was for Windows only, the fix was presumably in Windows-only code, this is why I don't care much about other L&F. Even if the text was displayed outside of the button, it *was* Windows-specific. Until we understand what the original bug was, it is too early to extend the test to other L&F. Additionally, it's a manual test. If the test is automated, it makes more sense to test for all L&Fs; for a manual test, I'd rather avoid testing in other L&F because the bug never existed there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25883#discussion_r2158861159 From aivanov at openjdk.org Fri Jun 20 15:25:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 15:25:36 GMT Subject: RFR: 8335986: Test javax/swing/JCheckBox/4449413/bug4449413.java fails on Windows 11 x64 because RBMenuItem's and CBMenuItem's checkmark on the left side are not visible [v3] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 04:10:20 GMT, Prasanta Sadhukhan wrote: >> RBMenuItem's and CBMenuItem's checkmark on the left side are not visible while running on Windows L&F as background color is same as RBMenuItem/CBMenuItem's checkmark.. >> Modified the color so that they are visible.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove author tag This fix does **not** look good to me, it does not fix the problem. You have fixed the test to make the problem disappear. @TejeshR13 [said](https://github.com/openjdk/jdk/pull/25864#discussion_r2153676999), > The test is specifically for background color black, I think you need to retain background color. I absolutely agree with Tejesh's concern. If an app developer sets the background of a `JCheckboxMenuItem` or `JRadioButtonMenuItem` to black, they'll be no way for the user to see whether it's selected or not. The developer set the foreground to white, yet Windows L&F doesn't respect this setting, it still renders the same black check mark or bullet. Essentially, Windows visual style theming doesn't support arbitrary backgrounds. Windows Classic L&F does supported. You used a gray background color for `JCheckboxMenuItem` or `JRadioButtonMenuItem` so that the black check mark and bullet are visible. How does this fix address the problem that they're still invisible on the black background?! [JDK-4449413](https://bugs.openjdk.org/browse/JDK-4449413) was about Metal L&F. Essentially, all the skinning, like Metal Ocean theme gradients or Nimbus and Synth may not work well with color customisations. The fact that this test passes in Nimbus L&F is a pure coincidence: it uses a lighter color for the check mark and bullet, that's why they're visible. If I change the color to `0x474748`, the check mark and bullet become invisible. Is it a bug? I think this test, `javax/swing/JCheckBox/4449413/bug4449413.java`, should be limited to specific L&Fs where changing the foreground color is respected. If not, then the test should explicitly iterate over all installed or supported L&Fs so that all the L&Fs are always tested. What do you, @prrace, think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25864#issuecomment-2992027022 From aivanov at openjdk.org Fri Jun 20 15:32:33 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 15:32:33 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v11] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 03:51:16 GMT, Prasanta Sadhukhan wrote: >> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime. >> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null. >> >> It's better to not go through all MediaTracker usage and bail out initially itself for null image.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove resetting description from constructor as it is already null src/java.desktop/share/classes/javax/swing/ImageIcon.java line 233: > 231: Object o = image.getProperty("comment", imageObserver); > 232: if (o instanceof String) { > 233: description = (String) o; To address [Phil's comment](https://github.com/openjdk/jdk/pull/25767/files#r2155610976): > This is wasted work if the app calls ImageIcon(Image, String) because that promptly over-writes whatever was obtained via this code. If we're going to change the constructors, to avoid *this wasted work* when `ImageIcon(Image, String)` constructor is called, I suggest moving the work into `ImageIcon(Image, String)` and implement `ImageIcon` like this: public ImageIcon (Image image) { String description = null; if (image != null) { Object o = image.getProperty("comment", null); if (o instanceof String) { description = (String) o; } } this(image, description); It is allowed in JDK 22 and later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2159249820 From liach at openjdk.org Fri Jun 20 15:55:36 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 20 Jun 2025 15:55:36 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 20:28:42 GMT, Andrey Turbanov wrote: >> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. >> `eventsList` is an ArrayList. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8359996: Remove unnecessary List.indexOf key from Track.remove > > apply suggestion This version looks good. Please wait for a desktop reviewer. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24818#pullrequestreview-2946677580 From smandalika at openjdk.org Fri Jun 20 16:09:48 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 20 Jun 2025 16:09:48 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v6] In-Reply-To: References: Message-ID: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Improved instructions as per feedback. Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/bf6a2541..904414c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=04-05 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From smandalika at openjdk.org Fri Jun 20 16:22:43 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 20 Jun 2025 16:22:43 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v7] In-Reply-To: References: Message-ID: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Improved instructions as per feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/904414c5..59312425 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From smandalika at openjdk.org Fri Jun 20 16:28:08 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 20 Jun 2025 16:28:08 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v8] In-Reply-To: References: Message-ID: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Whitespace error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/59312425..dae189ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From duke at openjdk.org Fri Jun 20 17:47:28 2025 From: duke at openjdk.org (duke) Date: Fri, 20 Jun 2025 17:47:28 GMT Subject: [jdk25] RFR: 8353950: Clipboard interaction on Windows is unstable In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 13:27:50 GMT, Matthias Bl?sing wrote: > 8353950: Clipboard interaction on Windows is unstable @matthiasblaesing Your change (at version 1bff35bd3e7c7c59b5a63d0e7f82ada28ff66a50) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25897#issuecomment-2992373724 From mblaesing at openjdk.org Fri Jun 20 17:47:29 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 20 Jun 2025 17:47:29 GMT Subject: [jdk25] RFR: 8353950: Clipboard interaction on Windows is unstable In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 20:29:18 GMT, Phil Race wrote: >> 8353950: Clipboard interaction on Windows is unstable > > Marked as reviewed by prr (Reviewer). @prrace thank you for the swift review. Would you mind sponsering the integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25897#issuecomment-2992374762 From aivanov at openjdk.org Fri Jun 20 18:55:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 18:55:28 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v8] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 16:28:08 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace error Just a small typo left. test/jdk/java/awt/print/Dialog/DialogType.java line 52: > 50: On macOS & on Windows, the first dialog is a native > 51: dialog provided by the OS, the second dialog is > 52: implemented in Swing, the dialog differ in appearance. Suggestion: implemented in Swing, the dialogs differ in appearance. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25842#pullrequestreview-2947052062 PR Review Comment: https://git.openjdk.org/jdk/pull/25842#discussion_r2159519911 From aivanov at openjdk.org Fri Jun 20 18:58:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 18:58:28 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 01:23:23 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/java/awt/GraphicsDevice.java line 306: >> >>> 304: } >>> 305: // Set the full screen window >>> 306: synchronized (fsAppContextLock) { >> >> A `synchronized` block has stronger memory consistency guarantees than a `volatile` modifier. >> >> Did you consider leaving the synchronized block but removing the usage of `AppContext`? > > What do you mean by stronger in this use case? I mean that there's a _happens before_ relation each time the synchronized block is reach whereas with volatile, the _happens before_ relation is guaranteed only when the value of the variable changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2159523719 From smandalika at openjdk.org Fri Jun 20 19:06:09 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Fri, 20 Jun 2025 19:06:09 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v9] In-Reply-To: References: Message-ID: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Fixed a small typo. Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25842/files - new: https://git.openjdk.org/jdk/pull/25842/files/dae189ee..7d337340 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25842&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25842/head:pull/25842 PR: https://git.openjdk.org/jdk/pull/25842 From aivanov at openjdk.org Fri Jun 20 19:17:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 19:17:30 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v9] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 19:06:09 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a small typo. > > Co-authored-by: Alexey Ivanov Looks good to me. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25842#pullrequestreview-2947090411 From aivanov at openjdk.org Fri Jun 20 19:20:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 19:20:29 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 20:28:42 GMT, Andrey Turbanov wrote: >> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. >> `eventsList` is an ArrayList. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8359996: Remove unnecessary List.indexOf key from Track.remove > > apply suggestion Looks good. Maybe wait for another reviewer? ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24818#pullrequestreview-2947095926 From serb at openjdk.org Fri Jun 20 20:15:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 20 Jun 2025 20:15:31 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> On Fri, 20 Jun 2025 18:55:30 GMT, Alexey Ivanov wrote: > I mean that there's a _happens before_ relation each time the synchronized block is reach whereas with volatile, the _happens before_ relation is guaranteed only when the value of the variable changes. I do not think that this is true "guaranteed only when the value of the variable changes". >A write to a volatile field ([?8.3.1.4](https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.3.1.4)) happens-before every subsequent read of that field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2159607617 From duke at openjdk.org Fri Jun 20 20:17:29 2025 From: duke at openjdk.org (duke) Date: Fri, 20 Jun 2025 20:17:29 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v9] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 19:06:09 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a small typo. > > Co-authored-by: Alexey Ivanov @srmandal Your change (at version 7d337340ea35bc383fac5eebccd0725473de0695) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25842#issuecomment-2992682566 From aivanov at openjdk.org Fri Jun 20 20:31:34 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 20:31:34 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> References: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> Message-ID: On Fri, 20 Jun 2025 20:12:52 GMT, Sergey Bylokhov wrote: >> I mean that there's a _happens before_ relation each time the synchronized block is reach whereas with volatile, the _happens before_ relation is guaranteed only when the value of the variable changes. > >> I mean that there's a _happens before_ relation each time the synchronized block is reach whereas with volatile, the _happens before_ relation is guaranteed only when the value of the variable changes. > > I do not think that this is true "guaranteed only when the value of the variable changes". >>A write to a volatile field ([?8.3.1.4](https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.3.1.4)) happens-before every subsequent read of that field. Exactly! A *write* to a volatile field. Yet entering and leaving a synchronized block gives a happens-before relation *each time*. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2159624167 From aivanov at openjdk.org Fri Jun 20 20:38:33 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 20 Jun 2025 20:38:33 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> Message-ID: <-3XHdE_t-sAawF_jLCHjisZn4JcGLuYpkn1odm8neO4=.69404e00-5ea5-4191-96e1-420f83e24355@github.com> On Fri, 20 Jun 2025 20:28:43 GMT, Alexey Ivanov wrote: >>> I mean that there's a _happens before_ relation each time the synchronized block is reach whereas with volatile, the _happens before_ relation is guaranteed only when the value of the variable changes. >> >> I do not think that this is true "guaranteed only when the value of the variable changes". >>>A write to a volatile field ([?8.3.1.4](https://docs.oracle.com/javase/specs/jls/se14/html/jls-8.html#jls-8.3.1.4)) happens-before every subsequent read of that field. > > Exactly! A *write* to a volatile field. > > Yet entering and leaving a synchronized block gives a happens-before relation *each time*. What I mean is two threads that called `GraphicsDevice.getFullScreenWindow` still established a *happens-before* relation for each call, which will be gone with the volatile modifier. It may be fine? or may be not? this is why I'm asking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2159631528 From duke at openjdk.org Fri Jun 20 20:42:33 2025 From: duke at openjdk.org (duke) Date: Fri, 20 Jun 2025 20:42:33 GMT Subject: RFR: 8355904: Use variadic macros for J2dTrace [v7] In-Reply-To: References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> Message-ID: On Fri, 6 Jun 2025 08:36:40 GMT, Nikita Gubarkov wrote: >> J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead. >> >> Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style. > > Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8355904 > - Update D3DShaderGen.c > - fixup! 8355904: Use variadic macros for J2dTrace > - fixup! 8355904: Use variadic macros for J2dTrace > - fixup! 8355904: Use variadic macros for J2dTrace > - Apply suggestions from code review > > Co-authored-by: Alexey Ivanov > - fixup! 8355904: Use variadic macros for J2dTrace > - 8355904: Use variadic macros for J2dTrace @YaaZ Your change (at version a4f9d118c21f61a205e0c3703602a6df42cd0fb0) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24949#issuecomment-2992742065 From achung at openjdk.org Fri Jun 20 21:10:29 2025 From: achung at openjdk.org (Alisen Chung) Date: Fri, 20 Jun 2025 21:10:29 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. src/java.desktop/share/classes/java/awt/HeadlessException.java line 1: > 1: /* do copyright years need to be updated for this file if there's a docs change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25881#discussion_r2159666300 From mblaesing at openjdk.org Fri Jun 20 21:52:34 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Fri, 20 Jun 2025 21:52:34 GMT Subject: [jdk25] Integrated: 8353950: Clipboard interaction on Windows is unstable In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 13:27:50 GMT, Matthias Bl?sing wrote: > 8353950: Clipboard interaction on Windows is unstable This pull request has now been integrated. Changeset: 79a85df0 Author: Matthias Bl?sing Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/79a85df074f25fbb767ad1b72db5082c51a88e9d Stats: 174 lines in 4 files changed: 128 ins; 24 del; 22 mod 8353950: Clipboard interaction on Windows is unstable 8332271: Reading data from the clipboard from multiple threads crashes the JVM Reviewed-by: prr Backport-of: 92be7821f5d5cbf5fe0244b41b2b7b1ada898df0 ------------- PR: https://git.openjdk.org/jdk/pull/25897 From honkar at openjdk.org Fri Jun 20 22:16:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 20 Jun 2025 22:16:29 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. Updated javadoc and regression test LGTM. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25881#pullrequestreview-2947358998 From honkar at openjdk.org Fri Jun 20 22:25:35 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 20 Jun 2025 22:25:35 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. test/jdk/java/awt/Headless/HeadlessExceptionTest.java line 37: > 35: public static void main (String[] args) { > 36: String nullmsg = new HeadlessException().getMessage(); > 37: String emptymsg = new HeadlessException("").getMessage(); @prrace I was thinking of a case which would actually throw HeadlessException when run with `Djava.awt.headless=true` such as creating a frame or robot but the exception msg can be null or default message from GraphicsEnvironment so making it difficult to validate on different platforms. The current test works well to validate both empty and null message. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25881#discussion_r2159723867 From prr at openjdk.org Fri Jun 20 22:25:36 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 20 Jun 2025 22:25:36 GMT Subject: Integrated: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 17:57:26 GMT, Phil Race wrote: > Clarify the behaviour of new HeadlessException().getMessage() > The spec. is updated to be clear that empty means null, not an empty string. This pull request has now been integrated. Changeset: 81985d42 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/81985d422d3a433c1248deec18e4fd9b9f780c2c Stats: 52 lines in 2 files changed: 51 ins; 0 del; 1 mod 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args Reviewed-by: aivanov, honkar ------------- PR: https://git.openjdk.org/jdk/pull/25881 From prr at openjdk.org Fri Jun 20 22:41:42 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 20 Jun 2025 22:41:42 GMT Subject: [jdk25] RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args Message-ID: This needs to be backported ------------- Commit messages: - Backport 81985d422d3a433c1248deec18e4fd9b9f780c2c Changes: https://git.openjdk.org/jdk/pull/25921/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25921&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358526 Stats: 52 lines in 2 files changed: 51 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25921.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25921/head:pull/25921 PR: https://git.openjdk.org/jdk/pull/25921 From honkar at openjdk.org Fri Jun 20 22:47:29 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 20 Jun 2025 22:47:29 GMT Subject: [jdk25] RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 22:37:16 GMT, Phil Race wrote: > This needs to be backported Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25921#pullrequestreview-2947388094 From serb at openjdk.org Sat Jun 21 00:20:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 21 Jun 2025 00:20:30 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: <-3XHdE_t-sAawF_jLCHjisZn4JcGLuYpkn1odm8neO4=.69404e00-5ea5-4191-96e1-420f83e24355@github.com> References: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> <-3XHdE_t-sAawF_jLCHjisZn4JcGLuYpkn1odm8neO4=.69404e00-5ea5-4191-96e1-420f83e24355@github.com> Message-ID: <_GBNjG32VmqYwLAReCdOQSiG1H8wS8J7RBHNRW3uOog=.37ec9319-bceb-49f2-bf79-0555669ef1c9@github.com> On Fri, 20 Jun 2025 20:35:52 GMT, Alexey Ivanov wrote: >What I mean is two threads that called GraphicsDevice.getFullScreenWindow still established a happens-before relation for each call, which will be gone with the volatile modifier. >It may be fine? or may be not? this is why I'm asking. That only affects the case where the second thread tries to read shared data (unrelated to GraphicsDevice) without synchronization, which was written before the first thread called getFullScreenWindow(). If visibility is required, it should be ensured by the caller. Depending on some internal and undocumented lock for that is not a good thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2159783549 From serb at openjdk.org Sat Jun 21 02:57:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 21 Jun 2025 02:57:32 GMT Subject: RFR: 8359430: Test 'javax/swing/plaf/windows/bug4991587.java' automatically failed on Windows 2025 x64 with message "Failed. Compilation failed: Compilation failed" In-Reply-To: References: <414k9GtbyCEvEah6rhM_FpKzk2NXPBucKeWFl2PXz9E=.57a79e6c-5fa4-4528-87e2-749097d16558@github.com> Message-ID: On Fri, 20 Jun 2025 12:35:12 GMT, Alexey Ivanov wrote: >This specific bug was for Windows only, the fix was presumably in Windows-only code, this is why I don't care much about other L&F. It does not matter where the bug was if it can be reproduced via the public API. It is quite common for a test written for one platform later catch a bug on another. >Even if the text was displayed outside of the button, it was Windows-specific. How do we know that if we did not run the test on non-windows platforms? >Additionally, it's a manual test. If the test is automated, it makes more sense to test for all L&Fs; for a manual test, I'd rather avoid testing in other L&F because the bug never existed there. For a manual test it is unnecessary but I think it should be possible to automate. And checking of all L&F depends only on how the bug can be triggered and what is wrong. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25883#discussion_r2159839180 From mblaesing at openjdk.org Sun Jun 22 11:33:35 2025 From: mblaesing at openjdk.org (Matthias =?UTF-8?B?QmzDpHNpbmc=?=) Date: Sun, 22 Jun 2025 11:33:35 GMT Subject: [jdk25] RFR: 8353950: Clipboard interaction on Windows is unstable In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 20:29:18 GMT, Phil Race wrote: >> 8353950: Clipboard interaction on Windows is unstable > > Marked as reviewed by prr (Reviewer). @prrace thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25897#issuecomment-2994137070 From abhiscxk at openjdk.org Mon Jun 23 04:57:38 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 23 Jun 2025 04:57:38 GMT Subject: RFR: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java [v9] In-Reply-To: References: Message-ID: <4dYuOkXjeVNlKPsUYgZxV9zwAj_svWcWdZKzsB5K_To=.0c90152e-3043-4d11-a205-2d8268cc9abc@github.com> On Fri, 20 Jun 2025 19:06:09 GMT, Srinivas Mandalika wrote: >> Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. >> >> Modified Manual Test Passed when run using jtreg. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a small typo. > > Co-authored-by: Alexey Ivanov Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25842#pullrequestreview-2948654364 From smandalika at openjdk.org Mon Jun 23 04:57:38 2025 From: smandalika at openjdk.org (Srinivas Mandalika) Date: Mon, 23 Jun 2025 04:57:38 GMT Subject: Integrated: 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 04:55:05 GMT, Srinivas Mandalika wrote: > Use PassFailJFrame to streamline the test java/awt/print/Dialog/DialogType.java, as is for several of the manual tests. > > Modified Manual Test Passed when run using jtreg. This pull request has now been integrated. Changeset: de34bb8e Author: Srinivas Mandalika Committer: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/de34bb8e66253cef90ba79831dadec0252595b35 Stats: 64 lines in 1 file changed: 27 ins; 13 del; 24 mod 8359687: Use PassFailJFrame for java/awt/print/Dialog/DialogType.java Reviewed-by: abhiscxk, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/25842 From azvegint at openjdk.org Mon Jun 23 05:04:35 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 23 Jun 2025 05:04:35 GMT Subject: RFR: 8359996: Remove unnecessary List.indexOf key from Track.remove [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 20:28:42 GMT, Andrey Turbanov wrote: >> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. >> `eventsList` is an ArrayList. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8359996: Remove unnecessary List.indexOf key from Track.remove > > apply suggestion Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24818#pullrequestreview-2948668293 From tr at openjdk.org Mon Jun 23 05:33:29 2025 From: tr at openjdk.org (Tejesh R) Date: Mon, 23 Jun 2025 05:33:29 GMT Subject: [jdk25] RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 22:37:16 GMT, Phil Race wrote: > This needs to be backported Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25921#pullrequestreview-2948706216 From henryjen at openjdk.org Mon Jun 23 07:34:32 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 23 Jun 2025 07:34:32 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 01:51:28 GMT, Naoto Sato wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1: > >> 1: # > > Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though. I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html). If that was intentionally left out, I don't see new reason to add them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2160914804 From djelinski at openjdk.org Mon Jun 23 08:32:51 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 23 Jun 2025 08:32:51 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code [v2] In-Reply-To: References: Message-ID: > Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. > > I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25754/files - new: https://git.openjdk.org/jdk/pull/25754/files/4f508157..53b8f84b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25754&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25754&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25754/head:pull/25754 PR: https://git.openjdk.org/jdk/pull/25754 From djelinski at openjdk.org Mon Jun 23 08:32:51 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 23 Jun 2025 08:32:51 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 22:04:13 GMT, Sergey Bylokhov wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright > > Marked as reviewed by serb (Reviewer). Thanks @mrserb @prrace @aivanov-jdk for the reviews! Copyright year updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25754#issuecomment-2995444356 From djelinski at openjdk.org Mon Jun 23 08:32:52 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 23 Jun 2025 08:32:52 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code [v2] In-Reply-To: References: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com> Message-ID: <_F9C0U0OL9cONH_33a6rIwrqrurokPIwKTmp3zV9x_c=.c4b8dd8c-d03e-4651-b99f-4e0c00a756ca@github.com> On Thu, 19 Jun 2025 19:32:12 GMT, Alexey Ivanov wrote: >> just so we don't forget to add it when we modify the enclosing function. The call to `CallStaticBooleanMethod` is located pretty far from the end of the function, and can be easy to miss. > >> it wasn't always the case > > Does it mean that there was another up-call into Java before this method returns? yes, at least on Solaris we used to call other JNI methods after this one, see `parseExclusiveBindProperty` before 071bd521bca2485c6df95c45e4310d39b05bd046 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2161025223 From aturbanov at openjdk.org Mon Jun 23 08:34:37 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 23 Jun 2025 08:34:37 GMT Subject: Integrated: 8359996: Remove unnecessary List.indexOf key from Track.remove In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 08:53:57 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. > `eventsList` is an ArrayList. This pull request has now been integrated. Changeset: fe7ec312 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/fe7ec312590ed9f70e6caad4ef454123138bbbcf Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod 8359996: Remove unnecessary List.indexOf key from Track.remove Reviewed-by: aivanov, liach, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/24818 From ngubarkov at openjdk.org Mon Jun 23 10:54:34 2025 From: ngubarkov at openjdk.org (Nikita Gubarkov) Date: Mon, 23 Jun 2025 10:54:34 GMT Subject: Integrated: 8355904: Use variadic macros for J2dTrace In-Reply-To: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> References: <-9CAObCkXrOQCQ85CXnMswvDaWWA4OmBy699xKF2qpI=.c081bd7e-1a31-4e36-99d7-97bb2e005d83@github.com> Message-ID: On Tue, 29 Apr 2025 13:07:35 GMT, Nikita Gubarkov wrote: > J2dTrace macros have multiple overloads specifying number of arguments, making it less convent to change number of arguments. There were cases when existing macros were not enough and people had to add new variants with even more arguments. We could simply use variadic macros instead. > > Also, currently those macros expand to a { code block }, which doesn't require a semicolon at the end, so it can sometimes be missed, leading to an inconsistent code style. We could expand it directly to the function, forcing user to insert a semicolon after that, in a function-like style. This pull request has now been integrated. Changeset: 251f2ac7 Author: Nikita Gubarkov Committer: Alexey Ushakov URL: https://git.openjdk.org/jdk/commit/251f2ac785708a7ebf713d3fdc7d66317f1b2c2e Stats: 1148 lines in 64 files changed: 65 ins; 104 del; 979 mod 8355904: Use variadic macros for J2dTrace Reviewed-by: aivanov, serb, prr, avu ------------- PR: https://git.openjdk.org/jdk/pull/24949 From aivanov at openjdk.org Mon Jun 23 13:22:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 13:22:37 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v9] In-Reply-To: References: Message-ID: <50w959NA7UBm9xNh7VbGGYqXAwWRi2FcC_8PzqfDXEM=.c40ae585-7030-41d5-bb56-6e0118a8aa63@github.com> On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 There's a tiny suggestion left; it could be amended after this PR is integrated if not taken up here. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2950107360 From aivanov at openjdk.org Mon Jun 23 13:44:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 13:44:29 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 08:32:51 GMT, Daniel Jeli?ski wrote: >> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. >> >> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2950185657 From aivanov at openjdk.org Mon Jun 23 13:49:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 13:49:28 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code [v2] In-Reply-To: <_F9C0U0OL9cONH_33a6rIwrqrurokPIwKTmp3zV9x_c=.c4b8dd8c-d03e-4651-b99f-4e0c00a756ca@github.com> References: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com> <_F9C0U0OL9cONH_33a6rIwrqrurokPIwKTmp3zV9x_c=.c4b8dd8c-d03e-4651-b99f-4e0c00a756ca@github.com> Message-ID: On Mon, 23 Jun 2025 08:29:47 GMT, Daniel Jeli?ski wrote: >>> it wasn't always the case >> >> Does it mean that there was another up-call into Java before this method returns? > > yes, at least on Solaris we used to call other JNI methods after this one, see `parseExclusiveBindProperty` before 071bd521bca2485c6df95c45e4310d39b05bd046 Thank you! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2161682127 From jlu at openjdk.org Mon Jun 23 14:45:31 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 23 Jun 2025 14:45:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3] In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 18:48:04 GMT, Damon Nguyen wrote: >> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved. >> >> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year. > > Is there any way to prevent this or do we just change it back when we do a drop and explain why each time? If this is committed, then the years will be synced and we won't have to change it back. This would be consistent with the way we receive l10n translations which sync the copyright years of localized files to the original. If we want to deviate from this then we could file a request asking them to not update copyright years and we could update them ourselves. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161805058 From jlu at openjdk.org Mon Jun 23 14:57:30 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 23 Jun 2025 14:57:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 15:52:15 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220: > >> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert >> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert >> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen: > > Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings. I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161832785 From jlu at openjdk.org Mon Jun 23 15:00:37 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 23 Jun 2025 15:00:37 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 15:59:35 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229: > >> 227: doclet.search_in_documentation=In Dokumentation suchen >> 228: doclet.search_reset=Zur?cksetzen >> 229: doclet.Member=Member > > Is `Member` translated? Should it be _?Mitglied?_? Good catch. Usually, we file these issues with the translation team and make the appropriate updates in the second L10n drop. I think this one is fine to be updated now as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161839290 From abaya at openjdk.org Mon Jun 23 15:42:27 2025 From: abaya at openjdk.org (Anass Baya) Date: Mon, 23 Jun 2025 15:42:27 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 02:59:15 GMT, Sergey Bylokhov wrote: >> I cant reproduce it locally. >> I can see it only on CI 20/20 with the new test and 2/20 with the old one > > what is the stack trace when the new test fails? Hello @mrserb, What do you think about the test? Does it look good to you? KR, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2161927162 From duke at openjdk.org Mon Jun 23 16:02:35 2025 From: duke at openjdk.org (Jeremy Wood) Date: Mon, 23 Jun 2025 16:02:35 GMT Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v6] In-Reply-To: References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com> Message-ID: On Mon, 26 May 2025 05:30:55 GMT, Jeremy Wood wrote: >> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments. >> >> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work. >> >> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported. >> >> I have dozens of additional test cases for this problem, but unfortunately I don't have the rights to commit them to the OpenJDK repo. Feel free to email me for additional context/test cases. >> >> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler: >> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) >> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) >> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) >> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) (this one) > > Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision: > > 8356137: Adding copyright to GifComparison I'm assuming (?) there's a compelling reason to preserve the GifImageDecoder. ImageIO's decoder appears to avoid all the bugs I've observed in the ToolkitImage's implementation. If they are redundant: we could just rewrite the GifImageDecoder to rely on ImageIO . ------------- PR Comment: https://git.openjdk.org/jdk/pull/24271#issuecomment-2997036336 From achung at openjdk.org Mon Jun 23 16:38:29 2025 From: achung at openjdk.org (Alisen Chung) Date: Mon, 23 Jun 2025 16:38:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 20:37:43 GMT, Phil Race wrote: >> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460: >> >>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler >>> 459: SliderDemo.majorticks=Grobteilungen >>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen >> >> Should the translation of `SliderDemo.majorticks` also be updated? > > I agree. I'd expect consistency here. What would be the correct translation of majorticks here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162027420 From achung at openjdk.org Mon Jun 23 16:38:31 2025 From: achung at openjdk.org (Alisen Chung) Date: Mon, 23 Jun 2025 16:38:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 14:48:13 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix unicode escapes > > src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462: > >> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen >> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels >> 462: SliderDemo.minorticks=Feinteilungen > > The following description uses different words now: > > Feinteilungen -> Teilstrichen > Teilungen -> Teilstrichen Just to clarify, does this mean SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels SliderDemo.minorticks=Teilstrichen is correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162030543 From achung at openjdk.org Mon Jun 23 16:38:31 2025 From: achung at openjdk.org (Alisen Chung) Date: Mon, 23 Jun 2025 16:38:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Mon, 23 Jun 2025 07:31:34 GMT, Henry Jen wrote: >> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1: >> >>> 1: # >> >> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though. > > I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html). > If that was intentionally left out, I don't see new reason to add them. This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162024606 From achung at openjdk.org Mon Jun 23 16:44:23 2025 From: achung at openjdk.org (Alisen Chung) Date: Mon, 23 Jun 2025 16:44:23 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: References: Message-ID: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: update to german translations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25839/files - new: https://git.openjdk.org/jdk/pull/25839/files/66c34e7d..90bfd7bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From naoto at openjdk.org Mon Jun 23 16:44:24 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 23 Jun 2025 16:44:24 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Mon, 23 Jun 2025 16:32:21 GMT, Alisen Chung wrote: >> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html). >> If that was intentionally left out, I don't see new reason to add them. > > This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file? Thanks. I guess this was simply an overlook in the first place, as the process was manual back then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162038459 From azvegint at openjdk.org Mon Jun 23 17:08:36 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 23 Jun 2025 17:08:36 GMT Subject: [jdk25] RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 22:37:16 GMT, Phil Race wrote: > This needs to be backported Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25921#pullrequestreview-2950820820 From prr at openjdk.org Mon Jun 23 17:08:37 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 23 Jun 2025 17:08:37 GMT Subject: [jdk25] Integrated: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 22:37:16 GMT, Phil Race wrote: > This needs to be backported This pull request has now been integrated. Changeset: fe9efb75 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/fe9efb75b0521ea3eeadcbf4a80fa8797226344f Stats: 52 lines in 2 files changed: 51 ins; 0 del; 1 mod 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args Reviewed-by: honkar, tr, azvegint Backport-of: 81985d422d3a433c1248deec18e4fd9b9f780c2c ------------- PR: https://git.openjdk.org/jdk/pull/25921 From duke at openjdk.org Mon Jun 23 17:41:29 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Mon, 23 Jun 2025 17:41:29 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Mon, 23 Jun 2025 16:34:05 GMT, Alisen Chung wrote: >> I agree. I'd expect consistency here. > > What would be the correct translation of majorticks here? If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick"). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162131034 From abhiscxk at openjdk.org Mon Jun 23 17:45:46 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 23 Jun 2025 17:45:46 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character Message-ID: `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**. This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect. `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**. After modifying the condition check, expected character is returned. Test is added to verify the check, ------------- Commit messages: - TextComponent's getBeforeIndex boundary value check fix Changes: https://git.openjdk.org/jdk/pull/25941/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25941&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360070 Stats: 61 lines in 2 files changed: 59 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25941.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25941/head:pull/25941 PR: https://git.openjdk.org/jdk/pull/25941 From aivanov at openjdk.org Mon Jun 23 18:45:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 18:45:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: <9FQIYMoH-HEi7ktEzRGxRsoWXGPsDyWPWk3Ds0Edjy0=.5dcab616-2713-441b-b363-350ea62505e3@github.com> On Mon, 23 Jun 2025 14:55:08 GMT, Justin Lu wrote: >> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220: >> >>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert >>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert >>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen: >> >> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings. > > I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR". I see the entries for jar.signed.=jar signed. jar.verified.=jar verified. don't have the word *?file?*, whereas `?via.jarfile.and.jarinputstream` has it: ?This JAR *file*?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162318454 From prr at openjdk.org Mon Jun 23 18:58:32 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 23 Jun 2025 18:58:32 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v10] In-Reply-To: References: Message-ID: > This is the implementation of JEP 504 - Remove the Applet API. > API changes are > - Remove the entire java.applet package > - Remove the javax/swing/JApplet class > - Remove applet related APIs in java.beans > - Update javadoc referring to applets, including one gif image - now changed to an svg image > - > Other changes are > - Remove references to the removed classes > - Remove obsolete tests > - Update obsolete code comments > > sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, > and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same > release as this JEP is integrated. > > I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8359053 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25698/files - new: https://git.openjdk.org/jdk/pull/25698/files/253d2bc0..1d75d248 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=08-09 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25698.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698 PR: https://git.openjdk.org/jdk/pull/25698 From prr at openjdk.org Mon Jun 23 18:58:34 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 23 Jun 2025 18:58:34 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v10] In-Reply-To: References: Message-ID: <-rJLS1VZJfK5uk9gkurAPsiYDEqrO4E7lfn7g594wm4=.edd40711-b1d3-46fb-8b80-3dba2aba0bf7@github.com> On Mon, 9 Jun 2025 21:39:26 GMT, Phil Race wrote: >> PR for this issue has been created here: https://github.com/openjdk/jdk/pull/25703. > > noted. 8358729 is now pushed. So reverting Problem listing as expected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2162337149 From aivanov at openjdk.org Mon Jun 23 19:07:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 19:07:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Mon, 23 Jun 2025 17:38:58 GMT, Johannes D?bler wrote: >> What would be the correct translation of majorticks here? > > If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick"). Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162350461 From aivanov at openjdk.org Mon Jun 23 19:36:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 19:36:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Mon, 23 Jun 2025 16:36:00 GMT, Alisen Chung wrote: >> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462: >> >>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen >>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels >>> 462: SliderDemo.minorticks=Feinteilungen >> >> The following description uses different words now: >> >> Feinteilungen -> Teilstrichen >> Teilungen -> Teilstrichen > > Just to clarify, does this mean > > SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels > SliderDemo.minorticks=Teilstrichen > > is correct? Hm? I don't know. You should clarify with the translation team. They've changed the translation for the major ticks from *Grobteilungen* to *Hauptteilstriche*. Yet minor ticks remain *Feinteilungen*, which doesn't look right because the main word is different. (*Teilung* doesn't seem to be the right word, at least dictionaries translate it as ?division?.) *Teilstrich* means *scale line*, the marks on a ruler, so it fits. Microsoft documentation for [MinorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.minortickmark?view=openxml-3.0.1) uses *Kleinere Teilstriche*, yet I don't understand why there's ?-e? ending (plural?). SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels This one looks particularly incorrect; ?einrasten? is a verb with a separable prefix that means ?to lock?, and I can't find a usage as if it's a noun. The English phrase is ?Minor Ticks, Snap-to-ticks and Labels?, and I don't know how to correctly translate it to German. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162394521 From aivanov at openjdk.org Mon Jun 23 19:36:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 19:36:32 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Thu, 19 Jun 2025 17:39:38 GMT, Johannes D?bler wrote: >> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183: >> >>> 181: size.bit.alg=%1$d-Bit-%2$s >>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3} >>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4} >> >> It feels as if there's something missing after _?einem?_. > > seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162395125 From aivanov at openjdk.org Mon Jun 23 19:44:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 23 Jun 2025 19:44:45 GMT Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v10] In-Reply-To: References: Message-ID: <5hv53zmZA9kKblG14CHqjUjg1tXK_y6RePXkaRKbXAI=.0dc6287e-1af8-402f-862f-cc2da1075909@github.com> On Mon, 23 Jun 2025 18:58:32 GMT, Phil Race wrote: >> This is the implementation of JEP 504 - Remove the Applet API. >> API changes are >> - Remove the entire java.applet package >> - Remove the javax/swing/JApplet class >> - Remove applet related APIs in java.beans >> - Update javadoc referring to applets, including one gif image - now changed to an svg image >> - >> Other changes are >> - Remove references to the removed classes >> - Remove obsolete tests >> - Update obsolete code comments >> >> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required, >> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same >> release as this JEP is integrated. >> >> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8359053 Marked as reviewed by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 352: > 350: Dialog(owner, true), etc. Prior to JDK 6 > 351: the default type was toolkit-modal, > 352: and now with single application per-VM there is no Why is it ?per-VM? instead of ?per VM?? ??Single application per VM??, in this sentence ?per? is a preposition and ?VM? is a noun, don't you agree? There should be a space, not a hyphen. If it were ?per-VM application?, then it would be spelt with a hyphen. ------------- PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2951339948 PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2162407407 From serb at openjdk.org Mon Jun 23 19:46:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 23 Jun 2025 19:46:32 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 15:39:26 GMT, Anass Baya wrote: >> what is the stack trace when the new test fails? > > Hello @mrserb, > What do you think about the test? Does it look good to you? > KR, looking into it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2162410177 From duke at openjdk.org Mon Jun 23 21:19:35 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 23 Jun 2025 21:19:35 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v11] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 15:29:56 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove resetting description from constructor as it is already null > > src/java.desktop/share/classes/javax/swing/ImageIcon.java line 233: > >> 231: Object o = image.getProperty("comment", imageObserver); >> 232: if (o instanceof String) { >> 233: description = (String) o; > > To address [Phil's comment](https://github.com/openjdk/jdk/pull/25767/files#r2155610976): > >> This is wasted work if the app calls ImageIcon(Image, String) because that promptly over-writes whatever was obtained via this code. > > If we're going to change the constructors, to avoid *this wasted work* when `ImageIcon(Image, String)` constructor is called, I suggest moving the work into `ImageIcon(Image, String)` and implement `ImageIcon` like this: > > > public ImageIcon (Image image) { > String description = null; > if (image != null) { > Object o = image.getProperty("comment", null); > if (o instanceof String) { > description = (String) o; > } > } > this(image, description); > > It is allowed in JDK 22 and later. Note?that this?was a?preview language?feature until?**JDK?25**. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2162548529 From serb at openjdk.org Mon Jun 23 23:08:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 23 Jun 2025 23:08:30 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v8] In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 23:57:09 GMT, Anass Baya wrote: >> **Analysis:** >> >> We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). >> The race condition between the execution paths of these two native methods sometimes causes an exception >> >> **Proposed Fix:** >> >> While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number >> >> >> public void updateGC() { >> >> int scrn = getScreenImOn(); >> >> if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { >> log.finer("Screen number: " + scrn); >> } >> >> // get current GD >> Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); >> >> Win32GraphicsDevice newDev; >> GraphicsDevice[] devs = GraphicsEnvironment >> .getLocalGraphicsEnvironment() >> .getScreenDevices(); >> >> // Occasionally during device addition/removal getScreenImOn can return >> // a non-existing screen number. Use the default device in this case. >> if (scrn >= devs.length) { >> newDev = (Win32GraphicsDevice) GraphicsEnvironment >> .getLocalGraphicsEnvironment().getDefaultScreenDevice(); >> } else { >> newDev = (Win32GraphicsDevice) devs[scrn]; >> } >> } >> >> >> Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : >> >> jint AwtWindow::_GetScreenImOn(void *param) >> { >> ... >> jboolean destroyed = JNI_GET_DESTROYED(self); >> if (destroyed == JNI_TRUE){ >> env->DeleteGlobalRef(self); >> return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> } >> ... >> >> >> **Tests Summary:** >> >> GetGraphicsStressTest (existing test): >> >> Fails intermittently without the fix >> >> Consistently passes with the fix >> >> NotifyStressTest (newly added test): >> >> Consistently fails without the fix >> >> Consistently passes with the fix > > Anass Baya has updated the pull request incrementally with one additional commit since the last revision: > > Enhance the test test/jdk/java/awt/Frame/NotifyStressTest/NotifyStressTest.java line 57: > 55: for (int i = 0; i < 10; i++) { > 56: f.removeNotify(); > 57: f.addNotify(); Note that we call addNotify last, so the frame will not be disposed at the end of the test. btw, I cannot reproduce the bug even with the updated test. If you look at the stack trace, it seems the error comes from displayChanged, which is not triggered by the test itself ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2162664584 From serb at openjdk.org Mon Jun 23 23:11:34 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 23 Jun 2025 23:11:34 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v8] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 23:05:54 GMT, Sergey Bylokhov wrote: >> Anass Baya has updated the pull request incrementally with one additional commit since the last revision: >> >> Enhance the test > > test/jdk/java/awt/Frame/NotifyStressTest/NotifyStressTest.java line 57: > >> 55: for (int i = 0; i < 10; i++) { >> 56: f.removeNotify(); >> 57: f.addNotify(); > > Note that we call addNotify last, so the frame will not be disposed at the end of the test. > btw, I cannot reproduce the bug even with the updated test. If you look at the stack trace, it seems the error comes from displayChanged, which is not triggered by the test itself you can use this test: /* * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ import java.awt.Window; /** * @test * @bug 8346952 * @key headful */ public final class BogusFocusableWindowState { public static void main(String[] args) { Window frame = new Window(null) { @Override public boolean getFocusableWindowState() { removeNotify(); return true; } }; try { frame.pack(); frame.setVisible(true); } finally { frame.dispose(); } } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2162667111 From serb at openjdk.org Mon Jun 23 23:26:29 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 23 Jun 2025 23:26:29 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 17:40:42 GMT, Abhishek Kumar wrote: >getBeforeIndex method should return null only if the passed index parameter is less than 0 and greater than the text's length. I am not sure about the statement above. I think the check should take care of the direction, which is -1 in your case. This is actually properly handled by the code below(in t he same method you changed): if (index + direction < model.getLength() && index + direction >= 0) { return model.getText(index + direction, 1); } The code you added also affects WORD and SENTENCE cases. I suggest covering those with a test as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-2998264339 From serb at openjdk.org Mon Jun 23 23:34:27 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 23 Jun 2025 23:34:27 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 07:59:57 GMT, Prasanta Sadhukhan wrote: >so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead Does macOS have equivalent shortcuts for the native tree component? >No regression test as it can be verified through SwingSet2 demo as below.. I doubt anyone will run SwingSet2 in the future specifically to test this bug. The original issue was reported due to a failing test. If that test is no longer available, it would be better to create a new one to cover this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-2998277090 From ljnelson at gmail.com Tue Jun 24 02:03:06 2025 From: ljnelson at gmail.com (Laird Nelson) Date: Mon, 23 Jun 2025 19:03:06 -0700 Subject: "Smudge" factor on Mac OSX mouse events? Message-ID: (Disclaimer: I happen to work for Oracle but this has nothing to do with my job.) I have been having trouble double-clicking things with my Apple Magic Mouse on my M1 Mac when running (Swing-based) Netbeans (see https://github.com/apache/netbeans/issues/8609 and the inciting discussion at https://github.com/apache/netbeans/discussions/8580). I noticed that perhaps (?) this is due to the lack of a "smudge factor" correcting for inadvertent tiny mouse motion events while double clicking. It seems, perhaps, that the Magic Mouse is very finicky in this area where the built-in Mac trackpad is not. At any rate, the XWindows toolkit has this: https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java#L71-L75 But perhaps (?) the analogous Mac OSX area does not: https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java#L71-L79 and it seems like this might result in the observed behavior. Is this a bug or works-as-it-does? Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: From mvs at openjdk.org Tue Jun 24 02:23:40 2025 From: mvs at openjdk.org (Manukumar V S) Date: Tue, 24 Jun 2025 02:23:40 GMT Subject: Integrated: 8358697: TextLayout/MyanmarTextTest.java passes if no Myanmar font is found In-Reply-To: References: Message-ID: <8hY9hLmzV_fqYHujEbLN7rvcl2NPQ5ny9EOTMdN8d1U=.2118e35c-8c8a-4dea-9a00-287a4d40bea7@github.com> On Wed, 18 Jun 2025 16:20:14 GMT, Manukumar V S wrote: > Issue: > MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. > > Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. > > Fix: > Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. > > Testing: > Tested using mach5 in all available platforms and got full PASS. This pull request has now been integrated. Changeset: bcad87ea Author: Manukumar V S Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec Stats: 33 lines in 1 file changed: 7 ins; 14 del; 12 mod 8358697: TextLayout/MyanmarTextTest.java passes if no Myanmar font is found Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/25879 From syan at openjdk.org Tue Jun 24 02:23:39 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 24 Jun 2025 02:23:39 GMT Subject: RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no Myanmar font is found [v6] In-Reply-To: <1dLK-TdHycvdgZ63-6WXfDQF-m-00Ra1N-Vlbqd96UU=.fe0c34b9-5d00-4551-8745-2f5746d80354@github.com> References: <1dLK-TdHycvdgZ63-6WXfDQF-m-00Ra1N-Vlbqd96UU=.fe0c34b9-5d00-4551-8745-2f5746d80354@github.com> Message-ID: On Thu, 19 Jun 2025 11:11:32 GMT, Manukumar V S wrote: >> Issue: >> MyanmarTextTest.java produces a false positive result when some of the test preconditions are not met. It checks whether certain fonts are present in the system, for example, 'Padauk' on Linux. If the required font is missing, the test simply returns early, and the test ends up passing, which is incorrect. Ideally, it should throw a jtreg.SkippedException when the necessary preconditions are not satisfied. >> >> Another scenario is that the test passes on headless machines even though it creates GUI components. Ideally, when GUI components are created in code running on a headless machine, a HeadlessException should be thrown. However, since MyanmarTextTest.java exits before reaching the point where the GUI is created (due to unmet preconditions), it incorrectly reports a pass. This behavior may lead to a misinterpretation of the test as being headless, which it is not. >> >> Fix: >> Need to throw jtreg.SkippedException in cases where some pre-conditions for running the test are not met. >> >> Testing: >> Tested using mach5 in all available platforms and got full PASS. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes, removed unwanted code Test-fix only, throw SkippedException instead print the message. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25879#issuecomment-2998549922 From syan at openjdk.org Tue Jun 24 02:34:11 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 24 Jun 2025 02:34:11 GMT Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no Myanmar font is found Message-ID: Hi all, This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov. Thanks! ------------- Commit messages: - Backport bcad87eacbd7fbfd3254479b7e061bab34e64aec Changes: https://git.openjdk.org/jdk/pull/25946/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25946&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358697 Stats: 33 lines in 1 file changed: 7 ins; 14 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/25946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25946/head:pull/25946 PR: https://git.openjdk.org/jdk/pull/25946 From cstein at openjdk.org Tue Jun 24 05:15:34 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 24 Jun 2025 05:15:34 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Mon, 23 Jun 2025 19:04:22 GMT, Alexey Ivanov wrote: >> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick"). > > Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct. Ja, "Hauptteilstrich" and "Hauptteilstriche" (pl) are correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162975420 From cstein at openjdk.org Tue Jun 24 05:22:33 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 24 Jun 2025 05:22:33 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> References: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> Message-ID: On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > update to german translations src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462: > 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen > 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels > 462: SliderDemo.minorticks=Feinteilungen For consistency with the "Hilfsteilstrich" (singular) and "Hilfsteilstriche" (plural) used below in `SliderDemo.minorticksdescription` and `SliderDemo.disableddescription`, I'd suggest to use: Suggestion: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften SliderDemo.minorticks=Hilfsteilstriche As "Labels" is not a German word. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162982972 From cstein at openjdk.org Tue Jun 24 05:34:31 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 24 Jun 2025 05:34:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> References: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> Message-ID: <8Orj0J7-iUsSjTQEc7t-pSShM2wHGmfReMStzGByHGY=.41967017-0e70-4e2a-9133-f84fd263ff51@github.com> On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > update to german translations src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 178: > 176: javac.opt.Xlint.desc.restricted=Warnt vor der Verwendung eingeschr?nkter Methoden. > 177: > 178: javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "Identit?t", die dieselben Verwendungen und\n Effekte hat. Benutzern wird empfohlen, die Kategorie "Identit?t" f?r alle zuk?nftigen\n und vorhandenen Verwendungen von "Synchronisierung" zu verwenden. "Identit?t" and "Synchronisierung" are literals that must not be translated. The English base entry reads: javac.opt.Xlint.desc.synchronization=\ Warn about synchronization attempts on instances of value-based classes.\n\ \ This key is a deprecated alias for ''identity'', which has the same uses and\n\ \ effects. Users are encouraged to use the ''identity'' category for all future\n\ \ and existing uses of ''synchronization''. And `javac --help-lint` contains: strictfp Warn about unnecessary use of the strictfp modifier. synchronization Warn about synchronization attempts on instances of value-based classes. text-blocks Warn about inconsistent white space characters in text block indentation. Suggestion: javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "identity", die dieselben Verwendungen und\n Effekte hat. Benutzern wird empfohlen, die Kategorie "identity" f?r alle zuk?nftigen\n und vorhandenen Verwendungen von "synchronization" zu verwenden. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162995954 From psadhukhan at openjdk.org Tue Jun 24 05:42:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 24 Jun 2025 05:42:04 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v27] In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: > When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. > If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/bfc108e3..898996a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=25-26 Stats: 39 lines in 1 file changed: 38 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324 PR: https://git.openjdk.org/jdk/pull/23324 From aivanov at openjdk.org Tue Jun 24 05:42:04 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 24 Jun 2025 05:42:04 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v26] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 19 Jun 2025 06:06:23 GMT, Prasanta Sadhukhan wrote: > > > In SwingSet2, now there will be gap between bullet and text to accomodate non-existing imageicon > > > > > > That gap should only be there if _at least one_ menu item has an image icon. It shoudn't be there if none have an icon. > > That will require to find out if current menuItem is part of ButtonGroup and then reiterate each menuitems of the ButtonGroup and see if anyone has an imageicon..It does not seem possible to find out from current menuItem if it part of ButtonGroup as that info is not passed to each MenuItemUI (ButtonGroup info is only known to application/user) Why? This depends on two factors only: 1. Are there any instances of `JCheckBoxMenuItem` or `JRadioButtonMenuItem`, and 2. Does any of them contain an icon? If both are true, you add two columns for the *mark* and for the *icon*; in all other cases, the layout remains as it is now with one column where icons and marks are rendered. The above is done in Metal L&F (run the test case in the default L&F), why can't it be done in Windows L&F? > Also, assuming if we do find a way to get if this menuItem is part of a ButtonGroup, then iterating everytime to find out if any menu item has imageicon will affect performance. Probably it's better to reserve space for imageicon even if not present.. No, I don't think it's a good approach. Look at how it's done in Metal, ideally re-use the layout code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2987450656 From psadhukhan at openjdk.org Tue Jun 24 05:42:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 24 Jun 2025 05:42:04 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v26] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 19 Jun 2025 09:45:14 GMT, Alexey Ivanov wrote: > > In SwingSet2, now there will be gap between bullet and text to accomodate non-existing imageicon > > That gap should only be there if _at least one_ menu item has an image icon. It shoudn't be there if none have an icon. @prrace Fixed now in latest iteration ![image](https://github.com/user-attachments/assets/9d921443-ea59-4969-aa09-3291c01b9113) SwingSet2 there's no gap for RBMI since there are no imageicons ![image](https://github.com/user-attachments/assets/f1e5499a-dd8d-4d03-a4bc-00c00f0fe98e) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2998889287 From cstein at openjdk.org Tue Jun 24 05:44:30 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 24 Jun 2025 05:44:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> References: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> Message-ID: On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > update to german translations src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties line 103: > 101: > 102: # 0: string > 103: launcher.err.cant.find.main.method=main(String[])- oder main()-Methode nicht gefunden in Klasse: {0} Suggestion: launcher.err.cant.find.main.method=Konnte keine main(String[])- oder main()-Methode in der Klasse: {0} finden. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2163006433 From mickleness at gmail.com Tue Jun 24 05:54:41 2025 From: mickleness at gmail.com (Jeremy Wood) Date: Tue, 24 Jun 2025 05:54:41 +0000 Subject: "Smudge" factor on Mac OSX mouse events? In-Reply-To: References: Message-ID: I can?t speak to the Apple Magic Mouse specifically, but at my old job we wrote a work-around for a very similar-sounding complaint: we received MOUSE_PRESSED and MOUSE_RELEASED events just fine, but we didn?t receive MOUSE_CLICKED events unless the mouse location stayed exactly the same. This came up because some of our users were kindergarteners, and they often lacked the fine motor schools to tap touchpads in exactly the same spot. IMO I?d also consider these complaints bugs, but I?m not an OpenJDK member and I certainly don?t have the historical knowledge that some people here might have about whether this is intentional or not. I?m curious to see what other folks say?? Regards, - Jeremy ------ Original Message ------ >From "Laird Nelson" To client-libs-dev at openjdk.org Date 6/23/2025 10:03:06?PM Subject "Smudge" factor on Mac OSX mouse events? >(Disclaimer: I happen to work for Oracle but this has nothing to do >with my job.) > >I have been having trouble double-clicking things with my Apple Magic >Mouse on my M1 Mac when running (Swing-based) Netbeans (see >https://github.com/apache/netbeans/issues/8609 and the inciting >discussion at https://github.com/apache/netbeans/discussions/8580). I >noticed that perhaps (?) this is due to the lack of a "smudge factor" >correcting for inadvertent tiny mouse motion events while double >clicking. It seems, perhaps, that the Magic Mouse is very finicky in >this area where the built-in Mac trackpad is not. > >At any rate, the XWindows toolkit has this: >https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java#L71-L75 > >But perhaps (?) the analogous Mac OSX area does not: >https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java#L71-L79 >and it seems like this might result in the observed behavior. > >Is this a bug or works-as-it-does? > >Best, >Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Tue Jun 24 06:11:39 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 24 Jun 2025 06:11:39 GMT Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code [v2] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 13:41:38 GMT, Alexey Ivanov wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright > > Marked as reviewed by aivanov (Reviewer). Thanks @aivanov-jdk for the re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25754#issuecomment-2998947207 From djelinski at openjdk.org Tue Jun 24 06:11:39 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 24 Jun 2025 06:11:39 GMT Subject: Integrated: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code In-Reply-To: References: Message-ID: On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski wrote: > Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test. > > I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass. This pull request has now been integrated. Changeset: dbbfa76b Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/dbbfa76b7335291b4bb9d8de6e7db8e6cec144ce Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code Reviewed-by: aivanov, prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/25754 From ljnelson at gmail.com Tue Jun 24 06:38:29 2025 From: ljnelson at gmail.com (Laird Nelson) Date: Mon, 23 Jun 2025 23:38:29 -0700 Subject: "Smudge" factor on Mac OSX mouse events? In-Reply-To: References: Message-ID: On Mon, Jun 23, 2025 at 10:54?PM Jeremy Wood wrote: > I can?t speak to the Apple Magic Mouse specifically, but at my old job we > wrote a work-around > > for a very similar-sounding complaint: we received MOUSE_PRESSED and > MOUSE_RELEASED events just fine, but we didn?t receive MOUSE_CLICKED events > unless the mouse location stayed exactly the same. > Right; that seems to be what happens in every platform-specific AWT machinery in the JDK except the XWindows one, to my na?ve reading, which "solves" the issue by saying, well, if the mouse didn't move more than {checks notes} four pixels (the "smudge factor"), we're good. On the Mac with its built-in trackpad (and maybe with wired external mice, or others) this hack doesn't appear to be necessary, but I wonder if the Magic Mouse is exhibiting the same sort of behavior that originally led the XWindows-specific JDK machinery author to introduce the four-pixel "smudge factor" for that platform. Perhaps it should be introduced for the Mac as well. L -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhiscxk at openjdk.org Tue Jun 24 11:14:50 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 24 Jun 2025 11:14:50 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character [v2] In-Reply-To: References: Message-ID: > `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**. > This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect. > `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**. > > After modifying the condition check, expected character is returned. Test is added to verify the check, Abhishek Kumar has updated the pull request 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 - TextComponent's getBeforeIndex boundary value check fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25941/files - new: https://git.openjdk.org/jdk/pull/25941/files/6e5eef63..b7852974 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25941&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25941&range=00-01 Stats: 52056 lines in 1209 files changed: 35231 ins; 10992 del; 5833 mod Patch: https://git.openjdk.org/jdk/pull/25941.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25941/head:pull/25941 PR: https://git.openjdk.org/jdk/pull/25941 From abhiscxk at openjdk.org Tue Jun 24 11:36:27 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 24 Jun 2025 11:36:27 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 23:24:14 GMT, Sergey Bylokhov wrote: > I am not sure about the statement above. I think the check should take care of the direction, which is -1 in your case I think the check is to ensure the passed index parameter is to verify the boundary of text length. > This is actually properly handled by the code below(in t he same method you changed): If the `index` is equal to the the `text length`, the returned character from the `getBeforeIndex` should return the last character i.e. 6 but the existing condition evaluates to `true` due to `index equals to model.getLength()` and method returns `null`. So, even the `direction` is handled correctly below, execution doesn't reach to that point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-2999976301 From abhiscxk at openjdk.org Tue Jun 24 11:44:13 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 24 Jun 2025 11:44:13 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character [v3] In-Reply-To: References: Message-ID: > `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**. > This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect. > `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**. > > After modifying the condition check, expected character is returned. Test is added to verify the check, Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Test extended for WORD and SENTENCE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25941/files - new: https://git.openjdk.org/jdk/pull/25941/files/b7852974..e9c5ae37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25941&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25941&range=01-02 Stats: 21 lines in 1 file changed: 14 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25941.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25941/head:pull/25941 PR: https://git.openjdk.org/jdk/pull/25941 From abhiscxk at openjdk.org Tue Jun 24 11:47:27 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 24 Jun 2025 11:47:27 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 23:24:14 GMT, Sergey Bylokhov wrote: >> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**. >> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect. >> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**. >> >> After modifying the condition check, expected character is returned. Test is added to verify the check, > >>getBeforeIndex method should return null only if the passed index parameter is less than 0 and greater than the text's length. > > I am not sure about the statement above. I think the check should take care of the direction, which is -1 in your case. This is actually properly handled by the code below(in t he same method you changed): > > if (index + direction < model.getLength() && > index + direction >= 0) { > return model.getText(index + direction, 1); > } > > The code you added also affects WORD and SENTENCE cases. I suggest covering those with a test as well. > @mrserb The code you added also affects WORD and SENTENCE cases. I suggest covering those with a test as well. Yes, that affects the WORD and SENTENCE cases. I have extended the test to cover them. Before the fix the returned value for WORD and SENTENCE is null that seems incorrect as well. I think the return string in case of WORD should be `Test6` and SENTENCE should be `Test4 Test5. ` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3000004752 From psadhukhan at openjdk.org Tue Jun 24 12:11:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 24 Jun 2025 12:11:52 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF [v2] In-Reply-To: References: Message-ID: > There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY)..... > Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them > so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead > > No regression test as it can be verified through SwingSet2 demo as below.. > > With ctrl+shift+down > Screenshot 2025-06-19 at 1 41 39?PM > > another ctrl+shift+down > Screenshot 2025-06-19 at 1 42 39?PM > > Now, ctrl+shift+up > Screenshot 2025-06-19 at 1 44 51?PM Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25892/files - new: https://git.openjdk.org/jdk/pull/25892/files/e5bc5d01..3db32cd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25892&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25892&range=00-01 Stats: 101 lines in 1 file changed: 101 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25892/head:pull/25892 PR: https://git.openjdk.org/jdk/pull/25892 From psadhukhan at openjdk.org Tue Jun 24 12:11:53 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 24 Jun 2025 12:11:53 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 07:59:57 GMT, Prasanta Sadhukhan wrote: > There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY)..... > Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them > so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead > > No regression test as it can be verified through SwingSet2 demo as below.. > > With ctrl+shift+down > Screenshot 2025-06-19 at 1 41 39?PM > > another ctrl+shift+down > Screenshot 2025-06-19 at 1 42 39?PM > > Now, ctrl+shift+up > Screenshot 2025-06-19 at 1 44 51?PM I couldn't find native tree component in any native app. Regression Test added ------------- PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-3000089478 From aivanov at openjdk.org Tue Jun 24 12:21:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 24 Jun 2025 12:21:28 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character [v3] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 11:44:13 GMT, Abhishek Kumar wrote: >> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**. >> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect. >> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**. >> >> After modifying the condition check, expected character is returned. Test is added to verify the check, > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Test extended for WORD and SENTENCE Marked as reviewed by aivanov (Reviewer). test/jdk/javax/accessibility/TestAccessibleTextBoundaryValue.java line 69: > 67: if (!expected.equals(actual)) { > 68: throw new RuntimeException("The actual result does not match " + > 69: "the expected result."); Why not include the values in the error message? Suggestion: throw new RuntimeException("Result doesn't match: '" + actual + "' vs. '" + expected + "'"); ------------- PR Review: https://git.openjdk.org/jdk/pull/25941#pullrequestreview-2953565277 PR Review Comment: https://git.openjdk.org/jdk/pull/25941#discussion_r2163825211 From aivanov at openjdk.org Tue Jun 24 12:42:33 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 24 Jun 2025 12:42:33 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan wrote: > Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F. > This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon. > > Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F.. This is an invalid test. The L&F has to applied to entire component tree after the application changes it. One has not to expect anything to work correctly if the L&F is changed on the fly. In this test, the L&F is set before menu items are created. Depending on the L&F internals, it may display well or not; for Windows L&F it doesn't. The test has to be re-written so that a L&F is changed and the entire component tree is updated, at this pointer the tester verifies how menu items look. Then the L&F can be changed to a next one. Ideally, all the installed L&Fs should be tested. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25907#pullrequestreview-2953647827 From aivanov at openjdk.org Tue Jun 24 12:46:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 24 Jun 2025 12:46:38 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: References: Message-ID: <2rlz1PHVZ5WmsWgjyZ92eTC-Y3dNXnn94QlXBHTZX-g=.90339adc-a821-434c-8783-8ff73f35a5e8@github.com> On Fri, 20 Jun 2025 22:22:53 GMT, Harshitha Onkar wrote: >> Clarify the behaviour of new HeadlessException().getMessage() >> The spec. is updated to be clear that empty means null, not an empty string. > > test/jdk/java/awt/Headless/HeadlessExceptionTest.java line 37: > >> 35: public static void main (String[] args) { >> 36: String nullmsg = new HeadlessException().getMessage(); >> 37: String emptymsg = new HeadlessException("").getMessage(); > > @prrace I was thinking of a case which would actually throw HeadlessException when run with `Djava.awt.headless=true` such as creating a frame or robot but the exception msg can be null or default message from GraphicsEnvironment so making it difficult to validate on different platforms. The current test works well to validate both empty and null message. Since this test is run on *headless* hosts, the default headless message will always be present on Linux, therefore `nullmsg` will not be `null`. If the test is run on headful hosts, the message should be `null` and empty string correspondingly. @honkar-jdk Do you suggest a test needs expanding to cover both cases where the default headless message is present or not? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25881#discussion_r2163891474 From aivanov at openjdk.org Tue Jun 24 12:52:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 24 Jun 2025 12:52:32 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: <_GBNjG32VmqYwLAReCdOQSiG1H8wS8J7RBHNRW3uOog=.37ec9319-bceb-49f2-bf79-0555669ef1c9@github.com> References: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> <-3XHdE_t-sAawF_jLCHjisZn4JcGLuYpkn1odm8neO4=.69404e00-5ea5-4191-96e1-420f83e24355@github.com> <_GBNjG32VmqYwLAReCdOQSiG1H8wS8J7RBHNRW3uOog=.37ec9319-bceb-49f2-bf79-0555669ef1c9@github.com> Message-ID: On Sat, 21 Jun 2025 00:17:26 GMT, Sergey Bylokhov wrote: > That only affects the case where the second thread tries to read shared data (unrelated to GraphicsDevice) without synchronization, which was written before the first thread called getFullScreenWindow(). If visibility is required, it should be ensured by the caller. Depending on some internal and undocumented lock for that is not a good thing. It is true? but it affects the fields of the full screen window itself. Doesn't any code path uses the fields of the full screen window after getting an object reference to it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2163916863 From aivanov at openjdk.org Tue Jun 24 14:03:34 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 24 Jun 2025 14:03:34 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v11] In-Reply-To: References: Message-ID: <6zA_Ov7yomMGPHkeHf3g8F513Cqr_mzF2EeZTrV3JcU=.2c228efa-548f-493d-94ad-365acd592cd4@github.com> On Mon, 23 Jun 2025 21:17:05 GMT, ExE Boss wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 233: >> >>> 231: Object o = image.getProperty("comment", imageObserver); >>> 232: if (o instanceof String) { >>> 233: description = (String) o; >> >> To address [Phil's comment](https://github.com/openjdk/jdk/pull/25767/files#r2155610976): >> >>> This is wasted work if the app calls ImageIcon(Image, String) because that promptly over-writes whatever was obtained via this code. >> >> If we're going to change the constructors, to avoid *this wasted work* when `ImageIcon(Image, String)` constructor is called, I suggest moving the work into `ImageIcon(Image, String)` and implement `ImageIcon` like this: >> >> >> public ImageIcon (Image image) { >> String description = null; >> if (image != null) { >> Object o = image.getProperty("comment", null); >> if (o instanceof String) { >> description = (String) o; >> } >> } >> this(image, description); >> >> It is allowed in JDK 22 and later. > > Note?that this?was a?preview language?feature until?**JDK?25**. I haven't done my due diligence to verify whether this feature can be used. Even if this particular way can't be used, it's still a viable option, just move the code above into a helper method. public ImageIcon(Image image, String description) { this.image = image; this.description = description; loadImage(image); } public ImageIcon (Image image) { this(image, getImageComment(image)); } /** * {@return the {@code "comment"} property of the image * if the value of the property is a sting} * @param image the image to get the {@code "comment"} property */ private static String getImageComment(Image image) { if (image == null) { return null; } Object o = image.getProperty("comment", null); return (o instanceof String) ? (String) o : null; } This should be done separately from this changeset, I think, to have shorter, more specific changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2164102520 From weijun at openjdk.org Tue Jun 24 14:56:30 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 24 Jun 2025 14:56:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: On Wed, 18 Jun 2025 16:43:02 GMT, Alexey Ivanov wrote: >> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language. > > Thank you for the clarification. However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164251035 From weijun at openjdk.org Tue Jun 24 15:01:31 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 24 Jun 2025 15:01:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> Message-ID: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com> On Tue, 24 Jun 2025 14:54:17 GMT, Weijun Wang wrote: >> Thank you for the clarification. > > However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????". Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164261187 From weijun at openjdk.org Tue Jun 24 15:01:30 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 24 Jun 2025 15:01:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> References: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> Message-ID: On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > update to german translations src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49: > 47: .Principal.=\t????\u0020 > 48: .Public.Credential.=\t??????:\u0020 > 49: .Private.Credential.=\t??????:\u0020 Why aren't the 2 lines above updated like in lines 46 and 47? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164262664 From psadhukhan at openjdk.org Tue Jun 24 16:17:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 24 Jun 2025 16:17:30 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: References: Message-ID: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan wrote: > Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F. > This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon. > > Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F.. I dont think the test is invalid..It was in closed repo and tested for so many years before it got opensourced L&F is anyway applied to entire component tree in the fix via `SwingUtilities.updateComponentTreeUI(frame);` Similar method was used in opensourced test javax/swing/JTabbedPane/bug4499556.java by @prrace ..Its the similar strategy used in many closed/open manual tests for testing different L&Fs in applet era @prrace Any comments on this test regarding its validity and fix? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3001105201 From honkar at openjdk.org Tue Jun 24 17:15:41 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 24 Jun 2025 17:15:41 GMT Subject: RFR: 8358526: Clarify behavior of java.awt.HeadlessException constructed with no-args In-Reply-To: <2rlz1PHVZ5WmsWgjyZ92eTC-Y3dNXnn94QlXBHTZX-g=.90339adc-a821-434c-8783-8ff73f35a5e8@github.com> References: <2rlz1PHVZ5WmsWgjyZ92eTC-Y3dNXnn94QlXBHTZX-g=.90339adc-a821-434c-8783-8ff73f35a5e8@github.com> Message-ID: <8EGZZufP2AXzRgb0BGrANjXlz5f9lcOJkKiDEVKIuMs=.7568535a-f57e-40ff-b68a-77daaecbd5fe@github.com> On Tue, 24 Jun 2025 12:43:37 GMT, Alexey Ivanov wrote: >> test/jdk/java/awt/Headless/HeadlessExceptionTest.java line 37: >> >>> 35: public static void main (String[] args) { >>> 36: String nullmsg = new HeadlessException().getMessage(); >>> 37: String emptymsg = new HeadlessException("").getMessage(); >> >> @prrace I was thinking of a case which would actually throw HeadlessException when run with `Djava.awt.headless=true` such as creating a frame or robot but the exception msg can be null or default message from GraphicsEnvironment so making it difficult to validate on different platforms. The current test works well to validate both empty and null message. > > Since this test is run on *headless* hosts, the default headless message will always be present on Linux, therefore `nullmsg` will not be `null`. > > If the test is run on headful hosts, the message should be `null` and empty string correspondingly. > > @honkar-jdk Do you suggest a test needs expanding to cover both cases where the default headless message is present or not? @aivanov-jdk > Since this test is run on headless hosts, the default headless message will always be present on Linux, therefore nullmsg will not be null. That is correct Alex. But since this default headless message is platform and GraphicsEnvironment specific, checking for specific message may not feasible. Did you mean checking for non-null msg (on headless)? May be it is not as important as the cases already being tested in the reg test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25881#discussion_r2164521752 From aivanov at openjdk.org Tue Jun 24 17:26:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 24 Jun 2025 17:26:27 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> References: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> Message-ID: On Tue, 24 Jun 2025 16:14:28 GMT, Prasanta Sadhukhan wrote: > I dont think the test is invalid..It was in closed repo and tested for so many years before it got opensourced L&F is anyway applied to entire component tree in the fix via `SwingUtilities.updateComponentTreeUI(frame);` I believe what fixed the test is that you removed the line `UIManager.setLookAndFeel(save)` which restored the L&F to whatever L&F that was set before at the time when the test started, in this particular case Nimbus L&F according to the bug description. This ensures the current L&F remains Windows L&F so that the missing resources are now found. If there were another L&F to test, or if Windows L&F weren't the last in the list, the test will continue to fail because the current L&F will again be different from Windows L&F. Indeed, it does. If I comment out `UIManager.setLookAndFeel(save)` from the original test code, the menu items under Windows do have check marks and bullets. At the same time, `SwingUtilities.updateComponentTreeUI(frame)` has no effect? however, it does change the L&F of the menu bar and the menu items on the menu bar. The menu items that are displayed in popups aren't visible and aren't part of the component hierarchy, therefore they remain at the assigned L&F which was active when they were created. > Similar method was used in opensourced test javax/swing/JTabbedPane/bug4499556.java by @prrace ..Its the similar strategy used in many closed/open manual tests for testing different L&Fs in applet era Yes, I've seen other tests which employ this strategy? where several components in a container are created with different L&Fs. And often everything seem to work? except for the cases where it doesn't. This is the case where it doesn't? Continuing with my example above where I commented out the line `UIManager.setLookAndFeel(save)`, the **Windows** menu looks good but clicking the **Metal** menu now throws NPE: java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null at java.desktop/sun.font.FontDesignMetrics$MetricsKey.init(FontDesignMetrics.java:213) at java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:282) at java.desktop/sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1235) at java.desktop/javax.swing.JComponent.getFontMetrics(JComponent.java:1700) at java.desktop/sun.swing.MenuItemLayoutHelper.reset(MenuItemLayoutHelper.java:126) at java.desktop/javax.swing.plaf.synth.SynthMenuItemLayoutHelper.(SynthMenuItemLayoutHelper.java:118) at java.desktop/javax.swing.plaf.synth.SynthGraphicsUtils.paint(SynthGraphicsUtils.java:578) at java.desktop/javax.swing.plaf.synth.SynthMenuUI.paint(SynthMenuUI.java:278) at java.desktop/javax.swing.plaf.synth.SynthMenuUI.update(SynthMenuUI.java:245) at java.desktop/javax.swing.JComponent.paintComponent(JComponent.java:852) at java.desktop/javax.swing.JComponent.paint(JComponent.java:1128) at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:961) at java.desktop/javax.swing.JComponent.paint(JComponent.java:1137) at java.desktop/javax.swing.JComponent.paintToOffscreen(JComponent.java:5324) This makes sense, the **Metal** menu itself was created while Nimbus was the active L&F. (Yes, you moved the menu creation after the new L&F was set.) This just proves my point that multiple L&Fs aren't really supported. > @prrace Any comments on this test regarding its validity and fix? I'm looking forward to seeing Phil's comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3001288429 From serb at openjdk.org Tue Jun 24 17:37:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 24 Jun 2025 17:37:30 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> <-3XHdE_t-sAawF_jLCHjisZn4JcGLuYpkn1odm8neO4=.69404e00-5ea5-4191-96e1-420f83e24355@github.com> <_GBNjG32VmqYwLAReCdOQSiG1H8wS8J7RBHNRW3uOog=.37ec9319-bceb-49f2-bf79-0555669ef1c9@github.com> Message-ID: On Tue, 24 Jun 2025 12:50:14 GMT, Alexey Ivanov wrote: >>>What I mean is two threads that called GraphicsDevice.getFullScreenWindow still established a happens-before relation for each call, which will be gone with the volatile modifier. >>>It may be fine? or may be not? this is why I'm asking. >> >> That only affects the case where the second thread tries to read shared data (unrelated to GraphicsDevice) without synchronization, which was written before the first thread called getFullScreenWindow(). If visibility is required, it should be ensured by the caller. Depending on some internal and undocumented lock for that is not a good thing. > >> That only affects the case where the second thread tries to read shared data (unrelated to GraphicsDevice) without synchronization, which was written before the first thread called getFullScreenWindow(). If visibility is required, it should be ensured by the caller. Depending on some internal and undocumented lock for that is not a good thing. > > It is true? but it affects the fields of the full screen window itself. Doesn't any code path uses the fields of the full screen window after getting an object reference to it? Window fields may be modified at any time by different threads, such as the EDT, Toolkit thread, or others. Without proper synchronization, this can lead to race conditions. Even in the scenario we discussed where getFullScreenWindow() is called twice a race condition can still occur. For example if the first thread modifies the Window and then calls getFullScreenWindow(), and at the same time, a second thread also calls getFullScreenWindow() and attempts to read the Window's fields, a race may occur if the first thread begins modifying the Window again before its next call to getFullScreenWindow(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2164556539 From duke at openjdk.org Tue Jun 24 18:39:31 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 24 Jun 2025 18:39:31 GMT Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor can't handle null parameter [v10] In-Reply-To: References: Message-ID: On Fri, 20 Jun 2025 12:13:23 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 389: >> >>> 387: this.image = image; >>> 388: if (image == null) { >>> 389: this.description = null; >> >> We must not change the description. Why do we enforce resetting the description to `null`? >> >> The app is still free to change the description to an arbitrary value using `setDescription` even if the image is `null`. > > **I *strongly* disagree to changing the value of `description`** here, even though [I brought up this concern](https://github.com/openjdk/jdk/pull/25767#discussion_r2150249349). > > This does not make sense. Consider the following code snippet: > > > ImageIcon im = new ImageIcon(); > // Both image and description are null > > im.setDescription("whatever"); > // Now image is null, and description isn't null > > im.setImage(null); > // Why does description change to null? > > > Both `image` and `description` are two independent fields of `ImageIcon` object, each has its own getter and setter, and each can be changed independently. We should not enforce the order of calls: if an app developer wants to set the image to `null`, temporarily or not, the value of the description has to be preserved. Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2164666059 From achung at openjdk.org Tue Jun 24 21:47:23 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 24 Jun 2025 21:47:23 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v5] In-Reply-To: References: Message-ID: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties Co-authored-by: Christian Stein - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties Co-authored-by: Christian Stein - Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties Co-authored-by: Christian Stein ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25839/files - new: https://git.openjdk.org/jdk/pull/25839/files/90bfd7bd..97f3fe37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=03-04 Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From serb at openjdk.org Tue Jun 24 23:03:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 24 Jun 2025 23:03:07 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 11:34:04 GMT, Abhishek Kumar wrote: > I think the check is to ensure the passed index parameter is to verify the boundary of text length. Yes, but the index passed to the method is `an index within the text`, so it should be from 0 to length - 1. You can take a look at the opposite case when the index is outside the range, for example at the beginning of the text and getAfterIndex: > result = at.getAfterIndex(AccessibleText.CHARACTER, -1); > verifyResult("T", result); Is that expectation correct or not? I think we should first decide whether this is actually a bug or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3002102230 From dnguyen at openjdk.org Wed Jun 25 00:30:31 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jun 2025 00:30:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: References: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> Message-ID: On Tue, 24 Jun 2025 14:59:18 GMT, Weijun Wang wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> update to german translations > > src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49: > >> 47: .Principal.=\t????\u0020 >> 48: .Public.Credential.=\t??????:\u0020 >> 49: .Private.Credential.=\t??????:\u0020 > > Why aren't the 2 lines above updated like in lines 46 and 47? I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here. I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2165200706 From dnguyen at openjdk.org Wed Jun 25 00:39:29 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jun 2025 00:39:29 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF [v2] In-Reply-To: References: Message-ID: <8vM7HArYB5wFC9c1IqcwMPav8p4Jb9xESTicXoiUc1c=.5c874a41-0fbe-4e19-b09f-5e20537fda92@github.com> On Tue, 24 Jun 2025 12:11:52 GMT, Prasanta Sadhukhan wrote: >> There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY)..... >> Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them >> so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead >> >> No regression test as it can be verified through SwingSet2 demo as below.. >> >> With ctrl+shift+down >> Screenshot 2025-06-19 at 1 41 39?PM >> >> another ctrl+shift+down >> Screenshot 2025-06-19 at 1 42 39?PM >> >> Now, ctrl+shift+up >> Screenshot 2025-06-19 at 1 44 51?PM > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Add test Is CTRL+SHIFT+(UP/DOWN) the correct key binding here? I can mimic a Tree on MacOS using `Finder` and viewing as a `List View`. Looks like CTRL+SHIFT+(UP/DOWN) selects the next in that direction as well in a selection group. Here's a screenshot where I started on `Apple` and pressed CTRL+SHIFT+DOWN 5 times. Screenshot 2025-06-24 at 5 33 21?PM ------------- PR Review: https://git.openjdk.org/jdk/pull/25892#pullrequestreview-2955824696 PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-3002245908 From psadhukhan at openjdk.org Wed Jun 25 03:17:27 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 03:17:27 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: References: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> Message-ID: <7o6YN6zsOQUdXXgX_7BQDR11InQHhfdyz_PtaMoMsg8=.dc5765d0-f794-4f78-81c3-0bcd6d0ce34c@github.com> On Tue, 24 Jun 2025 17:23:47 GMT, Alexey Ivanov wrote: > If there were another L&F to test, or if Windows L&F weren't the last in the list, the test will continue to fail because the current L&F will again be different from Windows L&F. But there isn't..The L&F the test wanted to test and had tested since closed days are now working with the fix and this allows the test to run ok...I dont think its a product bug since the L&F was not propagated to all nodes of the Swing components after L&F change so it should be a test issue which was solved. Rewriting the test, if needed, could be done as part of new issue but this one fixes the issue and let manual testing team run the test in all L&F > I commented out the line UIManager.setLookAndFeel(save), the Windows menu looks good but clicking the Metal menu now throws NPE: I couldn't reproduce this problem with the current PR..What L&F you started the test with? I tested the test with Metal/Windows/Nimbus from the commandline and couldn't find any issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3002735947 From psadhukhan at openjdk.org Wed Jun 25 03:26:34 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 03:26:34 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF [v2] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 12:11:52 GMT, Prasanta Sadhukhan wrote: >> There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY)..... >> Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them >> so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead >> >> No regression test as it can be verified through SwingSet2 demo as below.. >> >> With ctrl+shift+down >> Screenshot 2025-06-19 at 1 41 39?PM >> >> another ctrl+shift+down >> Screenshot 2025-06-19 at 1 42 39?PM >> >> Now, ctrl+shift+up >> Screenshot 2025-06-19 at 1 44 51?PM > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Add test Yes, seems not..No combinations seems to work in native Finder, the way lead selection does in Java I chose that combination because there is nothing listed in macos with those options...Seems like LeadSelection change are not supported in macos. Probably we should close this as Not an issue unless someone has other ideas. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-3002778400 From psadhukhan at openjdk.org Wed Jun 25 03:57:35 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 03:57:35 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF [v2] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 12:11:52 GMT, Prasanta Sadhukhan wrote: >> There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY)..... >> Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them >> so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead >> >> No regression test as it can be verified through SwingSet2 demo as below.. >> >> With ctrl+shift+down >> Screenshot 2025-06-19 at 1 41 39?PM >> >> another ctrl+shift+down >> Screenshot 2025-06-19 at 1 42 39?PM >> >> Now, ctrl+shift+up >> Screenshot 2025-06-19 at 1 44 51?PM > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Add test Seems like JDK doesnt honour `ctrl+shift+up/down` in Aqua as it does in Finder..We should fix that probably.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-3002935426 From abhiscxk at openjdk.org Wed Jun 25 04:45:35 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 25 Jun 2025 04:45:35 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 23:00:03 GMT, Sergey Bylokhov wrote: > > I think the check is to ensure the passed index parameter is to verify the boundary of text length. > > Yes, but the index passed to the method is `an index within the text`, so it should be from 0 to length - 1. You can take a look at the opposite case when the index is outside the range, for example at the beginning of the text and getAfterIndex: > > > result = at.getAfterIndex(AccessibleText.CHARACTER, -1); > > verifyResult("T", result); > > Is that expectation correct or not? I think we should first decide whether this is actually a bug or not. I got your point now. The spec says that `index an index within the text` and that means the value should range from 0 to length - 1. And that means, `getBeforeIndex` won't be able to fetch the last character and `getAfterIndex` won't be able to fetch the first character. So, if someone wants to retrieve the first or last character, they shouldn't rely on `getAfterIndex and getBeforeIndex` method respectively, rather use `getAtIndex` method to get the first and last character with index passed as 0 and length -1 respectively. Right ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3003204161 From psadhukhan at openjdk.org Wed Jun 25 04:46:27 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 04:46:27 GMT Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for Tree in Aqua LAF [v2] In-Reply-To: References: Message-ID: <2tbNXqg_q5o8L3yR62-8OFOLOw6aO-aHAGKgqe1mopM=.c61cf4e8-4fd7-4be4-809b-80d9191e77fe@github.com> On Tue, 24 Jun 2025 12:11:52 GMT, Prasanta Sadhukhan wrote: >> There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY)..... >> Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them >> so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead >> >> No regression test as it can be verified through SwingSet2 demo as below.. >> >> With ctrl+shift+down >> Screenshot 2025-06-19 at 1 41 39?PM >> >> another ctrl+shift+down >> Screenshot 2025-06-19 at 1 42 39?PM >> >> Now, ctrl+shift+up >> Screenshot 2025-06-19 at 1 44 51?PM > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Add test Rasied JDK-8360462 and PR https://github.com/openjdk/jdk/pull/25966 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-3003210702 From psadhukhan at openjdk.org Wed Jun 25 04:48:13 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 04:48:13 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F Message-ID: Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. Fixed the keybindings. ------------- Commit messages: - 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F Changes: https://git.openjdk.org/jdk/pull/25966/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25966&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360462 Stats: 108 lines in 2 files changed: 107 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25966.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25966/head:pull/25966 PR: https://git.openjdk.org/jdk/pull/25966 From duke at openjdk.org Wed Jun 25 05:19:12 2025 From: duke at openjdk.org (Dmitry Kulikov) Date: Wed, 25 Jun 2025 05:19:12 GMT Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess Message-ID: Added an on-demand installation of the native OpenURL event handler to the `Application.setOpenURIHandler()`. This does not break the specification for the affected API, since the requirement of the application being bundled and containing `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither launch nor send OpenURL events to an application that does not declare such capabilities it the bundle. Running tests on macOS showed no regressions after this patch. Other platforms are not affected. ------------- Commit messages: - Install OpenURL handler on demand Changes: https://git.openjdk.org/jdk/pull/25967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360120 Stats: 38 lines in 3 files changed: 32 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25967/head:pull/25967 PR: https://git.openjdk.org/jdk/pull/25967 From psadhukhan at openjdk.org Wed Jun 25 06:52:15 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 06:52:15 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v2] In-Reply-To: References: Message-ID: <8eifuoANPlNYK-Kvkqi7xD5vm66IDusjkEy2ST4dh_g=.b8bc0478-3677-4646-a86d-f791ba99fadb@github.com> > Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. > Fixed the keybindings. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Correct bugid ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25966/files - new: https://git.openjdk.org/jdk/pull/25966/files/7e694599..4cd7677b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25966&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25966&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25966.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25966/head:pull/25966 PR: https://git.openjdk.org/jdk/pull/25966 From duke at openjdk.org Wed Jun 25 07:03:33 2025 From: duke at openjdk.org (Dmitry Kulikov) Date: Wed, 25 Jun 2025 07:03:33 GMT Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess [v2] In-Reply-To: References: Message-ID: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com> > Added an on-demand installation of the native OpenURL event handler to the `Application.setOpenURIHandler()`. > > This does not break the specification for the affected API, since the requirement of the application being bundled and containing `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither launch nor send OpenURL events to an application that does not declare such capabilities it the bundle. > > Running tests on macOS showed no regressions after this patch. Other platforms are not affected. Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25967/files - new: https://git.openjdk.org/jdk/pull/25967/files/88676983..9b579b60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25967&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25967&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25967/head:pull/25967 PR: https://git.openjdk.org/jdk/pull/25967 From psadhukhan at openjdk.org Wed Jun 25 07:09:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 07:09:10 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v2] In-Reply-To: References: Message-ID: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: - Update javadoc - Update javadoc - Update javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25850/files - new: https://git.openjdk.org/jdk/pull/25850/files/aeed7361..e29a07be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25850&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25850&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25850/head:pull/25850 PR: https://git.openjdk.org/jdk/pull/25850 From psadhukhan at openjdk.org Wed Jun 25 07:09:10 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 07:09:10 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v2] In-Reply-To: References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Fri, 20 Jun 2025 11:26:09 GMT, Alexey Ivanov wrote: >> It is passed to `View.setSize` also so just mentioning one may not be right..and I guess {@code allocation} is a no-op as it is not a class.. >> >> Maybe we can mention "The returned rectangle is unrelated to visibility, and is used as an allocation parameter in javax.swing.text.View class to set the size and paint the allocated View" > >> It is passed to `View.setSize` also so just mentioning one may not be right? > > Right. Both uses cases fall into the same category: the allocation controls the size of the root view. > > The returned allocation rectangle is also used in handling mutations to the text model. > > I'd rather leave it without any explanation why it's called *allocation*. Anyone who dealt with Swing text components and their implementation of the view classes is expected to roughly understand what allocation means. Searching for usages of `getVisibleEditorRect` reveals the usages. > >> `{@code allocation}` is a no-op as it is not a class.. > > Yes, it is an op: it refers to `allocation` the parameter of the `paint` method. > >> Maybe we can mention "The returned rectangle is unrelated to visibility, and is used as an allocation parameter in javax.swing.text.View class to set the size and paint the allocated View" > > If we stick to explaining *allocation*, your suggestion makes sense, I edited it a bit: _?The returned rectangle is unrelated to visibility, it is used to set the size of the root view.?_ This is what it means? without going too deep into the details. > > We could add `@see` links for `View.paint` and/or `View.setSize`, the link to paint could be the most useful because it has a parameter called `allocation`. Updated javadoc. @prrace Can you please take a look? CSR will be required? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2165960440 From duke at openjdk.org Wed Jun 25 08:19:02 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Wed, 25 Jun 2025 08:19:02 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick 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. ------------- Commit messages: - Problem list files for Mac OS only - Removes passed tests from problem list - Changes Frame width to 300, uses protected constants for all base tests frame sizes Changes: https://git.openjdk.org/jdk/pull/25971/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8158801 Stats: 42 lines in 7 files changed: 3 ins; 30 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 ngubarkov at openjdk.org Wed Jun 25 08:29:29 2025 From: ngubarkov at openjdk.org (Nikita Gubarkov) Date: Wed, 25 Jun 2025 08:29:29 GMT Subject: RFR: 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride [v2] In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 13:06:56 GMT, Nikita Gubarkov wrote: >> 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > The previous approach was wrong for non-pixel interleaving. > > Just align the buffer size to the pixel stride instead, should be better. I'm gonna find some time to refresh all the details, consider all concerns and move this and https://github.com/openjdk/jdk/pull/24378 further ------------- PR Comment: https://git.openjdk.org/jdk/pull/24111#issuecomment-3003855673 From aturbanov at openjdk.org Wed Jun 25 08:50:43 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 25 Jun 2025 08:50:43 GMT Subject: RFR: 8360487: Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove Message-ID: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. ------------- Commit messages: - [PATCH] Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove Changes: https://git.openjdk.org/jdk/pull/25931/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25931&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360487 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25931.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25931/head:pull/25931 PR: https://git.openjdk.org/jdk/pull/25931 From serb at openjdk.org Wed Jun 25 08:50:43 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 25 Jun 2025 08:50:43 GMT Subject: RFR: 8360487: Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove In-Reply-To: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> References: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> Message-ID: On Mon, 23 Jun 2025 08:53:16 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. looks fine ------------- PR Comment: https://git.openjdk.org/jdk/pull/25931#issuecomment-2998267325 From duke at openjdk.org Wed Jun 25 09:04:37 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Wed, 25 Jun 2025 09:04:37 GMT Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus workaround trick [v2] 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: Changes protected fields to static ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25971/files - new: https://git.openjdk.org/jdk/pull/25971/files/f68973cc..fa864b2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25971.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971 PR: https://git.openjdk.org/jdk/pull/25971 From aivanov at openjdk.org Wed Jun 25 09:26:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 09:26:28 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: <7o6YN6zsOQUdXXgX_7BQDR11InQHhfdyz_PtaMoMsg8=.dc5765d0-f794-4f78-81c3-0bcd6d0ce34c@github.com> References: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> <7o6YN6zsOQUdXXgX_7BQDR11InQHhfdyz_PtaMoMsg8=.dc5765d0-f794-4f78-81c3-0bcd6d0ce34c@github.com> Message-ID: On Wed, 25 Jun 2025 03:14:33 GMT, Prasanta Sadhukhan wrote: > I dont think its a product bug since the L&F was not propagated to all nodes of the Swing components after L&F change so it should be a test issue which was solved. I didn't say it was a product bug, it is rather a product *feature*: multiple L&Fs at the same time aren't really supported, have never been. As I said above, the problem wasn't that the L&F wasn't propagated to all nodes of the Swing components. The problem is and was that the current L&F doesn't match the L&F with which a component was created. > Rewriting the test, if needed, could be done as part of new issue but this one fixes the issue and let manual testing team run the test in all L&F Why not now? We have a bug in the test, your fix doesn't fix the fundamental problem with the test, but rather tweaks the test so that the problem isn't visible any more. > > I commented out the line UIManager.setLookAndFeel(save), the Windows menu looks good but clicking the Metal menu now throws NPE: > > I couldn't reproduce this problem with the current PR..What L&F you started the test with? I tested the test with Metal/Windows/Nimbus from the commandline and couldn't find any issue. Nimbus, as specified in the command line in the bug description: `-vmoption:-Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel` You can't reproduce NPE if there's a call to `SwingUtilities.updateComponentTreeUI(frame)` because it updates the L&F of the top-level menu items, those that are on the menu bar. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3004059997 From psadhukhan at openjdk.org Wed Jun 25 09:39:27 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 09:39:27 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: References: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> <7o6YN6zsOQUdXXgX_7BQDR11InQHhfdyz_PtaMoMsg8=.dc5765d0-f794-4f78-81c3-0bcd6d0ce34c@github.com> Message-ID: On Wed, 25 Jun 2025 09:24:21 GMT, Alexey Ivanov wrote: > > Rewriting the test, if needed, could be done as part of new issue but this one fixes the issue and let manual testing team run the test in all L&F > > Why not now? We have a bug in the test, your fix doesn't fix the fundamental problem with the test, but rather tweaks the test so that the problem isn't visible any more. > > > > I commented out the line UIManager.setLookAndFeel(save), the Windows menu looks good but clicking the Metal menu now throws NPE: > > > > > > I couldn't reproduce this problem with the current PR..What L&F you started the test with? I tested the test with Metal/Windows/Nimbus from the commandline and couldn't find any issue. > > Nimbus, as specified in the command line in the bug description: > > `-vmoption:-Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel` > > You can't reproduce NPE if there's a call to `SwingUtilities.updateComponentTreeUI(frame)` because it updates the L&F of the top-level menu items, those that are on the menu bar. I dont want to do it as I already told before..Its the same strategy used in other recently opensourced tests I mentioned before where `SwingUtilities.updateComponentTreeUI(frame)` is used ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3004106471 From aivanov at openjdk.org Wed Jun 25 10:04:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 10:04:30 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: References: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> <7o6YN6zsOQUdXXgX_7BQDR11InQHhfdyz_PtaMoMsg8=.dc5765d0-f794-4f78-81c3-0bcd6d0ce34c@github.com> Message-ID: <2wIDoTcunUTeB3WJyXE8x7zbRoPIXzm82zzEC2nXRSk=.4ad6add4-b3e2-4214-abe5-7b5c57e9a4d4@github.com> On Wed, 25 Jun 2025 09:37:10 GMT, Prasanta Sadhukhan wrote: > I dont want to do it as I already told before..Its the same strategy used in other recently opensourced tests I mentioned before where `SwingUtilities.updateComponentTreeUI(frame)` is used ... But missing `SwingUtilities.updateComponentTreeUI(frame)` wasn't the problem, wasn't the root cause? in this particular case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3004179655 From psadhukhan at openjdk.org Wed Jun 25 10:10:33 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 10:10:33 GMT Subject: RFR: 8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel In-Reply-To: <2wIDoTcunUTeB3WJyXE8x7zbRoPIXzm82zzEC2nXRSk=.4ad6add4-b3e2-4214-abe5-7b5c57e9a4d4@github.com> References: <6FfXPVLcQhjgHhjdPSP3ejgl34A32_TTdywDLP0YMG4=.14b7713f-6729-452b-b5fb-69f8b27d47eb@github.com> <7o6YN6zsOQUdXXgX_7BQDR11InQHhfdyz_PtaMoMsg8=.dc5765d0-f794-4f78-81c3-0bcd6d0ce34c@github.com> <2wIDoTcunUTeB3WJyXE8x7zbRoPIXzm82zzEC2nXRSk=.4ad6add4-b3e2-4214-abe5-7b5c57e9a4d4@github.com> Message-ID: <5rgqXw8huoSelvDvNcU-VADUmYVfB1BL3SJFhRfQmnU=.d9151999-d8fd-4376-8435-62b533025ae8@github.com> On Wed, 25 Jun 2025 10:01:52 GMT, Alexey Ivanov wrote: > > I dont want to do it as I already told before..Its the same strategy used in other recently opensourced tests I mentioned before where `SwingUtilities.updateComponentTreeUI(frame)` is used ... > > But missing `SwingUtilities.updateComponentTreeUI(frame)` wasn't the problem, wasn't the root cause? in this particular case. Adding this call and removing UIManager.setLookAndFeel(save) is what is used to not fallback to old L&F (this restoration to old L&F is also not used in other tests opensourced) and I stand by it.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3004195866 From aivanov at openjdk.org Wed Jun 25 10:39:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 10:39:28 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v2] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 07:09:10 GMT, Prasanta Sadhukhan wrote: >> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". > > Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: > > - Update javadoc > - Update javadoc > - Update javadoc Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1034: > 1032: * Gets the allocation for the root view. > 1033: * The returned rectangle is unrelated to visibility, > 1034: * and is used to set the size of the root view. Suggestion: * The returned rectangle is unrelated to visibility. * It is used to set the size of the root view. I still think, ?it is used?? is clearer. ------------- PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2957623200 PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2166390088 From aivanov at openjdk.org Wed Jun 25 10:39:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 10:39:29 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v2] In-Reply-To: References: Message-ID: <3xkDzNz1LhpvFI-XP_BMrm7eAn2xzW0LfBUgNJG2N_s=.7963f2cb-973e-4e2d-9baa-4f3d5eba021b@github.com> On Wed, 25 Jun 2025 10:33:48 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update javadoc >> - Update javadoc >> - Update javadoc > > src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1034: > >> 1032: * Gets the allocation for the root view. >> 1033: * The returned rectangle is unrelated to visibility, >> 1034: * and is used to set the size of the root view. > > Suggestion: > > * The returned rectangle is unrelated to visibility. > * It is used to set the size of the root view. > > I still think, ?it is used?? is clearer. We may break the description into paragraphs like this: /** * Gets the allocation for the root view. *

      * The returned rectangle is unrelated to visibility, * and is used to set the size of the root view. *

      * The component must have a non-zero positive size for * this translation to be computed. * * @return the bounding box for the root view * * @see View#paint * @see View#setSize */ protected Rectangle getVisibleEditorRect() { This way different parts of the description are clearly separated, therefore each part stands out when one scans the javadoc for information. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2166395256 From aivanov at openjdk.org Wed Jun 25 10:50:29 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 10:50:29 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v2] In-Reply-To: <3xkDzNz1LhpvFI-XP_BMrm7eAn2xzW0LfBUgNJG2N_s=.7963f2cb-973e-4e2d-9baa-4f3d5eba021b@github.com> References: <3xkDzNz1LhpvFI-XP_BMrm7eAn2xzW0LfBUgNJG2N_s=.7963f2cb-973e-4e2d-9baa-4f3d5eba021b@github.com> Message-ID: On Wed, 25 Jun 2025 10:36:46 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1034: >> >>> 1032: * Gets the allocation for the root view. >>> 1033: * The returned rectangle is unrelated to visibility, >>> 1034: * and is used to set the size of the root view. >> >> Suggestion: >> >> * The returned rectangle is unrelated to visibility. >> * It is used to set the size of the root view. >> >> I still think, ?it is used?? is clearer. > > We may break the description into paragraphs like this: > > > /** > * Gets the allocation for the root view. > *

      > * The returned rectangle is unrelated to visibility. > * It is used to set the size of the root view. > *

      > * The component must have a non-zero positive size for > * this translation to be computed. > * > * @return the bounding box for the root view > * > * @see View#paint > * @see View#setSize > */ > protected Rectangle getVisibleEditorRect() { > > This way different parts of the description are clearly separated, therefore each part stands out when one scans the javadoc for information. If linked with ?and?, there should be no comma. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2166414060 From psadhukhan at openjdk.org Wed Jun 25 12:15:54 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 12:15:54 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v3] In-Reply-To: References: Message-ID: > BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Update javadoc - Update javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25850/files - new: https://git.openjdk.org/jdk/pull/25850/files/e29a07be..6289a27a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25850&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25850&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25850.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25850/head:pull/25850 PR: https://git.openjdk.org/jdk/pull/25850 From psadhukhan at openjdk.org Wed Jun 25 12:15:55 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 12:15:55 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v2] In-Reply-To: References: <3xkDzNz1LhpvFI-XP_BMrm7eAn2xzW0LfBUgNJG2N_s=.7963f2cb-973e-4e2d-9baa-4f3d5eba021b@github.com> Message-ID: On Wed, 25 Jun 2025 10:47:27 GMT, Alexey Ivanov wrote: >> We may break the description into paragraphs like this: >> >> >> /** >> * Gets the allocation for the root view. >> *

      >> * The returned rectangle is unrelated to visibility. >> * It is used to set the size of the root view. >> *

      >> * The component must have a non-zero positive size for >> * this translation to be computed. >> * >> * @return the bounding box for the root view >> * >> * @see View#paint >> * @see View#setSize >> */ >> protected Rectangle getVisibleEditorRect() { >> >> This way different parts of the description are clearly separated, therefore each part stands out when one scans the javadoc for information. > > If linked with ?and?, there should be no comma. ok..modified.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2166566514 From psadhukhan at openjdk.org Wed Jun 25 12:15:55 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 25 Jun 2025 12:15:55 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v2] In-Reply-To: References: <3xkDzNz1LhpvFI-XP_BMrm7eAn2xzW0LfBUgNJG2N_s=.7963f2cb-973e-4e2d-9baa-4f3d5eba021b@github.com> Message-ID: <_McR_JcuoCwwBmKCWB-dAPaClN_CYbNwOmRuJKBuCm0=.1533f44a-8faa-4a36-940b-1931a78a5950@github.com> On Wed, 25 Jun 2025 12:12:54 GMT, Prasanta Sadhukhan wrote: >> If linked with ?and?, there should be no comma. > > ok..modified.. ok..modified.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2166567168 From azvegint at openjdk.org Wed Jun 25 14:37:27 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 25 Jun 2025 14:37:27 GMT Subject: RFR: 8360487: Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove In-Reply-To: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> References: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> Message-ID: On Mon, 23 Jun 2025 08:53:16 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25931#pullrequestreview-2958464430 From aivanov at openjdk.org Wed Jun 25 14:48:30 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 14:48:30 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v3] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 12:15:54 GMT, Prasanta Sadhukhan wrote: >> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Update javadoc > - Update javadoc Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2958507061 From aivanov at openjdk.org Wed Jun 25 14:51:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 14:51:31 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v3] In-Reply-To: References: <67i7meKGZngex1kdfcSlWDLdaffOPGIMyjQrc9Qtf8Y=.03f96f74-73a8-4aec-b426-2aee9f0ddcae@github.com> Message-ID: On Wed, 25 Jun 2025 07:06:13 GMT, Prasanta Sadhukhan wrote: >>> It is passed to `View.setSize` also so just mentioning one may not be right? >> >> Right. Both uses cases fall into the same category: the allocation controls the size of the root view. >> >> The returned allocation rectangle is also used in handling mutations to the text model. >> >> I'd rather leave it without any explanation why it's called *allocation*. Anyone who dealt with Swing text components and their implementation of the view classes is expected to roughly understand what allocation means. Searching for usages of `getVisibleEditorRect` reveals the usages. >> >>> `{@code allocation}` is a no-op as it is not a class.. >> >> Yes, it is an op: it refers to `allocation` the parameter of the `paint` method. >> >>> Maybe we can mention "The returned rectangle is unrelated to visibility, and is used as an allocation parameter in javax.swing.text.View class to set the size and paint the allocated View" >> >> If we stick to explaining *allocation*, your suggestion makes sense, I edited it a bit: _?The returned rectangle is unrelated to visibility, it is used to set the size of the root view.?_ This is what it means? without going too deep into the details. >> >> We could add `@see` links for `View.paint` and/or `View.setSize`, the link to paint could be the most useful because it has a parameter called `allocation`. > > Updated javadoc. > @prrace Can you please take a look? CSR will be required? My take is that CSR isn't required because the meaning remains the same. However, the added clarification may still be documented with a CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2166925446 From aivanov at openjdk.org Wed Jun 25 14:58:32 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 14:58:32 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: <-LlqUOlsSrT0mid5SIa7vYkDCFxv6SoH6A68_OvPN-g=.22b516bc-c720-4667-bfaf-04d191a068e8@github.com> <-3XHdE_t-sAawF_jLCHjisZn4JcGLuYpkn1odm8neO4=.69404e00-5ea5-4191-96e1-420f83e24355@github.com> <_GBNjG32VmqYwLAReCdOQSiG1H8wS8J7RBHNRW3uOog=.37ec9319-bceb-49f2-bf79-0555669ef1c9@github.com> Message-ID: On Tue, 24 Jun 2025 17:34:54 GMT, Sergey Bylokhov wrote: >>> That only affects the case where the second thread tries to read shared data (unrelated to GraphicsDevice) without synchronization, which was written before the first thread called getFullScreenWindow(). If visibility is required, it should be ensured by the caller. Depending on some internal and undocumented lock for that is not a good thing. >> >> It is true? but it affects the fields of the full screen window itself. Doesn't any code path uses the fields of the full screen window after getting an object reference to it? > > Window fields may be modified at any time by different threads, such as the EDT, Toolkit thread, or others. Without proper synchronization, this can lead to race conditions. Even in the scenario we discussed where getFullScreenWindow() is called twice a race condition can still occur. For example if the first thread modifies the Window and then calls getFullScreenWindow(), and at the same time, a second thread also calls getFullScreenWindow() and attempts to read the Window's fields, a race may occur if the first thread begins modifying the Window again before its next call to getFullScreenWindow(). Yes, I agree race conditions and memory inconsistencies are still in place, however, the synchronized block brought the state of the full screen object to a fresher state. I looked through the usages of `getFullScreenWindow()` and couldn't find any usages of full screen window fields, so a `volatile` modifier seems appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2166941317 From aivanov at openjdk.org Wed Jun 25 15:02:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 15:02:47 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 06:17:32 GMT, Sergey Bylokhov wrote: > This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. > > Notes: GraphicsDevice provides two methods for handling full-screen windows: > - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). > - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/GraphicsDevice/FullScreenWindowRace.java line 55: > 53: gd.setFullScreenWindow(window); > 54: > 55: thread.join(15000); Does it make sense to reduce the waiting time? The thread should exit much quicker than 15 seconds, 5 second should be plenty enough. ------------- PR Review: https://git.openjdk.org/jdk/pull/25818#pullrequestreview-2958559956 PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2166951688 From aivanov at openjdk.org Wed Jun 25 15:43:28 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 15:43:28 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 04:43:14 GMT, Abhishek Kumar wrote: > The spec says What spec in particular? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3005132532 From abhiscxk at openjdk.org Wed Jun 25 15:43:28 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 25 Jun 2025 15:43:28 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 15:05:27 GMT, Alexey Ivanov wrote: > > The spec says > > What spec in particular? https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/accessibility/AccessibleText.html#getBeforeIndex(int,int) It says, `index - an index within the text` for the `getBeforeIndex` method description ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3005245568 From dnguyen at openjdk.org Wed Jun 25 16:20:30 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 25 Jun 2025 16:20:30 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v2] In-Reply-To: <8eifuoANPlNYK-Kvkqi7xD5vm66IDusjkEy2ST4dh_g=.b8bc0478-3677-4646-a86d-f791ba99fadb@github.com> References: <8eifuoANPlNYK-Kvkqi7xD5vm66IDusjkEy2ST4dh_g=.b8bc0478-3677-4646-a86d-f791ba99fadb@github.com> Message-ID: On Wed, 25 Jun 2025 06:52:15 GMT, Prasanta Sadhukhan wrote: >> Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. >> Fixed the keybindings. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Correct bugid I mentioned in your other PR that I can test this natively with a bunch of folders in Finder when viewing under `List View`. One note is that natively on macOS in Finder, there is a pinging noise for each CTRL+SHIFT+(UP/DOWN). This is in contrast to just SHIFT+(UP/DOWN) which does the same thing but without the pinging. Do you have any idea why this is? Test looks good when testing myself. test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 29: > 27: * @requires (os.family == "mac") > 28: * @bug 8360462 > 29: * @summary Verifies ctrl+shift+down slects next row in AquaL&F Suggestion: * @summary Verifies ctrl+shift+down selects next row in Aqua L&F ------------- PR Review: https://git.openjdk.org/jdk/pull/25966#pullrequestreview-2958810156 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2167095570 From aivanov at openjdk.org Wed Jun 25 16:35:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 16:35:36 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v27] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Tue, 24 Jun 2025 05:42:04 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon The current layout doesn't match the layout of menus in Windows. The check mark or the bullet has to be painted where it was always painted. The menu in Windows 10 looks broken now: ![The position of the check mark isn't in the centre of the highlight](https://github.com/user-attachments/assets/5fecfb30-171d-4273-9d4a-234bc07edfaf) This applies to the radio bullet JRadioButtonMenuItem3 which has no icon. In Windows 11, I expect the check mark and the bullet render at the same location as it was before the fix, but it's not the case. Below is a portion of the menu rendered with the current fix: ![Comparison of JMenuItem on Windows11 with the fix vs. without the fix](https://github.com/user-attachments/assets/df1d5262-94af-4efb-9625-69c96653d45a) The part on the image in an orange rectangle is a portion of the same test case running on JDK that has no fix. 1. The width of the popup menu with the two columns?for check marks or bullets and icons?is the same, how is it possible? If a second column for the icon is added, the width of the popup menu has to increase. 2. The text of `JCheckBoxMenuItem 3` is not aligned to other menu items text.\ This applies to any other item added to the menu: *the text of all items must align*. 4. The location of the check mark and the bullet is wrong, you moved the check mark / bullet to the left but now it doesn't match the menu layout of a native Win32 application. 5. If I add another regular menu item with an icon, the icon is rendered below the menu item text. We have to support two cases: 1. One column is reserved as it is currently done; 2. Two columns are reserved if there's `JCheckBoxMenuItem` and/or `JRadioButtonMenuItem` that has an icon. To reiterate [Phil's suggestion](https://github.com/openjdk/jdk/pull/23324#issuecomment-2914400828), * **One-column layout** (nothing changes): * No menu item has icons, check marks or bullets; * There are `JCheckBoxMenuItem` and/or `JRadioButtonMenuItem` but they have no icons, and no other menu items have icons either; * There are `JCheckBoxMenuItem` and/or `JRadioButtonMenuItem` but none of them has an icon, yet there are other menu items with icons: the check marks / bullets and the icons share the same reserved column. * **Two-column layout** (new layout): * There's a least one `JCheckBoxMenuItem` and/or `JRadioButtonMenuItem` that has an icon. In the two-column layout, the first column (which is always present) is reserved for check marks and bullets of `JCheckBoxMenuItem` and `JRadioButtonMenuItem` correspondingly, and the second column is reserved for rendering any icons that menu items have. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3005372591 PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3005416654 From jlu at openjdk.org Wed Jun 25 17:01:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 25 Jun 2025 17:01:42 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: References: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> Message-ID: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com> On Wed, 25 Jun 2025 00:27:48 GMT, Damon Nguyen wrote: >> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49: >> >>> 47: .Principal.=\t????\u0020 >>> 48: .Public.Credential.=\t??????:\u0020 >>> 49: .Private.Credential.=\t??????:\u0020 >> >> Why aren't the 2 lines above updated like in lines 46 and 47? > > I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here. > > I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to. If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167196792 From achung at openjdk.org Wed Jun 25 17:08:20 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 25 Jun 2025 17:08:20 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6] In-Reply-To: References: Message-ID: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: - update majorticks translation - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761 - fix colon in chinese security.properties file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25839/files - new: https://git.openjdk.org/jdk/pull/25839/files/97f3fe37..67990651 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From achung at openjdk.org Wed Jun 25 17:14:30 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 25 Jun 2025 17:14:30 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4] In-Reply-To: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com> References: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com> <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com> Message-ID: On Wed, 25 Jun 2025 16:59:09 GMT, Justin Lu wrote: >> I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here. >> >> I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to. > > If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced. There's more full width colons spread around in different properties files and I think the translation team just revisits lines and decides to change the colon, so these changes look a bit random to us. I've updated these specific colons to full width for now but I think it might be better to just let the translation team update them for each drop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167222866 From serb at openjdk.org Wed Jun 25 17:19:30 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 25 Jun 2025 17:19:30 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 04:43:14 GMT, Abhishek Kumar wrote: > So, if someone wants to retrieve the first or last character, they shouldn't rely on `getAfterIndex and getBeforeIndex` method respectively, rather use `getAtIndex` method to get the first and last character with index passed as 0 and length -1 respectively. > > Right ? That is my understanding. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3005562699 From serb at openjdk.org Wed Jun 25 20:02:45 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 25 Jun 2025 20:02:45 GMT Subject: RFR: 8360487: Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove In-Reply-To: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> References: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> Message-ID: On Mon, 23 Jun 2025 08:53:16 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. Marked as reviewed by serb (Reviewer). please rerun the Pre-submit tests in the GA ------------- PR Review: https://git.openjdk.org/jdk/pull/25931#pullrequestreview-2959482163 PR Comment: https://git.openjdk.org/jdk/pull/25931#issuecomment-3005978808 From achung at openjdk.org Wed Jun 25 20:22:31 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 25 Jun 2025 20:22:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: > > - update majorticks translation > - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761 > - fix colon in chinese security.properties file Currently running tests and everything looks green so far, @aivanov-jdk @sormuras do the German localizations look fine? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-3006029100 From aivanov at openjdk.org Wed Jun 25 20:36:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 25 Jun 2025 20:36:27 GMT Subject: RFR: 8360487: Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove In-Reply-To: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> References: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> Message-ID: On Mon, 23 Jun 2025 08:53:16 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25931#pullrequestreview-2959578963 From jlu at openjdk.org Wed Jun 25 21:19:31 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 25 Jun 2025 21:19:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6] In-Reply-To: References: Message-ID: <7w3okXKFhjzXb1zG6J-pfS1skbQqOsmKnt9Wpxap83o=.1fb9f308-b219-4acb-9b75-8de05c43055d@github.com> On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: > > - update majorticks translation > - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761 > - fix colon in chinese security.properties file Overall looks correct to me, and it seems you addressed all of the suggestions left by other reviewers. I skimmed most of the files for any glaring issues and also spot checked a few to make sure their associated English file had the correct corresponding change. Left some small comments which should be addressed. src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties line 36: > 34: MSG_Help_mac_install=\ --mac-dmg-content [,...]\n Nimmt den gesamten referenzierten Inhalt in die DMG-Datei auf.\n Diese Option kann mehrmals verwendet werden. \n > 35: MSG_Help_mac_launcher=\ --mac-package-identifier \n Eine ID, die die Anwendung f?r macOS eindeutig identifiziert\n Standardwert ist der Hauptklassenname.\n Es d?rfen nur alphanumerische Zeichen (A-Z, a-z, 0-9), Bindestriche (-)\n und Punkte (.) verwendet werden.\n --mac-package-name \n Name der Anwendung, wie in der Men?leiste angezeigt\n Dieser kann vom Anwendungsnamen abweichen.\n Er darf maximal 15 Zeichen enthalten und muss f?r die Anzeige\n in der Men?leiste und im Infofenster der Anwendung geeignet sein.\n Standardwert: Anwendungsname.\n --mac-package-signing-prefix \n Beim Signieren des Anwendungspackages wird dieser Wert\n allen zu signierenden Komponenten ohne vorhandene\n Package-ID als Pr?fix vorangestellt.\n --mac-sign\n Anforderung zum Signieren des Packages oder des vordefinierten\n Anwendungsimages\n --mac-signing-keychain \n Name des Schl?sselbundes f?r die Suche nach der Signaturidentit?t\n Bei fehlender Angabe werden die Standardschl?sselbunde verwendet.\n --mac-signing-key-user-name \n Team- oder Benutzernamensteil der Apple-Signaturidentit?ten. Um direkt zu steuern,\n welche Signaturidentit?t zum Signieren eines Anwendungsimages oder\n Installationsprogramms verwendet wird, verwenden Sie --mac-app-image-sign-identity und/oder\n --mac-installer-sign-identity. Diese Option kann nicht mit\n --mac-app-image-sign-identity oder --mac-installer-sign-identity kombiniert werden.\n --mac-app-image-sign-identity \n Zum Signieren des Anwendungsimages verwendete Identit?t. Dieser Wert wird\n direkt an die Option --sign des Tools "codesign" ?bergeben. Diese Option kann nicht\n mit --mac-signing-key-user-name kombiniert werden.\n --mac-installer-sign-identity \n Zum Signieren des Installationsprogramms "pkg" verwendete Identit?t. Dieser Wert wird\n direkt an die Option --sign des Tools "productbuild" ?bergeben. Diese Option\n kann nicht mit --mac-signing-key-user-name kombiniert werden.\n --mac-app-store\n Gibt an, dass die jpackage-Ausgabe f?r den\n Mac App Store bestimmt ist.\n --mac-entitlements \n Pfad zu einer Datei mit Berechtigungen, die beim Signieren\n von ausf?hrbaren Dateien und Librarys im Bundle verwendet werden sollen.\n --mac-app-category \n Zeichenfolge f?r das Erstellen von LSApplicationCategoryType in\n Anwendungs-plist. Standardwert: "utilities".\n > 36: MSG_Help_linux_install=\ --linux-package-name \n Name f?r das Linux-Package, Standardwert: Anwendungsname\n --linux-deb-maintainer \n Maintainer f?r .deb-Package\n --linux-menu-group \n Men?gruppe, in der diese Anwendung abgelegt wird\n --linux-package-deps \n Erforderliche Packages oder Funktionen f?r die Anwendung\n --linux-rpm-license-type \n Typ der Lizenz ("License: " der RPM-SPEC-Datei)\n --linux-app-release \n Releasewert der RPM-SPEC-Datei oder \n Debian-Revisionswert der DEB-Kontrolldatei\n --linux-app-category \n Gruppenwert der RPM-SPEC-Datei oder \n Abschnittswert der DEB-Kontrolldatei\n --linux-shortcut\n Erstellt eine Verkn?pfung f?r die Anwendung.\n "package-dep-string" is within "<>" and should not be translated. ja and zh_CN locales remain un-translated as well. I'd like this particular one to be reverted back and we can file an issue with the translation team. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_en.wxl line 1: > 1: This change can be reverted, the English file should not be touched anyways during l10n. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959683606 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167643767 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167645253 From achung at openjdk.org Wed Jun 25 21:28:16 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 25 Jun 2025 21:28:16 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: References: Message-ID: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: revert german translation, revert english wxl format change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25839/files - new: https://git.openjdk.org/jdk/pull/25839/files/67990651..d54f457d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=05-06 Stats: 21 lines in 2 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From jlu at openjdk.org Wed Jun 25 21:43:31 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 25 Jun 2025 21:43:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > revert german translation, revert english wxl format change Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959749881 From jlu at openjdk.org Wed Jun 25 22:55:33 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 25 Jun 2025 22:55:33 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2] In-Reply-To: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com> References: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com> <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com> Message-ID: <9xiUCl6NKMT520fpbnfGriItpYYHh93M9Gn2T5nfEIE=.3e8ab340-855f-47cb-87ba-1d3275a37598@github.com> On Tue, 24 Jun 2025 14:58:38 GMT, Weijun Wang wrote: >> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????". > > Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual. As discussed offline, since there are many instances of this, we will file an issue with the translation team and see if they will agree to the suggested changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167774594 From dnguyen at openjdk.org Thu Jun 26 00:18:39 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 26 Jun 2025 00:18:39 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > revert german translation, revert english wxl format change Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959999177 From serb at openjdk.org Thu Jun 26 01:54:39 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 26 Jun 2025 01:54:39 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 14:59:53 GMT, Alexey Ivanov wrote: >> This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. >> >> Notes: GraphicsDevice provides two methods for handling full-screen windows: >> - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). >> - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. > > test/jdk/java/awt/GraphicsDevice/FullScreenWindowRace.java line 55: > >> 53: gd.setFullScreenWindow(window); >> 54: >> 55: thread.join(15000); > > Does it make sense to reduce the waiting time? The thread should exit much quicker than 15 seconds, 5 second should be plenty enough. It will stop waiting immediately if the thread completes execution, but just to be sure we do not get any false positive results when the test fails on slow systems, I added this timeout. So if it fails it will be a real bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25818#discussion_r2167930721 From psadhukhan at openjdk.org Thu Jun 26 02:31:17 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 02:31:17 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v3] In-Reply-To: References: Message-ID: <-UNv4yQ9lHmLzKrDEUQt31W6WtZ-QvzHUWJM7RVIung=.12e101c4-02b7-4ba7-bdbb-3c35003f52b3@github.com> > Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. > Fixed the keybindings. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25966/files - new: https://git.openjdk.org/jdk/pull/25966/files/4cd7677b..c6aa70bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25966&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25966&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25966.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25966/head:pull/25966 PR: https://git.openjdk.org/jdk/pull/25966 From psadhukhan at openjdk.org Thu Jun 26 02:34:28 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 02:34:28 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v3] In-Reply-To: <-UNv4yQ9lHmLzKrDEUQt31W6WtZ-QvzHUWJM7RVIung=.12e101c4-02b7-4ba7-bdbb-3c35003f52b3@github.com> References: <-UNv4yQ9lHmLzKrDEUQt31W6WtZ-QvzHUWJM7RVIung=.12e101c4-02b7-4ba7-bdbb-3c35003f52b3@github.com> Message-ID: On Thu, 26 Jun 2025 02:31:17 GMT, Prasanta Sadhukhan wrote: >> Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. >> Fixed the keybindings. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix It seems to be "Alert" (Boop) sound being emanated..It probably will need to call macOS NSSound API if we have to replicate..I dont think we want to do this from Swing which is lightweight.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25966#issuecomment-3006835642 From psadhukhan at openjdk.org Thu Jun 26 03:02:06 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 03:02:06 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v28] In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: > When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. > If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Windows 10 offset correction without icon ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/898996a9..f019f638 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=26-27 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324 PR: https://git.openjdk.org/jdk/pull/23324 From psadhukhan at openjdk.org Thu Jun 26 03:09:29 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 03:09:29 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v29] In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: > When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. > If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 - Windows 10 offset correction without icon - Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon - Text alignment fix - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 - Review comments fix - Expand wildcard imports - Remove unneeded methods - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 - Code duplication removed - ... and 23 more: https://git.openjdk.org/jdk/compare/5ac58a9a...ea1016fc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/f019f638..ea1016fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=27-28 Stats: 103274 lines in 1910 files changed: 61970 ins; 26723 del; 14581 mod Patch: https://git.openjdk.org/jdk/pull/23324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324 PR: https://git.openjdk.org/jdk/pull/23324 From psadhukhan at openjdk.org Thu Jun 26 04:36:38 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 04:36:38 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v29] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 03:09:29 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Windows 10 offset correction without icon > - Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon > - Text alignment fix > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Review comments fix > - Expand wildcard imports > - Remove unneeded methods > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Code duplication removed > - ... and 23 more: https://git.openjdk.org/jdk/compare/0f385feb...ea1016fc > 4. If I add another regular menu item with an icon, the icon is rendered below the menu item text. I couldn't reproduce this ![image](https://github.com/user-attachments/assets/1a4b93be-2d8c-4710-b094-4b7a5691d1cf) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3007017870 From abhiscxk at openjdk.org Thu Jun 26 05:03:32 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 26 Jun 2025 05:03:32 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v3] In-Reply-To: <-UNv4yQ9lHmLzKrDEUQt31W6WtZ-QvzHUWJM7RVIung=.12e101c4-02b7-4ba7-bdbb-3c35003f52b3@github.com> References: <-UNv4yQ9lHmLzKrDEUQt31W6WtZ-QvzHUWJM7RVIung=.12e101c4-02b7-4ba7-bdbb-3c35003f52b3@github.com> Message-ID: <6IOIyBunKs4gZI0Ek7xCQXk_XqZPV2MPd4C7Kj3fPFI=.81d87ed9-baaa-494e-8d59-f7a51997a103@github.com> On Thu, 26 Jun 2025 02:31:17 GMT, Prasanta Sadhukhan wrote: >> Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. >> Fixed the keybindings. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Fix test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 62: > 60: frame.pack(); > 61: frame.setLocationRelativeTo(null); > 62: frame.setVisible(true); You may move UI implementation code to helper method. test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 67: > 65: robot.waitForIdle(); > 66: robot.delay(1000); > 67: int selectedRowCount = tree.getSelectionCount(); `tree.getSelectionCount()` on EDT ? test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 82: > 80: System.out.println("rows selected " + curSelectedRowCount); > 81: if (curSelectedRowCount != selectedRowCount + 2) { > 82: throw new RuntimeException("ctrl+shift+down not working"); Does it sound better ? Suggestion: throw new RuntimeException("ctrl+shift+down does not select next row"); test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 89: > 87: robot.keyRelease(KeyEvent.VK_UP); > 88: robot.keyRelease(KeyEvent.VK_SHIFT); > 89: robot.keyRelease(KeyEvent.VK_CONTROL); Helper method can be used to perform robot operations. test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 95: > 93: System.out.println("rows selected " + curSelectedRowCount); > 94: if (curSelectedRowCount != selectedRowCount + 1) { > 95: throw new RuntimeException("ctrl+shift+up not working"); Suggestion: throw new RuntimeException("ctrl+shift+up does not select previous row"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168104410 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168109502 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168107479 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168110873 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168107994 From tr at openjdk.org Thu Jun 26 05:12:28 2025 From: tr at openjdk.org (Tejesh R) Date: Thu, 26 Jun 2025 05:12:28 GMT Subject: RFR: 6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording [v3] In-Reply-To: References: Message-ID: <0xERgjzLkB8oOX67gyMU7PP1-nBD01YQr97NbNrRc7U=.4eff47fd-8c9a-4e2d-90cf-ac76f4602ea3@github.com> On Wed, 25 Jun 2025 12:15:54 GMT, Prasanta Sadhukhan wrote: >> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named". > > Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: > > - Update javadoc > - Update javadoc Marked as reviewed by tr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2960568867 From psadhukhan at openjdk.org Thu Jun 26 05:16:20 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 05:16:20 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v4] In-Reply-To: References: Message-ID: > Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. > Fixed the keybindings. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test modification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25966/files - new: https://git.openjdk.org/jdk/pull/25966/files/c6aa70bd..11b61fac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25966&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25966&range=02-03 Stats: 13 lines in 1 file changed: 8 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25966.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25966/head:pull/25966 PR: https://git.openjdk.org/jdk/pull/25966 From psadhukhan at openjdk.org Thu Jun 26 05:16:20 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 05:16:20 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v3] In-Reply-To: <6IOIyBunKs4gZI0Ek7xCQXk_XqZPV2MPd4C7Kj3fPFI=.81d87ed9-baaa-494e-8d59-f7a51997a103@github.com> References: <-UNv4yQ9lHmLzKrDEUQt31W6WtZ-QvzHUWJM7RVIung=.12e101c4-02b7-4ba7-bdbb-3c35003f52b3@github.com> <6IOIyBunKs4gZI0Ek7xCQXk_XqZPV2MPd4C7Kj3fPFI=.81d87ed9-baaa-494e-8d59-f7a51997a103@github.com> Message-ID: On Thu, 26 Jun 2025 04:55:01 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix > > test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 62: > >> 60: frame.pack(); >> 61: frame.setLocationRelativeTo(null); >> 62: frame.setVisible(true); > > You may move UI implementation code to helper method. Not needed strictly..good to have linear flow.. > test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 67: > >> 65: robot.waitForIdle(); >> 66: robot.delay(1000); >> 67: int selectedRowCount = tree.getSelectionCount(); > > `tree.getSelectionCount()` on EDT ? ok > test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 82: > >> 80: System.out.println("rows selected " + curSelectedRowCount); >> 81: if (curSelectedRowCount != selectedRowCount + 2) { >> 82: throw new RuntimeException("ctrl+shift+down not working"); > > Does it sound better ? > Suggestion: > > throw new RuntimeException("ctrl+shift+down does not select next row"); ok > test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 89: > >> 87: robot.keyRelease(KeyEvent.VK_UP); >> 88: robot.keyRelease(KeyEvent.VK_SHIFT); >> 89: robot.keyRelease(KeyEvent.VK_CONTROL); > > Helper method can be used to perform robot operations. not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168122496 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168122791 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168122589 PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2168122892 From cstein at openjdk.org Thu Jun 26 05:23:31 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 26 Jun 2025 05:23:31 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: References: Message-ID: <4Yu9Xo_LEoSLn6WwWbZB5GoLk0YroJfIT8B2izB5Y2k=.372e1dfb-bf3f-4ca7-be8c-edf13e87533c@github.com> On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > revert german translation, revert english wxl format change German `_de` translations look good to me. ------------- Marked as reviewed by cstein (Committer). PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2960590912 From aivanov at openjdk.org Thu Jun 26 10:43:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 10:43:42 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v29] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <95RxcpNkEymhFsmjOSLSou6PAYDN6DTnfwF5hh1gsd0=.78982cbd-428a-40eb-b208-aa2ccbf79c33@github.com> On Thu, 26 Jun 2025 03:09:29 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Windows 10 offset correction without icon > - Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon > - Text alignment fix > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Review comments fix > - Expand wildcard imports > - Remove unneeded methods > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Code duplication removed > - ... and 23 more: https://git.openjdk.org/jdk/compare/4c5515c7...ea1016fc This is how it looks for me: ![Radio- and check mark menus with additional menu item with an icon with the proposed fix and 200% scale](https://github.com/user-attachments/assets/df50f726-ea4e-4617-ab28-72e0a33f09a6) I haven't pulled your recent changes that you pushed 7 hours ago. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3008030059 From aivanov at openjdk.org Thu Jun 26 11:28:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 11:28:39 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v29] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <3YNrdJdu8o2GRrdrcR-fulBVfquV_WaiohunovoQhTc=.b5293abc-7640-42df-bd8f-70ae5e64a825@github.com> On Thu, 26 Jun 2025 03:09:29 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Windows 10 offset correction without icon > - Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon > - Text alignment fix > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Review comments fix > - Expand wildcard imports > - Remove unneeded methods > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Code duplication removed > - ... and 23 more: https://git.openjdk.org/jdk/compare/10fdd51a...ea1016fc The layout for Windows 11 is still wrong and suffers from the same problems that [I raised yesterday](https://github.com/openjdk/jdk/pull/23324#issuecomment-3005372591). The entire popup menu looks the same way that [I posted about an hour ago](https://github.com/openjdk/jdk/pull/23324#issuecomment-3008030059). The layout for Windows 10 is correct now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3008146432 From psadhukhan at openjdk.org Thu Jun 26 12:17:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 12:17:52 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: > When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. > If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: MenuItem with icon fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/ea1016fc..23485485 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=28-29 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324 PR: https://git.openjdk.org/jdk/pull/23324 From aivanov at openjdk.org Thu Jun 26 12:24:33 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 12:24:33 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 12:17:52 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > MenuItem with icon fix Your latest change has fixed the position of the icon for a regular `JMenuItem`. > > * Text strings will all align. Always > > Current PR doesnt have this..Text string is not aligned for item that doesn't have iconimage with item that does have iconimage. I will fix this. This still remain unresolved: the text of all menu items should be aligned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3008298036 From psadhukhan at openjdk.org Thu Jun 26 12:35:40 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 26 Jun 2025 12:35:40 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 12:21:21 GMT, Alexey Ivanov wrote: > > Current PR doesnt have this..Text string is not aligned for item that doesn't have iconimage with item that does have iconimage. I will fix this. > > This still remain unresolved: the text of all menu items should be aligned. It is fixed for RBMIs as they are part of ButtonGroup (where selecting one will deselect other) so we can find out if any of the RBMIs in that group has imageicon by obtaining ButtonGroup object. CBMIs are not part of group and can be selected/deselected individually so it doesn't seem possible to know from one CBMI whether another CBMI used by application have imageicon or not (similar for regular MIs) so in their case text are aligned individually depending on presence of imageicon for that CBMI (or regular MI) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3008330853 From aivanov at openjdk.org Thu Jun 26 13:58:34 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 13:58:34 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 12:32:42 GMT, Prasanta Sadhukhan wrote: > > > Current PR doesnt have this..Text string is not aligned for item that doesn't have iconimage with item that does have iconimage. I will fix this. > > > > > > This still remain unresolved: the text of all menu items should be aligned. > > It is fixed for RBMIs as they are part of ButtonGroup (where selecting one will deselect other) so we can find out if any of the RBMIs in that group has imageicon by obtaining ButtonGroup object. Why is it important? > CBMIs are not part of group and can be selected/deselected individually so it doesn't seem possible to know from one CBMI whether another CBMI used by application have imageicon or not (similar for regular MIs) so in their case text are aligned individually depending on presence of imageicon for that CBMI (or regular MI) Why is it important? [The rule](https://github.com/openjdk/jdk/pull/23324#issuecomment-3005416654) to switching to two-column layout is as simple as that: > *There's a least one `JCheckBoxMenuItem` and/or `JRadioButtonMenuItem` that has an icon.* If there's at least one `JCheckBoxMenuItem` and/or `JRadioButtonMenuItem` in a popup menu, the entire menu should be laid out in two columns reserved columns: * The first column is for check mark or bullet; * The second column is for the icon associated with a menu item; * The text goes in the third column; * Accelerators are rendered in the fourth column. This is absolutely possible, both Metal & Nimbus L&F use this menu layout.\ ![JMenu layout with radio bullets, check marks and icons in Metal Look-and-Feel](https://github.com/user-attachments/assets/65c5b4bb-dc3b-46dd-a74a-2cb6ef53ccc9) ![JMenu layout with radio bullets, check marks and icons in Nimbus Look-and-Feel](https://github.com/user-attachments/assets/b79ce261-9602-42c4-b3cd-c3686b3cc932) If none of `JCheckBoxMenuItem` and `JRadioButtonMenuItem` has an icon, both check marks / bullets and icons share the same first column. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3008593168 From azvegint at openjdk.org Thu Jun 26 14:12:35 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 26 Jun 2025 14:12:35 GMT Subject: RFR: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java [v10] In-Reply-To: References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: <_LxxiLVsKXNQ6rXEsmZB6o552OTQ_tR4kVWkCK20_sw=.2d5a7d9d-4d41-4679-9f1e-38e51cfc55a4@github.com> On Wed, 18 Jun 2025 22:55:12 GMT, Damon Nguyen wrote: >> This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. >> >> There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. >> >> I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Additional review comments. Looks like the integrate command didn't work this time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25705#issuecomment-3008632542 From dnguyen at openjdk.org Thu Jun 26 14:12:36 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 26 Jun 2025 14:12:36 GMT Subject: Integrated: 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java In-Reply-To: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> References: <_51FeT6L-EisQ8DQgjp-45eadyhLsgJvPgrkHkyE4bA=.9e59ae1b-9561-4c44-a527-820db1401633@github.com> Message-ID: On Mon, 9 Jun 2025 21:17:22 GMT, Damon Nguyen wrote: > This change is to restore the original intent of the test by updating the instructions to check that the type of Cursor is preserved when clicked and dragged. Now the test correctly has instructions to check that an I-beam cursor stays an I-beam until released over a List with its cursor being updated to a Hand cursor. > > There is a bug where this does not correctly update in macOS (found in [JDK-7177297](https://bugs.openjdk.org/browse/JDK-7177297)). So, this test needs to be problem-listed. > > I have confirmed that preserving the cursor image when dragging is native behavior across macOS, Windows, and Ubuntu. And I have checked that the test passes on both Windows and Ubuntu, while macOS fails and immediately updates the cursor as it leaves the TextArea. This pull request has now been integrated. Changeset: 7576064a Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/7576064a10c0f7a1fbfe88fc39254f32005d88f8 Stats: 85 lines in 2 files changed: 66 ins; 3 del; 16 mod 8359061: Update and ProblemList manual test java/awt/Cursor/CursorDragTest/ListDragCursor.java Reviewed-by: honkar, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/25705 From aivanov at openjdk.org Thu Jun 26 14:21:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 14:21:38 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 12:17:52 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > MenuItem with icon fix As I mentioned accelerators column in my previous comment, I realised that I hadn't tested accelerators so far. Indeed, accelerators rendering is broken now: ![JMenu showing accelerators are rendered on top of menu item text](https://github.com/user-attachments/assets/471c87bb-18e0-48c7-b8ec-63b389407a6f) This proves that the layout isn't right. You're trying to fit both check mark / bullet and an icon into the same allocated space by moving text to the right *without reserving additional width for the icon*. At the same time, you move the check mark / bullet to the left. Such approach doesn't respect the default insets added on the left and right of a menu item. The popup menu has to become wider if both check marks / bullets and icons are rendered at the same time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3008665338 From aivanov at openjdk.org Thu Jun 26 15:28:43 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 15:28:43 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 12:17:52 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > MenuItem with icon fix Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 77: > 75: private static Color disabledForeground; > 76: private static Color acceleratorSelectionForeground; > 77: private static Color acceleratorForeground; Why are these static? I'm pretty sure the colors can be menu item specific, although more commonly they would be L&F specific. src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 167: > 165: } > 166: > 167: public static void paintCheckIcon(Graphics g, MenuItemLayoutHelper lh, I suggest creating a new `sun.swing.MenuItemRenderHelper` class similar to `sun.swing.MenuItemLayoutHelper` to keep both layout and renderer closer together. src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java line 723: > 721: acceleratorSelectionForeground); > 722: SwingUtilities3.setAcceleratorForeground(acceleratorForeground); > 723: SwingUtilities3.paintAccText(g, lh, lr); This is a really weird way? Pass the colors explicitly as parameters to the `SwingUtilities3.paintAccText` method. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxMenuItemUI.java line 81: > 79: * Paint MenuItem. > 80: */ > 81: protected void paintMenuItem(Graphics g, JComponent c, This javadoc doesn't add anything on top of what's in the overridden method, remove the javadoc. Add `@Override` annotation. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 891: > 889: // beside imageicon so this check is necessary to differentiate > 890: boolean isWindows11OrLater = Integer.parseInt(System.getProperty("os.name") > 891: .replaceAll("[^0-9]", "")) >= 11; This value can be cached in a static field rather than evaluating it each time `WindowsIconFactory.VistaMenuItemCheckIconFactory.VistaMenuItemCheckIcon.paintIcon` is called. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 927: > 925: skin.paintSkin(g, x - 2 * OFFSET, y, > 926: getIconWidth(), getIconHeight(), backgroundState); > 927: skinWidth = getIconWidth(); To achieve a better layout, the icon size, specifically its width, should increase whenever we detect a situation where both check mark / bullet and associated icon need to be painted together so that `VistaMenuItemCheckIconFactory` returns an instance of `VistaMenuItemCheckIcon` or `Windows11MenuItemCheckIcon` which reserves the space for both check mark / bullet and icon as well as a gap between them. This way, the exiting menu layout code would position the elements correctly. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 73: > 71: private static Color disabledForeground; > 72: private static Color acceleratorSelectionForeground; > 73: private static Color acceleratorForeground; Why are these needed? `BasicMenuItemUI` has fields for all three colors: `disabledForeground`, `acceleratorSelectionForeground`, `acceleratorForeground`. Why do you need to create three *new static* fields instead? src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 157: > 155: UIManager.getColor(prefix + ".disabledForeground"); > 156: } > 157: } I'm not convinced `installDefaults` needs overriding, `BasicMenuItemUI` already provides all these colors via its `BasicMenuItemUI.installDefaults` method and protected fields. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 184: > 182: MenuItemLayoutHelper.LayoutResult lr, Color holdc) { > 183: SwingUtilities3.paintIcon(g, lh, lr, holdc); > 184: } Why are these static methods needed? You can statically import these methods from `SwingUtilities3` (or wherever they end up) and use them as if they're declared locally. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 193: > 191: SwingUtilities3.setAcceleratorForeground(acceleratorForeground); > 192: SwingUtilities3.paintAccText(g, lh, lr); > 193: } Pass the colors explicitly as parameters to the SwingUtilities3.paintAccText method. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 201: > 199: } > 200: > 201: protected void paintMenuItem(Graphics g, JComponent c, Suggestion: @Override protected void paintMenuItem(Graphics g, JComponent c, Add `@Override` annotation. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 234: > 232: } > 233: return iconPresent; > 234: } This should be really simple: private static boolean checkIfImageIconPresent(JMenuItem mi) { return (mi instanceof JCheckBoxMenuItem || mi instanceof JRadioButtonMenuItem) && mi.getIcon() != null; } That is src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 262: > 260: acceleratorFont, MenuItemLayoutHelper.useCheckAndArrow(menuItem), > 261: prefix); > 262: MenuItemLayoutHelper.LayoutResult lr = lh.layoutMenuItem(); Can `acceleratorDelimiter`, `acceleratorFont` be fetched from any `MenuItemUI` classes? Do I understand correctly that the original menu layout that was already performed for a class gets thrown away and is being re-evaluated here? src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 269: > 267: > 268: if ((Integer.parseInt(System.getProperty("os.name") > 269: .replaceAll("[^0-9]", "")) >= 11) You already have this code to detect whether it's Windows 11 or 10, put that code somewhere for re-use instead of duplicating it. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 306: > 304: g.setColor(holdc); > 305: g.setFont(holdf); > 306: return; Suggestion: `return` as the last statement in a method is redundant. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuUI.java line 136: > 134: * Paint MenuItem. > 135: */ > 136: protected void paintMenuItem(Graphics g, JComponent c, Suggestion: @Override protected void paintMenuItem(Graphics g, JComponent c, src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonMenuItemUI.java line 81: > 79: * Paint MenuItem. > 80: */ > 81: protected void paintMenuItem(Graphics g, JComponent c, Suggestion: @Override protected void paintMenuItem(Graphics g, JComponent c, ------------- PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2961758453 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2168941423 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169334895 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169199694 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169272729 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169282066 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169331667 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169217699 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169267877 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169263009 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169219765 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169285512 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169258704 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169310299 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169294403 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169296194 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169298130 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2169302893 From aivanov at openjdk.org Thu Jun 26 15:28:49 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 15:28:49 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v29] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 03:09:29 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Windows 10 offset correction without icon > - Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon > - Text alignment fix > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Review comments fix > - Expand wildcard imports > - Remove unneeded methods > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 > - Code duplication removed > - ... and 23 more: https://git.openjdk.org/jdk/compare/0f1a141e...ea1016fc src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 158: > 156: } > 157: > 158: public static void applyInsets(Rectangle rect, Insets insets) { Isn't a similar helper function already exists? src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 163: > 161: rect.y += insets.top; > 162: rect.width -= (insets.right + rect.x); > 163: rect.height -= (insets.bottom + rect.y); Suggestion: rect.width -= (insets.right + insets.left); rect.height -= (insets.bottom + insets.top); The formula doesn't look right. Why do you subtract `rect.x` and `rect.y` instead of `insets.left` and `insets.top`? This would work correctly if both `rect.x` and `rect.y` are zero, but it would give wrong results in other cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2168848929 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2168852213 From naoto at openjdk.org Thu Jun 26 16:11:35 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 26 Jun 2025 16:11:35 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: References: Message-ID: On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > revert german translation, revert english wxl format change Looks fine to me. Thanks, Alisen! ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2962676541 From kizune at openjdk.org Thu Jun 26 16:31:35 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 26 Jun 2025 16:31:35 GMT Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last character [v3] In-Reply-To: References: Message-ID: On Tue, 24 Jun 2025 11:44:13 GMT, Abhishek Kumar wrote: >> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**. >> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect. >> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**. >> >> After modifying the condition check, expected character is returned. Test is added to verify the check, > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Test extended for WORD and SENTENCE Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25941#pullrequestreview-2962728423 From aivanov at openjdk.org Thu Jun 26 17:32:34 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 26 Jun 2025 17:32:34 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: References: Message-ID: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com> On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > revert german translation, revert english wxl format change src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461: > 459: SliderDemo.majorticks=Hauptteilstriche > 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen > 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972). Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised? Should *Beschriften* rather be *Beschriftung*? Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation? src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 463: > 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften > 462: SliderDemo.minorticks=Hilfsteilstriche > 463: SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, mit Teilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einem sichtbaren Label versehen sind This one is repetitive: Suggestion: SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einer sichtbaren Beschriftung versehen sind ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169540017 PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169535281 From cstein at openjdk.org Thu Jun 26 17:44:34 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 26 Jun 2025 17:44:34 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com> References: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com> Message-ID: On Thu, 26 Jun 2025 17:22:24 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> revert german translation, revert english wxl format change > > src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461: > >> 459: SliderDemo.majorticks=Hauptteilstriche >> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen >> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften > > @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972). > > Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised? > > Should *Beschriften* rather be *Beschriftung*? > > Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation? You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung) > Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation? Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like: _Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169576244 From achung at openjdk.org Thu Jun 26 20:56:39 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 26 Jun 2025 20:56:39 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8] In-Reply-To: References: Message-ID: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25839/files - new: https://git.openjdk.org/jdk/pull/25839/files/d54f457d..dcce2a39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25839.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839 PR: https://git.openjdk.org/jdk/pull/25839 From achung at openjdk.org Thu Jun 26 20:56:40 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 26 Jun 2025 20:56:40 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7] In-Reply-To: References: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com> Message-ID: On Thu, 26 Jun 2025 17:41:13 GMT, Christian Stein wrote: >> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461: >> >>> 459: SliderDemo.majorticks=Hauptteilstriche >>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen >>> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften >> >> @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972). >> >> Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised? >> >> Should *Beschriften* rather be *Beschriftung*? >> >> Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation? > > You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung) > >> Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation? > > Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like: > > _Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_ Maybe better to leave this one as is and next drop the translation team can take another look ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169956970 From abaya at openjdk.org Thu Jun 26 21:22:05 2025 From: abaya at openjdk.org (Anass Baya) Date: Thu, 26 Jun 2025 21:22:05 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v9] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with three additional commits since the last revision: - BogusFocusableWindowState -2- - Add BogusFocusableWindowState - Delete NotifyStressTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/9103d253..0a02b31e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=07-08 Stats: 119 lines in 2 files changed: 50 ins; 69 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From serb at openjdk.org Thu Jun 26 21:38:08 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 26 Jun 2025 21:38:08 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v9] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 21:22:05 GMT, Anass Baya wrote: >> **Analysis:** >> >> We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). >> The race condition between the execution paths of these two native methods sometimes causes an exception >> >> **Proposed Fix:** >> >> While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number >> >> >> public void updateGC() { >> >> int scrn = getScreenImOn(); >> >> if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { >> log.finer("Screen number: " + scrn); >> } >> >> // get current GD >> Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); >> >> Win32GraphicsDevice newDev; >> GraphicsDevice[] devs = GraphicsEnvironment >> .getLocalGraphicsEnvironment() >> .getScreenDevices(); >> >> // Occasionally during device addition/removal getScreenImOn can return >> // a non-existing screen number. Use the default device in this case. >> if (scrn >= devs.length) { >> newDev = (Win32GraphicsDevice) GraphicsEnvironment >> .getLocalGraphicsEnvironment().getDefaultScreenDevice(); >> } else { >> newDev = (Win32GraphicsDevice) devs[scrn]; >> } >> } >> >> >> Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : >> >> jint AwtWindow::_GetScreenImOn(void *param) >> { >> ... >> jboolean destroyed = JNI_GET_DESTROYED(self); >> if (destroyed == JNI_TRUE){ >> env->DeleteGlobalRef(self); >> return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> } >> ... >> >> >> **Tests Summary:** >> >> GetGraphicsStressTest (existing test): >> >> Fails intermittently without the fix >> >> Consistently passes with the fix >> >> NotifyStressTest (newly added test): >> >> Consistently fails without the fix >> >> Consistently passes with the fix > > Anass Baya has updated the pull request incrementally with three additional commits since the last revision: > > - BogusFocusableWindowState -2- > - Add BogusFocusableWindowState > - Delete NotifyStressTest test/jdk/java/awt/Frame/BogusFocusableWindowState/BogusFocusableWindowState.java line 33: > 31: */ > 32: > 33: public final class BogusFocusableWindowState { please split the long line to 80 chars, also the empty line above is not really necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2170063306 From abaya at openjdk.org Thu Jun 26 21:47:07 2025 From: abaya at openjdk.org (Anass Baya) Date: Thu, 26 Jun 2025 21:47:07 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v10] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: Enhanecments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/0a02b31e..ba8e40f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=08-09 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From abaya at openjdk.org Thu Jun 26 21:47:07 2025 From: abaya at openjdk.org (Anass Baya) Date: Thu, 26 Jun 2025 21:47:07 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v9] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 21:35:23 GMT, Sergey Bylokhov wrote: >> Anass Baya has updated the pull request incrementally with three additional commits since the last revision: >> >> - BogusFocusableWindowState -2- >> - Add BogusFocusableWindowState >> - Delete NotifyStressTest > > test/jdk/java/awt/Frame/BogusFocusableWindowState/BogusFocusableWindowState.java line 33: > >> 31: */ >> 32: >> 33: public final class BogusFocusableWindowState { > > please split the long line to 80 chars, also the empty line above is not really necessary. hello @mrserb, Of course, it's done. Thank you. For my proposed test, it does trigger the same exception call stack. However, yours is better. The reproduction frequency with it is 20/20. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2170071747 From abaya at openjdk.org Thu Jun 26 21:53:02 2025 From: abaya at openjdk.org (Anass Baya) Date: Thu, 26 Jun 2025 21:53:02 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v11] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: delete trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/ba8e40f0..9434c982 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From serb at openjdk.org Thu Jun 26 22:19:39 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 26 Jun 2025 22:19:39 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 19:44:10 GMT, Sergey Bylokhov wrote: >> Hello @mrserb, >> What do you think about the test? Does it look good to you? >> KR, > > looking into it It is unclear from the diff, but does the PDATA pData have additional space at the beginning? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2170133199 From abaya at openjdk.org Fri Jun 27 01:56:15 2025 From: abaya at openjdk.org (Anass Baya) Date: Fri, 27 Jun 2025 01:56:15 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v12] In-Reply-To: References: Message-ID: > **Analysis:** > > We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). > The race condition between the execution paths of these two native methods sometimes causes an exception > > **Proposed Fix:** > > While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number > > > public void updateGC() { > > int scrn = getScreenImOn(); > > if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { > log.finer("Screen number: " + scrn); > } > > // get current GD > Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); > > Win32GraphicsDevice newDev; > GraphicsDevice[] devs = GraphicsEnvironment > .getLocalGraphicsEnvironment() > .getScreenDevices(); > > // Occasionally during device addition/removal getScreenImOn can return > // a non-existing screen number. Use the default device in this case. > if (scrn >= devs.length) { > newDev = (Win32GraphicsDevice) GraphicsEnvironment > .getLocalGraphicsEnvironment().getDefaultScreenDevice(); > } else { > newDev = (Win32GraphicsDevice) devs[scrn]; > } > } > > > Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : > > jint AwtWindow::_GetScreenImOn(void *param) > { > ... > jboolean destroyed = JNI_GET_DESTROYED(self); > if (destroyed == JNI_TRUE){ > env->DeleteGlobalRef(self); > return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); > } > ... > > > **Tests Summary:** > > GetGraphicsStressTest (existing test): > > Fails intermittently without the fix > > Consistently passes with the fix > > NotifyStressTest (newly added test): > > Consistently fails without the fix > > Consistently passes with the fix Anass Baya has updated the pull request incrementally with one additional commit since the last revision: Remove trailing space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25619/files - new: https://git.openjdk.org/jdk/pull/25619/files/9434c982..e458e6ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25619&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25619/head:pull/25619 PR: https://git.openjdk.org/jdk/pull/25619 From abaya at openjdk.org Fri Jun 27 01:56:16 2025 From: abaya at openjdk.org (Anass Baya) Date: Fri, 27 Jun 2025 01:56:16 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v4] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 22:16:33 GMT, Sergey Bylokhov wrote: >> looking into it > > It is unclear from the diff, but does the PDATA pData have additional space at the beginning? Yes. it's handled now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25619#discussion_r2170513786 From psadhukhan at openjdk.org Fri Jun 27 03:46:43 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 27 Jun 2025 03:46:43 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com> On Thu, 26 Jun 2025 14:49:16 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> MenuItem with icon fix > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 234: > >> 232: } >> 233: return iconPresent; >> 234: } > > This should be really simple: > > > private static boolean checkIfImageIconPresent(JMenuItem mi) { > return (mi instanceof JCheckBoxMenuItem > || mi instanceof JRadioButtonMenuItem) > && mi.getIcon() != null; > } > > > That is Have you checked this code? It doesn't work for me I get this whereby JRadioButtonMenuItem3 which doesnt have imageicon is not aligned..For this only, we need to know if other RBMIs have imageicon from ButtonGroup or if there any other way, let me know.. ![image](https://github.com/user-attachments/assets/eb2d701e-f235-4527-9f80-e372586fc16a) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2170694169 From abhiscxk at openjdk.org Fri Jun 27 05:07:38 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 27 Jun 2025 05:07:38 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v4] In-Reply-To: References: Message-ID: <-3VwwSfQ8c-lElAyFFtotouKUrc0VCd9YFOBx8eT1Mw=.13b83bfd-06ea-4421-90db-6db1e0953b8e@github.com> On Thu, 26 Jun 2025 05:16:20 GMT, Prasanta Sadhukhan wrote: >> Ctrl+Shift+Down/Up does extend row selection down or up in Aqua L&F as it does in native tree view in Finder. >> Fixed the keybindings. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test modification Verified the fix and look good to me. It aligns with the native side behaviour. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25966#pullrequestreview-2964755314 From abhiscxk at openjdk.org Fri Jun 27 05:07:39 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 27 Jun 2025 05:07:39 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v3] In-Reply-To: References: <-UNv4yQ9lHmLzKrDEUQt31W6WtZ-QvzHUWJM7RVIung=.12e101c4-02b7-4ba7-bdbb-3c35003f52b3@github.com> <6IOIyBunKs4gZI0Ek7xCQXk_XqZPV2MPd4C7Kj3fPFI=.81d87ed9-baaa-494e-8d59-f7a51997a103@github.com> Message-ID: On Thu, 26 Jun 2025 05:12:08 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 62: >> >>> 60: frame.pack(); >>> 61: frame.setLocationRelativeTo(null); >>> 62: frame.setVisible(true); >> >> You may move UI implementation code to helper method. > > Not needed strictly..good to have linear flow.. I agree it's not compulsory but I feel it better from readability POV. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2170789469 From aturbanov at openjdk.org Fri Jun 27 07:56:42 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 27 Jun 2025 07:56:42 GMT Subject: Integrated: 8360487: Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove In-Reply-To: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> References: <4c8G_OM6svOk6RHZ9sRydtG3WPfUImoXfyXWaTi2Ld8=.fc64a957-b8bf-463e-9486-159f84d71117@github.com> Message-ID: <6V0_iv20Ns2_ADm7ZOGhL9CQRsTSnzIAW97s6UK_go8=.999b7461-07f6-445c-92dd-341b404de9bd@github.com> On Mon, 23 Jun 2025 08:53:16 GMT, Andrey Turbanov wrote: > No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner. This pull request has now been integrated. Changeset: 20e983a9 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/20e983a97c66902c61ee2fa1959a7e612266732b Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod 8360487: Remove unnecessary List.indexOf key from AbstractMidiDevice.TransmitterList.remove Reviewed-by: azvegint, serb, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/25931 From aivanov at openjdk.org Fri Jun 27 11:46:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 27 Jun 2025 11:46:45 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com> Message-ID: On Fri, 27 Jun 2025 03:44:23 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 234: >> >>> 232: } >>> 233: return iconPresent; >>> 234: } >> >> This should be really simple: >> >> >> private static boolean checkIfImageIconPresent(JMenuItem mi) { >> return (mi instanceof JCheckBoxMenuItem >> || mi instanceof JRadioButtonMenuItem) >> && mi.getIcon() != null; >> } >> >> >> That is > > Have you checked this code? It doesn't work for me > > I get this whereby JRadioButtonMenuItem3 which doesnt have imageicon is not aligned..For this only, we need to know if other RBMIs have imageicon from ButtonGroup or if there any other way, let me know.. > > ![image](https://github.com/user-attachments/assets/eb2d701e-f235-4527-9f80-e372586fc16a) No, I didn't. It doesn't work because the overall menu layout isn't right at the moment. If you implement [four-column layout](https://github.com/openjdk/jdk/pull/23324#issuecomment-3008593168): check mark / bullet, icon, text, accelerator, it would work. Just like the text of **MenuItem1** and **JCheckBoxMenuItem 3** would be aligned to the text of other menu items. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2171742764 From aivanov at openjdk.org Fri Jun 27 11:57:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 27 Jun 2025 11:57:44 GMT Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 20:56:39 GMT, Alisen Chung wrote: >> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties > > Co-authored-by: Alexey Ivanov Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2966237280 From azvegint at openjdk.org Fri Jun 27 14:35:44 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 27 Jun 2025 14:35:44 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 06:17:32 GMT, Sergey Bylokhov wrote: > This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. > > Notes: GraphicsDevice provides two methods for handling full-screen windows: > - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). > - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25818#pullrequestreview-2966821387 From achung at openjdk.org Fri Jun 27 16:15:51 2025 From: achung at openjdk.org (Alisen Chung) Date: Fri, 27 Jun 2025 16:15:51 GMT Subject: Integrated: 8359761: JDK 25 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung wrote: > This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop. This pull request has now been integrated. Changeset: da7080ff Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/da7080fffb2389465dc9afca6d02e9085fe15302 Stats: 1196 lines in 71 files changed: 814 ins; 93 del; 289 mod 8359761: JDK 25 RDP1 L10n resource files update Reviewed-by: aivanov, almatvee, nbenalla, jlu, dnguyen, cstein, naoto ------------- PR: https://git.openjdk.org/jdk/pull/25839 From rmahajan at openjdk.org Fri Jun 27 18:30:35 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 27 Jun 2025 18:30:35 GMT Subject: RFR: 8349188: LineBorder does not scale correctly Message-ID: Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change. Testing done. ------------- Commit messages: - Update ScaledTextFieldBorderTest.java - 8349188: Expand bug8033699.java to iterate over all LaFs Changes: https://git.openjdk.org/jdk/pull/26025/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349188 Stats: 96 lines in 3 files changed: 43 ins; 19 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/26025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26025/head:pull/26025 PR: https://git.openjdk.org/jdk/pull/26025 From achung at openjdk.org Fri Jun 27 18:31:40 2025 From: achung at openjdk.org (Alisen Chung) Date: Fri, 27 Jun 2025 18:31:40 GMT Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update Message-ID: 8359761: JDK 25 RDP1 L10n resource files update ------------- Commit messages: - Backport da7080fffb2389465dc9afca6d02e9085fe15302 Changes: https://git.openjdk.org/jdk/pull/26026/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26026&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359761 Stats: 1196 lines in 71 files changed: 814 ins; 93 del; 289 mod Patch: https://git.openjdk.org/jdk/pull/26026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26026/head:pull/26026 PR: https://git.openjdk.org/jdk/pull/26026 From jlu at openjdk.org Fri Jun 27 18:48:40 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 27 Jun 2025 18:48:40 GMT Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung wrote: > 8359761: JDK 25 RDP1 L10n resource files update Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967612181 From aivanov at openjdk.org Fri Jun 27 18:58:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 27 Jun 2025 18:58:42 GMT Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung wrote: > 8359761: JDK 25 RDP1 L10n resource files update Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967634176 From aivanov at openjdk.org Fri Jun 27 19:17:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 27 Jun 2025 19:17:40 GMT Subject: RFR: 8349188: LineBorder does not scale correctly In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 18:11:46 GMT, Rajat Mahajan wrote: > Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change. > > Testing done. Looks good except for a few nits. src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 166: > 164: Shape inner; > 165: > 166: int offs = clipRound(this.thickness*scaleFactor); Suggestion: int offs = clipRound(this.thickness * scaleFactor); src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 167: > 165: > 166: int offs = clipRound(this.thickness*scaleFactor); > 167: I'd leave out the added blank line, both `offs` and `size` are still tightly coupled, only the formula for `offs` is amended. test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java line 117: > 115: > 116: for (Point p : test.panelLocations) { > 117: int y = (int) (p.y * test.scale) + (int) (SIZE.height * test.scale / 2); This expression can be simplified: Suggestion: int y = (int) ((p.y + (SIZE.height / 2)) * test.scale); This way may look clearer: find the vertical centre of the panel, taking into account the scale applied. test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java line 302: > 300: private static String getImageFileName(final double scaling, > 301: int thickness) { > 302: return String.format("test%02d@%.2f.png", thickness, scaling); Suggestion: private static String getImageFileName(final double scaling, final int thickness) { return String.format("test%02d@%.2f.png", thickness, scaling); Declare both parameters as `final` to be consistent. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26025#pullrequestreview-2967643714 PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2172687248 PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2172705614 PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2172695201 PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2172700022 From achung at openjdk.org Fri Jun 27 19:31:01 2025 From: achung at openjdk.org (Alisen Chung) Date: Fri, 27 Jun 2025 19:31:01 GMT Subject: [jdk25] Integrated: 8359761: JDK 25 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung wrote: > 8359761: JDK 25 RDP1 L10n resource files update This pull request has now been integrated. Changeset: 12ffb0c1 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/12ffb0c131c5100dc23549b9b7216625bc0dab9e Stats: 1196 lines in 71 files changed: 814 ins; 93 del; 289 mod 8359761: JDK 25 RDP1 L10n resource files update Reviewed-by: jlu, aivanov Backport-of: da7080fffb2389465dc9afca6d02e9085fe15302 ------------- PR: https://git.openjdk.org/jdk/pull/26026 From rmahajan at openjdk.org Fri Jun 27 19:43:56 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 27 Jun 2025 19:43:56 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v2] In-Reply-To: References: Message-ID: > Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change. > > Testing done. Rajat Mahajan has updated the pull request incrementally with three additional commits since the last revision: - Update test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java Co-authored-by: Alexey Ivanov - Update test/jdk/javax/swing/border/LineBorder/ScaledLineBorderTest.java Co-authored-by: Alexey Ivanov - Update src/java.desktop/share/classes/javax/swing/border/LineBorder.java Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26025/files - new: https://git.openjdk.org/jdk/pull/26025/files/01230719..4dd9a0f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26025&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26025&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26025/head:pull/26025 PR: https://git.openjdk.org/jdk/pull/26025 From rmahajan at openjdk.org Fri Jun 27 19:46:56 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 27 Jun 2025 19:46:56 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: > Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change. > > Testing done. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: fix blank line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26025/files - new: https://git.openjdk.org/jdk/pull/26025/files/4dd9a0f3..f6af4cb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26025&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26025&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26025/head:pull/26025 PR: https://git.openjdk.org/jdk/pull/26025 From duke at openjdk.org Fri Jun 27 22:38:13 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 27 Jun 2025 22:38:13 GMT Subject: RFR: 8358813: remove more bindings for JPasswordFields in Aqua Message-ID: There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words. This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.) ------------- Commit messages: - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java - 8358813: remove more bindings for JPasswordFields in Aqua Changes: https://git.openjdk.org/jdk/pull/25688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358813 Stats: 110 lines in 2 files changed: 110 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25688/head:pull/25688 PR: https://git.openjdk.org/jdk/pull/25688 From duke at openjdk.org Fri Jun 27 22:38:13 2025 From: duke at openjdk.org (Jeremy Wood) Date: Fri, 27 Jun 2025 22:38:13 GMT Subject: RFR: 8358813: remove more bindings for JPasswordFields in Aqua In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 02:36:44 GMT, Jeremy Wood wrote: > There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words. > > This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.) IMO this PR is a simple response that interfaces with an existing method. I recommend this approach because it should be relatively low-risk, and it is based on existing precedent. By contrast: #25443 does something more aggressive (and interesting). It replaces selectWordAction with selectLineAction. That looks (to me) like a more thorough/better approach to the general problem of accidentally interacting with words in a password field. This PR should resolve any *KeyStroke-based* actions, but in JDK-8354646 the original complaint had to do with double-clicking the mouse; so this PR wouldn't impact those steps. I haven't explored this thoroughly yet, but glancing through the AccessibleJTextField suggests an AX interface could still have access (via AccessibleActions) to the word-related actions we're trying to restrict access to. If so: this problem (accessing words in a password field) keeps popping up, and removing/replacing the unwanted actions seems like the most thorough response. (Also see JDK-6191897 and JDK-4231444 ). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25688#issuecomment-2954485278 From aturbanov at openjdk.org Fri Jun 27 22:38:13 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 27 Jun 2025 22:38:13 GMT Subject: RFR: 8358813: remove more bindings for JPasswordFields in Aqua In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 02:36:44 GMT, Jeremy Wood wrote: > There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words. > > This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.) test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 59: > 57: UIManager.setLookAndFeel(laf.getClassName()); > 58: return true; > 59: } catch (UnsupportedLookAndFeelException e) { Suggestion: } catch (UnsupportedLookAndFeelException e) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2141039241 From honkar at openjdk.org Fri Jun 27 22:45:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 27 Jun 2025 22:45:40 GMT Subject: RFR: 8358813: remove more bindings for JPasswordFields in Aqua In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 02:36:44 GMT, Jeremy Wood wrote: > There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words. > > This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.) There is a mismatch between the PR title and JBS title [JDK-8358813](https://bugs.openjdk.org/browse/JDK-8358813). ------------- PR Review: https://git.openjdk.org/jdk/pull/25688#pullrequestreview-2968109748 From serb at openjdk.org Sat Jun 28 04:03:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 28 Jun 2025 04:03:04 GMT Subject: RFR: 8359266: Delete the usage of AppContext in the GraphicsDevice [v2] In-Reply-To: References: Message-ID: > This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. > > Notes: GraphicsDevice provides two methods for handling full-screen windows: > - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). > - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8359266 - Create FullScreenWindowRace.java - 8359266: Delete the usage of AppContext in the GraphicsDevice ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25818/files - new: https://git.openjdk.org/jdk/pull/25818/files/f4856925..bdb08a93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25818&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25818&range=00-01 Stats: 30633 lines in 915 files changed: 16999 ins; 8666 del; 4968 mod Patch: https://git.openjdk.org/jdk/pull/25818.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25818/head:pull/25818 PR: https://git.openjdk.org/jdk/pull/25818 From serb at openjdk.org Sat Jun 28 04:30:39 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 28 Jun 2025 04:30:39 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 19:46:56 GMT, Rajat Mahajan wrote: >> Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change. >> >> Testing done. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > fix blank line src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 166: > 164: Shape inner; > 165: > 166: int offs = clipRound(this.thickness * scaleFactor); Please double-check whether you need to use `Region.clipScale()` instead. I actually do not remember when to use one over the other. Maybe if you find a review request for the patch where these methods were added, you can confirm which one should be used. I checked the current source, and it seems that we randomly use one or the other, which seems incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2173117608 From serb at openjdk.org Sat Jun 28 04:30:39 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 28 Jun 2025 04:30:39 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: On Sat, 28 Jun 2025 04:26:31 GMT, Sergey Bylokhov wrote: >> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: >> >> fix blank line > > src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 166: > >> 164: Shape inner; >> 165: >> 166: int offs = clipRound(this.thickness * scaleFactor); > > Please double-check whether you need to use `Region.clipScale()` instead. > > I actually do not remember when to use one over the other. Maybe if you find a review request for the patch where these methods were added, you can confirm which one should be used. I checked the current source, and it seems that we randomly use one or the other, which seems incorrect. it might be possible we should use one for the left/top part and another for the right/bottom so we will not create a gaps. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2173118068 From aivanov at openjdk.org Sat Jun 28 20:11:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sat, 28 Jun 2025 20:11:40 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 19:46:56 GMT, Rajat Mahajan wrote: >> Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change. >> >> Testing done. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > fix blank line Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26025#pullrequestreview-2968974574 From aivanov at openjdk.org Sat Jun 28 20:11:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Sat, 28 Jun 2025 20:11:41 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: On Sat, 28 Jun 2025 04:28:23 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/javax/swing/border/LineBorder.java line 166: >> >>> 164: Shape inner; >>> 165: >>> 166: int offs = clipRound(this.thickness * scaleFactor); >> >> Please double-check whether you need to use `Region.clipScale()` instead. >> >> I actually do not remember when to use one over the other. Maybe if you find a review request for the patch where these methods were added, you can confirm which one should be used. I checked the current source, and it seems that we randomly use one or the other, which seems incorrect. > > it might be possible we should use one for the left/top part and another for the right/bottom so we will not create a gaps. > Please double-check whether you need to use Region.clipScale() instead. @mrserb We use `Region.clipRound` for converting coordinates in `SwingUtilities3.paintBorder`: https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java#L231-L236 These formulas were introduced in #10681 ([JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)); and after refactoring #11571 ([JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680)), the new formulas resolved [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921) after #7449 ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) where there was a gap between the component edge and its border. These formulas specifically addressed the situation with gaps and were developed while we worked on making `LineBorder` and `EtchedBorder` render better at fractional scales. So, using `clipRound` seems good enough. Initially, [I suggested](https://bugs.openjdk.org/browse/JDK-8349188?focusedId=14758933&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14758933) using `(int) (this.thickness * scaleFactor)`, but `clipRound` gives better results. > I actually do not remember when to use one over the other. Maybe if you find a review request for the patch where these methods were added, you can confirm which one should be used. I couldn't find anything explaining where `clipScale` is better than `clipRound`. The discussion for [JDK-8000629](https://bugs.openjdk.org/browse/JDK-8000629) started in [March 2013](https://mail.openjdk.org/pipermail/awt-dev/2013-March/004486.html) and continued in [April 2013](https://mail.openjdk.org/pipermail/awt-dev/2013-April/004577.html). > I checked the current source, and it seems that we randomly use one or the other, which seems incorrect. The javadoc for neither `clipScale` nor `clipRound` provides an example where each method is best suitable. So, it's not that surprising either is used randomly? It seems to me, that both [`clipScale`](https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/sun/java2d/pipe/Region.java#L159) and [`clipRound`](https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/sun/java2d/pipe/Region.java#L140) yield the same result. The former uses `Math.round`, whereas the latter uses `Math.ceil` after subtracting `0.5`. > it might be possible we should use one for the left/top part and another for the right/bottom so we will not create a gaps. Perhaps? However, I'm pretty sure gaps are still possible whatever method we choose because fractional pixels don't fit nicely into the pixel grid. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2173510928 From serb at openjdk.org Sun Jun 29 07:02:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 29 Jun 2025 07:02:48 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: On Sat, 28 Jun 2025 20:06:29 GMT, Alexey Ivanov wrote: >> it might be possible we should use one for the left/top part and another for the right/bottom so we will not create a gaps. > >> Please double-check whether you need to use Region.clipScale() instead. > > @mrserb We use `Region.clipRound` for converting coordinates in `SwingUtilities3.paintBorder`: > > https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java#L231-L236 > > These formulas were introduced in #10681 ([JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)); and after refactoring #11571 ([JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680)), the new formulas resolved [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921) after #7449 ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) where there was a gap between the component edge and its border. These formulas specifically addressed the situation with gaps and were developed while we worked on making `LineBorder` and `EtchedBorder` render better at fractional scales. > > So, using `clipRound` seems good enough. Initially, [I suggested](https://bugs.openjdk.org/browse/JDK-8349188?focusedId=14758933&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14758933) using `(int) (this.thickness * scaleFactor)`, but `clipRound` gives better results. > >> I actually do not remember when to use one over the other. Maybe if you find a review request for the patch where these methods were added, you can confirm which one should be used. > > I couldn't find anything explaining where `clipScale` is better than `clipRound`. The discussion for [JDK-8000629](https://bugs.openjdk.org/browse/JDK-8000629) started in [March 2013](https://mail.openjdk.org/pipermail/awt-dev/2013-March/004486.html) and continued in [April 2013](https://mail.openjdk.org/pipermail/awt-dev/2013-April/004577.html). > >> I checked the current source, and it seems that we randomly use one or the other, which seems incorrect. > > The javadoc for neither `clipScale` nor `clipRound` provides an example where each method is best suitable. So, it's not that surprising either is used randomly? > > It seems to me, that both [`clipScale`](https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/sun/java2d/pipe/Region.java#L159) and [`clipRound`](https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/sun/java2d/pipe/Region.java#L140) yield the same result. The former uses `Math.round`, whereas the latter uses `Math.ceil` after subtracting `0.5`. > >> it might b... I am pretty sure these methods produce different results for negative coordinates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2173617318 From serb at openjdk.org Sun Jun 29 07:02:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 29 Jun 2025 07:02:48 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 06:54:06 GMT, Sergey Bylokhov wrote: >>> Please double-check whether you need to use Region.clipScale() instead. >> >> @mrserb We use `Region.clipRound` for converting coordinates in `SwingUtilities3.paintBorder`: >> >> https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java#L231-L236 >> >> These formulas were introduced in #10681 ([JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)); and after refactoring #11571 ([JDK-8294680](https://bugs.openjdk.org/browse/JDK-8294680)), the new formulas resolved [JDK-8294921](https://bugs.openjdk.org/browse/JDK-8294921) after #7449 ([JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614)) where there was a gap between the component edge and its border. These formulas specifically addressed the situation with gaps and were developed while we worked on making `LineBorder` and `EtchedBorder` render better at fractional scales. >> >> So, using `clipRound` seems good enough. Initially, [I suggested](https://bugs.openjdk.org/browse/JDK-8349188?focusedId=14758933&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14758933) using `(int) (this.thickness * scaleFactor)`, but `clipRound` gives better results. >> >>> I actually do not remember when to use one over the other. Maybe if you find a review request for the patch where these methods were added, you can confirm which one should be used. >> >> I couldn't find anything explaining where `clipScale` is better than `clipRound`. The discussion for [JDK-8000629](https://bugs.openjdk.org/browse/JDK-8000629) started in [March 2013](https://mail.openjdk.org/pipermail/awt-dev/2013-March/004486.html) and continued in [April 2013](https://mail.openjdk.org/pipermail/awt-dev/2013-April/004577.html). >> >>> I checked the current source, and it seems that we randomly use one or the other, which seems incorrect. >> >> The javadoc for neither `clipScale` nor `clipRound` provides an example where each method is best suitable. So, it's not that surprising either is used randomly? >> >> It seems to me, that both [`clipScale`](https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/sun/java2d/pipe/Region.java#L159) and [`clipRound`](https://github.com/openjdk/jdk/blob/a23de2ec090628b52532ee5d9bd4364a97499f5b/src/java.desktop/share/classes/sun/java2d/pipe/Region.java#L140) yield the same result. The former uses `Math.round`, whereas the latter uses `Math.ceil` aft... > > I am pretty sure these methods produce different results for negative coordinates. probably these discussions may help https://mail.openjdk.org/pipermail/2d-dev/2016-July/007152.html https://mail.openjdk.org/pipermail/2d-dev/2016-October/007764.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2173617586 From serb at openjdk.org Sun Jun 29 07:02:49 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 29 Jun 2025 07:02:49 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: Message-ID: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> On Sun, 29 Jun 2025 06:54:56 GMT, Sergey Bylokhov wrote: >> I am pretty sure these methods produce different results for negative coordinates. > > probably these discussions may help > https://mail.openjdk.org/pipermail/2d-dev/2016-July/007152.html > https://mail.openjdk.org/pipermail/2d-dev/2016-October/007764.html And this https://mail.openjdk.org/pipermail/2d-dev/2016-October/007772.html (it has a looong discissuin thread) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2173618432 From serb at openjdk.org Sun Jun 29 19:46:51 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 29 Jun 2025 19:46:51 GMT Subject: Integrated: 8359266: Delete the usage of AppContext in the GraphicsDevice In-Reply-To: References: Message-ID: On Mon, 16 Jun 2025 06:17:32 GMT, Sergey Bylokhov wrote: > This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated. > > Notes: GraphicsDevice provides two methods for handling full-screen windows: > - setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods ([example](https://github.com/openjdk/jdk/blob/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf/src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java#L226)). > - getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test. This pull request has now been integrated. Changeset: 240541e1 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/240541e1c1e3aee633da08e7d12117b8ea38b8f4 Stats: 93 lines in 2 files changed: 65 ins; 23 del; 5 mod 8359266: Delete the usage of AppContext in the GraphicsDevice Reviewed-by: aivanov, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/25818 From psadhukhan at openjdk.org Mon Jun 30 02:19:48 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 30 Jun 2025 02:19:48 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v29] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 26 Jun 2025 11:33:15 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan 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 33 additional commits since the last revision: >> >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 >> - Windows 10 offset correction without icon >> - Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon >> - Text alignment fix >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 >> - Review comments fix >> - Expand wildcard imports >> - Remove unneeded methods >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760 >> - Code duplication removed >> - ... and 23 more: https://git.openjdk.org/jdk/compare/30e97b8d...ea1016fc > > src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 163: > >> 161: rect.y += insets.top; >> 162: rect.width -= (insets.right + rect.x); >> 163: rect.height -= (insets.bottom + rect.y); > > Suggestion: > > rect.width -= (insets.right + insets.left); > rect.height -= (insets.bottom + insets.top); > > The formula doesn't look right. Why do you subtract `rect.x` and `rect.y` instead of `insets.left` and `insets.top`? > > This would work correctly if both `rect.x` and `rect.y` are zero, but it would give wrong results in other cases. It was the same calculation used in `BasicMenuItemUI `which is now moved to `SwingUtilities3 `so that it can be called from Basic and `WindowsMenuItemUI `to avoid code duplication....you can compare the contents before the fix.....in this specific case, `rect.x` is inclusive of `insets.left`.. Similarly other SwingUtilities3 changes are also as it was in BasicMenuItemUI, it was just moved verbatim from BasicMenuItemUI to it so that it can be called from both Basic and WindowsMenuItemUI class with no changes..nothing more and nothing less...probably it can be optimized but I wanted to keep the call and the content in each method in SwingUtilities3 same as it was in BasicMenuItemUI ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2174091099 From psadhukhan at openjdk.org Mon Jun 30 02:19:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 30 Jun 2025 02:19:49 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com> Message-ID: On Fri, 27 Jun 2025 11:44:01 GMT, Alexey Ivanov wrote: >> Have you checked this code? It doesn't work for me >> >> I get this whereby JRadioButtonMenuItem3 which doesnt have imageicon is not aligned..For this only, we need to know if other RBMIs have imageicon from ButtonGroup or if there any other way, let me know.. >> >> ![image](https://github.com/user-attachments/assets/eb2d701e-f235-4527-9f80-e372586fc16a) > > No, I didn't. > > It doesn't work because the overall menu layout isn't right at the moment. If you implement [four-column layout](https://github.com/openjdk/jdk/pull/23324#issuecomment-3008593168): check mark / bullet, icon, text, accelerator, it would work. Just like the text of **MenuItem1** and **JCheckBoxMenuItem 3** would be aligned to the text of other menu items. Probably you missed seeing it but already _5-column layout_ is implemented via [MenuItemLayoutHelper.layoutMenuItem.](https://github.com/openjdk/jdk/blob/ecd2d83096a1fea7d5086736306770bcffa4fdb6/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L464-L476) In the PR. `WindowsMenuItemUI.paintMenuItem` calls `MenuItemLayoutHelper.layoutMenuItem` to layout in 5 columns actually through check icon + icon + text + accelerator text + arrow icon layout via `paintCheckIcon, paintIcon, paintText, paintAccText and paintArrowIcon` call in `WindowsMenuItemUI.paintMenuItem` seems like offset value used in WindowsIconFactory paintIcon is not matching with MenuItemLayout expectation and wrong rendering is happening at slightly off position ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2174089015 From serb at openjdk.org Mon Jun 30 04:30:46 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 30 Jun 2025 04:30:46 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v12] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 01:56:15 GMT, Anass Baya wrote: >> **Analysis:** >> >> We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). >> The race condition between the execution paths of these two native methods sometimes causes an exception >> >> **Proposed Fix:** >> >> While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number >> >> >> public void updateGC() { >> >> int scrn = getScreenImOn(); >> >> if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { >> log.finer("Screen number: " + scrn); >> } >> >> // get current GD >> Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); >> >> Win32GraphicsDevice newDev; >> GraphicsDevice[] devs = GraphicsEnvironment >> .getLocalGraphicsEnvironment() >> .getScreenDevices(); >> >> // Occasionally during device addition/removal getScreenImOn can return >> // a non-existing screen number. Use the default device in this case. >> if (scrn >= devs.length) { >> newDev = (Win32GraphicsDevice) GraphicsEnvironment >> .getLocalGraphicsEnvironment().getDefaultScreenDevice(); >> } else { >> newDev = (Win32GraphicsDevice) devs[scrn]; >> } >> } >> >> >> Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : >> >> jint AwtWindow::_GetScreenImOn(void *param) >> { >> ... >> jboolean destroyed = JNI_GET_DESTROYED(self); >> if (destroyed == JNI_TRUE){ >> env->DeleteGlobalRef(self); >> return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> } >> ... >> >> >> **Tests Summary:** >> >> GetGraphicsStressTest (existing test): >> >> Fails intermittently without the fix >> >> Consistently passes with the fix >> >> NotifyStressTest (newly added test): >> >> Consistently fails without the fix >> >> Consistently passes with the fix > > Anass Baya has updated the pull request incrementally with one additional commit since the last revision: > > Remove trailing space Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25619#pullrequestreview-2969860404 From duke at openjdk.org Mon Jun 30 04:38:48 2025 From: duke at openjdk.org (duke) Date: Mon, 30 Jun 2025 04:38:48 GMT Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources unavailable [v12] In-Reply-To: References: Message-ID: On Fri, 27 Jun 2025 01:56:15 GMT, Anass Baya wrote: >> **Analysis:** >> >> We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects(). >> The race condition between the execution paths of these two native methods sometimes causes an exception >> >> **Proposed Fix:** >> >> While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number >> >> >> public void updateGC() { >> >> int scrn = getScreenImOn(); >> >> if (screenLog.isLoggable(PlatformLogger.Level.FINER)) { >> log.finer("Screen number: " + scrn); >> } >> >> // get current GD >> Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice(); >> >> Win32GraphicsDevice newDev; >> GraphicsDevice[] devs = GraphicsEnvironment >> .getLocalGraphicsEnvironment() >> .getScreenDevices(); >> >> // Occasionally during device addition/removal getScreenImOn can return >> // a non-existing screen number. Use the default device in this case. >> if (scrn >= devs.length) { >> newDev = (Win32GraphicsDevice) GraphicsEnvironment >> .getLocalGraphicsEnvironment().getDefaultScreenDevice(); >> } else { >> newDev = (Win32GraphicsDevice) devs[scrn]; >> } >> } >> >> >> Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed : >> >> jint AwtWindow::_GetScreenImOn(void *param) >> { >> ... >> jboolean destroyed = JNI_GET_DESTROYED(self); >> if (destroyed == JNI_TRUE){ >> env->DeleteGlobalRef(self); >> return AwtWin32GraphicsDevice::GetDefaultDeviceIndex(); >> } >> ... >> >> >> **Tests Summary:** >> >> GetGraphicsStressTest (existing test): >> >> Fails intermittently without the fix >> >> Consistently passes with the fix >> >> NotifyStressTest (newly added test): >> >> Consistently fails without the fix >> >> Consistently passes with the fix > > Anass Baya has updated the pull request incrementally with one additional commit since the last revision: > > Remove trailing space @anass-baya Your change (at version e458e6ec49bf9c520204dc9a323228cd068a96bc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25619#issuecomment-3017754152 From duke at openjdk.org Mon Jun 30 04:42:40 2025 From: duke at openjdk.org (duke) Date: Mon, 30 Jun 2025 04:42:40 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v8] In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: On Mon, 9 Jun 2025 18:22:20 GMT, Anass Baya wrote: >> **Analysis :** >> >> Whether the test passes on the main line or fails, the behavior is still incorrect. >> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly. >> >> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >> >> This causes the test to proceed immediately to the validation step: >> >> if (fd.isVisible()) { >> throw new RuntimeException("File Dialog is not closed"); >> } >> >> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet) >> >> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation. >> >> **Proposed fix:** >> >> set the CountDownLatch to 2 >> >> **Proposed enhancements :** >> >> Remove unnecessary threads (Thread and Thread-2) >> Properly handle delays and robot.waitForIdle() >> Avoid indefinite blocking on latch.await() >> >> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds >> >> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details > > Anass Baya has updated the pull request incrementally with six additional commits since the last revision: > > - The bug id is not needed > > Co-authored-by: Abhishek Kumar > - No need to add bug id > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Increased the latch timeout to ensure the test doesn't fail incorrectly. @anass-baya Your change (at version 50bc31039ceb792d2d582a75c44aaef0b670a5ee) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-3017769931 From psadhukhan at openjdk.org Mon Jun 30 05:57:30 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 30 Jun 2025 05:57:30 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v31] In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: > When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. > If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Alignment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/23485485..24fb8195 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=29-30 Stats: 42 lines in 2 files changed: 1 ins; 37 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324 PR: https://git.openjdk.org/jdk/pull/23324 From rgupta at openjdk.org Mon Jun 30 12:22:55 2025 From: rgupta at openjdk.org (Ravi Gupta) Date: Mon, 30 Jun 2025 12:22:55 GMT Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in finally block Message-ID: Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block. + finally { + if (frame != null) { + frame.dispose(); + frame = null; + } + } ------------- Commit messages: - 8361067: Test ExtraButtonDrag.java requires frame.dispose in finally block Changes: https://git.openjdk.org/jdk/pull/26043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361067 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26043/head:pull/26043 PR: https://git.openjdk.org/jdk/pull/26043 From aivanov at openjdk.org Mon Jun 30 12:25:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 12:25:44 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> References: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> Message-ID: On Sun, 29 Jun 2025 06:58:38 GMT, Sergey Bylokhov wrote: >> probably these discussions may help >> https://mail.openjdk.org/pipermail/2d-dev/2016-July/007152.html >> https://mail.openjdk.org/pipermail/2d-dev/2016-October/007764.html > > And this https://mail.openjdk.org/pipermail/2d-dev/2016-October/007772.html (it has a looong discissuin thread) > I am pretty sure these methods produce different results for negative coordinates. Likely? Yet when a border is painted, there can't be negative coordinates. > probably these discussions may help https://mail.openjdk.org/pipermail/2d-dev/2016-July/007152.html https://mail.openjdk.org/pipermail/2d-dev/2016-October/007764.html > > And this https://mail.openjdk.org/pipermail/2d-dev/2016-October/007772.html (it has a looong discissuin thread) I'll look through these discussions, thanks. (These discussions happened in three years after `clipScale` and `clipRound` had been added.) The last discussion thread could be the best source for clarity. It would be a helpful to understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2174949328 From aivanov at openjdk.org Mon Jun 30 13:04:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 13:04:45 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com> Message-ID: On Mon, 30 Jun 2025 02:13:37 GMT, Prasanta Sadhukhan wrote: >> No, I didn't. >> >> It doesn't work because the overall menu layout isn't right at the moment. If you implement [four-column layout](https://github.com/openjdk/jdk/pull/23324#issuecomment-3008593168): check mark / bullet, icon, text, accelerator, it would work. Just like the text of **MenuItem1** and **JCheckBoxMenuItem 3** would be aligned to the text of other menu items. > > Probably you missed seeing it but already _5-column layout_ is implemented via [MenuItemLayoutHelper.layoutMenuItem.](https://github.com/openjdk/jdk/blob/ecd2d83096a1fea7d5086736306770bcffa4fdb6/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L464-L476) > In the PR. `WindowsMenuItemUI.paintMenuItem` calls `MenuItemLayoutHelper.layoutMenuItem` to layout in 5 columns actually through > check icon + icon + text + accelerator text + arrow icon layout > via `paintCheckIcon, paintIcon, paintText, paintAccText and paintArrowIcon` call in `WindowsMenuItemUI.paintMenuItem` > > seems like offset value used in WindowsIconFactory paintIcon is not matching with MenuItemLayout expectation and wrong rendering is happening at slightly off position As I said, I didn't look deeply into the details. If the menu layout already implements a 5-column layout, this is what I expect because both Metal and Nimbus look exactly like a 5-column layout. Yet Windows L&F is still off, and the margins and offsets don't match what one sees in File Explorer in Windows 11. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2175022017 From aivanov at openjdk.org Mon Jun 30 13:23:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 13:23:45 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v30] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com> Message-ID: On Mon, 30 Jun 2025 13:01:49 GMT, Alexey Ivanov wrote: >> Probably you missed seeing it but already _5-column layout_ is implemented via [MenuItemLayoutHelper.layoutMenuItem.](https://github.com/openjdk/jdk/blob/ecd2d83096a1fea7d5086736306770bcffa4fdb6/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L464-L476) >> In the PR. `WindowsMenuItemUI.paintMenuItem` calls `MenuItemLayoutHelper.layoutMenuItem` to layout in 5 columns actually through >> check icon + icon + text + accelerator text + arrow icon layout >> via `paintCheckIcon, paintIcon, paintText, paintAccText and paintArrowIcon` call in `WindowsMenuItemUI.paintMenuItem` >> >> seems like offset value used in WindowsIconFactory paintIcon is not matching with MenuItemLayout expectation and wrong rendering is happening at slightly off position > > As I said, I didn't look deeply into the details. > > The menu layout already implements a 5-column layout ? this is what I expect because both Metal and Nimbus look exactly like a 5-column layout. Yet Windows L&F is still off, and the margins and offsets don't match what one sees in File Explorer in Windows 11. After your latest fix, the accelerator doesn't get painted over the menu text, but the positioning is still way off. With the added column for the icon the menu width has to increase but it hasn't. Instead, the width remains the same, and you squeeze both check mark / bullet and icon to the same allocated space. The position of the check mark must not change in the new layout. In old rendering code, the was 29-pixel margin between the left edge and first pixel of the check mark (at 200% scale), but now it's reduced to 23 pixels only. There was 24-pixel margin between an icon and text, but now it's only 6 pixels. The margin between menu text and accelerator is reduced from 12 pixels to 4. The menu looks too crowded, squished. You have to properly add *a new column for the icon* with margins around it whenever a popup menu has a JCheckBoxMenuItem or JRadioButtonMenuItem with an icon. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2175066908 From aivanov at openjdk.org Mon Jun 30 14:48:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 14:48:44 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v31] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Mon, 30 Jun 2025 05:57:30 GMT, Prasanta Sadhukhan wrote: >> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. >> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Alignment fix src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 928: > 926: getIconWidth(), getIconHeight(), backgroundState); > 927: skinWidth = getIconWidth(); > 928: skin = xp.getSkin(c, part); What I expect to see here is that the skin is always painted at (`x + OFFSET, y + OFFSET`) skin.paintSkin(g, x + OFFSET, y + OFFSET, state); in both Windows 10 and 11. The check mark and bullet have to remain on their own designated place. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 940: > 938: icon.paintIcon(c, g, x + icon.getIconWidth(), > 939: y + OFFSET); > 940: } If an icon is present, it gets painted instead of check mark or bullet in Windows 10. In Windows 11 the icon gets painted on * on the same location in regular case when the current popup menu contains no check or radio menu items with an icon; * on its own column with has proper large margins when there's at least one check or radio menu item with an icon; the size of the entire popup has to increase to allocate space for the icon column. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2175235234 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2175244401 From aivanov at openjdk.org Mon Jun 30 15:00:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 15:00:39 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> References: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> Message-ID: On Sun, 29 Jun 2025 06:58:38 GMT, Sergey Bylokhov wrote: >> probably these discussions may help >> https://mail.openjdk.org/pipermail/2d-dev/2016-July/007152.html >> https://mail.openjdk.org/pipermail/2d-dev/2016-October/007764.html > > And this https://mail.openjdk.org/pipermail/2d-dev/2016-October/007772.html (it has a looong discissuin thread) @mrserb Putting the discussions aside, does the suggested fix look good to you? As I said, border painting uses `clipRound` consistently: both in coordinate calculation and in thickness calculation. This approach resolves the problem reported. Looking at descriptions of `clipScale` and `clipRound`, it seems the former suits better? Yet it makes the rendering less consistent with other borders: using `clipScale` switches to 2-pixel and 3-pixel border at 1.50 and 2.50 correspondingly (from 1 and 2 with `clipRound`). In other cases, the border thickness also increases, which may be undesirable. Overall, there are 6 failures of the `ScaledLineBorderTest.java` test when the code in JDK uses `clipScale` instead of `clipRound`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2175286281 From aivanov at openjdk.org Mon Jun 30 15:08:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 15:08:41 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> Message-ID: On Mon, 30 Jun 2025 14:57:34 GMT, Alexey Ivanov wrote: >> And this https://mail.openjdk.org/pipermail/2d-dev/2016-October/007772.html (it has a looong discissuin thread) > > @mrserb Putting the discussions aside, does the suggested fix look good to you? > > As I said, border painting uses `clipRound` consistently: both in coordinate calculation and in thickness calculation. This approach resolves the problem reported. > > Looking at descriptions of `clipScale` and `clipRound`, it seems the former suits better? Yet it makes the rendering less consistent with other borders: using `clipScale` switches to 2-pixel and 3-pixel border at 1.50 and 2.50 correspondingly (from 1 and 2 with `clipRound`). In other cases, the border thickness also increases, which may be undesirable. > > Overall, there are 6 failures of the `ScaledLineBorderTest.java` test when the code in JDK uses `clipScale` instead of `clipRound`. I looked at another test case Rajat and I discussed, and using `clipScale` doesn't help there either. I prefer rendering with `clipRound`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2175305371 From serb at openjdk.org Mon Jun 30 16:26:43 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 30 Jun 2025 16:26:43 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> Message-ID: On Mon, 30 Jun 2025 15:05:55 GMT, Alexey Ivanov wrote: >> @mrserb Putting the discussions aside, does the suggested fix look good to you? >> >> As I said, border painting uses `clipRound` consistently: both in coordinate calculation and in thickness calculation. This approach resolves the problem reported. >> >> Looking at descriptions of `clipScale` and `clipRound`, it seems the former suits better? Yet it makes the rendering less consistent with other borders: using `clipScale` switches to 2-pixel and 3-pixel border at 1.50 and 2.50 correspondingly (from 1 and 2 with `clipRound`). In other cases, the border thickness also increases, which may be undesirable. >> >> Overall, there are 6 failures of the `ScaledLineBorderTest.java` test when the code in JDK uses `clipScale` instead of `clipRound`. > > I looked at another test case Rajat and I discussed, and using `clipScale` doesn't help there either. I prefer rendering with `clipRound`. My point is to investigate the difference between clipScale and clipRound to ensure the correct one is used. There was a complex discussion before about similar issue, which is why we currently have two separate versions of this rounding logic. Simply replacing one with the other might not work and some other tweaks should be done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2175466296 From aivanov at openjdk.org Mon Jun 30 17:09:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 17:09:40 GMT Subject: RFR: 8349188: LineBorder does not scale correctly [v3] In-Reply-To: References: <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com> Message-ID: <7BXx2SffjA3gTNkytfYV3meBKrle7kLGk6z1vKdR9kM=.c0a87b7b-019f-46a1-adbd-21586ccd6c69@github.com> On Mon, 30 Jun 2025 16:24:09 GMT, Sergey Bylokhov wrote: >> I looked at another test case Rajat and I discussed, and using `clipScale` doesn't help there either. I prefer rendering with `clipRound`. > > My point is to investigate the difference between clipScale and clipRound to ensure the correct one is used. There was a complex discussion before about similar issue, which is why we currently have two separate versions of this rounding logic. Simply replacing one with the other might not work and some other tweaks should be done. My point is `clipRound` works good in this use case, *it resolves the problem*, I see no reason not to accept the fix. --- I agree with your general concern that we should understand better the purpose of each of the methods. Yet no one seems to remember the outcome of that complex discussion, therefore switching to `clipScale` could be postponed; if it's deemed necessary, we can easily change the method, both in the implementation and in the test. I submitted [JDK-8361095](https://bugs.openjdk.org/browse/JDK-8361095) to ensure this current discussion isn't forgotten and we figure out the purpose and guidelines for `clipScale` and `clipRound`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2175537369 From aivanov at openjdk.org Mon Jun 30 18:31:43 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 18:31:43 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v8] In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: On Mon, 9 Jun 2025 18:22:20 GMT, Anass Baya wrote: >> **Analysis :** >> >> Whether the test passes on the main line or fails, the behavior is still incorrect. >> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly. >> >> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >> >> This causes the test to proceed immediately to the validation step: >> >> if (fd.isVisible()) { >> throw new RuntimeException("File Dialog is not closed"); >> } >> >> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet) >> >> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation. >> >> **Proposed fix:** >> >> set the CountDownLatch to 2 >> >> **Proposed enhancements :** >> >> Remove unnecessary threads (Thread and Thread-2) >> Properly handle delays and robot.waitForIdle() >> Avoid indefinite blocking on latch.await() >> >> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds >> >> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details > > Anass Baya has updated the pull request incrementally with six additional commits since the last revision: > > - The bug id is not needed > > Co-authored-by: Abhishek Kumar > - No need to add bug id > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java > > Co-authored-by: Abhishek Kumar > - Increased the latch timeout to ensure the test doesn't fail incorrectly. Changes requested by aivanov (Reviewer). test/jdk/java/awt/FileDialog/DoubleActionESC.java line 41: > 39: /* > 40: * @test > 41: * @bug 5097243 Add another `@run` to this test instead of creating a new one. * @key headful * @run main DoubleActionESC * @run main/othervm -Dsun.awt.disableGtkFileDialogs=true DoubleActionESC * ``` test/jdk/java/awt/FileDialog/DoubleActionESCWithGtkDisabled.java line 37: > 35: DoubleActionESC.main(args); > 36: } > 37: } A file should end with `\n` to avoid this error. No need to create another test, just add another `@run` into existing test. ------------- PR Review: https://git.openjdk.org/jdk/pull/25184#pullrequestreview-2972239652 PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2175656286 PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2175654225 From aivanov at openjdk.org Mon Jun 30 18:37:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 18:37:42 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v8] In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: On Mon, 30 Jun 2025 18:27:46 GMT, Alexey Ivanov wrote: >> Anass Baya has updated the pull request incrementally with six additional commits since the last revision: >> >> - The bug id is not needed >> >> Co-authored-by: Abhishek Kumar >> - No need to add bug id >> >> Co-authored-by: Abhishek Kumar >> - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java >> >> Co-authored-by: Abhishek Kumar >> - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java >> >> Co-authored-by: Abhishek Kumar >> - Update test/jdk/java/awt/FileDialog/DoubleActionESC.java >> >> Co-authored-by: Abhishek Kumar >> - Increased the latch timeout to ensure the test doesn't fail incorrectly. > > test/jdk/java/awt/FileDialog/DoubleActionESCWithGtkDisabled.java line 37: > >> 35: DoubleActionESC.main(args); >> 36: } >> 37: } > > A file should end with `\n` to avoid this error. > > No need to create another test, just add another `@run` into existing test. To avoid the warning *No newline at end of file* displayed at the end of the file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25184#discussion_r2175664949 From abaya at openjdk.org Mon Jun 30 18:57:26 2025 From: abaya at openjdk.org (Anass Baya) Date: Mon, 30 Jun 2025 18:57:26 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v9] In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: > **Analysis :** > > Whether the test passes on the main line or fails, the behavior is still incorrect. > This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly. > > However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. > > This causes the test to proceed immediately to the validation step: > > if (fd.isVisible()) { > throw new RuntimeException("File Dialog is not closed"); > } > > At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet) > > To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation. > > **Proposed fix:** > > set the CountDownLatch to 2 > > **Proposed enhancements :** > > Remove unnecessary threads (Thread and Thread-2) > Properly handle delays and robot.waitForIdle() > Avoid indefinite blocking on latch.await() > > With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds > > The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details Anass Baya has updated the pull request incrementally with two additional commits since the last revision: - Run the test with disableGtkFileDialogs - No need for new test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25184/files - new: https://git.openjdk.org/jdk/pull/25184/files/50bc3103..7d850fed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25184&range=07-08 Stats: 38 lines in 2 files changed: 1 ins; 37 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25184/head:pull/25184 PR: https://git.openjdk.org/jdk/pull/25184 From aivanov at openjdk.org Mon Jun 30 19:02:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 30 Jun 2025 19:02:46 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v9] In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: On Mon, 30 Jun 2025 18:57:26 GMT, Anass Baya wrote: >> **Analysis :** >> >> Whether the test passes on the main line or fails, the behavior is still incorrect. >> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly. >> >> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >> >> This causes the test to proceed immediately to the validation step: >> >> if (fd.isVisible()) { >> throw new RuntimeException("File Dialog is not closed"); >> } >> >> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet) >> >> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation. >> >> **Proposed fix:** >> >> set the CountDownLatch to 2 >> >> **Proposed enhancements :** >> >> Remove unnecessary threads (Thread and Thread-2) >> Properly handle delays and robot.waitForIdle() >> Avoid indefinite blocking on latch.await() >> >> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds >> >> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details > > Anass Baya has updated the pull request incrementally with two additional commits since the last revision: > > - Run the test with disableGtkFileDialogs > - No need for new test Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25184#pullrequestreview-2972324049 From duke at openjdk.org Mon Jun 30 19:05:41 2025 From: duke at openjdk.org (duke) Date: Mon, 30 Jun 2025 19:05:41 GMT Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v9] In-Reply-To: References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com> Message-ID: On Mon, 30 Jun 2025 18:57:26 GMT, Anass Baya wrote: >> **Analysis :** >> >> Whether the test passes on the main line or fails, the behavior is still incorrect. >> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly. >> >> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt. >> >> This causes the test to proceed immediately to the validation step: >> >> if (fd.isVisible()) { >> throw new RuntimeException("File Dialog is not closed"); >> } >> >> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet) >> >> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation. >> >> **Proposed fix:** >> >> set the CountDownLatch to 2 >> >> **Proposed enhancements :** >> >> Remove unnecessary threads (Thread and Thread-2) >> Properly handle delays and robot.waitForIdle() >> Avoid indefinite blocking on latch.await() >> >> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds >> >> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details > > Anass Baya has updated the pull request incrementally with two additional commits since the last revision: > > - Run the test with disableGtkFileDialogs > - No need for new test @anass-baya Your change (at version 7d850fed18abb0753264333f644a469dd997d4b6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25184#issuecomment-3020378214 From aturbanov at openjdk.org Mon Jun 30 20:33:39 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 30 Jun 2025 20:33:39 GMT Subject: RFR: 8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F [v4] In-Reply-To: References: Message-ID: <5jo-MGJwBlvYvA0jUnEu3IMYdzdfiuO10qvvOMnwG5g=.ec85f355-6b72-41a7-acad-e0e03849ef70@github.com> On Thu, 26 Jun 2025 05:16:20 GMT, Prasanta Sadhukhan wrote: >> Ctrl+Shift+Down/Up doesn't extend row selection down or up in Aqua L&F as it does in native tree view in Finder. >> Fixed the keybindings. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test modification test/jdk/javax/swing/JTree/TestTreeRowSelection.java line 47: > 45: static volatile int curSelectedRowCount; > 46: > 47: public static void main(String[] args) throws Exception { Suggestion: public static void main(String[] args) throws Exception { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25966#discussion_r2175844134