From duke at openjdk.org Wed Jan 1 21:43:27 2025 From: duke at openjdk.org (Jeremy) Date: Wed, 1 Jan 2025 21:43:27 GMT Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for JPEG Message-ID: This adds support for parsing thumbnails in an APP1 Exif marker. This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.) The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.) ------------- Commit messages: - 8160327: removed unused field - 8160327: fixing typo in comment - 8160327: if thumbnailLength == 0, we don't have a thumbnail - 8160327: avoid ArrayIndexOutOfBoundsE for unknown data format - 8160327: support malformed IFD - 8160327: wrap LocaleDateTime.parse in try/catch - 8160327: clarifying comment - 8160327: adding a new test case where the timestamp is "0000:00..." - 8160327: adding a new test case where `compression` = 0x60000 - 8160327: updating test to include "ImageCreationTime" - ... and 7 more: https://git.openjdk.org/jdk/compare/f7f2b42e...05ee149c Changes: https://git.openjdk.org/jdk/pull/22898/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8160327 Stats: 658 lines in 11 files changed: 654 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898 PR: https://git.openjdk.org/jdk/pull/22898 From abhiscxk at openjdk.org Thu Jan 2 05:31:34 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 2 Jan 2025 05:31:34 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v3] In-Reply-To: References: Message-ID: > For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. > > Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. > > AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. > > Manual test case is added to verify the shortcut for JMenuItems. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Review comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22822/files - new: https://git.openjdk.org/jdk/pull/22822/files/a83aa98f..b6169d3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=01-02 Stats: 5 lines in 2 files changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22822/head:pull/22822 PR: https://git.openjdk.org/jdk/pull/22822 From abhiscxk at openjdk.org Thu Jan 2 05:34:52 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 2 Jan 2025 05:34:52 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v2] In-Reply-To: <3uoXnpkV7U20bFvhgINlfbo39HlvrrGeRXdBHxtE83A=.928bdafc-8ae6-47d9-b328-27c98a02edf8@github.com> References: <3uoXnpkV7U20bFvhgINlfbo39HlvrrGeRXdBHxtE83A=.928bdafc-8ae6-47d9-b328-27c98a02edf8@github.com> Message-ID: On Tue, 24 Dec 2024 19:51:12 GMT, Alexander Zuev wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright year and test update > > src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 3975: > >> 3973: keyCode = keyStroke.getKeyCode(); >> 3974: debugString("[INFO]: Shortcut is: " + Integer.toHexString(keyCode)); >> 3975: if (keyCode != 0) { > > Why do we need this check? If keyCode is not zero we return keyCode but if it is zero we will still return keyCode because we return zero after the condition. Yeah, the condition check is not needed. Updated. > test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 37: > >> 35: * @summary Tests that JAWS announce the shortcuts for JMenuItems. >> 36: * @library /java/awt/regtesthelpers >> 37: * @build PassFailJFrame > > Since instructions mention JAWS i would either make this test Windows specific or if you want to test t on mac too i would rephrase the instructions so they are not OS specific. Either way will work for me. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1900551704 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1900551451 From kizune at openjdk.org Thu Jan 2 06:35:34 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 2 Jan 2025 06:35:34 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v3] In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 05:31:34 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update This version looks good. Manually tested with both JAWS and NVDA haven't found no functional regressions. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22822#pullrequestreview-2527075694 From duke at openjdk.org Thu Jan 2 06:49:19 2025 From: duke at openjdk.org (Jeremy) Date: Thu, 2 Jan 2025 06:49:19 GMT Subject: RFR: 8160327: Support for thumbnails present in APP1 marker for JPEG [v2] In-Reply-To: References: Message-ID: <9O2VRa0ye98EUfHo5GXExxOL7HYq9Bx5Lfa7oNuBnkM=.409a6095-e51b-4392-91e4-53a3b81acea3@github.com> > This adds support for parsing thumbnails in an APP1 Exif marker. > > This builds on an unfinished proposal by Brian Burkhalter (around 2016). In that previous work the only additional meta info he parsed was the image creation time; this PR similarly includes the same property. (I can't speak to why he included that property, but it looks like he has a lot of experience with ImageIO so I trust his judgment.) > > The test addresses the original images attached to the ticket plus a few extra images I found on my computer that include unusual properties. (Possibly those images are malformed, but if they exist in the wild and other platforms support them then I'd prefer to support them too.) Jeremy has updated the pull request incrementally with one additional commit since the last revision: 8160327: fixing typo so `thumbnailPos` can be zero The `thumbnailLength` cannot be zero, but the position can be. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22898/files - new: https://git.openjdk.org/jdk/pull/22898/files/05ee149c..20d44cfb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22898&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22898.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22898/head:pull/22898 PR: https://git.openjdk.org/jdk/pull/22898 From acobbs at openjdk.org Thu Jan 2 20:06:54 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 2 Jan 2025 20:06:54 GMT Subject: RFR: 8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) Message-ID: Please review this patch which removes unnecessary `@SuppressWarnings` annotations. This issue is a follow up to [JDK-8343476](https://bugs.openjdk.org/browse/JDK-8343476) to remove some additional warnings that were missed in that issue. ------------- Commit messages: - Remove unnecessary @SuppressWarnings annotations. Changes: https://git.openjdk.org/jdk/pull/22906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346953 Stats: 27 lines in 9 files changed: 0 ins; 18 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22906/head:pull/22906 PR: https://git.openjdk.org/jdk/pull/22906 From vdyakov at openjdk.org Thu Jan 2 20:43:37 2025 From: vdyakov at openjdk.org (Victor Dyakov) Date: Thu, 2 Jan 2025 20:43:37 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v3] In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 05:31:34 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update @prsadhuk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/22822#issuecomment-2568352351 From psadhukhan at openjdk.org Fri Jan 3 04:34:13 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 3 Jan 2025 04:34:13 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel Message-ID: "OptionPane.buttonFont" and "OptionPane.messageFont" property are ignored for Nimbus L&F as for Nimbus, lookup calls initiated by BasicOptionPaneUI#configureButton and BasicOptionPaneUI#configureMessageLabel, were redirected via SynthContext so UIManager.getDefaults L&F properties were ignored.. Added way to honor this properties for SynthOptionPaneUI..It could be later extended for other UI properties for other widgets which may need UIManager lookup.. ------------- Commit messages: - dummy commit - 8346260: Test javax/swing/JOptionPane/bug4174551.java failed because the font size of message Hi 24 is not set to 24 in Nimbus LookAndFeel Changes: https://git.openjdk.org/jdk/pull/22908/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22908&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346260 Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22908.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22908/head:pull/22908 PR: https://git.openjdk.org/jdk/pull/22908 From rkannathpari at openjdk.org Fri Jan 3 04:52:04 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Fri, 3 Jan 2025 04:52:04 GMT Subject: RFR: 8346846 : Open source PageRangesException.java test Message-ID: Hi All, I have updated the test and made it automation friendly. Please review and let me know your suggestions ------------- Commit messages: - 8334644 : Automate javax/print/attribute/PageRangesException.java Changes: https://git.openjdk.org/jdk/pull/22909/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22909&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346846 Stats: 55 lines in 1 file changed: 55 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22909.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22909/head:pull/22909 PR: https://git.openjdk.org/jdk/pull/22909 From jkratochvil at openjdk.org Fri Jan 3 09:19:34 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 3 Jan 2025 09:19:34 GMT Subject: RFR: 8346436: Compilation with clang fails [v2] In-Reply-To: <2T1MSOZ5x2Aui8EwMvWvLEXeUGmty5PLl1nuAWSZZ74=.02465712-ad35-48c7-83e9-8e825b92f35a@github.com> References: <2T1MSOZ5x2Aui8EwMvWvLEXeUGmty5PLl1nuAWSZZ74=.02465712-ad35-48c7-83e9-8e825b92f35a@github.com> Message-ID: > clang-18.1.8-1.fc40.x86_64 > Fedora 40 x86_64 > fbd76ca8edd756ff2ebbc9f6477cc1a827df67b0 > > > src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); > | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:375:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 375 | write(splash->controlpipe[1], &code, 1); > | ^~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:713:5: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 713 | pipe(splash->controlpipe); > | ^~~~ ~~~~~~~~~~~~~~~~~~~ > src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h:45:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined] > 45 | #define dprintf(s) > | ^ > /usr/include/bits/stdio2.h:121:12: note: previous definition is here > 121 | # define dprintf(fd, ...) \ > | ^ > src/java.smartcardio/share/native/libj2pcsc/pcsc.c:48:9: error: 'dprintf' macro redefined [-Werror,-Wmacro-redefined] > 48 | #define dprintf(s) > | ^ > /usr/include/bits/stdio2.h:121:12: note: previous definition is here > 121 | # define dprintf(fd, ...) \ > | ^ Jan Kratochvil 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: - Use only (void) casts - Merge branch 'master' into clangbuild - 8346436: Compilation with clang fails ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22794/files - new: https://git.openjdk.org/jdk/pull/22794/files/3e81ab51..0e2ab3b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22794&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22794&range=00-01 Stats: 10553 lines in 262 files changed: 7856 ins; 1822 del; 875 mod Patch: https://git.openjdk.org/jdk/pull/22794.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22794/head:pull/22794 PR: https://git.openjdk.org/jdk/pull/22794 From jkratochvil at openjdk.org Fri Jan 3 09:19:36 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 3 Jan 2025 09:19:36 GMT Subject: RFR: 8346436: Compilation with clang fails [v2] In-Reply-To: References: <2T1MSOZ5x2Aui8EwMvWvLEXeUGmty5PLl1nuAWSZZ74=.02465712-ad35-48c7-83e9-8e825b92f35a@github.com> Message-ID: On Fri, 20 Dec 2024 18:58:44 GMT, Phil Race wrote: >> Jan Kratochvil 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: >> >> - Use only (void) casts >> - Merge branch 'master' into clangbuild >> - 8346436: Compilation with clang fails > > src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 696: > >> 694: if (!isMainThread() && awt_pipe_inited) { >> 695: if (write ( AWT_WRITEPIPE, &wakeUp_char, 1 ) != 1) { >> 696: fprintf(stderr, "Cannot not write to AWT utility control: %s\n", strerror(errno)); > > what happens to the process if this call fails ? > Can it continue ? > You can check by commenting out the call and see what happens when you run AWT tests > And assuming it is a continuable error, can you do the print only in a DEBUG build ? I have verified this `write()` call is exercised by the testsuite (`test/jdk/java/awt`) but the syscall never fails during my testsuite run. In the scope of this patch I can also just cast the syscall to `(void)`. I did not want to do the cast as it will hide an unchecked error path for the future. For something more I expect one should rather port it to Qt or GTK(GDK) but I do not think my employer has free capacity for that. I can also change it according to your directions but (1) I do not have an opinion what it will do and (2) IMO such engineering is out of scope of this patch. I can also just cast it to `(void)` and file a JDK issue for that. > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 377: > >> 375: if (write(splash->controlpipe[1], &code, 1) != 1) { >> 376: fprintf(stderr, "Cannot not write to splash screen control: %s\n", strerror(errno)); >> 377: } > > what happens to the process if this call fails ? > Can it continue ? > You can check by commenting out the call and see what happens when you run an app on Linux that uses splashScreen ? SwingSet2 would be sufficient. > And assuming it is a continuable error, can you do the print only in a DEBUG build ? Likewise, the testcase is `test/jdk/java/awt/SplashScreen`. > src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 716: > >> 714: SplashLock(splash); >> 715: if (pipe(splash->controlpipe)) { >> 716: fprintf(stderr, "Error creating pipe for splash screen control: %s\n", strerror(errno)); > > what happens to the process if this call fails ? > Can it continue ? > You can check by commenting out the call and see what happens when you run an app on Linux that uses splashScreen ? SwingSet2 would be sufficient. > And assuming it is a continuable error, can you do the print only in a DEBUG build ? Likewise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22794#discussion_r1901595237 PR Review Comment: https://git.openjdk.org/jdk/pull/22794#discussion_r1901595633 PR Review Comment: https://git.openjdk.org/jdk/pull/22794#discussion_r1901595792 From aivanov at openjdk.org Fri Jan 3 13:47:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Jan 2025 13:47:46 GMT Subject: RFR: 8346846 : Open source PageRangesException.java test In-Reply-To: References: Message-ID: <7xNBrvKN1tGCVZ2WB88mZTwXpYqZF1_lgl4M_nobNgU=.0dd23d91-f94a-4341-b3f3-df170fd3c0f8@github.com> On Fri, 3 Jan 2025 04:47:41 GMT, Renjith Kannath Pariyangad wrote: > Hi All, > > I have updated the test and made it automation friendly. Please review and let me know your suggestions Looks good to me except for minor comments. test/jdk/javax/print/attribute/PageRangesException.java line 2: > 1: /* > 2: * Copyright (c) 2001, 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2001, 2025, Oracle and/or its affiliates. All rights reserved. The year should be 2025 now. test/jdk/javax/print/attribute/PageRangesException.java line 44: > 42: } > 43: > 44: //test 4433096 Suggestion: // test 4433096 For consistency. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22909#pullrequestreview-2529105119 PR Review Comment: https://git.openjdk.org/jdk/pull/22909#discussion_r1901798977 PR Review Comment: https://git.openjdk.org/jdk/pull/22909#discussion_r1901798404 From aivanov at openjdk.org Fri Jan 3 14:08:49 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Jan 2025 14:08:49 GMT Subject: RFR: 8346846 : Open source PageRangesException.java test In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 04:47:41 GMT, Renjith Kannath Pariyangad wrote: > Hi All, > > I have updated the test and made it automation friendly. Please review and let me know your suggestions Use [JDK-8334644](https://bugs.openjdk.org/browse/JDK-8334644) as the bug id for this PR. I've closed [JDK-8346846](https://bugs.openjdk.org/browse/JDK-8346846) as duplicate of JDK-8334644. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22909#issuecomment-2569269742 From aivanov at openjdk.org Fri Jan 3 14:15:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Jan 2025 14:15:45 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 03:01:48 GMT, Prasanta Sadhukhan wrote: > "OptionPane.buttonFont" and "OptionPane.messageFont" property are ignored for Nimbus L&F as for Nimbus, lookup calls initiated by BasicOptionPaneUI#configureButton and BasicOptionPaneUI#configureMessageLabel, were redirected via SynthContext so UIManager.getDefaults L&F properties were ignored.. > Added way to honor this properties for SynthOptionPaneUI..It could be later extended for other UI properties for other widgets which may need UIManager lookup.. I wonder if such a customisation is supported. Synth and Nimbus don't always use the `UIMaganager` to set the defaults. Perhaps, these Look-and-Feels should be excluded from this test. On the other hand, Swing usually allows such customisations and respects settings in `UIManger`? but doing so in Synth and Nimbus often looks inconsistent and requires special handling of UI-delegate classes. src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDefaultLookup.java line 44: > 42: if (value != null) { > 43: return value; > 44: } It should probably call `super.getDefault` rather than use `UIManager` directly. test/jdk/javax/swing/JOptionPane/bug4174551.java line 26: > 24: /* > 25: * @test > 26: * @bug 4174551 8346260 Should the test exercise all available Look and Feels? ------------- PR Review: https://git.openjdk.org/jdk/pull/22908#pullrequestreview-2529127099 PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1901811650 PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1901817555 From aivanov at openjdk.org Fri Jan 3 14:32:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Jan 2025 14:32:55 GMT Subject: RFR: 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:02:52 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.parser.Entity#entityTypes` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. > Similar to what we did in #21825. This looks good to me. It aligns `javax.swing.text.html.parser.Entity` to `javax.swing.text.html.parser.Element` which you did in #21825. @turbanoff Could you re-open the issue? I'll run the tests with this change in our CI. ------------- PR Review: https://git.openjdk.org/jdk/pull/21831#pullrequestreview-2529171594 From psadhukhan at openjdk.org Fri Jan 3 15:05:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 3 Jan 2025 15:05:41 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel [v2] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 14:13:15 GMT, Alexey Ivanov wrote: > I wonder if such a customisation is supported. Synth and Nimbus don't always use the `UIMaganager` to set the defaults. Perhaps, these Look-and-Feels should be excluded from this test. > > On the other hand, Swing usually allows such customisations and respects settings in `UIManger`? but doing so in Synth and Nimbus often looks inconsistent and requires special handling of UI-delegate classes. I thought about ignoring this property for Synth and probably close "Not an issue" but I could not find in spec of not honoring UIManager properties in Synth so added this fix...I guess we can argue for both for and against of adding this support in Synth but since it's pretty early in jdk25 mainline so any problem arising out of this can be tackled before the final release.. > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDefaultLookup.java line 44: > >> 42: if (value != null) { >> 43: return value; >> 44: } > > It should probably call `super.getDefault` rather than use `UIManager` directly. ok.. > test/jdk/javax/swing/JOptionPane/bug4174551.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 4174551 8346260 > > Should the test exercise all available Look and Feels? SInce it's manual test, I guess this will make it more complex..its good as it is.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22908#issuecomment-2569363281 PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1901867449 PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1901867980 From aivanov at openjdk.org Fri Jan 3 19:37:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Jan 2025 19:37:39 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v3] In-Reply-To: References: Message-ID: <36VkJltnv5w6PBy9E6NmTJPGrnJ5XFQUyz80XH9D3A0=.7991ae7b-bdde-4f65-a785-dc38e4d3334d@github.com> On Thu, 2 Jan 2025 05:31:34 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Review comment update Looks good to me except for minor comments. You may want to bump up the copyright year to 2025 now. src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 3975: > 3973: keyCode = keyStroke.getKeyCode(); > 3974: debugString("[INFO]: Shortcut is: " + Integer.toHexString(keyCode)); > 3975: return (char) keyCode; Suggestion: return (char)keyCode; For consistency with the `return` statements above which have no space after the cast. test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 49: > 47: 3. Navigate the Menu Items by using UP / DOWN arrow key > 48: 4. Press Pass if you are able to hear correct JAWS announcements > 49: for each menu item shorcut else Fail. Suggestion: for each menu item shortcut else Fail. Typo. You should probably remove the period? to be consistent. Either add ending punctuation to each instruction item, nor don't add it at all, including the last item. test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 65: > 63: > 64: JMenuBar menuBar = new JMenuBar(); > 65: JMenu menu = new JMenu("Menu with Keystrokes"); Suggestion: JMenu menu = new JMenu("Menu with shortcuts"); You refer to concept as ?shortcuts? in the instructions. test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 107: > 105: menu.add(menuItem7); > 106: > 107: frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); You should not define a default close operation for a manual test, the `PassFailJFrame` framework handles closing the test window and fails the test. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22822#pullrequestreview-2529606057 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1902098356 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1902102157 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1902101228 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1902100219 From aivanov at openjdk.org Fri Jan 3 19:53:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Jan 2025 19:53:36 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel [v2] In-Reply-To: References: Message-ID: <_AjyDJlwclv1Q1HrgggVBaYEox8L87yBKjc_-Vx__mU=.875596ef-401e-4fe1-a726-d1365462f325@github.com> On Fri, 3 Jan 2025 15:01:17 GMT, Prasanta Sadhukhan wrote: >> "OptionPane.buttonFont" and "OptionPane.messageFont" property are ignored for Nimbus L&F as for Nimbus, lookup calls initiated by BasicOptionPaneUI#configureButton and BasicOptionPaneUI#configureMessageLabel, were redirected via SynthContext so UIManager.getDefaults L&F properties were ignored.. >> Added way to honor this properties for SynthOptionPaneUI..It could be later extended for other UI properties for other widgets which may need UIManager lookup.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Call super Marked as reviewed by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDefaultLookup.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2003, 2025, Oracle and/or its affiliates. All rights reserved. It's the third day of 2025. ------------- PR Review: https://git.openjdk.org/jdk/pull/22908#pullrequestreview-2529620310 PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1902107033 From aivanov at openjdk.org Fri Jan 3 20:08:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 3 Jan 2025 20:08:41 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel [v2] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 15:02:13 GMT, Prasanta Sadhukhan wrote: > > I wonder if such a customisation is supported. Synth and Nimbus don't always use the `UIMaganager` to set the defaults. Perhaps, these Look-and-Feels should be excluded from this test. > > On the other hand, Swing usually allows such customisations and respects settings in `UIManger`? but doing so in Synth and Nimbus often looks inconsistent and requires special handling of UI-delegate classes. > > I thought about ignoring this property for Synth and probably close "Not an issue" but I could not find in spec of not honoring UIManager properties in Synth so added this fix...I guess we can argue for both for and against of adding this support in Synth but since it's pretty early in jdk25 mainline so any problem arising out of this can be tackled before the final release.. What I don't like with the current approach is that we'll need to add an `instanceof` for each component to support customisation. If `UIManager` properties should be honoured, `SynthContext`, `SynthStyle` or whatever holds the defaults should look up properties in `UIManager` too. The [`SynthStyle` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/plaf/synth/SynthStyle.html) represents ?a set of style properties.? It loads the defaults from a synth file? Anyway, it's out of scope for the current fix. If it's a one-off fix for one component, it's okay to handle it this way. Yet if the number of components and/or properties grows, we should rethink how Synth-based look-and-feels can be customised via `UIManager` just like all other L&Fs. >> test/jdk/javax/swing/JOptionPane/bug4174551.java line 26: >> >>> 24: /* >>> 25: * @test >>> 26: * @bug 4174551 8346260 >> >> Should the test exercise all available Look and Feels? > > SInce it's manual test, I guess this will make it more complex..its good as it is.. Fair enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22908#issuecomment-2569753058 PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1902125579 From dnguyen at openjdk.org Fri Jan 3 20:45:37 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 3 Jan 2025 20:45:37 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel [v2] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 15:01:17 GMT, Prasanta Sadhukhan wrote: >> "OptionPane.buttonFont" and "OptionPane.messageFont" property are ignored for Nimbus L&F as for Nimbus, lookup calls initiated by BasicOptionPaneUI#configureButton and BasicOptionPaneUI#configureMessageLabel, were redirected via SynthContext so UIManager.getDefaults L&F properties were ignored.. >> Added way to honor this properties for SynthOptionPaneUI..It could be later extended for other UI properties for other widgets which may need UIManager lookup.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Call super Ran java test with updates. "Hi 24" looks like it's showing properly. LGTM ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/22908#pullrequestreview-2529687496 From dnguyen at openjdk.org Fri Jan 3 20:45:37 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 3 Jan 2025 20:45:37 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel [v2] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 20:05:38 GMT, Alexey Ivanov wrote: >> SInce it's manual test, I guess this will make it more complex..its good as it is.. > > Fair enough. Does the year for this test have to be updated as well? Curious since it's only adding a bugID, but we're still touching the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1902147464 From rkannathpari at openjdk.org Mon Jan 6 05:43:19 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Mon, 6 Jan 2025 05:43:19 GMT Subject: RFR: 8334644 : Automate javax/print/attribute/PageRangesException.java [v2] In-Reply-To: References: Message-ID: > Hi All, > > I have updated the test and made it automation friendly. Please review and let me know your suggestions Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: Updated copy right year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22909/files - new: https://git.openjdk.org/jdk/pull/22909/files/aee78aa0..9ef119e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22909&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22909&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22909.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22909/head:pull/22909 PR: https://git.openjdk.org/jdk/pull/22909 From abhiscxk at openjdk.org Mon Jan 6 05:48:17 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 6 Jan 2025 05:48:17 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v4] In-Reply-To: References: Message-ID: > For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. > > Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. > > AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. > > Manual test case is added to verify the shortcut for JMenuItems. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Copyright year and minor fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22822/files - new: https://git.openjdk.org/jdk/pull/22822/files/b6169d3d..7e5b00d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=02-03 Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22822/head:pull/22822 PR: https://git.openjdk.org/jdk/pull/22822 From abhiscxk at openjdk.org Mon Jan 6 05:48:18 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 6 Jan 2025 05:48:18 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v3] In-Reply-To: <36VkJltnv5w6PBy9E6NmTJPGrnJ5XFQUyz80XH9D3A0=.7991ae7b-bdde-4f65-a785-dc38e4d3334d@github.com> References: <36VkJltnv5w6PBy9E6NmTJPGrnJ5XFQUyz80XH9D3A0=.7991ae7b-bdde-4f65-a785-dc38e4d3334d@github.com> Message-ID: On Fri, 3 Jan 2025 19:32:59 GMT, Alexey Ivanov wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment update > > test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 49: > >> 47: 3. Navigate the Menu Items by using UP / DOWN arrow key >> 48: 4. Press Pass if you are able to hear correct JAWS announcements >> 49: for each menu item shorcut else Fail. > > Suggestion: > > for each menu item shortcut else Fail. > > Typo. > > You should probably remove the period? to be consistent. Either add ending punctuation to each instruction item, nor don't add it at all, including the last item. Updated > test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 107: > >> 105: menu.add(menuItem7); >> 106: >> 107: frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); > > You should not define a default close operation for a manual test, the `PassFailJFrame` framework handles closing the test window and fails the test. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1903683465 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1903683805 From psadhukhan at openjdk.org Mon Jan 6 06:04:39 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Jan 2025 06:04:39 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel [v2] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 20:05:13 GMT, Alexey Ivanov wrote: > > > I wonder if such a customisation is supported. Synth and Nimbus don't always use the `UIMaganager` to set the defaults. Perhaps, these Look-and-Feels should be excluded from this test. > > > On the other hand, Swing usually allows such customisations and respects settings in `UIManger`? but doing so in Synth and Nimbus often looks inconsistent and requires special handling of UI-delegate classes. > > > > > > I thought about ignoring this property for Synth and probably close "Not an issue" but I could not find in spec of not honoring UIManager properties in Synth so added this fix...I guess we can argue for both for and against of adding this support in Synth but since it's pretty early in jdk25 mainline so any problem arising out of this can be tackled before the final release.. > > What I don't like with the current approach is that we'll need to add an `instanceof` for each component to support customisation. If `UIManager` properties should be honoured, `SynthContext`, `SynthStyle` or whatever holds the defaults should look up properties in `UIManager` too. The [`SynthStyle` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/plaf/synth/SynthStyle.html) represents ?a set of style properties.? It loads the defaults from a synth file? > > Anyway, it's out of scope for the current fix. If it's a one-off fix for one component, it's okay to handle it this way. Yet if the number of components and/or properties grows, we should rethink how Synth-based look-and-feels can be customised via `UIManager` just like all other L&Fs. It is supposed to be one-off fix so I did via this instanceof check but if more such widgets needs UIManager lookup, then I was thinking of introducing an "else" block to "! instanceof SynthUI" check since I guess most of the widget could be of SynthUI subclass ------------- PR Comment: https://git.openjdk.org/jdk/pull/22908#issuecomment-2572338695 From psadhukhan at openjdk.org Mon Jan 6 06:04:40 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Jan 2025 06:04:40 GMT Subject: RFR: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel [v2] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 20:42:04 GMT, Damon Nguyen wrote: >> Fair enough. > > Does the year for this test have to be updated as well? Curious since it's only adding a bugID, but we're still touching the test. We are not changing any test logic so I am refraining from changing copyright year.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22908#discussion_r1903695896 From psadhukhan at openjdk.org Mon Jan 6 06:04:40 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Jan 2025 06:04:40 GMT Subject: Integrated: 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 03:01:48 GMT, Prasanta Sadhukhan wrote: > "OptionPane.buttonFont" and "OptionPane.messageFont" property are ignored for Nimbus L&F as for Nimbus, lookup calls initiated by BasicOptionPaneUI#configureButton and BasicOptionPaneUI#configureMessageLabel, were redirected via SynthContext so UIManager.getDefaults L&F properties were ignored.. > Added way to honor this properties for SynthOptionPaneUI..It could be later extended for other UI properties for other widgets which may need UIManager lookup.. This pull request has now been integrated. Changeset: 93938978 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/9393897817a3280e08a8278b86df71f59608be9c Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod 8346260: Test "javax/swing/JOptionPane/bug4174551.java" failed because the font size of message "Hi 24" is not set to 24 in Nimbus LookAndFeel Reviewed-by: aivanov, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/22908 From abhiscxk at openjdk.org Mon Jan 6 06:10:27 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 6 Jan 2025 06:10:27 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v5] In-Reply-To: References: Message-ID: <92Ewtiyn46SRvX1hVvyHgJQjcf53RtnY5In1lnVZIn4=.19d58ee1-4cb5-4f9d-a59a-17f4ca0c929b@github.com> > For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. > > Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. > > AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. > > Manual test case is added to verify the shortcut for JMenuItems. 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 five additional commits since the last revision: - Merge branch 'master' into JDK-8339728 - Copyright year and minor fix - Review comment update - Copyright year and test update - MenuItem shortcut accessibility fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22822/files - new: https://git.openjdk.org/jdk/pull/22822/files/7e5b00d3..64ecaf0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=03-04 Stats: 177173 lines in 5136 files changed: 120891 ins; 38678 del; 17604 mod Patch: https://git.openjdk.org/jdk/pull/22822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22822/head:pull/22822 PR: https://git.openjdk.org/jdk/pull/22822 From psadhukhan at openjdk.org Mon Jan 6 06:19:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Jan 2025 06:19:50 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v5] In-Reply-To: <92Ewtiyn46SRvX1hVvyHgJQjcf53RtnY5In1lnVZIn4=.19d58ee1-4cb5-4f9d-a59a-17f4ca0c929b@github.com> References: <92Ewtiyn46SRvX1hVvyHgJQjcf53RtnY5In1lnVZIn4=.19d58ee1-4cb5-4f9d-a59a-17f4ca0c929b@github.com> Message-ID: <01gHhpucOg0qX1UUnEGCYerhDaIz2PdQE9eTaSxAYtU=.3f731c32-8f15-494b-b9bb-872ceeb219bc@github.com> On Mon, 6 Jan 2025 06:10:27 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8339728 > - Copyright year and minor fix > - Review comment update > - Copyright year and test update > - MenuItem shortcut accessibility fix src/jdk.accessibility/windows/native/include/bridge/AccessBridgePackages.h line 2: > 1: /* > 2: * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved. this copyright also needs to be updated.. test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 45: > 43: public static void main(String[] args) throws Exception { > 44: String INSTRUCTIONS = """ > 45: 1. Start the JAWS aplication "application" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1903709299 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1903712911 From psadhukhan at openjdk.org Mon Jan 6 06:28:41 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Jan 2025 06:28:41 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v5] In-Reply-To: <92Ewtiyn46SRvX1hVvyHgJQjcf53RtnY5In1lnVZIn4=.19d58ee1-4cb5-4f9d-a59a-17f4ca0c929b@github.com> References: <92Ewtiyn46SRvX1hVvyHgJQjcf53RtnY5In1lnVZIn4=.19d58ee1-4cb5-4f9d-a59a-17f4ca0c929b@github.com> Message-ID: On Mon, 6 Jan 2025 06:10:27 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8339728 > - Copyright year and minor fix > - Review comment update > - Copyright year and test update > - MenuItem shortcut accessibility fix test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 49: > 47: 3. Navigate the Menu Items by using UP / DOWN arrow key > 48: 4. Press Pass if you are able to hear correct JAWS announcements > 49: for each menu item shortcut else Fail should we need not expand what is "correct" JAWS announcements? like mentioning it should read aloud "full" shortcut text and not only the 1st character of shortcut ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1903724256 From abhiscxk at openjdk.org Mon Jan 6 07:09:23 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 6 Jan 2025 07:09:23 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v6] In-Reply-To: References: Message-ID: > For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. > > Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. > > AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. > > Manual test case is added to verify the shortcut for JMenuItems. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Instruction and missed copyright year update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22822/files - new: https://git.openjdk.org/jdk/pull/22822/files/64ecaf0a..705fb4c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22822&range=04-05 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22822/head:pull/22822 PR: https://git.openjdk.org/jdk/pull/22822 From abhiscxk at openjdk.org Mon Jan 6 07:09:26 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 6 Jan 2025 07:09:26 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v5] In-Reply-To: <01gHhpucOg0qX1UUnEGCYerhDaIz2PdQE9eTaSxAYtU=.3f731c32-8f15-494b-b9bb-872ceeb219bc@github.com> References: <92Ewtiyn46SRvX1hVvyHgJQjcf53RtnY5In1lnVZIn4=.19d58ee1-4cb5-4f9d-a59a-17f4ca0c929b@github.com> <01gHhpucOg0qX1UUnEGCYerhDaIz2PdQE9eTaSxAYtU=.3f731c32-8f15-494b-b9bb-872ceeb219bc@github.com> Message-ID: On Mon, 6 Jan 2025 06:15:37 GMT, Prasanta Sadhukhan wrote: >> 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 five additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8339728 >> - Copyright year and minor fix >> - Review comment update >> - Copyright year and test update >> - MenuItem shortcut accessibility fix > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgePackages.h line 2: > >> 1: /* >> 2: * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved. > > this copyright also needs to be updated.. Updated. > test/jdk/javax/accessibility/TestJMenuItemShortcutAccessibility.java line 49: > >> 47: 3. Navigate the Menu Items by using UP / DOWN arrow key >> 48: 4. Press Pass if you are able to hear correct JAWS announcements >> 49: for each menu item shortcut else Fail > > should we need not expand what is "correct" JAWS announcements? like mentioning it should read aloud "full" shortcut text and not only the 1st character of shortcut Updated test instruction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1903752040 PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1903752306 From psadhukhan at openjdk.org Mon Jan 6 07:17:36 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 6 Jan 2025 07:17:36 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v6] In-Reply-To: References: Message-ID: <0Dozjm8VYK2mUT-FeFGozvDewUvMVi0qyWng3jYToCo=.75d2b6e9-25df-4e2c-84c7-9d145312aca4@github.com> On Mon, 6 Jan 2025 07:09:23 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Instruction and missed copyright year update Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22822#pullrequestreview-2531491152 From abhiscxk at openjdk.org Mon Jan 6 08:42:35 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 6 Jan 2025 08:42:35 GMT Subject: RFR: 8334644 : Automate javax/print/attribute/PageRangesException.java [v2] In-Reply-To: References: Message-ID: <7wl7FImJxMdvotf-L5tB8s_a6rhp2fdtz45GGbwIk7A=.eb50e480-6560-4d42-a3bb-009ad8de8690@github.com> On Mon, 6 Jan 2025 05:43:19 GMT, Renjith Kannath Pariyangad wrote: >> Hi All, >> >> I have updated the test and made it automation friendly. Please review and let me know your suggestions > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copy right year Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22909#pullrequestreview-2531627899 From aivanov at openjdk.org Mon Jan 6 11:51:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 6 Jan 2025 11:51:45 GMT Subject: RFR: 8334644 : Automate javax/print/attribute/PageRangesException.java [v2] In-Reply-To: References: Message-ID: <3Okjoqz2CaqqCLVmMbICRvqGy01xuZNovOIvZqrII4A=.ac929231-130d-45d9-9ad5-4db20edd052e@github.com> On Mon, 6 Jan 2025 05:43:19 GMT, Renjith Kannath Pariyangad wrote: >> Hi All, >> >> I have updated the test and made it automation friendly. Please review and let me know your suggestions > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copy right year Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22909#pullrequestreview-2531979659 From azvegint at openjdk.org Mon Jan 6 16:07:36 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 6 Jan 2025 16:07:36 GMT Subject: RFR: 8334644 : Automate javax/print/attribute/PageRangesException.java [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 05:43:19 GMT, Renjith Kannath Pariyangad wrote: >> Hi All, >> >> I have updated the test and made it automation friendly. Please review and let me know your suggestions > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copy right year Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22909#pullrequestreview-2532462778 From aivanov at openjdk.org Mon Jan 6 16:10:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 6 Jan 2025 16:10:37 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v6] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 07:09:23 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Instruction and missed copyright year update Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22822#pullrequestreview-2532470314 From azvegint at openjdk.org Mon Jan 6 16:57:46 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 6 Jan 2025 16:57:46 GMT Subject: RFR: 8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 20:01:28 GMT, Archie Cobbs wrote: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > This issue is a follow up to [JDK-8343476](https://bugs.openjdk.org/browse/JDK-8343476) to remove some additional warnings that were missed in that issue. Looks good, I also checked that it builds on all platforms. ------------- Marked as reviewed by azvegint (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22906#pullrequestreview-2532565680 From acobbs at openjdk.org Mon Jan 6 17:27:45 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 6 Jan 2025 17:27:45 GMT Subject: Integrated: 8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 20:01:28 GMT, Archie Cobbs wrote: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > This issue is a follow up to [JDK-8343476](https://bugs.openjdk.org/browse/JDK-8343476) to remove some additional warnings that were missed in that issue. This pull request has now been integrated. Changeset: 9c393a24 Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/9c393a243d6678b8435178a141b38b444b348580 Stats: 27 lines in 9 files changed: 0 ins; 18 del; 9 mod 8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/22906 From acobbs at openjdk.org Mon Jan 6 17:27:44 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 6 Jan 2025 17:27:44 GMT Subject: RFR: 8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 20:01:28 GMT, Archie Cobbs wrote: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > This issue is a follow up to [JDK-8343476](https://bugs.openjdk.org/browse/JDK-8343476) to remove some additional warnings that were missed in that issue. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22906#issuecomment-2573567092 From rmahajan at openjdk.org Mon Jan 6 17:43:07 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 6 Jan 2025 17:43:07 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected Message-ID: **Issue:** AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. **Solution:** I have added the exception handling code to take care that the handles are properly destroyed and not leaked. **Testing:** I have tested the code to make sure there are no regressions caused by this. ------------- Commit messages: - 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected Changes: https://git.openjdk.org/jdk/pull/22932/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282862 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22932/head:pull/22932 PR: https://git.openjdk.org/jdk/pull/22932 From aivanov at openjdk.org Mon Jan 6 17:56:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 6 Jan 2025 17:56:42 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v6] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 07:09:23 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Instruction and missed copyright year update I ran the test with Java 21 and with the fix, and I confirm JAWS announces the shortcuts correctly now. > ?it worked fine except for Enter key? Should we submit a bug? It's _a known problem_ now, but there's no fix for it. It could be a limitation that may be worth calling out in a release note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22822#issuecomment-2573618924 From rmahajan at openjdk.org Mon Jan 6 21:14:50 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Mon, 6 Jan 2025 21:14:50 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v2] In-Reply-To: References: Message-ID: > **Issue:** > AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. > > **Solution:** > I have added the exception handling code to take care that the handles are properly destroyed and not leaked. > > **Testing:** > I have tested the code to make sure there are no regressions caused by this. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: fix indentation and make sure we delete both handles. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22932/files - new: https://git.openjdk.org/jdk/pull/22932/files/726fbd9a..bdba3a94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=00-01 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22932/head:pull/22932 PR: https://git.openjdk.org/jdk/pull/22932 From duke at openjdk.org Mon Jan 6 23:31:40 2025 From: duke at openjdk.org (ScientificWare) Date: Mon, 6 Jan 2025 23:31:40 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v10] In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 09:56:15 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731) >> >> This is tracked in JBS as >> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731) >> >> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input) >> >> `alt` is not an attribute of the `input` element. >> >> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : >> >>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ... >> >> This feature is not implemented in `FormView.java`. >> >> ?? ~~This also affects the HTML 32 DTD~~ >> >> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138) >> >> Left before the patch and right after the patch. >> >> >> import java.awt.BorderLayout; >> import java.awt.Dimension; >> import javax.swing.JEditorPane; >> import javax.swing.JFrame; >> import javax.swing.JScrollPane; >> import javax.swing.SwingUtilities; >> import javax.swing.text.Document; >> import javax.swing.text.html.HTMLEditorKit; >> import javax.swing.text.html.StyleSheet; >> >> public class HTMLAddsSupportAltInputTag { >> public static void main(String[] args) { >> new HTMLAddsSupportAltInputTag(); >> } >> >> public HTMLAddsSupportAltInputTag() { >> SwingUtilities.invokeLater(new Runnable(){ >> public void run(){ >> JEditorPane jEditorPane = new JEditorPane(); >> jEditorPane.setEditable(false); >> JScrollPane scrollPane = new JScrollPane(jEditorPane); >> HTMLEditorKit kit = new HTMLEditorKit(); >> jEditorPane.setEditorKit(kit); >> StyleSheet styleSheet = kit.getStyleSheet(); >> styleSheet.addRule(""" >> body { >> color: #000; >> font-family:times; >> margin: 4px; >> } >> """); >> String htmlString = """ >> >> >> >>

>> - Merge master > - Replaces this title with "alt attribute test in HTML image type input". > > Moves this test to /jdk/test/jdk/javax/swing/text/html. > - bug8314731.java : Corrects the CopyRight date. > - FormView.java : > Removes a whitespace > > bug8314731.java : > Adds a newline at end of file. > - getMaximumSpan(int axis) method > doc -> Not used > > mouseReleased(MouseEvent evt) method > elem and hdoc -> not used > return -> could be removed, method returns void > > loadElementDataIntoBuffer(Element elem, StringBuilder buffer) method > value != null -> name can't be null at this point > > getInputElementData(AttributeSet attr) method > value = null -> Already set at null > - ... and 15 more: https://git.openjdk.org/jdk/compare/69e664de...9b423808 Awaiting review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-2574104168 From honkar at openjdk.org Tue Jan 7 00:44:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 7 Jan 2025 00:44:40 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 21:14:50 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > fix indentation and make sure we delete both handles. Please update the copyright year for .cpp file. Is there a way to test this fix or possibly add a test case? src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2138: > 2136: DestroyIcon(m_hIconSm); > 2137: } > 2138: throw; // Re-throw the exception Looks good here. I suppose you are cleaning up the resources in catch block since finally block isn't available in C++. ------------- PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2533191469 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1904775064 From psadhukhan at openjdk.org Tue Jan 7 03:20:58 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 7 Jan 2025 03:20:58 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI Message-ID: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. ------------- Commit messages: - 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI - 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI Changes: https://git.openjdk.org/jdk/pull/22937/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22937&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346828 Stats: 30 lines in 1 file changed: 1 ins; 20 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22937/head:pull/22937 PR: https://git.openjdk.org/jdk/pull/22937 From abhiscxk at openjdk.org Tue Jan 7 08:08:35 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 7 Jan 2025 08:08:35 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI In-Reply-To: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Tue, 7 Jan 2025 03:16:57 GMT, Prasanta Sadhukhan wrote: > Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 34: > 32: import java.awt.event.MouseAdapter; > 33: import java.awt.event.MouseEvent; > 34: import javax.swing.JFrame; No longer required. Please remove the import and frame variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22937#discussion_r1905049121 From abhiscxk at openjdk.org Tue Jan 7 08:37:36 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 7 Jan 2025 08:37:36 GMT Subject: RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v6] In-Reply-To: References: Message-ID: <18PSIfa6fEftqsSBxxDnes7ateZxQlHsiUqCNawaKyQ=.22b8e69e-a4f2-4c12-b306-4184d055b51b@github.com> On Mon, 6 Jan 2025 07:09:23 GMT, Abhishek Kumar wrote: >> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. >> >> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. >> >> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. >> >> Manual test case is added to verify the shortcut for JMenuItems. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Instruction and missed copyright year update > > ?it worked fine except for Enter key? > > Should we submit a bug? It's _a known problem_ now, but there's no fix for it. It could be a limitation that may be worth calling out in a release note. Yeah, as of now I don't have a fix for "Enter" key shortcut or it may be a limitation. I am not sure if filing a bug is a good idea as it may just increase the backlog with no potential solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22822#issuecomment-2574683102 From psadhukhan at openjdk.org Tue Jan 7 08:48:24 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 7 Jan 2025 08:48:24 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v2] In-Reply-To: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: > Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Remove import/var ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22937/files - new: https://git.openjdk.org/jdk/pull/22937/files/d4025132..6804cfd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22937&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22937&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22937/head:pull/22937 PR: https://git.openjdk.org/jdk/pull/22937 From abhiscxk at openjdk.org Tue Jan 7 08:51:43 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 7 Jan 2025 08:51:43 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v2] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Tue, 7 Jan 2025 08:48:24 GMT, Prasanta Sadhukhan wrote: >> Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove import/var Looks good to me. Tested for all platform in CI machines and no failure observed. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22937#pullrequestreview-2533712711 From jwaters at openjdk.org Tue Jan 7 09:16:12 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 7 Jan 2025 09:16:12 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v4] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Formatting changes in AccessBridgeEventHandler.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21656/files - new: https://git.openjdk.org/jdk/pull/21656/files/324f89f1..b91d2f3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21656&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21656&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21656/head:pull/21656 PR: https://git.openjdk.org/jdk/pull/21656 From jwaters at openjdk.org Tue Jan 7 09:56:11 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 7 Jan 2025 09:56:11 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'openjdk:master' into accessibility - Cast to void in AccessBridgeCalls.c - static_cast to void in jaccessinspector.cpp - Formatting changes in AccessBridgeEventHandler.cpp - Merge branch 'master' into accessibility - Remove now unused result - Merge branch 'master' into accessibility - 8342870 ------------- Changes: https://git.openjdk.org/jdk/pull/21656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21656&range=04 Stats: 28 lines in 9 files changed: 4 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/21656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21656/head:pull/21656 PR: https://git.openjdk.org/jdk/pull/21656 From jwaters at openjdk.org Tue Jan 7 10:00:39 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 7 Jan 2025 10:00:39 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v2] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 17:58:59 GMT, Phil Race wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > There's not much I like about this PR. I think it would be better to withdraw it and submit a bug against A11Y for people to look at what should really be done about these cases. Which could include "do nothing". @prrace I've tried to fix up the code changes here to look as neat as possible, but ultimately I'm not sure what you want it to look like. Could you explain why you don't like the changes in accessibility? Unlike the corresponding awt changes which are more complex and even touch the C++ Standard, the Pull Request here consists purely of marking unused code for removal, which shouldn't be too bad at least in my opinion, which is why I'm not sure why you don't like it ------------- PR Comment: https://git.openjdk.org/jdk/pull/21656#issuecomment-2574861271 From duke at openjdk.org Tue Jan 7 15:09:43 2025 From: duke at openjdk.org (duke) Date: Tue, 7 Jan 2025 15:09:43 GMT Subject: RFR: 8334644 : Automate javax/print/attribute/PageRangesException.java [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 05:43:19 GMT, Renjith Kannath Pariyangad wrote: >> Hi All, >> >> I have updated the test and made it automation friendly. Please review and let me know your suggestions > > Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision: > > Updated copy right year @Renjithkannath Your change (at version 9ef119e16485a47eff324e1062015f11dd27b4f5) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22909#issuecomment-2575530177 From rkannathpari at openjdk.org Tue Jan 7 16:56:42 2025 From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad) Date: Tue, 7 Jan 2025 16:56:42 GMT Subject: Integrated: 8334644 : Automate javax/print/attribute/PageRangesException.java In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 04:47:41 GMT, Renjith Kannath Pariyangad wrote: > Hi All, > > I have updated the test and made it automation friendly. Please review and let me know your suggestions This pull request has now been integrated. Changeset: 030149fe Author: Renjith Kannath Pariyangad Committer: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/030149fec4f175e5571e053fa56d2921d95c6b13 Stats: 55 lines in 1 file changed: 55 ins; 0 del; 0 mod 8334644: Automate javax/print/attribute/PageRangesException.java Reviewed-by: aivanov, abhiscxk, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/22909 From rmahajan at openjdk.org Tue Jan 7 19:37:24 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Tue, 7 Jan 2025 19:37:24 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v3] In-Reply-To: References: Message-ID: > **Issue:** > AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. > > **Solution:** > I have added the exception handling code to take care that the handles are properly destroyed and not leaked. > > **Testing:** > I have tested the code to make sure there are no regressions caused by this. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22932/files - new: https://git.openjdk.org/jdk/pull/22932/files/bdba3a94..79a82de0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22932/head:pull/22932 PR: https://git.openjdk.org/jdk/pull/22932 From honkar at openjdk.org Tue Jan 7 20:33:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 7 Jan 2025 20:33:50 GMT Subject: RFR: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null [v2] In-Reply-To: References: <5aMCVNPYKVGefspy36ZLeilgpOjgqvNgJubW1SHaavA=.467f452f-560d-4669-84f0-ed4ec26ca1b6@github.com> Message-ID: On Tue, 24 Dec 2024 12:56:14 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1205: >> >>> 1203: Image icon = null; >>> 1204: long hIcon = getSystemIcon(iconType.getIconID()); >>> 1205: if (hIcon != 0) { >> >> I suggest inverting the condition: >> >> >> if (hIcon == 0) { >> return null; >> } >> >> Image icon = makeIcon(hIcon); >> >> >> The code has less indentation and has better readability, in my opinion. > > Ah, I see the current style that you use follows the code style in `getShell32Icon`. > > Either go with the current style, or change the condition in `getShell32Icon` so that both methods use the same code flow. @aivanov-jdk Inverted hIcon condition and updated both the methods to match. Please re-review when you get a chance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22776#discussion_r1906004459 From honkar at openjdk.org Tue Jan 7 20:33:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 7 Jan 2025 20:33:50 GMT Subject: RFR: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null [v3] In-Reply-To: References: Message-ID: > Win32ShellFolder2.getSystemIcon() can result in NPE if icon is null. Sanity null checks have been added. > > > long hIcon = getSystemIcon(iconType.getIconID()); //Can return null > Image icon = makeIcon(hIcon); // returns null if the condition (hIcon != 0L && hIcon != -1L) is false > if (LARGE_ICON_SIZE != icon.getWidth(null)) { // NullPointerException -- icon is null > > > Occurs when Windows is unable to provide a system icon and the code assumes an icon will **always** be returned, but the Windows API makes no such guarantee. > > getSystemIcon calls LoadIcon (User32.dll). This can return null. > https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: inverted hIcon condition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22776/files - new: https://git.openjdk.org/jdk/pull/22776/files/2307a4a1..314d2ddf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22776&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22776&range=01-02 Stats: 26 lines in 1 file changed: 10 ins; 10 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22776/head:pull/22776 PR: https://git.openjdk.org/jdk/pull/22776 From dgredler at openjdk.org Tue Jan 7 20:47:39 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 7 Jan 2025 20:47:39 GMT Subject: RFR: 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows [v7] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 19:07:28 GMT, Daniel Gredler wrote: >> This PR fixes the issue identified in JDK-8148334 in screenshots `Page8_landscape.JPG` and `Page8_portrait.JPG`. >> >> It does not address `mac_Page1.png` or `mac_Page8.png`, which I'm not even sure are still issues (I have no access to a Mac). >> >> The method in question, `PathGraphics.printedSimpleGlyphVector(...)` is quite complex, with many special cases being handled in different ways. In this specific scenario (page 8 of `PrintTextTest`), all special case checks fail, and we fall through all the way to the final handling block, which draws the individual characters one by one. It looks like the problem is that the font transform translation is applied twice, once via the glyph positions, and again by `drawString(...)` via the font. The proposed fix is to provide `drawString(...)` a font without any translation transform. >> >> Testing looks good on Linux, but needs to be done on Mac and Windows. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Add additional issue ID to PrintTextTest bug list Bot, please keep open. @prrace Friendly reminder that this one probably needs your review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21980#issuecomment-2576187884 From aivanov at openjdk.org Tue Jan 7 21:26:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 7 Jan 2025 21:26:36 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 19:37:24 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Changes requested by aivanov (Reviewer). src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2127: > 2125: try { > 2126: m_hIcon = CreateIconFromRaster(env, iconRaster, w, h); > 2127: JNU_CHECK_EXCEPTION(env); // Might throw here The comment is misleading, `JNU_CHECK_EXCEPTION` does not throw an exception. https://github.com/openjdk/jdk/blob/27646e551686ec02740600fc73694fc2fbd00a88/src/java.base/share/native/libjava/jni_util.h#L278-L283 It checks if an exception is raised in Java code and returns immediately if there's a pending Java exception. If a Java exception is raised at this line, after `m_hIcon` is assigned and its value is not `NULL`, it has to be deleted. Perhaps, you have to handle it explicitly here: if (env->ExceptionCheck()) { if (m_hIcon) { DestroyIcon(m_hIcon); } return; } It looks that the original values stored in `hOldIcon` and `hOldIconSm` should be restored if an error occurs. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2129: > 2127: JNU_CHECK_EXCEPTION(env); // Might throw here > 2128: m_hIconSm = CreateIconFromRaster(env, smallIconRaster, smw, smh); > 2129: JNU_CHECK_EXCEPTION(env); // Or here The clean-up code here should delete both `m_hIcon` and `m_hIconSm`. And restore the previous values? src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2130: > 2128: m_hIconSm = CreateIconFromRaster(env, smallIconRaster, smw, smh); > 2129: JNU_CHECK_EXCEPTION(env); // Or here > 2130: } catch (...) { At first I thought using C++ exception handling was a bad idea, but it's actually needed. The code in `CreateIconFromRaster` can throw a C++ exception, specifically `BitmapUtil::CreateTransparencyMaskFromARGB` and `BitmapUtil::CreateV4BitmapFromARGB`. https://github.com/openjdk/jdk/blob/e413fc643c4a58e3c46d81025c3ac9fbf89db4b9/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2075-L2087 Since the exception is re-thrown in the handler there, it has to be caught in `AwtWindow::SetIconData`. Yet you shouldn't re-throw the C++ exception here, it must not escape JNI code, otherwise, the unhandled exception will likely crash the Java process. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2138: > 2136: DestroyIcon(m_hIconSm); > 2137: } > 2138: throw; // Re-throw the exception The C++ exception shouldn't be *re-thrown* here. Whether we should raise a Java exception to indicate an error is to be discussed. If we restore the state of the `AwtWindow` object as if no failure occurred, it can continue. And I don't see any meaningful way to return an error back to Java here. `CreateIconFromRaster` throws `NullPointerException` if it fails to get the image raster. https://github.com/openjdk/jdk/blob/e413fc643c4a58e3c46d81025c3ac9fbf89db4b9/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2076-L2078 where `JNI_CHECK_NULL_GOTO` is https://github.com/openjdk/jdk/blob/27646e551686ec02740600fc73694fc2fbd00a88/src/java.desktop/windows/native/libawt/windows/awt.h#L48-L54 ------------- PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2535323825 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1906029348 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1906031377 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1906013829 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1906050261 From aivanov at openjdk.org Tue Jan 7 22:02:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 7 Jan 2025 22:02:40 GMT Subject: RFR: 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:02:52 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.parser.Entity#entityTypes` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. > Similar to what we did in #21825. Looks good to me. All the client tests are green. src/java.desktop/share/classes/javax/swing/text/html/parser/Entity.java line 2: > 1: /* > 2: * Copyright (c) 1998, 2024, Oracle and/or its affiliates. All rights reserved. Needs to be updated to 2025? ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21831#pullrequestreview-2535453539 PR Review Comment: https://git.openjdk.org/jdk/pull/21831#discussion_r1906090574 From aivanov at openjdk.org Tue Jan 7 22:19:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 7 Jan 2025 22:19:39 GMT Subject: RFR: 8346953: Remove unnecessary @SuppressWarnings annotations (client, #2) In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 16:55:17 GMT, Alexander Zvegintsev wrote: > Looks good, I also checked that it builds on all platforms. I also did it. And I found the changeset had been integrated when I got back to it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22906#issuecomment-2576334613 From achung at openjdk.org Tue Jan 7 23:36:36 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 7 Jan 2025 23:36:36 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v2] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Tue, 7 Jan 2025 08:48:24 GMT, Prasanta Sadhukhan wrote: >> Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove import/var this test is failing for me locally on macOS with the same error `Execution failed: 'main' threw exception: java.lang.RuntimeException: The scrollbar block increment is incorrect ` ------------- PR Review: https://git.openjdk.org/jdk/pull/22937#pullrequestreview-2535565999 From psadhukhan at openjdk.org Wed Jan 8 04:29:40 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 8 Jan 2025 04:29:40 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v2] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Tue, 7 Jan 2025 23:33:40 GMT, Alisen Chung wrote: > this test is failing for me locally on macOS with the same error `Execution failed: 'main' threw exception: java.lang.RuntimeException: The scrollbar block increment is incorrect ` Strange that the mousePress is not happening on headful macos if frame is not shown and scrollbar remains in initial value of -1...maybe its osx limitation..it works well for headless macos CI systems I see and even in local headful windows/linux.. Even bug4842792.java which is headless does not honor mousePress but it pass as the check condition is not the initial value.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22937#issuecomment-2576723538 From jwaters at openjdk.org Wed Jan 8 04:49:40 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 8 Jan 2025 04:49:40 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'openjdk:master' into accessibility > - Cast to void in AccessBridgeCalls.c > - static_cast to void in jaccessinspector.cpp > - Formatting changes in AccessBridgeEventHandler.cpp > - Merge branch 'master' into accessibility > - Remove now unused result > - Merge branch 'master' into accessibility > - 8342870 Sorry for this, but I really have no one else to turn to for help. Paging @azuev-java ------------- PR Comment: https://git.openjdk.org/jdk/pull/21656#issuecomment-2576744879 From psadhukhan at openjdk.org Wed Jan 8 05:32:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 8 Jan 2025 05:32:03 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v3] In-Reply-To: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: > Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: mac limitation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22937/files - new: https://git.openjdk.org/jdk/pull/22937/files/6804cfd5..40dd4da2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22937&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22937&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22937/head:pull/22937 PR: https://git.openjdk.org/jdk/pull/22937 From psadhukhan at openjdk.org Wed Jan 8 05:51:22 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 8 Jan 2025 05:51:22 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v4] In-Reply-To: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: > Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: mac limitation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22937/files - new: https://git.openjdk.org/jdk/pull/22937/files/40dd4da2..895ce7fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22937&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22937&range=02-03 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22937/head:pull/22937 PR: https://git.openjdk.org/jdk/pull/22937 From achung at openjdk.org Wed Jan 8 09:39:42 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 8 Jan 2025 09:39:42 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v4] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Wed, 8 Jan 2025 05:51:22 GMT, Prasanta Sadhukhan wrote: >> Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > mac limitation test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 50: > 48: String osName = System.getProperty("os.name"); > 49: if (osName.toLowerCase().contains("os x")) { > 50: System.out.println("This test is not for MacOS, considered passed."); should probably be a jtreg.SkippedException here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22937#discussion_r1906888279 From abhiscxk at openjdk.org Wed Jan 8 10:17:41 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 8 Jan 2025 10:17:41 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v4] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Wed, 8 Jan 2025 05:51:22 GMT, Prasanta Sadhukhan wrote: >> Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > mac limitation test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 50: > 48: String osName = System.getProperty("os.name"); > 49: if (osName.toLowerCase().contains("os x")) { > 50: System.out.println("This test is not for MacOS, considered passed."); Test is restricted to run on non-mac systems. Is it required to check OS explicitly here ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22937#discussion_r1906944495 From psadhukhan at openjdk.org Wed Jan 8 10:21:37 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 8 Jan 2025 10:21:37 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v4] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: <1A1ccH7-OYQXk-8gXIB0NDEeshO4qo3OLqTEn5IX238=.7d25ccd3-160e-4002-bc33-14eea8550979@github.com> On Wed, 8 Jan 2025 10:15:08 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> mac limitation > > test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 50: > >> 48: String osName = System.getProperty("os.name"); >> 49: if (osName.toLowerCase().contains("os x")) { >> 50: System.out.println("This test is not for MacOS, considered passed."); > > Test is restricted to run on non-mac systems. > Is it required to check OS explicitly here ? For standalone run.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22937#discussion_r1906950208 From psadhukhan at openjdk.org Wed Jan 8 10:21:36 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 8 Jan 2025 10:21:36 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v4] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Wed, 8 Jan 2025 09:36:58 GMT, Alisen Chung wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> mac limitation > > test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 50: > >> 48: String osName = System.getProperty("os.name"); >> 49: if (osName.toLowerCase().contains("os x")) { >> 50: System.out.println("This test is not for MacOS, considered passed."); > > should probably be a jtreg.SkippedException here Not mandatory.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22937#discussion_r1906949924 From abhiscxk at openjdk.org Wed Jan 8 10:25:47 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 8 Jan 2025 10:25:47 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v4] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Wed, 8 Jan 2025 05:51:22 GMT, Prasanta Sadhukhan wrote: >> Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > mac limitation Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22937#pullrequestreview-2536757241 From aivanov at openjdk.org Wed Jan 8 12:34:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 8 Jan 2025 12:34:50 GMT Subject: RFR: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null [v3] In-Reply-To: References: Message-ID: <_5QNLGFmj1iEpAmOUBPELgAc1HlgkqEi-zaH8bnaGO8=.5097a43d-935e-4580-b530-fb1911d4fe75@github.com> On Tue, 7 Jan 2025 20:33:50 GMT, Harshitha Onkar wrote: >> Win32ShellFolder2.getSystemIcon() can result in NPE if icon is null. Sanity null checks have been added. >> >> >> long hIcon = getSystemIcon(iconType.getIconID()); //Can return null >> Image icon = makeIcon(hIcon); // returns null if the condition (hIcon != 0L && hIcon != -1L) is false >> if (LARGE_ICON_SIZE != icon.getWidth(null)) { // NullPointerException -- icon is null >> >> >> Occurs when Windows is unable to provide a system icon and the code assumes an icon will **always** be returned, but the Windows API makes no such guarantee. >> >> getSystemIcon calls LoadIcon (User32.dll). This can return null. >> https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > inverted hIcon condition Looks good to me except for minor comments. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1207: > 1205: return null; > 1206: } > 1207: Image icon = makeIcon(hIcon); Suggestion: } Image icon = makeIcon(hIcon); I'd add a blank line here to visually separate the two blocks: deal with `null`, then handle the ?happy? case. src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1222: > 1220: if (hIcon == 0) { > 1221: return null; > 1222: } Suggestion: if (hIcon == 0) { return null; } And I'd add a blank line here, too. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22776#pullrequestreview-2537024999 PR Review Comment: https://git.openjdk.org/jdk/pull/22776#discussion_r1907112424 PR Review Comment: https://git.openjdk.org/jdk/pull/22776#discussion_r1907113744 From dmarkov at openjdk.org Wed Jan 8 16:40:45 2025 From: dmarkov at openjdk.org (Dmitry Markov) Date: Wed, 8 Jan 2025 16:40:45 GMT Subject: RFR: 8346887: DrawFocusRect() may cause an assertion failure Message-ID: On Windows debug build execution of `DrawFocusRect()` may cause an assertion failure. In particular if a component, which is going to gain a focus, has zero size, the function returns `0` because focus rectangle is empty. It is necessary to check that the focus rectangle is not empty before `DrawFocusRect()` call. ------------- Commit messages: - 8346887: DrawFocusRect() may cause an assertion failure Changes: https://git.openjdk.org/jdk/pull/22973/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22973&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346887 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/22973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22973/head:pull/22973 PR: https://git.openjdk.org/jdk/pull/22973 From aivanov at openjdk.org Wed Jan 8 18:54:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 8 Jan 2025 18:54:44 GMT Subject: RFR: 8346887: DrawFocusRect() may cause an assertion failure In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 16:36:07 GMT, Dmitry Markov wrote: > On Windows debug build execution of `DrawFocusRect()` may cause an assertion failure. In particular if a component, which is going to gain a focus, has zero size, the function returns `0` because focus rectangle is empty. > > It is necessary to check that the focus rectangle is not empty before `DrawFocusRect()` call. Looks good. src/java.desktop/windows/native/libawt/windows/awt_Checkbox.cpp line 292: > 290: if ((drawInfo.itemState & ODS_FOCUS) && > 291: ((drawInfo.itemAction & ODA_FOCUS)|| > 292: (drawInfo.itemAction &ODA_DRAWENTIRE))) { These two lines ask for spacing adjustment, but it would hide the real fix. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22973#pullrequestreview-2537941602 PR Review Comment: https://git.openjdk.org/jdk/pull/22973#discussion_r1907650682 From honkar at openjdk.org Wed Jan 8 19:14:56 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 8 Jan 2025 19:14:56 GMT Subject: RFR: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null [v4] In-Reply-To: References: Message-ID: > Win32ShellFolder2.getSystemIcon() can result in NPE if icon is null. Sanity null checks have been added. > > > long hIcon = getSystemIcon(iconType.getIconID()); //Can return null > Image icon = makeIcon(hIcon); // returns null if the condition (hIcon != 0L && hIcon != -1L) is false > if (LARGE_ICON_SIZE != icon.getWidth(null)) { // NullPointerException -- icon is null > > > Occurs when Windows is unable to provide a system icon and the code assumes an icon will **always** be returned, but the Windows API makes no such guarantee. > > getSystemIcon calls LoadIcon (User32.dll). This can return null. > https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22776/files - new: https://git.openjdk.org/jdk/pull/22776/files/314d2ddf..701864d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22776&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22776&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22776.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22776/head:pull/22776 PR: https://git.openjdk.org/jdk/pull/22776 From aivanov at openjdk.org Wed Jan 8 19:14:57 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 8 Jan 2025 19:14:57 GMT Subject: RFR: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null [v4] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:10:59 GMT, Harshitha Onkar wrote: >> Win32ShellFolder2.getSystemIcon() can result in NPE if icon is null. Sanity null checks have been added. >> >> >> long hIcon = getSystemIcon(iconType.getIconID()); //Can return null >> Image icon = makeIcon(hIcon); // returns null if the condition (hIcon != 0L && hIcon != -1L) is false >> if (LARGE_ICON_SIZE != icon.getWidth(null)) { // NullPointerException -- icon is null >> >> >> Occurs when Windows is unable to provide a system icon and the code assumes an icon will **always** be returned, but the Windows API makes no such guarantee. >> >> getSystemIcon calls LoadIcon (User32.dll). This can return null. >> https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > minor Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22776#pullrequestreview-2537985544 From honkar at openjdk.org Wed Jan 8 19:15:02 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 8 Jan 2025 19:15:02 GMT Subject: RFR: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null [v3] In-Reply-To: <_5QNLGFmj1iEpAmOUBPELgAc1HlgkqEi-zaH8bnaGO8=.5097a43d-935e-4580-b530-fb1911d4fe75@github.com> References: <_5QNLGFmj1iEpAmOUBPELgAc1HlgkqEi-zaH8bnaGO8=.5097a43d-935e-4580-b530-fb1911d4fe75@github.com> Message-ID: On Wed, 8 Jan 2025 12:31:47 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> inverted hIcon condition > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1222: > >> 1220: if (hIcon == 0) { >> 1221: return null; >> 1222: } > > Suggestion: > > if (hIcon == 0) { > return null; > } > > > And I'd add a blank line here, too. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22776#discussion_r1907674346 From prr at openjdk.org Wed Jan 8 19:18:44 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 8 Jan 2025 19:18:44 GMT Subject: RFR: 8346887: DrawFocusRect() may cause an assertion failure In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 16:36:07 GMT, Dmitry Markov wrote: > On Windows debug build execution of `DrawFocusRect()` may cause an assertion failure. In particular if a component, which is going to gain a focus, has zero size, the function returns `0` because focus rectangle is empty. > > It is necessary to check that the focus rectangle is not empty before `DrawFocusRect()` call. I'm a bit surprised that there's no Microsoft doc on the assert .. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22973#pullrequestreview-2537998180 From azvegint at openjdk.org Wed Jan 8 19:26:46 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 8 Jan 2025 19:26:46 GMT Subject: RFR: 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:02:52 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.parser.Entity#entityTypes` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. > Similar to what we did in #21825. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21831#pullrequestreview-2538018534 From aivanov at openjdk.org Wed Jan 8 19:45:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 8 Jan 2025 19:45:46 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux Message-ID: **Problem:** The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. The focus is on _Button 2_ instead of _Button 4_. **Root cause:** The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. **Fix:** Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. Log focus movements and dispatched key events to facilitate failure analysis. Take a screenshot of the test frame in case of failure. These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. ------------- Commit messages: - Log only focusOwner properties to reduce the noise in the test log - Increase focus timeout and remove delay between generating events - Detect spurious KEY_PRESS event and report an error - Rework JRadioButton/ButtonGroupFocusTest.java Changes: https://git.openjdk.org/jdk/pull/22977/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22977&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346581 Stats: 135 lines in 1 file changed: 96 ins; 13 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/22977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22977/head:pull/22977 PR: https://git.openjdk.org/jdk/pull/22977 From hannesw at openjdk.org Wed Jan 8 20:02:36 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 8 Jan 2025 20:02:36 GMT Subject: RFR: 8347122: Add missing @serial tags to module java.desktop Message-ID: Please review a doc-only change to add missing `@serial` javadoc tags in module `java.desktop`. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. This change has no effect on the generated documentation (apart from muting the warnings for missing `@serial` tags when building documentation with `-serialwarn` enabled). ------------- Commit messages: - 8347122: Add missing @serial tags to module java.desktop Changes: https://git.openjdk.org/jdk/pull/22979/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22979&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347122 Stats: 173 lines in 47 files changed: 39 ins; 0 del; 134 mod Patch: https://git.openjdk.org/jdk/pull/22979.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22979/head:pull/22979 PR: https://git.openjdk.org/jdk/pull/22979 From hannesw at openjdk.org Wed Jan 8 20:30:11 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 8 Jan 2025 20:30:11 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules Message-ID: Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. ------------- Commit messages: - 8347123: Add missing @serial tags to other modules Changes: https://git.openjdk.org/jdk/pull/22980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347123 Stats: 107 lines in 39 files changed: 45 ins; 0 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/22980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22980/head:pull/22980 PR: https://git.openjdk.org/jdk/pull/22980 From serb at openjdk.org Wed Jan 8 20:43:37 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 8 Jan 2025 20:43:37 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v4] In-Reply-To: <8h31s_D-xhSxDOclmXt8EIEI9GF9J8eZsPal7w6d8U4=.d07f9365-3de1-4198-8721-4f6a63b39b84@github.com> References: <_ZcECw-XMUkUP4jHKV2fBALSAKABYCcQBkN-j_t-344=.11480a9d-34d5-4c3e-9500-c443dc116f8f@github.com> <8h31s_D-xhSxDOclmXt8EIEI9GF9J8eZsPal7w6d8U4=.d07f9365-3de1-4198-8721-4f6a63b39b84@github.com> Message-ID: On Fri, 20 Dec 2024 13:56:08 GMT, Alexey Ivanov wrote: >> Robot is already created with a screen .. ie GraphicsDevice .. the bounds are from that .. and it is already used elsewhere in Robot >> If that can be across physical screens it will still work. >> If screens are separate then Robot is constrained to that anyway. >> >> Can you show a specific case where this is a problem ? > > I agree with Alex. Currently, it's possible to use a Robot instance to move mouse across all the screens in a multi-monitor environment. > > According to the specification of [`Robot(GraphicsDevice screen)`](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/java/awt/Robot.html#%3Cinit%3E(java.awt.GraphicsDevice)), Coordinates passed to `Robot` method calls like `mouseMove`, `getPixelColor` and `createScreenCapture` will be interpreted as being in the same coordinate system as the specified screen. > > I understand this statement correctly, it means that if I create a Robot instance with a screen that's not the main one, `Robot.mouse(0, 0)` should move the mouse to `(screenBounds.x, screenBounds.y)`. > > However, if ?share the same coordinate system to form a combined virtual screen?, `Robot` is expected to move mouse within the bounds of the virtual screen, isn't it? Notes: * The main screen does not necessarily starts from {0, 0} * The robot.screen property only matter if the system is configured to use separate monitors (separate coordinate systems) - for example, when xinerama is disabled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1907840970 From honkar at openjdk.org Wed Jan 8 22:23:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 8 Jan 2025 22:23:40 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v3] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 19:22:35 GMT, Alisen Chung wrote: >> @aivanov-jdk >> I see your point. But I'm running into NPE at `MouseInfo.getPointerInfo().getLocation()` without the fix as well (dual monitor, extended display setup) >> >> Is it expected of MouseInfo.getPointerInfo() to return null for off-screen coordinates (meaning does it consider it as mouse not available if it is outside the screen devices)? >> >> PointerInfo has two things associated with it - screen device and a location, so if it is not able to associate the coordinate with any of the screen device (off-screen coordinate) is it suppose to return null in this case? > > Interesting. Does this also happen after the fix with Robot clamping coordinates in shared code? @alisenchung > By looking at the numbers, I infer Harshitha has a scale on her screens. Scaling down what's received from Windows could trim a pixel on the right, and it could be the reason why the point isn't within the bounds of any screen in her case. I think @aivanov-jdk intuition was right. I checked with different uiScales. With this configuration: Left side: Secondary & Right side: Primary screen The test passes on uiScale: 1, 1.25, 1.75, 2 .. and so on... It fails on uiScale: 1.5, 2.5 and every other 0.5 scale increment. Surely looks like a pixel rounding error .. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1907929765 From honkar at openjdk.org Thu Jan 9 00:07:47 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 9 Jan 2025 00:07:47 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:40:29 GMT, Alexey Ivanov wrote: > **Problem:** > > The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. > > The focus is on _Button 2_ instead of _Button 4_. > > **Root cause:** > > The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. > > **Fix:** > > Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. > > Log focus movements and dispatched key events to facilitate failure analysis. > > Take a screenshot of the test frame in case of failure. > > These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. CountDownLatch and additional logging LGTM. Latches might help stabilize the test on slower nodes. test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 70: > 68: private static final CountDownLatch button4FocusLatch = new CountDownLatch(1); > 69: > 70: private static final CountDownLatch button2FocusLatch2 = new CountDownLatch(2); Minor: Should the no. of button2FocusLatch2 latches be 1? since we already have another button2FocusLatch Suggestion: private static final CountDownLatch button2FocusLatch2 = new CountDownLatch(1); ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22977#pullrequestreview-2538495203 PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1907994326 From abhiscxk at openjdk.org Thu Jan 9 04:14:46 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 9 Jan 2025 04:14:46 GMT Subject: Integrated: 8339728 : [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 05:17:07 GMT, Abhishek Kumar wrote: > For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. > > Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed. > > AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT. > > Manual test case is added to verify the shortcut for JMenuItems. This pull request has now been integrated. Changeset: a46ae703 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/a46ae7031e30eb4940e43012a42f1b7fa5d942ef Stats: 127 lines in 3 files changed: 116 ins; 5 del; 6 mod 8339728: [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class Reviewed-by: aivanov, psadhukhan, kizune ------------- PR: https://git.openjdk.org/jdk/pull/22822 From aturbanov at openjdk.org Thu Jan 9 12:50:51 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 9 Jan 2025 12:50:51 GMT Subject: RFR: 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:02:52 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.parser.Entity#entityTypes` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. > Similar to what we did in #21825. Thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21831#issuecomment-2580070512 From duke at openjdk.org Thu Jan 9 12:50:52 2025 From: duke at openjdk.org (ExE Boss) Date: Thu, 9 Jan 2025 12:50:52 GMT Subject: RFR: 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity In-Reply-To: References: Message-ID: <9jHqHX1w1kI9ehb8Tokw_0-q3hHF1Z_C9ykhDtxhLPo=.cdec31fa-9c55-41ea-8306-9907ba79f98b@github.com> On Tue, 7 Jan 2025 21:59:37 GMT, Alexey Ivanov wrote: >> The Hashtable `javax.swing.text.html.parser.Entity#entityTypes` is modified only within `` block. >> We can replace it with immutable map to avoid Hashtable synchronization overhead. >> Similar to what we did in #21825. > > src/java.desktop/share/classes/javax/swing/text/html/parser/Entity.java line 2: > >> 1: /* >> 2: * Copyright (c) 1998, 2024, Oracle and/or its affiliates. All rights reserved. > > Needs to be updated to 2025? Leaving?this as?is is?probably?fine given?that this?PR hasn?t?changed since?then, just?like https://github.com/openjdk/jdk/pull/22854#pullrequestreview-2528134788 (commit?https://github.com/openjdk/jdk/commit/9a60f4457bb56d0f5039a97e6b943e62a8a2c3ee) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21831#discussion_r1908730629 From aturbanov at openjdk.org Thu Jan 9 12:50:53 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 9 Jan 2025 12:50:53 GMT Subject: Integrated: 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity In-Reply-To: References: Message-ID: <5orsp0XmI8Jz4FU4stSdNUhfYvQTGXXpvMBOZ0HccdY=.ff2d15a3-ab57-433f-b19f-290cef53ad88@github.com> On Fri, 1 Nov 2024 14:02:52 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.parser.Entity#entityTypes` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. > Similar to what we did in #21825. This pull request has now been integrated. Changeset: 9c72dedd Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/9c72dedd072e838d363d0eec364514584fd4e2e6 Stats: 26 lines in 1 file changed: 0 ins; 11 del; 15 mod 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity Reviewed-by: aivanov, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/21831 From aivanov at openjdk.org Thu Jan 9 13:08:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 9 Jan 2025 13:08:50 GMT Subject: RFR: 8346036: Unnecessary Hashtable usage in javax.swing.text.html.parser.Entity In-Reply-To: <9jHqHX1w1kI9ehb8Tokw_0-q3hHF1Z_C9ykhDtxhLPo=.cdec31fa-9c55-41ea-8306-9907ba79f98b@github.com> References: <9jHqHX1w1kI9ehb8Tokw_0-q3hHF1Z_C9ykhDtxhLPo=.cdec31fa-9c55-41ea-8306-9907ba79f98b@github.com> Message-ID: On Thu, 9 Jan 2025 12:44:14 GMT, ExE Boss wrote: >> src/java.desktop/share/classes/javax/swing/text/html/parser/Entity.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 1998, 2024, Oracle and/or its affiliates. All rights reserved. >> >> Needs to be updated to 2025? > > Leaving?this as?is is?probably?fine given?that this?PR hasn?t?changed since?then, just?like https://github.com/openjdk/jdk/pull/22854#pullrequestreview-2528134788 (commit?https://github.com/openjdk/jdk/commit/9a60f4457bb56d0f5039a97e6b943e62a8a2c3ee) The PR will be or is integrated in 2025, so the entire changeset is dated 2025 ? thus, 2025 copyright year applies to all the files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21831#discussion_r1908764920 From kizune at openjdk.org Thu Jan 9 18:21:38 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 9 Jan 2025 18:21:38 GMT Subject: RFR: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null [v4] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:14:56 GMT, Harshitha Onkar wrote: >> Win32ShellFolder2.getSystemIcon() can result in NPE if icon is null. Sanity null checks have been added. >> >> >> long hIcon = getSystemIcon(iconType.getIconID()); //Can return null >> Image icon = makeIcon(hIcon); // returns null if the condition (hIcon != 0L && hIcon != -1L) is false >> if (LARGE_ICON_SIZE != icon.getWidth(null)) { // NullPointerException -- icon is null >> >> >> Occurs when Windows is unable to provide a system icon and the code assumes an icon will **always** be returned, but the Windows API makes no such guarantee. >> >> getSystemIcon calls LoadIcon (User32.dll). This can return null. >> https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > minor Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22776#pullrequestreview-2540639828 From honkar at openjdk.org Thu Jan 9 18:25:44 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 9 Jan 2025 18:25:44 GMT Subject: Integrated: JDK-8344907 : NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null In-Reply-To: References: Message-ID: On Mon, 16 Dec 2024 23:49:58 GMT, Harshitha Onkar wrote: > Win32ShellFolder2.getSystemIcon() can result in NPE if icon is null. Sanity null checks have been added. > > > long hIcon = getSystemIcon(iconType.getIconID()); //Can return null > Image icon = makeIcon(hIcon); // returns null if the condition (hIcon != 0L && hIcon != -1L) is false > if (LARGE_ICON_SIZE != icon.getWidth(null)) { // NullPointerException -- icon is null > > > Occurs when Windows is unable to provide a system icon and the code assumes an icon will **always** be returned, but the Windows API makes no such guarantee. > > getSystemIcon calls LoadIcon (User32.dll). This can return null. > https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadicona This pull request has now been integrated. Changeset: 9f3c5f95 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/9f3c5f95361c75d2b4d9e083901ce5a0ebf355e0 Stats: 20 lines in 1 file changed: 10 ins; 5 del; 5 mod 8344907: NullPointerException in Win32ShellFolder2.getSystemIcon when "icon" is null Reviewed-by: aivanov, kizune ------------- PR: https://git.openjdk.org/jdk/pull/22776 From dnguyen at openjdk.org Thu Jan 9 18:35:41 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 9 Jan 2025 18:35:41 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v4] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Wed, 8 Jan 2025 05:51:22 GMT, Prasanta Sadhukhan wrote: >> Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > mac limitation Ran this myself locally and on CI with repeats. Making this headless is much nicer for testing. Results are passing and the changes LGTM. Minor phrasing suggestion, but OK overall. test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 50: > 48: String osName = System.getProperty("os.name"); > 49: if (osName.toLowerCase().contains("os x")) { > 50: System.out.println("This test is not for MacOS, considered passed."); Suggestion: System.out.println("Ignoring this test for MacOS and passing instead."); Maybe something like this reads better. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/22937#pullrequestreview-2540526984 PR Review Comment: https://git.openjdk.org/jdk/pull/22937#discussion_r1909201804 From aturbanov at openjdk.org Thu Jan 9 18:42:08 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 9 Jan 2025 18:42:08 GMT Subject: RFR: 8347370: Unnecessary Hashtable usage in javax.swing.text.html.HTML Message-ID: The Hashtable `javax.swing.text.html.HTML.scMapping` is modified only within `` block. We can replace it with immutable map to avoid Hashtable synchronization overhead. ------------- Commit messages: - 8347370 update copyright year - [PATCH] Unnecessary Hashtable usage in javax.swing.text.html.HTML.scMapping Changes: https://git.openjdk.org/jdk/pull/21842/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21842&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347370 Stats: 20 lines in 1 file changed: 10 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21842.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21842/head:pull/21842 PR: https://git.openjdk.org/jdk/pull/21842 From dnguyen at openjdk.org Thu Jan 9 19:02:42 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 9 Jan 2025 19:02:42 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux In-Reply-To: References: Message-ID: <17s9qZbLcUsEbzq-UqHwVf7ihHnSTp0AmjFPiApe4JI=.0638957a-082f-4741-8c69-753b7e1bc46c@github.com> On Wed, 8 Jan 2025 19:40:29 GMT, Alexey Ivanov wrote: > **Problem:** > > The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. > > The focus is on _Button 2_ instead of _Button 4_. > > **Root cause:** > > The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. > > **Fix:** > > Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. > > Log focus movements and dispatched key events to facilitate failure analysis. > > Take a screenshot of the test frame in case of failure. > > These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. Tested this on Windows and Linux locally and on CI. Logging looks good and the test passes with repeats. LGTM test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 121: > 119: + "\n\t" + evt.getNewValue()); > 120: } > 121: }); Suggestion: evt -> System.out.println(evt.getPropertyName() + "\n\t" + evt.getOldValue() + "\n\t" + evt.getNewValue())); Nit. Possible lambda replacement here. test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 124: > 122: > 123: // ...and dispatched key events > 124: Toolkit.getDefaultToolkit().addAWTEventListener(new AWTEventListener() { The `AWTEventListener` can also be replaced with a lambda if preferred. test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 172: > 170: BufferedImage image = robot.createScreenCapture(getFrameBounds()); > 171: ImageIO.write(image, "png", > 172: new File("image.png")); Does this overflow the 80 character line limit? Or is this a standard? ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/22977#pullrequestreview-2540703533 PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909302224 PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909303094 PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909297406 From aivanov at openjdk.org Thu Jan 9 19:06:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 9 Jan 2025 19:06:40 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux In-Reply-To: <17s9qZbLcUsEbzq-UqHwVf7ihHnSTp0AmjFPiApe4JI=.0638957a-082f-4741-8c69-753b7e1bc46c@github.com> References: <17s9qZbLcUsEbzq-UqHwVf7ihHnSTp0AmjFPiApe4JI=.0638957a-082f-4741-8c69-753b7e1bc46c@github.com> Message-ID: On Thu, 9 Jan 2025 18:52:58 GMT, Damon Nguyen wrote: >> **Problem:** >> >> The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. >> >> The focus is on _Button 2_ instead of _Button 4_. >> >> **Root cause:** >> >> The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. >> >> **Fix:** >> >> Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. >> >> Log focus movements and dispatched key events to facilitate failure analysis. >> >> Take a screenshot of the test frame in case of failure. >> >> These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. > > test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 172: > >> 170: BufferedImage image = robot.createScreenCapture(getFrameBounds()); >> 171: ImageIO.write(image, "png", >> 172: new File("image.png")); > > Does this overflow the 80 character line limit? Or is this a standard? Yes, it does? by two characters. I find this way easier to parse anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909308082 From aivanov at openjdk.org Thu Jan 9 19:12:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 9 Jan 2025 19:12:35 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux In-Reply-To: <17s9qZbLcUsEbzq-UqHwVf7ihHnSTp0AmjFPiApe4JI=.0638957a-082f-4741-8c69-753b7e1bc46c@github.com> References: <17s9qZbLcUsEbzq-UqHwVf7ihHnSTp0AmjFPiApe4JI=.0638957a-082f-4741-8c69-753b7e1bc46c@github.com> Message-ID: On Thu, 9 Jan 2025 18:57:28 GMT, Damon Nguyen wrote: >> **Problem:** >> >> The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. >> >> The focus is on _Button 2_ instead of _Button 4_. >> >> **Root cause:** >> >> The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. >> >> **Fix:** >> >> Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. >> >> Log focus movements and dispatched key events to facilitate failure analysis. >> >> Take a screenshot of the test frame in case of failure. >> >> These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. > > test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 121: > >> 119: + "\n\t" + evt.getNewValue()); >> 120: } >> 121: }); > > Suggestion: > > evt -> System.out.println(evt.getPropertyName() > + "\n\t" + evt.getOldValue() > + "\n\t" + evt.getNewValue())); > > > Nit. Possible lambda replacement here. My IDE didn't suggest replacing it a lambda. Does it improve readability of the code? Perhaps, it does? by reducing the number of lines. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909314898 From aivanov at openjdk.org Thu Jan 9 19:19:01 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 9 Jan 2025 19:19:01 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: Message-ID: > **Problem:** > > The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. > > The focus is on _Button 2_ instead of _Button 4_. > > **Root cause:** > > The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. > > **Fix:** > > Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. > > Log focus movements and dispatched key events to facilitate failure analysis. > > Take a screenshot of the test frame in case of failure. > > These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Replace AWTEventListener and PropertyChangeListener with lambdas ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22977/files - new: https://git.openjdk.org/jdk/pull/22977/files/0e7376a3..e7991216 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22977&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22977&range=00-01 Stats: 17 lines in 1 file changed: 0 ins; 11 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22977/head:pull/22977 PR: https://git.openjdk.org/jdk/pull/22977 From dnguyen at openjdk.org Thu Jan 9 19:19:01 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 9 Jan 2025 19:19:01 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:16:02 GMT, Alexey Ivanov wrote: >> **Problem:** >> >> The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. >> >> The focus is on _Button 2_ instead of _Button 4_. >> >> **Root cause:** >> >> The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. >> >> **Fix:** >> >> Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. >> >> Log focus movements and dispatched key events to facilitate failure analysis. >> >> Take a screenshot of the test frame in case of failure. >> >> These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Replace AWTEventListener and PropertyChangeListener with lambdas Marked as reviewed by dnguyen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22977#pullrequestreview-2540740749 From dnguyen at openjdk.org Thu Jan 9 19:19:01 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 9 Jan 2025 19:19:01 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: <17s9qZbLcUsEbzq-UqHwVf7ihHnSTp0AmjFPiApe4JI=.0638957a-082f-4741-8c69-753b7e1bc46c@github.com> Message-ID: On Thu, 9 Jan 2025 19:10:21 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 121: >> >>> 119: + "\n\t" + evt.getNewValue()); >>> 120: } >>> 121: }); >> >> Suggestion: >> >> evt -> System.out.println(evt.getPropertyName() >> + "\n\t" + evt.getOldValue() >> + "\n\t" + evt.getNewValue())); >> >> >> Nit. Possible lambda replacement here. > > My IDE didn't suggest replacing it a lambda. Does it improve readability of the code? Perhaps, it does? by reducing the number of lines. Not by much if it does. I got into the habit of looking for where it's possible since reducing the line count usually makes it more readable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909319106 From prr at openjdk.org Thu Jan 9 19:42:46 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 9 Jan 2025 19:42:46 GMT Subject: RFR: 8344146: Remove temporary font file tracking code. Message-ID: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> The font data usage tracker only ever did anything if there was a SecurityManager installed and it restricted access to creating files. Since there can no longer be a Security Manager this is completely dead code and should be removed. ------------- Commit messages: - 8344146 Changes: https://git.openjdk.org/jdk/pull/22876/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22876&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344146 Stats: 276 lines in 5 files changed: 0 ins; 262 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/22876.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22876/head:pull/22876 PR: https://git.openjdk.org/jdk/pull/22876 From aivanov at openjdk.org Thu Jan 9 19:53:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 9 Jan 2025 19:53:41 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:00:48 GMT, Harshitha Onkar wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace AWTEventListener and PropertyChangeListener with lambdas > > test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 70: > >> 68: private static final CountDownLatch button4FocusLatch = new CountDownLatch(1); >> 69: >> 70: private static final CountDownLatch button2FocusLatch2 = new CountDownLatch(2); > > Minor: Should the no. of button2FocusLatch2 latches be 1? since we already have another button2FocusLatch > > Suggestion: > > private static final CountDownLatch button2FocusLatch2 = new CountDownLatch(1); No, `button2FocusLatch` tracks that _Button 2_ gets the initial focus; `button2FocusLatch2` tracks that _Button 2_ gets focus for the second time in case of repeated `KEY_PRESS` event for the Tab key. If `button2FocusLatch2` is released, the test fails with a clear error message ? _Button 2_ received focus whereas _Button 4_ is expected to have it. If the test continues, it will still fail because _Button 3_ won't get focus but there will be no indication why. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909357529 From honkar at openjdk.org Thu Jan 9 20:11:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 9 Jan 2025 20:11:36 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:51:09 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java line 70: >> >>> 68: private static final CountDownLatch button4FocusLatch = new CountDownLatch(1); >>> 69: >>> 70: private static final CountDownLatch button2FocusLatch2 = new CountDownLatch(2); >> >> Minor: Should the no. of button2FocusLatch2 latches be 1? since we already have another button2FocusLatch >> >> Suggestion: >> >> private static final CountDownLatch button2FocusLatch2 = new CountDownLatch(1); > > No, `button2FocusLatch` tracks that _Button 2_ gets the initial focus; `button2FocusLatch2` tracks that _Button 2_ gets focus for the second time in case of repeated `KEY_PRESS` event for the Tab key. > > If `button2FocusLatch2` is released, the test fails with a clear error message ? _Button 2_ received focus whereas _Button 4_ is expected to have it. If the test continues, it will still fail because _Button 3_ won't get focus but there will be no indication why. I understand that you need 2 separate CountDownLatches for Button 2, but my question was about the count of `button2FocusLatch2` . Shouldn't this be 1 instead of 2 counts or do you mean we require 2 counts of `button2FocusLatch2` to track focus twice after the initial one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909374489 From aivanov at openjdk.org Thu Jan 9 20:19:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 9 Jan 2025 20:19:40 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 20:08:21 GMT, Harshitha Onkar wrote: >> No, `button2FocusLatch` tracks that _Button 2_ gets the initial focus; `button2FocusLatch2` tracks that _Button 2_ gets focus for the second time in case of repeated `KEY_PRESS` event for the Tab key. >> >> If `button2FocusLatch2` is released, the test fails with a clear error message ? _Button 2_ received focus whereas _Button 4_ is expected to have it. If the test continues, it will still fail because _Button 3_ won't get focus but there will be no indication why. > > I understand that you need 2 separate CountDownLatches for Button 2, but my question was about the count of `button2FocusLatch2` . Shouldn't this be 1 instead of 2 counts or do you mean we require 2 counts of `button2FocusLatch2` to track focus twice after the initial one? No, it has to be 2. Focus listeners are added before the frame is displayed. https://github.com/openjdk/jdk/blob/e7991216fb25a0eeb094cbeef74128c6770c051a/test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java#L100-L104 If Button 2 receives focus **twice**, `button2FocusLatch2` will be released. If it had 1, then the latch would be released when Button 2 gets focus at the test start. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909382782 From honkar at openjdk.org Thu Jan 9 20:34:53 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 9 Jan 2025 20:34:53 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: Message-ID: <1ntufEXDuQJutqE_A-VrmxLUSzd47wMjd5Qv0483m-U=.a3f6ceb1-8896-499a-a511-b6b1c0266305@github.com> On Thu, 9 Jan 2025 19:19:01 GMT, Alexey Ivanov wrote: >> **Problem:** >> >> The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. >> >> The focus is on _Button 2_ instead of _Button 4_. >> >> **Root cause:** >> >> The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. >> >> **Fix:** >> >> Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. >> >> Log focus movements and dispatched key events to facilitate failure analysis. >> >> Take a screenshot of the test frame in case of failure. >> >> These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Replace AWTEventListener and PropertyChangeListener with lambdas Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22977#pullrequestreview-2540872033 From honkar at openjdk.org Thu Jan 9 20:34:53 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 9 Jan 2025 20:34:53 GMT Subject: RFR: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 20:17:06 GMT, Alexey Ivanov wrote: >> I understand that you need 2 separate CountDownLatches for Button 2, but my question was about the count of `button2FocusLatch2` . Shouldn't this be 1 instead of 2 counts or do you mean we require 2 counts of `button2FocusLatch2` to track focus twice after the initial one? > > No, it has to be 2. Focus listeners are added before the frame is displayed. > > https://github.com/openjdk/jdk/blob/e7991216fb25a0eeb094cbeef74128c6770c051a/test/jdk/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java#L100-L104 > > If Button 2 receives focus **twice**, `button2FocusLatch2` will be released. If it had 1, then the latch would be released when Button 2 gets focus at the test start. Makes sense. Thanks for clarifying. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22977#discussion_r1909396861 From achung at openjdk.org Thu Jan 9 20:50:43 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 9 Jan 2025 20:50:43 GMT Subject: Integrated: 8345144: Robot does not specify all causes of IllegalThreadStateException In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 22:33:41 GMT, Alisen Chung wrote: > When robot.autoWaitForIdle is set to true, all mouse and key-related methods when invoked on the EDT will throw java.lang.IllegalThreadStateException which is not in the Robot specification. > > This PR updates the specification by adding warnings to avoid calling lengthy and delay-type methods on EDT and including exceptions thrown when autoWaitForIdle is set to true and mouse/key-handling methods are called on the EDT. This pull request has now been integrated. Changeset: df28cec6 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/df28cec6e98f45ae535a35f97710710415522f99 Stats: 34 lines in 1 file changed: 33 ins; 0 del; 1 mod 8345144: Robot does not specify all causes of IllegalThreadStateException Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/22564 From achung at openjdk.org Thu Jan 9 21:17:14 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 9 Jan 2025 21:17:14 GMT Subject: RFR: 8347375: Extra

tag in robot specification Message-ID: Remove extra

tag in robot specification ------------- Commit messages: - remove

tag - api note - update class spec - align spacing - remove extra space - remove extra html tag, update wording - init commit Changes: https://git.openjdk.org/jdk/pull/23020/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23020&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347375 Stats: 34 lines in 1 file changed: 33 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23020.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23020/head:pull/23020 PR: https://git.openjdk.org/jdk/pull/23020 From prr at openjdk.org Thu Jan 9 21:22:47 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 9 Jan 2025 21:22:47 GMT Subject: RFR: 8347122: Add missing @serial tags to module java.desktop In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:58:33 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to add missing `@serial` javadoc tags in module `java.desktop`. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > This change has no effect on the generated documentation (apart from muting the warnings for missing `@serial` tags when building documentation with `-serialwarn` enabled). I did check that even without these tags, the comments appear in the serialisation spec, so this is really just a source clean up. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22979#pullrequestreview-2540950460 From achung at openjdk.org Thu Jan 9 21:22:58 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 9 Jan 2025 21:22:58 GMT Subject: RFR: 8347375: Extra

tag in robot specification [v2] In-Reply-To: References: Message-ID: > Remove extra

tag in robot specification Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: remove

from specification ------------- Changes: https://git.openjdk.org/jdk/pull/23020/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23020&range=01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23020.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23020/head:pull/23020 PR: https://git.openjdk.org/jdk/pull/23020 From achung at openjdk.org Thu Jan 9 21:30:50 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 9 Jan 2025 21:30:50 GMT Subject: RFR: 8347375: Extra

tag in robot specification [v3] In-Reply-To: References: Message-ID: > Remove extra

tag in robot specification Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: remove extra

tag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23020/files - new: https://git.openjdk.org/jdk/pull/23020/files/83f4d516..283325be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23020&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23020&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23020.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23020/head:pull/23020 PR: https://git.openjdk.org/jdk/pull/23020 From hannesw at openjdk.org Thu Jan 9 21:40:40 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 9 Jan 2025 21:40:40 GMT Subject: Integrated: 8347122: Add missing @serial tags to module java.desktop In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:58:33 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to add missing `@serial` javadoc tags in module `java.desktop`. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > This change has no effect on the generated documentation (apart from muting the warnings for missing `@serial` tags when building documentation with `-serialwarn` enabled). This pull request has now been integrated. Changeset: b335ea92 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/b335ea92963fc4524de41db6b1e866131b12f385 Stats: 173 lines in 47 files changed: 39 ins; 0 del; 134 mod 8347122: Add missing @serial tags to module java.desktop Reviewed-by: prr ------------- PR: https://git.openjdk.org/jdk/pull/22979 From kbarrett at openjdk.org Thu Jan 9 21:54:50 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 9 Jan 2025 21:54:50 GMT Subject: RFR: 8347375: Extra

tag in robot specification [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 21:30:50 GMT, Alisen Chung wrote: >> Remove extra

tag in robot specification > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > remove extra

tag Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23020#pullrequestreview-2540992158 From achung at openjdk.org Thu Jan 9 21:54:51 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 9 Jan 2025 21:54:51 GMT Subject: Integrated: 8347375: Extra

tag in robot specification In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 21:11:47 GMT, Alisen Chung wrote: > Remove extra

tag in robot specification This pull request has now been integrated. Changeset: 665c39c9 Author: Alisen Chung URL: https://git.openjdk.org/jdk/commit/665c39c93109f9ba23f3d9555878c0fb565622df Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8347375: Extra

tag in robot specification Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/23020 From jwaters at openjdk.org Fri Jan 10 04:58:40 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 10 Jan 2025 04:58:40 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'openjdk:master' into accessibility > - Cast to void in AccessBridgeCalls.c > - static_cast to void in jaccessinspector.cpp > - Formatting changes in AccessBridgeEventHandler.cpp > - Merge branch 'master' into accessibility > - Remove now unused result > - Merge branch 'master' into accessibility > - 8342870 Anyone? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21656#issuecomment-2581753221 From aivanov at openjdk.org Fri Jan 10 10:37:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 10 Jan 2025 10:37:48 GMT Subject: Integrated: 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:40:29 GMT, Alexey Ivanov wrote: > **Problem:** > > The `javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java` test fails in CI on Linux. > > The focus is on _Button 2_ instead of _Button 4_. > > **Root cause:** > > The additional logging revealed, an expected `KEY_PRESS` event. The test uses `Robot` API to press the Tab key and release it. When the test fails, there are two `KEY_PRESS` events followed by a single `KEY_RELEASE` event. Because the Tab key is pressed twice, the focus moves twice: from _Button 2_ (the initial state) to _Button 4_ and then back to _Button 2_. > > **Fix:** > > Use `CountDownLatch`es to track whether a radio button received focus. Detect the case where two `KEY_PRESS` events moved focus to _Button 2_ and report the failure. > > Log focus movements and dispatched key events to facilitate failure analysis. > > Take a screenshot of the test frame in case of failure. > > These CI hosts seem to be quite slow, removing the delay added by `robot.setAutoDelay(100)` has reduced the number of unexpected `KEY_PRESS` events. This didn't affect Windows or macOS. This pull request has now been integrated. Changeset: 57af52c5 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/57af52c57390f6f7413b5d3ffe64921c9b83aae4 Stats: 124 lines in 1 file changed: 85 ins; 13 del; 26 mod 8346581: JRadioButton/ButtonGroupFocusTest.java fails in CI on Linux Reviewed-by: honkar, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/22977 From duke at openjdk.org Fri Jan 10 10:53:13 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Fri, 10 Jan 2025 10:53:13 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v2] In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. GennadiyKrivoshein has updated the pull request incrementally with three additional commits since the last revision: - update copyright year - add imageable area test - move updates to the CUPSfuncs.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22110/files - new: https://git.openjdk.org/jdk/pull/22110/files/0344a01d..32fd353d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=00-01 Stats: 266 lines in 3 files changed: 259 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22110/head:pull/22110 PR: https://git.openjdk.org/jdk/pull/22110 From duke at openjdk.org Fri Jan 10 10:57:55 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Fri, 10 Jan 2025 10:57:55 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v3] In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: <-hK2CBiSdKOvtGGOmbhxdsR1iOXb5JgkhVl3hECVyus=.ec897864-169a-49ea-b310-534bf8012581@github.com> > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into PPDImageableArea - update copyright year - add imageable area test - move updates to the CUPSfuncs.c - Merge branch 'openjdk:master' into PPDImageableArea - margins calculation does not meet PostScript standard ------------- Changes: https://git.openjdk.org/jdk/pull/22110/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=02 Stats: 261 lines in 2 files changed: 257 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22110/head:pull/22110 PR: https://git.openjdk.org/jdk/pull/22110 From aivanov at openjdk.org Fri Jan 10 13:18:59 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 10 Jan 2025 13:18:59 GMT Subject: RFR: 8347427: JTabbedPane/8134116/Bug8134116.java has no license header Message-ID: The file `test/jdk/javax/swing/JTabbedPane/8134116/Bug8134116.java` has no license header. I added the GPL header and organised imports. ------------- Commit messages: - 8347427: JTabbedPane/8134116/Bug8134116.java has no license header Changes: https://git.openjdk.org/jdk/pull/23034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347427 Stats: 33 lines in 1 file changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23034.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23034/head:pull/23034 PR: https://git.openjdk.org/jdk/pull/23034 From dmarkov at openjdk.org Fri Jan 10 15:32:40 2025 From: dmarkov at openjdk.org (Dmitry Markov) Date: Fri, 10 Jan 2025 15:32:40 GMT Subject: RFR: 8347427: JTabbedPane/8134116/Bug8134116.java has no license header In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:14:27 GMT, Alexey Ivanov wrote: > The file `test/jdk/javax/swing/JTabbedPane/8134116/Bug8134116.java` has no license header. > > I added the GPL header and organised imports. Marked as reviewed by dmarkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23034#pullrequestreview-2542724550 From duke at openjdk.org Fri Jan 10 16:05:19 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Fri, 10 Jan 2025 16:05:19 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v4] In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: <6508dpyDdqBFLFWUsI5o8s4ZX0XjoKjqBsT7iJ4DEWE=.7219a4ce-9354-4aaf-bd9f-429db96ef070@github.com> > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. GennadiyKrivoshein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'openjdk:master' into PPDImageableArea - Merge branch 'master' into PPDImageableArea - update copyright year - add imageable area test - move updates to the CUPSfuncs.c - Merge branch 'openjdk:master' into PPDImageableArea - margins calculation does not meet PostScript standard ------------- Changes: https://git.openjdk.org/jdk/pull/22110/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=03 Stats: 261 lines in 2 files changed: 257 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22110/head:pull/22110 PR: https://git.openjdk.org/jdk/pull/22110 From ihse at openjdk.org Fri Jan 10 16:30:42 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Jan 2025 16:30:42 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds In-Reply-To: <-JVJPyA8NTl4D-TmJm9kolatk_WwMuR1-JXb-gef_gc=.22edd44c-f7c2-4451-938c-115c5e854e48@github.com> References: <-JVJPyA8NTl4D-TmJm9kolatk_WwMuR1-JXb-gef_gc=.22edd44c-f7c2-4451-938c-115c5e854e48@github.com> Message-ID: On Wed, 18 Dec 2024 19:35:09 GMT, Phil Race wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > >> There are multiple DllMain definitions throughout the JDK native libraries, causing name collisions. > > DllMain is a default name, not a required name. > You could just rename them and add /entry to the linker command line, eg /entry:AwtDllMain > > https://learn.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=msvc-170&viewFallbackFrom=vs-2019 > > I'm not sure it seems right to have every static destructor need to know what needs to be done to exit the DLL. > I do read your comment about not knowing when the static destructors are called vs the DllMain on shutdown, but surely this *is* well defined ? @prrace Are you okay with this solution, or would you prefer that I replace the use of JVM raw monitors with a hand-rolled mutex implementation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2583174116 From ihse at openjdk.org Fri Jan 10 17:57:40 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Jan 2025 17:57:40 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 11:51:51 GMT, Magnus Ihse Bursie wrote: > To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: > > 1) This is not called for statically linked libraries, and > 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. > > While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. > > In this case, the `DllMain` function did two things: > > 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. > > 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) > > But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means tha... Actually, when going over the backlog from my vacation, it looks like JDK-8346306 might fix this problem from the Hotspot side. I'll have to check that, and if so, this PR can be made much smaller. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2583377415 From honkar at openjdk.org Fri Jan 10 19:12:56 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 10 Jan 2025 19:12:56 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields Message-ID: ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). - Profile/Device class - Color Space - Rendering Intent - PCS - Header Size check (ICC Header Size = 128 bytes) These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf ------------- Commit messages: - test added - validation checks Changes: https://git.openjdk.org/jdk/pull/23044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347377 Stats: 273 lines in 3 files changed: 268 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From honkar at openjdk.org Fri Jan 10 19:28:17 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 10 Jan 2025 19:28:17 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v2] In-Reply-To: References: Message-ID: <0tsWcVqdpIbJOtcJzpwzv5XtpHmtc-47Ka9HIooORo8=.98e74b9d-f412-4352-80f9-563e178677c5@github.com> > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: line lengths, spacing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/3ef30ad1..550506de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=00-01 Stats: 24 lines in 1 file changed: 10 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From honkar at openjdk.org Fri Jan 10 19:28:17 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 10 Jan 2025 19:28:17 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v2] In-Reply-To: <0tsWcVqdpIbJOtcJzpwzv5XtpHmtc-47Ka9HIooORo8=.98e74b9d-f412-4352-80f9-563e178677c5@github.com> References: <0tsWcVqdpIbJOtcJzpwzv5XtpHmtc-47Ka9HIooORo8=.98e74b9d-f412-4352-80f9-563e178677c5@github.com> Message-ID: On Fri, 10 Jan 2025 19:25:18 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > line lengths, spacing src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java line 144: > 142: && profileClass != ICC_Profile.CLASS_DISPLAY > 143: && profileClass != ICC_Profile.CLASS_OUTPUT > 144: && profileClass != ICC_Profile.CLASS_DEVICELINK Test case 4 in ValidateICCHeaderData.java would fail without the addition of `ICC_Profile.CLASS_DEVICELINK` here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1911066641 From honkar at openjdk.org Fri Jan 10 19:34:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 10 Jan 2025 19:34:36 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/550506de..d3a4b8b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From honkar at openjdk.org Fri Jan 10 20:03:35 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 10 Jan 2025 20:03:35 GMT Subject: RFR: 8347427: JTabbedPane/8134116/Bug8134116.java has no license header In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:14:27 GMT, Alexey Ivanov wrote: > The file `test/jdk/javax/swing/JTabbedPane/8134116/Bug8134116.java` has no license header. > > I added the GPL header and organised imports. Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23034#pullrequestreview-2543623036 From aivanov at openjdk.org Fri Jan 10 20:44:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 10 Jan 2025 20:44:47 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 19:37:24 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year The suggested fix does not address the reported issue yet: both `hOldIcon` and `hOldIconSm` are still leaked if the function exists prematurely. Based on my above comments, I suggest restructuring the code. 1. Create new icons using `CreateIconFromRaster`. Do not assign the handles to member fields `m_hIcon` and `m_hIconSm` just yet. 2. Wrap the calls to `CreateIconFromRaster` in step 1 into a try-catch block to prevent a C++ exception escaping from JNI code as well as ensure a Java exception isn't raised. 1. If any exception occurs, destroy the newly created icon handles (`(new_)hIcon` and `(new_)hIconSm`) and exit. In this case both `m_hIcon` and `m_hIconSm` remain unmodified?the current icons remain unchanged. 2. If no exception occurs, 1. Assign the old values of `m_hIcon` and `m_hIconSm` to temporary variables (`hOldIcon` and `hOldIconSm`), ~~or call `DestroyIcon` right on the member fields `m_*`~~; 2. Assign the newly created icons to the member fields `m_hIcon` and `m_hIconSm` and execute the code below to update the inherited icons; 3. Call `DestroyIcon` on `hOldIcon` and `hOldIconSm`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22932#issuecomment-2584089564 From honkar at openjdk.org Fri Jan 10 22:05:47 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 10 Jan 2025 22:05:47 GMT Subject: RFR: 8344146: Remove temporary font file tracking code. In-Reply-To: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> References: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> Message-ID: <6of7QXf3i3bYvEKNldkhDv4UwvhBrVwjkirCUOudG5Q=.55fba1c0-62b1-499b-a10a-f61543b936cc@github.com> On Tue, 24 Dec 2024 18:26:06 GMT, Phil Race wrote: > The font data usage tracker only ever did anything if there was a SecurityManager installed and it restricted access to creating files. > Since there can no longer be a Security Manager this is completely dead code and should be removed. Changes & build LGTM. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22876#pullrequestreview-2544054276 From abhiscxk at openjdk.org Mon Jan 13 05:10:40 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 13 Jan 2025 05:10:40 GMT Subject: RFR: 8347427: JTabbedPane/8134116/Bug8134116.java has no license header In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:14:27 GMT, Alexey Ivanov wrote: > The file `test/jdk/javax/swing/JTabbedPane/8134116/Bug8134116.java` has no license header. > > I added the GPL header and organised imports. Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23034#pullrequestreview-2545715531 From psadhukhan at openjdk.org Mon Jan 13 05:21:38 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 13 Jan 2025 05:21:38 GMT Subject: Integrated: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI In-Reply-To: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Tue, 7 Jan 2025 03:16:57 GMT, Prasanta Sadhukhan wrote: > Test seems to still fail in CI in ubuntu22.04 intermittently even after [JDK-8346324](https://bugs.openjdk.org/browse/JDK-8346324). Made the test headless similar to javax/swing/JScrollBar/bug4842792.java. This pull request has now been integrated. Changeset: 9fafd63d Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/9fafd63d46f64428e0b9c2e9a6b0ac7ca0e2d355 Stats: 35 lines in 1 file changed: 4 ins; 19 del; 12 mod 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI Reviewed-by: abhiscxk, dnguyen ------------- PR: https://git.openjdk.org/jdk/pull/22937 From abhiscxk at openjdk.org Mon Jan 13 07:26:16 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 13 Jan 2025 07:26:16 GMT Subject: [jdk24] RFR: 8339728: [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class Message-ID: Hi all, This pull request contains a backport of commit [a46ae703](https://github.com/openjdk/jdk/commit/a46ae7031e30eb4940e43012a42f1b7fa5d942ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Abhishek Kumar on 9 Jan 2025 and was reviewed by Alexey Ivanov, Prasanta Sadhukhan and Alexander Zuev. Thanks! ------------- Commit messages: - 8339728: [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class Changes: https://git.openjdk.org/jdk/pull/23061/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23061&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339728 Stats: 127 lines in 3 files changed: 116 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23061/head:pull/23061 PR: https://git.openjdk.org/jdk/pull/23061 From kizune at openjdk.org Mon Jan 13 10:29:24 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 13 Jan 2025 10:29:24 GMT Subject: RFR: 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream Message-ID: If pitch drifts too low assume minimum allowed pitch to continue sampling. ------------- Commit messages: - 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream Changes: https://git.openjdk.org/jdk/pull/23064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336920 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23064/head:pull/23064 PR: https://git.openjdk.org/jdk/pull/23064 From duke at openjdk.org Mon Jan 13 11:36:27 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Mon, 13 Jan 2025 11:36:27 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v5] In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: Update test description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22110/files - new: https://git.openjdk.org/jdk/pull/22110/files/33947bce..339f383b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=03-04 Stats: 19 lines in 1 file changed: 13 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22110/head:pull/22110 PR: https://git.openjdk.org/jdk/pull/22110 From duke at openjdk.org Mon Jan 13 11:41:46 2025 From: duke at openjdk.org (Karm Michal Babacek) Date: Mon, 13 Jan 2025 11:41:46 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception RFR ping pls @mrserb @prrace @theRealAph :upside_down_face: ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2586874919 From duke at openjdk.org Mon Jan 13 11:42:34 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Mon, 13 Jan 2025 11:42:34 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files In-Reply-To: References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: On Thu, 12 Dec 2024 16:01:18 GMT, Prasanta Sadhukhan wrote: >> **Description:** >> The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. >> The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 >> >> **Updates:** >> Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. >> >> **Tests:** >> Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. >> The test was run with the minimum possible margins. >> _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). >> _After the fix_: all lines are printed. > > So, how returning the correct values from JNI violate this? Even if we do the calculation in the native, we will still be returning float values for upper top, right coordinates, correct? @prsadhuk, I moved changes to the CUPSfuncs.c. Could you please take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22110#issuecomment-2586876910 From ihse at openjdk.org Mon Jan 13 12:24:48 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 12:24:48 GMT Subject: RFR: 8306579: Consider building with /Zc:throwingNew [v2] In-Reply-To: References: Message-ID: On Tue, 31 Dec 2024 06:57:03 GMT, Julian Waters wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' into patch-15 >> - -Zc:throwingNew in flags-cflags.m4 >> - 8306579 > > Keep open please @TheShermanTanker What is holding you back from integrating? I think you are good to go at this point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22039#issuecomment-2586962004 From ihse at openjdk.org Mon Jan 13 12:27:44 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 12:27:44 GMT Subject: Integrated: 8346377: Properly support static builds for Windows In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie wrote: > When the static launcher was introduced in [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and resource constraints, it was only working properly on Linux and macOS, while the Windows port compiled but did not work. Now the time has come to fix that. > > Most of the changes mirrors the kind of changes that were made for Linux and macOS in JDK-8339480. There are still limitations to static builds on Windows (e.g. starting with a splashscreen), but these kind of limitations also exists on the other platforms. > > Note that this PR is blocked by [JDK-8346433](https://bugs.openjdk.org/browse/JDK-8346433), [JDK-8346195](https://bugs.openjdk.org/browse/JDK-8346195), [JDK-8346378](https://bugs.openjdk.org/browse/JDK-8346378), [JDK-8346383](https://bugs.openjdk.org/browse/JDK-8346383), [JDK-8346388](https://bugs.openjdk.org/browse/JDK-8346388) and [JDK-8346394](https://bugs.openjdk.org/browse/JDK-8346394), which must be integrated before this one. This pull request has now been integrated. Changeset: c885e59c Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/c885e59cfaeaab98bd05ec1ea54441d8e7c8268a Stats: 59 lines in 5 files changed: 38 ins; 4 del; 17 mod 8346377: Properly support static builds for Windows Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/22795 From aivanov at openjdk.org Mon Jan 13 13:52:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 13 Jan 2025 13:52:50 GMT Subject: [jdk24] RFR: 8339728: [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 07:20:18 GMT, Abhishek Kumar wrote: > Hi all, > > This pull request contains a backport of commit [a46ae703](https://github.com/openjdk/jdk/commit/a46ae7031e30eb4940e43012a42f1b7fa5d942ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Abhishek Kumar on 9 Jan 2025 and was reviewed by Alexey Ivanov, Prasanta Sadhukhan and Alexander Zuev. > > Thanks! Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23061#pullrequestreview-2546663615 From jwaters at openjdk.org Mon Jan 13 14:05:54 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 13 Jan 2025 14:05:54 GMT Subject: RFR: 8306579: Consider building with /Zc:throwingNew [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 05:48:57 GMT, Julian Waters wrote: >> [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed `-fcheck-new` when building with gcc. It turns out Visual Studio has a similar option, though inverted in behavior and default. >> >> It seems like /Zc:throwingNew- (the default) corresponds to gcc -fcheck-new, and /Zc:throwingNew corresponds to -fno-check-new (the default). >> >> The Visual Studio documentation strongly recommends using /Zc:throwingNew if possible, as turning it off (the default) seriously bloats code and inhibits optimizations. >> https://learn.microsoft.com/en-us/cpp/build/reference/zc-throwingnew-assume-operator-new-throws?view=msvc-170 >> >> As mentioned in [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590), the standard says that an allocation function can report allocation failure either by returning null (when it must have a nothrow exception specification), or by throwing `std::bad_alloc` (so obviously must not be declared as non-throwing). HotSpot allocation functions terminate the program instead of throwing on allocation failure, so similarly don't need the result checked for null. >> >> The documentation for /Zc:throwingNew is somewhat vague and confusing, so some investigation is probably needed to verify it really has the desired effect for us. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into patch-15 > - -Zc:throwingNew in flags-cflags.m4 > - 8306579 Sorry, was bogged down on my end. I'm free enough to integrate this at the moment, so I'll do that ------------- PR Comment: https://git.openjdk.org/jdk/pull/22039#issuecomment-2587185351 From jwaters at openjdk.org Mon Jan 13 14:05:55 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 13 Jan 2025 14:05:55 GMT Subject: Integrated: 8306579: Consider building with /Zc:throwingNew In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:30:05 GMT, Julian Waters wrote: > [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed `-fcheck-new` when building with gcc. It turns out Visual Studio has a similar option, though inverted in behavior and default. > > It seems like /Zc:throwingNew- (the default) corresponds to gcc -fcheck-new, and /Zc:throwingNew corresponds to -fno-check-new (the default). > > The Visual Studio documentation strongly recommends using /Zc:throwingNew if possible, as turning it off (the default) seriously bloats code and inhibits optimizations. > https://learn.microsoft.com/en-us/cpp/build/reference/zc-throwingnew-assume-operator-new-throws?view=msvc-170 > > As mentioned in [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590), the standard says that an allocation function can report allocation failure either by returning null (when it must have a nothrow exception specification), or by throwing `std::bad_alloc` (so obviously must not be declared as non-throwing). HotSpot allocation functions terminate the program instead of throwing on allocation failure, so similarly don't need the result checked for null. > > The documentation for /Zc:throwingNew is somewhat vague and confusing, so some investigation is probably needed to verify it really has the desired effect for us. This pull request has now been integrated. Changeset: a289bcfe Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/a289bcfe7e2786d05c338712b818fc4ef12cb4ac Stats: 13 lines in 2 files changed: 0 ins; 11 del; 2 mod 8306579: Consider building with /Zc:throwingNew Reviewed-by: ihse, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/22039 From mbaesken at openjdk.org Mon Jan 13 15:00:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Jan 2025 15:00:01 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings Message-ID: When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . ------------- Commit messages: - JDK-8347576 Changes: https://git.openjdk.org/jdk/pull/23076/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347576 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23076/head:pull/23076 PR: https://git.openjdk.org/jdk/pull/23076 From kizune at openjdk.org Mon Jan 13 16:13:41 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 13 Jan 2025 16:13:41 GMT Subject: [jdk24] RFR: 8339728: [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 07:20:18 GMT, Abhishek Kumar wrote: > Hi all, > > This pull request contains a backport of commit [a46ae703](https://github.com/openjdk/jdk/commit/a46ae7031e30eb4940e43012a42f1b7fa5d942ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Abhishek Kumar on 9 Jan 2025 and was reviewed by Alexey Ivanov, Prasanta Sadhukhan and Alexander Zuev. > > Thanks! Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23061#pullrequestreview-2547128736 From aivanov at openjdk.org Mon Jan 13 16:16:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 13 Jan 2025 16:16:44 GMT Subject: Integrated: 8347427: JTabbedPane/8134116/Bug8134116.java has no license header In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:14:27 GMT, Alexey Ivanov wrote: > The file `test/jdk/javax/swing/JTabbedPane/8134116/Bug8134116.java` has no license header. > > I added the GPL header and organised imports. This pull request has now been integrated. Changeset: f67b7036 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/f67b703625afa2e049c572978d29ac00d8c956d3 Stats: 33 lines in 1 file changed: 30 ins; 0 del; 3 mod 8347427: JTabbedPane/8134116/Bug8134116.java has no license header Reviewed-by: dmarkov, honkar, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/23034 From abhiscxk at openjdk.org Mon Jan 13 16:40:42 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 13 Jan 2025 16:40:42 GMT Subject: [jdk24] Integrated: 8339728: [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 07:20:18 GMT, Abhishek Kumar wrote: > Hi all, > > This pull request contains a backport of commit [a46ae703](https://github.com/openjdk/jdk/commit/a46ae7031e30eb4940e43012a42f1b7fa5d942ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Abhishek Kumar on 9 Jan 2025 and was reviewed by Alexey Ivanov, Prasanta Sadhukhan and Alexander Zuev. > > Thanks! This pull request has now been integrated. Changeset: ecdc3220 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/ecdc322029d3f1338d547955c938b6bc57696ac0 Stats: 127 lines in 3 files changed: 116 ins; 5 del; 6 mod 8339728: [Accessibility,Windows,JAWS] Bug in the getKeyChar method of the AccessBridge class Reviewed-by: aivanov, kizune Backport-of: a46ae7031e30eb4940e43012a42f1b7fa5d942ef ------------- PR: https://git.openjdk.org/jdk/pull/23061 From serb at openjdk.org Mon Jan 13 17:03:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 17:03:48 GMT Subject: RFR: 8346887: DrawFocusRect() may cause an assertion failure In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 16:36:07 GMT, Dmitry Markov wrote: > On Windows debug build execution of `DrawFocusRect()` may cause an assertion failure. In particular if a component, which is going to gain a focus, has zero size, the function returns `0` because focus rectangle is empty. > > It is necessary to check that the focus rectangle is not empty before `DrawFocusRect()` call. src/java.desktop/windows/native/libawt/windows/awt_Button.cpp line 245: > 243: VERIFY(::CopyRect(&focusRect, &rect)); > 244: VERIFY(::InflateRect(&focusRect,-inf,-inf)); > 245: if (!::IsRectEmpty(&focusRect) && (::DrawFocusRect(hDC, &focusRect) == 0)) If the "focusRect" is empty why we cannot skip most of this method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22973#discussion_r1913517707 From clanger at openjdk.org Mon Jan 13 18:55:42 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 13 Jan 2025 18:55:42 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 14:54:09 GMT, Matthias Baesken wrote: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . This does not look wrong. However, is %lld the standard format string for printing out jlong values? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2587944333 From serb at openjdk.org Mon Jan 13 19:04:40 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 19:04:40 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 14:54:09 GMT, Matthias Baesken wrote: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23076#pullrequestreview-2547581743 From serb at openjdk.org Mon Jan 13 19:22:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 19:22:48 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 19:10:00 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 795: > >> 793: } >> 794: >> 795: if (p != null) { > > If it possible to get null here we should thrown an exception, but I think we thrown that exception already in the native. it is probably better to add this validation into ProfileDataVerifier.verify(data), and check it even before .getModule().loadProfile(data) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913691351 From serb at openjdk.org Mon Jan 13 19:22:47 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 19:22:47 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 19:34:36 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > indentation src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 795: > 793: } > 794: > 795: if (p != null) { If it possible to get null here we should thrown an exception, but I think we thrown that exception already in the native. src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 995: > 993: case icSigAbstractClass -> CLASS_ABSTRACT; > 994: case icSigNamedColorClass -> CLASS_NAMEDCOLOR; > 995: default -> throw new IllegalArgumentException("Unknown device class"); This will expand the line out of 80 chars per line src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1176: > 1174: return true; > 1175: } > 1176: default -> throw new IllegalArgumentException("Unknown Rendering Intent"); how it is handled by the lcms library? don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913684990 PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913682136 PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913688450 From aivanov at openjdk.org Mon Jan 13 19:32:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 13 Jan 2025 19:32:38 GMT Subject: RFR: 8344146: Remove temporary font file tracking code. In-Reply-To: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> References: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> Message-ID: <_DnMS9vzxuVpfQEwx9RD0Mbx7JSmCNZGaKS2os_SP50=.343cacab-81ed-41dd-a59f-ead8406767d8@github.com> On Tue, 24 Dec 2024 18:26:06 GMT, Phil Race wrote: > The font data usage tracker only ever did anything if there was a SecurityManager installed and it restricted access to creating files. > Since there can no longer be a Security Manager this is completely dead code and should be removed. Looks good to me. You should bump the year in the updated files to 2025. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22876#pullrequestreview-2547654787 From serb at openjdk.org Mon Jan 13 19:36:51 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 19:36:51 GMT Subject: RFR: 8337505: Footprint and startup regressions up to 20% in GUI apps In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 21:26:38 GMT, Phil Race wrote: > https://bugs.openjdk.org/browse/JDK-8338677 already improved things for this so that's good. > > This fix adds to it lazy initialisation of VarHandles in StrikeCache at the cost of some extra code. > Since these VarHandles get used more or less immediately on Linux this new fix won't further improve matters there > But should help on Mac where they aren't usually needed at startup > And Windows is somewhere in between. Do we have a chance to reproduce the 20% numbers, and how it is comparable to the initial unsafe implementation? As a mentioned in the initial PR the new ffm implementation may add up to 100ms on startup(I tested it in the cmm). So taking that into account and 20% on some perftests(which one?) I assume migration back to unsafe could be an option as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2588024176 From honkar at openjdk.org Mon Jan 13 19:48:47 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 13 Jan 2025 19:48:47 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 19:13:16 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1176: > >> 1174: return true; >> 1175: } >> 1176: default -> throw new IllegalArgumentException("Unknown Rendering Intent"); > > how it is handled by the lcms library? don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? @mrserb Non-header data are updated using cooked approach (and validated by LCMS) whereas header data are updated using raw LCMS APIs hence require additional validation before setData() is called (On native side it is handled here: setTagDataNative() in [LCMS.c](https://github.com/openjdk/jdk/blob/63eb4853f6782f350f67b6bcf25d83bc4480be71/src/java.desktop/share/native/liblcms/LCMS.c#L445)). Without the fix, if invalid rendering intent, PCS, ColorSpace or Device class is updated using setData() it does not throw IAE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913723871 From aivanov at openjdk.org Mon Jan 13 19:50:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 13 Jan 2025 19:50:38 GMT Subject: RFR: 8347370: Unnecessary Hashtable usage in javax.swing.text.html.HTML In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:13:31 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.HTML.scMapping` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. Looks good to me. I'll submit a clientlibs test job and approve the PR once the job is complete. ------------- PR Review: https://git.openjdk.org/jdk/pull/21842#pullrequestreview-2547703302 From honkar at openjdk.org Mon Jan 13 19:56:37 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 13 Jan 2025 19:56:37 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 19:44:54 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1176: >> >>> 1174: return true; >>> 1175: } >>> 1176: default -> throw new IllegalArgumentException("Unknown Rendering Intent"); >> >> how it is handled by the lcms library? don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? > > @mrserb > Non-header data are updated using cooked approach (and validated by LCMS) whereas header data are updated using raw LCMS APIs hence require additional validation before setData() is called (On native side it is handled here: setTagDataNative() in [LCMS.c](https://github.com/openjdk/jdk/blob/63eb4853f6782f350f67b6bcf25d83bc4480be71/src/java.desktop/share/native/liblcms/LCMS.c#L445)). > > Without the fix, if invalid rendering intent, PCS, ColorSpace or Device class is updated using setData() it does not throw IAE. > don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? LCMS does not catch invalid header data and updates the profile, this can cause exceptions later on for instance when the modified profile is used to create BufferedImage. This can be prevented by adding checks in setData and restricting updates to only allowed values as specified in ICC Spec Doc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913732872 From mdoerr at openjdk.org Mon Jan 13 20:06:35 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 13 Jan 2025 20:06:35 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 14:54:09 GMT, Matthias Baesken wrote: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . LGTM. Thanks for fixing it! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23076#pullrequestreview-2547745613 From prr at openjdk.org Mon Jan 13 20:07:48 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 13 Jan 2025 20:07:48 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 19:53:29 GMT, Harshitha Onkar wrote: >> @mrserb >> Non-header data are updated using cooked approach (and validated by LCMS) whereas header data are updated using raw LCMS APIs hence require additional validation before setData() is called (On native side it is handled here: setTagDataNative() in [LCMS.c](https://github.com/openjdk/jdk/blob/63eb4853f6782f350f67b6bcf25d83bc4480be71/src/java.desktop/share/native/liblcms/LCMS.c#L445)). >> >> Without the fix, if invalid rendering intent, PCS, ColorSpace or Device class is updated using setData() it does not throw IAE. > >> don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? > > Yes, LCMS ignores invalid header data and updates the profile, this can cause exceptions later on for instance when the modified profile is used to create BufferedImage which can be prevented by adding checks in `setData()` and restricting updates to only allowed values as specified in ICC Spec Doc. > how it is handled by the lcms library? don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? The ICC spec. only defines these 4 intents, so I don't see a problem here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913744824 From prr at openjdk.org Mon Jan 13 20:14:51 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 13 Jan 2025 20:14:51 GMT Subject: RFR: 8344146: Remove temporary font file tracking code. In-Reply-To: <_DnMS9vzxuVpfQEwx9RD0Mbx7JSmCNZGaKS2os_SP50=.343cacab-81ed-41dd-a59f-ead8406767d8@github.com> References: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> <_DnMS9vzxuVpfQEwx9RD0Mbx7JSmCNZGaKS2os_SP50=.343cacab-81ed-41dd-a59f-ead8406767d8@github.com> Message-ID: <0PlkBY35qTTc5Wn6AjUl47EC83f_forRPWwH5yRXXkU=.2a2b698e-a1ed-4bae-8561-822a4db5f832@github.com> On Mon, 13 Jan 2025 19:30:17 GMT, Alexey Ivanov wrote: > Looks good to me. > > You should bump the year in the updated files to 2025. The changes were all made in 2024. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22876#issuecomment-2588094336 From aivanov at openjdk.org Mon Jan 13 20:14:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 13 Jan 2025 20:14:51 GMT Subject: RFR: 8344146: Remove temporary font file tracking code. In-Reply-To: <0PlkBY35qTTc5Wn6AjUl47EC83f_forRPWwH5yRXXkU=.2a2b698e-a1ed-4bae-8561-822a4db5f832@github.com> References: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> <_DnMS9vzxuVpfQEwx9RD0Mbx7JSmCNZGaKS2os_SP50=.343cacab-81ed-41dd-a59f-ead8406767d8@github.com> <0PlkBY35qTTc5Wn6AjUl47EC83f_forRPWwH5yRXXkU=.2a2b698e-a1ed-4bae-8561-822a4db5f832@github.com> Message-ID: On Mon, 13 Jan 2025 20:10:00 GMT, Phil Race wrote: > > Looks good to me. > > You should bump the year in the updated files to 2025. > > The changes were all made in 2024. Yet the only commit *into the OpenJDK Project* is made in 2025, on January 13, 2025. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22876#issuecomment-2588098846 From prr at openjdk.org Mon Jan 13 20:14:52 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 13 Jan 2025 20:14:52 GMT Subject: Integrated: 8344146: Remove temporary font file tracking code. In-Reply-To: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> References: <6PnOP_1igre4RLemaKQ8nJaPhJY7bdvi_gF-hpoi8Pw=.7df8062f-efd7-43d7-8c61-4adc80cd1908@github.com> Message-ID: On Tue, 24 Dec 2024 18:26:06 GMT, Phil Race wrote: > The font data usage tracker only ever did anything if there was a SecurityManager installed and it restricted access to creating files. > Since there can no longer be a Security Manager this is completely dead code and should be removed. This pull request has now been integrated. Changeset: 13a17757 Author: Phil Race URL: https://git.openjdk.org/jdk/commit/13a1775718f329b02cdeb82f9d3f7d878ac5e771 Stats: 276 lines in 5 files changed: 0 ins; 262 del; 14 mod 8344146: Remove temporary font file tracking code. Reviewed-by: honkar, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/22876 From azvegint at openjdk.org Mon Jan 13 20:19:35 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 13 Jan 2025 20:19:35 GMT Subject: RFR: 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 10:23:28 GMT, Alexander Zuev wrote: > If pitch drifts too low assume minimum allowed pitch to continue sampling. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23064#pullrequestreview-2547777607 From honkar at openjdk.org Mon Jan 13 21:02:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 13 Jan 2025 21:02:40 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: <3wV48FMVVHii_h-pQkvTVOuRFLPkGt0NvkLVUND_3es=.78e7423e-e56a-49f6-aa99-469206a4c4aa@github.com> On Mon, 13 Jan 2025 19:15:32 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 795: >> >>> 793: } >>> 794: >>> 795: if (p != null) { >> >> If it possible to get null here we should thrown an exception, but I think we thrown that exception already in the native. > > it is probably better to add this validation into ProfileDataVerifier.verify(data), and check it even before .getModule().loadProfile(data) This requires making the new method `verifyHeader()`public so that it can be used in ProfileDataVerifier.verify(data) as follows. byte[] theHeader = new byte[HEADER_SIZE]; System.arraycopy(data,0, theHeader, 0, HEADER_SIZE); ICC_Profile.verifyHeader(theHeader); or it can be added before .getModule().loadProfile(data) within ICC_Profile.getInstance() and this keeps verifyHeader() private. public static ICC_Profile getInstance(byte[] data) { ProfileDataVerifier.verify(data); Profile p; try { byte[] theHeader = new byte[HEADER_SIZE]; System.arraycopy(data, 0, theHeader, 0, HEADER_SIZE); verifyHeader(theHeader); p = CMSManager.getModule().loadProfile(data); } catch (CMMException c) { throw new IllegalArgumentException("Invalid ICC Profile Data"); } @prrace Your suggestion on whether to have `verifyHeader()` as private or public method? If we decide to make it public then a CSR is required. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913795818 From serb at openjdk.org Mon Jan 13 21:07:44 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 21:07:44 GMT Subject: RFR: 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 10:23:28 GMT, Alexander Zuev wrote: > If pitch drifts too low assume minimum allowed pitch to continue sampling. Do we have any way to reproduce/test this bug? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23064#issuecomment-2588197280 From serb at openjdk.org Mon Jan 13 21:13:40 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 21:13:40 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 19:13:16 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1176: > >> 1174: return true; >> 1175: } >> 1176: default -> throw new IllegalArgumentException("Unknown Rendering Intent"); > > how it is handled by the lcms library? don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? > @mrserb Non-header data are updated using cooked approach (and validated by LCMS) whereas header data are updated using raw LCMS APIs hence require additional validation before setData() is called (On native side it is handled here: setTagDataNative() in [LCMS.c](https://github.com/openjdk/jdk/blob/63eb4853f6782f350f67b6bcf25d83bc4480be71/src/java.desktop/share/native/liblcms/LCMS.c#L445)). > Then probably we can use approach similar to 8282577: https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada and try to rely on lcms for validation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913811004 From serb at openjdk.org Mon Jan 13 21:17:45 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 13 Jan 2025 21:17:45 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> On Mon, 13 Jan 2025 21:11:11 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1176: >> >>> 1174: return true; >>> 1175: } >>> 1176: default -> throw new IllegalArgumentException("Unknown Rendering Intent"); >> >> how it is handled by the lcms library? don't we need to ignore unknown intents(and other parameters) and lets lcms decide what to do? > >> @mrserb Non-header data are updated using cooked approach (and validated by LCMS) whereas header data are updated using raw LCMS APIs hence require additional validation before setData() is called (On native side it is handled here: setTagDataNative() in [LCMS.c](https://github.com/openjdk/jdk/blob/63eb4853f6782f350f67b6bcf25d83bc4480be71/src/java.desktop/share/native/liblcms/LCMS.c#L445)). >> > Then probably we can use approach similar to 8282577: https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada and try to rely on lcms for validation. > The ICC spec. defines only these 4 intents, so I don't see a problem here. our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913814116 From prr at openjdk.org Mon Jan 13 22:43:44 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 13 Jan 2025 22:43:44 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> Message-ID: On Mon, 13 Jan 2025 21:14:31 GMT, Sergey Bylokhov wrote: >>> @mrserb Non-header data are updated using cooked approach (and validated by LCMS) whereas header data are updated using raw LCMS APIs hence require additional validation before setData() is called (On native side it is handled here: setTagDataNative() in [LCMS.c](https://github.com/openjdk/jdk/blob/63eb4853f6782f350f67b6bcf25d83bc4480be71/src/java.desktop/share/native/liblcms/LCMS.c#L445)). >>> >> Then probably we can use approach similar to 8282577: https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada and try to rely on lcms for validation. > >> The ICC spec. defines only these 4 intents, so I don't see a problem here. > > our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 "our own profiles do not strictly follow these specification" What you are pointing to isn't a profile. It is code that accepts a requested rendering intent. I don't see how it is related. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913895960 From honkar at openjdk.org Tue Jan 14 00:24:46 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 00:24:46 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> Message-ID: On Mon, 13 Jan 2025 21:14:31 GMT, Sergey Bylokhov wrote: >>> @mrserb Non-header data are updated using cooked approach (and validated by LCMS) whereas header data are updated using raw LCMS APIs hence require additional validation before setData() is called (On native side it is handled here: setTagDataNative() in [LCMS.c](https://github.com/openjdk/jdk/blob/63eb4853f6782f350f67b6bcf25d83bc4480be71/src/java.desktop/share/native/liblcms/LCMS.c#L445)). >>> >> Then probably we can use approach similar to 8282577: https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada and try to rely on lcms for validation. > >> The ICC spec. defines only these 4 intents, so I don't see a problem here. > > our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 @mrserb > Then probably we can use approach similar to 8282577: https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada and try to rely on lcms for validation. The cooked approach doesn't work for ICC_Profile header data. We run into `IAE- cannot write tag data` for both invalid as well as valid header field values. Moreover there are separate LCMS APIs to set header fields `cmsSetHeaderFlags(...), cmsSetDeviceClass(...)`. Additionally, it is more efficient if these validation checks are added early on rather than process the data, go all the way to native side - LCMS.c just to return with IAE in case of invalid header data. The cooked approach involves copying over the data to a new profile, writing it to a memory buffer and then loading it back to check for profile correctness. This seems to be a lot of work for header data when simple validation checks in setData() can prevent invalid data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1913958762 From mbaesken at openjdk.org Tue Jan 14 08:58:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 14 Jan 2025 08:58:46 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 14:54:09 GMT, Matthias Baesken wrote: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Regarding jlong-format, in HS globalDefinitions.hpp we have this #define INT64_FORMAT "%" PRId64 .... #ifndef JLONG_FORMAT #define JLONG_FORMAT INT64_FORMAT Not sure we want to use that here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2589354449 From mbaesken at openjdk.org Tue Jan 14 09:11:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 14 Jan 2025 09:11:39 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 14:54:09 GMT, Matthias Baesken wrote: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Looks like this fixes Linux (when the libjsound trace is enabled) but Windows has more coding and more issues c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): error C2220: the following warning is treated as an error c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'HMIDIIN' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4313: 'fprintf': '%x' in format string conflicts with argument 1 of type 'HMIDIIN' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 3 has type 'UINT_PTR' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%llx' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%Ix' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%I64x' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'UINT_PTR' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%I64x' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 2 has type 'UINT_PTR' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string ... (rest of output omitted) * For target support_native_java.desktop_libjsound_PLATFORM_API_WinOS_Ports.obj: PLATFORM_API_WinOS_Ports.c c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_Ports.c(254): error C2220: the following warning is treated as an error c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_Ports.c(254): warning C4473: 'fprintf' : not enough arguments passed for format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_Ports.c(254): note: placeholders and their parameters expect 3 variadic arguments, but 2 were provided c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_Ports.c(254): note: the missing variadic argument 3 is required by format string '%p' ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2589381750 From clanger at openjdk.org Tue Jan 14 09:51:39 2025 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 14 Jan 2025 09:51:39 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 14:54:09 GMT, Matthias Baesken wrote: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23076#pullrequestreview-2549247755 From clanger at openjdk.org Tue Jan 14 09:51:40 2025 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 14 Jan 2025 09:51:40 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 08:55:57 GMT, Matthias Baesken wrote: > Regarding jlong-format, in HS globalDefinitions.hpp we have this > > ``` > #define INT64_FORMAT "%" PRId64 > .... > #ifndef JLONG_FORMAT > #define JLONG_FORMAT INT64_FORMAT > ``` > > Not sure we want to use that here? I also did some source code search, I think %lld should be good here. It's used in lots of other places as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2589463402 From ihse at openjdk.org Tue Jan 14 10:43:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 14 Jan 2025 10:43:56 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v2] In-Reply-To: References: Message-ID: > To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: > > 1) This is not called for statically linked libraries, and > 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. > > While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. > > In this case, the `DllMain` function did two things: > > 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. > > 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) > > But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means tha... 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 three commits: - Merge branch 'master' into dll-main-in-libawt - Merge branch 'master' into dll-main-in-libawt - 8346388: Cannot use DllMain in libawt for static builds ------------- Changes: https://git.openjdk.org/jdk/pull/22790/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22790&range=01 Stats: 61 lines in 3 files changed: 35 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22790/head:pull/22790 PR: https://git.openjdk.org/jdk/pull/22790 From ihse at openjdk.org Tue Jan 14 10:49:43 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 14 Jan 2025 10:49:43 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds In-Reply-To: <207GaVwqkbHLIBuQAZTkdBXRwPN5huv-8FMgaVNRFwI=.306ffc92-749e-4e09-b575-e0f1f39b5481@github.com> References: <-JVJPyA8NTl4D-TmJm9kolatk_WwMuR1-JXb-gef_gc=.22edd44c-f7c2-4451-938c-115c5e854e48@github.com> <207GaVwqkbHLIBuQAZTkdBXRwPN5huv-8FMgaVNRFwI=.306ffc92-749e-4e09-b575-e0f1f39b5481@github.com> Message-ID: On Wed, 18 Dec 2024 19:53:10 GMT, Magnus Ihse Bursie wrote: > > I do read your comment about not knowing when the static destructors are called vs the DllMain on shutdown, but surely this _is_ well defined ? > > That is possible. It could be just that I have failed to locate the documentation about this. Here is the documentation: (from https://learn.microsoft.com/en-us/cpp/build/run-time-library-behavior?view=msvc-170; thanks @dholmes-ora for the link) "The VCRuntime library provides an entry-point function called _DllMainCRTStartup to handle default initialization and termination operations. On process attach, the _DllMainCRTStartup function sets up buffer security checks, initializes the CRT and other libraries, initializes run-time type information, initializes and calls constructors for static and non-local data, initializes thread-local storage, increments an internal static counter for each attach, and then calls a user- or library-supplied DllMain. On process detach, the function goes through these steps in reverse. It calls DllMain, decrements the internal counter, calls destructors, calls CRT termination functions and registered atexit functions, and notifies any other libraries of termination." The TL;DR is that `DllMain` with `DLL_PROCESS_DETACH` happens before static destructors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2589586521 From mbaesken at openjdk.org Tue Jan 14 10:51:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 14 Jan 2025 10:51:56 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v2] In-Reply-To: References: Message-ID: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Windows fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23076/files - new: https://git.openjdk.org/jdk/pull/23076/files/e2b414ed..d5a9f0fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23076/head:pull/23076 PR: https://git.openjdk.org/jdk/pull/23076 From jwaters at openjdk.org Tue Jan 14 12:41:40 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 14 Jan 2025 12:41:40 GMT Subject: RFR: 8346195: Fix static initialization problem in GDIHashtable In-Reply-To: References: Message-ID: <2IFtmY_BenhqgoZywbDNXJUvIaTr6jp8ya1QegTAwZg=.3e99bb9d-8fb6-4217-8d16-6b2ccf28a912@github.com> On Tue, 17 Dec 2024 18:00:04 GMT, Magnus Ihse Bursie wrote: > > I am not sure if this is already on my list of reasons I don't like C++. > > I did not know about this until I tried to resolve this bug (it took some time to figure out the problem). I can surely put it on my such list. :) Turns out this was the exact reason why awt.dll under Windows/gcc was defective and always crashed the process when any attempt was made to load it whatsoever. Pulling this in fixed the issue, and now awt.dll is fully functional. Thanks for fixing this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22736#issuecomment-2589808022 From clanger at openjdk.org Tue Jan 14 13:20:36 2025 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 14 Jan 2025 13:20:36 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 10:51:56 GMT, Matthias Baesken wrote: >> When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Windows fixes Marked as reviewed by clanger (Reviewer). You need to update the license years in the files with fixes for Windows as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/23076#pullrequestreview-2549672283 PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2589888765 From mbaesken at openjdk.org Tue Jan 14 13:33:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 14 Jan 2025 13:33:14 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v3] In-Reply-To: References: Message-ID: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust COPYRIGHT years in windows files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23076/files - new: https://git.openjdk.org/jdk/pull/23076/files/d5a9f0fa..52d0453c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23076/head:pull/23076 PR: https://git.openjdk.org/jdk/pull/23076 From mdoerr at openjdk.org Tue Jan 14 13:59:42 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 14 Jan 2025 13:59:42 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 10:51:56 GMT, Matthias Baesken wrote: >> When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Windows fixes src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp line 74: > 72: case MIM_DATA: > 73: TRACE3(" MIDI_IN_PutMessage: MIM_MOREDATA or MIM_DATA. status=%p data1=%p data2=%p\n", > 74: (void*)(dwParam1 & 0xFF), (void*)((dwParam1 & 0xFF00)>>8), (void*)((dwParam1 & 0xFF0000)>>16)); I think using "%p" for hex Byte values is a bit strange. Otherwise, good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1914857652 From azvegint at openjdk.org Tue Jan 14 15:55:48 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 14 Jan 2025 15:55:48 GMT Subject: RFR: 8347370: Unnecessary Hashtable usage in javax.swing.text.html.HTML In-Reply-To: References: Message-ID: <7F1dD1-r3eHvHmglJ8t78Hpp0hb2vqXcBmzYE6vKY34=.337c344b-834c-4c68-84e0-a19720d7c0d4@github.com> On Fri, 1 Nov 2024 20:13:31 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.HTML.scMapping` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21842#pullrequestreview-2550184018 From serb at openjdk.org Tue Jan 14 17:28:43 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 14 Jan 2025 17:28:43 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> Message-ID: <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> On Tue, 14 Jan 2025 00:22:15 GMT, Harshitha Onkar wrote: >>> The ICC spec. defines only these 4 intents, so I don't see a problem here. >> >> our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 > > @mrserb >> Then probably we can use approach similar to 8282577: https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada and try to rely on lcms for validation. > > The cooked approach doesn't work for ICC_Profile header data. In case header data is updated using the cooked approach we run into `IAE- cannot write tag data` for both invalid as well as valid header field values. There are separate LCMS APIs to set header fields `cmsSetHeaderRenderingIntent(..), cmsSetDeviceClass(...)` so I don't think we should be using cooked approach to set header data. > > Additionally, it is more efficient if these validation checks are added early on rather than process the data, go all the way to native side - LCMS.c just to return with IAE in case of invalid header data. > > The cooked approach involves copying over the data to a new profile, writing it to a memory buffer and then loading it back to check for profile correctness. This seems to be a lot of work for header data when simple validation checks in setData() can prevent invalid data. > "our own profiles do not strictly follow these specification" > > What you are pointing to isn't a profile. It is code that accepts a requested rendering intent. I don't see how it is related. the new code will be called when loading raw data for a profile, so if that profile was previously accepted and used some default values, the new code will reject it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915300959 From serb at openjdk.org Tue Jan 14 17:36:43 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 14 Jan 2025 17:36:43 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 19:07:13 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 995: > >> 993: case icSigAbstractClass -> CLASS_ABSTRACT; >> 994: case icSigNamedColorClass -> CLASS_NAMEDCOLOR; >> 995: default -> throw new IllegalArgumentException("Unknown device class"); > > This will expand the line out of 80 chars per line Interesting, this exception is not specified for this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915314590 From honkar at openjdk.org Tue Jan 14 18:01:55 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 18:01:55 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v4] In-Reply-To: References: Message-ID: > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: IAE exception msg updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/d3a4b8b5..ffacf6f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=02-03 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From serb at openjdk.org Tue Jan 14 18:01:55 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 14 Jan 2025 18:01:55 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Tue, 14 Jan 2025 17:26:12 GMT, Sergey Bylokhov wrote: >> @mrserb >>> Then probably we can use approach similar to 8282577: https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada and try to rely on lcms for validation. >> >> The cooked approach doesn't work for ICC_Profile header data. In case header data is updated using the cooked approach we run into `IAE- cannot write tag data` for both invalid as well as valid header field values. There are separate LCMS APIs to set header fields `cmsSetHeaderRenderingIntent(..), cmsSetDeviceClass(...)` so I don't think we should be using cooked approach to set header data. >> >> Additionally, it is more efficient if these validation checks are added early on rather than process the data, go all the way to native side - LCMS.c just to return with IAE in case of invalid header data. >> >> The cooked approach involves copying over the data to a new profile, writing it to a memory buffer and then loading it back to check for profile correctness. This seems to be a lot of work for header data when simple validation checks in setData() can prevent invalid data. > >> "our own profiles do not strictly follow these specification" >> >> What you are pointing to isn't a profile. It is code that accepts a requested rendering intent. I don't see how it is related. > > the new code will be called when loading raw data for a profile, so if that profile was previously accepted and used some default values, the new code will reject it. >The cooked approach doesn't work for ICC_Profile header data. In case header data is updated using the cooked approach we run into IAE- cannot write tag data for both invalid as well as valid header field values. maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods? for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?: **void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);** Sets the color space signature in profile header, using ICC convention. Parameters: hProfile: Handle to a profile object sig: any cmsColorSpaceSignature from Table 10 Returns: *None* https://www.littlecms.com/LittleCMS2.16%20API.pdf ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915355480 From serb at openjdk.org Tue Jan 14 18:01:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 14 Jan 2025 18:01:56 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 19:34:36 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > indentation test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData.java line 39: > 37: > 38: public class ValidateICCHeaderData { > 39: private static ICC_Profile profile; the change will also affect serialization, the test should check that code path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915364992 From serb at openjdk.org Tue Jan 14 18:01:55 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 14 Jan 2025 18:01:55 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Tue, 14 Jan 2025 17:56:07 GMT, Sergey Bylokhov wrote: >>> "our own profiles do not strictly follow these specification" >>> >>> What you are pointing to isn't a profile. It is code that accepts a requested rendering intent. I don't see how it is related. >> >> the new code will be called when loading raw data for a profile, so if that profile was previously accepted and used some default values, the new code will reject it. > >>The cooked approach doesn't work for ICC_Profile header data. In case header data is updated using the cooked approach we run into IAE- cannot write tag data for both invalid as well as valid header field values. > > maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods? > > for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?: > > **void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);** > > Sets the color space signature in profile header, using ICC convention. > Parameters: > hProfile: Handle to a profile object > sig: any cmsColorSpaceSignature from Table 10 > Returns: > *None* > > https://www.littlecms.com/LittleCMS2.16%20API.pdf probably the answer will be that not all profiles are used for transformation, and just to read some of its properties it is not necessary to reject unexpected data such as intent/etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915359597 From honkar at openjdk.org Tue Jan 14 18:11:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 18:11:40 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v4] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 18:01:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > IAE exception msg updated src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java line 148: > 146: && profileClass != ICC_Profile.CLASS_NAMEDCOLOR > 147: && profileClass != ICC_Profile.CLASS_ABSTRACT) { > 148: throw new IllegalArgumentException("Invalid profile class"); IAE for device or profile class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915377657 From honkar at openjdk.org Tue Jan 14 18:11:44 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 18:11:44 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 17:33:52 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 995: >> >>> 993: case icSigAbstractClass -> CLASS_ABSTRACT; >>> 994: case icSigNamedColorClass -> CLASS_NAMEDCOLOR; >>> 995: default -> throw new IllegalArgumentException("Unknown device class"); >> >> This will expand the line out of 80 chars per line > > Interesting, this exception is not specified for this method. I have changed it back to "Unknown profile class". For that particular header field ICC Spec doc uses either device class or profile class. I wanted to be consistent here as well as in [ColorSpace Ln#147](https://github.com/openjdk/jdk/pull/23044/files#r1915377657) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915380960 From honkar at openjdk.org Tue Jan 14 18:38:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 18:38:36 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Tue, 14 Jan 2025 17:57:39 GMT, Sergey Bylokhov wrote: >>>The cooked approach doesn't work for ICC_Profile header data. In case header data is updated using the cooked approach we run into IAE- cannot write tag data for both invalid as well as valid header field values. >> >> maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods? >> >> for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?: >> >> **void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);** >> >> Sets the color space signature in profile header, using ICC convention. >> Parameters: >> hProfile: Handle to a profile object >> sig: any cmsColorSpaceSignature from Table 10 >> Returns: >> *None* >> >> https://www.littlecms.com/LittleCMS2.16%20API.pdf > > probably the answer will be that not all profiles are used for transformation, and just to read some of its properties it is not necessary to reject unexpected data such as intent/etc. @mrserb Some of these checks already exist and are done by jdk when loading profile using ICC_Profile.getInstance(byte[] data). For instance profile/device class and color space. Shouldn't setData() do something similar? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915418472 From honkar at openjdk.org Tue Jan 14 18:51:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 18:51:40 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: <_9IZ1JFFBD_xQZCNTPcZB_SlNi8ye98D-zeofhGx_sA=.2343457e-6e57-429b-842d-4e03d8bed4cb@github.com> On Tue, 14 Jan 2025 18:35:54 GMT, Harshitha Onkar wrote: >> probably the answer will be that not all profiles are used for transformation, and just to read some of its properties it is not necessary to reject unexpected data such as intent/etc. > > @mrserb > Some of these checks already exist and are done by jdk when loading profile using ICC_Profile.getInstance(byte[] data). For instance profile/device class and color space. Shouldn't setData() do something similar? > **void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);** > > Sets the color space signature in profile header, using ICC convention. > Parameters: > hProfile: Handle to a profile object > sig: any cmsColorSpaceSignature from Table 10 > Returns: > *None* > for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?: Based on the API doc,looks like LCMS expects client code (jdk) to validate the values before updating it using cmsSet**() APIs. I can double-check with the LCMS maintainers for clarity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915434490 From honkar at openjdk.org Tue Jan 14 19:52:46 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 19:52:46 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: <_9IZ1JFFBD_xQZCNTPcZB_SlNi8ye98D-zeofhGx_sA=.2343457e-6e57-429b-842d-4e03d8bed4cb@github.com> References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> <_9IZ1JFFBD_xQZCNTPcZB_SlNi8ye98D-ze ofhGx_sA=.2343457e-6e57-429b-842d-4e03d8bed4cb@github.com> Message-ID: On Tue, 14 Jan 2025 18:48:40 GMT, Harshitha Onkar wrote: > for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values? We can choose to add these validation checks to jdk which makes the code more robust and ensures that the profiles adhere to ICC Specification whether or not LCMS APIs expect to validate it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915515877 From aivanov at openjdk.org Tue Jan 14 19:57:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 14 Jan 2025 19:57:44 GMT Subject: RFR: 8347370: Unnecessary Hashtable usage in javax.swing.text.html.HTML In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:13:31 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.HTML.scMapping` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. The tests returned green. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21842#pullrequestreview-2550892889 From aivanov at openjdk.org Tue Jan 14 20:06:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 14 Jan 2025 20:06:46 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 18:08:03 GMT, Harshitha Onkar wrote: >> Interesting, this exception is not specified for this method. > > I have changed it back to "Unknown profile class". For that particular header field ICC Spec doc uses either device class or profile class. > I wanted to be consistent here as well as in [ColorSpace Ln#147](https://github.com/openjdk/jdk/pull/23044/files#r1915377657) > Interesting, this exception is not specified for this method. What do you mean? The javadoc is: * @throws IllegalArgumentException If the byte array does not contain valid * ICC Profile data The error message is not specified, the error message can be changed to be more specific to the case where it's thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915530214 From honkar at openjdk.org Tue Jan 14 20:43:49 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 20:43:49 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> <_9IZ1JFFBD_xQZCNTPcZB_SlNi8ye98D-ze ofhGx_sA=.2343457e-6e57-429b-842d-4e03d8bed4cb@github.com> Message-ID: On Tue, 14 Jan 2025 19:50:27 GMT, Harshitha Onkar wrote: >>> **void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);** >>> >>> Sets the color space signature in profile header, using ICC convention. >>> Parameters: >>> hProfile: Handle to a profile object >>> sig: any cmsColorSpaceSignature from Table 10 >>> Returns: >>> *None* >> >>> for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?: >> >> Based on the API doc,looks like LCMS expects client code (jdk) to validate the values before updating it using cmsSet**() APIs. I can double-check with the LCMS maintainers for clarity. > >> for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values? > > We can choose to add these validation checks to jdk which makes the code more robust and ensures that the profiles adhere to ICC Specification whether or not LCMS APIs expect to validate it. > our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" > > https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 >the new code will be called when loading raw data for a profile, so if that profile was previously accepted and used some default values, the new code will reject it. @prrace @mrserb There is difference in what is stated as accepted values for Rendering Intent in **[ICC Spec Doc](https://www.color.org/specification/ICC.1-2022-05.pdf) vs [LittleCMS API doc](https://www.littlecms.com/LittleCMS2.16%20API.pdf)** **ICC Spec Doc** states Rendering Intent can take one of the following values [Pg#23]: image ---- **The API doc** states it can take ICC Intent as well as Non-ICC Intent values [Pg#88,90] void cmsSetHeaderRenderingIntent(cmsHPROFILE hProfile, cmsUInt32Number RenderingIntent); Sets the profile header rendering intent. See the discussion above. Parameters: hProfile: Handle to a profile object RenderingIntent: A cmsUInt32Number holding the intent code, as described in Intents section image ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915571810 From honkar at openjdk.org Tue Jan 14 20:47:41 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 14 Jan 2025 20:47:41 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> <_9IZ1JFFBD_xQZCNTPcZB_SlNi8ye98D-ze ofhGx_sA=.2343457e-6e57-429b-842d-4e03d8bed4cb@github.com> Message-ID: On Tue, 14 Jan 2025 20:41:06 GMT, Harshitha Onkar wrote: > our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" > > https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 Is it for the above reason (it can take ICC Intent as well as Non ICC Intent) that LCMSTransform does NOT validate the value of rendering intent ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915575998 From gziemski at openjdk.org Tue Jan 14 20:53:33 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 14 Jan 2025 20:53:33 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory Message-ID: Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism. To use, you first need to record the pattern of operations, ex: `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar` This will run the target app, and log all the allocations in chronological order. This will produce a few files: - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations) - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state) - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing) Now you can use those recording to actually benchmark your proposed changes, ex: `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10` Which will produce yet another file: - hs_nmt_pid23527_benchmark.log that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output. The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change. ------------- Commit messages: - white spaces - white spaces - white spaces - white spaces - win and linux APIs - more consistent output when benchmarking - remove exec flag - NMT benchmark Changes: https://git.openjdk.org/jdk/pull/23115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317453 Stats: 3522 lines in 30 files changed: 3518 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115 PR: https://git.openjdk.org/jdk/pull/23115 From mbaesken at openjdk.org Wed Jan 15 08:42:37 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 08:42:37 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v3] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 13:33:14 GMT, Matthias Baesken wrote: >> When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust COPYRIGHT years in windows files ping, need a re-review after recent changes ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2591948119 From abhiscxk at openjdk.org Wed Jan 15 09:34:49 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 15 Jan 2025 09:34:49 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser Message-ID: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. ------------- Commit messages: - Test update Changes: https://git.openjdk.org/jdk/pull/23128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347475 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23128/head:pull/23128 PR: https://git.openjdk.org/jdk/pull/23128 From psadhukhan at openjdk.org Wed Jan 15 09:50:56 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 15 Jan 2025 09:50:56 GMT Subject: RFR: 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete Message-ID: This manual test draws a "custom" Caret which is to be placed in the same position between characters but it is seen the movement of caret leaves artifacts. Custom caret is rendering 2 horizontal and 1 vertical line to render "capital I" but horizontal lines repainting is not done properly. If the test is made to use Swing DefaultCaret implementation, no artifacts is seen. Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. Also, added 1 extra pixel in repainting logic to tackle caretWidth,height. Tested against windows, linux and mac where it renders ok and movement of caret does not leave any artifacts. ------------- Commit messages: - 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete Changes: https://git.openjdk.org/jdk/pull/23129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345618 Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23129/head:pull/23129 PR: https://git.openjdk.org/jdk/pull/23129 From ihse at openjdk.org Wed Jan 15 10:30:37 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 10:30:37 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 10:43:56 GMT, Magnus Ihse Bursie wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > > 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 three commits: > > - Merge branch 'master' into dll-main-in-libawt > - Merge branch 'master' into dll-main-in-libawt > - 8346388: Cannot use DllMain in libawt for static builds It turns out that JDK-8346306 indeed solves part of this problem -- we don't need to disable the raw JVM monitors, which simplifies this code a bit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2592255451 From ihse at openjdk.org Wed Jan 15 10:34:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 10:34:09 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v3] In-Reply-To: References: Message-ID: > To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: > > 1) This is not called for statically linked libraries, and > 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. > > While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. > > In this case, the `DllMain` function did two things: > > 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. > > 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) > > But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means tha... Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Simplify patch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22790/files - new: https://git.openjdk.org/jdk/pull/22790/files/523d6d42..e3afbc3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22790&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22790&range=01-02 Stats: 17 lines in 3 files changed: 0 ins; 16 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22790/head:pull/22790 PR: https://git.openjdk.org/jdk/pull/22790 From ihse at openjdk.org Wed Jan 15 10:39:46 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 10:39:46 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds In-Reply-To: <-JVJPyA8NTl4D-TmJm9kolatk_WwMuR1-JXb-gef_gc=.22edd44c-f7c2-4451-938c-115c5e854e48@github.com> References: <-JVJPyA8NTl4D-TmJm9kolatk_WwMuR1-JXb-gef_gc=.22edd44c-f7c2-4451-938c-115c5e854e48@github.com> Message-ID: On Wed, 18 Dec 2024 19:35:09 GMT, Phil Race wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > >> There are multiple DllMain definitions throughout the JDK native libraries, causing name collisions. > > DllMain is a default name, not a required name. > You could just rename them and add /entry to the linker command line, eg /entry:AwtDllMain > > https://learn.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=msvc-170&viewFallbackFrom=vs-2019 > > I'm not sure it seems right to have every static destructor need to know what needs to be done to exit the DLL. > I do read your comment about not knowing when the static destructors are called vs the DllMain on shutdown, but surely this *is* well defined ? @prrace Are you okay with this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2592275119 From jdv at openjdk.org Wed Jan 15 10:53:36 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 15 Jan 2025 10:53:36 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> <_9IZ1JFFBD_xQZCNTPcZB_SlNi8ye98D-ze ofhGx_sA=.2343457e-6e57-429b-842d-4e03d8bed4cb@github.com> Message-ID: On Tue, 14 Jan 2025 20:45:14 GMT, Harshitha Onkar wrote: >>> our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" >>> >>> https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 >>>the new code will be called when loading raw data for a profile, so if that profile was previously accepted and used some default values, the new code will reject it. >> >> @prrace @mrserb >> >> There is difference in what is stated as accepted values for Rendering Intent in **[ICC Spec Doc](https://www.color.org/specification/ICC.1-2022-05.pdf) vs [LittleCMS API doc](https://www.littlecms.com/LittleCMS2.16%20API.pdf)** >> >> **ICC Spec Doc** states Rendering Intent can take one of the following values [Pg#23]: >> >> image >> >> ---- >> **The API doc** states it can take ICC Intent as well as Non-ICC Intent values [Pg#88,90] >> >> >> void cmsSetHeaderRenderingIntent(cmsHPROFILE hProfile, >> cmsUInt32Number RenderingIntent); >> >> Sets the profile header rendering intent. See the discussion above. >> Parameters: >> hProfile: Handle to a profile object >> RenderingIntent: A cmsUInt32Number holding the intent code, as described in >> Intents section >> >> >> image > >> our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" >> >> https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 > > Is it for the above reason (it can take ICC Intent as well as Non ICC Intent) that LCMSTransform does NOT validate the value of rendering intent ? > > The ICC spec. defines only these 4 intents, so I don't see a problem here. > > our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" > > https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 I think only when user sets "Any" rendering intent we fallback to "Perceptual" intent. @honkar-jdk What happens when we set some random intent value? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1916325457 From clanger at openjdk.org Wed Jan 15 10:54:37 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 15 Jan 2025 10:54:37 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 08:39:49 GMT, Matthias Baesken wrote: > ping, need a re-review after recent changes ... What about Martin's comment regarding the %p for hex byte values? Shouldn't some form of %x be better? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2592307209 From ihse at openjdk.org Wed Jan 15 11:23:29 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 11:23:29 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: > To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: > > 1) This is not called for statically linked libraries, and > 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. > > While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. > > In this case, the `DllMain` function did two things: > > 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. > > 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) > > But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means tha... 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 five commits: - Merge branch 'master' into dll-main-in-libawt - Simplify patch - Merge branch 'master' into dll-main-in-libawt - Merge branch 'master' into dll-main-in-libawt - 8346388: Cannot use DllMain in libawt for static builds ------------- Changes: https://git.openjdk.org/jdk/pull/22790/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22790&range=03 Stats: 46 lines in 1 file changed: 19 ins; 26 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22790/head:pull/22790 PR: https://git.openjdk.org/jdk/pull/22790 From mbaesken at openjdk.org Wed Jan 15 11:37:36 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 11:37:36 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 10:51:47 GMT, Christoph Langer wrote: > What about Martin's comment regarding the %p for hex byte values? Shouldn't some form of %x be better? Do you maybe prefer casting to uintptr_t and use `"%" PRIxPTR ` for printing this stuff ? Seems this is done at some other places in the codebase. globalDefinitions.hpp contains also a few related macro definitions but that's Hotspot, I think we miss that for other libs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2592459896 From mbaesken at openjdk.org Wed Jan 15 12:43:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 12:43:52 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v4] In-Reply-To: References: Message-ID: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: change format specifiers at some places in Windows coding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23076/files - new: https://git.openjdk.org/jdk/pull/23076/files/52d0453c..502043e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=02-03 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23076/head:pull/23076 PR: https://git.openjdk.org/jdk/pull/23076 From jwaters at openjdk.org Wed Jan 15 13:55:35 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 15 Jan 2025 13:55:35 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 18:53:18 GMT, Christoph Langer wrote: > This does not look wrong. However, is %lld the standard format string for printing out jlong values? That should depend on the platform, lld is a long long int, while jlong can be either a long long or just a long ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2592914896 From jwaters at openjdk.org Wed Jan 15 14:01:49 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 15 Jan 2025 14:01:49 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 12:43:52 GMT, Matthias Baesken wrote: >> When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > change format specifiers at some places in Windows coding src/java.desktop/share/native/libjsound/MidiOutDevice.c line 97: > 95: /* Handle error codes. */ > 96: if (ret < -1) { > 97: ERROR1("Java_com_sun_media_sound_MidiOutDevice_nGetTimeStamp: MIDI_IN_GetTimeStamp returned %lld\n", (long long int) ret); I wonder if we could use the format specifier for jlong here somehow, avoiding the cast here src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp line 76: > 74: case MIM_DATA: > 75: TRACE3(" MIDI_IN_PutMessage: MIM_MOREDATA or MIM_DATA. status=0x%" PRIxPTR " data1=0x%" PRIxPTR " data2=0x%" PRIxPTR "\n", > 76: (uintptr_t)(dwParam1 & 0xFF), (uintptr_t)((dwParam1 & 0xFF00)>>8), (uintptr_t)((dwParam1 & 0xFF0000)>>16)); Why cast to uintptr_t? dwParam1's UINT_PTR type is really just an unsigned int, so the existing %x seems correct ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916697942 PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916695459 From jwaters at openjdk.org Wed Jan 15 14:05:40 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 15 Jan 2025 14:05:40 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v4] In-Reply-To: References: Message-ID: <4gXXMRNRsth3Cbl_GB9oAunArAARNiVnj-ivrKkx3cI=.5a0595cc-aae1-48a6-aeed-3fb96a771743@github.com> On Wed, 15 Jan 2025 12:43:52 GMT, Matthias Baesken wrote: >> When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > change format specifiers at some places in Windows coding src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp line 60: > 58: MidiDeviceHandle* handle = (MidiDeviceHandle*) dwInstance; > 59: > 60: TRACE3("> MIDI_IN_PutMessage, hMidiIn: 0x%" PRIxPTR ", wMsg: %x, dwInstance: 0x%" PRIxPTR "\n", (uintptr_t)hMidiIn, wMsg, (uintptr_t)dwInstance); It's surprisingly difficult to find the type of HMIDIIN, but the rest of the types here are UINT_PTR and hence %x seems correct ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916702600 From mbaesken at openjdk.org Wed Jan 15 14:14:47 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 14:14:47 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 13:58:53 GMT, Julian Waters wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> change format specifiers at some places in Windows coding > > src/java.desktop/share/native/libjsound/MidiOutDevice.c line 97: > >> 95: /* Handle error codes. */ >> 96: if (ret < -1) { >> 97: ERROR1("Java_com_sun_media_sound_MidiOutDevice_nGetTimeStamp: MIDI_IN_GetTimeStamp returned %lld\n", (long long int) ret); > > I wonder if we could use the format specifier for jlong here somehow, avoiding the cast here I think we do not have this now in this lib. Of course we can copy something like this test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp 30 #include 34 #if defined(_LP64) && defined(__APPLE__) 35 #define JLONG_FORMAT "%ld" 36 #else // _LP64 && __APPLE__ 37 #define JLONG_FORMAT "%" PRId64 38 #endif // _LP64 && __APPLE__ into the file and then use JLONG_FORMAT . Is this worth it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916717612 From jwaters at openjdk.org Wed Jan 15 14:22:45 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 15 Jan 2025 14:22:45 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:12:11 GMT, Matthias Baesken wrote: >> src/java.desktop/share/native/libjsound/MidiOutDevice.c line 97: >> >>> 95: /* Handle error codes. */ >>> 96: if (ret < -1) { >>> 97: ERROR1("Java_com_sun_media_sound_MidiOutDevice_nGetTimeStamp: MIDI_IN_GetTimeStamp returned %lld\n", (long long int) ret); >> >> I wonder if we could use the format specifier for jlong here somehow, avoiding the cast here > > I think we do not have this now in this lib. Of course we can copy something like this > > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp > > 30 #include > > 34 #if defined(_LP64) && defined(__APPLE__) > 35 #define JLONG_FORMAT "%ld" > 36 #else // _LP64 && __APPLE__ > 37 #define JLONG_FORMAT "%" PRId64 > 38 #endif // _LP64 && __APPLE__ > > > into the file and then use JLONG_FORMAT . > Is this worth it? That seems preferable, but I'll leave it up to you and the other people who reviewed this on where to put the define, whether locally in the file, or in a header >> src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp line 60: >> >>> 58: MidiDeviceHandle* handle = (MidiDeviceHandle*) dwInstance; >>> 59: >>> 60: TRACE3("> MIDI_IN_PutMessage, hMidiIn: 0x%" PRIxPTR ", wMsg: %x, dwInstance: 0x%" PRIxPTR "\n", (uintptr_t)hMidiIn, wMsg, (uintptr_t)dwInstance); >> >> It's surprisingly difficult to find the type of HMIDIIN, but the rest of the types here are UINT_PTR and hence %x seems correct > > Here the compile error we get ; %x does not work for HMIDIIN or UINT_PTR. > > > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): error C2220: the following warning is treated as an error > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'HMIDIIN' > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4313: 'fprintf': '%x' in format string conflicts with argument 1 of type 'HMIDIIN' > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 3 has type 'UINT_PTR' > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%llx' in the format string > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%Ix' in the format string > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%I64x' in the format string > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'UINT_PTR' > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%I64x' in the format string > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 2 has type 'UINT_PTR' > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string > c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string > ... (rest of output omitted) Ah, I just checked, UINT_PTR confusingly differs depending on certain defines. Alright, makes sense, though I still haven't figured out what type HMIDIIN is ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916727458 PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916730912 From mbaesken at openjdk.org Wed Jan 15 14:22:47 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 14:22:47 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v4] In-Reply-To: <4gXXMRNRsth3Cbl_GB9oAunArAARNiVnj-ivrKkx3cI=.5a0595cc-aae1-48a6-aeed-3fb96a771743@github.com> References: <4gXXMRNRsth3Cbl_GB9oAunArAARNiVnj-ivrKkx3cI=.5a0595cc-aae1-48a6-aeed-3fb96a771743@github.com> Message-ID: On Wed, 15 Jan 2025 14:02:00 GMT, Julian Waters wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> change format specifiers at some places in Windows coding > > src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp line 60: > >> 58: MidiDeviceHandle* handle = (MidiDeviceHandle*) dwInstance; >> 59: >> 60: TRACE3("> MIDI_IN_PutMessage, hMidiIn: 0x%" PRIxPTR ", wMsg: %x, dwInstance: 0x%" PRIxPTR "\n", (uintptr_t)hMidiIn, wMsg, (uintptr_t)dwInstance); > > It's surprisingly difficult to find the type of HMIDIIN, but the rest of the types here are UINT_PTR and hence %x seems correct Here the compile error we get ; %x does not work for HMIDIIN or UINT_PTR. c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): error C2220: the following warning is treated as an error c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'HMIDIIN' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4313: 'fprintf': '%x' in format string conflicts with argument 1 of type 'HMIDIIN' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 3 has type 'UINT_PTR' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%llx' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%Ix' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%I64x' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'UINT_PTR' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%I64x' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 2 has type 'UINT_PTR' c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string ... (rest of output omitted) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916723519 From mbaesken at openjdk.org Wed Jan 15 14:35:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 14:35:40 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:19:51 GMT, Julian Waters wrote: >> Here the compile error we get ; %x does not work for HMIDIIN or UINT_PTR. >> >> >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): error C2220: the following warning is treated as an error >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'HMIDIIN' >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4313: 'fprintf': '%x' in format string conflicts with argument 1 of type 'HMIDIIN' >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 3 has type 'UINT_PTR' >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%llx' in the format string >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%Ix' in the format string >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(58): note: consider using '%I64x' in the format string >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 1 has type 'UINT_PTR' >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%I64x' in the format string >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): warning C4477: 'fprintf' : format string '%x' requires an argument of type 'unsigned int', but variadic argument 2 has type 'UINT_PTR' >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%llx' in the format string >> c:\builddir\jdk\src\java.desktop\windows\native\libjsound\PLATFORM_API_WinOS_MidiIn.cpp(59): note: consider using '%Ix' in the format string >> ...... > > Ah, I just checked, UINT_PTR confusingly differs depending on certain defines. Alright, makes sense, though I still haven't figured out what type HMIDIIN is. I think you could just do %llx directly instead of doing the dance with uintptr_t and inttypes.h though Regarding HMIDIIN , according to https://learn.microsoft.com/en-us/windows/win32/multimedia/midi-input-data-types it seems to be a HANDLE type/typedef. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23076#discussion_r1916761469 From duke at openjdk.org Wed Jan 15 16:56:35 2025 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 15 Jan 2025 16:56:35 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser In-Reply-To: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: On Wed, 15 Jan 2025 09:30:03 GMT, Abhishek Kumar wrote: > There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/23128#issuecomment-2593446979 From kizune at openjdk.org Wed Jan 15 21:13:43 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 15 Jan 2025 21:13:43 GMT Subject: RFR: 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream In-Reply-To: References: Message-ID: <_p8bEyAhxA6vvgIjAZmBME2osB--jlrml4hqapfB6x8=.49d8ee7d-fb30-4bdb-9cf4-3afe103e84e7@github.com> On Mon, 13 Jan 2025 21:05:05 GMT, Sergey Bylokhov wrote: > Do we have any way to reproduce/test this bug? Unfortunately the reproducer i have is proprietary so i can't share it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23064#issuecomment-2593943373 From prr at openjdk.org Wed Jan 15 21:30:40 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 15 Jan 2025 21:30:40 GMT Subject: RFR: 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream In-Reply-To: References: Message-ID: <-SloGY9b9ZjvmwuGxRgUAMUgqVkJN3yGpL6FjSiaxcA=.2cfc3e15-8f67-4af6-8389-f0fe132ac3fa@github.com> On Mon, 13 Jan 2025 10:23:28 GMT, Alexander Zuev wrote: > If pitch drifts too low assume minimum allowed pitch to continue sampling. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23064#pullrequestreview-2554015109 From rmahajan at openjdk.org Wed Jan 15 21:52:52 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Wed, 15 Jan 2025 21:52:52 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v4] In-Reply-To: References: Message-ID: <436Lmyuq3VrJBu6n8Ld3PFXSFBvn6-GG6n-dUgsftvY=.363f45fa-207c-41dc-b742-23a10bb04e30@github.com> > **Issue:** > AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. > > **Solution:** > I have added the exception handling code to take care that the handles are properly destroyed and not leaked. > > **Testing:** > I have tested the code to make sure there are no regressions caused by this. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: Update code according to the feedback in code review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22932/files - new: https://git.openjdk.org/jdk/pull/22932/files/79a82de0..e22d8119 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=02-03 Stats: 54 lines in 1 file changed: 34 ins; 16 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22932/head:pull/22932 PR: https://git.openjdk.org/jdk/pull/22932 From duke at openjdk.org Wed Jan 15 22:30:45 2025 From: duke at openjdk.org (duke) Date: Wed, 15 Jan 2025 22:30:45 GMT Subject: Withdrawn: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie wrote: > In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. > > I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. > > The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. > > This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22104 From achung at openjdk.org Wed Jan 15 22:37:34 2025 From: achung at openjdk.org (Alisen Chung) Date: Wed, 15 Jan 2025 22:37:34 GMT Subject: RFR: 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 09:45:33 GMT, Prasanta Sadhukhan wrote: > This manual test draws a "custom" Caret which is to be placed in the same position between characters but it is seen the movement of caret leaves artifacts. Custom caret is rendering 2 horizontal and 1 vertical line to render "capital I" but horizontal lines repainting is not done properly. > If the test is made to use Swing DefaultCaret implementation, no artifacts is seen. Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. Also, added 1 extra pixel in repainting logic to tackle caretWidth,height. > Tested against windows, linux and mac where it renders ok and movement of caret does not leave any artifacts. Test changes look fine, but do you know the reason why the CustomCaret was leaving artifacts? ------------- PR Review: https://git.openjdk.org/jdk/pull/23129#pullrequestreview-2554182406 From honkar at openjdk.org Wed Jan 15 23:40:04 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 15 Jan 2025 23:40:04 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v5] In-Reply-To: References: Message-ID: > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: added getInstance() test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/ffacf6f3..82436871 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=03-04 Stats: 45 lines in 1 file changed: 36 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From honkar at openjdk.org Wed Jan 15 23:52:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 15 Jan 2025 23:52:40 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 17:59:26 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData.java line 39: > >> 37: >> 38: public class ValidateICCHeaderData { >> 39: private static ICC_Profile profile; > > the change will also affect serialization, the test should check that code path. Added 2 more cases that tests loading a profile using ICC_Profile.getInstance(byte[] data) Now we hit the code path where verifyHeader() is called within getInstance(). Also , I did test by directly loading a profile from a file - ICC_Profile.getInstance("sRGB.pf") and it works fine. Do you mean this code path or something else? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1917483386 From prr at openjdk.org Thu Jan 16 00:17:41 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 16 Jan 2025 00:17:41 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 23:50:28 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData.java line 39: >> >>> 37: >>> 38: public class ValidateICCHeaderData { >>> 39: private static ICC_Profile profile; >> >> the change will also affect serialization, the test should check that code path. > > Added 2 more cases that tests loading a profile using ICC_Profile.getInstance(byte[] data) > Now we hit the code path where verifyHeader() is called within getInstance(). > Also , I did test by directly loading a profile from a file - ICC_Profile.getInstance("sRGB.pf") and it works fine. > > Do you mean this code path or something else? I *think* what he means is that a profile with a now rejected header might allowed on JDK 21, and serialised on JDK 21 and when deserialised on JDK 25 (with this change) it is then rejected. Since it is unlikely the profile actually worked properly anyway on JDK 21, I don't think that would be an issue except for contrived tests, and is an insufficient reason to not make this change. Also if we were to consider backporting this to 21u then they'd not be able to serialise it. If we get a bug report on serialisation with a legitimate case, we can take another look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1917497644 From kizune at openjdk.org Thu Jan 16 01:14:07 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Thu, 16 Jan 2025 01:14:07 GMT Subject: Integrated: 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 10:23:28 GMT, Alexander Zuev wrote: > If pitch drifts too low assume minimum allowed pitch to continue sampling. This pull request has now been integrated. Changeset: 9c430c92 Author: Alexander Zuev URL: https://git.openjdk.org/jdk/commit/9c430c92257739730155df05f340fe144fd24098 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream Reviewed-by: azvegint, prr ------------- PR: https://git.openjdk.org/jdk/pull/23064 From honkar at openjdk.org Thu Jan 16 02:19:41 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 16 Jan 2025 02:19:41 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> <_9IZ1JFFBD_xQZCNTPcZB_SlNi8ye98D-ze ofhGx_sA=.2343457e-6e57-429b-842d-4e03d8bed4cb@github.com> Message-ID: On Wed, 15 Jan 2025 10:36:58 GMT, Jayathirth D V wrote: >>> our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" >>> >>> https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 >> >> Is it for the above reason (it can take ICC Intent as well as Non ICC Intent) that LCMSTransform does NOT validate the value of rendering intent ? > >> > The ICC spec. defines only these 4 intents, so I don't see a problem here. >> >> our own profiles do not strictly follow these specification, so if lcms ignores that we can do the same, especially since we fallback to the "Perceptual intent" >> >> https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 > > I think only when user sets "Any" rendering intent we fallback to "Perceptual" intent. > @honkar-jdk What happens when we set some random intent value? @jayathirthrao When a random value is added for rendering intent in LCMSTransform as below, LCMS throws CMMException , but when I change to any other **Non-ICC Intents** (as specified in the table 41 above) it passes. Looks like LCMS accepts both ICC and Non-ICC Intents but I not sure if we need to check Non-ICC Intents during profile creation or updation. The location that @mrserb mentioned in LCMSTransform involves creating a new color space transform using 2 or more profiles. There is a note about rendering intent in Spec & API doc about being dynamically set and it has value only when profile is used in some context. _"The rendering intent field shall specify the rendering intent which should be used (or, in the case of a DeviceLink profile, was used) when this profile is (was) combined with another profile. In a sequence of more than two profiles, it applies to the combination of this profile and the next profile in the sequence and not to the entire sequence. **Typically, the user or application will set the rendering intent dynamically at runtime or embedding time. Therefore, this flag may not have any meaning until the profile is used in some context, e.g. in a DeviceLink or an embedded source profile**."_ Test case: ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_GRAY); cs.toRGB(new float[3]); //triggers createTransform() -> LCMSTransform ` this.renderingIntent = (renderingIntent == ColorTransform.Any) ? 5 : renderingIntent;` java.awt.color.CMMException: LCMS error 8: Unsupported intent '5' at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method) at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:113) at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:114) at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:534) at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224) at ValidateICCHeaderData.main(ValidateICCHeaderData.java:166) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1917569546 From honkar at openjdk.org Thu Jan 16 02:25:41 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 16 Jan 2025 02:25:41 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 00:14:31 GMT, Phil Race wrote: >> Added 2 more cases that tests loading a profile using ICC_Profile.getInstance(byte[] data) >> Now we hit the code path where verifyHeader() is called within getInstance(). >> Also , I did test by directly loading a profile from a file - ICC_Profile.getInstance("sRGB.pf") and it works fine. >> >> Did you mean this code path or something else? > > I *think* what he means is that a profile with a now rejected header might allowed on JDK 21, > and serialised on JDK 21 and when deserialised on JDK 25 (with this change) it is then rejected. > > Since it is unlikely the profile actually worked properly anyway on JDK 21, I don't think that would be an issue except for contrived tests, and is an insufficient reason to not make this change. > Also if we were to consider backporting this to 21u then they'd not be able to serialise it. > If we get a bug report on serialisation with a legitimate case, we can take another look. Makes sense - Serialization and deserialization on different versions of JDK. Thanks for clarifying. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1917573088 From psadhukhan at openjdk.org Thu Jan 16 03:22:35 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 16 Jan 2025 03:22:35 GMT Subject: RFR: 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete In-Reply-To: References: Message-ID: <3xLNU2sPc8ainPioX3UpySsSeSj8YuLNi_vDTMW2xak=.97bae194-a0b1-4c1f-9c05-2af443001798@github.com> On Wed, 15 Jan 2025 09:45:33 GMT, Prasanta Sadhukhan wrote: > This manual test draws a "custom" Caret which is to be placed in the same position between characters but it is seen the movement of caret leaves artifacts. Custom caret is rendering 2 horizontal and 1 vertical line to render "capital I" but horizontal lines repainting is not done properly. > If the test is made to use Swing DefaultCaret implementation, no artifacts is seen. Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. Also, added 1 extra pixel in repainting logic to tackle caretWidth,height. > Tested against windows, linux and mac where it renders ok and movement of caret does not leave any artifacts. Usually caret are normally vertical lines so "damage" routine repaints caret based on that as caret width will be of 1-2 pixel wide but this custom caret also draws 2 horizontal lines on top and below of vertical but "damage" does not take care of that, it seems. Also, since the test is about caret placement and not caret shape, even Swing DefaultCaret would have sufficed but I have retained its CustomCaret usgae but removed the problematic horizontal line rendering.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23129#issuecomment-2594394753 From psadhukhan at openjdk.org Thu Jan 16 04:10:49 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 16 Jan 2025 04:10:49 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser In-Reply-To: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: On Wed, 15 Jan 2025 09:30:03 GMT, Abhishek Kumar wrote: > There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. test/jdk/javax/swing/JColorChooser/Test8152419.java line 46: > 44: import javax.swing.border.EmptyBorder; > 45: > 46: import jtreg.SkippedException; jtreg tag @library needs to be added for this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23128#discussion_r1917634705 From jwaters at openjdk.org Thu Jan 16 06:26:42 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 16 Jan 2025 06:26:42 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: <5XRcWQcD4HXfxVBm2VNpGKW0v4fcOZr8Im89dbVpjxs=.6d801f2d-3cb4-445e-ab6b-7b8119240a19@github.com> On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'openjdk:master' into accessibility > - Cast to void in AccessBridgeCalls.c > - static_cast to void in jaccessinspector.cpp > - Formatting changes in AccessBridgeEventHandler.cpp > - Merge branch 'master' into accessibility > - Remove now unused result > - Merge branch 'master' into accessibility > - 8342870 Anyone? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21656#issuecomment-2594629260 From aturbanov at openjdk.org Thu Jan 16 11:41:39 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 16 Jan 2025 11:41:39 GMT Subject: Integrated: 8347370: Unnecessary Hashtable usage in javax.swing.text.html.HTML In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:13:31 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.HTML.scMapping` is modified only within `` block. > We can replace it with immutable map to avoid Hashtable synchronization overhead. This pull request has now been integrated. Changeset: 24de9dee Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/24de9dee80738fe6ab1fc726b071546c85bbf79a Stats: 20 lines in 1 file changed: 10 ins; 8 del; 2 mod 8347370: Unnecessary Hashtable usage in javax.swing.text.html.HTML Reviewed-by: aivanov, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/21842 From jdv at openjdk.org Thu Jan 16 11:57:12 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 16 Jan 2025 11:57:12 GMT Subject: RFR: 8347911: Limit the length of inflated text chunks Message-ID: In PNG we have non-essential compressed text chunks zTXt and iTXt, which can consume considerable amount of memory when they contain large amount of compressed data. We should restrict the amount of text data we want to decompress from these text chunks. This PR adds limit of 256k bytes of inflated data from each of zTXt/iTXt chunks. There is no regression test because we need PNG file with large amount of compressed data to hit the limit. ------------- Commit messages: - 8347911: Limit the length of inflated text chunks Changes: https://git.openjdk.org/jdk/pull/23148/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347911 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23148/head:pull/23148 PR: https://git.openjdk.org/jdk/pull/23148 From aturbanov at openjdk.org Thu Jan 16 12:13:12 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 16 Jan 2025 12:13:12 GMT Subject: RFR: 8347916: Simplify javax.swing.text.html.CSS.LengthUnit.getValue Message-ID: Static and non-static `CSS.LengthUnit.getValue` methods essentially do the same thing. https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3085-L3096 https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3098-L3108 1. delegate one to another to reduce code duplication. 2. use primitive `boolean` type as parameter to avoid boxing 3. take advantage of `Map.getOrDefault()` to simplify code futher ------------- Commit messages: - [PATCH] Simplify javax.swing.text.html.CSS.LengthUnit.getValue Changes: https://git.openjdk.org/jdk/pull/21833/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21833&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347916 Stats: 20 lines in 1 file changed: 2 ins; 14 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21833/head:pull/21833 PR: https://git.openjdk.org/jdk/pull/21833 From mbaesken at openjdk.org Thu Jan 16 15:36:54 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Jan 2025 15:36:54 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v5] In-Reply-To: References: Message-ID: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust Windows output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23076/files - new: https://git.openjdk.org/jdk/pull/23076/files/502043e6..5dc8b212 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23076&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23076.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23076/head:pull/23076 PR: https://git.openjdk.org/jdk/pull/23076 From mdoerr at openjdk.org Thu Jan 16 15:40:40 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 16 Jan 2025 15:40:40 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v5] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 15:36:54 GMT, Matthias Baesken wrote: >> When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust Windows output LGTM. Thanks for the update! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23076#pullrequestreview-2556531460 From mbaesken at openjdk.org Thu Jan 16 16:33:39 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Jan 2025 16:33:39 GMT Subject: RFR: 8347576: Error output in libjsound has non matching format strings [v5] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 15:36:54 GMT, Matthias Baesken wrote: >> When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust Windows output Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23076#issuecomment-2596177792 From mbaesken at openjdk.org Thu Jan 16 16:33:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 16 Jan 2025 16:33:40 GMT Subject: Integrated: 8347576: Error output in libjsound has non matching format strings In-Reply-To: References: Message-ID: <-zgC3xp4_IggfZrLChXcmBi9kMxbKU7VZ2rls_mcWr4=.8acad1cd-0faa-4cc0-b12c-a02200bc6cc7@github.com> On Mon, 13 Jan 2025 14:54:09 GMT, Matthias Baesken wrote: > When enabling the jsound ERROR and TRACE reporting (see src/java.desktop/share/native/libjsound/Configure.h https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32 ), we run into some build warnings as errors (when building on Linux) because at 2 places the format specifiers do not match the number types . This pull request has now been integrated. Changeset: 07a0dcba Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/07a0dcbabcb1216211c1da75f6dd2582da194df9 Stats: 13 lines in 4 files changed: 2 ins; 0 del; 11 mod 8347576: Error output in libjsound has non matching format strings Reviewed-by: mdoerr, serb, clanger ------------- PR: https://git.openjdk.org/jdk/pull/23076 From azvegint at openjdk.org Thu Jan 16 18:52:43 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 16 Jan 2025 18:52:43 GMT Subject: RFR: 8347916: Simplify javax.swing.text.html.CSS.LengthUnit.getValue In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:43:39 GMT, Andrey Turbanov wrote: > Static and non-static `CSS.LengthUnit.getValue` methods essentially do the same thing. > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3085-L3096 > > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3098-L3108 > > 1. delegate one to another to reduce code duplication. > 2. use primitive `boolean` type as parameter to avoid boxing > 3. take advantage of `Map.getOrDefault()` to simplify code futher Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21833#pullrequestreview-2556978174 From azvegint at openjdk.org Thu Jan 16 19:17:37 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 16 Jan 2025 19:17:37 GMT Subject: RFR: 8347911: Limit the length of inflated text chunks In-Reply-To: References: Message-ID: <1v1lMZJr1-QBEJ58sA7lol15SA0Ho-c__fIJuDjkeU8=.cf252445-e204-450a-9854-0badd4a0e30f@github.com> On Thu, 16 Jan 2025 11:52:14 GMT, Jayathirth D V wrote: > In PNG we have non-essential compressed text chunks zTXt and iTXt, which can consume considerable amount of memory when they contain large amount of compressed data. > > We should restrict the amount of text data we want to decompress from these text chunks. This PR adds limit of 256k bytes of inflated data from each of zTXt/iTXt chunks. > > There is no regression test because we need PNG file with large amount of compressed data to hit the limit. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23148#pullrequestreview-2557051173 From prr at openjdk.org Thu Jan 16 19:21:34 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 16 Jan 2025 19:21:34 GMT Subject: RFR: 8347911: Limit the length of inflated text chunks In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 11:52:14 GMT, Jayathirth D V wrote: > In PNG we have non-essential compressed text chunks zTXt and iTXt, which can consume considerable amount of memory when they contain large amount of compressed data. > > We should restrict the amount of text data we want to decompress from these text chunks. This PR adds limit of 256k bytes of inflated data from each of zTXt/iTXt chunks. > > There is no regression test because we need PNG file with large amount of compressed data to hit the limit. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23148#pullrequestreview-2557064797 From aivanov at openjdk.org Thu Jan 16 21:15:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 16 Jan 2025 21:15:36 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v4] In-Reply-To: <436Lmyuq3VrJBu6n8Ld3PFXSFBvn6-GG6n-dUgsftvY=.363f45fa-207c-41dc-b742-23a10bb04e30@github.com> References: <436Lmyuq3VrJBu6n8Ld3PFXSFBvn6-GG6n-dUgsftvY=.363f45fa-207c-41dc-b742-23a10bb04e30@github.com> Message-ID: <4E6tBHj-bNbQcuOTeyTrB3jxHwPjaIJWpGEJcMh_2ng=.1c754b9f-6905-45f7-80ed-c0a3cbf1f52e@github.com> On Wed, 15 Jan 2025 21:52:52 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update code according to the feedback in code review Looks good to me except for a tiny formatting nit. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2111: > 2109: > 2110: void AwtWindow::SetIconData(JNIEnv* env, jintArray iconRaster, jint w, jint h, > 2111: jintArray smallIconRaster, jint smw, jint smh) { I'd leave the opening brace where it is?on its own line. This style is followed in the entire file. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2557293428 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1919196008 From aivanov at openjdk.org Thu Jan 16 21:27:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 16 Jan 2025 21:27:35 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v2] In-Reply-To: References: Message-ID: <2fFpvaWRjx59Qhh7Djs3DdoOpnusgVI5ozUi3PcFZjw=.009ad468-e77b-4a48-823b-31f7ced20a91@github.com> On Tue, 7 Jan 2025 00:41:57 GMT, Harshitha Onkar wrote: > Is there a way to test this fix or possibly add a test case? @honkar-jdk I don't think it's possible to write a test for this case?. It my be tested by defining [`OUTOFMEM_TEST`](https://github.com/openjdk/jdk/blob/062f2dcfe5b62cc3dd3c292eeebd7a7ac78f849a/src/java.desktop/windows/native/libawt/windows/awt_new.cpp#L174C8-L174C21) in `awt_new.cpp` to enable random allocation failures. Another way could be to change the source code to explicitly cause `std::bad_alloc` and/or a Java exception in any of the called methods. Just to validate the suggested fix really works? on top of static code analysis. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22932#issuecomment-2596917931 From dholmes at openjdk.org Thu Jan 16 22:30:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Jan 2025 22:30:33 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 19:12:45 GMT, Gerard Ziemski wrote: > Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism. > > To use, you first need to record the pattern of operations, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar` > > This will run the target app, and log all the allocations in chronological order. This will produce a few files: > - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations) > - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state) > - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing) > > Now you can use those recording to actually benchmark your proposed changes, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10` > > Which will produce yet another file: > > - hs_nmt_pid23527_benchmark.log > > that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output. > > The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change. @gerard-ziemski we should not have a bunch of Java files for this in the hotspot source tree. Benchmarks should be in the test tree somewhere. Can this not be integrated into existing benchmark frameworks i.e. JMH? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2597036137 From dholmes at openjdk.org Thu Jan 16 22:43:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Jan 2025 22:43:37 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 19:12:45 GMT, Gerard Ziemski wrote: > Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism. > > To use, you first need to record the pattern of operations, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar` > > This will run the target app, and log all the allocations in chronological order. This will produce a few files: > - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations) > - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state) > - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing) > > Now you can use those recording to actually benchmark your proposed changes, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10` > > Which will produce yet another file: > > - hs_nmt_pid23527_benchmark.log > > that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output. > > The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change. I'm really not sure what this is actually trying to benchmark - who will be collecting this data and analysing it and what will they do with their results? That aside, generating the logs in a training run is okay, but the tool for processing those logs should reside elsewhere. A few initial passing comments. src/demo/share/jfc/J2Ddemo/java2d/Intro.java line 449: > 447: System.exit(0); > 448: } > 449: Scene scene = director.get(index); Leftover debugging code? src/hotspot/share/nmt/memLogRecorder.cpp line 27: > 25: // record pattern of allocations of memory calls: > 26: // > 27: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar You don't need the full paths in these examples src/hotspot/share/nmt/memLogRecorder.cpp line 43: > 41: // then to actually run the benchmark: > 42: // > 43: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=43100 -XX:NMTBenchmarkRecordedLoops=10 ?? How does this run anything - you haven't passed an initial class to the Java invocation? src/hotspot/share/nmt/memLogRecorder.cpp line 98: > 96: // ??? > 97: #endif > 98: pthread_mutex_init(&_mutex, NULL); You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work. src/hotspot/share/nmt/memLogRecorder.hpp line 37: > 35: #elif defined(WINDOWS) > 36: // ??? > 37: #endif You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23115#pullrequestreview-2557544778 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919324156 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919325893 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919328324 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919328661 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1919324004 From jdv at openjdk.org Fri Jan 17 04:05:38 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Fri, 17 Jan 2025 04:05:38 GMT Subject: Integrated: 8347911: Limit the length of inflated text chunks In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 11:52:14 GMT, Jayathirth D V wrote: > In PNG we have non-essential compressed text chunks zTXt and iTXt, which can consume considerable amount of memory when they contain large amount of compressed data. > > We should restrict the amount of text data we want to decompress from these text chunks. This PR adds limit of 256k bytes of inflated data from each of zTXt/iTXt chunks. > > There is no regression test because we need PNG file with large amount of compressed data to hit the limit. This pull request has now been integrated. Changeset: 398a5805 Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/398a580518b4e7961bdddf733e0a89ff25bc437a Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8347911: Limit the length of inflated text chunks Reviewed-by: azvegint, prr ------------- PR: https://git.openjdk.org/jdk/pull/23148 From psadhukhan at openjdk.org Fri Jan 17 06:20:40 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 17 Jan 2025 06:20:40 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v5] In-Reply-To: References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: On Mon, 13 Jan 2025 11:36:27 GMT, GennadiyKrivoshein wrote: >> **Description:** >> The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. >> The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 >> >> **Updates:** >> Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. >> >> **Tests:** >> Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. >> The test was run with the minimum possible margins. >> _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). >> _After the fix_: all lines are printed. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > Update test description test/jdk/javax/print/CUPSPrinterImageableAreaTest.java line 61: > 59: * @requires (os.family == "linux" | os.family == "mac") > 60: * @summary CUPSPrinter imageable area > 61: * @run main/manual CUPSPrinterImageableAreaTest For new manual test, it's better to use PassFailJFrame framework present in /java/awt/regtesthelpers...You can find several example of it in the repo.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22110#discussion_r1919616438 From duke at openjdk.org Fri Jan 17 11:15:17 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Fri, 17 Jan 2025 11:15:17 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v6] In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: Use PassFailJFrame ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22110/files - new: https://git.openjdk.org/jdk/pull/22110/files/339f383b..6e4811e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=04-05 Stats: 211 lines in 1 file changed: 73 ins; 122 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/22110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22110/head:pull/22110 PR: https://git.openjdk.org/jdk/pull/22110 From duke at openjdk.org Fri Jan 17 11:20:12 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Fri, 17 Jan 2025 11:20:12 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v7] In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: <7TjSqpznD8iWlfyDb3N3z7ymUpMMKEtclcHW4zQrz4M=.2ab71eb5-352e-45f0-8c17-f0e5471e6352@github.com> > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: remove trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22110/files - new: https://git.openjdk.org/jdk/pull/22110/files/6e4811e0..1682b903 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22110/head:pull/22110 PR: https://git.openjdk.org/jdk/pull/22110 From azvegint at openjdk.org Fri Jan 17 12:29:38 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 17 Jan 2025 12:29:38 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v4] In-Reply-To: <436Lmyuq3VrJBu6n8Ld3PFXSFBvn6-GG6n-dUgsftvY=.363f45fa-207c-41dc-b742-23a10bb04e30@github.com> References: <436Lmyuq3VrJBu6n8Ld3PFXSFBvn6-GG6n-dUgsftvY=.363f45fa-207c-41dc-b742-23a10bb04e30@github.com> Message-ID: On Wed, 15 Jan 2025 21:52:52 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update code according to the feedback in code review Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2558894206 From azvegint at openjdk.org Fri Jan 17 12:41:41 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 17 Jan 2025 12:41:41 GMT Subject: RFR: 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 09:45:33 GMT, Prasanta Sadhukhan wrote: > This manual test draws a "custom" Caret which is to be placed in the same position between characters but it is seen the movement of caret leaves artifacts. Custom caret is rendering 2 horizontal and 1 vertical line to render "capital I" but horizontal lines repainting is not done properly. > If the test is made to use Swing DefaultCaret implementation, no artifacts is seen. Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. Also, added 1 extra pixel in repainting logic to tackle caretWidth,height. > Tested against windows, linux and mac where it renders ok and movement of caret does not leave any artifacts. Marked as reviewed by azvegint (Reviewer). test/jdk/javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java line 226: > 224: g2d.draw(new Line2D.Float(c, cy, c, cy + ch)); > 225: g2d.draw(new Line2D.Float(cx, cy, cx + cw, cy)); > 226: g2d.draw(new Line2D.Float(cx, cy + ch, cx + cw, cy + ch)); > Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. I think we can still keep those lines, as it's kinda neat and presents a canonical caret look, and still works after applying the rest of the fix (I tried Linux and Windows). ------------- PR Review: https://git.openjdk.org/jdk/pull/23129#pullrequestreview-2558914355 PR Review Comment: https://git.openjdk.org/jdk/pull/23129#discussion_r1920132498 From dmarkov at openjdk.org Fri Jan 17 12:55:37 2025 From: dmarkov at openjdk.org (Dmitry Markov) Date: Fri, 17 Jan 2025 12:55:37 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v4] In-Reply-To: <436Lmyuq3VrJBu6n8Ld3PFXSFBvn6-GG6n-dUgsftvY=.363f45fa-207c-41dc-b742-23a10bb04e30@github.com> References: <436Lmyuq3VrJBu6n8Ld3PFXSFBvn6-GG6n-dUgsftvY=.363f45fa-207c-41dc-b742-23a10bb04e30@github.com> Message-ID: On Wed, 15 Jan 2025 21:52:52 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > Update code according to the feedback in code review Marked as reviewed by dmarkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2558942501 From psadhukhan at openjdk.org Fri Jan 17 12:57:45 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 17 Jan 2025 12:57:45 GMT Subject: Integrated: 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 09:45:33 GMT, Prasanta Sadhukhan wrote: > This manual test draws a "custom" Caret which is to be placed in the same position between characters but it is seen the movement of caret leaves artifacts. Custom caret is rendering 2 horizontal and 1 vertical line to render "capital I" but horizontal lines repainting is not done properly. > If the test is made to use Swing DefaultCaret implementation, no artifacts is seen. Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. Also, added 1 extra pixel in repainting logic to tackle caretWidth,height. > Tested against windows, linux and mac where it renders ok and movement of caret does not leave any artifacts. This pull request has now been integrated. Changeset: 15e06b61 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/15e06b61867a65c2b554efa6caf464b39ff8375a Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk/pull/23129 From psadhukhan at openjdk.org Fri Jan 17 12:57:45 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 17 Jan 2025 12:57:45 GMT Subject: RFR: 8345618: javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java leaves Caret is not complete In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 12:37:46 GMT, Alexander Zvegintsev wrote: >> This manual test draws a "custom" Caret which is to be placed in the same position between characters but it is seen the movement of caret leaves artifacts. Custom caret is rendering 2 horizontal and 1 vertical line to render "capital I" but horizontal lines repainting is not done properly. >> If the test is made to use Swing DefaultCaret implementation, no artifacts is seen. Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. Also, added 1 extra pixel in repainting logic to tackle caretWidth,height. >> Tested against windows, linux and mac where it renders ok and movement of caret does not leave any artifacts. > > test/jdk/javax/swing/text/Caret/8163124/CaretFloatingPointAPITest.java line 226: > >> 224: g2d.draw(new Line2D.Float(c, cy, c, cy + ch)); >> 225: g2d.draw(new Line2D.Float(cx, cy, cx + cw, cy)); >> 226: g2d.draw(new Line2D.Float(cx, cy + ch, cx + cw, cy + ch)); > >> Since the test is about placing of caret at same position between characters, a plain vertical caret is sufficient to test so removed the horizontal line rendering. > > I think we can still keep those lines, as it's kinda neat and presents a canonical caret look, and still works after applying the rest of the fix (I tried Linux and Windows). No, it leaves some artifact on macos so I decided to remove those.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23129#discussion_r1920148454 From davidalayachew at gmail.com Fri Jan 17 13:05:55 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 17 Jan 2025 08:05:55 -0500 Subject: Windows Magnifier does not work with my Swing applications In-Reply-To: References: Message-ID: Hello Phil, Did you get any more info about this issue? On Tue, Dec 17, 2024, 11:58?AM David Alayachew wrote: > Thanks Phil. > > Yeah, I am A-OK as long as this something that is looked into and the JBS > Bug Report is updated with the findings. If this isn't too bad, this would > be a solid inclusion. But if it's not worth the effort, I just want the JBS > to be updated, and then I can put that as an answer for my StackOverflow > post. > > Thanks again for taking a look into this. > > On Tue, Dec 17, 2024 at 11:56?AM Philip Race > wrote: > >> Perhaps .. if it is an easy fix but I do not know the specifics and the >> evaluator of that bug wrote >> "the magnifier cannot receive PropertyChangeEvents from Swing. This is a >> limitation in the Window magnifier. >> The Windows magnifier could be modified by Microsoft to receive such >> events but the work would need to be done by Microsoft." >> >> then went on to add that other magnifiers do work .. >> >> I also don't know how tied in this would be to implementing support for >> the Windows Accessibility API. >> >> Swing apps today use something called JavaAccessBridge and there are >> screen readers out there that support it. >> >> It would be good to have another look at this specific issue, but I can't >> make any promises. >> >> -phil. >> >> On 12/15/24 1:04 PM, David Alayachew wrote: >> >> Hello Client Libs Dev Team, >> >> My eyesite has started to deteriorate significantly, so I have been using >> the built-in Accessibility tool called Windows (Screen) Magnifier >> (available since Windows XP at least). It zooms in and out of the screen by >> pressing the Windows Key and (+) or (-). >> >> This works great because, as I type stuff, the magnifier will follow my >> text, so that I don't have to keep manually moving the magnifier whenever >> what I type inevitably ends up off-screen (off-view?). >> >> This feature works great for basically every other application I have, >> except my Swing apps. I make a lot of Swing apps, and I use a bunch too. >> And this Magnifier feature that follows text does not work for any of the >> ones I have tried. >> >> This feature does work on basically every other application I have. To >> name a few. >> >> * Notepad++ >> * WordPad >> * Firefox >> * Git Bash >> >> Here is a Bug Report referring to this problem. >> >> https://bugs.openjdk.org/browse/JDK-5079680 >> >> The resolution was listed as "Future Project". Any chance that the future >> can be now? >> >> I know that Swing is largely in maintenance mode, but if this were to get >> added, practically ALL Swing apps would receive a significant boost in >> accessibility. I think that's worth making some significant changes for. >> >> Finally, here is a StackOverflow post I made discussing the same subject. >> >> https://stackoverflow.com/questions/79281778 >> >> Thank you for your time. >> David Alayachew >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jan 17 14:03:42 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Fri, 17 Jan 2025 14:03:42 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v5] In-Reply-To: References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: On Fri, 17 Jan 2025 06:18:04 GMT, Prasanta Sadhukhan wrote: >> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test description > > test/jdk/javax/print/CUPSPrinterImageableAreaTest.java line 61: > >> 59: * @requires (os.family == "linux" | os.family == "mac") >> 60: * @summary CUPSPrinter imageable area >> 61: * @run main/manual CUPSPrinterImageableAreaTest > > For new manual test, it's better to use PassFailJFrame framework present in /java/awt/regtesthelpers...You can find several example of it in the repo.. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22110#discussion_r1920235367 From gziemski at openjdk.org Fri Jan 17 16:21:35 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 17 Jan 2025 16:21:35 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory In-Reply-To: References: Message-ID: <7qAPUArhTmcIGjvpoI_hxrE7Edm2FUruEK0UaVHQg3s=.82976906-0dc8-4e9a-964b-3983b8873715@github.com> On Thu, 16 Jan 2025 22:28:08 GMT, David Holmes wrote: > @gerard-ziemski we should not have a bunch of Java files for this in the hotspot source tree. Benchmarks should be in the test tree somewhere. Can this not be integrated into existing benchmark frameworks i.e. JMH? The java related files are totally optional and are example of one way to analyze the results. They are NOT in `hotspot`, they are in `src/utils`: # ls -la src/utils total 0 drwxr-xr-x 7 gerard staff 224 Jan 14 13:09 . drwxr-xr-x 76 gerard staff 2432 Jan 14 13:09 .. drwxr-xr-x 24 gerard staff 768 Jan 13 15:46 IdealGraphVisualizer drwxr-xr-x 7 gerard staff 224 Jan 13 15:46 LogCompilation drwxr-xr-x 8 gerard staff 256 Jan 13 15:46 hsdis drwxr-xr-x 18 gerard staff 576 Jan 14 14:47 nmt drwxr-xr-x 3 gerard staff 96 Jan 13 15:46 src together with other weird tools. There are only 2 new files in `src/hotspot/share/nmt`: `memLogRecorder.cpp` and `memLogRecorder.hpp` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2598711069 From gziemski at openjdk.org Fri Jan 17 16:33:41 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 17 Jan 2025 16:33:41 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory In-Reply-To: References: Message-ID: <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com> On Thu, 16 Jan 2025 22:41:06 GMT, David Holmes wrote: > I'm really not sure what this is actually trying to benchmark - who will be collecting this data and analysing it and what will they do with their results? > > That aside, generating the logs in a training run is okay, but the tool for processing those logs should reside elsewhere. > > A few initial passing comments. Thank you David for taking a look - very appreciated! The processing tools are indeed somewhere else - `jdk/src/utils` This benchmark records chronologically all the `malloc/realloc/free` calls so teey ca be played back later, which allows developers to test their code before/after with respect to malloc calls to measure speed/memory usage. I believe it should be a requirement to run this benchmark with your changes both to look for speed, but also memory usage, ebfore checkign in anything (though we can start with NTM related code) It was already used successfully to optimize Treap. The main idea behind it is that you need to record the pattern only once (using some fancy expensive use case), then iterate quickly over your fix and test against that pattern, without needing to actually run that use case. > src/demo/share/jfc/J2Ddemo/java2d/Intro.java line 449: > >> 447: System.exit(0); >> 448: } >> 449: Scene scene = director.get(index); > > Leftover debugging code? Yes, it is. I wanted a way to quit Java2Demo at the exact same point. I will revert it. > src/hotspot/share/nmt/memLogRecorder.cpp line 43: > >> 41: // then to actually run the benchmark: >> 42: // >> 43: // ./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=43100 -XX:NMTBenchmarkRecordedLoops=10 > > ?? How does this run anything - you haven't passed an initial class to the Java invocation? We check for the flags when we initialize NMT and run only when NMTBenchmarkRecordedPID is set. > src/hotspot/share/nmt/memLogRecorder.hpp line 37: > >> 35: #elif defined(WINDOWS) >> 36: // ??? >> 37: #endif > > You need to use existing synchronization API here. Either Mutex or PlatformMutex depending on initialization constraints; maybe a Semaphore if the others can't work. Why do we need to use existing synchronization API here? IS it because we can deadlock by introducing a new lock? I have run the existing code many times, no deadlocks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2598729741 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1920446882 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1920445805 PR Review Comment: https://git.openjdk.org/jdk/pull/23115#discussion_r1920448480 From aivanov at openjdk.org Fri Jan 17 17:46:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 17 Jan 2025 17:46:39 GMT Subject: RFR: 8347916: Simplify javax.swing.text.html.CSS.LengthUnit.getValue In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:43:39 GMT, Andrey Turbanov wrote: > Static and non-static `CSS.LengthUnit.getValue` methods essentially do the same thing. > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3085-L3096 > > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3098-L3108 > > 1. delegate one to another to reduce code duplication. > 2. use primitive `boolean` type as parameter to avoid boxing > 3. take advantage of `Map.getOrDefault()` to simplify code futher Looks good. I'm running tests. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21833#pullrequestreview-2559614153 From rmahajan at openjdk.org Fri Jan 17 17:56:50 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 17 Jan 2025 17:56:50 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v5] In-Reply-To: References: Message-ID: > **Issue:** > AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. > > **Solution:** > I have added the exception handling code to take care that the handles are properly destroyed and not leaked. > > **Testing:** > I have tested the code to make sure there are no regressions caused by this. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: leave opening bracre as is ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22932/files - new: https://git.openjdk.org/jdk/pull/22932/files/e22d8119..505f804b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22932/head:pull/22932 PR: https://git.openjdk.org/jdk/pull/22932 From honkar at openjdk.org Fri Jan 17 17:56:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 17 Jan 2025 17:56:50 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v5] In-Reply-To: References: Message-ID: <33TSz1wktlf1SqJ1KjYgjTBJ3y1cMYx0HQvlC8PXyxo=.70e7b3ae-836a-4f51-8733-0dca5544b110@github.com> On Fri, 17 Jan 2025 17:54:07 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > leave opening bracre as is Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2559628474 From honkar at openjdk.org Fri Jan 17 17:56:51 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 17 Jan 2025 17:56:51 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v2] In-Reply-To: <2fFpvaWRjx59Qhh7Djs3DdoOpnusgVI5ozUi3PcFZjw=.009ad468-e77b-4a48-823b-31f7ced20a91@github.com> References: <2fFpvaWRjx59Qhh7Djs3DdoOpnusgVI5ozUi3PcFZjw=.009ad468-e77b-4a48-823b-31f7ced20a91@github.com> Message-ID: On Thu, 16 Jan 2025 21:25:25 GMT, Alexey Ivanov wrote: > It my be tested by defining [`OUTOFMEM_TEST`](https://github.com/openjdk/jdk/blob/062f2dcfe5b62cc3dd3c292eeebd7a7ac78f849a/src/java.desktop/windows/native/libawt/windows/awt_new.cpp#L174C8-L174C21) in `awt_new.cpp` to enable random allocation failures. > > Another way could be to change the source code to explicitly cause `std::bad_alloc` and/or a Java exception in any of the called methods. Just to validate the suggested fix really works? on top of static code analysis. @aivanov-jdk Thanks for clarifying. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22932#issuecomment-2598884615 From rmahajan at openjdk.org Fri Jan 17 18:22:57 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 17 Jan 2025 18:22:57 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: References: Message-ID: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> > **Issue:** > AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. > > **Solution:** > I have added the exception handling code to take care that the handles are properly destroyed and not leaked. > > **Testing:** > I have tested the code to make sure there are no regressions caused by this. Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: check using not equal to NULL to match the rest of the code in the function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22932/files - new: https://git.openjdk.org/jdk/pull/22932/files/505f804b..2f47a554 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22932&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22932/head:pull/22932 PR: https://git.openjdk.org/jdk/pull/22932 From aivanov at openjdk.org Fri Jan 17 18:40:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 17 Jan 2025 18:40:42 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> Message-ID: <5h-8qAl0A7Gc8M-9RIyruonQEY_wsb5hCK6PJ0vT3Q8=.7561c2c9-a4c7-452f-84ed-eba964fbe8d6@github.com> On Fri, 17 Jan 2025 18:22:57 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > check using not equal to NULL to match the rest of the code in the function Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2559734852 From prr at openjdk.org Fri Jan 17 22:45:37 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 17 Jan 2025 22:45:37 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> Message-ID: <3tGyzFvrusJR4b2edH8C3d1ni7GgrNbi2BDj2JxtS2U=.0f06637a-e194-4b8e-acc0-0f23955a8de6@github.com> On Fri, 17 Jan 2025 18:22:57 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > check using not equal to NULL to match the rest of the code in the function Although this leak is extremely unlikely, leaks of GDI resources can bring even a modern windows system to its knees in a matter of seconds .. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2115: > 2113: HICON hNewIcon = NULL; > 2114: HICON hNewIconSm = NULL; > 2115: I presume we know for sure there's no exception pending when we enter ? Looking at the only caller, it seems probable. src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2147: > 2145: HICON hOldIcon = NULL; > 2146: HICON hOldIconSm = NULL; > 2147: if ((m_hIcon != NULL) && !m_iconInherited) { I am not sure why the check for NULL is needed .. but it is OK. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2560101616 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1920838476 PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1920839867 From rmahajan at openjdk.org Fri Jan 17 23:39:38 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Fri, 17 Jan 2025 23:39:38 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: <3tGyzFvrusJR4b2edH8C3d1ni7GgrNbi2BDj2JxtS2U=.0f06637a-e194-4b8e-acc0-0f23955a8de6@github.com> References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> <3tGyzFvrusJR4b2edH8C3d1ni7GgrNbi2BDj2JxtS2U=.0f06637a-e194-4b8e-acc0-0f23955a8de6@github.com> Message-ID: On Fri, 17 Jan 2025 22:40:09 GMT, Phil Race wrote: >> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: >> >> check using not equal to NULL to match the rest of the code in the function > > src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2115: > >> 2113: HICON hNewIcon = NULL; >> 2114: HICON hNewIconSm = NULL; >> 2115: > > I presume we know for sure there's no exception pending when we enter ? > Looking at the only caller, it seems probable. Are you suggesting we add a JNU_CHECK_EXCEPTION the beginning of the function? , as I don't think we know for sure there is an exception pending or not at this point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1920874523 From honkar at openjdk.org Fri Jan 17 23:58:52 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 17 Jan 2025 23:58:52 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v6] In-Reply-To: References: Message-ID: > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: moved verifyHeader() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/82436871..04880f66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=04-05 Stats: 10 lines in 2 files changed: 4 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From honkar at openjdk.org Sat Jan 18 00:04:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 18 Jan 2025 00:04:40 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 19:15:32 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 795: >> >>> 793: } >>> 794: >>> 795: if (p != null) { >> >> If it possible to get null here we should thrown an exception, but I think we thrown that exception already in the native. > > it is probably better to add this validation into ProfileDataVerifier.verify(data), and check it even before .getModule().loadProfile(data) @mrserb I have changed it so that verifyHeader is called before `CMSManager.getModule().loadProfile(data);` Validation checks cannot be moved to ProfileDataVerifier without making verifyHeader() public. NOTE: ProfileDataVerifier.verify() verifies entire profile data and not just the header and at this point we have not created a profile yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920884419 From honkar at openjdk.org Sat Jan 18 00:04:41 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 18 Jan 2025 00:04:41 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: <-nQZDCDj9hHsSMssDW0rKVqikuyK1T6SSLnICLVpw5k=.c2fcb380-1cd2-439a-8724-c00d677e3d81@github.com> On Tue, 14 Jan 2025 20:03:47 GMT, Alexey Ivanov wrote: > Interesting, this exception is not specified for this method. We were not able follow what you mean, can you please elaborate? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920885130 From honkar at openjdk.org Sat Jan 18 00:04:42 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 18 Jan 2025 00:04:42 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Tue, 14 Jan 2025 17:57:39 GMT, Sergey Bylokhov wrote: >>>The cooked approach doesn't work for ICC_Profile header data. In case header data is updated using the cooked approach we run into IAE- cannot write tag data for both invalid as well as valid header field values. >> >> maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods? >> >> for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?: >> >> **void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);** >> >> Sets the color space signature in profile header, using ICC convention. >> Parameters: >> hProfile: Handle to a profile object >> sig: any cmsColorSpaceSignature from Table 10 >> Returns: >> *None* >> >> https://www.littlecms.com/LittleCMS2.16%20API.pdf > > probably the answer will be that not all profiles are used for transformation, and just to read some of its properties it is not necessary to reject unexpected data such as intent/etc. @mrserb The location mentioned in LCMSTransform involves creating a new color space transform using 2 or more profiles and DOES NOT involve creating or updating a profile. Moreover LCMSTrandorm throws CMMException for invalid rendering intents so this case won't be an issue. > maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods? We are choosing to add these validation checks to jdk irrespective for whether lcms validates or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920884736 From honkar at openjdk.org Sat Jan 18 00:04:43 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 18 Jan 2025 00:04:43 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 17:59:26 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData.java line 39: > >> 37: >> 38: public class ValidateICCHeaderData { >> 39: private static ICC_Profile profile; > > the change will also affect serialization, the test should check that code path. @mrserb > the change will also affect serialization, the test should check that code path. Please check @prrace response above ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920884911 From honkar at openjdk.org Sat Jan 18 00:08:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 18 Jan 2025 00:08:36 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v6] In-Reply-To: References: Message-ID: <2vQ08gStf3v3ZlvKrffBPj6O6dKq3uej8so1__ss0HI=.b9947eef-5335-40fc-bbb2-56db9113eccc@github.com> On Fri, 17 Jan 2025 23:58:52 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > moved verifyHeader() src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 791: > 789: try { > 790: byte[] theHeader = new byte[HEADER_SIZE]; > 791: System.arraycopy(data, 0, theHeader, 0, HEADER_SIZE); We won't run into ArrayIndexOutOfBoundsException here since the incoming data array size is already being verified in ProfileDataVerifier.verify(data). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920886673 From honkar at openjdk.org Sat Jan 18 00:11:35 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 18 Jan 2025 00:11:35 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v6] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 23:58:52 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > moved verifyHeader() @mrserb Can you please re-review the latest code and comments? ------------- PR Review: https://git.openjdk.org/jdk/pull/23044#pullrequestreview-2560178339 From prr at openjdk.org Sat Jan 18 00:16:35 2025 From: prr at openjdk.org (Phil Race) Date: Sat, 18 Jan 2025 00:16:35 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Sat, 18 Jan 2025 00:01:31 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData.java line 39: >> >>> 37: >>> 38: public class ValidateICCHeaderData { >>> 39: private static ICC_Profile profile; >> >> the change will also affect serialization, the test should check that code path. > > @mrserb >> the change will also affect serialization, the test should check that code path. > > Please check @prrace response above What you could do is add a test to prove that deserialisation WILL fail. You'd need to create a bad profile and save it on JDK 21 - offline so to speak. Then write a simple test for this release that loads that icc.ser file and verify it is rejected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920890116 From honkar at openjdk.org Sat Jan 18 00:32:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sat, 18 Jan 2025 00:32:36 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: On Sat, 18 Jan 2025 00:14:23 GMT, Phil Race wrote: >> @mrserb >>> the change will also affect serialization, the test should check that code path. >> >> Please check @prrace response above > > What you could do is add a test to prove that deserialisation WILL fail. > You'd need to create a bad profile and save it on JDK 21 - offline so to speak. > Then write a simple test for this release that loads that icc.ser file and verify it is rejected. @prrace Thank you. Good way to test deserialization path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920896903 From duke at openjdk.org Sat Jan 18 01:34:52 2025 From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Sat, 18 Jan 2025 01:34:52 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v12] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: On Thu, 12 Dec 2024 00:05:33 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Update to lastest > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Remove tab > - Update to latest and make code safer > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - ... and 1 more: https://git.openjdk.org/jdk/compare/a20b6ccf...0ab7a467 I will give a result those days ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2599454426 From duke at openjdk.org Sat Jan 18 02:16:56 2025 From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=) Date: Sat, 18 Jan 2025 02:16:56 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v12] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: On Thu, 12 Dec 2024 00:05:33 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Update to lastest > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Remove tab > - Update to latest and make code safer > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - ... and 1 more: https://git.openjdk.org/jdk/compare/32b4ab36...0ab7a467 https://github.com/canonical/ubuntu.com/issues/14600 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2599473491 From gziemski at openjdk.org Sat Jan 18 14:20:46 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 18 Jan 2025 14:20:46 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory [v2] In-Reply-To: References: Message-ID: > Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism. > > To use, you first need to record the pattern of operations, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar` > > This will run the target app, and log all the allocations in chronological order. This will produce a few files: > - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations) > - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state) > - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing) > > Now you can use those recording to actually benchmark your proposed changes, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10` > > Which will produce yet another file: > > - hs_nmt_pid23527_benchmark.log > > that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output. > > The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change. Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: skip if not using ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23115/files - new: https://git.openjdk.org/jdk/pull/23115/files/a83389ab..a925e3d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=00-01 Stats: 15 lines in 1 file changed: 6 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115 PR: https://git.openjdk.org/jdk/pull/23115 From gziemski at openjdk.org Sat Jan 18 14:24:17 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 18 Jan 2025 14:24:17 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory [v3] In-Reply-To: References: Message-ID: > Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism. > > To use, you first need to record the pattern of operations, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar` > > This will run the target app, and log all the allocations in chronological order. This will produce a few files: > - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations) > - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state) > - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing) > > Now you can use those recording to actually benchmark your proposed changes, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10` > > Which will produce yet another file: > > - hs_nmt_pid23527_benchmark.log > > that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output. > > The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change. Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: move the optional tool into it's own issue/PR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23115/files - new: https://git.openjdk.org/jdk/pull/23115/files/a925e3d5..cf8acc0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=01-02 Stats: 2461 lines in 16 files changed: 0 ins; 2461 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115 PR: https://git.openjdk.org/jdk/pull/23115 From gziemski at openjdk.org Sat Jan 18 14:29:17 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 18 Jan 2025 14:29:17 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory [v4] In-Reply-To: References: Message-ID: > Here is another, hopefully, closer to the final iteration of NMT benchmarking mechanism. > > To use, you first need to record the pattern of operations, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTRecordMemoryAllocations=0x7FFFFFFF -jar build/macosx-aarch64-server-release/images/jdk/demo/jfc/J2Ddemo/J2Ddemo.jar` > > This will run the target app, and log all the allocations in chronological order. This will produce a few files: > - hs_nmt_pid22770_allocs_record.log (is the chronological record of the the desired operations) > - hs_nmt_pid22770_info_record.log (is the record of default NMT memory overhead and the NMT state) > - hs_nmt_pid22770_threads_record.log (is the record of thread names that can be retrieved later when processing) > > Now you can use those recording to actually benchmark your proposed changes, ex: > > `./build/macosx-aarch64-server-release/xcode/build/jdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:NMTBenchmarkRecordedPID=22770 -XX:NMTBenchmarkRecordedLoops=10` > > Which will produce yet another file: > > - hs_nmt_pid23527_benchmark.log > > that contains the details of the session, which can be further processed and analyzed by a tool, such as the one in jdk/src/utils/nmt, however, if you are looking just for one performance number look for `time:2744190[ns] [samples:115263]` in the output. > > The total time for this particular run is 2,744,190 nanosecond or ~2.7 seconds, which you can use to compare `before` and `after` your change. Gerard Ziemski has updated the pull request incrementally with two additional commits since the last revision: - undo white change - undo debug change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23115/files - new: https://git.openjdk.org/jdk/pull/23115/files/cf8acc0a..6c8c054f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23115&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23115/head:pull/23115 PR: https://git.openjdk.org/jdk/pull/23115 From stuefe at openjdk.org Sat Jan 18 15:57:35 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 18 Jan 2025 15:57:35 GMT Subject: RFR: 8317453: NMT: Performance benchmarks are needed to measure speed and memory [v4] In-Reply-To: <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com> References: <0F-hmvA2znP4UdDXpWOwtLNkqZEyABBcjZvkYr3NbiY=.20ae56b2-1c1e-4e0b-8a51-117e5c7f1755@github.com> Message-ID: <49spRgXYoY8YnH7s0q7-fbAQjqwMWCN3HEV6-th1QGw=.cceb034f-33bf-48e3-8d45-8b2c2d163bb5@github.com> On Fri, 17 Jan 2025 16:27:40 GMT, Gerard Ziemski wrote: > I'm really not sure what this is actually trying to benchmark - who will be collecting this data and analysing it and what will they do with their results? +1. Gerard, could provide a description of what this benchmark does, without having to analyze the patch? Neither text nor jbs text seem to explain that. How does this replay mechanism work, and why no simpler alternative? Basic first question, what exactly is replayed? the recordings, or the recordings + allocations themselves? If the former, why not just measure NMT overhead by comparing NMT on with off? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23115#issuecomment-2599767212 From duke at openjdk.org Sun Jan 19 20:30:35 2025 From: duke at openjdk.org (Jason Mehrens) Date: Sun, 19 Jan 2025 20:30:35 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v3] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 21:33:16 GMT, Phil Race wrote: >It is quite possible that we need to figure out what is going on with PointerInfo and fix something there first .. Not moving the mouse and locking the desktop can set X value larger the the display. See: https://bugs.openjdk.org/browse/JDK-6840067 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2601009901 From azvegint at openjdk.org Mon Jan 20 01:08:01 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 20 Jan 2025 01:08:01 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: References: Message-ID: <85SFmU5RZ1OMd9s2gg46q_7HcylQhOMpBtnrJmhQuH0=.a0a61bb2-e81d-42e6-b9ce-5b2ff7ca7c78@github.com> > The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. > > The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. > > This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. > > The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. Alexander Zvegintsev 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: - Popup may not be dismissed if there are multiple focusable components - NestedFocusablePopupTest review comments - Merge branch 'master' into 8342096_nested_popup - 8342096: Popup menus that request focus are not shown on Linux with Wayland ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22729/files - new: https://git.openjdk.org/jdk/pull/22729/files/2ee38b7d..b60a3326 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=00-01 Stats: 64441 lines in 2591 files changed: 32039 ins; 21008 del; 11394 mod Patch: https://git.openjdk.org/jdk/pull/22729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22729/head:pull/22729 PR: https://git.openjdk.org/jdk/pull/22729 From azvegint at openjdk.org Mon Jan 20 01:08:01 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 20 Jan 2025 01:08:01 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: References: Message-ID: <33Y5-ZPHAEBEv1_3fv9AW0MoUdvsOTDzC3xnIdJFMb8=.49a266f9-c7bd-4b44-834a-f4d7c36eac69@github.com> On Fri, 13 Dec 2024 22:12:58 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 550: >> >>> 548: addWaylandWindowFocusListenerToWindow(oppositeWindow); >>> 549: return; >>> 550: } >> >> So it's possible now that several windows in a hierarchy will have the listener added? Won't the listener be leaked? In other words, do we always remove the listener? > > As far as my tests with an instrumented build show - yes, but I discovered another case not covered: > > > for (int i = 0; i <= 1; i++) { > JMenu menu = new JMenu("Menu " + i); > menu.add(new JTextField("JTextField " + i)); > popupMenu.add(menu); > } > > > Clicking on gnome text editor does not hide the menu if the second menu is open. I do have a fix for it, but will not rush to post it, as I do not have enough time to test it thoroughly. > I will move this PR to draft status as I will be on vacation starting next week. Updated to cover this case by adding the listener to all owned windows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1921680298 From azvegint at openjdk.org Mon Jan 20 01:53:43 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 20 Jan 2025 01:53:43 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: <85SFmU5RZ1OMd9s2gg46q_7HcylQhOMpBtnrJmhQuH0=.a0a61bb2-e81d-42e6-b9ce-5b2ff7ca7c78@github.com> References: <85SFmU5RZ1OMd9s2gg46q_7HcylQhOMpBtnrJmhQuH0=.a0a61bb2-e81d-42e6-b9ce-5b2ff7ca7c78@github.com> Message-ID: On Mon, 20 Jan 2025 01:08:01 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev 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: > > - Popup may not be dismissed if there are multiple focusable components > - NestedFocusablePopupTest review comments > - Merge branch 'master' into 8342096_nested_popup > - 8342096: Popup menus that request focus are not shown on Linux with Wayland BTW, while testing this issue, I discovered another popup menu issue, where a popup window may close immediately after it appears on Linux. It is unrelated to this fix and reproducible only on Linux (Xorg, XWayland) with all supported JDKs, for more info see [JDK-8348041](https://bugs.openjdk.org/browse/JDK-8348041). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22729#issuecomment-2601162730 From aivanov at openjdk.org Mon Jan 20 12:16:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 12:16:37 GMT Subject: RFR: 8347916: Simplify javax.swing.text.html.CSS.LengthUnit.getValue In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:43:39 GMT, Andrey Turbanov wrote: > Static and non-static `CSS.LengthUnit.getValue` methods essentially do the same thing. > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3085-L3096 > > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3098-L3108 > > 1. delegate one to another to reduce code duplication. > 2. use primitive `boolean` type as parameter to avoid boxing > 3. take advantage of `Map.getOrDefault()` to simplify code futher The tests are green, too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21833#issuecomment-2602265953 From aturbanov at openjdk.org Mon Jan 20 12:57:40 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 20 Jan 2025 12:57:40 GMT Subject: RFR: 8347916: Simplify javax.swing.text.html.CSS.LengthUnit.getValue In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:43:39 GMT, Andrey Turbanov wrote: > Static and non-static `CSS.LengthUnit.getValue` methods essentially do the same thing. > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3085-L3096 > > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3098-L3108 > > 1. delegate one to another to reduce code duplication. > 2. use primitive `boolean` type as parameter to avoid boxing > 3. take advantage of `Map.getOrDefault()` to simplify code futher Thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21833#issuecomment-2602356345 From aturbanov at openjdk.org Mon Jan 20 12:57:41 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 20 Jan 2025 12:57:41 GMT Subject: Integrated: 8347916: Simplify javax.swing.text.html.CSS.LengthUnit.getValue In-Reply-To: References: Message-ID: <7IwnRuh6Wj84nDt43mKD7LN1KWB7WDf8UkgdAgLHoj4=.9e95bd88-16dc-4fa5-aed4-7204ac33a5c2@github.com> On Fri, 1 Nov 2024 14:43:39 GMT, Andrey Turbanov wrote: > Static and non-static `CSS.LengthUnit.getValue` methods essentially do the same thing. > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3085-L3096 > > https://github.com/openjdk/jdk/blob/751a914b0a377d4e1dd30d2501f0ab4e327dea34/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L3098-L3108 > > 1. delegate one to another to reduce code duplication. > 2. use primitive `boolean` type as parameter to avoid boxing > 3. take advantage of `Map.getOrDefault()` to simplify code futher This pull request has now been integrated. Changeset: 93469847 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/9346984725ed09e9917e825094b34c3a033af23e Stats: 20 lines in 1 file changed: 2 ins; 14 del; 4 mod 8347916: Simplify javax.swing.text.html.CSS.LengthUnit.getValue Reviewed-by: azvegint, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/21833 From abhiscxk at openjdk.org Mon Jan 20 13:07:19 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 20 Jan 2025 13:07:19 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser [v2] In-Reply-To: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: > There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: jtreg library tag added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23128/files - new: https://git.openjdk.org/jdk/pull/23128/files/98732088..f5f7df45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23128&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23128&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23128/head:pull/23128 PR: https://git.openjdk.org/jdk/pull/23128 From abhiscxk at openjdk.org Mon Jan 20 13:07:19 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 20 Jan 2025 13:07:19 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser [v2] In-Reply-To: References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: On Thu, 16 Jan 2025 04:07:31 GMT, Prasanta Sadhukhan wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> jtreg library tag added > > test/jdk/javax/swing/JColorChooser/Test8152419.java line 46: > >> 44: import javax.swing.border.EmptyBorder; >> 45: >> 46: import jtreg.SkippedException; > > jtreg tag @library needs to be added for this Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23128#discussion_r1922375414 From aivanov at openjdk.org Mon Jan 20 15:47:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 15:47:37 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> <3tGyzFvrusJR4b2edH8C3d1ni7GgrNbi2BDj2JxtS2U=.0f06637a-e194-4b8e-acc0-0f23955a8de6@github.com> Message-ID: On Fri, 17 Jan 2025 23:37:01 GMT, Rajat Mahajan wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2115: >> >>> 2113: HICON hNewIcon = NULL; >>> 2114: HICON hNewIconSm = NULL; >>> 2115: >> >> I presume we know for sure there's no exception pending when we enter ? >> Looking at the only caller, it seems probable. > > Are you suggesting we add a JNU_CHECK_EXCEPTION the beginning of the function? , as I don't think we know for sure there is an exception pending or not at this point. > I presume we know for sure there's no exception pending when we enter ? > Looking at the only caller, it seems probable. There can't be a pending exception when `AwtWindow::SetIconData` starts. The chain starts with JNI method [`Java_sun_awt_windows_WWindowPeer_setIconImagesData`](https://github.com/openjdk/jdk/blob/0fbf10a9cf51d01d82cd43cf0edfaeee83313a9c/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L3133) which calls [`AwtWindow::_SetIconImagesData`](https://github.com/openjdk/jdk/blob/0fbf10a9cf51d01d82cd43cf0edfaeee83313a9c/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L3149) wrapped in `SyncCall`. No Java code is called before execution gets into `SetIconData` where `CreateIconFromRaster` is called. > ?I don't think we know for sure there is an exception pending or not at this point. I'm sure there's no pending exception on the entry to `AwtWindow::SetIconData`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1922587897 From aivanov at openjdk.org Mon Jan 20 15:47:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 15:47:38 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: <3tGyzFvrusJR4b2edH8C3d1ni7GgrNbi2BDj2JxtS2U=.0f06637a-e194-4b8e-acc0-0f23955a8de6@github.com> References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> <3tGyzFvrusJR4b2edH8C3d1ni7GgrNbi2BDj2JxtS2U=.0f06637a-e194-4b8e-acc0-0f23955a8de6@github.com> Message-ID: On Fri, 17 Jan 2025 22:42:09 GMT, Phil Race wrote: >> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: >> >> check using not equal to NULL to match the rest of the code in the function > > src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2147: > >> 2145: HICON hOldIcon = NULL; >> 2146: HICON hOldIconSm = NULL; >> 2147: if ((m_hIcon != NULL) && !m_iconInherited) { > > I am not sure why the check for NULL is needed .. but it is OK. What do you mean? That it could've been just `if ((m_hIcon) && !m_iconInherited)`? This line is unchanged. In the majority of cases the surrounding code uses explicit `!= NULL` in `if`-statements. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22932#discussion_r1922591271 From aivanov at openjdk.org Mon Jan 20 15:58:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 15:58:38 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> Message-ID: On Fri, 17 Jan 2025 18:22:57 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > check using not equal to NULL to match the rest of the code in the function While I was looking deeper into the code flow, I found another place which needs changing. https://github.com/openjdk/jdk/blob/0fbf10a9cf51d01d82cd43cf0edfaeee83313a9c/src/java.desktop/windows/native/libawt/windows/awt_Taskbar.cpp#L126-L132 The JNI method `Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon` for `WTaskbarPeer.setOverlayIcon` calls `CreateIconFromRaster` that can throw a C++ exception. The call to `CreateIconFromRaster` has to be wrapped into a try-catch block to ensure the C++ exception does not escape. I think it's reasonable to address this new issue under a new bugid. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22932#issuecomment-2602772897 From aivanov at openjdk.org Mon Jan 20 16:28:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 16:28:38 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> Message-ID: On Mon, 20 Jan 2025 15:56:09 GMT, Alexey Ivanov wrote: > The call to `CreateIconFromRaster` has to be wrapped into a try-catch block to ensure the C++ exception does not escape. > > I think it's reasonable to address this new issue under a new bugid. I submitted [JDK-8282862](https://bugs.openjdk.org/browse/JDK-8348106): _Catch C++ exception in Java_sun_awt_windows_WTaskbarPeer_setOverlayIcon_. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22932#issuecomment-2602837621 From aivanov at openjdk.org Mon Jan 20 16:35:52 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 16:35:52 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v4] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 21:33:54 GMT, Phil Race wrote: > > Off topic: Is _?clamp?_ the right word for limiting mouse cursor coordinates to the virtual screen bounds? > > I think so, at least in programming it is used in this way. Did you have another word in mind ? You're right, it's used this way. I haven't come across such usage before. I'd use _?limit?_ or _?restrict?_. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2602851719 From aivanov at openjdk.org Mon Jan 20 16:39:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 16:39:40 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v3] In-Reply-To: References: Message-ID: On Sun, 19 Jan 2025 20:27:53 GMT, Jason Mehrens wrote: > > It is quite possible that we need to figure out what is going on with PointerInfo and fix something there first .. > > Not moving the mouse and locking the desktop can set X value larger the the display. See: https://bugs.openjdk.org/browse/JDK-6840067 This may still fail? unless we artificially ?move? the mouse pointer into the virtual screen bounds? even when the OS API returns coordinates which are out of bounds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2602860069 From aivanov at openjdk.org Mon Jan 20 17:18:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 17:18:39 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 11:23:29 GMT, Magnus Ihse Bursie wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > > 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 five commits: > > - Merge branch 'master' into dll-main-in-libawt > - Simplify patch > - Merge branch 'master' into dll-main-in-libawt > - Merge branch 'master' into dll-main-in-libawt > - 8346388: Cannot use DllMain in libawt for static builds Looks good to me. src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 108: > 106: * of a dynamic library build, or the .EXE in case of a static build. > 107: */ > 108: HMODULE GetAwtModuleHandle() { Should it be `static`? The function `GetAwtModuleHandle` isn't used outside of this translation unit and can be marked `static` to explicitly hide from other translation units unless it stops working. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22790#pullrequestreview-2562836866 PR Review Comment: https://git.openjdk.org/jdk/pull/22790#discussion_r1922665836 From aivanov at openjdk.org Mon Jan 20 17:29:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 17:29:38 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 11:23:29 GMT, Magnus Ihse Bursie wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > > 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 five commits: > > - Merge branch 'master' into dll-main-in-libawt > - Simplify patch > - Merge branch 'master' into dll-main-in-libawt > - Merge branch 'master' into dll-main-in-libawt > - 8346388: Cannot use DllMain in libawt for static builds > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since `DEF_JNI_OnLoad` is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means that the `JNI_OnLoad` function has never been called on Windows, but since it did not do anything of substance before, nobody noticed this.) I assumed that `JNI_OnLoad` would not be exported correctly if it were not declared with `extern "C"` modifier. At the same time, I see `JNI_OnLoad` in the list of exported functions from `awt.dll` in a recent build of JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2602952402 From aivanov at openjdk.org Mon Jan 20 17:37:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 17:37:42 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 11:23:29 GMT, Magnus Ihse Bursie wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > > 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 five commits: > > - Merge branch 'master' into dll-main-in-libawt > - Simplify patch > - Merge branch 'master' into dll-main-in-libawt > - Merge branch 'master' into dll-main-in-libawt > - 8346388: Cannot use DllMain in libawt for static builds > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Actually, when going over the backlog from my vacation, it looks like JDK-8346306 might fix this problem from the Hotspot side. I'll have to check that, and if so, this PR can be made much smaller. [JDK-8346306](https://bugs.openjdk.org/browse/JDK-8346306) is the reason why no destructors are modified anymore, is it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2602964285 From aivanov at openjdk.org Mon Jan 20 18:57:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 18:57:36 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser [v2] In-Reply-To: References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: On Mon, 20 Jan 2025 13:07:19 GMT, Abhishek Kumar wrote: >> There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > jtreg library tag added Looks good, except for minor comments. test/jdk/javax/swing/JColorChooser/Test8152419.java line 30: > 28: * @summary To Verify JColorChooser tab selection > 29: * @run main/manual Test8152419 > 30: */ Suggestion: /* * @test * @bug 8152419 * @library /test/lib * @summary To Verify JColorChooser tab selection * @run main/manual Test8152419 */ The formatting of the jtreg tags looks weird. Usually, the opening `/*` starts in the first column, and the following `*` are aligned to the first one. test/jdk/javax/swing/JColorChooser/Test8152419.java line 54: > 52: > 53: // ColorChooser UI design is different for GTK L&F. > 54: // There are no tabs available for GTK L&F, skip the testing. Suggestion: public static void main(String args[]) throws Exception { // ColorChooser UI design is different for GTK L&F. // There are no tabs in GTK L&F, skip the testing. No blank line at the start of a method; subtle change in comment. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23128#pullrequestreview-2563013799 PR Review Comment: https://git.openjdk.org/jdk/pull/23128#discussion_r1922767173 PR Review Comment: https://git.openjdk.org/jdk/pull/23128#discussion_r1922765997 From aivanov at openjdk.org Mon Jan 20 19:53:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 19:53:38 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: <85SFmU5RZ1OMd9s2gg46q_7HcylQhOMpBtnrJmhQuH0=.a0a61bb2-e81d-42e6-b9ce-5b2ff7ca7c78@github.com> References: <85SFmU5RZ1OMd9s2gg46q_7HcylQhOMpBtnrJmhQuH0=.a0a61bb2-e81d-42e6-b9ce-5b2ff7ca7c78@github.com> Message-ID: On Mon, 20 Jan 2025 01:08:01 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev 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: > > - Popup may not be dismissed if there are multiple focusable components > - NestedFocusablePopupTest review comments > - Merge branch 'master' into 8342096_nested_popup > - 8342096: Popup menus that request focus are not shown on Linux with Wayland src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 527: > 525: return false; > 526: } > 527: for (WindowFocusListener focusListener : window.getWindowFocusListeners()) { Suggestion: } for (WindowFocusListener focusListener : window.getWindowFocusListeners()) { I suggest adding a blank line to visually separate the early return logic from the common case one. test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 146: > 144: frame = new JFrame("NestedFocusablePopupTest"); > 145: JPanel panel = new JPanel(); > 146: panel.setPreferredSize(new Dimension(200,180)); Suggestion: panel.setPreferredSize(new Dimension(200, 180)); test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 153: > 151: getMenuWithMenuItem(true, "focusable subitem"); > 152: menuWithNonFocusableItem = > 153: getMenuWithMenuItem(false, "non focusable subitem"); Suggestion: getMenuWithMenuItem(false, "non-focusable subitem"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1922779957 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1922798224 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1922799389 From aivanov at openjdk.org Mon Jan 20 19:53:39 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 19:53:39 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: <33Y5-ZPHAEBEv1_3fv9AW0MoUdvsOTDzC3xnIdJFMb8=.49a266f9-c7bd-4b44-834a-f4d7c36eac69@github.com> References: <33Y5-ZPHAEBEv1_3fv9AW0MoUdvsOTDzC3xnIdJFMb8=.49a266f9-c7bd-4b44-834a-f4d7c36eac69@github.com> Message-ID: On Mon, 20 Jan 2025 01:00:26 GMT, Alexander Zvegintsev wrote: >> As far as my tests with an instrumented build show - yes, but I discovered another case not covered: >> >> >> for (int i = 0; i <= 1; i++) { >> JMenu menu = new JMenu("Menu " + i); >> menu.add(new JTextField("JTextField " + i)); >> popupMenu.add(menu); >> } >> >> >> Clicking on gnome text editor does not hide the menu if the second menu is open. I do have a fix for it, but will not rush to post it, as I do not have enough time to test it thoroughly. >> I will move this PR to draft status as I will be on vacation starting next week. > > Updated to cover this case by adding the listener to all owned windows. I'm still unconvinced the listener is always removed? Shouldn't the line below https://github.com/openjdk/jdk/blob/b60a33269247c1039fa0ec6cd99476c9f8976852/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L563 be changed to call `dismissPopupOnFocusLostIfNeededCleanUp` to remove the listener from the popup and its children? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1922788471 From aivanov at openjdk.org Mon Jan 20 19:53:40 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 19:53:40 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 22:14:31 GMT, Alexander Zvegintsev wrote: >> test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 53: >> >>> 51: //test is valid only when running on Wayland. >>> 52: return; >>> 53: } >> >> I think it should rather throw `jtreg.SkippedException`. >> >> With [jtreg enhancements](https://github.com/openjdk/jtreg/pull/217) and further reporting enhancements, we'll be able to see if tests aren't actually executed. > > Ok, but this test will lose the ability to run standalone with just `java NestedFocusablePopupTest.java`. It's an inconvenience which can be overcome by compiling the test and `SkippedException` together: javac -d ./build -cp ./build \ test/lib/jtreg/SkippedException.java \ test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java java -cp ./build NestedFocusablePopupTest The advantage is that the test will be reported as skipped if it isn't run when not in Wayland session. It could be not issue as more and more systems use Wayland session by default. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1922792552 From aivanov at openjdk.org Mon Jan 20 19:58:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 19:58:35 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: References: <33Y5-ZPHAEBEv1_3fv9AW0MoUdvsOTDzC3xnIdJFMb8=.49a266f9-c7bd-4b44-834a-f4d7c36eac69@github.com> Message-ID: <5G8aojnM5PfSbcoPMw031e81QfMKbCkHqJ6uPzqbvWI=.04447e9f-72ae-40d3-8147-d6e558f07ca8@github.com> On Mon, 20 Jan 2025 19:28:20 GMT, Alexey Ivanov wrote: >> Updated to cover this case by adding the listener to all owned windows. > > I'm still unconvinced the listener is always removed? > > Shouldn't the line below > > https://github.com/openjdk/jdk/blob/b60a33269247c1039fa0ec6cd99476c9f8976852/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L563 > > be changed to call `dismissPopupOnFocusLostIfNeededCleanUp` to remove the listener from the popup and its children? What if the window that loses focus is not the parent of the popup hierarchy? Or is it guaranteed that all the children of the popup window receive the focus lost event? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1922805022 From aivanov at openjdk.org Mon Jan 20 19:58:38 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 19:58:38 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v2] In-Reply-To: <85SFmU5RZ1OMd9s2gg46q_7HcylQhOMpBtnrJmhQuH0=.a0a61bb2-e81d-42e6-b9ce-5b2ff7ca7c78@github.com> References: <85SFmU5RZ1OMd9s2gg46q_7HcylQhOMpBtnrJmhQuH0=.a0a61bb2-e81d-42e6-b9ce-5b2ff7ca7c78@github.com> Message-ID: <1K3DeYGdjukE-Ms1Gd7gjgbkq_BJegSTCsC80ahNAL0=.8598afb1-1217-4b1f-b7b3-e07667424d0b@github.com> On Mon, 20 Jan 2025 01:08:01 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev 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: > > - Popup may not be dismissed if there are multiple focusable components > - NestedFocusablePopupTest review comments > - Merge branch 'master' into 8342096_nested_popup > - 8342096: Popup menus that request focus are not shown on Linux with Wayland src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 557: > 555: } > 556: owner = owner.getOwner(); > 557: } Suggestion: Window owner = window.getOwner(); while (owner != null) { if (owner == oppositeWindow) { return; } owner = owner.getOwner(); } I'd also add blank lines around this piece of code to break it into smaller pieces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1922803162 From aivanov at openjdk.org Mon Jan 20 21:26:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 21:26:42 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 70: > 68: graphicsEnvClass = (*env)->FindClass(env, > 69: "java/awt/GraphicsEnvironment"); > 70: CHECK_EXCEPTION_FATAL(env, "FindClass java/awt/GraphicsEnvironment failed"); If `FindClass` fails to find the class, a `NoClassDefFoundError` should be raised. This function returns immediately (a value of `true`). The caller of this function should check if there's a pending exception and perform an appropriate action. In this case, the function is called from https://github.com/openjdk/jdk/blob/955bf185c38ec0fcedb0a549461fc85367b37fbb/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L130-L132 If there's a pending exception, it should bail out and let the exception be thrown on the Java side. If it doesn't, the pending exception makes `JNU_NewStringPlatform` fail at https://github.com/openjdk/jdk/blob/955bf185c38ec0fcedb0a549461fc85367b37fbb/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L149-L150 --- Ah! There's no Java code to catch the exception? `AWT_OnLoad` is essentially `JNI_OnLoad`. In this case, `CHECK_EXCEPTION_FATAL` seems right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1922849674 From aivanov at openjdk.org Mon Jan 20 21:26:42 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 21:26:42 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 12:45:46 GMT, Karm Michal Babacek wrote: >> src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 83: >> >>> 81: headlessFn); >>> 82: // If an exception occurred, we assume headless mode. >>> 83: if ((*env)->ExceptionCheck(env)) { >> >> I don't like this at all. > > See [comment](https://github.com/openjdk/jdk/pull/20169#issuecomment-2247823182), please. Here, nothing has changed? except for the added comment which states what's done: if an exception occurred while calling `GraphicsEnvironment.isHeadless`, the `AWTIsHeadless` function returns `JNI_TRUE`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1922852985 From ihse at openjdk.org Mon Jan 20 21:34:38 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 20 Jan 2025 21:34:38 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:49:33 GMT, Alexey Ivanov wrote: >> 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 five commits: >> >> - Merge branch 'master' into dll-main-in-libawt >> - Simplify patch >> - Merge branch 'master' into dll-main-in-libawt >> - Merge branch 'master' into dll-main-in-libawt >> - 8346388: Cannot use DllMain in libawt for static builds > > src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 108: > >> 106: * of a dynamic library build, or the .EXE in case of a static build. >> 107: */ >> 108: HMODULE GetAwtModuleHandle() { > > Should it be `static`? The function `GetAwtModuleHandle` isn't used outside of this translation unit and can be marked `static` to explicitly hide from other translation units unless it stops working. Actually, this function needs to be **not** static for it to work -- it uses it's own address to look up the handle that contains it -- which will be awt.dll when running a normal, dynamic build, and the entire java.exe when running a static build. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22790#discussion_r1922859162 From ihse at openjdk.org Mon Jan 20 21:38:35 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 20 Jan 2025 21:38:35 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 17:27:25 GMT, Alexey Ivanov wrote: > I assumed that `JNI_OnLoad` would not be exported correctly if it were not declared with `extern "C"` modifier. At the same time, I see `JNI_OnLoad` in the list of exported functions from `awt.dll` in a recent build of JDK. Yeah, I dunno. I can't tell if we never run this, and it works anyway, or if we actually do run it despite not being declared `C`. In any case, all other instances of JNI_OnLoad is declared as `C`, so it will certainly not hurt. And, as I said in the comment, when compiling this for static builds it is necessary for the macro to work. > [JDK-8346306](https://bugs.openjdk.org/browse/JDK-8346306) is the reason why no destructors are modified anymore, is it? Correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2603259357 PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2603259612 From aivanov at openjdk.org Mon Jan 20 21:45:41 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 21:45:41 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v9] In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 19:54:17 GMT, Sergey Bylokhov wrote: >> src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 70: >> >>> 68: graphicsEnvClass = (*env)->FindClass(env, >>> 69: "java/awt/GraphicsEnvironment"); >>> 70: CHECK_EXCEPTION_FATAL(env, "java/awt/GraphicsEnvironment class not found"); >> >> Taking out any discussion about graal/etc as well as absent of any classes and methods, I agree that the current code is questionable. >> >> But the solution to always print "java/awt/GraphicsEnvironment class not found" does not seems to be correct as well. >> >> One of the problem with this code is an actual conflict between two patches. Both are related to warning caused by pending java exceptions, but implemented differently: >> - https://bugs.openjdk.org/browse/JDK-8031001: treated the java exceptions as a fatal errors and fail fast >> - https://bugs.openjdk.org/browse/JDK-8130507: ignores the java exceptions and tried to fallback into the headless mode in assumption that it may be fine for the application >> >> Both of that patches only changes the code paths which were reported by "some tools"/checkjni - this is the reason why the next code was not reported and was not patched(which is wrong): >> >> >> graphicsEnvClass = (*env)->FindClass(env, >> "java/awt/GraphicsEnvironment"); >> if (graphicsEnvClass == NULL) { >> return JNI_TRUE; >> } >> headlessFn = (*env)->GetStaticMethodID(env, >> graphicsEnvClass, "isHeadless", "()Z"); >> if (headlessFn == NULL) { >> return JNI_TRUE; >> } >> >> If we would like to follow JDK-8031001 approach we should use fatal error here and fail fast, for example if OOM is occurred. >> If we would like to follow JDK-8130507 we should clear an exceptions and try to use headless mode. >> >> I guess ignoring an exceptions is not that good and the fix for JDK-8130507 should be rethinking. > > You can change the CHECK_EXCEPTION_FATAL macro to something like > > #define CHECK_EXCEPTION_FATAL(env, message) \ > if ((*env)->ExceptionCheck(env)) { \ > (*env)->ExceptionDescribe(env); > (*env)->FatalError(env, message); \ > } > > In this case the root cause of the bug will always be printed. > And then update the fatal message to some generic text. > > Note that the FatalError is used in this code since we always should load the library(libawt_xawt or libawt_headless) or fail fast, otherwise we most probably will get an error later. @mrserb Perhaps, `ExceptionDescribe` isn't part of the `CHECK_EXCEPTION_FATAL` macro to avoid leaking sensitive information. Therefore, `ExceptionClear` which has been used previously is safer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1922864473 From aivanov at openjdk.org Mon Jan 20 21:50:37 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 20 Jan 2025 21:50:37 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: <0f78p-Zz3_KQHvclf-3N9o7X2a7Ngfo4WqX606YqtAs=.4005569c-6e8c-4e8b-90ca-d82217f3b34b@github.com> On Mon, 20 Jan 2025 21:32:17 GMT, Magnus Ihse Bursie wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 108: >> >>> 106: * of a dynamic library build, or the .EXE in case of a static build. >>> 107: */ >>> 108: HMODULE GetAwtModuleHandle() { >> >> Should it be `static`? The function `GetAwtModuleHandle` isn't used outside of this translation unit and can be marked `static` to explicitly hide from other translation units unless it stops working. > > Actually, this function needs to be **not** static for it to work -- it uses it's own address to look up the handle that contains it -- which will be awt.dll when running a normal, dynamic build, and the entire java.exe when running a static build. Yep. A static function could be optimised out? inlined. However, if the address of the function is taken, the function should remain as a stand-alone callable function. Adding `static` shouldn't remove the function, it just ensures the function name isn't visible to other .obj files. I'm not 100% sure, yet I think it should work correctly even when `GetAwtModuleHandle` is declared `static`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22790#discussion_r1922866918 From kizune at openjdk.org Mon Jan 20 23:21:41 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 20 Jan 2025 23:21:41 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'openjdk:master' into accessibility > - Cast to void in AccessBridgeCalls.c > - static_cast to void in jaccessinspector.cpp > - Formatting changes in AccessBridgeEventHandler.cpp > - Merge branch 'master' into accessibility > - Remove now unused result > - Merge branch 'master' into accessibility > - 8342870 src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c line 233: > 231: return TRUE; > 232: } > 233: ((void) error); Not sure why do we need it. I mean there is a value assignment before so why would compiler complain? src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 326: > 324: int regEnable() { > 325: HKEY hKey; > 326: // DWORD retval = -1; I don't think we need to comment out both retval and freeData. It is either remnants of the code that was long gone or (more likely) were just a copy of another template method that actually uses these variables. If variables are not used within the function i would just delete them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922905467 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922905577 From kizune at openjdk.org Mon Jan 20 23:38:38 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 20 Jan 2025 23:38:38 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'openjdk:master' into accessibility > - Cast to void in AccessBridgeCalls.c > - static_cast to void in jaccessinspector.cpp > - Formatting changes in AccessBridgeEventHandler.cpp > - Merge branch 'master' into accessibility > - Remove now unused result > - Merge branch 'master' into accessibility > - 8342870 src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 255: > 253: case WM_CREATE: > 254: RECT rcClient; // dimensions of client area > 255: // HWND hwndEdit; // handle of tree-view control Again, i would not remove or comment out variables assigned within the code - they might not be used down the line but in interactive debug session it is good to have them to see what was the result of the function call without stepping inside the function. I agree that removing the declarations of unused variables can be justified but this in my opinion is not the case. src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeJavaVMInstance.cpp line 271: > 269: DEBUG_CODE(if (*type == cGetAccessibleTextItemsPackage) {) > 270: DEBUG_CODE(AppendToCallInfo(" 'memoryMappedView' now contains:")); > 271: // DEBUG_CODE(GetAccessibleTextItemsPackage *pkg = (GetAccessibleTextItemsPackage *) (buffer + sizeof(PackageType))); Why do we need to comment out that? In non-debug build it will be replaced by the comment block anyways. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922911678 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922911741 From kizune at openjdk.org Tue Jan 21 00:05:34 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 21 Jan 2025 00:05:34 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser [v2] In-Reply-To: References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: On Mon, 20 Jan 2025 13:07:19 GMT, Abhishek Kumar wrote: >> There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > jtreg library tag added Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23128#pullrequestreview-2563250526 From jwaters at openjdk.org Tue Jan 21 00:37:43 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 21 Jan 2025 00:37:43 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 23:18:41 GMT, Alexander Zuev wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'openjdk:master' into accessibility >> - Cast to void in AccessBridgeCalls.c >> - static_cast to void in jaccessinspector.cpp >> - Formatting changes in AccessBridgeEventHandler.cpp >> - Merge branch 'master' into accessibility >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c line 233: > >> 231: return TRUE; >> 232: } >> 233: ((void) error); > > Not sure why do we need it. I mean there is a value assignment before so why would compiler complain? The error being cast to void is just there to mark that this was a place that the compiler flagged, as for the warning itself, apparently just assigning the value is not enough, as that yields a -Wunused-but-set-variable, it has to actually be used somehow or explicitly be cast to void to stop the warning altogether > src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 326: > >> 324: int regEnable() { >> 325: HKEY hKey; >> 326: // DWORD retval = -1; > > I don't think we need to comment out both retval and freeData. It is either remnants of the code that was long gone or (more likely) were just a copy of another template method that actually uses these variables. If variables are not used within the function i would just delete them. Will do, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922933515 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922933610 From jwaters at openjdk.org Tue Jan 21 00:42:40 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 21 Jan 2025 00:42:40 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: <5_HhRm4ISUSfn1hkKjvZdImdxm87KkDdFkueq_K-o08=.3c83fd01-5e8a-43f3-8cad-33886dc2fa45@github.com> On Mon, 20 Jan 2025 23:35:23 GMT, Alexander Zuev wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'openjdk:master' into accessibility >> - Cast to void in AccessBridgeCalls.c >> - static_cast to void in jaccessinspector.cpp >> - Formatting changes in AccessBridgeEventHandler.cpp >> - Merge branch 'master' into accessibility >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 255: > >> 253: case WM_CREATE: >> 254: RECT rcClient; // dimensions of client area >> 255: // HWND hwndEdit; // handle of tree-view control > > Again, i would not remove or comment out variables assigned within the code - they might not be used down the line but in interactive debug session it is good to have them to see what was the result of the function call without stepping inside the function. I agree that removing the declarations of unused variables can be justified but this in my opinion is not the case. If we had C++17 [[maybe_unused]] would be available to mark these instances so the compiler doesn't complain, but we're not there yet. As an alternative they can be cast to void (Like it was done above in AccessBridgeCalls.c). Could that be done instead? I do have doubts that the compilers will retain these locals when optimizations are turned on, but if that is the case, then I agree that these should not be removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922935414 From jwaters at openjdk.org Tue Jan 21 00:45:39 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 21 Jan 2025 00:45:39 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 23:35:33 GMT, Alexander Zuev wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'openjdk:master' into accessibility >> - Cast to void in AccessBridgeCalls.c >> - static_cast to void in jaccessinspector.cpp >> - Formatting changes in AccessBridgeEventHandler.cpp >> - Merge branch 'master' into accessibility >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > src/jdk.accessibility/windows/native/libwindowsaccessbridge/AccessBridgeJavaVMInstance.cpp line 271: > >> 269: DEBUG_CODE(if (*type == cGetAccessibleTextItemsPackage) {) >> 270: DEBUG_CODE(AppendToCallInfo(" 'memoryMappedView' now contains:")); >> 271: // DEBUG_CODE(GetAccessibleTextItemsPackage *pkg = (GetAccessibleTextItemsPackage *) (buffer + sizeof(PackageType))); > > Why do we need to comment out that? In non-debug build it will be replaced by the comment block anyways. In release builds this isn't an issue, but when building either fastdebug or slowdebug it fails as pkg is unused. Should this be removed or retained and marked explicitly so the compiler doesn't complain? I'm not sure whether this falls into the category of "Unused but useful to have in a debugger session" mentioned above ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1922937100 From psadhukhan at openjdk.org Tue Jan 21 03:38:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 21 Jan 2025 03:38:47 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v7] In-Reply-To: <7TjSqpznD8iWlfyDb3N3z7ymUpMMKEtclcHW4zQrz4M=.2ab71eb5-352e-45f0-8c17-f0e5471e6352@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> <7TjSqpznD8iWlfyDb3N3z7ymUpMMKEtclcHW4zQrz4M=.2ab71eb5-352e-45f0-8c17-f0e5471e6352@github.com> Message-ID: On Fri, 17 Jan 2025 11:20:12 GMT, GennadiyKrivoshein wrote: >> **Description:** >> The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. >> The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 >> >> **Updates:** >> Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. >> >> **Tests:** >> Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. >> The test was run with the minimum possible margins. >> _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). >> _After the fix_: all lines are printed. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > remove trailing whitespace test/jdk/javax/print/CUPSPrinterImageableAreaTest.java line 121: > 119: job.setPrintable(new RectPrintable(), pageFormat); > 120: try { > 121: job.print(); it now goes to default printer..maybe also give an option to show a printdialog and let user choose the printer..I guess choosing PDF-printer will not show the issue? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22110#discussion_r1923028045 From abhiscxk at openjdk.org Tue Jan 21 04:09:17 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 21 Jan 2025 04:09:17 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser [v3] In-Reply-To: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: <5QUtYLLYUQk673EcTgC-5KmPnDD1-Qx_Gt0wxdYDc8Y=.f2f83e05-0d2a-49bc-91ae-ee5ce037a491@github.com> > There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: Formatting changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23128/files - new: https://git.openjdk.org/jdk/pull/23128/files/f5f7df45..790ce7d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23128&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23128&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23128/head:pull/23128 PR: https://git.openjdk.org/jdk/pull/23128 From abhiscxk at openjdk.org Tue Jan 21 04:09:17 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 21 Jan 2025 04:09:17 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser [v2] In-Reply-To: References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: On Mon, 20 Jan 2025 18:54:01 GMT, Alexey Ivanov wrote: >> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> jtreg library tag added > > test/jdk/javax/swing/JColorChooser/Test8152419.java line 30: > >> 28: * @summary To Verify JColorChooser tab selection >> 29: * @run main/manual Test8152419 >> 30: */ > > Suggestion: > > /* > * @test > * @bug 8152419 > * @library /test/lib > * @summary To Verify JColorChooser tab selection > * @run main/manual Test8152419 > */ > > The formatting of the jtreg tags looks weird. > > Usually, the opening `/*` starts in the first column, and the following `*` are aligned to the first one. I saw that and then forget to change. Updated now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23128#discussion_r1923042388 From aturbanov at openjdk.org Tue Jan 21 09:27:09 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 21 Jan 2025 09:27:09 GMT Subject: RFR: 8348170: Unnecessary Hashtable usage in CSS.styleConstantToCssMap Message-ID: There is a field `javax.swing.text.html.CSS#styleConstantToCssMap` which uses legacy `Hashtable` class. As this map is read-only and all its content is initialized in `` we can safely use immutable `Map` instead. ------------- Commit messages: - [PATCH] Unnecessary Hashtable usage in CSS.styleConstantToCssMap Changes: https://git.openjdk.org/jdk/pull/23149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348170 Stats: 36 lines in 1 file changed: 2 ins; 0 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/23149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23149/head:pull/23149 PR: https://git.openjdk.org/jdk/pull/23149 From azvegint at openjdk.org Tue Jan 21 10:13:26 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 21 Jan 2025 10:13:26 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v3] In-Reply-To: References: Message-ID: > The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. > > The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. > > This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. > > The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22729/files - new: https://git.openjdk.org/jdk/pull/22729/files/b60a3326..9b4db46e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=01-02 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22729/head:pull/22729 PR: https://git.openjdk.org/jdk/pull/22729 From azvegint at openjdk.org Tue Jan 21 11:29:35 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 21 Jan 2025 11:29:35 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v3] In-Reply-To: <5G8aojnM5PfSbcoPMw031e81QfMKbCkHqJ6uPzqbvWI=.04447e9f-72ae-40d3-8147-d6e558f07ca8@github.com> References: <33Y5-ZPHAEBEv1_3fv9AW0MoUdvsOTDzC3xnIdJFMb8=.49a266f9-c7bd-4b44-834a-f4d7c36eac69@github.com> <5G8aojnM5PfSbcoPMw031e81QfMKbCkHqJ6uPzqbvWI=.04447e9f-72ae-40d3-8147-d6e558f07ca8@github.com> Message-ID: On Mon, 20 Jan 2025 19:56:18 GMT, Alexey Ivanov wrote: > What if the window that loses focus is not the parent of the popup hierarchy? Or is it guaranteed that all the children of the popup window receive the focus lost event? I can't imagine such a case, but even if it is, it will all be handled correctly once we pass the input back to the XWayland server. At the moment the popup menu is open, we have grabbed the input inside the Xserver, so any click outside the menu should result in ungrabbing and hiding all menus. But XWayland is a special case, where we can't track mouse clicks outside of it in native apps and DE, so we have to implement this workaround by manually ungrabbing the input, so that our code can at least handle the lost window focus as a reason to dismiss the popup menu. There are a few cases where this workaround does not work, e.g. when we click on or non-focusable native windows/panels (Dock, top panel in Gnome, etc.), or show a pop-up menu on our non-focusable window: import java.awt.EventQueue; import java.awt.Frame; import java.awt.MenuItem; import java.awt.PopupMenu; import java.awt.event.MouseAdapter; import java.awt.event.MouseEvent; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; public class AwtPopup { public static void main(String[] args) throws Exception{ EventQueue.invokeAndWait(() -> { final Frame f= new Frame("PopupMenu Example"); final PopupMenu popupmenu = new PopupMenu("Menu"); popupmenu.add(new MenuItem("Item")); f.add(popupmenu); f.addMouseListener(new MouseAdapter() { public void mouseClicked(MouseEvent e) { popupmenu.show(f , e.getX(), e.getY()); } }); f.setSize(200,200); f.addWindowListener(new WindowAdapter() { @Override public void windowClosing(WindowEvent e) { f.dispose(); } }); f.setLocationRelativeTo(null); // Menu is not hidden when we click on the native focusable window // but it is hidden when we click on any X11 application f.setFocusableWindowState(false); f.setVisible(true); }); } } It is not an ideal workaround, but it is good enough to exist. > Shouldn't the line below > > https://github.com/openjdk/jdk/blob/b60a33269247c1039fa0ec6cd99476c9f8976852/src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java#L563 > be changed to call dismissPopupOnFocusLostIfNeededCleanUp to remove the listener from the popup and its children? Not really, because a few lines after we ungrab the input, so all the popup menu will be dismissed, performing cleanups in their `hide()` and `setVisible()` methods. https://github.com/openjdk/jdk/blob/f54e0bf267280c270b0e181289498b28aaf36ee6/src/java.desktop/unix/classes/sun/awt/X11/XMenuWindow.java#L442-L444 https://github.com/openjdk/jdk/blob/f54e0bf267280c270b0e181289498b28aaf36ee6/src/java.desktop/share/classes/javax/swing/JPopupMenu.java#L824-L826 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1923549477 From azvegint at openjdk.org Tue Jan 21 11:36:40 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 21 Jan 2025 11:36:40 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v3] In-Reply-To: References: Message-ID: <5AWw4wEu0PoA3R__tGoKWwjjxUBzCZbwVkbDT53FUFM=.86bbdefb-2482-4428-827a-fa52c76e6b16@github.com> On Mon, 20 Jan 2025 19:35:18 GMT, Alexey Ivanov wrote: > It's an inconvenience which can be overcome by compiling the test and `SkippedException` together: *Grumbling*: "Overcome" is a good word in this case, as it's not even close to the convenience of just `java `, where you don't have to bother finding and specifying all the necessary parameters and paths. Anyway, I updated it to the correct way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1923560715 From azvegint at openjdk.org Tue Jan 21 11:40:34 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 21 Jan 2025 11:40:34 GMT Subject: RFR: 8348170: Unnecessary Hashtable usage in CSS.styleConstantToCssMap In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 11:53:18 GMT, Andrey Turbanov wrote: > There is a field `javax.swing.text.html.CSS#styleConstantToCssMap` which uses legacy `Hashtable` class. > As this map is read-only and all its content is initialized in `` we can safely use immutable `Map` instead. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23149#pullrequestreview-2564349378 From azvegint at openjdk.org Tue Jan 21 11:44:35 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 21 Jan 2025 11:44:35 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there is no swatches or RGB tab in JColorChooser [v3] In-Reply-To: <5QUtYLLYUQk673EcTgC-5KmPnDD1-Qx_Gt0wxdYDc8Y=.f2f83e05-0d2a-49bc-91ae-ee5ce037a491@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> <5QUtYLLYUQk673EcTgC-5KmPnDD1-Qx_Gt0wxdYDc8Y=.f2f83e05-0d2a-49bc-91ae-ee5ce037a491@github.com> Message-ID: On Tue, 21 Jan 2025 04:09:17 GMT, Abhishek Kumar wrote: >> There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23128#pullrequestreview-2564356685 From aivanov at openjdk.org Tue Jan 21 12:03:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 21 Jan 2025 12:03:36 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there are no swatches or RGB tab in JColorChooser [v3] In-Reply-To: <5QUtYLLYUQk673EcTgC-5KmPnDD1-Qx_Gt0wxdYDc8Y=.f2f83e05-0d2a-49bc-91ae-ee5ce037a491@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> <5QUtYLLYUQk673EcTgC-5KmPnDD1-Qx_Gt0wxdYDc8Y=.f2f83e05-0d2a-49bc-91ae-ee5ce037a491@github.com> Message-ID: On Tue, 21 Jan 2025 04:09:17 GMT, Abhishek Kumar wrote: >> There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23128#pullrequestreview-2564399899 From azvegint at openjdk.org Tue Jan 21 14:33:57 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 21 Jan 2025 14:33:57 GMT Subject: RFR: 8347008: beancontext package spec does not clearly explain why the API is deprecated Message-ID: The beancontext package description or the deprecation text in the classes doesn't say anything about why the API is deprecated. A few more words have been added in this regard. ------------- Commit messages: - 8347008: beancontext package spec does not clearly explain why the API is deprecated Changes: https://git.openjdk.org/jdk/pull/23216/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23216&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347008 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23216.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23216/head:pull/23216 PR: https://git.openjdk.org/jdk/pull/23216 From achung at openjdk.org Tue Jan 21 19:05:45 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 21 Jan 2025 19:05:45 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v4] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 19:36:20 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 one additional commit since the last revision: > > update test I did some further testing on macOS and found that as long as a second monitor is plugged in, if the mouse is moved off screen via robot.mouseMove (in either x or y coordinates) and the mouse position is queried via MouseInfo.getPointerInfo().getLocation(), getLocation will throw an NPE. I also tested windows and found different behavior from what Harshitha found - robot.mouseMove was already clamping on my primary screen and would no I was also able to reproduce the interesting corner case that Harshitha and Alexey described on macOS: Primary screen on right, secondary on left -> move mouse to (200, 20000) macOS - mouse moves to right of primary screen, NPE I don?t have any scaling on my macOS so I?m not sure how a rounding error could occur in my setup. I discussed the multi-monitor issue with Phil offline and I am working on an implementation that should work on multi-monitor setups. The plan is to store each of the screenBounds rectangles instead of just the main screen, then on mouseMove, loop through each of the screens until a coordinate lands within the bounds of a screen. The question is when the coordinate lands out of bounds of all screens, especially in cases where it would be reasonable to clamp to either screen, what should the behavior be? We discussed a few options: 1) we could look for the closest screen in the x direction, then y direction and clamp on that screen using x and y 2) we could look for the closest screen in both directions by calculating absolute distance then clamp on that screen using x and y 3) we could look for the closest screen with absolute distance then calculate the slope to figure out where to stop (basically ?fly? there and once you hit a wall you stop) Currently on macOS the mouse tries to ?fly? over to the location and moves along the first wall it encounters, so a combination of 2 and 3. The problem I could see with this approach is that it relies not only on the final location but also the starting location, so a mouseMove to the same location would have different behaviors depending on where you started. I?m not sure if this is a problem but @aivanov-jdk and @honkar-jdk do you have any thoughts/opinions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2605522152 From dgredler at openjdk.org Tue Jan 21 19:32:41 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 21 Jan 2025 19:32:41 GMT Subject: RFR: 8208377: Soft hyphens render if not using TextLayout In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 19:51:38 GMT, Phil Race wrote: >> @prrace, @alisenchung Thanks for your comments! >> >>> What automated checks? >> >> You're right, I had vastly overestimated the scope of the automated tier1 test runs on GitHub. I'll keep that in mind. >> >>> you will need to find machines to run all the tests yourself, across all platforms >> >> I was able to get my hands on a Mac, and have updated the Mac-specific code as well. I'm now covered on Linux, Windows and Mac. But if I ever need to test on AIX, I'll know I took a wrong turn somewhere. >> >>> One thing this fix does is change the logic which we have today [...] TO Never mind what the font says, these are always invisible and zero width >> >> Correct, this is the core of the issue in this bug: there are fonts containing glyphs for e.g. soft hyphen, but these glyphs should not be displayed because these characters are never displayed in and of themselves. This seems to match how HarfBuzz behaves, but the current Java logic does not mirror it, leading to inconsistent results depending on the internal code paths used to render or measure text. >> >> See the Unicode description of "default-ignorable" characters (http://www.unicode.org/L2/L2002/02368-default-ignorable.html): >> >>> Default-ignorable code points are those that should be ignored by default in rendering (unless explicitly supported). They have no visible glyph or advance width in and of themselves, although they may affect the display, positioning, or adornment of adjacent or surrounding characters. [...] This does not imply that default-ignorable code points must always be invisible: an implementation can show a visible glyph on request, such as in a "Show Hidden" mode. A particular use of a "Show Hidden" mode is to show a visible indication of "misplaced" or "ineffectual" formatting codes. [...] There are other characters that have no visible glyphs: the white-space characters. These typically have advance-width, however. The line separation characters such as CR do not clearly exhibit this advance-width since they are always at the end of a line, but in most GUIs show a visible advance width when selected. >> >> The `FontUtilities.isDefaultIgnorable` function matches the HarfBuzz classification, including a few exceptions made for the sake of Uniscribe compatibility: >> >> https://github.com/openjdk/jdk/blob/b2811a0ccd9664d11770980c47424ab6723cbbc9/src/java.desktop/share/native/libharfbuzz/hb-unicode.hh#L128 >> >>> you added 0x200B >> >> Correct, zero-width space is defined as having the Defa... > >> I did have one thought that I wanted to run by you guys: it could be argued that FontUtilities.isDefaultIgnorable should be native and should just delegate to HarfBuzz's is_default_ignorable. That's not the approach I decided to take, but let me know if you disagree. > > ah I guess that's what the hb related comment was about. It wasn't clear. > > > FYI I won't be able to finish reviewing this until January. @prrace Gentle reminder that this review is still pending. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2605570014 From prr at openjdk.org Tue Jan 21 19:35:37 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Jan 2025 19:35:37 GMT Subject: RFR: 8347008: beancontext package spec does not clearly explain why the API is deprecated In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 14:28:26 GMT, Alexander Zvegintsev wrote: > The beancontext package description or the deprecation text in the classes doesn't say anything about why the API is deprecated. > A few more words have been added in this regard. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23216#pullrequestreview-2565529452 From prr at openjdk.org Tue Jan 21 19:39:38 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Jan 2025 19:39:38 GMT Subject: RFR: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there are no swatches or RGB tab in JColorChooser [v3] In-Reply-To: <5QUtYLLYUQk673EcTgC-5KmPnDD1-Qx_Gt0wxdYDc8Y=.f2f83e05-0d2a-49bc-91ae-ee5ce037a491@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> <5QUtYLLYUQk673EcTgC-5KmPnDD1-Qx_Gt0wxdYDc8Y=.f2f83e05-0d2a-49bc-91ae-ee5ce037a491@github.com> Message-ID: On Tue, 21 Jan 2025 04:09:17 GMT, Abhishek Kumar wrote: >> There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. > > Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23128#pullrequestreview-2565536435 From prr at openjdk.org Tue Jan 21 19:44:42 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Jan 2025 19:44:42 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288: > 1286: > 1287: /** > 1288: * Serializes this {@code DataFlavor}. This most definitely changes the serialisation spec. So a CSR is needed. Also shouldn't readExternal be updated to correspond ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1924275958 From honkar at openjdk.org Tue Jan 21 19:45:08 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 21 Jan 2025 19:45:08 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v7] In-Reply-To: References: Message-ID: > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision: - typo - test case added for deserialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/04880f66..b31900bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=05-06 Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From honkar at openjdk.org Tue Jan 21 19:51:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 21 Jan 2025 19:51:36 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: Message-ID: <1wYevaob-VOndOuORCkQnDO8bzgQBhvSpmqVrdcL28w=.9e0c228b-cf66-40c9-b203-37e1784bf410@github.com> On Tue, 14 Jan 2025 17:59:26 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> indentation > > test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData.java line 39: > >> 37: >> 38: public class ValidateICCHeaderData { >> 39: private static ICC_Profile profile; > > the change will also affect serialization, the test should check that code path. @mrserb @prrace Added deserialization test case (as TestCase#15). invalidSRGB.icc was serialized on JDK 21 and the same .icc profile was deserialized here. As expected IAE is thrown in this case. @mrserb All the previous comments have been addressed. Can you please re-review the latest src code and test changes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1924284012 From honkar at openjdk.org Tue Jan 21 19:57:57 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 21 Jan 2025 19:57:57 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v8] In-Reply-To: References: Message-ID: > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: updated test summary, jtreg tag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/b31900bc..78500c2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=06-07 Stats: 25 lines in 1 file changed: 10 ins; 10 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From honkar at openjdk.org Tue Jan 21 20:06:55 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 21 Jan 2025 20:06:55 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: > ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. > > `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). > > - Profile/Device class > - Color Space > - Rendering Intent > - PCS > - Header Size check (ICC Header Size = 128 bytes) > > These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. > > Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: Runtime Exception added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23044/files - new: https://git.openjdk.org/jdk/pull/23044/files/78500c2a..5aa82b21 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23044&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23044/head:pull/23044 PR: https://git.openjdk.org/jdk/pull/23044 From prr at openjdk.org Tue Jan 21 20:14:37 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Jan 2025 20:14:37 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 11:23:29 GMT, Magnus Ihse Bursie wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > > 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 five commits: > > - Merge branch 'master' into dll-main-in-libawt > - Simplify patch > - Merge branch 'master' into dll-main-in-libawt > - Merge branch 'master' into dll-main-in-libawt > - 8346388: Cannot use DllMain in libawt for static builds Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22790#pullrequestreview-2565600574 From prr at openjdk.org Tue Jan 21 20:14:38 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Jan 2025 20:14:38 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: References: Message-ID: <2yxAJ3ZedxR3rDl6txzpPtCXGf1b1qsKJMbDV_c37jY=.f4131ff5-5f6d-46f6-bca6-10899e4719b7@github.com> On Mon, 20 Jan 2025 21:35:41 GMT, Magnus Ihse Bursie wrote: > [](https://bugs.openjdk.org/browse/JDK-8346306) is the reason why no destructors are modified anymore, is it? Much happier that is the case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2605645680 From honkar at openjdk.org Tue Jan 21 20:20:36 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 21 Jan 2025 20:20:36 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v4] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 19:03:02 GMT, Alisen Chung wrote: > The question is when the coordinate lands out of bounds of all screens, especially in cases where it would be reasonable to clamp to either screen, what should the behavior be? We discussed a few options: > > 1. we could look for the closest screen in the x direction, then y direction and clamp on that screen using x and y > 2. we could look for the closest screen in both directions by calculating absolute distance then clamp on that screen using x and y > 3. we could travel to the location and calculate the slope to figure out where to stop (basically ?fly? there and once you hit a wall you stop) > Currently on macOS the mouse tries to ?fly? over to the location and moves along the first wall it encounters, so a combination of 2 and 3. The problem I could see with this approach is that it relies not only on the final location but also the starting location, so a mouseMove to the same location would have different behaviors depending on where you started. I?m not sure if this is a problem but @aivanov-jdk and @honkar-jdk do you have any thoughts/opinions? The approach which results in the same and consistent behavior irrespective of the starting location sounds better to me. If we go with the 1st approach, does it result in consistent behavior (i.e does it return the same screen irrespective of the starting point) ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2605655525 From aivanov at openjdk.org Tue Jan 21 21:23:44 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 21 Jan 2025 21:23:44 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did >> >> build.log on release configuration: >> >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] >> 334 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] >> 326 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] >> 379 | bool freeData = false; >> | ^~~~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] >> 367 | DWORD retval = -1; >> | ^~~~~~ >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': >> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win3... > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'openjdk:master' into accessibility > - Cast to void in AccessBridgeCalls.c > - static_cast to void in jaccessinspector.cpp > - Formatting changes in AccessBridgeEventHandler.cpp > - Merge branch 'master' into accessibility > - Remove now unused result > - Merge branch 'master' into accessibility > - 8342870 I haven't looked at all the files, yet I'm posting my comments right away for discussion. src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c line 230: > 228: if (result != TRUE) { > 229: error = GetLastError(); > 230: } The comparison above should be `if (result == 0)` instead of `TRUE`, because [`FreeLibrary`](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-freelibrary) returns non-zero if the function succeeds, which implies the return value could be different from 1 (`TRUE`). src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 334: > 332: TCHAR dataBuffer[DEFAULT_ALLOC]; > 333: TCHAR *data = dataBuffer; > 334: // bool freeData = false; This should be set to `true` if `data` is reallocated, otherwise both `regEnable` and `regDeleteValue` leak `data`. https://github.com/openjdk/jdk/blob/4a9fba615da0dfa6646ecb9fd9d929f74fe6875e/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp#L336-L341 In fact, the above statement should probably be removed ? the following code uses only `dataBuffer` which does not contain any data if the buffer was dynamically allocated and assigned to `data`. src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 364: > 362: } > 363: > 364: int regDeleteValue(HKEY hFamilyKey, LPCWSTR lpSubKey) There's one more memory leak: https://github.com/openjdk/jdk/blob/4a9fba615da0dfa6646ecb9fd9d929f74fe6875e/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp#L352 The `delete[]` operator must be called on `newStr`. It's present in both `regEnable` and `regDeleteValue`. src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp line 1212: > 1210: } > 1211: > 1212: static_cast(lastError); This falls into category that's useful for debugging only. The value of `lastError` is never used to report an error, yet one can use a debugger to inspect the value. There seems to be no way to report or log the error. Isn't it better to add a flag to suppress the warning? Casting `lastError` to `void` is cryptic. A comment would definitely be helpful here. src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 261: > 259: GetClientRect(hWnd, &rcClient); > 260: // hwndEdit = > 261: CreateWindow("Edit", The edit control is created visible and it's resized to cover the entire client area. The edit control is used? the text is updated in the [`displayAndLog` function](https://github.com/openjdk/jdk/blob/c38417a86e27f047715cfd9a98770387d994a512/src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp#L60). Since the edit control is a child window, it's automatically destroyed when the parent window is destroyed. Therefore, there's no reason to store the handle in a variable, and I suggest removing the `hwndEdit` variable. Moreover, the comment for `hwndEdit`?`// handle of tree-view control`?is confusing because it doesn't store a handle to a TreeView control. src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 561: > 559: tvis.item = tvi; > 560: > 561: /* HTREEITEM treeNodeItem = */ TreeView_InsertItem(treeWnd, &tvis); Since it's unused, I'd rather remove the variable altogether. Does the handle have any other usage except for checking whether an error occurred? ------------- PR Review: https://git.openjdk.org/jdk/pull/21656#pullrequestreview-2564668085 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1924375318 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1923750005 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1923752261 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1923774492 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1923839914 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1923849086 From aivanov at openjdk.org Tue Jan 21 21:23:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 21 Jan 2025 21:23:45 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 00:34:39 GMT, Julian Waters wrote: >> src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c line 233: >> >>> 231: return TRUE; >>> 232: } >>> 233: ((void) error); >> >> Not sure why do we need it. I mean there is a value assignment before so why would compiler complain? > > The error being cast to void is just there to mark that this was a place that the compiler flagged, as for the warning itself, apparently just assigning the value is not enough, as that yields a -Wunused-but-set-variable, it has to actually be used somehow or explicitly be cast to void to stop the warning altogether This may be useful in a debug build to look up the error if it occurs? Shall it be removed? >> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 326: >> >>> 324: int regEnable() { >>> 325: HKEY hKey; >>> 326: // DWORD retval = -1; >> >> I don't think we need to comment out both retval and freeData. It is either remnants of the code that was long gone or (more likely) were just a copy of another template method that actually uses these variables. If variables are not used within the function i would just delete them. > > Will do, thanks I agree `retval` was probably used as a return value of the function; now there are explicit `return` statements. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1924377383 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1923754007 From aivanov at openjdk.org Tue Jan 21 21:31:36 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 21 Jan 2025 21:31:36 GMT Subject: RFR: 8347008: beancontext package spec does not clearly explain why the API is deprecated In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 14:28:26 GMT, Alexander Zvegintsev wrote: > The beancontext package description or the deprecation text in the classes doesn't say anything about why the API is deprecated. > A few more words have been added in this regard. Overall, looks good, yet I've a question. src/java.desktop/share/classes/java/beans/beancontext/package-info.java line 34: > 32: * a bean context. > 33: *

> 34: * These APIs are now both obsolete and express an "anti-pattern" of component Why is ?anti-pattern? in quotes? The word is used in its literal meaning, isn't it? To emphasize, `` or better `` could be used. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23216#pullrequestreview-2565727924 PR Review Comment: https://git.openjdk.org/jdk/pull/23216#discussion_r1924385253 From aivanov at openjdk.org Tue Jan 21 21:34:35 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 21 Jan 2025 21:34:35 GMT Subject: RFR: 8348170: Unnecessary Hashtable usage in CSS.styleConstantToCssMap In-Reply-To: References: Message-ID: <_5dQ21ATX6Vgkrj9f6nkHto_91QuPndbO8JUyYQvUxQ=.482c3929-ec07-42d3-b074-1584516e79e9@github.com> On Thu, 16 Jan 2025 11:53:18 GMT, Andrey Turbanov wrote: > There is a field `javax.swing.text.html.CSS#styleConstantToCssMap` which uses legacy `Hashtable` class. > As this map is read-only and all its content is initialized in `` we can safely use immutable `Map` instead. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23149#pullrequestreview-2565734767 From achung at openjdk.org Tue Jan 21 22:08:36 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 21 Jan 2025 22:08:36 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v4] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 20:18:03 GMT, Harshitha Onkar wrote: > The approach which results in the same and consistent behavior irrespective of the starting location sounds better to me. If we go with the 1st approach, does it result in consistent behavior (i.e does it return the same screen irrespective of the starting point) ? Yea as long as we're looking for the closest screen instead of traveling to the location it should be irrespective of starting location ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2605835095 From duke at openjdk.org Tue Jan 21 22:32:45 2025 From: duke at openjdk.org (duke) Date: Tue, 21 Jan 2025 22:32:45 GMT Subject: Withdrawn: 8343977: Convert java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest to main In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 07:04:36 GMT, Tejesh R wrote: > The test is supposed to be problem listed on macos & Linux but the Problem list points to the .java file instead of the .html file. > Hence converting java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest to main which would automatically resolve the issue. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22026 From prr at openjdk.org Tue Jan 21 23:38:36 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Jan 2025 23:38:36 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v7] In-Reply-To: References: Message-ID: <2q9jVxo2VrmqRIDZbqC58NH3dAgfKmNPhrTsM8G7ZzI=.2b027075-92bf-40fa-8672-84b74923c01f@github.com> On Tue, 21 Jan 2025 19:45:08 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - test case added for deserialization test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData/ValidateICCHeaderData.java line 1: > 1: package ValidateICCHeaderData;/* What's going on here ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1924494376 From honkar at openjdk.org Wed Jan 22 00:18:37 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 22 Jan 2025 00:18:37 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v7] In-Reply-To: <2q9jVxo2VrmqRIDZbqC58NH3dAgfKmNPhrTsM8G7ZzI=.2b027075-92bf-40fa-8672-84b74923c01f@github.com> References: <2q9jVxo2VrmqRIDZbqC58NH3dAgfKmNPhrTsM8G7ZzI=.2b027075-92bf-40fa-8672-84b74923c01f@github.com> Message-ID: On Tue, 21 Jan 2025 23:36:05 GMT, Phil Race wrote: >> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision: >> >> - typo >> - test case added for deserialization > > test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData/ValidateICCHeaderData.java line 1: > >> 1: package ValidateICCHeaderData;/* > > What's going on here ? It was removed in subsequent commit. You may want to refresh the page to see the latest change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1924518354 From azvegint at openjdk.org Wed Jan 22 00:50:56 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 22 Jan 2025 00:50:56 GMT Subject: RFR: 8347008: beancontext package spec does not clearly explain why the API is deprecated [v2] In-Reply-To: References: Message-ID: <_QThNXMcOvZ6n04YZkfQElzj-xWBCZ5Xs2OEgIeDhWA=.e8af5a1e-5312-4e7c-b199-35b6c13a2f26@github.com> > The beancontext package description or the deprecation text in the classes doesn't say anything about why the API is deprecated. > A few more words have been added in this regard. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23216/files - new: https://git.openjdk.org/jdk/pull/23216/files/6d6ae98c..a993944f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23216&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23216&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23216.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23216/head:pull/23216 PR: https://git.openjdk.org/jdk/pull/23216 From azvegint at openjdk.org Wed Jan 22 00:50:57 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 22 Jan 2025 00:50:57 GMT Subject: RFR: 8347008: beancontext package spec does not clearly explain why the API is deprecated [v2] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 21:28:35 GMT, Alexey Ivanov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > src/java.desktop/share/classes/java/beans/beancontext/package-info.java line 34: > >> 32: * a bean context. >> 33: *

>> 34: * These APIs are now both obsolete and express an "anti-pattern" of component > > Why is ?anti-pattern? in quotes? The word is used in its literal meaning, isn't it? > > To emphasize, `` or better `` could be used. It's a copy from [the release notes](https://bugs.openjdk.org/browse/JDK-8336785), updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23216#discussion_r1924539639 From honkar at openjdk.org Wed Jan 22 01:44:39 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 22 Jan 2025 01:44:39 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v3] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 10:13:26 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > formatting Initial testing looks good. Still in the process of reviewing the fix. test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 105: > 103: > 104: static void test1() throws Exception { > 105: Point frameLocation = frame.getLocationOnScreen(); Is it better to have .getLocationOnScreen() calls within EDT? Since getLocationOnScreen() has the possibility of throwing IIlegalCompnentStateException, do we check if the component is visible before calling getLocationOnScreen() especially in the context of pop menus and sub menus ? ------------- PR Review: https://git.openjdk.org/jdk/pull/22729#pullrequestreview-2566015041 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1924576095 From azvegint at openjdk.org Wed Jan 22 03:42:56 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 22 Jan 2025 03:42:56 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v4] In-Reply-To: References: Message-ID: > The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. > > The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. > > This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. > > The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: getLocationOnScreen on EDT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22729/files - new: https://git.openjdk.org/jdk/pull/22729/files/9b4db46e..ef9f0b3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=02-03 Stats: 65 lines in 1 file changed: 35 ins; 15 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/22729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22729/head:pull/22729 PR: https://git.openjdk.org/jdk/pull/22729 From azvegint at openjdk.org Wed Jan 22 03:42:56 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 22 Jan 2025 03:42:56 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v3] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 01:38:56 GMT, Harshitha Onkar wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting > > test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 105: > >> 103: >> 104: static void test1() throws Exception { >> 105: Point frameLocation = frame.getLocationOnScreen(); > > Is it better to have .getLocationOnScreen() calls within EDT? > > Since getLocationOnScreen() has the possibility of throwing IIlegalCompnentStateException, do we check if the component is visible before calling getLocationOnScreen() especially in the context of pop menus and sub menus ? We wait long enough, so if it throws the `IIlegalCompnentStateException` something is not right anyway. But I updated it to `waitTillShown` + get location on EDT to save some test execution time where it is possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1924649014 From psadhukhan at openjdk.org Wed Jan 22 04:04:17 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 22 Jan 2025 04:04:17 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale Message-ID: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) Native windows progressbar renders without leaving any gap as can be seen here ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) so the padding is removed to render the progressbar similar to windows native and it is rendered properly ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) ------------- Commit messages: - jcheck - jcheck - 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale Changes: https://git.openjdk.org/jdk/pull/23227/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23227&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318577 Stats: 102 lines in 2 files changed: 97 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23227/head:pull/23227 PR: https://git.openjdk.org/jdk/pull/23227 From duke at openjdk.org Wed Jan 22 04:16:49 2025 From: duke at openjdk.org (duke) Date: Wed, 22 Jan 2025 04:16:49 GMT Subject: Withdrawn: 8150564: Migrate useful ExtendedRobot methods into awt.Robot In-Reply-To: References: Message-ID: <0Qp3H5zaJvX9lk3Cmqqy-Qnvh5MOUvoeJW1X7YTydSc=.f00f9ddd-3879-4e39-a04e-68cd09d32bd7@github.com> On Tue, 12 Nov 2024 17:39:55 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). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22044 From abhiscxk at openjdk.org Wed Jan 22 05:54:40 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 22 Jan 2025 05:54:40 GMT Subject: Integrated: 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there are no swatches or RGB tab in JColorChooser In-Reply-To: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> References: <4tysuPluB31CRo0Gofp13tDTYskS7U4eKOoSAJtBL4o=.161d804f-1d6c-409f-990e-9bbf3a20198e@github.com> Message-ID: On Wed, 15 Jan 2025 09:30:03 GMT, Abhishek Kumar wrote: > There are no tabs available for GTK Look and Feel due to the different ColorChooser UI design. Updated the test to skip testing for GTK L&F. This pull request has now been integrated. Changeset: 8458f886 Author: Abhishek Kumar URL: https://git.openjdk.org/jdk/commit/8458f886bd3bf64e23e74262d8ad61e735f9bce9 Stats: 15 lines in 1 file changed: 9 ins; 0 del; 6 mod 8347475: GTK: javax/swing/JColorChooser/Test8152419.java there are no swatches or RGB tab in JColorChooser Reviewed-by: aivanov, azvegint, prr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/23128 From duke at openjdk.org Wed Jan 22 06:16:37 2025 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 22 Jan 2025 06:16:37 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale In-Reply-To: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 03:29:55 GMT, Prasanta Sadhukhan wrote: > JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below > > ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) > > Native windows progressbar renders without leaving any gap as can be seen here > > ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) > > so the padding is removed to render the progressbar similar to windows native and it is rendered properly > > ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) test/jdk/javax/swing/JProgressBar/TestProgressBarUI.java line 27: > 25: * @test > 26: * @bug 8318577 > 27: * @summary Tests that tab movement is correct in RTL component orientation. The title of the bug and the summary of the test does not match. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23227#discussion_r1924750601 From dmarkov at openjdk.org Wed Jan 22 06:45:42 2025 From: dmarkov at openjdk.org (Dmitry Markov) Date: Wed, 22 Jan 2025 06:45:42 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> Message-ID: On Fri, 17 Jan 2025 18:22:57 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > check using not equal to NULL to match the rest of the code in the function Marked as reviewed by dmarkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22932#pullrequestreview-2566311082 From psadhukhan at openjdk.org Wed Jan 22 07:02:21 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 22 Jan 2025 07:02:21 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: > JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below > > ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) > > Native windows progressbar renders without leaving any gap as can be seen here > > ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) > > so the padding is removed to render the progressbar similar to windows native and it is rendered properly > > ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: summary update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23227/files - new: https://git.openjdk.org/jdk/pull/23227/files/7af555ab..abb28511 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23227&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23227&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23227/head:pull/23227 PR: https://git.openjdk.org/jdk/pull/23227 From psadhukhan at openjdk.org Wed Jan 22 07:02:21 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 22 Jan 2025 07:02:21 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 06:14:16 GMT, lawrence.andrews wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> summary update > > test/jdk/javax/swing/JProgressBar/TestProgressBarUI.java line 27: > >> 25: * @test >> 26: * @bug 8318577 >> 27: * @summary Tests that tab movement is correct in RTL component orientation. > > The title of the bug and the summary of the test does not match. Updated.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23227#discussion_r1924786553 From hannesw at openjdk.org Wed Jan 22 09:25:43 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 22 Jan 2025 09:25:43 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 19:41:39 GMT, Phil Race wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. >> >> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 >> >> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. >> >> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. > > src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288: > >> 1286: >> 1287: /** >> 1288: * Serializes this {@code DataFlavor}. > > This most definitely changes the serialisation spec. So a CSR is needed. > Also shouldn't readExternal be updated to correspond ? Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that. @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1924979277 From jpai at openjdk.org Wed Jan 22 11:31:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:46 GMT Subject: [jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4 Message-ID: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> This brings in CPU25_01 changes into jdk24 branch. ------------- Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/23232/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23232/head:pull/23232 PR: https://git.openjdk.org/jdk/pull/23232 From jpai at openjdk.org Wed Jan 22 11:31:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:44 GMT Subject: Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 Message-ID: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> This brings in CPU25_01 changes into master branch. ------------- Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/23231/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23231.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23231/head:pull/23231 PR: https://git.openjdk.org/jdk/pull/23231 From dfuchs at openjdk.org Wed Jan 22 11:31:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Jan 2025 11:31:45 GMT Subject: Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 In-Reply-To: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> References: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:49 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into master branch. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23231#pullrequestreview-2566935776 From dfuchs at openjdk.org Wed Jan 22 11:31:46 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Jan 2025 11:31:46 GMT Subject: [jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4 In-Reply-To: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> References: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:53 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into jdk24 branch. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23232#pullrequestreview-2566937917 From jpai at openjdk.org Wed Jan 22 11:31:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:45 GMT Subject: Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 In-Reply-To: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> References: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:49 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into master branch. This pull request has now been integrated. Changeset: 61873564 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/61873564a44d448feb2ae6e5dae93ab33a0aa719 Stats: 137 lines in 4 files changed: 82 ins; 10 del; 45 mod Merge Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/23231 From jpai at openjdk.org Wed Jan 22 11:31:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:46 GMT Subject: [jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4 In-Reply-To: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> References: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:53 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into jdk24 branch. This pull request has now been integrated. Changeset: 4ce95c95 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/4ce95c95efd1587003e91c9d18d94d5b3134aeac Stats: 137 lines in 4 files changed: 82 ins; 10 del; 45 mod Merge Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/23232 From duke at openjdk.org Wed Jan 22 12:15:19 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Wed, 22 Jan 2025 12:15:19 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v8] In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: <0TkdX-Iw4U-c_2JHoeVoVnAHgoNHNd0oIBQhF0kcLzU=.610ef565-34a5-48ff-a5ea-d8b6bb5e5789@github.com> > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: let user choose the printer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22110/files - new: https://git.openjdk.org/jdk/pull/22110/files/1682b903..83240135 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22110&range=06-07 Stats: 213 lines in 1 file changed: 150 ins; 33 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/22110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22110/head:pull/22110 PR: https://git.openjdk.org/jdk/pull/22110 From duke at openjdk.org Wed Jan 22 12:37:37 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Wed, 22 Jan 2025 12:37:37 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v7] In-Reply-To: References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> <7TjSqpznD8iWlfyDb3N3z7ymUpMMKEtclcHW4zQrz4M=.2ab71eb5-352e-45f0-8c17-f0e5471e6352@github.com> Message-ID: On Tue, 21 Jan 2025 03:35:30 GMT, Prasanta Sadhukhan wrote: >> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: >> >> remove trailing whitespace > > test/jdk/javax/print/CUPSPrinterImageableAreaTest.java line 121: > >> 119: job.setPrintable(new RectPrintable(), pageFormat); >> 120: try { >> 121: job.print(); > > it now goes to default printer..maybe also give an option to show a printdialog and let user choose the printer..I guess choosing PDF-printer will not show the issue? I updated the test. The test does not use common print dialog to prevent changes of the media and margins, and filtered out printers that do not have phisycal margins (borderless). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22110#discussion_r1925247236 From ihse at openjdk.org Wed Jan 22 14:04:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Jan 2025 14:04:04 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v5] In-Reply-To: References: Message-ID: > To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: > > 1) This is not called for statically linked libraries, and > 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. > > While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. > > In this case, the `DllMain` function did two things: > > 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. > > 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) > > But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means tha... 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 six commits: - Merge branch 'master' into dll-main-in-libawt - Merge branch 'master' into dll-main-in-libawt - Simplify patch - Merge branch 'master' into dll-main-in-libawt - Merge branch 'master' into dll-main-in-libawt - 8346388: Cannot use DllMain in libawt for static builds ------------- Changes: https://git.openjdk.org/jdk/pull/22790/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22790&range=04 Stats: 46 lines in 1 file changed: 19 ins; 26 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22790/head:pull/22790 PR: https://git.openjdk.org/jdk/pull/22790 From ihse at openjdk.org Wed Jan 22 14:27:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Jan 2025 14:27:55 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v6] In-Reply-To: References: Message-ID: > To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: > > 1) This is not called for statically linked libraries, and > 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. > > While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. > > In this case, the `DllMain` function did two things: > > 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. > > 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) > > But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means tha... Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Make GetAwtModuleHandle static ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22790/files - new: https://git.openjdk.org/jdk/pull/22790/files/961b31ca..41eba91a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22790&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22790&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22790.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22790/head:pull/22790 PR: https://git.openjdk.org/jdk/pull/22790 From ihse at openjdk.org Wed Jan 22 14:27:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Jan 2025 14:27:56 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: <2yxAJ3ZedxR3rDl6txzpPtCXGf1b1qsKJMbDV_c37jY=.f4131ff5-5f6d-46f6-bca6-10899e4719b7@github.com> References: <2yxAJ3ZedxR3rDl6txzpPtCXGf1b1qsKJMbDV_c37jY=.f4131ff5-5f6d-46f6-bca6-10899e4719b7@github.com> Message-ID: On Tue, 21 Jan 2025 20:12:12 GMT, Phil Race wrote: >>> [JDK-8346306](https://bugs.openjdk.org/browse/JDK-8346306) is the reason why no destructors are modified anymore, is it? >> >> Correct. > >> [](https://bugs.openjdk.org/browse/JDK-8346306) is the reason why no destructors are modified anymore, is it? > > Much happier that is the case. @prrace @aivanov-jdk Can you please re-review the latest version (which makes GetAwtModuleHandle static)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2607387527 From ihse at openjdk.org Wed Jan 22 14:27:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Jan 2025 14:27:57 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v4] In-Reply-To: <0f78p-Zz3_KQHvclf-3N9o7X2a7Ngfo4WqX606YqtAs=.4005569c-6e8c-4e8b-90ca-d82217f3b34b@github.com> References: <0f78p-Zz3_KQHvclf-3N9o7X2a7Ngfo4WqX606YqtAs=.4005569c-6e8c-4e8b-90ca-d82217f3b34b@github.com> Message-ID: On Mon, 20 Jan 2025 21:47:33 GMT, Alexey Ivanov wrote: >> Actually, this function needs to be **not** static for it to work -- it uses it's own address to look up the handle that contains it -- which will be awt.dll when running a normal, dynamic build, and the entire java.exe when running a static build. > > Yep. A static function could be optimised out? inlined. However, if the address of the function is taken, the function should remain as a stand-alone callable function. Adding `static` shouldn't remove the function, it just ensures the function name isn't visible to other .obj files. > > I'm not 100% sure, yet I think it should work correctly even when `GetAwtModuleHandle` is declared `static`. You are 100% correct. It works fine with static. I got kind of confused that name resolution should come into play, but I guess Windows just looks up the address and determines what module it belongs to that way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22790#discussion_r1925410792 From aivanov at openjdk.org Wed Jan 22 15:03:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 22 Jan 2025 15:03:55 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v6] In-Reply-To: References: Message-ID: <--4aDMIh2iJ86xatm7ayBsCG4UE0yfTSJ2OI9DAlFAQ=.547aa7d5-5bac-4f0c-ab2a-0bb21a453441@github.com> On Wed, 22 Jan 2025 14:27:55 GMT, Magnus Ihse Bursie wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Make GetAwtModuleHandle static Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22790#pullrequestreview-2567470586 From ihse at openjdk.org Wed Jan 22 15:13:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Jan 2025 15:13:55 GMT Subject: RFR: 8346388: Cannot use DllMain in libawt for static builds [v6] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 14:27:55 GMT, Magnus Ihse Bursie wrote: >> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: >> >> 1) This is not called for statically linked libraries, and >> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. >> >> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. >> >> In this case, the `DllMain` function did two things: >> >> 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. >> >> 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) >> >> But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. >> >> I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). >> >> Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed thi... > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Make GetAwtModuleHandle static Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22790#issuecomment-2607508865 From ihse at openjdk.org Wed Jan 22 15:13:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Jan 2025 15:13:56 GMT Subject: Integrated: 8346388: Cannot use DllMain in libawt for static builds In-Reply-To: References: Message-ID: <4WkISLaA6jzkqtvVlCJ8uue1mTmcbQ1BvPssD-nQ54o=.3db22a35-d767-4864-a374-bc5c9a486e0b@github.com> On Tue, 17 Dec 2024 11:51:51 GMT, Magnus Ihse Bursie wrote: > To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons: > > 1) This is not called for statically linked libraries, and > 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions. > > While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds. > > In this case, the `DllMain` function did two things: > > 1) At startup, it called SetModuleHandle. This has been moved to the `JNI_OnLoad` function, which is called by the JVM right after loading the DLL, or in the case of a static build, when the `awt` native library has been requested. > > 2) At DLL unload -- for debug builds only -- it "disabled" the mutexes for the DTrace and DMem debug systems. In this case, "disable" means writing NULL to the mutexes, causing any further calls to the continue without locking, since the enter/exit calls only do the locking if the mutex is not NULL. (This is pre-existing code so I am not discussing the soundness of this approach.) > > But why did we need to do that? After the DLL unloading, which is done by Windows when the process is exiting, no code should be executing in AWT, right? No, wrong. There are three static objects, one instance of AwtDebugSupport and two instances of GDIHashtable, and the destructors of these objects are called by Windows at the time of process shutdown. I have not been able to confirm that the `DllMain` code is guaranteed to be called before the destructors are called, so I guess the fact that this ever worked has just been a lucky coincidence. > > I have solved this by disabling the mutexes in the destructors themselves, thereby guaranteeing that they are disabled before the last few calls to the DTrace/DMem calls are made. There is no guarantee in which order these destructors are made, so I do the same on both locations. (There is no bad effect from calling these twice in a row, it's just setting a mutex to NULL). > > Finally, I have wrapped the `DEF_JNI_OnLoad` function in `extern "C" { ... }`. This is needed since DEF_JNI_OnLoad is a macro that actually creates two functions, where one is a wrapper calling the other which has a generated name, and without this, the C++ name mangling messed things up. (To be clear: this means tha... This pull request has now been integrated. Changeset: 893d00ac Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/893d00ac7d118620b56ce147d447c6fca80bbe7b Stats: 46 lines in 1 file changed: 19 ins; 26 del; 1 mod 8346388: Cannot use DllMain in libawt for static builds Reviewed-by: aivanov, prr ------------- PR: https://git.openjdk.org/jdk/pull/22790 From aivanov at openjdk.org Wed Jan 22 16:51:45 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 22 Jan 2025 16:51:45 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java Message-ID: With this changeset, I update the `java/awt/List/ItemEventTest/ItemEventTest.java` test to improve its stability and analysis of failures of the test. 1. Use thread-safe `StringBuffer` for `actualSelectionOrder` to track selecting/deselecting items in the list. 2. Enable `robot.setAutoWaitForIdle(true)` and remove `robot.waitForIdle()` from the test code. 3. Log `handleEvent` and `ItemListener` which helps to identify test failures. (In case of [JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221), `handleEvent` is never logged.) 5. Take screenshot of the list on failure; Optionally take screenshot after each mouse press+release if `-save` is passed as a parameter to the test. The updated test passes. ------------- Commit messages: - 8348299: Update List/ItemEventTest/ItemEventTest.java Changes: https://git.openjdk.org/jdk/pull/23238/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23238&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348299 Stats: 100 lines in 1 file changed: 46 ins; 8 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/23238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23238/head:pull/23238 PR: https://git.openjdk.org/jdk/pull/23238 From duke at openjdk.org Wed Jan 22 17:10:50 2025 From: duke at openjdk.org (lawrence.andrews) Date: Wed, 22 Jan 2025 17:10:50 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 07:02:21 GMT, Prasanta Sadhukhan wrote: >> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below >> >> ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) >> >> Native windows progressbar renders without leaving any gap as can be seen here >> >> ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) >> >> so the padding is removed to render the progressbar similar to windows native and it is rendered properly >> >> ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > summary update The ProgressBar p1 & p2 are set with value 50 ( setValue(50);) in testcase but the image shows 100% ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2607799702 From aivanov at openjdk.org Wed Jan 22 17:20:57 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 22 Jan 2025 17:20:57 GMT Subject: RFR: 8348303: Remove repeated 'a' from ListSelectionEvent Message-ID: A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > ?The change is limited to **a a** single inclusive interval.? In addition to the above, I * expanded the wildcard imports, * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. ------------- Commit messages: - Use lower-case ?string? in @return for toString() - Mark up firstIndex and lastIndex with {@code} - 8348303: Remove repeated 'a' from ListSelectionEvent Changes: https://git.openjdk.org/jdk/pull/23240/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348303 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23240/head:pull/23240 PR: https://git.openjdk.org/jdk/pull/23240 From azvegint at openjdk.org Wed Jan 22 17:32:46 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 22 Jan 2025 17:32:46 GMT Subject: RFR: 8348303: Remove repeated 'a' from ListSelectionEvent In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:16:11 GMT, Alexey Ivanov wrote: > A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > >> ?The change is limited to **a a** single inclusive interval.? > > In addition to the above, I > * expanded the wildcard imports, > * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and > * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). > > ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23240#pullrequestreview-2567857349 From aivanov at openjdk.org Wed Jan 22 17:44:52 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 22 Jan 2025 17:44:52 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 07:02:21 GMT, Prasanta Sadhukhan wrote: >> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below >> >> ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) >> >> Native windows progressbar renders without leaving any gap as can be seen here >> >> ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) >> >> so the padding is removed to render the progressbar similar to windows native and it is rendered properly >> >> ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > summary update I don't think it's correct to compare the rendering of progress with visual styles enabled (XPStyle) and without them. Currently, Windows doesn't allow switching to the classic theme that has no visual styles. The latest version of Windows which had the classic theme was Windows 7. Your screenshot of a progress bar from the Copy progress dialog in Windows *uses visual styles*. But you're modifying the rendering in the portion which renders progress bar without XP Style. The reporter of the bug correctly identified the root cause: *it's rounding error* of the scaling applied ? depending on the position of the progress bar as well as its width and height, the thickness of border can become inconsistent. There were quite a few bugs which addressed this problem. The solution used was to reset the scale transform and render all the pixels. The subject of the bug says ?2?? but the attached screenshot demonstrates the problem at 1.75?, according to the filename: `Capture_175scale.png`. The fractional scales are where this rounding errors occur the most, especially at 1.25 and 1.75. Taking the above into account, I don't think the proposed fix resolves the problem completely. It removes the gap, I believe, it may still be possible to see inconsistencies around edges. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2607873290 From honkar at openjdk.org Wed Jan 22 17:48:48 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 22 Jan 2025 17:48:48 GMT Subject: RFR: 8348303: Remove repeated 'a' from ListSelectionEvent In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:16:11 GMT, Alexey Ivanov wrote: > A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > >> ?The change is limited to **a a** single inclusive interval.? > > In addition to the above, I > * expanded the wildcard imports, > * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and > * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). > > ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23240#pullrequestreview-2567888954 From dmarkov at openjdk.org Wed Jan 22 18:40:49 2025 From: dmarkov at openjdk.org (Dmitry Markov) Date: Wed, 22 Jan 2025 18:40:49 GMT Subject: RFR: 8348303: Remove repeated 'a' from ListSelectionEvent In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:16:11 GMT, Alexey Ivanov wrote: > A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > >> ?The change is limited to **a a** single inclusive interval.? > > In addition to the above, I > * expanded the wildcard imports, > * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and > * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). > > ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. Marked as reviewed by dmarkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23240#pullrequestreview-2567998080 From prr at openjdk.org Wed Jan 22 19:50:51 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 22 Jan 2025 19:50:51 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:45:17 GMT, Alexey Ivanov wrote: > With this changeset, I update the `java/awt/List/ItemEventTest/ItemEventTest.java` test to improve its stability and analysis of failures of the test. > > 1. Use thread-safe `StringBuffer` for `actualSelectionOrder` to track selecting/deselecting items in the list. > 2. Enable `robot.setAutoWaitForIdle(true)` and remove `robot.waitForIdle()` from the test code. > 3. Log `handleEvent` and `ItemListener` which helps to identify test failures. > (In case of [JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221), `handleEvent` is never logged.) > 5. Take screenshot of the list on failure; > Optionally take screenshot after each mouse press+release if `-save` is passed as a parameter to the test. > > The updated test passes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23238#pullrequestreview-2568132646 From prr at openjdk.org Wed Jan 22 19:52:49 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 22 Jan 2025 19:52:49 GMT Subject: RFR: 8348303: Remove repeated 'a' from ListSelectionEvent In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:16:11 GMT, Alexey Ivanov wrote: > A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > >> ?The change is limited to **a a** single inclusive interval.? > > In addition to the above, I > * expanded the wildcard imports, > * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and > * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). > > ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23240#pullrequestreview-2568135482 From honkar at openjdk.org Wed Jan 22 20:00:49 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 22 Jan 2025 20:00:49 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v4] In-Reply-To: References: Message-ID: <3OcDClok8xhw55JXhYJfyvkBZm4DmMy39ABRz0oIjFQ=.555bd56a-33a9-4679-b245-eefd02e3b931@github.com> On Wed, 22 Jan 2025 03:42:56 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > getLocationOnScreen on EDT Updated test changes LGTM ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22729#pullrequestreview-2568151132 From honkar at openjdk.org Wed Jan 22 20:00:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 22 Jan 2025 20:00:50 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v3] In-Reply-To: References: Message-ID: <7vihW3t4dMC3lWy0T4HdPL04LTIKpqo1DuL-7Jr9y6U=.536a97f9-1104-4b31-86e5-1ebbd30880ef@github.com> On Wed, 22 Jan 2025 03:39:44 GMT, Alexander Zvegintsev wrote: >> test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 105: >> >>> 103: >>> 104: static void test1() throws Exception { >>> 105: Point frameLocation = frame.getLocationOnScreen(); >> >> Is it better to have .getLocationOnScreen() calls within EDT? >> >> Since getLocationOnScreen() has the possibility of throwing IIlegalCompnentStateException, do we check if the component is visible before calling getLocationOnScreen() especially in the context of pop menus and sub menus ? > > We wait long enough, so if it throws the `IIlegalCompnentStateException` something is not right anyway. > > But I updated it to `waitTillShown` + get location on EDT to save some test execution time where it is possible. Sounds good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1925887880 From honkar at openjdk.org Wed Jan 22 20:05:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 22 Jan 2025 20:05:50 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v4] In-Reply-To: References: Message-ID: <-gI4SX9zSR5o--I9rg8QZWu9_EohY2ExFQUBINRP-jo=.d492084c-def1-4444-ab37-e79e04f57a7b@github.com> On Wed, 22 Jan 2025 03:42:56 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > getLocationOnScreen on EDT @aivanov-jdk > What if the window that loses focus is not the parent of the popup hierarchy? Or is it guaranteed that all the children of the popup window receive the focus lost event? Doesn't FocusablePopupDismissTest.java & NestedFocusablePopupTest.java cover this case (Focusable item > sub item) or is the above case different? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22729#issuecomment-2608155867 From aivanov at openjdk.org Wed Jan 22 20:30:43 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 22 Jan 2025 20:30:43 GMT Subject: RFR: 8348308: Make fields of ListSelectionEvent final Message-ID: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> The fields of `ListSelectionEvent` are set in the constructor and are never modified, mark the fields???`firstIndex`, `lastIndex`, `isAdjusting`???with the `final` modifier. ------------- Commit messages: - 8348308: Make fields of ListSelectionEvent final Changes: https://git.openjdk.org/jdk/pull/23243/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348308 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23243.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23243/head:pull/23243 PR: https://git.openjdk.org/jdk/pull/23243 From prr at openjdk.org Wed Jan 22 20:30:48 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 22 Jan 2025 20:30:48 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Runtime Exception added Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23044#pullrequestreview-2568204912 From prr at openjdk.org Wed Jan 22 20:37:51 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 22 Jan 2025 20:37:51 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 09:23:10 GMT, Hannes Walln?fer wrote: >> src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288: >> >>> 1286: >>> 1287: /** >>> 1288: * Serializes this {@code DataFlavor}. >> >> This most definitely changes the serialisation spec. So a CSR is needed. >> Also shouldn't readExternal be updated to correspond ? > > Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that. > > @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording? There's not a great number of "good" examples of this in the JDK, so probably OK except it seems like most cases will do it like a normal javadoc method so you'd want an @param tag too. note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1925928563 From duke at openjdk.org Wed Jan 22 20:44:46 2025 From: duke at openjdk.org (Abdelhak Zaaim) Date: Wed, 22 Jan 2025 20:44:46 GMT Subject: RFR: 8348308: Make fields of ListSelectionEvent final In-Reply-To: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> References: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> Message-ID: On Wed, 22 Jan 2025 20:20:28 GMT, Alexey Ivanov wrote: > The fields of `ListSelectionEvent` are set in the constructor and are never modified, mark the fields???`firstIndex`, `lastIndex`, `isAdjusting`???with the `final` modifier. Thank you for making the fields final, improving immutability and thread-safety. However, the file header still references the copyright year as 2014. Please update it to 2025 to reflect the changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/23243#pullrequestreview-2568224478 From aivanov at openjdk.org Wed Jan 22 20:44:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 22 Jan 2025 20:44:46 GMT Subject: RFR: 8348308: Make fields of ListSelectionEvent final In-Reply-To: References: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> Message-ID: On Wed, 22 Jan 2025 20:39:50 GMT, Abdelhak Zaaim wrote: > Please update it to 2025 to reflect the changes. File header will be updated by #23240. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23243#issuecomment-2608222128 From aivanov at openjdk.org Wed Jan 22 21:02:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 22 Jan 2025 21:02:54 GMT Subject: RFR: 8347008: beancontext package spec does not clearly explain why the API is deprecated [v2] In-Reply-To: <_QThNXMcOvZ6n04YZkfQElzj-xWBCZ5Xs2OEgIeDhWA=.e8af5a1e-5312-4e7c-b199-35b6c13a2f26@github.com> References: <_QThNXMcOvZ6n04YZkfQElzj-xWBCZ5Xs2OEgIeDhWA=.e8af5a1e-5312-4e7c-b199-35b6c13a2f26@github.com> Message-ID: On Wed, 22 Jan 2025 00:50:56 GMT, Alexander Zvegintsev wrote: >> The beancontext package description or the deprecation text in the classes doesn't say anything about why the API is deprecated. >> A few more words have been added in this regard. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23216#pullrequestreview-2568260682 From prr at openjdk.org Wed Jan 22 21:34:47 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 22 Jan 2025 21:34:47 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v8] In-Reply-To: <0TkdX-Iw4U-c_2JHoeVoVnAHgoNHNd0oIBQhF0kcLzU=.610ef565-34a5-48ff-a5ea-d8b6bb5e5789@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> <0TkdX-Iw4U-c_2JHoeVoVnAHgoNHNd0oIBQhF0kcLzU=.610ef565-34a5-48ff-a5ea-d8b6bb5e5789@github.com> Message-ID: On Wed, 22 Jan 2025 12:15:19 GMT, GennadiyKrivoshein wrote: >> **Description:** >> The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. >> The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 >> >> **Updates:** >> Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. >> >> **Tests:** >> Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. >> The test was run with the minimum possible margins. >> _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). >> _After the fix_: all lines are printed. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > let user choose the printer I had not looked at this PR properly until now. FWIW I probably would myself have made the change in the Java code as was initially done, but either is equivalent and I don't think it is worth flip-flopping and the fix is good to have. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22110#pullrequestreview-2568322668 From duke at openjdk.org Wed Jan 22 21:44:45 2025 From: duke at openjdk.org (Abdelhak Zaaim) Date: Wed, 22 Jan 2025 21:44:45 GMT Subject: RFR: 8348303: Remove repeated 'a' from ListSelectionEvent In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:16:11 GMT, Alexey Ivanov wrote: > A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > >> ?The change is limited to **a a** single inclusive interval.? > > In addition to the above, I > * expanded the wildcard imports, > * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and > * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). > > ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/23240#pullrequestreview-2568344515 From kizune at openjdk.org Wed Jan 22 23:49:50 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 22 Jan 2025 23:49:50 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:45:17 GMT, Alexey Ivanov wrote: > With this changeset, I update the `java/awt/List/ItemEventTest/ItemEventTest.java` test to improve its stability and analysis of failures of the test. > > 1. Use thread-safe `StringBuffer` for `actualSelectionOrder` to track selecting/deselecting items in the list. > 2. Enable `robot.setAutoWaitForIdle(true)` and remove `robot.waitForIdle()` from the test code. > 3. Log `handleEvent` and `ItemListener` which helps to identify test failures. > (In case of [JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221), `handleEvent` is never logged.) > 5. Take screenshot of the list on failure; > Optionally take screenshot after each mouse press+release if `-save` is passed as a parameter to the test. > > The updated test passes. Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23238#pullrequestreview-2568521961 From kizune at openjdk.org Wed Jan 22 23:50:46 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 22 Jan 2025 23:50:46 GMT Subject: RFR: 8348303: Remove repeated 'a' from ListSelectionEvent In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:16:11 GMT, Alexey Ivanov wrote: > A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > >> ?The change is limited to **a a** single inclusive interval.? > > In addition to the above, I > * expanded the wildcard imports, > * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and > * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). > > ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23240#pullrequestreview-2568523049 From honkar at openjdk.org Thu Jan 23 01:03:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 23 Jan 2025 01:03:50 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v3] In-Reply-To: References: Message-ID: <7env98PduHPZ06t99_jkG0988p4Ri1pE5O2l-ddORgA=.43c48f8a-4552-45c9-a29f-a28917f3d654@github.com> On Fri, 20 Dec 2024 19:22:35 GMT, Alisen Chung wrote: >> @aivanov-jdk >> I see your point. But I'm running into NPE at `MouseInfo.getPointerInfo().getLocation()` without the fix as well (dual monitor, extended display setup) >> >> Is it expected of MouseInfo.getPointerInfo() to return null for off-screen coordinates (meaning does it consider it as mouse not available if it is outside the screen devices)? >> >> PointerInfo has two things associated with it - screen device and a location, so if it is not able to associate the coordinate with any of the screen device (off-screen coordinate) is it suppose to return null in this case? > > Interesting. Does this also happen after the fix with Robot clamping coordinates in shared code? @alisenchung > I also tested windows and found different behavior from what Harshitha found - robot.mouseMove was already clamping on my primary screen, would not move to the second monitor, and did not throw any NPEs. Tested it on windows again on different scales and found a possible rounding error that might be the cause for NPE on windows. To save time you can run the test with multiple `@run` and different uiScales and do not have to change it manually in settings. * @run main/othervm -Dsun.java2d.uiScale=1 MouseMoveOffScreen * @run main/othervm -Dsun.java2d.uiScale=1.25 MouseMoveOffScreen * @run main/othervm -Dsun.java2d.uiScale=1.75 MouseMoveOffScreen * @run main/othervm -Dsun.java2d.uiScale=2 MouseMoveOffScreen * @run main/othervm -Dsun.java2d.uiScale=1.5 MouseMoveOffScreen Following are the logs. Observe the width of the primary screen and the point returned from fillPointWithCoords() in getPointerInfo(). uiScale: 1 - Passes Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1920,height=1080] Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,**width=3440**,height=1440] Point: java.awt.Point[**x=3439**,y=200] uiScale: 1.25 - Passes Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1536,height=864] Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,**width=2752**,height=1152] Point: java.awt.Point[**x=2751**,y=200] **uiScale: 1.5 - Fails** Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1280,height=720] Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,**width=2293**,height=960] Point: java.awt.Point[**x=2293**,y=200] => **x coordinate = width and bounds.contains(point) returns false for point on the edge/bounds of the window.** uiScale: 1.75 - Passes Win32GraphicsDevice[screen=0]:java.awt.Rectangle[x=-1920,y=363,width=1097,height=617] Win32GraphicsDevice[screen=1]:java.awt.Rectangle[x=0,y=0,width=1966,height=823] Point: java.awt.Point[x=0,y=200] => clamps to zero once coordinates are past the width of the screen. We probably need to look into `fillPointWithCoords()` closely and how it is implemented on different platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1926210713 From honkar at openjdk.org Thu Jan 23 01:13:52 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 23 Jan 2025 01:13:52 GMT Subject: RFR: 8348308: Make fields of ListSelectionEvent final In-Reply-To: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> References: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> Message-ID: On Wed, 22 Jan 2025 20:20:28 GMT, Alexey Ivanov wrote: > The fields of `ListSelectionEvent` are set in the constructor and are never modified, mark the fields???`firstIndex`, `lastIndex`, `isAdjusting`???with the `final` modifier. Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23243#pullrequestreview-2568651575 From psadhukhan at openjdk.org Thu Jan 23 03:16:46 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 23 Jan 2025 03:16:46 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 17:41:48 GMT, Alexey Ivanov wrote: > But you're modifying the rendering in the portion which renders progress bar without XP Style. I guess I am modifying for presence of XPStyle XPStyle xp = XPStyle.getXP(); if (xp != null) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2608756301 From psadhukhan at openjdk.org Thu Jan 23 03:16:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 23 Jan 2025 03:16:47 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 17:07:52 GMT, lawrence.andrews wrote: > The ProgressBar p1 & p2 are set with value 50 ( setValue(50);) in testcase but the image shows 100% Please run the testcase..The screenshot was not for the test. It was run separately to compare with the top so I took 100% for bottom bars too ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2608757512 From jwaters at openjdk.org Thu Jan 23 05:37:29 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 23 Jan 2025 05:37:29 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v6] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > build.log on release configuration: > > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regEnable()': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:334:14: warning: unused variable 'freeData' [-Wunused-variable] > 334 | bool freeData = false; > | ^~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:326:11: warning: unused variable 'retval' [-Wunused-variable] > 326 | DWORD retval = -1; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp: In function 'int regDeleteValue(HKEY, LPCWSTR)': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:379:14: warning: unused variable 'freeData' [-Wunused-variable] > 379 | bool freeData = false; > | ^~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp:367:11: warning: unused variable 'retval' [-Wunused-variable] > 367 | DWORD retval = -1; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c: In function 'shutdownAccessBridge': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibi... Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Typo in AccessBridgeCalls.c - Fix AccessBridgeCalls.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21656/files - new: https://git.openjdk.org/jdk/pull/21656/files/f975dfa2..47b168a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21656&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21656&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21656.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21656/head:pull/21656 PR: https://git.openjdk.org/jdk/pull/21656 From jwaters at openjdk.org Thu Jan 23 05:37:33 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 23 Jan 2025 05:37:33 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 21:18:27 GMT, Alexey Ivanov wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'openjdk:master' into accessibility >> - Cast to void in AccessBridgeCalls.c >> - static_cast to void in jaccessinspector.cpp >> - Formatting changes in AccessBridgeEventHandler.cpp >> - Merge branch 'master' into accessibility >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c line 230: > >> 228: if (result != TRUE) { >> 229: error = GetLastError(); >> 230: } > > The comparison above should be `if (result == 0)` instead of `!= TRUE`, because [`FreeLibrary`](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-freelibrary) returns non-zero if the function succeeds, which implies the return value could be different from 1 (`TRUE`). Fixed. I also changed the logic below to return FALSE if the FreeLibrary call above failed > src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp line 1212: > >> 1210: } >> 1211: >> 1212: static_cast(lastError); > > This falls into category that's useful for debugging only. The value of `lastError` is never used to report an error, yet one can use a debugger to inspect the value. > > There seems to be no way to report or log the error. > > Isn't it better to add a flag to suppress the warning? Casting `lastError` to `void` is cryptic. A comment would definitely be helpful here. I suppose I could do that yes, if that that is preferred ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1926387441 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1926388732 From jwaters at openjdk.org Thu Jan 23 05:37:33 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 23 Jan 2025 05:37:33 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: <07ErPfwZi_znjjtTEtbDbdHNQV8OgYZltTmTdRvZxxo=.2879d9b0-ea28-49ff-a691-d51af725b3a9@github.com> On Tue, 21 Jan 2025 13:43:17 GMT, Alexey Ivanov wrote: >> Will do, thanks > > I agree `retval` was probably used as a return value of the function; now there are explicit `return` statements. I'll remove retval in a moment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1926387875 From jwaters at openjdk.org Thu Jan 23 05:48:51 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 23 Jan 2025 05:48:51 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:40:42 GMT, Alexey Ivanov wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'openjdk:master' into accessibility >> - Cast to void in AccessBridgeCalls.c >> - static_cast to void in jaccessinspector.cpp >> - Formatting changes in AccessBridgeEventHandler.cpp >> - Merge branch 'master' into accessibility >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 334: > >> 332: TCHAR dataBuffer[DEFAULT_ALLOC]; >> 333: TCHAR *data = dataBuffer; >> 334: // bool freeData = false; > > This should be set to `true` if `data` is reallocated, otherwise both `regEnable` and `regDeleteValue` leak `data`. > > https://github.com/openjdk/jdk/blob/4a9fba615da0dfa6646ecb9fd9d929f74fe6875e/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp#L336-L341 > > In fact, the above statement should probably be removed ? the following code uses only `dataBuffer` which does not contain any data if the buffer was dynamically allocated and assigned to `data`. By the above statement are you referring to the lines 336 to 341? I'll admit I'm a little lost for this one ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1926398535 From jwaters at openjdk.org Thu Jan 23 05:52:54 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 23 Jan 2025 05:52:54 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 14:33:57 GMT, Alexey Ivanov wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'openjdk:master' into accessibility >> - Cast to void in AccessBridgeCalls.c >> - static_cast to void in jaccessinspector.cpp >> - Formatting changes in AccessBridgeEventHandler.cpp >> - Merge branch 'master' into accessibility >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 261: > >> 259: GetClientRect(hWnd, &rcClient); >> 260: // hwndEdit = >> 261: CreateWindow("Edit", > > The edit control is created visible and it's resized to cover the entire client area. > > The edit control is used? the text is updated in the [`displayAndLog` function](https://github.com/openjdk/jdk/blob/c38417a86e27f047715cfd9a98770387d994a512/src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp#L60). > > Since the edit control is a child window, it's automatically destroyed when the parent window is destroyed. > > Therefore, there's no reason to store the handle in a variable, and I suggest removing the `hwndEdit` variable. > > Moreover, the comment for `hwndEdit`?`// handle of tree-view control`?is confusing because it doesn't store a handle to a TreeView control. I wonder if this falls into the category of "Can be used in a debugger" like Alex mentioned above, if not I'll remove it > src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 561: > >> 559: tvis.item = tvi; >> 560: >> 561: /* HTREEITEM treeNodeItem = */ TreeView_InsertItem(treeWnd, &tvis); > > Since it's unused, I'd rather remove the variable altogether. > > Does the handle have any other usage except for checking whether an error occurred? I'm not sure which handle you're referring to, you mean treeNodeItem? It doesn't seem to be used for checking if an error occurred ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1926401417 PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1926400915 From azvegint at openjdk.org Thu Jan 23 07:41:46 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 23 Jan 2025 07:41:46 GMT Subject: RFR: 8348308: Make fields of ListSelectionEvent final In-Reply-To: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> References: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> Message-ID: On Wed, 22 Jan 2025 20:20:28 GMT, Alexey Ivanov wrote: > The fields of `ListSelectionEvent` are set in the constructor and are never modified, mark the fields???`firstIndex`, `lastIndex`, `isAdjusting`???with the `final` modifier. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23243#pullrequestreview-2569077165 From mbaesken at openjdk.org Thu Jan 23 09:28:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Jan 2025 09:28:57 GMT Subject: RFR: 8330936: [ubsan] signed integer overflows in libawt java2d Message-ID: In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int' #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683 #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499 #2 0x7efe9b8dee7b () java/awt/BasicStroke/DashStrokeTest.java shows src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int' #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366 #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75 #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92 #3 0x7fba12d07e7b () There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings. ------------- Commit messages: - JDK-8330936 Changes: https://git.openjdk.org/jdk/pull/23255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330936 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23255/head:pull/23255 PR: https://git.openjdk.org/jdk/pull/23255 From azvegint at openjdk.org Thu Jan 23 09:43:48 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 23 Jan 2025 09:43:48 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:45:17 GMT, Alexey Ivanov wrote: > With this changeset, I update the `java/awt/List/ItemEventTest/ItemEventTest.java` test to improve its stability and analysis of failures of the test. > > 1. Use thread-safe `StringBuffer` for `actualSelectionOrder` to track selecting/deselecting items in the list. > 2. Enable `robot.setAutoWaitForIdle(true)` and remove `robot.waitForIdle()` from the test code. > 3. Log `handleEvent` and `ItemListener` which helps to identify test failures. > (In case of [JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221), `handleEvent` is never logged.) > 5. Take screenshot of the list on failure; > Optionally take screenshot after each mouse press+release if `-save` is passed as a parameter to the test. > > The updated test passes. test/jdk/java/awt/List/ItemEventTest/ItemEventTest.java line 82: > 80: pack(); > 81: setLocationRelativeTo(null); > 82: setVisible(true); Didn't we decide that we should also now handle AWT calls on EDT? test/jdk/java/awt/List/ItemEventTest/ItemEventTest.java line 93: > 91: || e.id == Event.LIST_SELECT)) { > 92: logEvent("handleEvent: ", e.arg); > 93: } Suggestion: if (e.target instanceof List) { switch (e.id) { case Event.LIST_SELECT -> logEvent("handleEvent: LIST_SELECT ", e.arg); case Event.LIST_DESELECT -> logEvent("handleEvent: LIST_DESELECT ", e.arg); } } Not sure if this is really useful or not, but logging can be slightly improved. test/jdk/java/awt/List/ItemEventTest/ItemEventTest.java line 117: > 115: synchronized (actualSelectionOrder) { > 116: actualSelectionOrder.delete(0, actualSelectionOrder.length()); > 117: } Suggestion: actualSelectionOrder.setLength(0); we can make it shorter ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23238#discussion_r1926666866 PR Review Comment: https://git.openjdk.org/jdk/pull/23238#discussion_r1926656462 PR Review Comment: https://git.openjdk.org/jdk/pull/23238#discussion_r1926649258 From aivanov at openjdk.org Thu Jan 23 10:55:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 10:55:55 GMT Subject: Integrated: 8348303: Remove repeated 'a' from ListSelectionEvent In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:16:11 GMT, Alexey Ivanov wrote: > A trivial change which removes repeated ?a? from the [javadoc for the `ListSelectionEvent` class](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/event/ListSelectionEvent.html): > >> ?The change is limited to **a a** single inclusive interval.? > > In addition to the above, I > * expanded the wildcard imports, > * marked up `firstIndex` and `lastIndex` with `{@code}` in the class constructor parameter description (for consistency), and > * used a lower-case _?string?_? in the `@return` for `toString()` which aligns with the usage in [`Object.toString()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html#toString()). > > ? The word _?string?_ refers not to the `String` class but rather to a string in its literal meaning. This pull request has now been integrated. Changeset: 17df5151 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/17df51516aadf5ade73cf8d05c1be09772852b96 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8348303: Remove repeated 'a' from ListSelectionEvent Reviewed-by: azvegint, honkar, dmarkov, prr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/23240 From aivanov at openjdk.org Thu Jan 23 10:55:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 10:55:55 GMT Subject: Integrated: 8348308: Make fields of ListSelectionEvent final In-Reply-To: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> References: <3ba6ilBTLW--vPHEYvBXapKFp0KRR1dFNo24A18XZts=.69081408-1edf-4491-b0f5-2ebb381b10ba@github.com> Message-ID: On Wed, 22 Jan 2025 20:20:28 GMT, Alexey Ivanov wrote: > The fields of `ListSelectionEvent` are set in the constructor and are never modified, mark the fields???`firstIndex`, `lastIndex`, `isAdjusting`???with the `final` modifier. This pull request has now been integrated. Changeset: 89bfcb8d Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/89bfcb8db0877b89e9ac41f8330eb0a692ed77ae Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8348308: Make fields of ListSelectionEvent final Reviewed-by: honkar, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/23243 From aivanov at openjdk.org Thu Jan 23 11:12:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 11:12:47 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 09:33:33 GMT, Alexander Zvegintsev wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Use setLength to reset actualSelectionOrder >> >> Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com> > > test/jdk/java/awt/List/ItemEventTest/ItemEventTest.java line 93: > >> 91: || e.id == Event.LIST_SELECT)) { >> 92: logEvent("handleEvent: ", e.arg); >> 93: } > > Suggestion: > > if (e.target instanceof List) { > switch (e.id) { > case Event.LIST_SELECT > -> logEvent("handleEvent: LIST_SELECT ", e.arg); > case Event.LIST_DESELECT > -> logEvent("handleEvent: LIST_DESELECT ", e.arg); > } > } > > Not sure if this is really useful or not, but logging can be slightly improved. It makes the code more complicates but it adds no value? I've been trying to understand what's going on in [JDK-8345077](https://bugs.openjdk.org/browse/JDK-8345077) and why the test fails. The original test didn't give any clues. I added screenshots and event logging: the screenshots show the elements in the list get selected and deselected, yet no events are received via `handleEvent`???it's enough to diagnose the problem. That is the test fails, when it fails, because `handleEvent` is never called while items in the list are selected and deselected. The test always passes with `ItemListener`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23238#discussion_r1926800649 From aivanov at openjdk.org Thu Jan 23 11:09:23 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 11:09:23 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java [v2] In-Reply-To: References: Message-ID: > With this changeset, I update the `java/awt/List/ItemEventTest/ItemEventTest.java` test to improve its stability and analysis of failures of the test. > > 1. Use thread-safe `StringBuffer` for `actualSelectionOrder` to track selecting/deselecting items in the list. > 2. Enable `robot.setAutoWaitForIdle(true)` and remove `robot.waitForIdle()` from the test code. > 3. Log `handleEvent` and `ItemListener` which helps to identify test failures. > (In case of [JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221), `handleEvent` is never logged.) > 5. Take screenshot of the list on failure; > Optionally take screenshot after each mouse press+release if `-save` is passed as a parameter to the test. > > The updated test passes. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Use setLength to reset actualSelectionOrder Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23238/files - new: https://git.openjdk.org/jdk/pull/23238/files/5a54dcff..502ab45c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23238&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23238&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23238/head:pull/23238 PR: https://git.openjdk.org/jdk/pull/23238 From aivanov at openjdk.org Thu Jan 23 11:19:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 11:19:47 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 09:40:19 GMT, Alexander Zvegintsev wrote: >> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> Use setLength to reset actualSelectionOrder >> >> Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com> > > test/jdk/java/awt/List/ItemEventTest/ItemEventTest.java line 82: > >> 80: pack(); >> 81: setLocationRelativeTo(null); >> 82: setVisible(true); > > Didn't we decide that we should also now handle AWT calls on EDT? We did, as far as know? Yet it's a test for AWT component; AWT is a grey area which doesn't state its threading model clearly: is it thread-safe to call AWT components methods from threads other than EDT? I didn't look thoroughly at the bugs for which the test was written, using the main thread could be the purpose of the test. Other than that, I agree it's safer to create UI components on EDT and query their properties. And I'm not fan of extending `Frame`? I'd rather postpone further clean-up of the test to a later time? The test has been running successfully without many failures since 2016, so moving all the UI calls from the main thread to EDT isn't a priority. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23238#discussion_r1926809432 From duke at openjdk.org Thu Jan 23 11:43:22 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Thu, 23 Jan 2025 11:43:22 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Message-ID: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> This contains test fixes for the following issue in ScreenCaptureRobotTest.java ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. Testing: Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. ------------- Commit messages: - 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Changes: https://git.openjdk.org/jdk/pull/23264/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23264&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344581 Stats: 13 lines in 2 files changed: 12 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23264/head:pull/23264 PR: https://git.openjdk.org/jdk/pull/23264 From ihse at openjdk.org Thu Jan 23 12:27:45 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Jan 2025 12:27:45 GMT Subject: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 11:47:08 GMT, Joachim Kern wrote: > I reverted the changes in flags-cflags.m4 I still see them..? I think the changes you propose seem much better. Of course, in the end, the client team needs to agree to them to. The fp_pipewire.h looks trivially okay -- there seem to be no good reason to ever had that in a .h file that is just included in a .c file. The imageInitIDs.h changes looks good to me too. The solution previously employed was clever, but defies standard practice, and since it was only used there in the entire product, I think it is better to do as you propose. (Had we used that pattern everywhere, things would have been different.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2609679299 From azvegint at openjdk.org Thu Jan 23 13:26:46 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 23 Jan 2025 13:26:46 GMT Subject: RFR: 8348299: Update List/ItemEventTest/ItemEventTest.java [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 11:09:23 GMT, Alexey Ivanov wrote: >> With this changeset, I update the `java/awt/List/ItemEventTest/ItemEventTest.java` test to improve its stability and analysis of failures of the test. >> >> 1. Use thread-safe `StringBuffer` for `actualSelectionOrder` to track selecting/deselecting items in the list. >> 2. Enable `robot.setAutoWaitForIdle(true)` and remove `robot.waitForIdle()` from the test code. >> 3. Log `handleEvent` and `ItemListener` which helps to identify test failures. >> (In case of [JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221), `handleEvent` is never logged.) >> 5. Take screenshot of the list on failure; >> Optionally take screenshot after each mouse press+release if `-save` is passed as a parameter to the test. >> >> The updated test passes. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Use setLength to reset actualSelectionOrder > > Co-authored-by: Aleksandr Zvegintsev <77687766+azvegint at users.noreply.github.com> Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23238#pullrequestreview-2569858469 From duke at openjdk.org Thu Jan 23 13:35:57 2025 From: duke at openjdk.org (anass baya) Date: Thu, 23 Jan 2025 13:35:57 GMT Subject: RFR: 8340784 : Remove PassFailJFrame constructor with screenshots Message-ID: Remove PassFailJFrame constructor with screenshots since no test is using it ------------- Commit messages: - Update documentation - Handling annotations - Restore the detailed descripton - 2 - - Restore detailed description - Update test/jdk/java/awt/regtesthelpers/PassFailJFrame.java - Merge branch 'openjdk:master' into JDK-8340784 - Remove PassFailJFrame constructor with screenshots Changes: https://git.openjdk.org/jdk/pull/22873/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22873&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340784 Stats: 51 lines in 1 file changed: 0 ins; 42 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22873.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22873/head:pull/22873 PR: https://git.openjdk.org/jdk/pull/22873 From aivanov at openjdk.org Thu Jan 23 13:36:00 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 13:36:00 GMT Subject: RFR: 8340784 : Remove PassFailJFrame constructor with screenshots In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 03:02:51 GMT, anass baya wrote: > Remove PassFailJFrame constructor with screenshots since no test is using it Changes requested by aivanov (Reviewer). Nearly good. Please, also update the copyright year at the top of the file: 2024 ? 2025. Looks good. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 407: > 405: * the default values of {@value #ROWS} and {@value #COLUMNS} > 406: * for rows and columns. > 407: * The screenshot feature is not enabled, if you use this constructor. I think this line about the screenshot should be removed now. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 458: > 456: invokeAndWait(() -> createUI(title, instructions, testTimeOut, > 457: rows, columns)); > 458: } Please, keep the existing call to `invokeOnEDT`, just remove the last parameter from `createUI`: Suggestion: invokeOnEDT(() -> createUI(title, instructions, testTimeOut, rows, columns)); test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 473: > 471: * @see Builder Builder > 472: */ > 473: This blank line is redundant, follow the code style in the file where there's no blank line between the javadoc and the declaration. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 482: > 480: rows, columns)); > 481: } > 482: No trailing whitespace is allowed. The `jcheck` bot has marked it as an error and blocker. test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 510: > 508: builder.positionWindows > 509: .positionTestWindows(unmodifiableList(builder.testWindows), > 510: builder.instructionUIHandler)); Move the documentation to the constructor above. https://github.com/openjdk/jdk/blob/26b8b1e71f231d4601737a295dfed1ffd39f9b42/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L449-L451 Otherwise, you're removing the detailed documentation, which other constructors refer to. You may need to amend some sentences. ------------- PR Review: https://git.openjdk.org/jdk/pull/22873#pullrequestreview-2534741147 Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22873#pullrequestreview-2537104573 Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22873#pullrequestreview-2537962780 PR Review Comment: https://git.openjdk.org/jdk/pull/22873#discussion_r1907158578 PR Review Comment: https://git.openjdk.org/jdk/pull/22873#discussion_r1905703607 PR Review Comment: https://git.openjdk.org/jdk/pull/22873#discussion_r1907165044 PR Review Comment: https://git.openjdk.org/jdk/pull/22873#discussion_r1907165979 PR Review Comment: https://git.openjdk.org/jdk/pull/22873#discussion_r1905688661 From duke at openjdk.org Thu Jan 23 13:36:01 2025 From: duke at openjdk.org (anass baya) Date: Thu, 23 Jan 2025 13:36:01 GMT Subject: RFR: 8340784 : Remove PassFailJFrame constructor with screenshots In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 13:14:28 GMT, Alexey Ivanov wrote: >> Remove PassFailJFrame constructor with screenshots since no test is using it > > test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 473: > >> 471: * @see Builder Builder >> 472: */ >> 473: > > This blank line is redundant, follow the code style in the file where there's no blank line between the javadoc and the declaration. Done > test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 510: > >> 508: builder.positionWindows >> 509: .positionTestWindows(unmodifiableList(builder.testWindows), >> 510: builder.instructionUIHandler)); > > Move the documentation to the constructor above. > > https://github.com/openjdk/jdk/blob/26b8b1e71f231d4601737a295dfed1ffd39f9b42/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L449-L451 > > Otherwise, you're removing the detailed documentation, which other constructors refer to. You may need to amend some sentences. thank you for your review ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22873#discussion_r1907379024 PR Review Comment: https://git.openjdk.org/jdk/pull/22873#discussion_r1906140632 From jkern at openjdk.org Thu Jan 23 13:48:06 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 23 Jan 2025 13:48:06 GMT Subject: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors [v3] In-Reply-To: References: Message-ID: > We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan. > Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror. > One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found: > /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions] > 36 | IMGEXTERN jfieldID g_BImgRasterID; > | ^ > From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g. > imageInitIDs.h:36:20 > 36 extern jfieldID g_BImgRasterID; > and the corresponding c-File > jfieldID g_BImgRasterID; > > The other possible solution would be to compile everything with > -Wno-tentative-definitions > which could be set in flags-cflags.m4, if compiling with clang 17. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: remove old solution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23236/files - new: https://git.openjdk.org/jdk/pull/23236/files/5a228434..19ebd62c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23236&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23236&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23236/head:pull/23236 PR: https://git.openjdk.org/jdk/pull/23236 From azvegint at openjdk.org Thu Jan 23 14:08:51 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 23 Jan 2025 14:08:51 GMT Subject: RFR: 8340784 : Remove PassFailJFrame constructor with screenshots In-Reply-To: References: Message-ID: <91eIn7yQsg_-Q7Obz0qvnxp6Yfteff6Tk-m3fQiP1h4=.d58b3fce-ad43-420f-89e6-76cec9247bf1@github.com> On Tue, 24 Dec 2024 03:02:51 GMT, anass baya wrote: > Remove PassFailJFrame constructor with screenshots since no test is using it Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22873#pullrequestreview-2569960923 From ihse at openjdk.org Thu Jan 23 14:55:49 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Jan 2025 14:55:49 GMT Subject: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 13:48:06 GMT, Joachim Kern wrote: >> We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan. >> Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror. >> One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found: >> /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions] >> 36 | IMGEXTERN jfieldID g_BImgRasterID; >> | ^ >> From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g. >> imageInitIDs.h:36:20 >> 36 extern jfieldID g_BImgRasterID; >> and the corresponding c-File >> jfieldID g_BImgRasterID; >> >> The other possible solution would be to compile everything with >> -Wno-tentative-definitions >> which could be set in flags-cflags.m4, if compiling with clang 17. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > remove old solution ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23236#pullrequestreview-2570094539 From aivanov at openjdk.org Thu Jan 23 15:22:01 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 15:22:01 GMT Subject: Integrated: 8348299: Update List/ItemEventTest/ItemEventTest.java In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:45:17 GMT, Alexey Ivanov wrote: > With this changeset, I update the `java/awt/List/ItemEventTest/ItemEventTest.java` test to improve its stability and analysis of failures of the test. > > 1. Use thread-safe `StringBuffer` for `actualSelectionOrder` to track selecting/deselecting items in the list. > 2. Enable `robot.setAutoWaitForIdle(true)` and remove `robot.waitForIdle()` from the test code. > 3. Log `handleEvent` and `ItemListener` which helps to identify test failures. > (In case of [JDK-8204221](https://bugs.openjdk.org/browse/JDK-8204221), `handleEvent` is never logged.) > 5. Take screenshot of the list on failure; > Optionally take screenshot after each mouse press+release if `-save` is passed as a parameter to the test. > > The updated test passes. This pull request has now been integrated. Changeset: 605b53e4 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/605b53e4f8857c58a72fa361f8787c563d6dab90 Stats: 98 lines in 1 file changed: 44 ins; 8 del; 46 mod 8348299: Update List/ItemEventTest/ItemEventTest.java Use thread-safe StringBuffer to track selecting/deselecting items. Use auto waitForIdle for all events. Log handleEvent and ItemListener. Take screenshot of the list on failure; Optionally take screenshot after each mouse press+release. Reviewed-by: azvegint, prr, kizune ------------- PR: https://git.openjdk.org/jdk/pull/23238 From aivanov at openjdk.org Thu Jan 23 15:22:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 23 Jan 2025 15:22:47 GMT Subject: RFR: 8340784 : Remove PassFailJFrame constructor with screenshots In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 03:02:51 GMT, anass baya wrote: > Remove PassFailJFrame constructor with screenshots since no test is using it The feature remains available when using the recommended builder pattern to create an instance of `PassFailJFrame`. This is to discourage using constructors directly. It's easier to remove the constructor when it's not used at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22873#issuecomment-2610095467 From duke at openjdk.org Thu Jan 23 15:32:48 2025 From: duke at openjdk.org (duke) Date: Thu, 23 Jan 2025 15:32:48 GMT Subject: RFR: 8340784 : Remove PassFailJFrame constructor with screenshots In-Reply-To: References: Message-ID: <3a_gA_ANnjW7I8SjR5-ip2S08y6URdaWM0h4BQeKmRo=.5afa39c4-02b6-4a3c-b21a-96eb2f67bc9a@github.com> On Tue, 24 Dec 2024 03:02:51 GMT, anass baya wrote: > Remove PassFailJFrame constructor with screenshots since no test is using it @anass-baya Your change (at version 13570b6a67b29fe2bd42b3ce6bd9a91712277722) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22873#issuecomment-2610121369 From hannesw at openjdk.org Thu Jan 23 16:18:46 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 23 Jan 2025 16:18:46 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 20:35:22 GMT, Phil Race wrote: >> Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that. >> >> @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording? > > There's not a great number of "good" examples of this in the JDK, so probably OK except it > seems like most cases will do it like a normal javadoc method so you'd want an @param tag too. > > note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others I've created a CSR with a slightly modified version of the text proposed in this PR: https://bugs.openjdk.org/browse/JDK-8348408 Other doc tags such as `@param` and `@throws` are inherited from the overridden method. Also, this is the only change in this PR that modifies the serialization spec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1927261011 From honkar at openjdk.org Thu Jan 23 16:43:53 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 23 Jan 2025 16:43:53 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Runtime Exception added @jayathirthrao @aivanov-jdk Can you please have another look and review the updated code when you get a chance? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2610372008 From jdv at openjdk.org Thu Jan 23 17:41:01 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 23 Jan 2025 17:41:01 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Runtime Exception added Marked as reviewed by jdv (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23044#pullrequestreview-2570579768 From duke at openjdk.org Thu Jan 23 20:24:50 2025 From: duke at openjdk.org (duke) Date: Thu, 23 Jan 2025 20:24:50 GMT Subject: RFR: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected [v6] In-Reply-To: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> References: <_0VnAqNU2j4bo4-3nxVHk7vEJRotA7UB6mVR1cz6AUs=.74c99982-a249-4467-bdd7-d127ec1c01f2@github.com> Message-ID: On Fri, 17 Jan 2025 18:22:57 GMT, Rajat Mahajan wrote: >> **Issue:** >> AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. >> >> **Solution:** >> I have added the exception handling code to take care that the handles are properly destroyed and not leaked. >> >> **Testing:** >> I have tested the code to make sure there are no regressions caused by this. > > Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision: > > check using not equal to NULL to match the rest of the code in the function @rajamah Your change (at version 2f47a554e93a64869cc560fb89790b3475763557) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22932#issuecomment-2610941667 From prr at openjdk.org Thu Jan 23 20:33:53 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 23 Jan 2025 20:33:53 GMT Subject: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 13:48:06 GMT, Joachim Kern wrote: >> We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan. >> Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror. >> One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found: >> /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions] >> 36 | IMGEXTERN jfieldID g_BImgRasterID; >> | ^ >> From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g. >> imageInitIDs.h:36:20 >> 36 extern jfieldID g_BImgRasterID; >> and the corresponding c-File >> jfieldID g_BImgRasterID; >> >> The other possible solution would be to compile everything with >> -Wno-tentative-definitions >> which could be set in flags-cflags.m4, if compiling with clang 17. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > remove old solution If absolutely nothing else needs fp_pipewire.h I guess that ought to be OK ... but this is very new code. I'd like @azvegint to look at this as he may have had some reason that isn't obvious. I don't follow why you found it necessary to remove the include statement from the .c file in the image case ? And I agree that there was actually nothing wrong with the existing code. The compiler must have been confused. And other than *building* what testing was done with these changes ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2610956518 From rmahajan at openjdk.org Thu Jan 23 20:55:51 2025 From: rmahajan at openjdk.org (Rajat Mahajan) Date: Thu, 23 Jan 2025 20:55:51 GMT Subject: Integrated: 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 17:38:24 GMT, Rajat Mahajan wrote: > **Issue:** > AwtWindow::SetIconData leaks the old icon handles in hOldIcon and hOldIconSm if CreateIconFromRaster raises an exception. Additionally, an exception is checked only after the first call to CreateIconFromRaster. > > **Solution:** > I have added the exception handling code to take care that the handles are properly destroyed and not leaked. > > **Testing:** > I have tested the code to make sure there are no regressions caused by this. This pull request has now been integrated. Changeset: 48ece072 Author: Rajat Mahajan URL: https://git.openjdk.org/jdk/commit/48ece0721489c1b357aaa81e89fe59f486079d15 Stats: 42 lines in 1 file changed: 35 ins; 3 del; 4 mod 8282862: AwtWindow::SetIconData leaks old icon handles if an exception is detected Reviewed-by: aivanov, dmarkov, prr, honkar, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/22932 From duke at openjdk.org Thu Jan 23 22:10:44 2025 From: duke at openjdk.org (anass baya) Date: Thu, 23 Jan 2025 22:10:44 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values Message-ID: Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. We used an existing test and took the following considerations into account for Windows: - On Windows, undecorated maximized frames are placed over the taskbar. - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). - Consider the fractional part after scaling. ------------- Commit messages: - Remove trailing whitespace. - delete whitespaces - annotations adjustmentx - Test to verify that java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns xcorrect values - Remove extralines - Screen number 0 is not always the primary screen - Screen number 0 is not always the primary screen. Changes: https://git.openjdk.org/jdk/pull/23183/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6899304 Stats: 72 lines in 2 files changed: 38 ins; 20 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From duke at openjdk.org Thu Jan 23 22:29:22 2025 From: duke at openjdk.org (anass baya) Date: Thu, 23 Jan 2025 22:29:22 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v2] In-Reply-To: References: Message-ID: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. anass baya has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23183/files - new: https://git.openjdk.org/jdk/pull/23183/files/264f1113..ec467e34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From ihse at openjdk.org Thu Jan 23 23:11:47 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Jan 2025 23:11:47 GMT Subject: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 20:31:03 GMT, Phil Race wrote: > The compiler must have been confused. Definitely, but I don't blame it. Look at this construct: #define IMGEXTERN #include "imageInitIDs.h" There is really no way for the poor compiler to understand that in this case, it was really intentional to define variables in a .h file. And once again, this is a clever construct. If we had used it in all our code base I would not have complained. But when we do it in just a single place, it breaks expectations, and it is better to align the code to how we do everywhere else. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2611199045 From honkar at openjdk.org Thu Jan 23 23:34:46 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 23 Jan 2025 23:34:46 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 22:29:22 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 1940: > 1938: { > 1939: MONITORINFO *miInfo = AwtWin32GraphicsDevice::GetMonitorInfo(screenNum); > 1940: if (miInfo) { Based on [GetMonitorInfo](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getmonitorinfoa) API doc, it seems fine to use this API to query monitor info for both primary and non-primary monitors but I'm not sure why original code used `SystemParametersInfo()` specifically instead of `GetMonitorInfo()` for primary monitor. In case the screen insets need to be calculated differently for primary and non-primary then MonitorInfo (`miInfo.dwFlag`) can be used to check if it is primary monitor or not, instead of relying on screen number as follows MONITORINFO *miInfo = AwtWin32GraphicsDevice::GetMonitorInfo(screenNum); if (MONITORINFOF_PRIMARY & miInfo ->dwFlags) { // calculate screen insets for Primary monitor } else { //calculate screen insets for NON-Primary monitor } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1927818392 From achung at openjdk.org Thu Jan 23 23:46:04 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 23 Jan 2025 23:46:04 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v5] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: robot multimonitor fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22781/files - new: https://git.openjdk.org/jdk/pull/22781/files/f9b4d61f..57341658 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=03-04 Stats: 216 lines in 2 files changed: 56 ins; 20 del; 140 mod Patch: https://git.openjdk.org/jdk/pull/22781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781 PR: https://git.openjdk.org/jdk/pull/22781 From achung at openjdk.org Fri Jan 24 00:25:14 2025 From: achung at openjdk.org (Alisen Chung) Date: Fri, 24 Jan 2025 00:25:14 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: init finX, finY ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22781/files - new: https://git.openjdk.org/jdk/pull/22781/files/57341658..0eb4226f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781 PR: https://git.openjdk.org/jdk/pull/22781 From honkar at openjdk.org Fri Jan 24 00:25:15 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 24 Jan 2025 00:25:15 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v5] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 23:46:04 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 one additional commit since the last revision: > > robot multimonitor fix src/java.desktop/share/classes/java/awt/Robot.java line 269: > 267: *

> 268: * It is allowed to use only a combination of valid values as a {@code buttons} parameter. > 269: * A valid combination consists of {@code InputEvent.BUTTON1_DOWN_MASK}, Spacing looks off here as well. src/java.desktop/share/classes/java/awt/Robot.java line 323: > 321: * > 322: * @param buttons the Button mask; a combination of one or more > 323: * mouse button masks. Spacing looks off on javadocs ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1927916121 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1927915281 From serb at openjdk.org Fri Jan 24 00:44:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 24 Jan 2025 00:44:50 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Sat, 18 Jan 2025 00:01:05 GMT, Harshitha Onkar wrote: >We are choosing to add these validation checks to jdk irrespective for whether lcms validates or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927930013 From serb at openjdk.org Fri Jan 24 00:54:59 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 24 Jan 2025 00:54:59 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: <-nQZDCDj9hHsSMssDW0rKVqikuyK1T6SSLnICLVpw5k=.c2fcb380-1cd2-439a-8724-c00d677e3d81@github.com> References: <-nQZDCDj9hHsSMssDW0rKVqikuyK1T6SSLnICLVpw5k=.c2fcb380-1cd2-439a-8724-c00d677e3d81@github.com> Message-ID: On Sat, 18 Jan 2025 00:02:06 GMT, Harshitha Onkar wrote: >>> Interesting, this exception is not specified for this method. >> >> What do you mean? >> >> The javadoc is: >> >> * @throws IllegalArgumentException If the byte array does not contain valid >> * ICC Profile data >> >> The error message is not specified, the error message can be changed to be more specific to the case where it's thrown. > >> Interesting, this exception is not specified for this method. > > We were not able follow what you mean, can you please elaborate? I think I accidentally opened the source code for 8, which is missing throws ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927935028 From serb at openjdk.org Fri Jan 24 00:55:00 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 24 Jan 2025 00:55:00 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Fri, 24 Jan 2025 00:41:42 GMT, Sergey Bylokhov wrote: >> @mrserb >> The location mentioned in LCMSTransform involves creating a new color space transform using 2 or more profiles and DOES NOT involve creating or updating a profile. Moreover LCMSTrandorm throws CMMException for invalid rendering intents so this case won't be an issue. >> >>> maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods? >> >> We are choosing to add these validation checks to jdk irrespective for whether lcms validates or not. > >>We are choosing to add these validation checks to jdk irrespective for whether lcms validates or not. > > I don't think this is right. It's not a javase spec, and there may be a reason why the most common library for icc profiles accepts thad data. We shouldn't be more strict than that, it will limit java applications compared to the alternatives. Did the upstream provide any feedback/comments about this validation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927936243 From serb at openjdk.org Fri Jan 24 01:00:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 24 Jan 2025 01:00:50 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Fri, 24 Jan 2025 00:52:04 GMT, Sergey Bylokhov wrote: >>>We are choosing to add these validation checks to jdk irrespective for whether lcms validates or not. >> >> I don't think this is right. It's not a javase spec, and there may be a reason why the most common library for icc profiles accepts thad data. We shouldn't be more strict than that, it will limit java applications compared to the alternatives. > > Did the upstream provide any feedback/comments about this validation? BTW >Typically, the user or application will set the rendering intent dynamically at runtime or embedding time. Therefore, this flag may not have any meaning until the profile is used in some context, e.g. in a DeviceLink or an embedded source profile." Why this usecase should not be covered by the java? As of the current version of patch it will not be possible to load the profile and then set the intent, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927939786 From serb at openjdk.org Fri Jan 24 01:05:59 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 24 Jan 2025 01:05:59 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Runtime Exception added src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1155: > 1153: throw new IllegalArgumentException("Invalid header data"); > 1154: } > 1155: getProfileClass(data); Can any of these fields have custom values (not covered by java constants inside iccCStoJCS) ??that can still be used for color transformation? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927944871 From serb at openjdk.org Fri Jan 24 01:16:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 24 Jan 2025 01:16:52 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: <1wYevaob-VOndOuORCkQnDO8bzgQBhvSpmqVrdcL28w=.9e0c228b-cf66-40c9-b203-37e1784bf410@github.com> References: <1wYevaob-VOndOuORCkQnDO8bzgQBhvSpmqVrdcL28w=.9e0c228b-cf66-40c9-b203-37e1784bf410@github.com> Message-ID: On Tue, 21 Jan 2025 19:48:52 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData.java line 39: >> >>> 37: >>> 38: public class ValidateICCHeaderData { >>> 39: private static ICC_Profile profile; >> >> the change will also affect serialization, the test should check that code path. > > @mrserb @prrace > Added deserialization test case (as TestCase#15). > invalidSRGB.icc was serialized on JDK 21 and the same .icc profile was deserialized here. > As expected IAE is thrown in this case. > > @mrserb All the previous comments have been addressed. Can you please re-review the latest src code and test changes? The new test is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927951109 From honkar at openjdk.org Fri Jan 24 01:23:51 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 24 Jan 2025 01:23:51 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Fri, 24 Jan 2025 00:57:47 GMT, Sergey Bylokhov wrote: >> Did the upstream provide any feedback/comments about this validation? > > BTW >>Typically, the user or application will set the rendering intent dynamically at runtime or embedding time. Therefore, this flag may not have any meaning until the profile is used in some context, e.g. in a DeviceLink or an embedded source profile." > > Why this usecase should not be covered by the java? As of the current version of patch it will not be possible to load the profile and then set the intent, right? > I don't think this is right. It's not a javase spec, and there may be a reason why the most common library for icc profiles accepts thad data. We shouldn't be more strict than that, it will limit java applications compared to the alternatives. The path that you mentioned in LCMSTransformfor RenderingIntent involves creating a new color space transform using 2 or more profiles and does not involve creating or updating a profile. Moreover when a random value is added for rendering intent in LCMSTransform as below, LCMS throws CMMException , but when I change to any other value (ICC Intent or Non-ICC Intents as specified in the table 41 above) it passes. If LCMS validates the Rendering Intent while creating a new color space transform then wouldn't it be better to validate it while creating/updating a ICC_Profile. And as for the different values specified in ICC_Spec vs LCMS API doc, @prrace confirmed that jdk is required to follow ICC_Spec. > Did the upstream provide any feedback/comments about this validation? Discussed with @prrace, in this case it was decided that contacting upstream is not required since we are choosing to do validations in any case (whether or not LCMS validates). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927953851 From honkar at openjdk.org Fri Jan 24 01:53:49 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 24 Jan 2025 01:53:49 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Fri, 24 Jan 2025 00:57:47 GMT, Sergey Bylokhov wrote: >> Did the upstream provide any feedback/comments about this validation? > > BTW >>Typically, the user or application will set the rendering intent dynamically at runtime or embedding time. Therefore, this flag may not have any meaning until the profile is used in some context, e.g. in a DeviceLink or an embedded source profile." > > Why this usecase should not be covered by the java? As of the current version of patch it will not be possible to load the profile and then set the intent, right? @mrserb > there may be a reason why the most common library for icc profiles accepts thad data. We shouldn't be more strict than that, it will limit java applications compared to the alternatives. I see your point but color management engines may have different implementations (LCMS or KCMS) and ICC Specification is a standard. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1927976507 From azvegint at openjdk.org Fri Jan 24 05:43:51 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 24 Jan 2025 05:43:51 GMT Subject: Integrated: 8347008: beancontext package spec does not clearly explain why the API is deprecated In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 14:28:26 GMT, Alexander Zvegintsev wrote: > The beancontext package description or the deprecation text in the classes doesn't say anything about why the API is deprecated. > A few more words have been added in this regard. This pull request has now been integrated. Changeset: 416d4694 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/416d46947ca926a31fbf9e97d0e7c320063ecfb2 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod 8347008: beancontext package spec does not clearly explain why the API is deprecated Reviewed-by: aivanov, prr ------------- PR: https://git.openjdk.org/jdk/pull/23216 From tr at openjdk.org Fri Jan 24 06:30:55 2025 From: tr at openjdk.org (Tejesh R) Date: Fri, 24 Jan 2025 06:30:55 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 07:02:21 GMT, Prasanta Sadhukhan wrote: >> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below >> >> ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) >> >> Native windows progressbar renders without leaving any gap as can be seen here >> >> ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) >> >> so the padding is removed to render the progressbar similar to windows native and it is rendered properly >> >> ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > summary update I have a couple of observations here. 1. The suggested solution removes the gap completely as referenced from Windows OS progress bar, yet the border line is not visible which is grey in color. 2. If you can observe the "BAD" progress bar, the bottom border is visible, where as its not in "GOOD" progress bar. It's like the whole paint is shifted by pixel to top. 3. Probably the issue of rounding-off still exists, if we address this issue then the gap offset might get corrected (Not 100% sure though). ------------- PR Review: https://git.openjdk.org/jdk/pull/23227#pullrequestreview-2571740262 From psadhukhan at openjdk.org Fri Jan 24 06:40:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 24 Jan 2025 06:40:50 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Fri, 24 Jan 2025 06:27:43 GMT, Tejesh R wrote: > 2. If you can observe the "BAD" progress bar, the bottom border is visible, where as its not in "GOOD" progress bar. It's like the whole paint is shifted by pixel to top. The "GOOD" progressbar size is 100,21 whereas "BAD" progressbar size is 100,22 as per testcase so I guess its expected to be 1px less.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2611711793 From azvegint at openjdk.org Fri Jan 24 06:54:45 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 24 Jan 2025 06:54:45 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS In-Reply-To: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Thu, 23 Jan 2025 11:37:23 GMT, Naveen Narayanan wrote: > This contains test fixes for the following issue in ScreenCaptureRobotTest.java > > ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. > > Testing: > Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. test/jdk/java/awt/Robot/ScreenCaptureRobotTest.java line 118: > 116: IMAGE_WIDTH, IMAGE_HEIGHT); > 117: > 118: robot.mouseMove(0,0); I guess it is safer to move this `mouseMove` call right after the Robot creation, so in case the system is slow and shows a mouse cursor on the screenshot, there is a delay between the mouse movement and the screen capture. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23264#discussion_r1928164834 From tr at openjdk.org Fri Jan 24 06:58:51 2025 From: tr at openjdk.org (Tejesh R) Date: Fri, 24 Jan 2025 06:58:51 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Fri, 24 Jan 2025 06:38:36 GMT, Prasanta Sadhukhan wrote: > > ``` > > 2. If you can observe the "BAD" progress bar, the bottom border is visible, where as its not in "GOOD" progress bar. It's like the whole paint is shifted by pixel to top. > > ``` > > The "GOOD" progressbar size is 100,21 whereas "BAD" progressbar size is 100,22 as per testcase so I guess its expected to be 1px less.. But the progress color which is blue should be filled irrespective of height right ? meaning in "GOOD" its filled from top border till bottom, whereas in "BAD" its filled from top till one pixel above bottom which makes the bottom border visible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2611731461 From duke at openjdk.org Fri Jan 24 07:03:54 2025 From: duke at openjdk.org (anass baya) Date: Fri, 24 Jan 2025 07:03:54 GMT Subject: Integrated: 8340784 : Remove PassFailJFrame constructor with screenshots In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 03:02:51 GMT, anass baya wrote: > Remove PassFailJFrame constructor with screenshots since no test is using it This pull request has now been integrated. Changeset: 50ca4504 Author: anass baya Committer: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/50ca450417a5da7d4c6c08154515b8407bf656e8 Stats: 51 lines in 1 file changed: 0 ins; 42 del; 9 mod 8340784: Remove PassFailJFrame constructor with screenshots Reviewed-by: aivanov, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/22873 From abhiscxk at openjdk.org Fri Jan 24 07:10:49 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 24 Jan 2025 07:10:49 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS In-Reply-To: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Thu, 23 Jan 2025 11:37:23 GMT, Naveen Narayanan wrote: > This contains test fixes for the following issue in ScreenCaptureRobotTest.java > > ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. > > Testing: > Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. @Naveenam-Oracle As per JBS comment, test was failing intermittently where the text was not drawn in image. Did this issue happen again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23264#issuecomment-2611750407 From azvegint at openjdk.org Fri Jan 24 07:12:47 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 24 Jan 2025 07:12:47 GMT Subject: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 13:48:06 GMT, Joachim Kern wrote: >> We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan. >> Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror. >> One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found: >> /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions] >> 36 | IMGEXTERN jfieldID g_BImgRasterID; >> | ^ >> From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g. >> imageInitIDs.h:36:20 >> 36 extern jfieldID g_BImgRasterID; >> and the corresponding c-File >> jfieldID g_BImgRasterID; >> >> The other possible solution would be to compile everything with >> -Wno-tentative-definitions >> which could be set in flags-cflags.m4, if compiling with clang 17. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > remove old solution I did a quick testing, and it seems to work fine. > If absolutely nothing else needs fp_pipewire.h I guess that ought to be OK ... but this is very new code. I'd like @azvegint to look at this as he may have had some reason that isn't obvious. No particular reason, it was just easier to keep function pointers in a separate file at the beginning of development, and then it stayed that way. ------------- Marked as reviewed by azvegint (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23236#pullrequestreview-2571810940 From jkern at openjdk.org Fri Jan 24 09:57:48 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 24 Jan 2025 09:57:48 GMT Subject: RFR: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 20:31:03 GMT, Phil Race wrote: >> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: >> >> remove old solution > > If absolutely nothing else needs fp_pipewire.h I guess that ought to be OK ... but this is very new code. > I'd like @azvegint to look at this as he may have had some reason that isn't obvious. > > I don't follow why you found it necessary to remove the include statement from the .c file in the image case ? > And I agree that there was actually nothing wrong with the existing code. The compiler must have been confused. > > And other than *building* what testing was done with these changes ? @prrace Is this OK for you now after Aleksandr has tested and approved the PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23236#issuecomment-2612112103 From hannesw at openjdk.org Fri Jan 24 10:58:24 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 24 Jan 2025 10:58:24 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: > Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Update @serialData text to CSR-approved version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22980/files - new: https://git.openjdk.org/jdk/pull/22980/files/c4be23a7..b686fb10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22980&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22980&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22980/head:pull/22980 PR: https://git.openjdk.org/jdk/pull/22980 From psadhukhan at openjdk.org Fri Jan 24 12:24:02 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 24 Jan 2025 12:24:02 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v3] In-Reply-To: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: > JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below > > ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) > > Native windows progressbar renders without leaving any gap as can be seen here > > ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) > > so the padding is removed to render the progressbar similar to windows native and it is rendered properly > > ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: hidpi support for line stroke width/height ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23227/files - new: https://git.openjdk.org/jdk/pull/23227/files/abb28511..6ec1d16b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23227&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23227&range=01-02 Stats: 14 lines in 1 file changed: 9 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23227/head:pull/23227 PR: https://git.openjdk.org/jdk/pull/23227 From psadhukhan at openjdk.org Fri Jan 24 12:24:02 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 24 Jan 2025 12:24:02 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 07:02:21 GMT, Prasanta Sadhukhan wrote: >> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below >> >> ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) >> >> Native windows progressbar renders without leaving any gap as can be seen here >> >> ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) >> >> so the padding is removed to render the progressbar similar to windows native and it is rendered properly >> >> ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > summary update Actually there is no "border"..the gray "border" is a Skin image drawn using drawImage and the blue progressbar inside it is a drawline with set stroke of height "preferredHeight" as set by application and I have modified to use scaling factor for the line width/height ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2612399711 From aivanov at openjdk.org Fri Jan 24 14:02:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 14:02:48 GMT Subject: RFR: 8348170: Unnecessary Hashtable usage in CSS.styleConstantToCssMap In-Reply-To: References: Message-ID: <0a24kKaLBT8NbauSVGzM-QAwU1QzksFdsw50nXrVCec=.fdd5ad68-1fc9-4364-9c61-e21579dde386@github.com> On Thu, 16 Jan 2025 11:53:18 GMT, Andrey Turbanov wrote: > There is a field `javax.swing.text.html.CSS#styleConstantToCssMap` which uses legacy `Hashtable` class. > As this map is read-only and all its content is initialized in `` we can safely use immutable `Map` instead. The tests are green. Sorry for the delay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23149#issuecomment-2612598635 From aturbanov at openjdk.org Fri Jan 24 14:08:48 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 24 Jan 2025 14:08:48 GMT Subject: RFR: 8348170: Unnecessary Hashtable usage in CSS.styleConstantToCssMap In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 11:53:18 GMT, Andrey Turbanov wrote: > There is a field `javax.swing.text.html.CSS#styleConstantToCssMap` which uses legacy `Hashtable` class. > As this map is read-only and all its content is initialized in `` we can safely use immutable `Map` instead. Thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23149#issuecomment-2612609426 From aturbanov at openjdk.org Fri Jan 24 14:08:49 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 24 Jan 2025 14:08:49 GMT Subject: Integrated: 8348170: Unnecessary Hashtable usage in CSS.styleConstantToCssMap In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 11:53:18 GMT, Andrey Turbanov wrote: > There is a field `javax.swing.text.html.CSS#styleConstantToCssMap` which uses legacy `Hashtable` class. > As this map is read-only and all its content is initialized in `` we can safely use immutable `Map` instead. This pull request has now been integrated. Changeset: 56a18779 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/56a187798991cb6dede62ac166cbdca7a654cf7f Stats: 36 lines in 1 file changed: 2 ins; 0 del; 34 mod 8348170: Unnecessary Hashtable usage in CSS.styleConstantToCssMap Reviewed-by: azvegint, aivanov ------------- PR: https://git.openjdk.org/jdk/pull/23149 From hannesw at openjdk.org Fri Jan 24 14:42:47 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 24 Jan 2025 14:42:47 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 16:16:03 GMT, Hannes Walln?fer wrote: >> There's not a great number of "good" examples of this in the JDK, so probably OK except it >> seems like most cases will do it like a normal javadoc method so you'd want an @param tag too. >> >> note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others > > I've created a CSR with a slightly modified version of the text proposed in this PR: > https://bugs.openjdk.org/browse/JDK-8348408 > > Other doc tags such as `@param` and `@throws` are inherited from the overridden method. Also, this is the only change in this PR that modifies the serialization spec. CSR was approved, and I updated the PR with the slightly modified spec text from the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1928785006 From aivanov at openjdk.org Fri Jan 24 16:52:59 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 16:52:59 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay Message-ID: Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay. Use `Util.hitMnemonics` instead of custom code to handle macOS. I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI. ------------- Commit messages: - 8342524: Use latch in AbstractButton/bug6298940.java instead of delay Changes: https://git.openjdk.org/jdk/pull/23301/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23301&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342524 Stats: 89 lines in 1 file changed: 89 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23301/head:pull/23301 PR: https://git.openjdk.org/jdk/pull/23301 From aivanov at openjdk.org Fri Jan 24 17:39:03 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 17:39:03 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v4] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 03:42:56 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > getLocationOnScreen on EDT Looks good to me. I've run the test; both tests fail without the fix and *pass with the fix*. test/jdk/javax/swing/JPopupMenu/FocusablePopupDismissTest.java line 101: > 99: JFrame frame = new JFrame("FocusablePopupDismissTest"); > 100: JButton button = new JButton("Click me"); > 101: frame.add(button); May I suggest making the test window larger? You can make the button larger by setting its size or the size of the frame. Alternatively, you can add a wrapper panel with border around it: @@ -33,10 +33,12 @@ * @run main/manual FocusablePopupDismissTest */ +import javax.swing.BorderFactory; import javax.swing.JButton; import javax.swing.JFrame; import javax.swing.JMenu; import javax.swing.JMenuItem; +import javax.swing.JPanel; import javax.swing.JPopupMenu; import javax.swing.JTextField; import java.awt.Window; @@ -97,8 +99,12 @@ static JMenu getMenuWithMenuItem(boolean isSubmenuItemFocusable, String text) { static List createTestUI() { JFrame frame = new JFrame("FocusablePopupDismissTest"); + JPanel wrapper = new JPanel(); + wrapper.setBorder(BorderFactory.createEmptyBorder(16, 16, 16, 16)); + JButton button = new JButton("Click me"); - frame.add(button); + wrapper.add(button); + frame.add(wrapper); button.addActionListener(e -> { JPopupMenu popupMenu = new JPopupMenu(); The test becomes easier to use? Otherwise the small test UI frame gets somewhat lost near the large instructions. test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 108: > 106: Point frameLocation = waitAndGetLocationOnEDT(frame); > 107: robot.mouseMove(frameLocation.x + frame.getWidth() / 2, > 108: frameLocation.y + frame.getHeight() / 2); Then `frame.getWidth()` and `frame.getHeight()` should also be called on EDT, shouldn't they? test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 116: > 114: robot.mouseMove(menuLocation.x + 5, menuLocation.y + 5); > 115: > 116: // give popup some time to disappear (in case of failure) Suggestion: // Give popup some time to disappear (in case of failure) test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 121: > 119: > 120: try { > 121: waitTillShown(popupMenu, 500); Huh, I see you're using `waitTillShown` for other purposes too? I wonder if a popup listener would do better. But then, it's over-thinking and over-engineering? ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22729#pullrequestreview-2573182808 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1928998212 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1929022755 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1929024068 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1929026835 From aivanov at openjdk.org Fri Jan 24 17:39:03 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 17:39:03 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v4] In-Reply-To: References: <33Y5-ZPHAEBEv1_3fv9AW0MoUdvsOTDzC3xnIdJFMb8=.49a266f9-c7bd-4b44-834a-f4d7c36eac69@github.com> <5G8aojnM5PfSbcoPMw031e81QfMKbCkHqJ6uPzqbvWI=.04447e9f-72ae-40d3-8147-d6e558f07ca8@github.com> Message-ID: On Tue, 21 Jan 2025 11:25:20 GMT, Alexander Zvegintsev wrote: > Not really, because a few lines after we ungrab the input, so all the popup menu will be dismissed, performing cleanups in their `hide()` and `setVisible()` methods. This answers my question. I guess I got lost or distracted and forgot about this kind of clean-up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1929001676 From aivanov at openjdk.org Fri Jan 24 17:41:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 17:41:48 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v3] In-Reply-To: <7vihW3t4dMC3lWy0T4HdPL04LTIKpqo1DuL-7Jr9y6U=.536a97f9-1104-4b31-86e5-1ebbd30880ef@github.com> References: <7vihW3t4dMC3lWy0T4HdPL04LTIKpqo1DuL-7Jr9y6U=.536a97f9-1104-4b31-86e5-1ebbd30880ef@github.com> Message-ID: On Wed, 22 Jan 2025 19:57:04 GMT, Harshitha Onkar wrote: >> We wait long enough, so if it throws the `IIlegalCompnentStateException` something is not right anyway. >> >> But I updated it to `waitTillShown` + get location on EDT to save some test execution time where it is possible. > > Sounds good. > We wait long enough, so if it throws the `IIlegalCompnentStateException` something is not right anyway. I liked this way better. > But I updated it to `waitTillShown` + get location on EDT to save some test execution time where it is possible. For what it's worth, we have a utility method for this? Yet I couldn't quickly find it, I found quite a few tests which implement it themselves. I'd prefer using *an event-based approach* rather than delaying in a loop: releasing a latch when the frame receives focus. At the same time, [a recent discussion](https://github.com/openjdk/jdk/pull/21475#discussion_r1809317633) proved that `robot.waitForIdle()` is enough? especially if it's followed by a delay. (Hence, [I removed the focus latch](https://github.com/openjdk/jdk/pull/21475/commits/d16918a43d397fc889172265fe9b950301073401).) One more reason why I like `waitForIdle` + `delay` better is that the code is shorter. And *you still need `robot.waitForIdle()` any way.* ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1929032424 From aivanov at openjdk.org Fri Jan 24 17:45:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 17:45:47 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v4] In-Reply-To: <-gI4SX9zSR5o--I9rg8QZWu9_EohY2ExFQUBINRP-jo=.d492084c-def1-4444-ab37-e79e04f57a7b@github.com> References: <-gI4SX9zSR5o--I9rg8QZWu9_EohY2ExFQUBINRP-jo=.d492084c-def1-4444-ab37-e79e04f57a7b@github.com> Message-ID: <8t72yaQ1fmjsgII6m5dkwaTBKC5JIMWcpl2bR_Jm6Dw=.a9c41c04-e2c1-4681-b019-4c2c6eab1f51@github.com> On Wed, 22 Jan 2025 20:03:36 GMT, Harshitha Onkar wrote: > > What if the window that loses focus is not the parent of the popup hierarchy? Or is it guaranteed that all the children of the popup window receive the focus lost event? > > Doesn't the updated FocusablePopupDismissTest.java & NestedFocusablePopupTest.java cover this case (Focusable item > sub item) or is the above case different? @honkar-jdk Not sure about it? My question was about the clean-up of the focus listener. @azvegint [answered my question](https://github.com/openjdk/jdk/pull/22729#discussion_r1929001676) now: > _?all the popup menu will be dismissed, performing cleanups in their `hide()` and `setVisible()` methods._ ------------- PR Comment: https://git.openjdk.org/jdk/pull/22729#issuecomment-2613070788 From duke at openjdk.org Fri Jan 24 18:41:53 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 24 Jan 2025 18:41:53 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Fri, 24 Jan 2025 07:08:08 GMT, Abhishek Kumar wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > @Naveenam-Oracle As per JBS comment, test was failing intermittently where the text was not drawn in image. Did this issue happen again? @kumarabhi006 right, it was. May be its more inclined to a Machine config issue, Failure not observed in recent multiple runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23264#issuecomment-2613161693 From aivanov at openjdk.org Fri Jan 24 19:01:56 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 19:01:56 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 00:25:14 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 one additional commit since the last revision: > > init finX, finY Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/Robot.java line 1: > 1: /* Revert all the unrelated formatting changes. src/java.desktop/share/classes/java/awt/Robot.java line 109: > 107: * > 108: * @author Robi Khan > 109: * @since 1.3 Do we have to modify these lines? src/java.desktop/share/classes/java/awt/Robot.java line 133: > 131: init(GraphicsEnvironment.getLocalGraphicsEnvironment() > 132: .getDefaultScreenDevice()); > 133: } Nothing's changed here? These look as unrelated to the problem that's being addressed. src/java.desktop/share/classes/java/awt/Robot.java line 157: > 155: * GraphicsDevice. > 156: * @see java.awt.GraphicsEnvironment#isHeadless > 157: * @see GraphicsDevice It's exactly the same here: the formatting is changed, yet nothing's touched in this method. You should avoid changing or reformatting lines of code which you don't touch? unless the purpose of a PR is to update formatting and perform some clean-ups. src/java.desktop/share/classes/java/awt/Robot.java line 175: > 173: for (int i = 0; i < gs.length; i++) { > 174: allScreenBounds[i] = gs[i].getDefaultConfiguration().getBounds(); > 175: } This doesn't look right to me? `init` is an instance method, yet it initialises `allScreenBounds` which is shared among all instances. In a way it makes sense to share the graphics environment / configuration. On the other hand how much would it affect the operation of robot if the bounds are fetched from `GraphicsEnvironment` only when needed? What happens if the graphics configuration changes? Does the user need to create a new instance of the `Robot` class? src/java.desktop/share/classes/java/awt/Robot.java line 234: > 232: for (Rectangle screenBounds : allScreenBounds) { > 233: int closestX = Math.min(Math.max(x, screenBounds.x), screenBounds.x + screenBounds.width); > 234: int closestY = Math.min(Math.max(y, screenBounds.y), screenBounds.y + screenBounds.height); Shouldn't the width and height have `- 1`? I mean if the screen resolution is 1920?1080, the highest valid coordinates are 1919 and 1079 for x and y correspondingly. src/java.desktop/share/classes/java/awt/Robot.java line 253: > 251: leastXDiff = currXDiff; > 252: leastYDiff = currYDiff; > 253: } Both branches must be executed at the same time ? you have adjust both x and y if the diff isn't 0. Probably, min/max would work better here too. test/jdk/java/awt/Robot/MouseMoveOffScreen.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. It hasn't been integrated in 2024, so the year needs bumping up to 2025. test/jdk/java/awt/Robot/MouseMoveOffScreen.java line 44: > 42: robot.mouseMove(STARTING_LOC.x, STARTING_LOC.y); > 43: robot.delay(500); > 44: robot.mouseMove(OFF_SCREEN_LOC.x, OFF_SCREEN_LOC.y); You should validate to ensure your `OFF_SCREEN_LOC` is actually off screen. test/jdk/java/awt/Robot/MouseMoveOffScreen.java line 50: > 48: throw new RuntimeException("Test Failed, getLocation returned null."); > 49: } > 50: Point currLoc = MouseInfo.getPointerInfo().getLocation(); Suggestion: Point currLoc = MouseInfo.getPointerInfo().getLocation(); if (currLoc == null) { throw new RuntimeException("Test Failed, getLocation returned null."); } You could save the the mouse location right away. ------------- PR Review: https://git.openjdk.org/jdk/pull/22781#pullrequestreview-2573308137 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929109081 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929070058 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929071748 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929073747 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929100875 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929103712 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929107458 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929110307 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929111847 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1929113298 From aivanov at openjdk.org Fri Jan 24 19:36:49 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 19:36:49 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 22:29:22 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Changes requested by aivanov (Reviewer). test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 30: > 28: @summary Test to check if the frame is created on the specified GraphicsDevice > 29: and if getScreenInsets()returns the correct values across multiple monitors. > 30: @author Oleg Pekhovskiy Suggestion: We're removing `@author` tags from tests. test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 50: > 48: > 49: public static void main(String[] args) throws InterruptedException { > 50: There's no need in a blank right at the start of a method. test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 52: > 50: > 51: GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); > 52: GraphicsDevice[] gds = ge.getScreenDevices(); We throw `jtreg.SkippedException` if test cannot be run in the current environment. You can find a sample usage in #22729. test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 73: > 71: * Use a decorated frame instead. > 72: */ > 73: if(Platform.isWindows()) { Suggestion: if (Platform.isWindows()) { test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 84: > 82: frame.setExtendedState(java.awt.Frame.MAXIMIZED_BOTH); > 83: Thread.sleep(2000); > 84: I suggest using `Robot.waitForIdle` to ensure all events are handled, along with `Robot.delay`. On the other hand, if the test is stable as it is, this piece of code may remain unchanged. test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 93: > 91: */ > 92: if (frameBounds.x < bounds.x) > 93: { Suggestion: if (frameBounds.x < bounds.x) { Use Java code style. test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 117: > 115: System.out.println("Test PASSED!"); > 116: } > 117: static int getMarginForScaleX(GraphicsConfiguration gc) { I'd add the `private` modifier to both methods as well as a blank line between the methods, especially after the `main` method. ------------- PR Review: https://git.openjdk.org/jdk/pull/23183#pullrequestreview-2573405498 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929128385 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929128930 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929145080 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929129276 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929147230 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929130357 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929148652 From aivanov at openjdk.org Fri Jan 24 19:43:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 19:43:46 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 23:31:26 GMT, Harshitha Onkar wrote: > Based on [GetMonitorInfo](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getmonitorinfoa) API doc, it seems fine to use this API to query monitor info for both primary and non-primary monitors but I'm not sure why original code used `SystemParametersInfo()` specifically instead of `GetMonitorInfo()` for primary monitor. Likely it's because of legacy? `SystemParametersInfo()` had existed before `GetMonitorInfo()` was introduced. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929155357 From prr at openjdk.org Fri Jan 24 20:11:49 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 24 Jan 2025 20:11:49 GMT Subject: RFR: 8208377: Soft hyphens render if not using TextLayout [v3] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 00:17:54 GMT, Daniel Gredler wrote: >> Soft hyphens should never render, regardless of the rendering path used internally. >> >> This PR does not expand the categorization of "complex" characters in `FontUtilities` in order to force the use of `TextLayout` rendering code paths (as was discussed in JBS). >> >> Instead, it takes the existing (limited) format-category checks in `sun.font.CMap` (a TrueType font helper class), expands it to a more general / complete default-ignorable check (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out of `CMap` and up a level into the `CharToGlyphMapper` classes themselves. >> >> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper have all been updated. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Add more info about test fonts and default-ignorable chars I am not completely comfortable with this change, as there's a policy change, and I am not as sure as I'd like to be even though it passes all the tests that we normally run. Also note harfbuzz *happens* to be what we use for layout but that's internal implementation. But I do agree consistency of layout vs non-layout paths is important. Meaning drawString("XXX") ought to render the same glyphs in the same way as "new TextLayout("XXX").draw(...) in all cases. I am approving however, as this is early in 25 and I hope any issues surface early. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22670#pullrequestreview-2573495758 From aivanov at openjdk.org Fri Jan 24 20:15:54 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 20:15:54 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 05:46:29 GMT, Julian Waters wrote: >> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 334: >> >>> 332: TCHAR dataBuffer[DEFAULT_ALLOC]; >>> 333: TCHAR *data = dataBuffer; >>> 334: // bool freeData = false; >> >> This should be set to `true` if `data` is reallocated, otherwise both `regEnable` and `regDeleteValue` leak `data`. >> >> https://github.com/openjdk/jdk/blob/4a9fba615da0dfa6646ecb9fd9d929f74fe6875e/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp#L336-L341 >> >> In fact, the above statement should probably be removed ? the following code uses only `dataBuffer` which does not contain any data if the buffer was dynamically allocated and assigned to `data`. > > By the above statement are you referring to the lines 336 to 341? I'll admit I'm a little lost for this one I'll submit a new bug to address this problem. It's not just a matter of an unused variables, it's the logic error: if the buffer is too small, *a new buffer is allocated*, yet this new buffer isn't deleted afterwards, nor is used to read the value retrieved from the registry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1929185886 From prr at openjdk.org Fri Jan 24 20:23:47 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 24 Jan 2025 20:23:47 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v2] In-Reply-To: References: Message-ID: <7qUiwUKIVmpJIWkNe6uq_8n0uauHGk9gvog4KoA8K7c=.3a003f43-fc43-4541-b879-cefe67607a78@github.com> On Thu, 23 Jan 2025 22:29:22 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright I'm approving the reasonable looking product change. The test still needs to be updated as per reviewer comments. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23183#pullrequestreview-2573512160 From aivanov at openjdk.org Fri Jan 24 20:38:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 20:38:55 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:42:05 GMT, Alexey Ivanov wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: >> >> - Merge branch 'openjdk:master' into accessibility >> - Cast to void in AccessBridgeCalls.c >> - static_cast to void in jaccessinspector.cpp >> - Formatting changes in AccessBridgeEventHandler.cpp >> - Merge branch 'master' into accessibility >> - Remove now unused result >> - Merge branch 'master' into accessibility >> - 8342870 > > src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 364: > >> 362: } >> 363: >> 364: int regDeleteValue(HKEY hFamilyKey, LPCWSTR lpSubKey) > > There's one more memory leak: > > https://github.com/openjdk/jdk/blob/4a9fba615da0dfa6646ecb9fd9d929f74fe6875e/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp#L352 > > The `delete[]` operator must be called on `newStr`. > > It's present in both `regEnable` and `regDeleteValue`. I'll also submit a new bug against it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1929203791 From aivanov at openjdk.org Fri Jan 24 20:38:56 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 20:38:56 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 05:50:29 GMT, Julian Waters wrote: >> src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 261: >> >>> 259: GetClientRect(hWnd, &rcClient); >>> 260: // hwndEdit = >>> 261: CreateWindow("Edit", >> >> The edit control is created visible and it's resized to cover the entire client area. >> >> The edit control is used? the text is updated in the [`displayAndLog` function](https://github.com/openjdk/jdk/blob/c38417a86e27f047715cfd9a98770387d994a512/src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp#L60). >> >> Since the edit control is a child window, it's automatically destroyed when the parent window is destroyed. >> >> Therefore, there's no reason to store the handle in a variable, and I suggest removing the `hwndEdit` variable. >> >> Moreover, the comment for `hwndEdit`?`// handle of tree-view control`?is confusing because it doesn't store a handle to a TreeView control. > > I wonder if this falls into the category of "Can be used in a debugger" like Alex mentioned above, if not I'll remove it I see no reason to keep. If it's needed during debugging, there are many ways to find the handle. Otherwise, the edit control is accessed by its id: `cAccessInfoText`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1929205392 From aivanov at openjdk.org Fri Jan 24 20:41:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 24 Jan 2025 20:41:47 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 05:49:47 GMT, Julian Waters wrote: >> src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 561: >> >>> 559: tvis.item = tvi; >>> 560: >>> 561: /* HTREEITEM treeNodeItem = */ TreeView_InsertItem(treeWnd, &tvis); >> >> Since it's unused, I'd rather remove the variable altogether. >> >> Does the handle have any other usage except for checking whether an error occurred? > > I'm not sure which handle you're referring to, you mean treeNodeItem? It doesn't seem to be used for checking if an error occurred Yes, `treeNodeItem` has a type of `HTREEITEM` which is an opaque pointer or a handle. No error checking is performed here, I'm for removing the declaration completely. I don't see much value in keeping the variable even for debugging purposes? if needed, it can be quickly added, or the value of `rax` can be viewed after the function call if the debugger doesn't show explicitly the result of the most recent function call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1929208016 From dgredler at openjdk.org Fri Jan 24 21:10:49 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Fri, 24 Jan 2025 21:10:49 GMT Subject: RFR: 8208377: Soft hyphens render if not using TextLayout In-Reply-To: References: Message-ID: On Tue, 24 Dec 2024 19:51:38 GMT, Phil Race wrote: >> @prrace, @alisenchung Thanks for your comments! >> >>> What automated checks? >> >> You're right, I had vastly overestimated the scope of the automated tier1 test runs on GitHub. I'll keep that in mind. >> >>> you will need to find machines to run all the tests yourself, across all platforms >> >> I was able to get my hands on a Mac, and have updated the Mac-specific code as well. I'm now covered on Linux, Windows and Mac. But if I ever need to test on AIX, I'll know I took a wrong turn somewhere. >> >>> One thing this fix does is change the logic which we have today [...] TO Never mind what the font says, these are always invisible and zero width >> >> Correct, this is the core of the issue in this bug: there are fonts containing glyphs for e.g. soft hyphen, but these glyphs should not be displayed because these characters are never displayed in and of themselves. This seems to match how HarfBuzz behaves, but the current Java logic does not mirror it, leading to inconsistent results depending on the internal code paths used to render or measure text. >> >> See the Unicode description of "default-ignorable" characters (http://www.unicode.org/L2/L2002/02368-default-ignorable.html): >> >>> Default-ignorable code points are those that should be ignored by default in rendering (unless explicitly supported). They have no visible glyph or advance width in and of themselves, although they may affect the display, positioning, or adornment of adjacent or surrounding characters. [...] This does not imply that default-ignorable code points must always be invisible: an implementation can show a visible glyph on request, such as in a "Show Hidden" mode. A particular use of a "Show Hidden" mode is to show a visible indication of "misplaced" or "ineffectual" formatting codes. [...] There are other characters that have no visible glyphs: the white-space characters. These typically have advance-width, however. The line separation characters such as CR do not clearly exhibit this advance-width since they are always at the end of a line, but in most GUIs show a visible advance width when selected. >> >> The `FontUtilities.isDefaultIgnorable` function matches the HarfBuzz classification, including a few exceptions made for the sake of Uniscribe compatibility: >> >> https://github.com/openjdk/jdk/blob/b2811a0ccd9664d11770980c47424ab6723cbbc9/src/java.desktop/share/native/libharfbuzz/hb-unicode.hh#L128 >> >>> you added 0x200B >> >> Correct, zero-width space is defined as having the Defa... > >> I did have one thought that I wanted to run by you guys: it could be argued that FontUtilities.isDefaultIgnorable should be native and should just delegate to HarfBuzz's is_default_ignorable. That's not the approach I decided to take, but let me know if you disagree. > > ah I guess that's what the hb related comment was about. It wasn't clear. > > > FYI I won't be able to finish reviewing this until January. @prrace Thanks, and understood. @alisenchung Is there anything else from your end? If not, can you approve? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2613382354 From azvegint at openjdk.org Fri Jan 24 21:23:02 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 24 Jan 2025 21:23:02 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v5] In-Reply-To: References: Message-ID: > The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. > > The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. > > This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. > > The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22729/files - new: https://git.openjdk.org/jdk/pull/22729/files/ef9f0b3c..368494e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=03-04 Stats: 26 lines in 2 files changed: 8 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/22729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22729/head:pull/22729 PR: https://git.openjdk.org/jdk/pull/22729 From azvegint at openjdk.org Fri Jan 24 21:23:03 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 24 Jan 2025 21:23:03 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v4] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 17:30:30 GMT, Alexey Ivanov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> getLocationOnScreen on EDT > > test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 108: > >> 106: Point frameLocation = waitAndGetLocationOnEDT(frame); >> 107: robot.mouseMove(frameLocation.x + frame.getWidth() / 2, >> 108: frameLocation.y + frame.getHeight() / 2); > > Then `frame.getWidth()` and `frame.getHeight()` should also be called on EDT, shouldn't they? Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1929241686 From honkar at openjdk.org Fri Jan 24 21:57:47 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 24 Jan 2025 21:57:47 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 21:23:02 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22729#pullrequestreview-2573649422 From serb at openjdk.org Sat Jan 25 05:02:49 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 25 Jan 2025 05:02:49 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Fri, 24 Jan 2025 01:50:29 GMT, Harshitha Onkar wrote: >I see your point but color management engines may have different implementations (LCMS or KCMS) and ICC Specification is a standard. I am pretty sure the lcms/kcms follow the standard, because of the next statement in the "ICC.1-2022-05.pdf" Any colour management system, application, utility or device driver that claims conformance with this ICC specification shall have the ability to read the profiles as they are defined in this ICC specification. Any profile-generating software and/or hardware that claims conformance with this ICC specification shall have the ability to create profiles as they are defined in this ICC specification. Since you already mentioned "non-ICC intent", please specify the part of the specification in ICC.1-2022-05 where their use is prohibited. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1929473901 From aturbanov at openjdk.org Sat Jan 25 12:41:50 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 25 Jan 2025 12:41:50 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Runtime Exception added src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1169: > 1167: * bytes here. Please refer ICC Spec Document for more details. > 1168: */ > 1169: int renderingIntent = ((header[index+2] & 0xff) << 8) | Suggestion: int renderingIntent = ((header[index+2] & 0xff) << 8) | ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1929535914 From duke at openjdk.org Sat Jan 25 23:09:35 2025 From: duke at openjdk.org (anass baya) Date: Sat, 25 Jan 2025 23:09:35 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v3] In-Reply-To: References: Message-ID: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. anass baya has updated the pull request incrementally with three additional commits since the last revision: - Handle annotation Co-authored-by: Alexey Ivanov - handle annotation Co-authored-by: Alexey Ivanov - remove @author tag Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23183/files - new: https://git.openjdk.org/jdk/pull/23183/files/ec467e34..e0dd1620 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From duke at openjdk.org Sun Jan 26 00:21:24 2025 From: duke at openjdk.org (anass baya) Date: Sun, 26 Jan 2025 00:21:24 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v4] In-Reply-To: References: Message-ID: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. anass baya has updated the pull request incrementally with one additional commit since the last revision: Use jtreg.SkippedException to throw an exception if the test cannot be run in the current environment, and add the private modifier to the helpful methods. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23183/files - new: https://git.openjdk.org/jdk/pull/23183/files/e0dd1620..09c1979c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=02-03 Stats: 10 lines in 1 file changed: 3 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From duke at openjdk.org Sun Jan 26 00:36:11 2025 From: duke at openjdk.org (anass baya) Date: Sun, 26 Jan 2025 00:36:11 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v5] In-Reply-To: References: Message-ID: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. anass baya has updated the pull request incrementally with one additional commit since the last revision: Update Copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23183/files - new: https://git.openjdk.org/jdk/pull/23183/files/09c1979c..ec145d3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From duke at openjdk.org Sun Jan 26 00:36:11 2025 From: duke at openjdk.org (anass baya) Date: Sun, 26 Jan 2025 00:36:11 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v2] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 19:13:19 GMT, Alexey Ivanov wrote: >> anass baya has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright > > test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 50: > >> 48: >> 49: public static void main(String[] args) throws InterruptedException { >> 50: > > There's no need in a blank right at the start of a method. I've removed the blank line Thank you > test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 117: > >> 115: System.out.println("Test PASSED!"); >> 116: } >> 117: static int getMarginForScaleX(GraphicsConfiguration gc) { > > I'd add the `private` modifier to both methods as well as a blank line between the methods, especially after the `main` method. Okey. I've added that Thank you ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929632692 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1929632608 From serb at openjdk.org Sun Jan 26 04:07:09 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 26 Jan 2025 04:07:09 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v5] In-Reply-To: References: Message-ID: On Sun, 26 Jan 2025 00:36:11 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Update Copyright Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23183#pullrequestreview-2574131120 From honkar at openjdk.org Sun Jan 26 21:50:47 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sun, 26 Jan 2025 21:50:47 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 01:03:35 GMT, Sergey Bylokhov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> Runtime Exception added > > src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1155: > >> 1153: throw new IllegalArgumentException("Invalid header data"); >> 1154: } >> 1155: getProfileClass(data); > > Can any of these fields have custom values (not covered by java constants inside iccCStoJCS) ??that can still be used for color transformation? Using custom values of color space to create a new color transform (For instance: cmsSigMCH1Data: 0x4D434831 which is specified in LCMS API but not in ICC Spec) results in ProfileDataException as below. java.awt.color.ProfileDataException: invalid ICC color space at java.desktop/java.awt.color.ICC_Profile.getNumComponents(ICC_Profile.java:1217) at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.(LCMSTransform.java:85) at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:132) at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:212) To summarize: - Profile/Device class - constants match (in ICC Spec doc and LCMS API doc) - Color Space - constants differ - Rendering Intent - constants differ - PCS - constants differ. This is dependent on type of device class and takes color space values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1929879100 From honkar at openjdk.org Sun Jan 26 21:55:46 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Sun, 26 Jan 2025 21:55:46 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Sat, 25 Jan 2025 04:59:47 GMT, Sergey Bylokhov wrote: > Since you already mentioned "non-ICC intent", please specify the part of the specification in ICC.1-2022-05 where their use is prohibited. @mrserb The ICC Spec doesn't explicitly say that certain values are prohibited. Although it does not list Non-ICC Intent values under Rendering Intent (pg#23, Table 23) either. What do you suggest is the best solution here to address the difference in ICC Spec Doc vs LCMS API doc? 1. Add the missing constants present in LCMS API doc to Java? 2. Or skip validating Rendering Intent? 3. Since Color Space has few extra constants in LCMS API do we need to address it too? @prrace Can you please suggest how to address this concern, since the last time we discussed we agreed to follow ICC Spec Doc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1929879842 From duke at openjdk.org Mon Jan 27 06:16:29 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Mon, 27 Jan 2025 06:16:29 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v2] In-Reply-To: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: > This contains test fixes for the following issue in ScreenCaptureRobotTest.java > > ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. > > Testing: > Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23264/files - new: https://git.openjdk.org/jdk/pull/23264/files/4e0aa045..2466f426 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23264&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23264&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23264/head:pull/23264 PR: https://git.openjdk.org/jdk/pull/23264 From duke at openjdk.org Mon Jan 27 06:16:29 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Mon, 27 Jan 2025 06:16:29 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v2] In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Fri, 24 Jan 2025 06:49:05 GMT, Alexander Zvegintsev wrote: >> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS > > test/jdk/java/awt/Robot/ScreenCaptureRobotTest.java line 118: > >> 116: IMAGE_WIDTH, IMAGE_HEIGHT); >> 117: >> 118: robot.mouseMove(0,0); > > I guess it is safer to move this `mouseMove` call right after the Robot creation, so in case the system is slow and shows a mouse cursor on the screenshot, there is a delay between the mouse movement and the screen capture. Moved `mouseMove` just after Robot creation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23264#discussion_r1930025536 From psadhukhan at openjdk.org Mon Jan 27 07:08:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 27 Jan 2025 07:08:50 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v8] In-Reply-To: <0TkdX-Iw4U-c_2JHoeVoVnAHgoNHNd0oIBQhF0kcLzU=.610ef565-34a5-48ff-a5ea-d8b6bb5e5789@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> <0TkdX-Iw4U-c_2JHoeVoVnAHgoNHNd0oIBQhF0kcLzU=.610ef565-34a5-48ff-a5ea-d8b6bb5e5789@github.com> Message-ID: <9exr92lNRW7cE2DOqOfYzJnNYLLSu18Bdrv2mzdALhU=.d3b111f9-e0dc-4517-9165-00dc12ad3851@github.com> On Wed, 22 Jan 2025 12:15:19 GMT, GennadiyKrivoshein wrote: >> **Description:** >> The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. >> The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 >> >> **Updates:** >> Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. >> >> **Tests:** >> Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. >> The test was run with the minimum possible margins. >> _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). >> _After the fix_: all lines are printed. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > let user choose the printer Testing looks good.. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22110#pullrequestreview-2574661550 From duke at openjdk.org Mon Jan 27 07:36:55 2025 From: duke at openjdk.org (duke) Date: Mon, 27 Jan 2025 07:36:55 GMT Subject: RFR: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files [v8] In-Reply-To: <0TkdX-Iw4U-c_2JHoeVoVnAHgoNHNd0oIBQhF0kcLzU=.610ef565-34a5-48ff-a5ea-d8b6bb5e5789@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> <0TkdX-Iw4U-c_2JHoeVoVnAHgoNHNd0oIBQhF0kcLzU=.610ef565-34a5-48ff-a5ea-d8b6bb5e5789@github.com> Message-ID: On Wed, 22 Jan 2025 12:15:19 GMT, GennadiyKrivoshein wrote: >> **Description:** >> The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. >> The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 >> >> **Updates:** >> Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. >> >> **Tests:** >> Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. >> The test was run with the minimum possible margins. >> _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). >> _After the fix_: all lines are printed. > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > let user choose the printer @GennadiyKrivoshein Your change (at version 8324013528005f19151b4dd9d55ff9435b29f89a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22110#issuecomment-2615023055 From aturbanov at openjdk.org Mon Jan 27 09:21:07 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 27 Jan 2025 09:21:07 GMT Subject: RFR: 8348648: Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit Message-ID: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> Two `Hashtable`'s in `javax.swing.text.html.CSS.LengthUnit` class are modified only within `` block: 1. lengthMapping 2. w3cLengthMapping We can replace them with immutable maps to avoid Hashtable synchronization overhead. ------------- Commit messages: - [PATCH] Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit Changes: https://git.openjdk.org/jdk/pull/23198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348648 Stats: 21 lines in 1 file changed: 0 ins; 2 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/23198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23198/head:pull/23198 PR: https://git.openjdk.org/jdk/pull/23198 From serb at openjdk.org Mon Jan 27 10:01:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 27 Jan 2025 10:01:48 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3] In-Reply-To: References: <13dQrxE44aHDG1KCHQ2QYvnBB0V7SHh27QBtq_KxHLo=.832010b4-d47e-4590-b400-003b472adbfc@github.com> <_HtsYUkZVw2uvJ5lWb_Ldw_aooqx-KE08pV_9pafcko=.28e0fc4f-048d-4237-8e14-a9c40b5e2ef8@github.com> Message-ID: On Sun, 26 Jan 2025 21:53:09 GMT, Harshitha Onkar wrote: >Add the missing constants present in LCMS API doc to Java? No, we definitely don't need to add any custom values ??to the Java API, the question is whether we need to reject them or not, since the ICC specification allows it(?). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1930258000 From serb at openjdk.org Mon Jan 27 10:06:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 27 Jan 2025 10:06:52 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 00:25:14 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 one additional commit since the last revision: > > init finX, finY I would like to clarify one point: if the robot moves the mouse off the screen while the actual mouse pointer is on the screen and immediately presses the mouse button, where will the click occur? on or off the screen? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2615316852 From aivanov at openjdk.org Mon Jan 27 14:17:01 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 27 Jan 2025 14:17:01 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v5] In-Reply-To: References: Message-ID: On Sun, 26 Jan 2025 00:36:11 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Update Copyright Changes requested by aivanov (Reviewer). test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 31: > 29: and if getScreenInsets()returns the correct values across multiple monitors. > 30: @library /test/lib > 31: @build jdk.test.lib.Platform Suggestion: @build jdk.test.lib.Platform jtreg.SkippedException test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 88: > 86: /* > 87: * On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > 88: * Adjust the frame bounds accordingly. This line is too long, we usually limit the number of columns to 80. Suggestion: * On Windows, the top-left corner of an undecorated maximized frame * may have negative coordinates (x, y). * Adjust the frame bounds accordingly. Alternatively, you may wrap before _?frame?_. test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 99: > 97: } > 98: > 99: // Add a margin to compensate for the lost fractional parts when casting to an integer. Suggestion: // Add a margin to compensate for the lost fractional parts // when casting to an integer. ------------- PR Review: https://git.openjdk.org/jdk/pull/23183#pullrequestreview-2575509254 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1930571433 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1930595439 PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1930596373 From duke at openjdk.org Mon Jan 27 14:25:08 2025 From: duke at openjdk.org (anass baya) Date: Mon, 27 Jan 2025 14:25:08 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v6] In-Reply-To: References: Message-ID: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. anass baya has updated the pull request incrementally with three additional commits since the last revision: - Reduce the line length Co-authored-by: Alexey Ivanov - Reduce the line length Co-authored-by: Alexey Ivanov - add "@build jdk.test.lib.Platform jtreg.SkippedException" Co-authored-by: Alexey Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23183/files - new: https://git.openjdk.org/jdk/pull/23183/files/ec145d3d..f66aa032 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=04-05 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From duke at openjdk.org Mon Jan 27 16:14:52 2025 From: duke at openjdk.org (Karm Michal Babacek) Date: Mon, 27 Jan 2025 16:14:52 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 21:14:55 GMT, Alexey Ivanov wrote: >> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: >> >> Amended error message, doesn't clear exception > > src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 70: > >> 68: graphicsEnvClass = (*env)->FindClass(env, >> 69: "java/awt/GraphicsEnvironment"); >> 70: CHECK_EXCEPTION_FATAL(env, "FindClass java/awt/GraphicsEnvironment failed"); > > If `FindClass` fails to find the class, a `NoClassDefFoundError` should be raised. This function returns immediately (a value of `true`). The caller of this function should check if there's a pending exception and perform an appropriate action. > > In this case, the function is called from > > https://github.com/openjdk/jdk/blob/955bf185c38ec0fcedb0a549461fc85367b37fbb/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L130-L132 > > If there's a pending exception, it should bail out and let the exception be thrown on the Java side. > > If it doesn't, the pending exception makes `JNU_NewStringPlatform` fail at > > https://github.com/openjdk/jdk/blob/955bf185c38ec0fcedb0a549461fc85367b37fbb/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L149-L150 > > --- > > Ah! There's no Java code to catch the exception? `AWT_OnLoad` is essentially `JNI_OnLoad`. In this case, `CHECK_EXCEPTION_FATAL` seems right. Hello @aivanov-jdk, Thank you for looking into the review. Is there anything I can do to move things forward right now? It's not clear to me whether you agree or disagree with the latest iteration inspired by @mrserb 's review. Cheers Karm ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1930790472 From azvegint at openjdk.org Mon Jan 27 16:33:49 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 27 Jan 2025 16:33:49 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v2] In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Mon, 27 Jan 2025 06:16:29 GMT, Naveen Narayanan wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23264#pullrequestreview-2575936773 From honkar at openjdk.org Mon Jan 27 17:28:56 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 27 Jan 2025 17:28:56 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Sun, 26 Jan 2025 21:48:22 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1155: >> >>> 1153: throw new IllegalArgumentException("Invalid header data"); >>> 1154: } >>> 1155: getProfileClass(data); >> >> Can any of these fields have custom values (not covered by java constants inside iccCStoJCS) ??that can still be used for color transformation? > > Using custom values of color space to create a new color transform (For instance: cmsSigMCH1Data: 0x4D434831 which is specified in LCMS API but not in ICC Spec) results in ProfileDataException as below. (this is expected since cmsSigMCH1Data constant is NOT present in JDK). > > > java.awt.color.ProfileDataException: invalid ICC color space > at java.desktop/java.awt.color.ICC_Profile.getNumComponents(ICC_Profile.java:1217) > at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.(LCMSTransform.java:85) > at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:132) > at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:212) > > > To summarize: > - Profile/Device class - constants match (in ICC Spec doc and LCMS API doc) > - Color Space - constants differ > - Rendering Intent - constants differ > - PCS - constants differ. This is dependent on type of device class and takes color space values. > No, we definitely don't need to add any custom values ??to the Java API, the question is whether we need to reject them or not, since the ICC specification allows it(?). Is this question applicable only for Rendering Intent or other fields too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1930905654 From duke at openjdk.org Mon Jan 27 18:08:58 2025 From: duke at openjdk.org (GennadiyKrivoshein) Date: Mon, 27 Jan 2025 18:08:58 GMT Subject: Integrated: 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files In-Reply-To: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> References: <5S8fyVLCYJ6-k-4bqikLIsfJ9X6QFLsGm-55-PF-giY=.e7c503ec-d666-4fcb-b34b-243d205d127e@github.com> Message-ID: On Thu, 14 Nov 2024 16:15:46 GMT, GennadiyKrivoshein wrote: > **Description:** > The PR updates sun.print.CUPSPrinter's behavior in terms of reading media imageable area values according to the PostScript Printer Description File Format Specification. > The actual implementation reads X and Y coordinates of the upper right corner of the imageable area as width and height of the imageable area. https://bugs.openjdk.org/browse/JDK-8344119 > > **Updates:** > Added subtraction of the X and Y coordinates of the lower left corner to fix the width and height values of the imageable area. > > **Tests:** > Tested with `test/jdk/javax/print/DialogMargins.java` using Brother DCP-T720DW, the test draws a black line along the borders of the imageable area. > The test was run with the minimum possible margins. > _Before the fix_: the right and bottom lines are not printed (the right and bottom lines are outside the printable area). > _After the fix_: all lines are printed. This pull request has now been integrated. Changeset: 03106eb2 Author: Gennadiy Krivoshein Committer: Alexander Scherbatiy URL: https://git.openjdk.org/jdk/commit/03106eb2d37903f3367b54c615a77e9df219e9cd Stats: 342 lines in 2 files changed: 338 ins; 0 del; 4 mod 8344119: CUPSPrinter does not respect PostScript printer definition specification in case of reading ImageableArea values from PPD files Reviewed-by: prr, psadhukhan ------------- PR: https://git.openjdk.org/jdk/pull/22110 From azvegint at openjdk.org Mon Jan 27 18:26:48 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 27 Jan 2025 18:26:48 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 16:47:42 GMT, Alexey Ivanov wrote: > Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay. > Use `Util.hitMnemonics` instead of custom code to handle macOS. > > I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23301#pullrequestreview-2576234514 From prr at openjdk.org Mon Jan 27 23:15:50 2025 From: prr at openjdk.org (Phil Race) Date: Mon, 27 Jan 2025 23:15:50 GMT Subject: RFR: 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows [v7] In-Reply-To: References: Message-ID: <8nq0wHDpIB5pR1ABmYQtaHGZqWAqskvgURBBlTuP5zQ=.92e6ea02-7275-4832-8014-b172eea54af5@github.com> On Wed, 20 Nov 2024 19:07:28 GMT, Daniel Gredler wrote: >> This PR fixes the issue identified in JDK-8148334 in screenshots `Page8_landscape.JPG` and `Page8_portrait.JPG`. >> >> It does not address `mac_Page1.png` or `mac_Page8.png`, which I'm not even sure are still issues (I have no access to a Mac). >> >> The method in question, `PathGraphics.printedSimpleGlyphVector(...)` is quite complex, with many special cases being handled in different ways. In this specific scenario (page 8 of `PrintTextTest`), all special case checks fail, and we fall through all the way to the final handling block, which draws the individual characters one by one. It looks like the problem is that the font transform translation is applied twice, once via the glyph positions, and again by `drawString(...)` via the font. The proposed fix is to provide `drawString(...)` a font without any translation transform. >> >> Testing looks good on Linux, but needs to be done on Mac and Windows. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Add additional issue ID to PrintTextTest bug list I've tested the fix on Mac, Linux and Windows. It is painstaking comparing all the pages on-screen and off-screen to be sure not to overlook something. I had to pause the test timer to review it all before the test timed out. There are a couple of before and after things to note (ie pre-existing problems, which remain an issue) Eg on Linux Page 3, "drawChars(char[]" prints as "drawChars( char[]" I don't know where the extra space came from. but I should note I am viewing this in a Postscript viewer, not on a printer and it is the same before and after. On windows, pages 12 / 13 - using the Japanese font - on screen uses embedded bitmaps so the size doesn't scale smoothly line to line. It 'jumps' when the next bitmap size is selected. The printing case size increases smoothly because bitmaps aren't used there. This is a small, pre-existing anomaly and the instructions have a comment that text does not scale linearly screen to printer, so that is not necessarily a bug and the on-screen case is actually what you might want to change, but not at the cost of losing the bitmaps .. But the difference is pretty extreme in this case. We may need to re-visit this. macOS is still a problem. Notably every page has an issue with the glyphvector positioning case being wildly wrong. But again, pre-existing. I didn't see anything get worse with this change. So I'm approving the fix, although the *pre-existing* problems on windows and linux may mean that some tester might consider the anomalies there worth a new bug report. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21980#pullrequestreview-2576742178 From serb at openjdk.org Tue Jan 28 00:50:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 28 Jan 2025 00:50:52 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 17:25:58 GMT, Harshitha Onkar wrote: >Is this question applicable only for Rendering Intent or other fields too? For other fields too. Note, before this fix the following method iccCStoJCS was used to convert icc constant to java constant and if it was not possible an exception was thrown. One of the reasons it was not possible is because we do not cover all variants as java constants so we cannot return anything useful from getPCSType/etc, but it was still possible to use such profiles for color conversion. This patch starts using iccCStoJCS as the source of truth. I'm not sure if this is correct or not. We can double-check that it covers all valid cases, so we can reject everything else. But the existing checks that are already in the constructor can be safely added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1931379481 From honkar at openjdk.org Tue Jan 28 02:10:57 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 28 Jan 2025 02:10:57 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 00:48:33 GMT, Sergey Bylokhov wrote: >Note, before this fix the following method iccCStoJCS was used to convert icc constant to java constant and if it was not possible an exception was thrown. Agreed. > One of the reasons it was not possible is because we do not cover all variants as java constants so we cannot return anything useful from getPCSType/etc, but it was still possible to use such profiles for color conversion. But the exception that I mentioned here: https://github.com/openjdk/jdk/pull/23044#discussion_r1929879100 is WITHOUT the newly added validation checks in setData(). The test case for that I used is as follows ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB); ICC_Profile sRGB = ICC_Profile.getInstace(ColorSpace.CS_sRGB); sRGB.setData() // changed the color space to cmsSigMCH1Data which is not in JDK and commented out the validation checks cs.toRGB(new float[3]); //color transform from CS_LINEAR_RGB to CS_sRGB fails ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1931426040 From honkar at openjdk.org Tue Jan 28 02:18:54 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 28 Jan 2025 02:18:54 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 02:08:18 GMT, Harshitha Onkar wrote: >>>Is this question applicable only for Rendering Intent or other fields too? >> >> For other fields too. Note, before this fix the following method iccCStoJCS was used to convert icc constant to java constant and if it was not possible an exception was thrown. One of the reasons it was not possible is because we do not cover all variants as java constants so we cannot return anything useful from getPCSType/etc, but it was still possible to use such profiles for color conversion. >> >> This patch starts using iccCStoJCS as the source of truth. I'm not sure if this is correct or not. We can double-check that it covers all valid cases, so we can reject everything else. >> >> But the existing checks that are already in the constructor can be safely added. > >>Note, before this fix the following method iccCStoJCS was used to convert icc constant to java constant and if it was not possible an exception was thrown. > > Agreed. > >> but it was still possible to use such profiles for color conversion. > > The exception that I mentioned here: https://github.com/openjdk/jdk/pull/23044#discussion_r1929879100 is WITHOUT the newly added validation checks in setData(). > > The test case for that I used is as follows > > > ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB); > ICC_Profile sRGB = ICC_Profile.getInstace(ColorSpace.CS_sRGB); > sRGB.setData() // changed the color space to cmsSigMCH1Data which is not in JDK and commented out the validation checks in setData() > cs.toRGB(new float[3]); //color transform from CS_LINEAR_RGB to CS_sRGB fails > But the existing checks that are already in the constructor can be safely added. So profile class and color space validation checks should be okay to add to .setData() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1931430373 From abhiscxk at openjdk.org Tue Jan 28 03:46:48 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 28 Jan 2025 03:46:48 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v2] In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Mon, 27 Jan 2025 06:16:29 GMT, Naveen Narayanan wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Need to update copyright year. ------------- PR Review: https://git.openjdk.org/jdk/pull/23264#pullrequestreview-2577022335 From abhiscxk at openjdk.org Tue Jan 28 03:46:50 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 28 Jan 2025 03:46:50 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: <7hliD3ROR3292UTheKoxtPpUb58lU49KwyynLZ5BM0I=.5790909f-5c5b-4f20-88e0-edf72a6d0a4e@github.com> On Fri, 24 Jan 2025 07:08:08 GMT, Abhishek Kumar wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > @Naveenam-Oracle As per JBS comment, test was failing intermittently where the text was not drawn in image. Did this issue happen again? > @kumarabhi006 right, it was. May be its more inclined to a Machine config issue, Failure not observed in recent multiple runs. Ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23264#issuecomment-2617780116 From psadhukhan at openjdk.org Tue Jan 28 03:47:31 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 28 Jan 2025 03:47:31 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel Message-ID: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. ------------- Commit messages: - jecheck - 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel Changes: https://git.openjdk.org/jdk/pull/23324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348760 Stats: 126 lines in 3 files changed: 122 ins; 1 del; 3 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 achung at openjdk.org Tue Jan 28 04:43:44 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 04:43:44 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v7] In-Reply-To: References: Message-ID: > 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 three additional commits since the last revision: - robot update - Revert "robot multimonitor fix" This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9. - Revert "init finX, finY" This reverts commit 0eb4226fe6d3cf7406bf0124d4871388fb04a77e. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22781/files - new: https://git.openjdk.org/jdk/pull/22781/files/0eb4226f..1bd09930 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=05-06 Stats: 184 lines in 2 files changed: 20 ins; 25 del; 139 mod Patch: https://git.openjdk.org/jdk/pull/22781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781 PR: https://git.openjdk.org/jdk/pull/22781 From achung at openjdk.org Tue Jan 28 04:51:54 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 04:51:54 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 18:52:48 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> init finX, finY > > src/java.desktop/share/classes/java/awt/Robot.java line 1: > >> 1: /* > > Revert all the unrelated formatting changes. accidentally reformatted the file instead of specific lines, change is reverted now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1931514004 From dnguyen at openjdk.org Tue Jan 28 08:32:50 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 28 Jan 2025 08:32:50 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 16:47:42 GMT, Alexey Ivanov wrote: > Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay. > Use `Util.hitMnemonics` instead of custom code to handle macOS. > > I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI. I tested this as well with repeats. Looks good to me. However, I noticed that this test is newly added. Double-checking, is this intentionally open-sourced? ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/23301#pullrequestreview-2577440429 From dnguyen at openjdk.org Tue Jan 28 09:08:55 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 28 Jan 2025 09:08:55 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Tue, 28 Jan 2025 03:40:26 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. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 860: > 858: State state; > 859: if (isEnabled(c, null)) { > 860: backgroundState = State.NORMAL; Do you happen to know why `State.BITMAP` was originally here? I tried locating where it originated from, but can't pinpoint exactly why it's either `State.BITMAP` or `State.NORMAL` based on the icon being `null`. Curious only because we're completely eliminating it here and there might be a dependency. However, I haven't encountered any issues when testing yet. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 882: > 880: } else { > 881: skin = xp.getSkin(c, part); > 882: skin.paintSkin(g, x - 3*OFFSET, y + OFFSET, state); Suggestion: skin.paintSkin(g, x - 3 * OFFSET, y + OFFSET, state); test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java line 51: > 49: Verify that for JRadioButtonMenuItem with imageicon, > 50: radiobutton is been shown alongside the imageicon. > 51: If radiobutton is shown, test passes else fails."""; Suggestion: One JRadioButtonMenuItem is with imageicon and another one without imageicon. Verify that for JRadioButtonMenuItem with imageicon, radiobutton is been shown alongside the imageicon. If radiobutton is shown, test passes. Else fails."""; Just for consistency, I see theres one capital `i`. I guess you can also just title-case all of the UI components. Ex: ImageIcon and RadioButton. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1931734330 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1931715704 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1931731265 From jkern at openjdk.org Tue Jan 28 10:28:53 2025 From: jkern at openjdk.org (Joachim Kern) Date: Tue, 28 Jan 2025 10:28:53 GMT Subject: Integrated: 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 15:34:36 GMT, Joachim Kern wrote: > We (SAP) try to introduce the ?IBM Open XL C/C++ for AIX 17.1.2? (based on clang 17) as a feasible compiler for jdk25, because in combination with the 17.1.3 runtime this would enable the support for ubsan. > Unfortunately, the new compiler comes along with a new set of compiler warnings turned into errors by -Werror. > One of the warnings is -Wtentative-definitions. It is fired when a variable definition in a header is found: > /jdk/src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h:36:20: error: possible missing 'extern' on global variable definition in header [-Werror,-Wtentative-definitions] > 36 | IMGEXTERN jfieldID g_BImgRasterID; > | ^ > From now on headers allow only extern declarations of variables. The definition must take place in a c/cpp file. This means e.g. > imageInitIDs.h:36:20 > 36 extern jfieldID g_BImgRasterID; > and the corresponding c-File > jfieldID g_BImgRasterID; > > The other possible solution would be to compile everything with > -Wno-tentative-definitions > which could be set in flags-cflags.m4, if compiling with clang 17. This pull request has now been integrated. Changeset: a4942a2f Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/a4942a2f7a2afdea5577eaae7cc4322ef1662fb9 Stats: 281 lines in 4 files changed: 126 ins; 94 del; 61 mod 8348286: [AIX] clang 17 introduces new warning Wtentative-Definitions which produces Build errors Reviewed-by: ihse, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/23236 From duke at openjdk.org Tue Jan 28 10:40:40 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Tue, 28 Jan 2025 10:40:40 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v3] In-Reply-To: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: > This contains test fixes for the following issue in ScreenCaptureRobotTest.java > > ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. > > Testing: > Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23264/files - new: https://git.openjdk.org/jdk/pull/23264/files/2466f426..b49045c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23264&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23264&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23264/head:pull/23264 PR: https://git.openjdk.org/jdk/pull/23264 From abhiscxk at openjdk.org Tue Jan 28 11:06:52 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 28 Jan 2025 11:06:52 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v3] In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Tue, 28 Jan 2025 10:40:40 GMT, Naveen Narayanan wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23264#pullrequestreview-2577879591 From aivanov at openjdk.org Tue Jan 28 11:32:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 11:32:46 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 08:29:56 GMT, Damon Nguyen wrote: > I noticed that this test is newly added. Double-checking, is this intentionally open-sourced? I intended open-sourcing the test when I submitted the bug. I see no reason why it should remain closed-source. We have been open-sourcing all the tests which can be. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23301#issuecomment-2618735701 From azvegint at openjdk.org Tue Jan 28 11:36:27 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 28 Jan 2025 11:36:27 GMT Subject: RFR: 8348675: TrayIcon tests fails in Ubuntu 24.10 wayland Message-ID: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) > the reason is this is using XTEST, an X11 protocol which will not work outside of X11. > > In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. I also tested the same tests by clicking manually instead of using the robot, and it works as expected. So for now, skip those tests on Wayland (and do some minor cleanup). Testing after modifications is also green. ------------- Commit messages: - move mouse away from the hot corner - skip tests on wayland - cleanup Changes: https://git.openjdk.org/jdk/pull/23329/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23329&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348675 Stats: 140 lines in 4 files changed: 71 ins; 8 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/23329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23329/head:pull/23329 PR: https://git.openjdk.org/jdk/pull/23329 From azvegint at openjdk.org Tue Jan 28 11:36:27 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 28 Jan 2025 11:36:27 GMT Subject: RFR: 8348675: TrayIcon tests fails in Ubuntu 24.10 wayland In-Reply-To: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: On Tue, 28 Jan 2025 11:28:27 GMT, Alexander Zvegintsev wrote: > Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. > > Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) >> the reason is this is using XTEST, an X11 protocol which will not work outside of X11. >> >> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. > > I also tested the same tests by clicking manually instead of using the robot, and it works as expected. > So for now, skip those tests on Wayland (and do some minor cleanup). > > Testing after modifications is also green. test/jdk/java/awt/TrayIcon/ActionCommand/ActionCommand.java line 161: > 159: }); > 160: > 161: robot.mouseMove(100, 0); I moved it away from the top left corner, because it can trigger a `hot corner` in Gnome(X11 session), so the following tests may fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932002423 From aivanov at openjdk.org Tue Jan 28 11:39:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 11:39:47 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v6] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 14:25:08 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with three additional commits since the last revision: > > - Reduce the line length > > Co-authored-by: Alexey Ivanov > - Reduce the line length > > Co-authored-by: Alexey Ivanov > - add "@build jdk.test.lib.Platform jtreg.SkippedException" > > Co-authored-by: Alexey Ivanov The updated test `MultiScreenInsetsTest.java` fails for me on Windows: bounds: java.awt.Rectangle[x=0,y=0,width=1920,height=1080] frameBounds: java.awt.Rectangle[x=-7,y=-7,width=1933,height=1045] adjusted: java.awt.Rectangle[x=0,y=0,width=1919,height=1031] marginX = 0, marginY 0 Exception in thread "main" java.lang.RuntimeException: Test FAILED! Wrong screen #0 insets: java.awt.Insets[top=0,left=0,bottom=48,right=0] at MultiScreenInsetsTest.main(MultiScreenInsetsTest.java:113) I added some debug prints to the test. Both width and height are 1 pixel off. I'm pretty sure it's due to scaling. You tried to take this fact into account, yet it doesn't seem to work reliably in all the cases? and rounding error could accumulate. Probably, we can tolerate a 1-pixel difference from what is expected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23183#issuecomment-2618750856 From aivanov at openjdk.org Tue Jan 28 11:39:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 11:39:47 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v6] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 11:36:22 GMT, Alexey Ivanov wrote: > I added some debug prints to the test. Both width and height are 1 pixel off. By the way, the output of the values could be crucial in analysing failures, so it could worth adding right away. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23183#issuecomment-2618754614 From perini.davide at dpsoftware.org Tue Jan 28 12:40:41 2025 From: perini.davide at dpsoftware.org (Davide Perini) Date: Tue, 28 Jan 2025 13:40:41 +0100 Subject: RFR: 8348675: TrayIcon tests fails in Ubuntu 24.10 wayland In-Reply-To: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: <059092df-2293-4407-8047-b4308a843abd@dpsoftware.org> I don't know what kind of tests you are running but TrayIcon is broken on most Linux systems: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8341144 No one is still using xembed for trayicon, Ubuntu has some sort of compatibility when running GNOME, but it's broken on KDE. On Windows does not work better: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8341173 https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8323977 TrayIcon is rotting in the current state, it uses 20+ years old APIs, I think that it needs a refresh instead of a "skip of some tests". Davide On 28/01/2025 12:36, Alexander Zvegintsev wrote: > Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. > > Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) >> the reason is this is using XTEST, an X11 protocol which will not work outside of X11. >> >> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. > I also tested the same tests by clicking manually instead of using the robot, and it works as expected. > So for now, skip those tests on Wayland (and do some minor cleanup). > > Testing after modifications is also green. > > ------------- > > Commit messages: > - move mouse away from the hot corner > - skip tests on wayland > - cleanup > > Changes: https://git.openjdk.org/jdk/pull/23329/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23329&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8348675 > Stats: 140 lines in 4 files changed: 71 ins; 8 del; 61 mod > Patch: https://git.openjdk.org/jdk/pull/23329.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/23329/head:pull/23329 > > PR: https://git.openjdk.org/jdk/pull/23329 From mbaesken at openjdk.org Tue Jan 28 13:38:55 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 28 Jan 2025 13:38:55 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST Message-ID: In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. ------------- Commit messages: - JDK-8348830 Changes: https://git.openjdk.org/jdk/pull/23332/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23332&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348830 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23332/head:pull/23332 PR: https://git.openjdk.org/jdk/pull/23332 From aivanov at openjdk.org Tue Jan 28 13:47:46 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 13:47:46 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Tue, 28 Jan 2025 08:34:30 GMT, Damon Nguyen 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. > > test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java line 51: > >> 49: Verify that for JRadioButtonMenuItem with imageicon, >> 50: radiobutton is been shown alongside the imageicon. >> 51: If radiobutton is shown, test passes else fails."""; > > Suggestion: > > One JRadioButtonMenuItem is with imageicon and > another one without imageicon. > Verify that for JRadioButtonMenuItem with imageicon, > radiobutton is been shown alongside the imageicon. > If radiobutton is shown, test passes. Else fails."""; > > > Just for consistency, I see theres one capital `i`. I guess you can also just title-case all of the UI components. Ex: ImageIcon and RadioButton. With it's referred to the type `ImageIcon`, both `i` need to be capitalised; on the other hand, it doesn't make sense for the tester, as they may know nothing about the underlying code and shouldn't know. Just use ?image?, it's less confusing than imageicon?is it an image, or is it an icon? Both terms have meaning in UI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1932191078 From aivanov at openjdk.org Tue Jan 28 13:47:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 13:47:47 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <4gUF0U5hrzDoPxm8Fsh5FXSagqzP0884hdG5ZOP2pYg=.aea09fdc-6839-49b2-b8e4-d7f0af224bc1@github.com> On Tue, 28 Jan 2025 03:40:26 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. test/jdk/javax/swing/JMenuItem/duke.gif line 1: > 1: GIF89ap!?:,?3f???++3+f+?+?+?UU3UfU?U?U???3?f????????3?f????????3?f???????3?f??????3333f3?3?3?3+3+33+f3+?3+?3+?3U3U33Uf3U?3U?3U?3?3?33?f3??3??3??3?3?33?f3??3??3??3?3?33?f3?3??3??3?3?33?f3??3??3??ff3fff?f?f?f+f+3f+ff+?f+?f+?fUfU3fUffU?fU?fU?f?f?3f?ff??f??f??f?f?3f?ff??f??f??f?f?3f?ff?f??f??f?f?3f?ff??f??f????3?f??????+?+3?+f?+??+?+??U?U3?Uf?U??U?U?????3??f????????????3??f????????????3??f???????????3??f??????????3?f???????+?+3?+f? +??+??+??U?U3?Uf?U??U??U???3?f????????3?f??????????3??f????????????3??f???????????3?f???????+?+3?+f?+??+??+??U?U3?Uf?U??U??U?????3??f?????????????3??f?????????????3??f????????????3??f??????????? Hp1e ?f?B???#F???&?M??bb`?@b %?OL?052??, J??z???? F??l???L?C??1R?o??}? T?? ????R}? ??U f??L+?72????F??O?2?T1?}?? ?; Can't you generate an image on the fly? It doesn't have to be Duke, any image like a red square or rectangle will do. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1932193033 From aivanov at openjdk.org Tue Jan 28 13:55:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 13:55:51 GMT Subject: RFR: 8348648: Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit In-Reply-To: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> References: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> Message-ID: On Mon, 20 Jan 2025 13:07:19 GMT, Andrey Turbanov wrote: > Two `Hashtable`'s in `javax.swing.text.html.CSS.LengthUnit` class are modified only within `` block: > 1. lengthMapping > 2. w3cLengthMapping > > We can replace them with immutable maps to avoid Hashtable synchronization overhead. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23198#pullrequestreview-2578318187 From erikj at openjdk.org Tue Jan 28 14:08:46 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 28 Jan 2025 14:08:46 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23332#pullrequestreview-2578358124 From mbaesken at openjdk.org Tue Jan 28 14:38:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 28 Jan 2025 14:38:46 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. Hi Erik, thanks for the review ! I noticed this issue, while going through the make rules of our libs; any idea why so many are set to OPTIMIZATION level LOW ? Is this really still needed or just because of old compilers used many years ago? For some libs the OPTIMIZATION level is not set (e.g. BUILD_LIBSYSLOOKUP) is this okay ? Guess some default is used in those cases? Lib compilation current optimization level BUILD_LIBJVM varies BUILD_LIBNET LOW BUILD_LIBNIO HIGH BUILD_LIBOSXSECURITY LOW BUILD_LIBJSIG LOW BUILD_LIBSYSLOOKUP nothing set ?? BUILD_LIBFALLBACKLINKER nothing set ?? BUILD_LIBSIMD_SORT HIGH BUILD_LIBVERIFY HIGH BUILD_LIBJAVA HIGH BUILD_LIBZIP LOW BUILD_LIBJIMAGE LOW BUILD_LIBJLI HIGH BUILD_LIBJSOUND LOW BUILD_LIBOSXAPP LOW BUILD_LIBOSX LOW BUILD_LIBAWT HIGHEST BUILD_LIBAWT_HEADLESS LOW BUILD_LIBAWT_XAWT LOW BUILD_LIBAWT_LWAWT LOW BUILD_LIBJAWT LOW BUILD_LIBMLIB_IMAGE HIGHEST BUILD_LIBLCMS HIGHEST BUILD_LIBJAVAJPEG HIGHEST BUILD_LIBSPLASHSCREEN LOW BUILD_LIBFREETYPE HIGHEST BUILD_LIBFONTMANAGER HIGHEST BUILD_LIBOSXUI LOW BUILD_LIBINSTRUMENT LOW BUILD_LIBMANAGEMENT HIGH BUILD_LIBPREFS HIGH BUILD_LIBRMI LOW BUILD_LIBJ2GSS LOW BUILD_LIBSSPI_BRIDGE LOW BUILD_LIBW2K_LSA_AUTH LOW BUILD_LIBOSXKRB5 LOW BUILD_LIBJ2PCSC LOW BUILD_LIBJAVAACCESSBRIDGE LOW BUILD_LIBWINDOWSACCESSBRIDGE LOW BUILD_LIBATTACH LOW BUILD_LIBJ2PKCS11 LOW BUILD_LIBSUNMSCAPI LOW BUILD_LIBSAPROC HIGH BUILD_LIBJSVML nothing set ?? BUILD_LIBSLEEF HIGH BUILD_LIBDT_SHMEM LOW BUILD_LIBDT_SOCKET LOW BUILD_LIBJDWP LOW BUILD_LIBJPACKAGEAPPLAUNCHERAUX LOW BUILD_LIBJPACKAGE LOW BUILD_LIBWIXHELPER LOW BUILD_LIBMANAGEMENT_AGENT LOW BUILD_LIBMANAGEMENT_EXT HIGH BUILD_LIBEXTNET LOW BUILD_LIBSCTP LOW BUILD_LIBJAAS LOW ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2619179908 From aivanov at openjdk.org Tue Jan 28 15:01:20 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 15:01:20 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable Message-ID: The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. The updated test passes in the CI. ------------- Commit messages: - 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable Changes: https://git.openjdk.org/jdk/pull/23336/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23336&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348865 Stats: 78 lines in 1 file changed: 45 ins; 13 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/23336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23336/head:pull/23336 PR: https://git.openjdk.org/jdk/pull/23336 From aivanov at openjdk.org Tue Jan 28 15:01:20 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 15:01:20 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable In-Reply-To: References: Message-ID: <9egZqdErnrMIxJW4KjIKbeBYpU1OM1sqDH9KKAtdOQU=.ff3f959e-6d8e-4f55-b9c9-ff15ea29038f@github.com> On Tue, 28 Jan 2025 14:51:57 GMT, Alexey Ivanov wrote: > The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. > > Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. > > I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. > > The updated test passes in the CI. test/jdk/javax/swing/JButton/4796987/bug4796987.java line 79: > 77: > 78: // Hover over button1 > 79: Point b1Center = Util.getCenterPoint(button1); This is a center point of `button1` in screen coordinates. test/jdk/javax/swing/JButton/4796987/bug4796987.java line 88: > 86: BufferedImage image = robot.createScreenCapture(panelBounds); > 87: > 88: final Point p1 = Util.invokeOnEDT(() -> getCenterPoint(button1)); Here, `p1` is the center point of `button1` relative to its parent, `panel`. It can be used to iterate over the pixels in the captured image. Previously, it was in screen coordinates for `Robot.getPixelColor`.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1932324647 PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1932328800 From azvegint at openjdk.org Tue Jan 28 15:19:45 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 28 Jan 2025 15:19:45 GMT Subject: RFR: 8348648: Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit In-Reply-To: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> References: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> Message-ID: <0Ncj5U17u_QCkaRIYTyDfbWnCUdCp6ZRAOUcfoKt5AI=.36a8e672-d6ec-402e-adb5-c42bf5bda7a6@github.com> On Mon, 20 Jan 2025 13:07:19 GMT, Andrey Turbanov wrote: > Two `Hashtable`'s in `javax.swing.text.html.CSS.LengthUnit` class are modified only within `` block: > 1. lengthMapping > 2. w3cLengthMapping > > We can replace them with immutable maps to avoid Hashtable synchronization overhead. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23198#pullrequestreview-2578601573 From clanger at openjdk.org Tue Jan 28 15:54:45 2025 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 28 Jan 2025 15:54:45 GMT Subject: RFR: 8330936: [ubsan] signed integer overflows in libawt java2d In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 09:23:52 GMT, Matthias Baesken wrote: > In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) > jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows > > jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int' > #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683 > #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499 > #2 0x7efe9b8dee7b () > > java/awt/BasicStroke/DashStrokeTest.java shows > > src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int' > #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366 > #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75 > #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92 > #3 0x7fba12d07e7b () > > > There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings. The change looks ok and trivial. However I find nothing about an investigation what would need to be changed to eliminate the UB warning in code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2619393742 From duke at openjdk.org Tue Jan 28 16:00:02 2025 From: duke at openjdk.org (Nikita Provotorov) Date: Tue, 28 Jan 2025 16:00:02 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v11] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> <_SoKL7Px213yhvoalhrderizXDhL6n3IOW0lXrIhMjc=.efc336cd-cb0d-4c2b-b57c-0b4b5e1d3acf@github.com> Message-ID: <2NR4iR7XxODCUtD2RzMbBIhXL9ZG8lbfCZ8Hr6wL1LA=.5256ca35-3fa8-43cd-afff-0bd9ed6da0f6@github.com> On Fri, 22 Nov 2024 07:05:41 GMT, Alexander Zuev wrote: >> ??? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Update to lastest >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - Remove tab >> - Update to latest and make code safer >> - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 >> - 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea > > I tested this fix on Ubuntu 22 and 24 with X11 and Wayland and the fix works except for two minor notes: > 1. With old IM suggestion window it displayed the text we enter in the choose box as well as in the text area itself interactively which allows easy editing if you, for example, made a typo - you can use left and right arrows to navigate within the entered text and fix the typo. With the new style IM suggestion popup there is no visible cursor in the preview string and while it is technically possible to navigate with arrows within it to fix typo the lack of the cursor makes it much harder. > 2. With old IM when you start entering text and dismiss suggestion window with escape you will still have the text you entered in the text area. For example for Japanese (Mozc) IM with Hiragana input mode when you start typing you get hiragana representation in the text area right away and if you press escape the hiragana string you entered stays in the editor. With your fix no text appears in editor - only in the IM popup and if you press escape the text is gone. I do not know if this is intended behavior but it is a change of behavior and needs to be discussed. > > Also please take time to respond to valid technical requests from @NikitkoCent and @alisenchung - even though i like the new way of handling IM more than the old one i would hesitate to approve change that has unresolved technical questions. @azuev-java, hello! Am I right that you don't mind to accept the following behavior change? > With old IM suggestion window it displayed the text we enter in the choose box as well as in the text area itself interactively which allows easy editing if you, for example, made a typo - you can use left and right arrows to navigate within the entered text and fix the typo. With the new style IM suggestion popup there is no visible cursor in the preview string and while it is technically possible to navigate with arrows within it to fix typo the lack of the cursor makes it much harder. This is exactly what I wrote about in https://github.com/openjdk/jdk/pull/13055#issuecomment-2100900752 and wanted to get feedback about such a change from a project's Reviewer before starting working towards porting JetBrains' version of the patch ------------- PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2619405368 From duke at openjdk.org Tue Jan 28 16:07:59 2025 From: duke at openjdk.org (Nikita Provotorov) Date: Tue, 28 Jan 2025 16:07:59 GMT Subject: RFR: 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea [v12] In-Reply-To: References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com> Message-ID: <-dpVHBQsQWPjsf6Tsl9-MMYl2FRMLf-F0S86BHstPIg=.9a0a0fe5-a230-4d89-9bdb-cf2c3988c8a3@github.com> On Thu, 12 Dec 2024 00:05:33 GMT, ??? wrote: >> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem. >> >> 1, I wrote a example for linux: >> https://github.com/quantum6/X11InputMethod >> >> I tried all parameters to test and as my research: >> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret. >> If you use XIMPreeditNothing, it works. >> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes. >> >> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux. >> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK. >> 4, I am not sure for AIX( no environment). >> >> >> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea >> Type: Bug >> Component: client-libs >> Sub-Component: java.awt:i18n >> Affected Version: 8,9,15,16 >> Priority: P3 >> Status: Open >> Resolution: Unresolved >> OS: linux >> CPU: x86_64 > > ??? 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: > > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Update to lastest > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - Remove tab > - Update to latest and make code safer > - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6 > - ... and 1 more: https://git.openjdk.org/jdk/compare/4c28bcc5...0ab7a467 A few another issues with the current patch: * On KDE the preedit popup isn't positioned correctly. Most likely this is because HiDPI settings aren't taken into account - I observed the issue with 200% scale set (the used IM engine is _iBus_) ; * Preedit text doesn't get discarded when a mouse click happens in a different place _of the same component_, e.g. in a multi-lined `JTextArea` ; * The preedit popup isn't moved when the focused component is scrolled . Also please don't forget to take a look at my question in https://github.com/openjdk/jdk/pull/13055#issuecomment-2100914601 ------------- Changes requested by OnePatchGuy at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/13055#pullrequestreview-2578742908 From bourges.laurent at gmail.com Tue Jan 28 16:14:50 2025 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 28 Jan 2025 17:14:50 +0100 Subject: JDK-8297962 review ? Message-ID: Hi, I figured out yesterday that this fix was backported in jdk21.0.6 and it causes freezes... https://bugs.openjdk.org/browse/JDK-8296972 I did not see any client-libs reviewer as mandatory for awt changes. How was it reviewed ? Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Tue Jan 28 17:18:25 2025 From: alexey.ivanov at oracle.com (Aleksei Ivanov) Date: Tue, 28 Jan 2025 17:18:25 +0000 Subject: JDK-8297962 review ? In-Reply-To: References: Message-ID: <00535d76-1b9e-417c-8d67-d5d4d96a70f2@oracle.com> Hi Laurent, I don't think it was reviewed because the backport was clean: https://github.com/openjdk/jdk21u-dev/pull/965 The ?discussion? thread: https://mail.openjdk.org/pipermail/jdk-updates-dev/2024-September/037274.html The original changeset was reviewed by client-libs reviewers: https://github.com/openjdk/jdk/pull/14226 Is the problem reproducible with Oracle JDK 21.0.6? Is it reproducible with mainline? On 2025-01-28 16:14, Laurent Bourg?s wrote: > Hi, > > I figured out yesterday that this fix was backported in jdk21.0.6 and > it causes freezes... > > https://bugs.openjdk.org/browse/JDK-8296972 > > I did not see any client-libs reviewer as mandatory for awt changes. > How was it reviewed ? > > Cheers, > Laurent -- Regards, Alexey From aivanov at openjdk.org Tue Jan 28 17:37:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 17:37:48 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 20:13:26 GMT, Alexey Ivanov wrote: >> By the above statement are you referring to the lines 336 to 341? I'll admit I'm a little lost for this one > > I'll submit a new bug to address this problem. > > It's not just a matter of an unused variables, it's the logic error: if the buffer is too small, *a new buffer is allocated*, yet this new buffer isn't deleted afterwards, nor is used to read the value retrieved from the registry. I submitted [JDK-8348872](https://bugs.openjdk.org/browse/JDK-8348872): _jabswitch.cpp: regEnable and regDeleteValue leak reallocated data buffer_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1932597632 From aivanov at openjdk.org Tue Jan 28 17:37:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 17:37:50 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 20:34:26 GMT, Alexey Ivanov wrote: >> src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp line 364: >> >>> 362: } >>> 363: >>> 364: int regDeleteValue(HKEY hFamilyKey, LPCWSTR lpSubKey) >> >> There's one more memory leak: >> >> https://github.com/openjdk/jdk/blob/4a9fba615da0dfa6646ecb9fd9d929f74fe6875e/src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp#L352 >> >> The `delete[]` operator must be called on `newStr`. >> >> It's present in both `regEnable` and `regDeleteValue`. > > I'll also submit a new bug against it. I submitted [JDK-8348876](https://bugs.openjdk.org/browse/JDK-8348876): _jabswitch.cpp: regEnable and regDeleteValue leak newStr_ I assigned both bugs to myself, feel free to re-assign if you're going to address the issues. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1932599379 From aivanov at openjdk.org Tue Jan 28 17:40:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 17:40:51 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 20:36:20 GMT, Alexey Ivanov wrote: >> I wonder if this falls into the category of "Can be used in a debugger" like Alex mentioned above, if not I'll remove it > > I see no reason to keep it. > > If it's needed during debugging, there are many ways to find the handle. > > Otherwise, the edit control is accessed by its id: `cAccessInfoText`. It looks like this feature doesn't work: [JDK-8348882](https://bugs.openjdk.org/browse/JDK-8348882): )jaccesswalker: "Display Accessibility Information" doesn't work_ It's not related to your changes directly, it's just an observation after running `jaccesswalker.exe`; I'm still for removing `hwndEdit`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21656#discussion_r1932603818 From aivanov at openjdk.org Tue Jan 28 17:57:09 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 17:57:09 GMT Subject: RFR: 8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland In-Reply-To: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: On Tue, 28 Jan 2025 11:28:27 GMT, Alexander Zvegintsev wrote: > Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. > > Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) >> the reason is this is using XTEST, an X11 protocol which will not work outside of X11. >> >> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. > > I also tested the same tests by clicking manually instead of using the robot, and it works as expected. > So for now, skip those tests on Wayland (and do some minor cleanup). > > Testing after modifications is also green. Changes requested by aivanov (Reviewer). test/jdk/java/awt/TrayIcon/ActionCommand/ActionCommand.java line 68: > 66: > 67: public static void main(String[] args) throws Exception { > 68: if (Platform.isOnWayland()) { Perhaps, each `if` statement could be standalone? without the `else`. For both conditions `Platform.isOnWayland()` and `!SystemTray.isSupported()`, an exception is thrown, which means the test effectively finished. The following statements would be executed if and only if, no exception was thrown, therefore the indentation of the code could be reduced and the code would also look cleaner. test/jdk/java/awt/TrayIcon/ActionCommand/ActionCommand.java line 75: > 73: throw new SkippedException("SystemTray is not supported on this platform."); > 74: } else { > 75: if (System.getProperty("os.name").toLowerCase().startsWith("win")) { `Platform.isWindows()` could work better? as well `Platform.isOSX()` for Mac. The case `SystemTrayIconHelper.isOel7orLater()` should probably also throw `SkippedException`. test/jdk/java/awt/TrayIcon/ActionCommand/ActionCommand.java line 148: > 146: if (!actionPerformed) { > 147: throw new RuntimeException("FAIL: ActionEvent not triggered when TrayIcon is "+(isMacOS? "" : "double ")+"clicked"); > 148: } else if (! "Sample Command".equals(actionCommand)) { Suggestion: } else if (!"Sample Command".equals(actionCommand)) { test/jdk/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupClickTest.java line 41: > 39: * @summary Check if a action performed event is received when TrayIcon display > 40: * message is clicked on. > 41: * @author Shashidhara Veerabhadraiah (shashidhara.veerabhadraiah at oracle.com) Suggestion: The `@author` tags are removed. test/jdk/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java line 46: > 44: * @summary Check if a JPopupMenu can be displayed when TrayIcon is > 45: * right clicked. It uses a JWindow as the parent of the JPopupMenu > 46: * @author Dmitriy Ermashov (dmitriy.ermashov at oracle.com) Suggestion: The @author tags are removed. ------------- PR Review: https://git.openjdk.org/jdk/pull/23329#pullrequestreview-2579011225 PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932611515 PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932615258 PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932616875 PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932622551 PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932624759 From aivanov at openjdk.org Tue Jan 28 17:57:10 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 17:57:10 GMT Subject: RFR: 8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland In-Reply-To: References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: On Tue, 28 Jan 2025 17:47:56 GMT, Alexey Ivanov wrote: >> Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. >> >> Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) >>> the reason is this is using XTEST, an X11 protocol which will not work outside of X11. >>> >>> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. >> >> I also tested the same tests by clicking manually instead of using the robot, and it works as expected. >> So for now, skip those tests on Wayland (and do some minor cleanup). >> >> Testing after modifications is also green. > > test/jdk/java/awt/TrayIcon/ActionCommand/ActionCommand.java line 148: > >> 146: if (!actionPerformed) { >> 147: throw new RuntimeException("FAIL: ActionEvent not triggered when TrayIcon is "+(isMacOS? "" : "double ")+"clicked"); >> 148: } else if (! "Sample Command".equals(actionCommand)) { > > Suggestion: > > } else if (!"Sample Command".equals(actionCommand)) { Here, the chained `if` statements could be changed to separate statements. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932620308 From azvegint at openjdk.org Tue Jan 28 18:40:00 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 28 Jan 2025 18:40:00 GMT Subject: RFR: 8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland [v2] In-Reply-To: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: > Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. > > Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) >> the reason is this is using XTEST, an X11 protocol which will not work outside of X11. >> >> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. > > I also tested the same tests by clicking manually instead of using the robot, and it works as expected. > So for now, skip those tests on Wayland (and do some minor cleanup). > > Testing after modifications is also green. Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: - minor - review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23329/files - new: https://git.openjdk.org/jdk/pull/23329/files/71ea490d..f859c790 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23329&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23329&range=00-01 Stats: 103 lines in 4 files changed: 52 ins; 46 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23329/head:pull/23329 PR: https://git.openjdk.org/jdk/pull/23329 From azvegint at openjdk.org Tue Jan 28 18:40:01 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 28 Jan 2025 18:40:01 GMT Subject: RFR: 8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland [v2] In-Reply-To: References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: On Tue, 28 Jan 2025 17:44:19 GMT, Alexey Ivanov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: >> >> - minor >> - review comments > > test/jdk/java/awt/TrayIcon/ActionCommand/ActionCommand.java line 68: > >> 66: >> 67: public static void main(String[] args) throws Exception { >> 68: if (Platform.isOnWayland()) { > > Perhaps, each `if` statement could be standalone? without the `else`. For both conditions `Platform.isOnWayland()` and `!SystemTray.isSupported()`, an exception is thrown, which means the test effectively finished. The following statements would be executed if and only if, no exception was thrown, therefore the indentation of the code could be reduced and the code would also look cleaner. Sure, this is better, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1932680453 From achung at openjdk.org Tue Jan 28 18:42:50 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 18:42:50 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 18:44:43 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> init finX, finY > > src/java.desktop/share/classes/java/awt/Robot.java line 175: > >> 173: for (int i = 0; i < gs.length; i++) { >> 174: allScreenBounds[i] = gs[i].getDefaultConfiguration().getBounds(); >> 175: } > > This doesn't look right to me? `init` is an instance method, yet it initialises `allScreenBounds` which is shared among all instances. > > In a way it makes sense to share the graphics environment / configuration. On the other hand how much would it affect the operation of robot if the bounds are fetched from `GraphicsEnvironment` only when needed? > > What happens if the graphics configuration changes? Does the user need to create a new instance of the `Robot` class? I did consider this and thought it would be too expensive to fetch the bounds on every mouseMove action, so i thought it would be better to reinitialize robot when the graphics configuration changes. Do you have a better idea for where/when to cache the bounds? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1932683280 From aivanov at openjdk.org Tue Jan 28 18:45:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 18:45:50 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 18:39:44 GMT, Alisen Chung wrote: >> src/java.desktop/share/classes/java/awt/Robot.java line 175: >> >>> 173: for (int i = 0; i < gs.length; i++) { >>> 174: allScreenBounds[i] = gs[i].getDefaultConfiguration().getBounds(); >>> 175: } >> >> This doesn't look right to me? `init` is an instance method, yet it initialises `allScreenBounds` which is shared among all instances. >> >> In a way it makes sense to share the graphics environment / configuration. On the other hand how much would it affect the operation of robot if the bounds are fetched from `GraphicsEnvironment` only when needed? >> >> What happens if the graphics configuration changes? Does the user need to create a new instance of the `Robot` class? > > I did consider this and thought it would be too expensive to fetch the bounds on every mouseMove action, so i thought it would be better to reinitialize robot when the graphics configuration changes. Do you have a better idea for where/when to cache the bounds? The first question to answer: _Is it expensive to get screen data from GraphicsEnvironment?_ It shouldn't be, the data is already there, you just fetch the data. > it would be better to reinitialize robot when the graphics configuration changes But I see no code which re-initialises the cached graphics configuration if anything changes. Do I miss anything? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1932687868 From duke at openjdk.org Tue Jan 28 18:52:47 2025 From: duke at openjdk.org (duke) Date: Tue, 28 Jan 2025 18:52:47 GMT Subject: RFR: 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows [v7] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 19:07:28 GMT, Daniel Gredler wrote: >> This PR fixes the issue identified in JDK-8148334 in screenshots `Page8_landscape.JPG` and `Page8_portrait.JPG`. >> >> It does not address `mac_Page1.png` or `mac_Page8.png`, which I'm not even sure are still issues (I have no access to a Mac). >> >> The method in question, `PathGraphics.printedSimpleGlyphVector(...)` is quite complex, with many special cases being handled in different ways. In this specific scenario (page 8 of `PrintTextTest`), all special case checks fail, and we fall through all the way to the final handling block, which draws the individual characters one by one. It looks like the problem is that the font transform translation is applied twice, once via the glyph positions, and again by `drawString(...)` via the font. The proposed fix is to provide `drawString(...)` a font without any translation transform. >> >> Testing looks good on Linux, but needs to be done on Mac and Windows. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Add additional issue ID to PrintTextTest bug list @gredler Your change (at version 2652e10550672c837a103fafa00928e4cf74170d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21980#issuecomment-2619808836 From bourges.laurent at gmail.com Tue Jan 28 18:58:16 2025 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 28 Jan 2025 19:58:16 +0100 Subject: JDK-8297962 review ? In-Reply-To: <00535d76-1b9e-417c-8d67-d5d4d96a70f2@oracle.com> References: <00535d76-1b9e-417c-8d67-d5d4d96a70f2@oracle.com> Message-ID: Hi aleksei, I will investigate tonight with openjdk 21.0.6 vs jbr21 but this kind of lock.wait() looks like a hammer to be kicked later as I am fixing few freezes in JB IDEs... I will diagnose what is causing me problems here asap. Laurent Le mar. 28 janv. 2025, 18:18, Aleksei Ivanov a ?crit : > Hi Laurent, > > I don't think it was reviewed because the backport was clean: > https://github.com/openjdk/jdk21u-dev/pull/965 > > The ?discussion? thread: > > https://mail.openjdk.org/pipermail/jdk-updates-dev/2024-September/037274.html > > > The original changeset was reviewed by client-libs reviewers: > https://github.com/openjdk/jdk/pull/14226 > > > Is the problem reproducible with Oracle JDK 21.0.6? Is it reproducible > with mainline? > > On 2025-01-28 16:14, Laurent Bourg?s wrote: > > Hi, > > > > I figured out yesterday that this fix was backported in jdk21.0.6 and > > it causes freezes... > > > > https://bugs.openjdk.org/browse/JDK-8296972 > > > > I did not see any client-libs reviewer as mandatory for awt changes. > > How was it reviewed ? > > > > Cheers, > > Laurent > -- > Regards, > Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From achung at openjdk.org Tue Jan 28 19:06:55 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 19:06:55 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 16:47:42 GMT, Alexey Ivanov wrote: > Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay. > Use `Util.hitMnemonics` instead of custom code to handle macOS. > > I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI. LGTM, ran test on local machine (macOS sonoma 14.7) and it passses ------------- Marked as reviewed by achung (Committer). PR Review: https://git.openjdk.org/jdk/pull/23301#pullrequestreview-2579179803 From aivanov at openjdk.org Tue Jan 28 19:08:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 19:08:51 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v7] In-Reply-To: References: Message-ID: <6J8kAP8KNsMnv10vewjSoHQv2T2Pi3S2jfdVeUg4ytA=.93a0fc60-cd59-468a-9617-5132c20ec95d@github.com> On Tue, 28 Jan 2025 04:43:44 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 three additional commits since the last revision: > > - robot update > - Revert "robot multimonitor fix" > > This reverts commit 5734165881a66dc48d5a9f19e02bf63fac57cdc9. > - Revert "init finX, finY" > > This reverts commit 0eb4226fe6d3cf7406bf0124d4871388fb04a77e. Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/Robot.java line 234: > 232: for (Rectangle screenBounds : allScreenBounds) { > 233: int closestX = Math.min(Math.max(x, screenBounds.x), screenBounds.x + screenBounds.width); > 234: int closestY = Math.min(Math.max(y, screenBounds.y), screenBounds.y + screenBounds.height); I propose moving the code which calculates the closest???_final_???position of the mouse to a helper method, it would make the logic cleaner. src/java.desktop/share/classes/java/awt/Robot.java line 242: > 240: mouseMove(x,y); > 241: afterEvent(); > 242: return; So, now you recursively call `mouseMove` again? ------------- PR Review: https://git.openjdk.org/jdk/pull/22781#pullrequestreview-2579171240 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1932710714 PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1932708226 From aivanov at openjdk.org Tue Jan 28 19:14:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 28 Jan 2025 19:14:47 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 10:03:45 GMT, Sergey Bylokhov wrote: > I would like to clarify one point: if the robot moves the mouse off the screen while the actual mouse pointer is on the screen and immediately presses the mouse button, where will the click occur? on or off the screen? That's a good question? How do we validate it? Mouse events are usually sent to the window under the mouse cursor, so we create a set windows or a single large window which cover the entire virtual screen and some additional space to accommodate the off-screen location where we will move the mouse cursor to. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2619852452 From prr at openjdk.org Tue Jan 28 19:22:49 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 28 Jan 2025 19:22:49 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Runtime Exception added ICC specifies 4 rendering intents, no more. And is clear that these are the 4 ICC rendering intents. Non-ICC intents are not something we'd support. I see absolutely no problem with that. If a profile has an intent that is unknown to JDK APIs, it doesn't matter what LCMS might do with it if you were programming directly to LCMS as a CMM. Who knows how many things we'd have to do in order to support 'custom' ICC intents. For Color Spaces, the ICC spec. says "The names and signatures of the permitted data colour spaces are shown in Table 19." The word "permitted" makes it clear that anything not in this table is not permitted, and thus illegal. So in summary, the changes made here are all fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2619867896 From philip.race at oracle.com Tue Jan 28 19:32:41 2025 From: philip.race at oracle.com (Philip Race) Date: Tue, 28 Jan 2025 11:32:41 -0800 Subject: JDK-8297962 review ? In-Reply-To: References: <00535d76-1b9e-417c-8d67-d5d4d96a70f2@oracle.com> Message-ID: <11f144a4-fdfc-4fbd-ac55-e4c8721b732f@oracle.com> SFAIK, we've not had any other reports of this. Perhaps the JDK used by JB IDE has some other changes too ? But aside from waiting forever to be questionable (I would guess that a few seconds is more reasonable), why would the state change never happens / gets lost ? The code wants a specific state (NORMAL). What if the window is transitioned to some other state instead ? So there's a couple of possibilities. -phil. On 1/28/25 10:58 AM, Laurent Bourg?s wrote: > > Hi aleksei, > > I will investigate tonight with openjdk 21.0.6 vs jbr21 but this kind > of lock.wait() looks like a hammer to be kicked later as I am fixing > few freezes in JB IDEs... > I will diagnose what is causing me problems here asap. > > Laurent > > > Le mar. 28 janv. 2025, 18:18, Aleksei Ivanov > a ?crit?: > > Hi Laurent, > > I don't think it was reviewed because the backport was clean: > https://github.com/openjdk/jdk21u-dev/pull/965 > > The ?discussion? thread: > https://mail.openjdk.org/pipermail/jdk-updates-dev/2024-September/037274.html > > > The original changeset was reviewed by client-libs reviewers: > https://github.com/openjdk/jdk/pull/14226 > > > Is the problem reproducible with Oracle JDK 21.0.6? Is it > reproducible > with mainline? > > On 2025-01-28 16:14, Laurent Bourg?s wrote: > > Hi, > > > > I figured out yesterday that this fix was backported in > jdk21.0.6 and > > it causes freezes... > > > > https://bugs.openjdk.org/browse/JDK-8296972 > > > > I did not see any client-libs reviewer as mandatory for awt changes. > > How was it reviewed ? > > > > Cheers, > > Laurent > -- > Regards, > Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.org Tue Jan 28 19:46:45 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 28 Jan 2025 19:46:45 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. Marked as reviewed by prr (Reviewer). Not all libraries do especially performance critical things. For the client ones, fontmanager (does opentype layout), freetype (font rasterisation), awt (many of the core rendering loops), lcms (color processing), jpeg (image decoding), mlib_image (image processing) are ones where HIGHEST is set and should be important. For the rest, it is is probably not critical, so LOW should not be a problem. ------------- PR Review: https://git.openjdk.org/jdk/pull/23332#pullrequestreview-2579257241 PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2619910489 From dgredler at openjdk.org Tue Jan 28 20:05:58 2025 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 28 Jan 2025 20:05:58 GMT Subject: Integrated: 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 14:44:18 GMT, Daniel Gredler wrote: > This PR fixes the issue identified in JDK-8148334 in screenshots `Page8_landscape.JPG` and `Page8_portrait.JPG`. > > It does not address `mac_Page1.png` or `mac_Page8.png`, which I'm not even sure are still issues (I have no access to a Mac). > > The method in question, `PathGraphics.printedSimpleGlyphVector(...)` is quite complex, with many special cases being handled in different ways. In this specific scenario (page 8 of `PrintTextTest`), all special case checks fail, and we fall through all the way to the final handling block, which draws the individual characters one by one. It looks like the problem is that the font transform translation is applied twice, once via the glyph positions, and again by `drawString(...)` via the font. The proposed fix is to provide `drawString(...)` a font without any translation transform. > > Testing looks good on Linux, but needs to be done on Mac and Windows. This pull request has now been integrated. Changeset: c018a604 Author: Daniel Gredler Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/c018a604f6857e319bf8b14913c14dc2d36aaca1 Stats: 44 lines in 4 files changed: 21 ins; 13 del; 10 mod 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows Reviewed-by: honkar, prr ------------- PR: https://git.openjdk.org/jdk/pull/21980 From prr at openjdk.org Tue Jan 28 20:16:47 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 28 Jan 2025 20:16:47 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: <5rLwREvBwD_4oD3b2to9uvQafxCJ8XFVCXyvjxvMuIY=.198a6e8f-46fa-4b2c-8960-492d7d9f3307@github.com> On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. >> >> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 >> >> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. >> >> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Update @serialData text to CSR-approved version Approving the datatransfer portion .. at least ... ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2579320786 PR Comment: https://git.openjdk.org/jdk/pull/22980#issuecomment-2619967593 From stanio at yahoo.com Tue Jan 28 20:19:08 2025 From: stanio at yahoo.com (Stanimir Stamenkov) Date: Tue, 28 Jan 2025 22:19:08 +0200 Subject: JDK-8297962 review ? In-Reply-To: <11f144a4-fdfc-4fbd-ac55-e4c8721b732f@oracle.com> References: <00535d76-1b9e-417c-8d67-d5d4d96a70f2@oracle.com> <11f144a4-fdfc-4fbd-ac55-e4c8721b732f@oracle.com> Message-ID: <7172c433-6a66-441f-a584-b457a10c9d9c@yahoo.com> Tue, 28 Jan 2025 11:32:41 -0800, /Philip Race/: > why would the state change never happens / gets lost ? Is it possible the state changes after the 'if', and before the lock is obtained? if (peer.getState() != state) { synchronized (lock) { Maybe the the 'if' test should be re-evaluated inside the synchronized block, first or maybe using a CountDownLatch is more suitable: CountDownLatch latch = new CountDownLatch(1); WindowStateListener wsl = new WindowStateListener() { public void windowStateChanged(WindowEvent e) { if (e.getNewState() == state) { latch.countDown(); } } }; target.addWindowStateListener(wsl); for (int retries = 5; retries > 0 && peer.getState() != state; retries--) { try { latch.await(1, TimeUnit.SECONDS); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); break; } } target.removeWindowStateListener(wsl); > The code wants a specific state (NORMAL). What if the window is > transitioned to some other state instead ? > So there's a couple of possibilities. -- From achung at openjdk.org Tue Jan 28 22:32:07 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 22:32:07 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v8] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: fix implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22781/files - new: https://git.openjdk.org/jdk/pull/22781/files/1bd09930..42962d24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=06-07 Stats: 56 lines in 2 files changed: 39 ins; 5 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/22781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781 PR: https://git.openjdk.org/jdk/pull/22781 From achung at openjdk.org Tue Jan 28 22:37:08 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 22:37:08 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v9] In-Reply-To: References: Message-ID: <68tz9NqSnXspA87LBI0PnsubePBAeylYRjkzFpa03Ow=.2c42d16d-46c9-4b22-bea8-b787ea209186@github.com> > 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 one additional commit since the last revision: peer.mouseMove ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22781/files - new: https://git.openjdk.org/jdk/pull/22781/files/42962d24..5117a272 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781 PR: https://git.openjdk.org/jdk/pull/22781 From achung at openjdk.org Tue Jan 28 23:06:29 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 23:06:29 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v10] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: fix bounds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22781/files - new: https://git.openjdk.org/jdk/pull/22781/files/5117a272..e929a07a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781 PR: https://git.openjdk.org/jdk/pull/22781 From achung at openjdk.org Tue Jan 28 23:11:47 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 23:11:47 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: <2OJDaTvxuwEg8SoHWW9VgJqNmuvMf21XUhUXCxIMJrc=.51d32787-914e-4281-b4bd-9fd168891b20@github.com> On Fri, 24 Jan 2025 18:51:04 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> init finX, finY > > src/java.desktop/share/classes/java/awt/Robot.java line 253: > >> 251: leastXDiff = currXDiff; >> 252: leastYDiff = currYDiff; >> 253: } > > Both branches must be executed at the same time ? you have adjust both x and y if the diff isn't 0. > > Probably, min/max would work better here too. I changed the algorithm to keep track of the closest screen in the x direction and the closest screen in the y direction, then at the end choose the closer screen between x and y distances ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1932987627 From achung at openjdk.org Tue Jan 28 23:21:26 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 23:21:26 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v11] In-Reply-To: References: Message-ID: > 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: - helper function - grab screen data on mouseMove ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22781/files - new: https://git.openjdk.org/jdk/pull/22781/files/e929a07a..5cd1e6a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22781&range=09-10 Stats: 29 lines in 1 file changed: 13 ins; 9 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/22781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22781/head:pull/22781 PR: https://git.openjdk.org/jdk/pull/22781 From achung at openjdk.org Tue Jan 28 23:21:26 2025 From: achung at openjdk.org (Alisen Chung) Date: Tue, 28 Jan 2025 23:21:26 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: <_iyxgTGC4lqBGOPhyarQ9xqR7Wmhf2UeplYhW_5F_zE=.77a829b3-10be-45a3-9184-71b9ee74eaf1@github.com> On Tue, 28 Jan 2025 18:43:28 GMT, Alexey Ivanov wrote: > But I see no code which re-initialises the cached graphics configuration if anything changes. > > Do I miss anything? What I meant was have the user reinitialize the instance of robot, but it's not a clean solution. I've now updated it to grab the screen data during the mouseMove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1932993258 From prr at openjdk.org Tue Jan 28 23:26:58 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 28 Jan 2025 23:26:58 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception So this is much better than what was there in the beginning. FindClass failing - for a key API class - is probably a fatal error one way or another. Although in all (?) other cases, we try to return to Java and let the VM throw a Java-level error. Note that OnLoad is not the only code path that calls AWTIsHeadless, and there will be Java code to return to in the other case. However I think that the OnLoad will always be reached first, so maybe it is OK to do the current fix. Either way, things aren't going to work. Generally the calls to check and clear exceptions when looking up code are there to keep 'tools' happy. If these classes aren't found something is badly wrong. meaning it should NEVER EVER happen. Failing to find java/lang/String for example hardly seems like something it is worth trying to recover from .. In your case it seems like it does some times happen for GraphicsEnvironment which still worries me. I don't want to make this fix a precedent for assuming that it is normal for classes to be missing. So consider it a truly exceptional case. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20169#pullrequestreview-2579630865 From serb at openjdk.org Tue Jan 28 23:28:51 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 28 Jan 2025 23:28:51 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v9] In-Reply-To: <68tz9NqSnXspA87LBI0PnsubePBAeylYRjkzFpa03Ow=.2c42d16d-46c9-4b22-bea8-b787ea209186@github.com> References: <68tz9NqSnXspA87LBI0PnsubePBAeylYRjkzFpa03Ow=.2c42d16d-46c9-4b22-bea8-b787ea209186@github.com> Message-ID: On Tue, 28 Jan 2025 22:37:08 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 one additional commit since the last revision: > > peer.mouseMove src/java.desktop/share/classes/java/awt/Robot.java line 176: > 174: > 175: for (int i = 0; i < gs.length; i++) { > 176: allScreenBounds[i] = gs[i].getDefaultConfiguration().getBounds(); This data cannot be cached, it can be modified at runtime. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1932999242 From serb at openjdk.org Tue Jan 28 23:48:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 28 Jan 2025 23:48:48 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 14:51:57 GMT, Alexey Ivanov wrote: > The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. > > Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. > > I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. > > The updated test passes in the CI. test/jdk/javax/swing/JButton/4796987/bug4796987.java line 60: > 58: public static void main(String[] args) throws Exception { > 59: try { > 60: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); maybe we can check all installed L&Fs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1933012537 From serb at openjdk.org Tue Jan 28 23:50:49 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 28 Jan 2025 23:50:49 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:12:30 GMT, Alexey Ivanov wrote: > Mouse events are usually sent to the window under the mouse cursor, so we create a set windows or a single large window which cover the entire virtual screen and some additional space to accommodate the off-screen location where we will move the mouse cursor to. Yes, that is how we can check it to know whether it is really a bug or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2620284556 From serb at openjdk.org Wed Jan 29 00:02:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 29 Jan 2025 00:02:50 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 23:23:44 GMT, Phil Race wrote: > So consider it a truly exceptional case. `FindClass("java/awt/GraphicsEnvironment")` can fail with OutOfMemoryError, so even in this fix it is not an exceptional case. We still assume that standard classes should always be present in the bundle. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2620297264 From serb at openjdk.org Wed Jan 29 00:13:49 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 29 Jan 2025 00:13:49 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v6] In-Reply-To: References: Message-ID: <240FhuAAemC-HchgUQ7shUdFm_WCc1GkR7kk7IWmxKc=.cf1dad64-7d10-4902-86b0-c8582b8b13ea@github.com> On Mon, 27 Jan 2025 14:25:08 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with three additional commits since the last revision: > > - Reduce the line length > > Co-authored-by: Alexey Ivanov > - Reduce the line length > > Co-authored-by: Alexey Ivanov > - add "@build jdk.test.lib.Platform jtreg.SkippedException" > > Co-authored-by: Alexey Ivanov btw please enable pre-submit tests in your fork. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23183#issuecomment-2620309564 From serb at openjdk.org Wed Jan 29 00:20:46 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 29 Jan 2025 00:20:46 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23332#pullrequestreview-2579685295 From serb at openjdk.org Wed Jan 29 00:22:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 29 Jan 2025 00:22:48 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 16:47:42 GMT, Alexey Ivanov wrote: > Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay. > Use `Util.hitMnemonics` instead of custom code to handle macOS. > > I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI. test/jdk/javax/swing/AbstractButton/bug6298940.java line 86: > 84: } > 85: } finally { > 86: SwingUtilities.invokeAndWait(() -> frame.dispose()); Usually we follow a pattern to check the frame for null. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23301#discussion_r1933035733 From serb at openjdk.org Wed Jan 29 00:24:47 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 29 Jan 2025 00:24:47 GMT Subject: RFR: 8348648: Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit In-Reply-To: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> References: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> Message-ID: On Mon, 20 Jan 2025 13:07:19 GMT, Andrey Turbanov wrote: > Two `Hashtable`'s in `javax.swing.text.html.CSS.LengthUnit` class are modified only within `` block: > 1. lengthMapping > 2. w3cLengthMapping > > We can replace them with immutable maps to avoid Hashtable synchronization overhead. Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23198#pullrequestreview-2579689084 From serb at openjdk.org Wed Jan 29 02:57:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 29 Jan 2025 02:57:52 GMT Subject: RFR: 8346828: javax/swing/JScrollBar/4865918/bug4865918.java still fails in CI [v2] In-Reply-To: References: <6fI7ASQUHVtYX3hJlWDsB4HEJbWNmc0WhVuLQioyxC4=.281743c0-22d5-49e0-8456-81666a34eba8@github.com> Message-ID: On Wed, 8 Jan 2025 04:26:53 GMT, Prasanta Sadhukhan wrote: > We can restrict the test to windows/linux as [JDK-4865918](https://bugs.openjdk.org/browse/JDK-4865918) was meant for windows 2000, linux It is for sure should work on macOS, the bug you mentioned was reported at time we did not have macOS port. I suggest to create another ticket and update the test to be headful and working on macOS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22937#issuecomment-2620516256 From psadhukhan at openjdk.org Wed Jan 29 02:59:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 29 Jan 2025 02:59:03 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] 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: <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> > When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon. > If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present. Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/bc5580ff..befbdf55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 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 Wed Jan 29 02:59:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 29 Jan 2025 02:59:04 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Tue, 28 Jan 2025 08:36:59 GMT, Damon Nguyen wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 860: > >> 858: State state; >> 859: if (isEnabled(c, null)) { >> 860: backgroundState = State.NORMAL; > > Do you happen to know why `State.BITMAP` was originally here? I tried locating where it originated from, but can't pinpoint exactly why it's either `State.BITMAP` or `State.NORMAL` based on the icon being `null`. Curious only because we're completely eliminating it here and there might be a dependency. However, I haven't encountered any issues when testing yet. I guess if we can use normal resolution image, then its best to use it than bitmap image which can be flaky..Probably, in earlier days, image icons used to come in bitmap format.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1933144129 From psadhukhan at openjdk.org Wed Jan 29 02:59:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 29 Jan 2025 02:59:04 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Tue, 28 Jan 2025 13:43:51 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java line 51: >> >>> 49: Verify that for JRadioButtonMenuItem with imageicon, >>> 50: radiobutton is been shown alongside the imageicon. >>> 51: If radiobutton is shown, test passes else fails."""; >> >> Suggestion: >> >> One JRadioButtonMenuItem is with imageicon and >> another one without imageicon. >> Verify that for JRadioButtonMenuItem with imageicon, >> radiobutton is been shown alongside the imageicon. >> If radiobutton is shown, test passes. Else fails."""; >> >> >> Just for consistency, I see theres one capital `i`. I guess you can also just title-case all of the UI components. Ex: ImageIcon and RadioButton. > > With it's referred to the type `ImageIcon`, both `i` need to be capitalised; on the other hand, it doesn't make sense for the tester, as they may know nothing about the underlying code and shouldn't know. Just use ?image?, it's less confusing than imageicon?is it an image, or is it an icon? Both terms have meaning in UI. I used "image icon" as it is about icon from image ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1933145505 From psadhukhan at openjdk.org Wed Jan 29 02:59:04 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 29 Jan 2025 02:59:04 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: <4gUF0U5hrzDoPxm8Fsh5FXSagqzP0884hdG5ZOP2pYg=.aea09fdc-6839-49b2-b8e4-d7f0af224bc1@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <4gUF0U5hrzDoPxm8Fsh5FXSagqzP0884hdG5ZOP2pYg=.aea09fdc-6839-49b2-b8e4-d7f0af224bc1@github.com> Message-ID: On Tue, 28 Jan 2025 13:45:05 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting > > test/jdk/javax/swing/JMenuItem/duke.gif line 1: > >> 1: GIF89ap!???:,???3f?????????++3+f+???+???+???UU3UfU???U???U?????????3???f????????????????????????3???f????????????????????????3???f????????????????????3???f??????????????????3333f3???3???3???3+3+33+f3+???3+???3+???3U3U33Uf3U???3U???3U???3???3???33???f3??????3??????3??????3???3???33???f3??????3??????3??????3???3???33???f3??3??????3??????3???3???33???f3??????3??????3??????ff3fff???f???f???f+f+3f+ff+???f+???f+???fUfU3fUffU???fU???fU???f???f???3f???ff??????f??????f??????f???f???3f???ff??????f??????f??????f???f???3f???ff??f??????f??????f???f???3f???ff??????f??????f????????????3???f?????????????????+???+3???+f???+??????+??+??????U???U3???Uf???U??????U??U???????????????3??????f???????????????????????????????????3??????f???????????????????????????????????3??????f???????????????????????????????3??????f?????????????????????????????3???f?????????????????????+???+3???+f?? ?+??????+??????+??????U???U3???Uf???U??????U??????U???????3??f???????????????????3??f???????????????????????????3??????f???????????????????????????????????3??????f?????????????????????????????????3???f?????????????????????+???+3???+f???+??????+??????+??????U???U3???Uf???U??????U??????U???????????????3??????f???????????????????????????????????????3??????f???????????????????????????????????????3??????f???????????????????????????????????3??????f????????????????????????????????? Hp1e > ???f???B????????#F?????????&??M??????bb`???@b %???OL???052??????, > J??????z????????????F??????l?????????L???C??????1R???o??????}??? T?????? ????????????R}??? ?????U f??????L+??72?????????F??????O???2???T1???}????????; > > Can't you generate an image on the fly? It doesn't have to be Duke, any image like a red square or rectangle will do. I chose not to as firstly, for the test to be same as actual usecase where proper gif image is used so as to trace the same image decoding codepath and secondly, since it is about image icon, it will be easier for tester to discern if there is actual image rather than a red sqaure/rectangle which tester can think of primitives and finally, there will not be a licensing issue for duke so I guess this is ok for this test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1933143385 From bourges.laurent at gmail.com Wed Jan 29 06:57:36 2025 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 29 Jan 2025 07:57:36 +0100 Subject: JDK-8297962 review ? In-Reply-To: <7172c433-6a66-441f-a584-b457a10c9d9c@yahoo.com> References: <00535d76-1b9e-417c-8d67-d5d4d96a70f2@oracle.com> <11f144a4-fdfc-4fbd-ac55-e4c8721b732f@oracle.com> <7172c433-6a66-441f-a584-b457a10c9d9c@yahoo.com> Message-ID: Hi, My main concerns consists in avoiding any deadlock due to appkit (main thread), EDT, flusher & disposer + user threads... Instead of new lock.wait(), why not rely on other existing patterns like LWCToolkit.invokeAndWait() ? It implements non-blocking rendez-vous to avoid appkit or EDT threads to wait but perform other pending events meanwhile. More details later, Laurent Le mar. 28 janv. 2025, 21:19, Stanimir Stamenkov a ?crit : > Tue, 28 Jan 2025 11:32:41 -0800, /Philip Race/: > > > why would the state change never happens / gets lost ? > > Is it possible the state changes after the 'if', and before the lock is > obtained? > > if (peer.getState() != state) { > synchronized (lock) { > > Maybe the the 'if' test should be re-evaluated inside the synchronized > block, first or maybe using a CountDownLatch is more suitable: > > CountDownLatch latch = new CountDownLatch(1); > WindowStateListener wsl = new WindowStateListener() { > public void windowStateChanged(WindowEvent e) { > if (e.getNewState() == state) { > latch.countDown(); > } > } > }; > > target.addWindowStateListener(wsl); > for (int retries = 5; retries > 0 > && peer.getState() != state; retries--) { > try { > latch.await(1, TimeUnit.SECONDS); > } catch (InterruptedException ie) { > Thread.currentThread().interrupt(); > break; > } > } > target.removeWindowStateListener(wsl); > > > The code wants a specific state (NORMAL). What if the window is > > transitioned to some other state instead ? > > So there's a couple of possibilities. > > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbaesken at openjdk.org Wed Jan 29 08:25:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 29 Jan 2025 08:25:52 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. Thanks for the reviews ! > Not all libraries do especially performance critical things. Agree, it was not my suggestion to set everywhere HIGH/HIGHEST . The question I had is - are there libraries where we set LOW because higher/other opt-levels would break the library (compilation and also runtime - wise) ? For most of the libs probably other opt levels would work too, but it is hard to say in general. Other question - for hotspot / libjvm we have the option to influence the opt - level we want to use in the build, e.g. by setting jvm feature opt-size and als link-time-optimization . As far as I know we do not have this yet for JDK native libs. I would like to have it at least for libs where it is possible and does not break anything (probably some opt-in parameter of the make rule of the lib ). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2620965972 From mbaesken at openjdk.org Wed Jan 29 08:25:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 29 Jan 2025 08:25:52 GMT Subject: Integrated: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. This pull request has now been integrated. Changeset: 168a471f Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/168a471fd0b6cc7c6a9e2ada19edbc489d62849c Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod 8348830: LIBFONTMANAGER optimization is always HIGHEST Reviewed-by: erikj, prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/23332 From tr at openjdk.org Wed Jan 29 08:26:50 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 29 Jan 2025 08:26:50 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v3] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Fri, 24 Jan 2025 12:24:02 GMT, Prasanta Sadhukhan wrote: >> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below >> >> ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) >> >> Native windows progressbar renders without leaving any gap as can be seen here >> >> ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) >> >> so the padding is removed to render the progressbar similar to windows native and it is rendered properly >> >> ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > hidpi support for line stroke width/height I tested the fix with the proposed test, works as expected. I guess making the test automatic would be great. ------------- PR Review: https://git.openjdk.org/jdk/pull/23227#pullrequestreview-2580305013 From psadhukhan at openjdk.org Wed Jan 29 08:26:50 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 29 Jan 2025 08:26:50 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v3] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 29 Jan 2025 08:22:53 GMT, Tejesh R wrote: > I tested the fix with the proposed test, works as expected. I guess making the test automatic would be great. SInce finer details need to be looked at, I intended to keep it manual.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2620970935 From tr at openjdk.org Wed Jan 29 08:45:03 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 29 Jan 2025 08:45:03 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v3] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 29 Jan 2025 08:24:16 GMT, Prasanta Sadhukhan wrote: > > I tested the fix with the proposed test, works as expected. I guess making the test automatic would be great. > > SInce finer details need to be looked at, I intended to keep it manual.. Actually I felt it the other way. To test it manually, I had to take screen shot, copy to paint app and then zoom to verify it. I guess it would be easier to test automatic by comparing the colors of entire progress portion. Btw what finer details you are referring to ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2620999297 From psadhukhan at openjdk.org Wed Jan 29 08:45:03 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 29 Jan 2025 08:45:03 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v3] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 29 Jan 2025 08:40:25 GMT, Tejesh R wrote: > > > I tested the fix with the proposed test, works as expected. I guess making the test automatic would be great. > > > > > > SInce finer details need to be looked at, I intended to keep it manual.. > > Actually I felt it the other way. To test it manually, I had to take screen shot, copy to paint app and then zoom to verify it. I guess it would be easier to test automatic by comparing the colors of entire progress portion. Btw what finer details you are referring to ? The same thing you saw in your first comment..there is a pixel off from the margin.for BAD bar... I would still keep it manual for now.. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2621002863 From tr at openjdk.org Wed Jan 29 09:39:47 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 29 Jan 2025 09:39:47 GMT Subject: RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v3] In-Reply-To: References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Fri, 24 Jan 2025 12:24:02 GMT, Prasanta Sadhukhan wrote: >> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below >> >> ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) >> >> Native windows progressbar renders without leaving any gap as can be seen here >> >> ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) >> >> so the padding is removed to render the progressbar similar to windows native and it is rendered properly >> >> ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > hidpi support for line stroke width/height Fix looks good to me. ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23227#pullrequestreview-2580471048 From tr at openjdk.org Wed Jan 29 09:47:47 2025 From: tr at openjdk.org (Tejesh R) Date: Wed, 29 Jan 2025 09:47:47 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 14:51:57 GMT, Alexey Ivanov wrote: > The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. > > Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. > > I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. > > The updated test passes in the CI. If the test is for only XP, then why to retain it ? Can't we remove the test since xp is not supported ? ------------- PR Review: https://git.openjdk.org/jdk/pull/23336#pullrequestreview-2580488275 From duke at openjdk.org Wed Jan 29 11:25:03 2025 From: duke at openjdk.org (anass baya) Date: Wed, 29 Jan 2025 11:25:03 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v7] In-Reply-To: References: Message-ID: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. anass baya has updated the pull request incrementally with one additional commit since the last revision: Allow a margin tolerance of 1 pixel due to scaling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23183/files - new: https://git.openjdk.org/jdk/pull/23183/files/f66aa032..2eae7575 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=05-06 Stats: 19 lines in 1 file changed: 2 ins; 15 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From aivanov at openjdk.org Wed Jan 29 12:18:57 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 12:18:57 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception Marked as reviewed by aivanov (Reviewer). src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 48: > 46: #define CHECK_EXCEPTION_FATAL(env, message) \ > 47: if ((*env)->ExceptionCheck(env)) { \ > 48: (*env)->ExceptionDescribe(env); \ Is it possible that `ExceptionDescribe` could leak something important? Should we preserve `ExceptionClear` instead? ------------- PR Review: https://git.openjdk.org/jdk/pull/20169#pullrequestreview-2580855884 PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1933773087 From aivanov at openjdk.org Wed Jan 29 12:18:58 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 12:18:58 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 16:12:34 GMT, Karm Michal Babacek wrote: >> src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c line 70: >> >>> 68: graphicsEnvClass = (*env)->FindClass(env, >>> 69: "java/awt/GraphicsEnvironment"); >>> 70: CHECK_EXCEPTION_FATAL(env, "FindClass java/awt/GraphicsEnvironment failed"); >> >> If `FindClass` fails to find the class, a `NoClassDefFoundError` should be raised. This function returns immediately (a value of `true`). The caller of this function should check if there's a pending exception and perform an appropriate action. >> >> In this case, the function is called from >> >> https://github.com/openjdk/jdk/blob/955bf185c38ec0fcedb0a549461fc85367b37fbb/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L130-L132 >> >> If there's a pending exception, it should bail out and let the exception be thrown on the Java side. >> >> If it doesn't, the pending exception makes `JNU_NewStringPlatform` fail at >> >> https://github.com/openjdk/jdk/blob/955bf185c38ec0fcedb0a549461fc85367b37fbb/src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c#L149-L150 >> >> --- >> >> Ah! There's no Java code to catch the exception? `AWT_OnLoad` is essentially `JNI_OnLoad`. In this case, `CHECK_EXCEPTION_FATAL` seems right. > > Hello @aivanov-jdk, > > Thank you for looking into the review. > > Is there anything I can do to move things forward right now? It's not clear to me whether you agree or disagree with the latest iteration inspired by @mrserb 's review. > > > Cheers > Karm Sorry, I didn't make myself clear. Since there's no Java code to catch the exception, there's no other option but to call `(*env)->FatalError` via `CHECK_EXCEPTION_FATAL`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20169#discussion_r1933775711 From aivanov at openjdk.org Wed Jan 29 12:22:52 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 12:22:52 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 09:44:42 GMT, Tejesh R wrote: > If the test is for only XP, then why to retain it ? Can't we remove the test since xp is not supported ? The test is still relevant: visual styles that were introduced in Windows XP are still here. Essentially, the test verifies that no button gradients are painted if painting border is disabled. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23336#issuecomment-2621491349 From aivanov at openjdk.org Wed Jan 29 12:22:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 12:22:53 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable In-Reply-To: References: Message-ID: <2Ur6_ymOMG_ItEYncKnpkPPd0TuAM3Cr93dQM9XAmMA=.c04a9ee1-ad2b-45b3-88b0-0ddaee66ea1f@github.com> On Tue, 28 Jan 2025 23:45:54 GMT, Sergey Bylokhov wrote: >> The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. >> >> Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. >> >> I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. >> >> The updated test passes in the CI. > > test/jdk/javax/swing/JButton/4796987/bug4796987.java line 60: > >> 58: public static void main(String[] args) throws Exception { >> 59: try { >> 60: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); > > maybe we can check all installed L&Fs? It's not applicable to other L&Fs as far as I can see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1933779652 From duke at openjdk.org Wed Jan 29 12:25:29 2025 From: duke at openjdk.org (anass baya) Date: Wed, 29 Jan 2025 12:25:29 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: References: Message-ID: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. anass baya has updated the pull request incrementally with one additional commit since the last revision: Add debug output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23183/files - new: https://git.openjdk.org/jdk/pull/23183/files/2eae7575..017da1ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23183&range=06-07 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23183/head:pull/23183 PR: https://git.openjdk.org/jdk/pull/23183 From mbaesken at openjdk.org Wed Jan 29 13:25:47 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 29 Jan 2025 13:25:47 GMT Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and ShapeSINextSpan in libawt java2d from ubsan checks In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 09:23:52 GMT, Matthias Baesken wrote: > In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) > jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows > > jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int' > #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683 > #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499 > #2 0x7efe9b8dee7b () > > java/awt/BasicStroke/DashStrokeTest.java shows > > src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int' > #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366 > #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75 > #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92 > #3 0x7fba12d07e7b () > > > There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings. I moved the ubsan 'exclusion' to a subissue and opened parent issue https://bugs.openjdk.org/browse/JDK-8348966 for the 2 overflows . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2621644532 From mbaesken at openjdk.org Wed Jan 29 13:45:54 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 29 Jan 2025 13:45:54 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 14:35:45 GMT, Matthias Baesken wrote: > BUILD_LIBAWT_XAWT LOW Regarding BUILD_LIBAWT_XAWT I wonder why LOW is set; there is some java2d / OGL coding in the lib and there the performance is probably important? java.desktop/libawt_xawt/AccelGlyphCache.o java.desktop/libawt_xawt/CUPSfuncs.o java.desktop/libawt_xawt/GLXGraphicsConfig.o java.desktop/libawt_xawt/GLXSurfaceData.o java.desktop/libawt_xawt/OGLBlitLoops.o java.desktop/libawt_xawt/OGLBufImgOps.o java.desktop/libawt_xawt/OGLContext.o java.desktop/libawt_xawt/OGLFuncs.o java.desktop/libawt_xawt/OGLMaskBlit.o java.desktop/libawt_xawt/OGLMaskFill.o java.desktop/libawt_xawt/OGLPaints.o java.desktop/libawt_xawt/OGLRenderQueue.o java.desktop/libawt_xawt/OGLRenderer.o java.desktop/libawt_xawt/OGLSurfaceData.o java.desktop/libawt_xawt/OGLTextRenderer.o java.desktop/libawt_xawt/OGLVertexCache.o java.desktop/libawt_xawt/X11Color.o java.desktop/libawt_xawt/X11FontScaler_md.o java.desktop/libawt_xawt/X11PMBlitLoops.o java.desktop/libawt_xawt/X11Renderer.o java.desktop/libawt_xawt/X11SurfaceData.o java.desktop/libawt_xawt/X11TextRenderer_md.o java.desktop/libawt_xawt/XRBackendNative.o java.desktop/libawt_xawt/XRSurfaceData.o java.desktop/libawt_xawt/XToolkit.o java.desktop/libawt_xawt/XWindow.o java.desktop/libawt_xawt/XlibWrapper.o java.desktop/libawt_xawt/awt_AWTEvent.o java.desktop/libawt_xawt/awt_Desktop.o java.desktop/libawt_xawt/awt_DrawingSurface.o java.desktop/libawt_xawt/awt_Event.o java.desktop/libawt_xawt/awt_Font.o java.desktop/libawt_xawt/awt_GraphicsEnv.o java.desktop/libawt_xawt/awt_InputMethod.o java.desktop/libawt_xawt/awt_Insets.o java.desktop/libawt_xawt/awt_Robot.o java.desktop/libawt_xawt/awt_Taskbar.o java.desktop/libawt_xawt/awt_UNIXToolkit.o java.desktop/libawt_xawt/awt_util.o java.desktop/libawt_xawt/fontpath.o java.desktop/libawt_xawt/gnome_interface.o java.desktop/libawt_xawt/gtk3_interface.o java.desktop/libawt_xawt/gtk_interface.o java.desktop/libawt_xawt/list.o java.desktop/libawt_xawt/multiVis.o java.desktop/libawt_xawt/rect.o java.desktop/libawt_xawt/screencast_pipewire.o java.desktop/libawt_xawt/screencast_portal.o java.desktop/libawt_xawt/sun_awt_X11_GtkFileDialogPeer.o java.desktop/libawt_xawt/swing_GTKEngine.o java.desktop/libawt_xawt/swing_GTKStyle.o java.desktop/libawt_xawt/systemScale.o ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2621688257 From psadhukhan at openjdk.org Wed Jan 29 14:39:56 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 29 Jan 2025 14:39:56 GMT Subject: Integrated: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale In-Reply-To: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> References: <33yxjfbFJDD0XeApLJ65oAJTafwLhedYw3E_wUsSOjs=.c27b5aa5-5d06-463a-877e-772f2779728f@github.com> Message-ID: On Wed, 22 Jan 2025 03:29:55 GMT, Prasanta Sadhukhan wrote: > JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below > > ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9) > > Native windows progressbar renders without leaving any gap as can be seen here > > ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca) > > so the padding is removed to render the progressbar similar to windows native and it is rendered properly > > ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb) This pull request has now been integrated. Changeset: 51cce6e6 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/51cce6e612e1e3b4647ad2c0c8bffc0f3adccb63 Stats: 116 lines in 2 files changed: 106 ins; 3 del; 7 mod 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale Reviewed-by: tr ------------- PR: https://git.openjdk.org/jdk/pull/23227 From aivanov at openjdk.org Wed Jan 29 15:40:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 15:40:48 GMT Subject: RFR: 8348648: Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit In-Reply-To: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> References: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> Message-ID: On Mon, 20 Jan 2025 13:07:19 GMT, Andrey Turbanov wrote: > Two `Hashtable`'s in `javax.swing.text.html.CSS.LengthUnit` class are modified only within `` block: > 1. lengthMapping > 2. w3cLengthMapping > > We can replace them with immutable maps to avoid Hashtable synchronization overhead. The client tests are green in CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23198#issuecomment-2621994714 From aivanov at openjdk.org Wed Jan 29 15:46:31 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 15:46:31 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay [v2] In-Reply-To: References: Message-ID: > Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay. > Use `Util.hitMnemonics` instead of custom code to handle macOS. > > I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Check for null before dispose() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23301/files - new: https://git.openjdk.org/jdk/pull/23301/files/c5c6b6a4..5969e82c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23301&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23301&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23301.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23301/head:pull/23301 PR: https://git.openjdk.org/jdk/pull/23301 From aivanov at openjdk.org Wed Jan 29 15:56:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 15:56:50 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v5] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 21:23:02 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by aivanov (Reviewer). test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 96: > 94: } > 95: > 96: static Rectangle waitAndGetOnScreenBoundsOnEDT(Component component) throws Exception { Suggestion: static Rectangle waitAndGetOnScreenBoundsOnEDT(Component component) throws InterruptedException, TimeoutException, ExecutionException { For consistency with `waitTillShown` which lists exceptions. ------------- PR Review: https://git.openjdk.org/jdk/pull/22729#pullrequestreview-2581484518 PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1934141378 From clanger at openjdk.org Wed Jan 29 16:36:58 2025 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 29 Jan 2025 16:36:58 GMT Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and ShapeSINextSpan in libawt java2d from ubsan checks In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 09:23:52 GMT, Matthias Baesken wrote: > In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) > jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows > > jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int' > #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683 > #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499 > #2 0x7efe9b8dee7b () > > java/awt/BasicStroke/DashStrokeTest.java shows > > src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int' > #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366 > #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75 > #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92 > #3 0x7fba12d07e7b () > > > There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings. LGTM now with the updated bug synopsis. But somebody from client-libs has to give their blessings as well. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23255#pullrequestreview-2581615307 From azvegint at openjdk.org Wed Jan 29 17:26:06 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 29 Jan 2025 17:26:06 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v6] In-Reply-To: References: Message-ID: > The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. > > The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. > > This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. > > The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22729/files - new: https://git.openjdk.org/jdk/pull/22729/files/368494e2..65c8a2b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22729&range=04-05 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22729/head:pull/22729 PR: https://git.openjdk.org/jdk/pull/22729 From azvegint at openjdk.org Wed Jan 29 17:26:06 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 29 Jan 2025 17:26:06 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v5] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 15:50:25 GMT, Alexey Ivanov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > test/jdk/javax/swing/JPopupMenu/NestedFocusablePopupTest.java line 96: > >> 94: } >> 95: >> 96: static Rectangle waitAndGetOnScreenBoundsOnEDT(Component component) throws Exception { > > Suggestion: > > static Rectangle waitAndGetOnScreenBoundsOnEDT(Component component) > throws InterruptedException, TimeoutException, ExecutionException { > > For consistency with `waitTillShown` which lists exceptions. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22729#discussion_r1934294922 From aivanov at openjdk.org Wed Jan 29 17:50:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 17:50:50 GMT Subject: RFR: 8342096: Popup menus that request focus are not shown on Linux with Wayland [v6] In-Reply-To: References: Message-ID: <5i946RNk-lTRvBzUJEC_SX8QCX_KZXNBhOq_rVWGuTw=.9e7a1ed8-ff04-4a1c-bb3f-923968cd517d@github.com> On Wed, 29 Jan 2025 17:26:06 GMT, Alexander Zvegintsev wrote: >> The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. >> >> The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. >> >> This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. >> >> The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22729#pullrequestreview-2581797940 From aivanov at openjdk.org Wed Jan 29 17:50:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 29 Jan 2025 17:50:53 GMT Subject: RFR: 8336382: Fixes error reporting in loading AWT and fonts [v10] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 11:39:10 GMT, Karm Michal Babacek wrote: >> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: >> >> Amended error message, doesn't clear exception > > RFR ping pls @mrserb @prrace @theRealAph :upside_down_face: @Karm I've updated the subject of the JBS issue; please update the PR subject. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2622434183 From azvegint at openjdk.org Wed Jan 29 17:48:51 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 29 Jan 2025 17:48:51 GMT Subject: RFR: 8342524: Use latch in AbstractButton/bug6298940.java instead of delay [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 15:46:31 GMT, Alexey Ivanov wrote: >> Use a `CountDownLatch` in `javax/swing/AbstractButton/bug6298940.java` instead of delay. >> Use `Util.hitMnemonics` instead of custom code to handle macOS. >> >> I ran the updated test a few times with `JTREG=REPEAT_COUNT=20`, the test always passed in the CI. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Check for null before dispose() Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23301#pullrequestreview-2581793437 From azvegint at openjdk.org Wed Jan 29 22:11:57 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 29 Jan 2025 22:11:57 GMT Subject: Integrated: 8342096: Popup menus that request focus are not shown on Linux with Wayland In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 04:16:06 GMT, Alexander Zvegintsev wrote: > The previous [JDK-8319103](https://bugs.openjdk.org/browse/JDK-8319103) fix was not complete. > > The case where a menu item with a focusable component was not a direct child of a window was missing(failing the `if (window == oppositeWindow.getParent() ) {` check), so the ungrab event was posted prematurely. > > This can be fixed by adding `waylandWindowFocusListener` to all submenus in hierarchy. > > The manual test updated to use this case, and also added an automated test that checks that it didn't close prematurely. This pull request has now been integrated. Changeset: d985b31c Author: Alexander Zvegintsev URL: https://git.openjdk.org/jdk/commit/d985b31cbb5646c526e1a68a7547f26f56d37607 Stats: 271 lines in 3 files changed: 249 ins; 6 del; 16 mod 8342096: Popup menus that request focus are not shown on Linux with Wayland Reviewed-by: aivanov, honkar ------------- PR: https://git.openjdk.org/jdk/pull/22729 From ihse at openjdk.org Wed Jan 29 23:28:49 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 29 Jan 2025 23:28:49 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. The problem with changing optimization levels is that folks are generally conservative and worried that things might break, that are hard to detect. I'm not convinced that the risk of changing optimization level is any larger than upgrading the compiler though, so maybe that is not a very good argument. As has been pointed out e.g. by Phil, not all libraries are performance critical. With that said, maybe such libraries should be optimized for size instead? (In many cases that also brings along a speed performance, even if it by no means guaranteed.) Changing optimization levels should not only be measured on the execution speed of the final product, but also on how much it affects the build time. If you feel up for it, I suggest that you go through all libraries you want to update, change the optimization levels to what you think is reasonable, measure any relevant performance benchmarks before and after, and also the the build time. (hint: Use e.g. `make java.desktop-libs-only JOBS=1 LOG=info` to get a build speed number that you can compare across compiler flag changes) Run all relevant tests that stress that native component. Then you can post a PR and suggest that we change the optimization level. I'm all in favor of this, I'm not just in favor of having to do all the work needed myself. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2623151495 From duke at openjdk.org Wed Jan 29 23:36:52 2025 From: duke at openjdk.org (Karm Michal Babacek) Date: Wed, 29 Jan 2025 23:36:52 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 23:23:44 GMT, Phil Race wrote: > So this is much better than what was there in the beginning. FindClass failing - for a key API class - is probably a fatal error one way or another. Although in all (?) other cases, we try to return to Java and let the VM throw a Java-level error. Note that OnLoad is not the only code path that calls AWTIsHeadless, and there will be Java code to return to in the other case. However I think that the OnLoad will always be reached first, so maybe it is OK to do the current fix. Either way, things aren't going to work. > > Generally the calls to check and clear exceptions when looking up code are there to keep 'tools' happy. If these classes aren't found something is badly wrong. meaning it should NEVER EVER happen. Failing to find java/lang/String for example hardly seems like something it is worth trying to recover from .. In your case it seems like it does some times happen for GraphicsEnvironment which still worries me. I don't want to make this fix a precedent for assuming that it is normal for classes to be missing. So consider it a truly exceptional case. Thank you for the review. This is indeed an awkward, yet real-world exceptional case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2623168541 From duke at openjdk.org Wed Jan 29 23:36:52 2025 From: duke at openjdk.org (Karm Michal Babacek) Date: Wed, 29 Jan 2025 23:36:52 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 23:33:18 GMT, Karm Michal Babacek wrote: >> So this is much better than what was there in the beginning. >> FindClass failing - for a key API class - is probably a fatal error one way or another. >> Although in all (?) other cases, we try to return to Java and let the VM throw a Java-level error. >> Note that OnLoad is not the only code path that calls AWTIsHeadless, and there will be >> Java code to return to in the other case. >> However I think that the OnLoad will always be reached first, so maybe it is OK to do the current fix. >> Either way, things aren't going to work. >> >> Generally the calls to check and clear exceptions when looking up code are there >> to keep 'tools' happy. If these classes aren't found something is badly wrong. >> meaning it should NEVER EVER happen. >> Failing to find java/lang/String for example hardly seems like something it is worth trying to recover from .. >> In your case it seems like it does some times happen for GraphicsEnvironment which still worries me. >> I don't want to make this fix a precedent for assuming that it is normal for classes to be missing. >> So consider it a truly exceptional case. > >> So this is much better than what was there in the beginning. FindClass failing - for a key API class - is probably a fatal error one way or another. Although in all (?) other cases, we try to return to Java and let the VM throw a Java-level error. Note that OnLoad is not the only code path that calls AWTIsHeadless, and there will be Java code to return to in the other case. However I think that the OnLoad will always be reached first, so maybe it is OK to do the current fix. Either way, things aren't going to work. >> >> Generally the calls to check and clear exceptions when looking up code are there to keep 'tools' happy. If these classes aren't found something is badly wrong. meaning it should NEVER EVER happen. Failing to find java/lang/String for example hardly seems like something it is worth trying to recover from .. In your case it seems like it does some times happen for GraphicsEnvironment which still worries me. I don't want to make this fix a precedent for assuming that it is normal for classes to be missing. So consider it a truly exceptional case. > > Thank you for the review. This is indeed an awkward, yet real-world exceptional case. > @Karm I've updated the subject of the JBS issue; please update the PR subject. Thank you @aivanov-jdk . Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2623169473 From abhiscxk at openjdk.org Thu Jan 30 07:22:46 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 07:22:46 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 14:51:57 GMT, Alexey Ivanov wrote: > The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. > > Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. > > I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. > > The updated test passes in the CI. test/jdk/javax/swing/JButton/4796987/bug4796987.java line 29: > 27: * @key headful > 28: * @requires (os.family == "windows") > 29: * @summary XP Only: JButton.setBorderPainted() does not work with XP L&F Summary should be rephrased. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1935105461 From abhiscxk at openjdk.org Thu Jan 30 07:38:45 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 07:38:45 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 14:51:57 GMT, Alexey Ivanov wrote: > The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. > > Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. > > I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. > > The updated test passes in the CI. test/jdk/javax/swing/JButton/4796987/bug4796987.java line 126: > 124: > 125: JButton button = new JButton(); > 126: button.setBorder(null); What's the use of this `button` instance ? Looks unused instance to me and can be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23336#discussion_r1935140022 From serb at openjdk.org Thu Jan 30 08:17:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 30 Jan 2025 08:17:52 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20169#pullrequestreview-2583196126 From abhiscxk at openjdk.org Thu Jan 30 08:23:47 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 08:23:47 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> Message-ID: On Wed, 29 Jan 2025 02:59:03 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: > > formatting @prsadhuk Unable to see the duke image along with RadioButtonMenuItem. Is it correct behaviour? ![RadioButtonMenuItem](https://github.com/user-attachments/assets/fa373784-047f-4af0-bfed-063bc34530b3) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2623820382 From psadhukhan at openjdk.org Thu Jan 30 08:29:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 08:29:47 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> Message-ID: On Wed, 29 Jan 2025 02:59:03 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: > > formatting > @prsadhuk Unable to see the duke image along with RadioButtonMenuItem. Is it correct behaviour? > > ![RadioButtonMenuItem](https://private-user-images.githubusercontent.com/107542245/408042548-fa373784-047f-4af0-bfed-063bc34530b3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzgyMjU1NzcsIm5iZiI6MTczODIyNTI3NywicGF0aCI6Ii8xMDc1NDIyNDUvNDA4MDQyNTQ4LWZhMzczNzg0LTA0N2YtNGFmMC1iZmVkLTA2M2JjMzQ1MzBiMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMTMwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDEzMFQwODIxMTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xMDJkMjMyODgwZTY5OGIyYjUxZTU3MDEzMjM2MTY1ZGRjZjk1Yzk2MTIyODIxM2MyYTZhMDg5MGE2ZGRhODc3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.AFbwA8UKoad5R1E58syN-Ap5K6B3Kd920spOiU3Yzww) did you download the duke file from the PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2623831937 From abhiscxk at openjdk.org Thu Jan 30 08:34:45 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 08:34:45 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> Message-ID: On Thu, 30 Jan 2025 08:27:02 GMT, Prasanta Sadhukhan wrote: > > @prsadhuk Unable to see the duke image along with RadioButtonMenuItem. Is it correct behaviour? > > ![RadioButtonMenuItem](https://private-user-images.githubusercontent.com/107542245/408042548-fa373784-047f-4af0-bfed-063bc34530b3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzgyMjU1NzcsIm5iZiI6MTczODIyNTI3NywicGF0aCI6Ii8xMDc1NDIyNDUvNDA4MDQyNTQ4LWZhMzczNzg0LTA0N2YtNGFmMC1iZmVkLTA2M2JjMzQ1MzBiMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMTMwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDEzMFQwODIxMTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xMDJkMjMyODgwZTY5OGIyYjUxZTU3MDEzMjM2MTY1ZGRjZjk1Yzk2MTIyODIxM2MyYTZhMDg5MGE2ZGRhODc3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.AFbwA8UKoad5R1E58syN-Ap5K6B3Kd920spOiU3Yzww) > > did you download the duke file from the PR? Yeah, it's inside "javax\swing\JMenuItem" folder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2623841061 From abhiscxk at openjdk.org Thu Jan 30 08:38:51 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 08:38:51 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> Message-ID: On Wed, 29 Jan 2025 02:59:03 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: > > formatting src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 888: > 886: } > 887: if (icon != null) { > 888: if (!((AbstractButton)c).isSelected()) { Suggestion: if (!((AbstractButton) c).isSelected()) { test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java line 45: > 43: public class TestImageIconWithJRadioButtonMenuItem { > 44: > 45: private static final String instructionsText = """ Suggestion: private static final String INSTRUCTIONSTEXT = """ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935142368 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935144748 From psadhukhan at openjdk.org Thu Jan 30 08:51:05 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 08:51:05 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v3] 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: image path correction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/befbdf55..2bb08692 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=01-02 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 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 abhiscxk at openjdk.org Thu Jan 30 08:54:49 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 08:54:49 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v2] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0aqXQmSwxgddIpz4BzAw0Z-HO8nnFMgJztZd6keucsM=.592841b3-ce66-40f6-ac9f-e07a263e578e@github.com> Message-ID: On Thu, 30 Jan 2025 08:27:02 GMT, Prasanta Sadhukhan wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting > >> @prsadhuk Unable to see the duke image along with RadioButtonMenuItem. Is it correct behaviour? >> >> ![RadioButtonMenuItem](https://private-user-images.githubusercontent.com/107542245/408042548-fa373784-047f-4af0-bfed-063bc34530b3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzgyMjU1NzcsIm5iZiI6MTczODIyNTI3NywicGF0aCI6Ii8xMDc1NDIyNDUvNDA4MDQyNTQ4LWZhMzczNzg0LTA0N2YtNGFmMC1iZmVkLTA2M2JjMzQ1MzBiMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMTMwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDEzMFQwODIxMTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xMDJkMjMyODgwZTY5OGIyYjUxZTU3MDEzMjM2MTY1ZGRjZjk1Yzk2MTIyODIxM2MyYTZhMDg5MGE2ZGRhODc3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.AFbwA8UKoad5R1E58syN-Ap5K6B3Kd920spOiU3Yzww) > > did you download the duke file from the PR? @prsadhuk After image path correction, duke image icon is visible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2623878435 From abhiscxk at openjdk.org Thu Jan 30 09:43:47 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 09:43:47 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v3] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <87_ME70-0giTme4wXtz228Ze3jlHO5GKoLhu8Xt50U4=.9e41a8ca-e390-4540-ac38-187d1b459897@github.com> On Thu, 30 Jan 2025 08:51:05 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: > > image path correction src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 881: > 879: skin.paintSkin(g, x + OFFSET, y + OFFSET, state); > 880: } else { > 881: skin = xp.getSkin(c, part); `skin = xp.getSkin(c, part);` can be taken out of if-else block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935299374 From psadhukhan at openjdk.org Thu Jan 30 09:59:33 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 09:59:33 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v4] 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: optimise ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/2bb08692..9aeda887 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 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 Jan 30 09:59:33 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 09:59:33 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v3] In-Reply-To: <87_ME70-0giTme4wXtz228Ze3jlHO5GKoLhu8Xt50U4=.9e41a8ca-e390-4540-ac38-187d1b459897@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <87_ME70-0giTme4wXtz228Ze3jlHO5GKoLhu8Xt50U4=.9e41a8ca-e390-4540-ac38-187d1b459897@github.com> Message-ID: On Thu, 30 Jan 2025 09:40:15 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> image path correction > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 881: > >> 879: skin.paintSkin(g, x + OFFSET, y + OFFSET, state); >> 880: } else { >> 881: skin = xp.getSkin(c, part); > > `skin = xp.getSkin(c, part);` can be taken out of if-else block. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935323239 From abhiscxk at openjdk.org Thu Jan 30 10:19:52 2025 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 30 Jan 2025 10:19:52 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v4] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 30 Jan 2025 09:59:33 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: > > optimise Looks good to me. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2583479974 From aivanov at openjdk.org Thu Jan 30 10:42:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 10:42:48 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 12:25:29 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Add debug output The updated test passes for me on Windows. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23183#pullrequestreview-2583532480 From duke at openjdk.org Thu Jan 30 10:53:55 2025 From: duke at openjdk.org (duke) Date: Thu, 30 Jan 2025 10:53:55 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception @Karm Your change (at version 91d554f4919a9923a304ec1d3b23b96cb5cf144a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2624149712 From duke at openjdk.org Thu Jan 30 11:15:59 2025 From: duke at openjdk.org (Karm Michal Babacek) Date: Thu, 30 Jan 2025 11:15:59 GMT Subject: Integrated: 8336382: Fix error reporting in loading AWT In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 00:18:43 GMT, Karm Michal Babacek wrote: > If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: > > Fatal error reported via JNI: Could not allocate library name > > Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. > > Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. > > * https://github.com/oracle/graal/issues/9138 > * https://github.com/oracle/graal/issues/8475 > * https://github.com/oracle/graal/issues/9300 > * https://github.com/quarkusio/quarkus/issues/31596 > * https://github.com/graalvm/mandrel/issues/292 > * https://github.com/Karm/mandrel-integration-tests/issues/262 > > This commit fixes the error reporting in the AWTIsHeadless. > > Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. > > /tmp/JAVA_HOME/ > /tmp/JAVA_HOME/conf > /tmp/JAVA_HOME/conf/fonts > /tmp/JAVA_HOME/lib > > The exception is somewhat cryptic for users again, merely stating: > > Exception in thread "main" java.io.IOException: Problem reading font data. > at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) > at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) > at imageio.Main.loadFonts(Main.java:139 > > Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: > > Exception in thread "main" java.io.IOException: Problem reading font data. > at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) > at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) > at imageio.Main.loadFonts(Main.java:139) > at imageio.Main.paintRectangles(Main.java:97) > at imageio.Main.main(Main.java:195) > at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) > Caused by: java.lang.Error: java.home property not set > at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigFile(FontConfiguration.java:180) > at java.desktop at 23-internal/sun.awt.FontConf... This pull request has now been integrated. Changeset: 1858dc14 Author: Michal Karm Babacek Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/1858dc141041dbea7167007b17d03fe41378c0be Stats: 166 lines in 3 files changed: 154 ins; 10 del; 2 mod 8336382: Fix error reporting in loading AWT Reviewed-by: prr, aivanov, serb ------------- PR: https://git.openjdk.org/jdk/pull/20169 From aivanov at openjdk.org Thu Jan 30 11:50:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 11:50:48 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v4] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 30 Jan 2025 09:59:33 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: > > optimise I am also for generating an `ImageIcon` on the fly _to avoid adding a binary file_. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 887: > 885: } > 886: if (icon != null) { > 887: if (!((AbstractButton) c).isSelected()) { This new block of code 887?918 copies that from above 855?884. You should create a helper method instead copying the same code in the two branches of code, or the code should be re-arranged somehow. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 891: > 889: Part part; > 890: if (type == JRadioButtonMenuItem.class) { > 891: part = Part.BP_RADIOBUTTON; The part `Part.BP_RADIOBUTTON` doesn't look right to me. The selected case above always uses the part `Part.MP_POPUPCHECK` ? and it looks correct because this code paints a menu item (and radio or check menu items are usually in popup menus rather than on the menu bar). src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 894: > 892: } else { > 893: part = Part.MP_POPUPCHECK; > 894: } Suggestion: Part part = (type == JRadioButtonMenuItem.class) ? Part.BP_RADIOBUTTON : Part.MP_POPUPCHECK; Moreover, you use this syntax below. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 907: > 905: (type == JRadioButtonMenuItem.class) > 906: ? State.BULLETDISABLED > 907: : State.CHECKMARKDISABLED; Suggestion: state = (type == JRadioButtonMenuItem.class) ? State.BULLETDISABLED : State.CHECKMARKDISABLED; For consistency with the code in the block above `else`. ------------- Changes requested by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23324#pullrequestreview-2583633590 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935463611 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935467489 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935452320 PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935454098 From aivanov at openjdk.org Thu Jan 30 11:50:50 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 11:50:50 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v4] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Wed, 29 Jan 2025 02:53:29 GMT, Prasanta Sadhukhan wrote: >> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 860: >> >>> 858: State state; >>> 859: if (isEnabled(c, null)) { >>> 860: backgroundState = State.NORMAL; >> >> Do you happen to know why `State.BITMAP` was originally here? I tried locating where it originated from, but can't pinpoint exactly why it's either `State.BITMAP` or `State.NORMAL` based on the icon being `null`. Curious only because we're completely eliminating it here and there might be a dependency. However, I haven't encountered any issues when testing yet. > > I guess if we can use normal resolution image, then its best to use it than bitmap image which can be flaky..Probably, in earlier days, image icons used to come in bitmap format.. > Do you happen to know why State.BITMAP was originally here? Perhaps, because of default Windows behaviour: a bitmap menu item fully replaces the menu item text. Yet I can't be sure? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935448700 From aivanov at openjdk.org Thu Jan 30 11:50:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 11:50:51 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v4] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <4gUF0U5hrzDoPxm8Fsh5FXSagqzP0884hdG5ZOP2pYg=.aea09fdc-6839-49b2-b8e4-d7f0af224bc1@github.com> Message-ID: On Wed, 29 Jan 2025 02:52:16 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JMenuItem/duke.gif line 1: >> >>> 1: GIF89ap!???:,???3f?????????++3+f+???+???+???UU3UfU???U???U?????????3???f????????????????????????3???f????????????????????????3???f????????????????????3???f??????????????????3333f3???3???3???3+3+33+f3+???3+???3+???3U3U33Uf3U???3U???3U???3???3???33???f3??????3??????3??????3???3???33???f3??????3??????3??????3???3???33???f3??3??????3??????3???3???33???f3??????3??????3??????ff3fff???f???f???f+f+3f+ff+???f+???f+???fUfU3fUffU???fU???fU???f???f???3f???ff??????f??????f??????f???f???3f???ff??????f??????f??????f???f???3f???ff??f??????f??????f???f???3f???ff??????f??????f????????????3???f?????????????????+???+3???+f???+??????+??+??????U???U3???Uf???U??????U??U???????????????3??????f???????????????????????????????????3??????f???????????????????????????????????3??????f???????????????????????????????3??????f?????????????????????????????3???f?????????????????????+???+3???+f? ??+??????+??????+??????U???U3???Uf???U??????U??????U???????3??f???????????????????3??f???????????????????????????3??????f???????????????????????????????????3??????f?????????????????????????????????3???f?????????????????????+???+3???+f???+??????+??????+??????U???U3???Uf???U??????U??????U???????????????3??????f???????????????????????????????????????3??????f???????????????????????????????????????3??????f???????????????????????????????????3??????f????????????????????????????????? Hp1e >> ???f???B????????#F?????????&??M??????bb`???@b %???OL???052??????, >> J??????z????????????F??????l?????????L???C??????1R???o??????}??? T?????? ????????????R}??? ?????U f??????L+??72?????????F??????O???2???T1???}????????; >> >> Can't you generate an image on the fly? It doesn't have to be Duke, any image like a red square or rectangle will do. > > I chose not to as firstly, for the test to be same as actual usecase where proper gif image is used so as to trace the same image decoding codepath (instead of using a BufferedImage) and secondly, since it is about image icon, it will be easier for tester to discern if there is actual image rather than a red sqaure/rectangle which tester can think of primitives > and finally, there will not be a licensing issue for duke so I guess this is ok for this test. Once the image is in `ImageIcon`, it doesn't matter where it came from: generated, loaded from disk. If red square could be confused, you can use a red circle, you can add an ???i??? into the icon, there are quite a few options which could still make it clear the menu item contains _an image_??? like a circle in a square. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935476640 From aivanov at openjdk.org Thu Jan 30 11:59:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 11:59:47 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v3] In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Tue, 28 Jan 2025 10:40:40 GMT, Naveen Narayanan wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Looks good to me. There's a minor nit: a missing space after the comma in `mouseMove`. test/jdk/java/awt/Robot/ScreenCaptureRobotTest.java line 110: > 108: private static void doTest() throws Exception { > 109: Robot robot = new Robot(); > 110: robot.mouseMove(0,0); Suggestion: robot.mouseMove(0, 0); ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23264#pullrequestreview-2583688144 PR Review Comment: https://git.openjdk.org/jdk/pull/23264#discussion_r1935482257 From psadhukhan at openjdk.org Thu Jan 30 12:49:14 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 12:49:14 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] 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 two additional commits since the last revision: - Remove duke - RadioButton not drawn. ImageIcon on the fly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/9aeda887..6a8faec5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=03-04 Stats: 43 lines in 3 files changed: 6 ins; 32 del; 5 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 Jan 30 12:49:14 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 12:49:14 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v4] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 30 Jan 2025 11:40:30 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> optimise > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 891: > >> 889: Part part; >> 890: if (type == JRadioButtonMenuItem.class) { >> 891: part = Part.BP_RADIOBUTTON; > > The part `Part.BP_RADIOBUTTON` doesn't look right to me. > > The selected case above always uses the part `Part.MP_POPUPCHECK` ? and it looks correct because this code paints a menu item (and radio or check menu items are usually in popup menus rather than on the menu bar). You are right..It is not needed..I have removed.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935552863 From aivanov at openjdk.org Thu Jan 30 12:58:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 12:58:48 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 30 Jan 2025 12:49:14 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 two additional commits since the last revision: > > - Remove duke > - RadioButton not drawn. ImageIcon on the fly This does not look right at all: ![The screenshot of the newly added test case `TestImageIconWithJRadioButtonMenuItem.java` on Windows 10: it renders an unselected radio button control to the left of menu item which has an icon in addition to text](https://github.com/user-attachments/assets/2d5d47cb-7de5-41e0-9b14-e7994d4a9991) You shouldn't render an unselected radio button in menu. (Yes, I modified your test case to display the menu items in a popup menu as they're supposed to be.) The position of the image also seems off. On Windows 10, the selected state has a background which you can see on the screenshot. Without the fix, the duke is centered in this selected background; but with the fix, it's off. If we add support for painting both an `ImageIcon` and the bullet / check-mark, the layout of the menu item has to change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2624442850 From aivanov at openjdk.org Thu Jan 30 13:14:47 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 13:14:47 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 30 Jan 2025 11:25:20 GMT, Alexey Ivanov wrote: >> I guess if we can use normal resolution image, then its best to use it than bitmap image which can be flaky..Probably, in earlier days, image icons used to come in bitmap format.. > >> Do you happen to know why State.BITMAP was originally here? > > Perhaps, because of default Windows behaviour: a bitmap menu item fully replaces the menu item text. Yet I can't be sure? This state was added by [JDK-6432667](https://bugs.openjdk.org/browse/JDK-6432667): _Vista: Menu dropdown differs while compare with native in vista laf_. No more background is available? It may be due to how Windows renders icons in menus: if a menu item has an icon, it's rendered at the location where bullets / check-marks are rendered; if you need to display selected / unselected state of such a menu item, you have to use different icons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935589364 From psadhukhan at openjdk.org Thu Jan 30 13:20:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 13:20:47 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 30 Jan 2025 12:55:45 GMT, Alexey Ivanov wrote: > You shouldn't render an unselected radio button in menu. Please check updated PR and share your testcase ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2624495918 From duke at openjdk.org Thu Jan 30 13:26:08 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Thu, 30 Jan 2025 13:26:08 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v4] In-Reply-To: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: <83289AzwVKmckmio1pF_GHyh5WnBgp99E02OJaT5Ab4=.5b02e161-0509-4418-8f44-24aec541cd20@github.com> > This contains test fixes for the following issue in ScreenCaptureRobotTest.java > > ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. > > Testing: > Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23264/files - new: https://git.openjdk.org/jdk/pull/23264/files/b49045c3..df19c55f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23264&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23264&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23264/head:pull/23264 PR: https://git.openjdk.org/jdk/pull/23264 From duke at openjdk.org Thu Jan 30 13:26:09 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Thu, 30 Jan 2025 13:26:09 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v3] In-Reply-To: References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Thu, 30 Jan 2025 11:52:09 GMT, Alexey Ivanov wrote: >> Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: >> >> 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS > > test/jdk/java/awt/Robot/ScreenCaptureRobotTest.java line 110: > >> 108: private static void doTest() throws Exception { >> 109: Robot robot = new Robot(); >> 110: robot.mouseMove(0,0); > > Suggestion: > > robot.mouseMove(0, 0); done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23264#discussion_r1935604339 From psadhukhan at openjdk.org Thu Jan 30 13:30:46 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 13:30:46 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <0GbRMNtzd56p_9XXGb8glFy-LvzRVOkcl__h18x8_2g=.8212eb22-c5f1-4f21-8d64-a9ecba9c5ee7@github.com> On Thu, 30 Jan 2025 13:11:50 GMT, Alexey Ivanov wrote: >>> Do you happen to know why State.BITMAP was originally here? >> >> Perhaps, because of default Windows behaviour: a bitmap menu item fully replaces the menu item text. Yet I can't be sure? > > This state was added by [JDK-6432667](https://bugs.openjdk.org/browse/JDK-6432667): _Vista: Menu dropdown differs while compare with native in vista laf_. > > No more background is available? It may be due to how Windows renders icons in menus: if a menu item has an icon, it's rendered at the location where bullets / check-marks are rendered; if you need to display selected / unselected state of such a menu item, you have to use different icons. The bug says > in case icon is defined for JCheckBoxMenuItem or > JRadioButtonMenuItem this icon is used as a check/radio mark. themed > background is used to show the selection. so I guess it was done intentionally to not draw checkmark if icon is there, but I am not getting any menuitem with icon and radiobutton selection natively in windows11 to compare..anything in windows10? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935612704 From aivanov at openjdk.org Thu Jan 30 13:42:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 13:42:51 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: On Thu, 30 Jan 2025 13:18:25 GMT, Prasanta Sadhukhan wrote: > > You shouldn't render an unselected radio button in menu. > > Please check updated PR? I saw your update. I wrote this comment before you removed rendering the unselected radio button. > ?share your testcase Here's the latest version of [modified `TestImageIconWithJRadioButtonMenuItem.java`](https://github.com/openjdk/jdk/blob/de48cbdf37fd812d652f6dc7113e700b0d26f99d/test/jdk/javax/swing/JMenuItem/TestImageIconWithJRadioButtonMenuItem.java). The diff [between yours and mine](https://github.com/openjdk/jdk/compare/4a5a7790e00650cbdd87d533429e3b47a537c3e8..de48cbdf37fd812d652f6dc7113e700b0d26f99d). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2624548270 From aivanov at openjdk.org Thu Jan 30 14:44:48 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 14:44:48 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: <0GbRMNtzd56p_9XXGb8glFy-LvzRVOkcl__h18x8_2g=.8212eb22-c5f1-4f21-8d64-a9ecba9c5ee7@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0GbRMNtzd56p_9XXGb8glFy-LvzRVOkcl__h18x8_2g=.8212eb22-c5f1-4f21-8d64-a9ecba9c5ee7@github.com> Message-ID: On Thu, 30 Jan 2025 13:28:00 GMT, Prasanta Sadhukhan wrote: > The bug says > > > in case icon is defined for JCheckBoxMenuItem or > > JRadioButtonMenuItem this icon is used as a check/radio mark. themed > > background is used to show the selection. > > so I guess it was done intentionally to not draw checkmark if icon is there, but I am not getting any menuitem with icon and radiobutton selection natively in windows11 to compare..anything in windows10? I think so. Vista and Windows 7 had a kind of separator in the menu between text and icons. ![Notepad - selected Word wrap in Windows 7](https://github.com/user-attachments/assets/81315ca3-5567-4cdf-8a2a-3bffd413b2b8) This screenshot shows how menu looked like in Windows 7, the *Word Wrap* item is selected. I don't think Windows has ever supported both icons and bullets / check marks? unless you drew menu items yourself. The icons in menus were always displayed in that area. The right-click menu on the desktop in Windows 10 is a good example; Windows 11 uses a completely different style of menus on the desktop and in Explorer. I can't find any native Windows app which displayed both states. The closest I found are Paint.NET and VirtualBox. Paint.NET ![Paint NET - selected menu item](https://github.com/user-attachments/assets/1545d3a7-4354-4aac-90c9-92da0c98a713) Here *Pixel Grid* is selected. It uses a selected background and a highlight square around the icon. The *Pixels* item is also selected, but it has no icon, it displays a check-mark (even though it should've been a bullet: only one of _Pixels_, _Inches_, _Centimeters_ can be selected). VirtualBox ![VirtualBox - selected Pause](https://github.com/user-attachments/assets/777f45d8-5ac0-4bc6-ae88-77f43c063704) In this case, the *Pause* item is selected. VirtualBox adds both a selected background as well as a check-mark overlay to indicate the item is currently selected. Neither Paint.NET nor VirtualBox fully rely on Windows to render their menus, either app uses owner-drawn menus or its own controls. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935724542 From aivanov at openjdk.org Thu Jan 30 14:59:51 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 14:59:51 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> Message-ID: <2RDxMPXslHw36StQ73tdMpjDNylkbmp4zqOvYFACXS8=.83c7de53-d0a2-4cc5-931e-aa44e4e63855@github.com> On Thu, 30 Jan 2025 12:49:14 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 two additional commits since the last revision: > > - Remove duke > - RadioButton not drawn. ImageIcon on the fly Based on [the discussion above](https://github.com/openjdk/jdk/pull/23324#discussion_r1935589364) in relation to [JDK-6432667](https://bugs.openjdk.org/browse/JDK-6432667) where the current behaviour/rendering was implemented, this quirk may be *a feature* of Windows L&F rather than a bug. ![Windows 10 - red square item selected](https://github.com/user-attachments/assets/343adf20-b3ca-4c06-af93-e63736bce123) Windows 10 has a highlight around the selected icon. Yet there's no such highlight in Windows 11, therefore it's hard to distinguish whether a menu item has a selected state of not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-2624726843 From psadhukhan at openjdk.org Thu Jan 30 14:59:52 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 14:59:52 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0GbRMNtzd56p_9XXGb8glFy-LvzRVOkcl__h18x8_2g=.8212eb22-c5f1-4f21-8d64-a9ecba9c5ee7@github.com> Message-ID: On Thu, 30 Jan 2025 14:42:33 GMT, Alexey Ivanov wrote: >> The bug says >> >>> in case icon is defined for JCheckBoxMenuItem or >>> JRadioButtonMenuItem this icon is used as a check/radio mark. themed >>> background is used to show the selection. >> >> so I guess it was done intentionally to not draw checkmark if icon is there, but I am not getting any menuitem with icon and radiobutton selection natively in windows11 to compare..anything in windows10? > >> The bug says >> >> > in case icon is defined for JCheckBoxMenuItem or >> > JRadioButtonMenuItem this icon is used as a check/radio mark. themed >> > background is used to show the selection. >> >> so I guess it was done intentionally to not draw checkmark if icon is there, but I am not getting any menuitem with icon and radiobutton selection natively in windows11 to compare..anything in windows10? > > I think so. Vista and Windows 7 had a kind of separator in the menu between text and icons. > > ![Notepad - selected Word wrap in Windows 7](https://github.com/user-attachments/assets/81315ca3-5567-4cdf-8a2a-3bffd413b2b8) > This screenshot shows how menu looked like in Windows 7, the *Word Wrap* item is selected. > > I don't think Windows has ever supported both icons and bullets / check marks? unless you drew menu items yourself. > > The icons in menus were always displayed in that area. The right-click menu on the desktop in Windows 10 is a good example; Windows 11 uses a completely different style of menus on the desktop and in Explorer. > > > I can't find any native Windows app which displayed both states. The closest I found are Paint.NET and VirtualBox. > > Paint.NET > ![Paint NET - selected menu item](https://github.com/user-attachments/assets/1545d3a7-4354-4aac-90c9-92da0c98a713) > > Here *Pixel Grid* is selected. It uses a selected background and a highlight square around the icon. The *Pixels* item is also selected, but it has no icon, it displays a check-mark (even though it should've been a bullet: only one of _Pixels_, _Inches_, _Centimeters_ can be selected). > > VirtualBox > ![VirtualBox - selected Pause](https://github.com/user-attachments/assets/777f45d8-5ac0-4bc6-ae88-77f43c063704) > > In this case, the *Pause* item is selected. VirtualBox adds both a selected background as well as a check-mark overlay to indicate the item is currently selected. > > Neither Paint.NET nor VirtualBox fully rely on Windows to render their menus, either app uses owner-drawn menus or its own controls. I found one in windows11 in Explorer which seems to use both icon and bullet checkmark and the present PR do the same ![image](https://github.com/user-attachments/assets/910a5b48-98f5-4ddb-8761-fe2205970774) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935744523 From aivanov at openjdk.org Thu Jan 30 15:15:07 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 15:15:07 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v5] In-Reply-To: References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0GbRMNtzd56p_9XXGb8glFy-LvzRVOkcl__h18x8_2g=.8212eb22-c5f1-4f21-8d64-a9ecba9c5ee7@github.com> Message-ID: <7nuocJJ76-uMik3qqduJSDf2WOCLCMN-as9Y0sfPJqw=.0997ce6b-aac3-4879-a39d-68c7d808cba8@github.com> On Thu, 30 Jan 2025 14:55:59 GMT, Prasanta Sadhukhan wrote: > I found one in windows11 in Explorer which seems to use both icon and bullet checkmark and the present PR do the same Yeah, you're right, it looks similar. Yet the currently proposed fix in this PR is still off. The bullet or check-mark should be displayed where it is now. What I mean by this is that this `if` statement needs to be removed: https://github.com/openjdk/jdk/blob/fac63d4383c931ea515dcdf7a89e4285f753f41b/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L878-L881 If you remove it, then the bullet or check-mark will be rendered at its own place. Yet if there's an icon associated with a menu item, all the text in other menus should shift to make room for the added icon. (Note that this menu in File Explorer in Windows 11 has icons on each and every menu item.) ![Proposed layout for icons and bullets](https://github.com/user-attachments/assets/c3809aaa-3219-4b9a-b86e-7850a747f652) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1935784688 From aivanov at openjdk.org Thu Jan 30 15:37:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 30 Jan 2025 15:37:55 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v4] In-Reply-To: <83289AzwVKmckmio1pF_GHyh5WnBgp99E02OJaT5Ab4=.5b02e161-0509-4418-8f44-24aec541cd20@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> <83289AzwVKmckmio1pF_GHyh5WnBgp99E02OJaT5Ab4=.5b02e161-0509-4418-8f44-24aec541cd20@github.com> Message-ID: On Thu, 30 Jan 2025 13:26:08 GMT, Naveen Narayanan wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23264#pullrequestreview-2584260664 From psadhukhan at openjdk.org Thu Jan 30 15:47:26 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 30 Jan 2025 15:47:26 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v6] 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: Draw checkmark skin at same location with/without icon ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23324/files - new: https://git.openjdk.org/jdk/pull/23324/files/6a8faec5..9482b261 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=04-05 Stats: 7 lines in 1 file changed: 1 ins; 4 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 mbaesken at openjdk.org Thu Jan 30 16:23:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 30 Jan 2025 16:23:56 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 23:25:51 GMT, Magnus Ihse Bursie wrote: >As has been pointed out e.g. by Phil, not all libraries are performance critical. With that said, maybe such libraries should be > optimized for size instead? (In many cases that also brings along a speed performance, even if it by no means guaranteed.) Hi Magnus, that sounds like a good idea, especially for libraries that are a bit larger (if they are below 100K it does probably not make a big difference). Some candidates that have optimization LOW **and** are larger than 200K linuxx86_64 macosaarch64 windows-x86_64 BUILD_LIBAWT_XAWT 540K BUILD_LIBAWT_LWAWT 1.2M BUILD_LIBZIP 164K BUILD_LIBSPLASHSCREEN 364K 468K 204K BUILD_LIBJDWP 330K 312K 228K BUILD_LIBJAVAACCESSBRIDGE 280K BUILD_LIBJSVML is also rather large (~ 850K) but has no opt-level set for the lib make rule; not sure what that means, almost all other libs set a specific optimization level . ( Besides changing a couple of default opt-levels for some libs, I also would like to have better configure functionality to set it myself like we have for libjvm with the 'jvm-features' . ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2624952613 From duke at openjdk.org Thu Jan 30 17:15:51 2025 From: duke at openjdk.org (duke) Date: Thu, 30 Jan 2025 17:15:51 GMT Subject: RFR: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS [v4] In-Reply-To: <83289AzwVKmckmio1pF_GHyh5WnBgp99E02OJaT5Ab4=.5b02e161-0509-4418-8f44-24aec541cd20@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> <83289AzwVKmckmio1pF_GHyh5WnBgp99E02OJaT5Ab4=.5b02e161-0509-4418-8f44-24aec541cd20@github.com> Message-ID: On Thu, 30 Jan 2025 13:26:08 GMT, Naveen Narayanan wrote: >> This contains test fixes for the following issue in ScreenCaptureRobotTest.java >> >> ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. >> >> Testing: >> Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. > > Naveen Narayanan has updated the pull request incrementally with one additional commit since the last revision: > > 8344581: java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS @Naveenam-Oracle Your change (at version df19c55f250044648c07e7a8f5340d93a3046d66) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23264#issuecomment-2625091733 From aturbanov at openjdk.org Thu Jan 30 17:50:51 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 30 Jan 2025 17:50:51 GMT Subject: Integrated: 8348648: Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit In-Reply-To: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> References: <1cgMNRtZGEZzEgOPt2ZacwCvxq2Rd8P7e6HSK3rqeto=.30894b87-571d-47aa-80f8-1248ce9cdd7a@github.com> Message-ID: On Mon, 20 Jan 2025 13:07:19 GMT, Andrey Turbanov wrote: > Two `Hashtable`'s in `javax.swing.text.html.CSS.LengthUnit` class are modified only within `` block: > 1. lengthMapping > 2. w3cLengthMapping > > We can replace them with immutable maps to avoid Hashtable synchronization overhead. This pull request has now been integrated. Changeset: cc775b16 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/cc775b16208bba4df98485de0970513baa0495a7 Stats: 20 lines in 1 file changed: 0 ins; 2 del; 18 mod 8348648: Unnecessary Hashtable usage in javax.swing.text.html.CSS.LengthUnit Reviewed-by: aivanov, azvegint, serb ------------- PR: https://git.openjdk.org/jdk/pull/23198 From ihse at openjdk.org Thu Jan 30 20:06:35 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 30 Jan 2025 20:06:35 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 13:32:56 GMT, Matthias Baesken wrote: > In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting. I don't think there is much point in being able to vary the opt level; it is more about spending the time to find the most appropriate opt level, and once you've done that, you can update the makefile directly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2625428785 From achung at openjdk.org Thu Jan 30 20:23:50 2025 From: achung at openjdk.org (Alisen Chung) Date: Thu, 30 Jan 2025 20:23:50 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:12:30 GMT, Alexey Ivanov wrote: > I would like to clarify one point: if the robot moves the mouse off the screen while the actual mouse pointer is on the screen and immediately presses the mouse button, where will the click occur? on or off the screen? In macOS code there is similar method that checks for mouse offscreen locations called checkMousePos() which updates and clamps the mousePosition stored in CRobot and is called after mousePress and mouseRelease, but I think it makes more sense to do the clamping during the mouseMove instead of having the mouse move to nonexistent coordinates then performing operations on a clamped location based on those nonexistent coordinates. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2625496940 From dholmes at openjdk.org Thu Jan 30 20:44:00 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Jan 2025 20:44:00 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception The new test will not compile. The ASM library has been removed from OpenJDK, except for use by some hotspot tests. Everything else should be converted to use the Classfile API. See [JDK-8349099](https://bugs.openjdk.org/browse/JDK-8349099). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2625533806 From honkar at openjdk.org Thu Jan 30 21:15:26 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 30 Jan 2025 21:15:26 GMT Subject: Integrated: JDK-8349101 : Problemlist HeadlessMalfunctionTest.java Message-ID: java/awt/Headless/HeadlessMalfunctionTest.java problemlisted as it fails after [JDK-8336382](https://bugs.openjdk.org/browse/JDK-8336382) fix. ------------- Commit messages: - PL HeadlessMalfunctionTest.java Changes: https://git.openjdk.org/jdk/pull/23375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23375&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349101 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23375/head:pull/23375 PR: https://git.openjdk.org/jdk/pull/23375 From dholmes at openjdk.org Thu Jan 30 21:15:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Jan 2025 21:15:27 GMT Subject: Integrated: JDK-8349101 : Problemlist HeadlessMalfunctionTest.java In-Reply-To: References: Message-ID: <0F8XlrH6tCnS9koWNQtM0Gbfb-yWTQnBGLE3bVPCzdo=.954c1776-1474-4602-98bf-0d3ee903d249@github.com> On Thu, 30 Jan 2025 20:58:17 GMT, Harshitha Onkar wrote: > java/awt/Headless/HeadlessMalfunctionTest.java problemlisted as it fails after [JDK-8336382](https://bugs.openjdk.org/browse/JDK-8336382) fix. LGTM! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23375#pullrequestreview-2585066092 From honkar at openjdk.org Thu Jan 30 21:15:27 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 30 Jan 2025 21:15:27 GMT Subject: Integrated: JDK-8349101 : Problemlist HeadlessMalfunctionTest.java In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 20:58:17 GMT, Harshitha Onkar wrote: > java/awt/Headless/HeadlessMalfunctionTest.java problemlisted as it fails after [JDK-8336382](https://bugs.openjdk.org/browse/JDK-8336382) fix. This pull request has now been integrated. Changeset: d589a82d Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/d589a82d08a01ae6ff87103b58d286f3c14367e5 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8349101: Problemlist HeadlessMalfunctionTest.java Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23375 From duke at openjdk.org Thu Jan 30 23:20:56 2025 From: duke at openjdk.org (Karm Michal Babacek) Date: Thu, 30 Jan 2025 23:20:56 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 20:41:26 GMT, David Holmes wrote: >> Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: >> >> Amended error message, doesn't clear exception > > The new test will not compile. The ASM library has been removed from OpenJDK, except for use by some hotspot tests. Everything else should be converted to use the Classfile API. See [JDK-8349099](https://bugs.openjdk.org/browse/JDK-8349099). @dholmes-ora Let me take a look presently... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2625879352 From serb at openjdk.org Fri Jan 31 01:02:59 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 31 Jan 2025 01:02:59 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: References: Message-ID: <8egXooYFVTjOhDHE9rFKoK6aWpP29ojgR-rlZz4p2m8=.4844d630-c774-4fb9-8459-8a51488e6464@github.com> On Wed, 29 Jan 2025 12:25:29 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Add debug output test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 59: > 57: GraphicsDevice[] gds = ge.getScreenDevices(); > 58: if (gds.length < 2) { > 59: System.out.println("It's a multi-screen test... skipping!"); BTW I hope we have a test for insets in a single screen config? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1936517419 From serb at openjdk.org Fri Jan 31 01:03:58 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 31 Jan 2025 01:03:58 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 02:16:02 GMT, Harshitha Onkar wrote: >>>Note, before this fix the following method iccCStoJCS was used to convert icc constant to java constant and if it was not possible an exception was thrown. >> >> Agreed. >> >>> but it was still possible to use such profiles for color conversion. >> >> The exception that I mentioned here: https://github.com/openjdk/jdk/pull/23044#discussion_r1929879100 is WITHOUT the newly added validation checks in setData(). >> >> The test case for that I used is as follows >> >> >> ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB); >> ICC_Profile sRGB = ICC_Profile.getInstace(ColorSpace.CS_sRGB); >> sRGB.setData() // changed the color space to cmsSigMCH1Data which is not present in JDK and commented out the validation checks in setData() >> cs.toRGB(new float[3]); //color transform from CS_LINEAR_RGB to CS_sRGB fails, java.awt.color.ProfileDataException: invalid ICC color space thrown during color conversion. > >> But the existing checks that are already in the constructor can be safely added. > > Did you mean: profile class and color space validation checks should be okay to add to .setData() ? Everything we've already checked in the constructor is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1936518312 From serb at openjdk.org Fri Jan 31 01:04:46 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 31 Jan 2025 01:04:46 GMT Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and ShapeSINextSpan in libawt java2d from ubsan checks In-Reply-To: References: Message-ID: <3jdex5JTctdBekXPeXMDDdAUr0a4L47GAjtNB_4UYbM=.f0ced193-89e7-4503-a9bb-af414d0747ae@github.com> On Thu, 23 Jan 2025 09:23:52 GMT, Matthias Baesken wrote: > In java2d coding there are a few overflows (those are shown when running jtreg tests with ubsan enabled binaries) > jtreg test java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java shows > > jdk/src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683:16: runtime error: signed integer overflow: 1651910497 + 660764199 cannot be represented in type 'int' > #0 0x7efe59e6ece8 in BilinearInterp src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:683 > #1 0x7efe59e75e21 in Java_sun_java2d_loops_TransformHelper_Transform src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c:499 > #2 0x7efe9b8dee7b () > > java/awt/BasicStroke/DashStrokeTest.java shows > > src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366:21: runtime error: signed integer overflow: 128253951 + 2118518271 cannot be represented in type 'int' > #0 0x7fb97d7daf21 in ShapeSINextSpan src/java.desktop/share/native/libawt/java2d/pipe/ShapeSpanIterator.c:1366 > #1 0x7fb97d62fa7e in AnyIntSetSpans src/java.desktop/share/native/libawt/java2d/loops/AnyInt.c:75 > #2 0x7fb97d6a8816 in Java_sun_java2d_loops_FillSpans_FillSpans src/java.desktop/share/native/libawt/java2d/loops/FillSpans.c:92 > #3 0x7fba12d07e7b () > > > There is currently no need seen to adjust this coding, so exclude the methods from ubsan checking to avoid unneeded warnings. how it is possible to repro these warnings? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2626052192 From serb at openjdk.org Fri Jan 31 01:09:51 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 31 Jan 2025 01:09:51 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 20:21:16 GMT, Alisen Chung wrote: >nonexistent coordinates. But why this coordinates nonexistent, you at least can move undecorated windows there, that coordinates just is not visible on teh screen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2626063277 From honkar at openjdk.org Fri Jan 31 01:26:50 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 31 Jan 2025 01:26:50 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: <7ncKfAa8MHLoQLTgSS6NpAinizMXcZHmnAegBgFoXwE=.c369c1f0-84b8-4bb2-9c37-ac9031d98ae7@github.com> On Tue, 21 Jan 2025 20:06:55 GMT, Harshitha Onkar wrote: >> ICC_Profile.setData(..) does validation of the specified tag contents and throws an exception if it is not valid. But if the tag represents the header, at least some of the validation is lazy, occurring only when the data is used, leading to unexpected exceptions at a later time. The check should be done up-front when the data is set, as in other cases. >> >> `verifyHeader(byte[] data)`is called when header data is being updated and the following fields are validated according to the ICC Spec Document. [[1] Pg#19](https://www.color.org/specification/ICC.1-2022-05.pdf). >> >> - Profile/Device class >> - Color Space >> - Rendering Intent >> - PCS >> - Header Size check (ICC Header Size = 128 bytes) >> >> These validation checks are added to ICC_Profile.getInstance(..) & ICC_Profile.setData(..) methods. >> >> Reference: [1] https://www.color.org/specification/ICC.1-2022-05.pdf > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > Runtime Exception added @mrserb Discussed Rendering Intent and other cases with Phil and he thinks all the current validation checks look good as-is and no changes are required. Please refer to his latest comment https://github.com/openjdk/jdk/pull/23044#issuecomment-2619867896 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2626079398 From nbenalla at openjdk.org Fri Jan 31 02:08:30 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 31 Jan 2025 02:08:30 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. >> >> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 >> >> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. >> >> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Update @serialData text to CSR-approved version Code changes make sense and the updated text matches the text from the CSR. ------------- Marked as reviewed by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2585511820 From honkar at openjdk.org Fri Jan 31 02:09:40 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 31 Jan 2025 02:09:40 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: <8egXooYFVTjOhDHE9rFKoK6aWpP29ojgR-rlZz4p2m8=.4844d630-c774-4fb9-8459-8a51488e6464@github.com> References: <8egXooYFVTjOhDHE9rFKoK6aWpP29ojgR-rlZz4p2m8=.4844d630-c774-4fb9-8459-8a51488e6464@github.com> Message-ID: <7Yh8SPF8TsxV9NTOhKlA7S1sv9AqL2RcG5I50iYniOQ=.352e82f1-0d5c-4381-9489-808d909d1c17@github.com> On Fri, 31 Jan 2025 00:59:51 GMT, Sergey Bylokhov wrote: >> anass baya has updated the pull request incrementally with one additional commit since the last revision: >> >> Add debug output > > test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 59: > >> 57: GraphicsDevice[] gds = ge.getScreenDevices(); >> 58: if (gds.length < 2) { >> 59: System.out.println("It's a multi-screen test... skipping!"); > > BTW I hope we have a test for insets in a single screen config? Good point. Yes, I did see a test for Single screen config - `test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java` @mrserb @aivanov-jdk May be it can be combined into one single test rather than have two separate tests? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1936568297 From honkar at openjdk.org Fri Jan 31 02:39:57 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 31 Jan 2025 02:39:57 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 12:25:29 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Add debug output @anass-baya Fix looks good to me. Initially the test passed without the fix, I realized that I had the option **"Show taskbar on all displays"** checked in Settings, after unchecking it the test works as expected with the fix. Suggestion: Based on other reviewers opinion you can choose to combine MultiScreenInsetsTest & ScreenInsetsTest. https://github.com/openjdk/jdk/pull/23183#discussion_r1936568297 ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23183#pullrequestreview-2585552155 From psadhukhan at openjdk.org Fri Jan 31 03:20:47 2025 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 31 Jan 2025 03:20:47 GMT Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is rendered with ImageIcon in WindowsLookAndFeel [v6] In-Reply-To: <7nuocJJ76-uMik3qqduJSDf2WOCLCMN-as9Y0sfPJqw=.0997ce6b-aac3-4879-a39d-68c7d808cba8@github.com> References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com> <0GbRMNtzd56p_9XXGb8glFy-LvzRVOkcl__h18x8_2g=.8212eb22-c5f1-4f21-8d64-a9ecba9c5ee7@github.com> <7nuocJJ76-uMik3qqduJSDf2WOCLCMN-as9Y0sfPJqw=.0997ce6b-aac3-4879-a39d-68c7d808cba8@github.com> Message-ID: On Thu, 30 Jan 2025 15:12:01 GMT, Alexey Ivanov wrote: >> I found one in windows11 in Explorer which seems to use both icon and bullet checkmark and the present PR do the same >> >> ![image](https://github.com/user-attachments/assets/910a5b48-98f5-4ddb-8761-fe2205970774) > >> I found one in windows11 in Explorer which seems to use both icon and bullet checkmark and the present PR do the same > > Yeah, you're right, it looks similar. > > Yet the currently proposed fix in this PR is still off. The bullet or check-mark should be displayed where it is now. What I mean by this is that this `if` statement needs to be removed: > > https://github.com/openjdk/jdk/blob/fac63d4383c931ea515dcdf7a89e4285f753f41b/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java#L878-L881 > > If you remove it, then the bullet or check-mark will be rendered at its own place. > > Yet if there's an icon associated with a menu item, all the text in other menus should shift to make room for the added icon. (Note that this menu in File Explorer in Windows 11 has icons on each and every menu item.) > > ![Proposed layout for icons and bullets](https://github.com/user-attachments/assets/c3809aaa-3219-4b9a-b86e-7850a747f652) Updated.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r1936629025 From duke at openjdk.org Fri Jan 31 05:05:47 2025 From: duke at openjdk.org (anass baya) Date: Fri, 31 Jan 2025 05:05:47 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: <7Yh8SPF8TsxV9NTOhKlA7S1sv9AqL2RcG5I50iYniOQ=.352e82f1-0d5c-4381-9489-808d909d1c17@github.com> References: <8egXooYFVTjOhDHE9rFKoK6aWpP29ojgR-rlZz4p2m8=.4844d630-c774-4fb9-8459-8a51488e6464@github.com> <7Yh8SPF8TsxV9NTOhKlA7S1sv9AqL2RcG5I50iYniOQ=.352e82f1-0d5c-4381-9489-808d909d1c17@github.com> Message-ID: On Fri, 31 Jan 2025 02:07:21 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/Multiscreen/MultiScreenInsetsTest/MultiScreenInsetsTest.java line 59: >> >>> 57: GraphicsDevice[] gds = ge.getScreenDevices(); >>> 58: if (gds.length < 2) { >>> 59: System.out.println("It's a multi-screen test... skipping!"); >> >> BTW I hope we have a test for insets in a single screen config? > > Good point. Yes, I did see a test for Single screen config - `test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java` > > @mrserb @aivanov-jdk May be it can be combined into one single test rather than have two separate tests? Hello @honkar-jdk, @mrserb , Thank you for your review. I have already discussed this with @aivanov-jdk . We agreed to rename the current test MultiScreenInsetsTest.java to something like ScreenInsetsTest.java, and remove the condition that allows the test to run only with a multi-screen configuration. Additionally, we will remove the test located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java. We also agreed that this change should be handled in a separate bug ticket. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1936685768 From duke at openjdk.org Fri Jan 31 05:24:36 2025 From: duke at openjdk.org (Naveen Narayanan) Date: Fri, 31 Jan 2025 05:24:36 GMT Subject: Integrated: 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS In-Reply-To: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> References: <4c2-sr4ueKq2EbpFAPgQ9SHAwUKBMaYYqegMpiU3rSs=.1c67525a-e0c9-4400-83ed-9ac4c14b0868@github.com> Message-ID: On Thu, 23 Jan 2025 11:37:23 GMT, Naveen Narayanan wrote: > This contains test fixes for the following issue in ScreenCaptureRobotTest.java > > ? Failures in Mac OS because of mouse pointer visible on top of the image that is screen captured by robot. > > Testing: > Tested using Mach5(100 times per platform) in MacOS, Linux, Windows & MacOS AArch64. Seen all tests passing. This pull request has now been integrated. Changeset: 0d30b869 Author: naveen.n.narayanan URL: https://git.openjdk.org/jdk/commit/0d30b869d8be831bfc5ff5511b3a42900e4c22a4 Stats: 14 lines in 2 files changed: 12 ins; 1 del; 1 mod 8344581: [TESTBUG] java/awt/Robot/ScreenCaptureRobotTest.java failing on macOS Reviewed-by: aivanov, azvegint, abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/23264 From mbaesken at openjdk.org Fri Jan 31 08:10:49 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 31 Jan 2025 08:10:49 GMT Subject: RFR: 8330936: [ubsan] exclude function BilinearInterp and ShapeSINextSpan in libawt java2d from ubsan checks In-Reply-To: <3jdex5JTctdBekXPeXMDDdAUr0a4L47GAjtNB_4UYbM=.f0ced193-89e7-4503-a9bb-af414d0747ae@github.com> References: <3jdex5JTctdBekXPeXMDDdAUr0a4L47GAjtNB_4UYbM=.f0ced193-89e7-4503-a9bb-af414d0747ae@github.com> Message-ID: On Fri, 31 Jan 2025 01:02:34 GMT, Sergey Bylokhov wrote: > how it is possible to repro these warnings? Configure with '--enable-ubsan' added (on Linux; ubsan package needs to be installed on your distro). After the build, run the mentioned jtreg tests (java/awt/Scrollbar/AquaLFScrollbarTest/ScrollBarBorderTest.java and java/awt/BasicStroke/DashStrokeTest.java, if you run jtreg jdk :tier4 there might be a few other tests showing the issues too). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23255#issuecomment-2626556464 From serb at openjdk.org Fri Jan 31 10:21:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 31 Jan 2025 10:21:56 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:20:36 GMT, Phil Race wrote: >Non-ICC intents are not something we'd support. I see absolutely no problem with that. If a profile has an intent that is unknown to JDK APIs, it doesn't matter what LCMS might do with it if you were programming directly to LCMS as a CMM. non-cc intents in lcms are just examples of profiles in the wild that don't violate the icc spec, currently such profiles can be loaded and used for conversion, this patch will break that. Why we should apply this limit and do that now? Note that it is possible to use custom intents as well, and we will break it: >Little CMS plug-in architecture allows to implement user-defined intents >Who knows how many things we'd have to do in order to support 'custom' ICC intents. Then let's at least not break it intentionally. Then test and fix if it does not work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2626845518 From aivanov at openjdk.org Fri Jan 31 10:56:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 31 Jan 2025 10:56:53 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 02:36:50 GMT, Harshitha Onkar wrote: > @anass-baya Fix looks good to me. > > Initially the test passed without the fix, I realized that I had the option **"Show taskbar on all displays"** checked in Settings, after unchecking it the test works as expected with the fix. I have the option **Show taskbar on all displays** selected, yet the test didn't work for me initially. It depends on whether the main monitor happens to be the first screen in graphics environment. If not, you get wrong results. I cannot reproduce the problem at this moment, my main monitor is the first one in the list. I [reproduced the problem](https://bugs.openjdk.org/browse/JDK-6899304?focusedId=14594269&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14594269) when three monitors were connected, I used a different laptop at that time. > Suggestion: Based on other reviewers opinion you can choose to combine MultiScreenInsetsTest & ScreenInsetsTest. [#23183 (comment)](https://github.com/openjdk/jdk/pull/23183#discussion_r1936568297) Yes, we should combine the two tests. However, I'd rather do it separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23183#issuecomment-2626920314 From mbaesken at openjdk.org Fri Jan 31 12:19:54 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 31 Jan 2025 12:19:54 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 19:47:55 GMT, Magnus Ihse Bursie wrote: > I don't think there is much point in being able to vary the opt level; it is more about spending the time to find the most appropriate opt level, and once you've done that, you can update the makefile directly. You want to optimize for binary size in some scenarios but not in all. And when looking at binary size (maybe also performance in some special cases) lto is promising for some jdk libs but at least for now you don't want to enable it as a default. Still, for some simple cases like e.g. BUILD_LIBSPLASHSCREEN changing the opt level from LOW to SIZE is probably the best thing to do after some more testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2627072670 From ihse at openjdk.org Fri Jan 31 13:35:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 31 Jan 2025 13:35:58 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:11:58 GMT, Karm Michal Babacek wrote: >> If there is a problem with finding and calling e.g. `java/awt/GraphicsEnvironment` in `AWTIsHeadless`, the env' Exception remains set and it is not cleared. Later, that manifests as: >> >> Fatal error reported via JNI: Could not allocate library name >> >> Which is misleading. The code path is perhaps rare in a normal JDK usage, but it has been complicating our users' bug reports in the GraalVM/native-image ecosystem for quite some time. >> >> Instead of failing later indicating that the user has incorrectly configured JNI, it bails out very soon with a message that seems as if a jstring could not have been allocated. It sends users on wild goose chases where it appears `JNU_NewStringPlatform` calls failed, e.g. >> >> * https://github.com/oracle/graal/issues/9138 >> * https://github.com/oracle/graal/issues/8475 >> * https://github.com/oracle/graal/issues/9300 >> * https://github.com/quarkusio/quarkus/issues/31596 >> * https://github.com/graalvm/mandrel/issues/292 >> * https://github.com/Karm/mandrel-integration-tests/issues/262 >> >> This commit fixes the error reporting in the AWTIsHeadless. >> >> Furthermore, when AOT compiled, there is little sense for having a JAVA_HOME, yet some parts of AWT code look for it to search fonts. In such case, an empty directory structure is enough to accommodate it, e.g. >> >> /tmp/JAVA_HOME/ >> /tmp/JAVA_HOME/conf >> /tmp/JAVA_HOME/conf/fonts >> /tmp/JAVA_HOME/lib >> >> The exception is somewhat cryptic for users again, merely stating: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 22.0.1/java.awt.Font.createFont0(Font.java:1205) >> at java.desktop at 22.0.1/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139 >> >> Adding the cause there makes it clearer, i.e. that JAVA_HOME might be missing: >> >> Exception in thread "main" java.io.IOException: Problem reading font data. >> at java.desktop at 23-internal/java.awt.Font.createFont0(Font.java:1206) >> at java.desktop at 23-internal/java.awt.Font.createFont(Font.java:1076) >> at imageio.Main.loadFonts(Main.java:139) >> at imageio.Main.paintRectangles(Main.java:97) >> at imageio.Main.main(Main.java:195) >> at java.base at 23-internal/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH) >> Caused by: java.lang.Error: java.home property not set >> at java.desktop at 23-internal/sun.awt.FontConfiguration.findFontConfigF... > > Karm Michal Babacek has updated the pull request incrementally with one additional commit since the last revision: > > Amended error message, doesn't clear exception See https://bugs.openjdk.org/browse/JDK-8349099 @Karm I was wondering why this did not show up on GHA (it's probably not executed there). But I noticed when researching this that your last merge from mainline was in September. Even if there are no "physical" merge conflicts that git can detect, there are likely to be "logical" conflicts like this, where a library was removed that your test depended on. So for a long running PR like this, when it is ready to be checked in, you need to merge in main and verify that the fix (and the tests) still works, and nothing else breaks. If there are no "physical" conflicts you do not need to push the merge to the PR on github, since that might invalidate approvals, but you need to test it locally. As for how long "long running" is, I don't know. A week without merge is likely okay, 3 months is not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2627351962 From jwaters at openjdk.org Fri Jan 31 14:02:55 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 31 Jan 2025 14:02:55 GMT Subject: RFR: 8348830: LIBFONTMANAGER optimization is always HIGHEST In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 12:16:54 GMT, Matthias Baesken wrote: > > I don't think there is much point in being able to vary the opt level; it is more about spending the time to find the most appropriate opt level, and once you've done that, you can update the makefile directly. > > You want to optimize for binary size in some scenarios but not in all. And when looking at binary size (maybe also performance in some special cases) lto is promising for some jdk libs but at least for now you don't want to enable it as a default. > > Still, for some simple cases like e.g. BUILD_LIBSPLASHSCREEN changing the opt level from LOW to SIZE is probably the best thing to do after some more testing. I think LTO ability for native JDK code could be worthwhile as a flag, but having a JVM opt-size equivalent for the JDK native code is not as beneficial, given not many are really interested in the individual optimization levels of each module. In any case LibCommon.gmk and LauncherCommon.gmk is where I put these optimization overrides in my fork ------------- PR Comment: https://git.openjdk.org/jdk/pull/23332#issuecomment-2627422830 From duke at openjdk.org Fri Jan 31 17:13:53 2025 From: duke at openjdk.org (duke) Date: Fri, 31 Jan 2025 17:13:53 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 12:25:29 GMT, anass baya wrote: >> Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. >> >> We used an existing test and took the following considerations into account for Windows: >> >> - On Windows, undecorated maximized frames are placed over the taskbar. >> - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). >> - Consider the fractional part after scaling. > > anass baya has updated the pull request incrementally with one additional commit since the last revision: > > Add debug output @anass-baya Your change (at version 017da1ab2df945f614b64e9e0919792fb2b41264) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23183#issuecomment-2627833631 From aturbanov at openjdk.org Fri Jan 31 18:01:22 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 31 Jan 2025 18:01:22 GMT Subject: RFR: 8349157: Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash Message-ID: There is a field 'sun.awt.X11.XKeysym#javaKeycode2KeysymHash' which uses legacy Hashtable class. As this map is read-only and all its content is initialized in '' we can safely use immutable Map instead. ------------- Commit messages: - [PATCH] Unnecessary Hashtable usage in XKeysym.javaKeycode2KeysymHash Changes: https://git.openjdk.org/jdk/pull/23347/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349157 Stats: 20 lines in 1 file changed: 7 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23347.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23347/head:pull/23347 PR: https://git.openjdk.org/jdk/pull/23347 From duke at openjdk.org Fri Jan 31 18:32:53 2025 From: duke at openjdk.org (anass baya) Date: Fri, 31 Jan 2025 18:32:53 GMT Subject: Integrated: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 20:51:09 GMT, anass baya wrote: > Screen number 0 is not always the primary screen, so we?ve removed the code that assumes it is. > > We used an existing test and took the following considerations into account for Windows: > > - On Windows, undecorated maximized frames are placed over the taskbar. > - On Windows, the top-left corner of an undecorated maximized frame may have negative coordinates (x, y). > - Consider the fractional part after scaling. This pull request has now been integrated. Changeset: 651ac3cc Author: anass baya URL: https://git.openjdk.org/jdk/commit/651ac3cc0f2a8b3edf5cddb42df1d38d4aa0e1a6 Stats: 73 lines in 2 files changed: 34 ins; 23 del; 16 mod 6899304: java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values Reviewed-by: aivanov, honkar, prr, serb ------------- PR: https://git.openjdk.org/jdk/pull/23183 From aivanov at openjdk.org Fri Jan 31 19:09:59 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 31 Jan 2025 19:09:59 GMT Subject: RFR: 8336382: Fix error reporting in loading AWT [v10] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 13:33:13 GMT, Magnus Ihse Bursie wrote: > See https://bugs.openjdk.org/browse/JDK-8349099 > > @Karm I was wondering why this did not show up on GHA (it's probably not executed there). But I noticed when researching this that your last merge from mainline was in September. Even if there are no "physical" merge conflicts that git can detect, there are likely to be "logical" conflicts like this, where a library was removed that your test depended on. I thought I'd run the client tests with changes from this PR, and I usually merge master into my local branch before submitting a job. Yet I can't find the job, I might not have run the tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20169#issuecomment-2628103573 From aivanov at openjdk.org Fri Jan 31 19:54:11 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 31 Jan 2025 19:54:11 GMT Subject: RFR: 8345538: Robot.mouseMove doesn't clamp bounds on macOS when trying to move mouse off screen [v6] In-Reply-To: References: Message-ID: <-xcXsVV9DmHoMMQI-syIIF-k7gxxlPLtSyzPLhCespY=.3b4a6dda-e0ef-4849-9889-508e0d6c73cc@github.com> On Thu, 30 Jan 2025 20:21:16 GMT, Alisen Chung wrote: > > I would like to clarify one point: if the robot moves the mouse off the screen while the actual mouse pointer is on the screen and immediately presses the mouse button, where will the click occur? on or off the screen? > > In macOS code there is similar method that checks for mouse offscreen locations called checkMousePos() which updates and clamps the mousePosition stored in CRobot and is called after mousePress and mouseRelease In macOS? Do you mean in macOS-specific code in JDK? ~~If the code to clamp mouse coordinates has already been written, why are you writing new code instead of re-using the existing code?~~ However, the code in [`CRobot.checkMousePos`](https://github.com/openjdk/jdk/blob/651ac3cc0f2a8b3edf5cddb42df1d38d4aa0e1a6/src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java#L98) doesn't really clamp mouse coordinates. The value of `MOUSE_LOCATION_UNKNOWN` is -1: https://github.com/openjdk/jdk/blob/651ac3cc0f2a8b3edf5cddb42df1d38d4aa0e1a6/src/java.desktop/macosx/classes/sun/lwawt/macosx/CRobot.java#L36 This means it may be impossible to click at (-1, -1) which could be perfectly valid coordinates. It looks like _a bug_, actually. > > nonexistent coordinates. > > But why this coordinates nonexistent, you at least can move undecorated windows there, that coordinates just is not visible on teh screen. This is the question we have to answer first: Are the coordinates off the virtual screen invalid, non-existent? What we've seen so far is `Robot.mouseMove` succeeds in a way that mouse appears to be moved to the specified location. That location gets returned by the OS, at least on macOS, when the OS-specific native code in `MouseInfo.getPointerInfo()` reads the coordinates???it is the code in `MouseInfo.getPointerInfo()` that clamps the coordinates to known screen devices and returns `null`, if the coordinates are outside of these bounds: https://github.com/openjdk/jdk/blob/651ac3cc0f2a8b3edf5cddb42df1d38d4aa0e1a6/src/java.desktop/share/classes/java/awt/MouseInfo.java#L84-L86 This is because `PointerInfo` requires both the device and the coordinates. Then, when you use a physical mouse, the OS doesn't allow moving the mouse cursor outside of the virtual screen bounds. Does this imply Java should prevent moving the mouse cursor off the virtual screen, too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22781#issuecomment-2628256432 From honkar at openjdk.org Fri Jan 31 20:13:16 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 31 Jan 2025 20:13:16 GMT Subject: RFR: 6899304 : java.awt.Toolkit.getScreenInsets(GraphicsConfiguration) returns incorrect values [v8] In-Reply-To: References: <8egXooYFVTjOhDHE9rFKoK6aWpP29ojgR-rlZz4p2m8=.4844d630-c774-4fb9-8459-8a51488e6464@github.com> <7Yh8SPF8TsxV9NTOhKlA7S1sv9AqL2RcG5I50iYniOQ=.352e82f1-0d5c-4381-9489-808d909d1c17@github.com> Message-ID: <3eGA6jv0ZHNSX1ugUdf64dEKCTf7ulIEAKRQXQg-Rak=.d9748fcb-a23a-4b2e-b0c5-1a22458c279b@github.com> On Fri, 31 Jan 2025 05:03:31 GMT, anass baya wrote: >> Good point. Yes, I did see a test for Single screen config - `test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java` >> >> @mrserb @aivanov-jdk May be it can be combined into one single test rather than have two separate tests? > > Hello @honkar-jdk, @mrserb , > > Thank you for your review. > > I have already discussed this with @aivanov-jdk . We agreed to rename the current test MultiScreenInsetsTest.java to something like ScreenInsetsTest.java, and remove the condition that allows the test to run only with a multi-screen configuration. Additionally, we will remove the test located at test/jdk/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java. ( since it is less accurate than MultiScreenInsetsTest.java ). > > We also agreed that this change should be handled in a separate bug ticket. > > Is it Okay for you to proceed that way ? If yes I will proceed with integration Sounds good to me ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23183#discussion_r1937933084 From aivanov at openjdk.org Fri Jan 31 20:40:27 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 31 Jan 2025 20:40:27 GMT Subject: RFR: 8348865: JButton/bug4796987.java never runs because Windows XP is unavailable [v2] In-Reply-To: References: Message-ID: > The `javax/swing/JButton/4796987/bug4796987.java` test strictly verifies if it's run on Windows XP, for this reason it never runs on modern versions of Windows. > > Since Windows XP is obsolete and visual styles cannot be disabled since Windows 8, I removed the OS version check completely. > > I captured an image of the panel and analyse colors in the image instead of using `Robot.getPixelColor`; I save the image for reference if the test fails. > > The updated test passes in the CI. Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision: - Update the test summary - Remove the redundant button ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23336/files - new: https://git.openjdk.org/jdk/pull/23336/files/62833cbc..0349f37a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23336&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23336&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23336/head:pull/23336 PR: https://git.openjdk.org/jdk/pull/23336 From aivanov at openjdk.org Fri Jan 31 20:48:59 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 31 Jan 2025 20:48:59 GMT Subject: RFR: 8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland [v2] In-Reply-To: References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: On Tue, 28 Jan 2025 18:40:00 GMT, Alexander Zvegintsev wrote: >> Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. >> >> Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) >>> the reason is this is using XTEST, an X11 protocol which will not work outside of X11. >>> >>> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. >> >> I also tested the same tests by clicking manually instead of using the robot, and it works as expected. >> So for now, skip those tests on Wayland (and do some minor cleanup). >> >> Testing after modifications is also green. > > Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: > > - minor > - review comments Marked as reviewed by aivanov (Reviewer). test/jdk/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupClickTest.java line 79: > 77: "\"Always show all icons and notifications on the taskbar\" true " + > 78: "to avoid this problem. Or change behavior only for Java SE " + > 79: "tray icon."); These instructions are outdated, at the same time, they're visible only on the test log? *I'd rather leave them as is*???it's out of scope to amend the instructions to be accurate for Windows 10 and 11. ------------- PR Review: https://git.openjdk.org/jdk/pull/23329#pullrequestreview-2587845730 PR Review Comment: https://git.openjdk.org/jdk/pull/23329#discussion_r1937964332 From honkar at openjdk.org Fri Jan 31 21:14:02 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 31 Jan 2025 21:14:02 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 10:17:11 GMT, Sergey Bylokhov wrote: >> ICC specifies 4 rendering intents, no more. And is clear that these are the 4 ICC rendering intents. >> >> Non-ICC intents are not something we'd support. I see absolutely no problem with that. >> If a profile has an intent that is unknown to JDK APIs, it doesn't matter what LCMS might do with it >> if you were programming directly to LCMS as a CMM. >> Who knows how many things we'd have to do in order to support 'custom' ICC intents. >> >> For Color Spaces, the ICC spec. says >> "The names and signatures of the permitted data colour spaces are shown in Table 19." >> >> The word "permitted" makes it clear that anything not in this table is not permitted, and thus illegal. >> >> So in summary, the changes made here are all fine. > >>Non-ICC intents are not something we'd support. I see absolutely no problem with that. > If a profile has an intent that is unknown to JDK APIs, it doesn't matter what LCMS might do with it > if you were programming directly to LCMS as a CMM. > > non-cc intents in lcms are just examples of profiles in the wild that don't violate the icc spec, currently such profiles can be loaded and used for conversion, this patch will break that. Why we should apply this limit and do that now? > > Note that it is possible to use custom intents as well, and we will break it: >>Little CMS plug-in architecture allows to implement user-defined intents > >>Who knows how many things we'd have to do in order to support 'custom' ICC intents. > > Then let's at least not break it intentionally. Then test and fix if it does not work. @mrserb > non-cc intents in lcms are just examples of profiles in the wild that don't violate the icc spec, currently such profiles can be loaded and used for conversion, this patch will break that. Why we should apply this limit and do that now? When Rendering Intent validation is skipped, it means that along with non-icc intents other random invalid values are also allowed while updating the profile.. Is it okay to allow invalid Rendering Intents that successfully updated the profile only to cause exception later by LCMS (as below during color transform)? java.awt.color.CMMException: LCMS error 8: Unsupported intent '5' at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method) at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:113) at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:114) at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:534) at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224) The same is true for ColorSpace or Device profile with the original code (without validation checks). You are allowed to update the profile with invalid values successfully which later causes exception. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23044#issuecomment-2628404798 From dnguyen at openjdk.org Fri Jan 31 21:34:50 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 31 Jan 2025 21:34:50 GMT Subject: RFR: 8348675: TrayIcon tests fail in Ubuntu 24.10 Wayland [v2] In-Reply-To: References: <2mWoCuhKjnzS47DwLgeP8siD6oAAZiHRF8lkQM0vhSU=.df1e9b19-4f6c-46dc-a9be-08abcdbccfae@github.com> Message-ID: <2qZlj6UxnCSoMEzLBsxdSMESbVZZoMhezrZl1PAjBWo=.4fb1cf73-6780-4000-95a8-82429b3874fe@github.com> On Tue, 28 Jan 2025 18:40:00 GMT, Alexander Zvegintsev wrote: >> Several TrayIcon tests are trying to click on the system tray icon with Robot using XTest API. >> >> Basically we have the same kind of failures as before, e.g. [JDK-8280990](https://bugs.openjdk.org/browse/JDK-8280990) >>> the reason is this is using XTEST, an X11 protocol which will not work outside of X11. >>> >>> In other words, the emulated input event reaches the X11 clients, but not the Wayland compositor which is the actual display server but also the X11 window manager in Wayland, the component which is in charge of moving/resizing/stacking the windows. >> >> I also tested the same tests by clicking manually instead of using the robot, and it works as expected. >> So for now, skip those tests on Wayland (and do some minor cleanup). >> >> Testing after modifications is also green. > > Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: > > - minor > - review comments I noticed the same issue when testing on Wayland for some tests regarding SystemTray/TrayIcon. One of the ones I looked at was actually TrayIconPopupTest, which you covered here. Makes sense to just skip them for now where possible. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/23329#pullrequestreview-2587914491 From honkar at openjdk.org Fri Jan 31 21:43:51 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 31 Jan 2025 21:43:51 GMT Subject: RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v9] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 01:01:22 GMT, Sergey Bylokhov wrote: >>> But the existing checks that are already in the constructor can be safely added. >> >> Did you mean: profile class and color space validation checks should be okay to add to .setData() ? > > Everything we've already checked in the constructor is fine. I'm not sure if I understood the above conversation clearly. Can you please explain again? > For other fields too which fields ? Is it RenderingIntent and PCS? > the existing checks which checks? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1938012324