From duke at openjdk.org Sun Dec 1 00:50:12 2024 From: duke at openjdk.org (ScientificWare) Date: Sun, 1 Dec 2024 00:50:12 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v4] In-Reply-To: References: Message-ID: > This is referenced in Java Bug Database as > - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731) > > This is tracked in JBS as > - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731) > > According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input) > > `alt` is not an attribute of the `input` element. > > According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : > >> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ... > > This feature is not implemented in `FormView.java`. > > ?? ~~This also affects the HTML 32 DTD~~ > > ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138) > > Left before the patch and right after the patch. > > > import java.awt.BorderLayout; > import java.awt.Dimension; > import javax.swing.JEditorPane; > import javax.swing.JFrame; > import javax.swing.JScrollPane; > import javax.swing.SwingUtilities; > import javax.swing.text.Document; > import javax.swing.text.html.HTMLEditorKit; > import javax.swing.text.html.StyleSheet; > > public class HTMLAddsSupportAltInputTag { > public static void main(String[] args) { > new HTMLAddsSupportAltInputTag(); > } > > public HTMLAddsSupportAltInputTag() { > SwingUtilities.invokeLater(new Runnable(){ > public void run(){ > JEditorPane jEditorPane = new JEditorPane(); > jEditorPane.setEditable(false); > JScrollPane scrollPane = new JScrollPane(jEditorPane); > HTMLEditorKit kit = new HTMLEditorKit(); > jEditorPane.setEditorKit(kit); > StyleSheet styleSheet = kit.getStyleSheet(); > styleSheet.addRule(""" > body { > color: #000; > font-family:times; > margin: 4px; > } > """); > String htmlString = """ > > > >

> >

> - Merge master - Merge master - Merge master - ... and 4 more: https://git.openjdk.org/jdk/compare/28ae281b...242bf546 ------------- Changes: https://git.openjdk.org/jdk/pull/15319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15319&range=03 Stats: 235 lines in 5 files changed: 230 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15319/head:pull/15319 PR: https://git.openjdk.org/jdk/pull/15319 From duke at openjdk.org Sun Dec 1 01:10:39 2024 From: duke at openjdk.org (ScientificWare) Date: Sun, 1 Dec 2024 01:10:39 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v3] In-Reply-To: <3QQGijNyprMJBC8JrdntzeD5RKklMDkZB60_BPC-2dw=.a1b6c3e9-1f3d-4010-933f-23d9c2375fdd@github.com> References: <3QQGijNyprMJBC8JrdntzeD5RKklMDkZB60_BPC-2dw=.a1b6c3e9-1f3d-4010-933f-23d9c2375fdd@github.com> Message-ID: On Tue, 21 Nov 2023 14:09:07 GMT, Alexey Ivanov wrote: > I wonder if it's possible to write a (unit) test which verifies the new behaviour? and whether it's worth doing. @aivanov-jdk Done. > please say when you will be getting back to this @prrace I'm getting back to this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-2509506629 From duke at openjdk.org Sun Dec 1 10:17:34 2024 From: duke at openjdk.org (ScientificWare) Date: Sun, 1 Dec 2024 10:17:34 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v5] In-Reply-To: References: Message-ID: > This is referenced in Java Bug Database as > - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731) > > This is tracked in JBS as > - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731) > > According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input) > > `alt` is not an attribute of the `input` element. > > According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : > >> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ... > > This feature is not implemented in `FormView.java`. > > ?? ~~This also affects the HTML 32 DTD~~ > > ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138) > > Left before the patch and right after the patch. > > > import java.awt.BorderLayout; > import java.awt.Dimension; > import javax.swing.JEditorPane; > import javax.swing.JFrame; > import javax.swing.JScrollPane; > import javax.swing.SwingUtilities; > import javax.swing.text.Document; > import javax.swing.text.html.HTMLEditorKit; > import javax.swing.text.html.StyleSheet; > > public class HTMLAddsSupportAltInputTag { > public static void main(String[] args) { > new HTMLAddsSupportAltInputTag(); > } > > public HTMLAddsSupportAltInputTag() { > SwingUtilities.invokeLater(new Runnable(){ > public void run(){ > JEditorPane jEditorPane = new JEditorPane(); > jEditorPane.setEditable(false); > JScrollPane scrollPane = new JScrollPane(jEditorPane); > HTMLEditorKit kit = new HTMLEditorKit(); > jEditorPane.setEditorKit(kit); > StyleSheet styleSheet = kit.getStyleSheet(); > styleSheet.addRule(""" > body { > color: #000; > font-family:times; > margin: 4px; > } > """); > String htmlString = """ > > > >

> >

> References: Message-ID: > This is referenced in Java Bug Database as > - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731) > > This is tracked in JBS as > - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731) > > According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input) > > `alt` is not an attribute of the `input` element. > > According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : > >> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ... > > This feature is not implemented in `FormView.java`. > > ?? ~~This also affects the HTML 32 DTD~~ > > ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138) > > Left before the patch and right after the patch. > > > import java.awt.BorderLayout; > import java.awt.Dimension; > import javax.swing.JEditorPane; > import javax.swing.JFrame; > import javax.swing.JScrollPane; > import javax.swing.SwingUtilities; > import javax.swing.text.Document; > import javax.swing.text.html.HTMLEditorKit; > import javax.swing.text.html.StyleSheet; > > public class HTMLAddsSupportAltInputTag { > public static void main(String[] args) { > new HTMLAddsSupportAltInputTag(); > } > > public HTMLAddsSupportAltInputTag() { > SwingUtilities.invokeLater(new Runnable(){ > public void run(){ > JEditorPane jEditorPane = new JEditorPane(); > jEditorPane.setEditable(false); > JScrollPane scrollPane = new JScrollPane(jEditorPane); > HTMLEditorKit kit = new HTMLEditorKit(); > jEditorPane.setEditorKit(kit); > StyleSheet styleSheet = kit.getStyleSheet(); > styleSheet.addRule(""" > body { > color: #000; > font-family:times; > margin: 4px; > } > """); > String htmlString = """ > > > >

> >

> References: <7_6ap7IiM5hzP1kXLmWZ3kHns9kmkQOylEVIDQmjFOE=.00930420-3576-44bc-96fd-ab48a9c8d248@github.com> Message-ID: On Sat, 30 Nov 2024 03:55:50 GMT, Phil Race wrote: >> Remove uses of and references to SecurityManager from the printing code > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8345142 Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22422#pullrequestreview-2471556976 From azvegint at openjdk.org Mon Dec 2 00:47:52 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 2 Dec 2024 00:47:52 GMT Subject: RFR: 8345141: Remove uses of SecurityManager in ShellFolder related classes [v2] In-Reply-To: References: Message-ID: On Sat, 30 Nov 2024 03:50:24 GMT, Phil Race wrote: >> Remove SecurityManager related code from Swing filechooser implementation > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8345141 Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22423#pullrequestreview-2471558552 From azvegint at openjdk.org Mon Dec 2 00:47:53 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 2 Dec 2024 00:47:53 GMT Subject: RFR: 8345141: Remove uses of SecurityManager in ShellFolder related classes [v2] In-Reply-To: References: Message-ID: On Sat, 30 Nov 2024 03:45:14 GMT, Phil Race wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java line 167: >> >>> 165: >>> 166: static Win32ShellFolder2 getDesktop() { >>> 167: if (desktop == null) { >> >> `import java.util.stream.Stream;` unused > > Doesn't seem related to this change. I'll fix it here since a simple build should prove it is safe, but refactoring and non-SM clean up is not a goal in these fixes. In this case, it is related because you have removed its use: `- private static File[] checkFiles(Stream filesStream, @SuppressWarnings("removal") SecurityManager sm) {` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22423#discussion_r1865077865 From azvegint at openjdk.org Mon Dec 2 00:58:46 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 2 Dec 2024 00:58:46 GMT Subject: RFR: 8345143: Remove uses of SecurityManager in the java.desktop module [v2] In-Reply-To: References: Message-ID: <7sYuojWQDsIRMswxvYS1uqj5_NepvjYfZjXT3Q7sTgQ=.817db01a-3ea3-4d3c-a7c5-d57b8be35c51@github.com> On Fri, 29 Nov 2024 01:04:32 GMT, Alexander Zvegintsev wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8345143 > > src/java.desktop/share/classes/javax/swing/Popup.java line 247: > >> 245: // Try to set "always-on-top" for the popup window. >> 246: // Applets usually don't have sufficient permissions to do it. >> 247: // In this case simply ignore the exception. > > Suggestion: This can still be updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22424#discussion_r1865083798 From prr at openjdk.org Mon Dec 2 04:23:46 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 2 Dec 2024 04:23:46 GMT Subject: RFR: 8345143: Remove uses of SecurityManager in the java.desktop module [v3] In-Reply-To: <7sYuojWQDsIRMswxvYS1uqj5_NepvjYfZjXT3Q7sTgQ=.817db01a-3ea3-4d3c-a7c5-d57b8be35c51@github.com> References: <7sYuojWQDsIRMswxvYS1uqj5_NepvjYfZjXT3Q7sTgQ=.817db01a-3ea3-4d3c-a7c5-d57b8be35c51@github.com> Message-ID: On Mon, 2 Dec 2024 00:55:55 GMT, Alexander Zvegintsev wrote: >> src/java.desktop/share/classes/javax/swing/Popup.java line 247: >> >>> 245: // Try to set "always-on-top" for the popup window. >>> 246: // Applets usually don't have sufficient permissions to do it. >>> 247: // In this case simply ignore the exception. >> >> Suggestion: > > This can still be updated. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22424#discussion_r1865204366 From prr at openjdk.org Mon Dec 2 04:23:45 2024 From: prr at openjdk.org (Phil Race) Date: Mon, 2 Dec 2024 04:23:45 GMT Subject: RFR: 8345143: Remove uses of SecurityManager in the java.desktop module [v3] In-Reply-To: References: Message-ID: <60yT3WANw9AZv4R8kKUPtf8bziCriK_I2-nk6Qn0jCA=.31992c2f-c8a2-497e-92ee-2f44c50caecc@github.com> > Remove SecurityManager related code in the desktop module that is not covered by other PRs Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8345143 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22424/files - new: https://git.openjdk.org/jdk/pull/22424/files/a02cecb4..17302404 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22424&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22424&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22424/head:pull/22424 PR: https://git.openjdk.org/jdk/pull/22424 From azvegint at openjdk.org Mon Dec 2 04:40:42 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 2 Dec 2024 04:40:42 GMT Subject: RFR: 8345143: Remove uses of SecurityManager in the java.desktop module [v3] In-Reply-To: <60yT3WANw9AZv4R8kKUPtf8bziCriK_I2-nk6Qn0jCA=.31992c2f-c8a2-497e-92ee-2f44c50caecc@github.com> References: <60yT3WANw9AZv4R8kKUPtf8bziCriK_I2-nk6Qn0jCA=.31992c2f-c8a2-497e-92ee-2f44c50caecc@github.com> Message-ID: On Mon, 2 Dec 2024 04:23:45 GMT, Phil Race wrote: >> Remove SecurityManager related code in the desktop module that is not covered by other PRs > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8345143 Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22424#pullrequestreview-2471726576 From psadhukhan at openjdk.org Mon Dec 2 05:26:46 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 2 Dec 2024 05:26:46 GMT Subject: RFR: 8345142: Remove uses of SecurityManager in Printing related classes [v2] In-Reply-To: References: <7_6ap7IiM5hzP1kXLmWZ3kHns9kmkQOylEVIDQmjFOE=.00930420-3576-44bc-96fd-ab48a9c8d248@github.com> Message-ID: On Sat, 30 Nov 2024 03:55:50 GMT, Phil Race wrote: >> Remove uses of and references to SecurityManager from the printing code > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8345142 Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22422#pullrequestreview-2471767353 From abhiscxk at openjdk.org Mon Dec 2 06:51:40 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 2 Dec 2024 06:51:40 GMT Subject: RFR: 8345247: Deproblemlist test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java In-Reply-To: References: Message-ID: <_dxrFcF1VS3vfQcD-oavFtz9ZXAJ2MllL__DueYWA6o=.6e1bf024-d68f-4e2a-9908-0eab55d82a98@github.com> On Fri, 29 Nov 2024 12:19:43 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java is not failing in OCI but still listed in PL. > Removing as it is passing in OCI ubuntu22.04 system..Tested for 50 iterations in OCI.. test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java line 55: > 53: robot = new Robot(); > 54: robot.waitForIdle(); > 55: robot.delay(1000); Test is passing in my local machine without this extra delay. Does the test pass on CI machines without this increased delay or the delay is required to make the test more stable ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22458#discussion_r1865307896 From psadhukhan at openjdk.org Mon Dec 2 06:51:40 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 2 Dec 2024 06:51:40 GMT Subject: RFR: 8345247: Deproblemlist test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java In-Reply-To: <_dxrFcF1VS3vfQcD-oavFtz9ZXAJ2MllL__DueYWA6o=.6e1bf024-d68f-4e2a-9908-0eab55d82a98@github.com> References: <_dxrFcF1VS3vfQcD-oavFtz9ZXAJ2MllL__DueYWA6o=.6e1bf024-d68f-4e2a-9908-0eab55d82a98@github.com> Message-ID: On Mon, 2 Dec 2024 06:46:54 GMT, Abhishek Kumar wrote: >> test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java is not failing in OCI but still listed in PL. >> Removing as it is passing in OCI ubuntu22.04 system..Tested for 50 iterations in OCI.. > > test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java line 55: > >> 53: robot = new Robot(); >> 54: robot.waitForIdle(); >> 55: robot.delay(1000); > > Test is passing in my local machine without this extra delay. > > Does the test pass on CI machines without this increased delay or the delay is required to make the test more stable ? Its not needed strictly par se and it passed without it also but I modified as the test is using Robot class so better to use robot method.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22458#discussion_r1865309408 From abhiscxk at openjdk.org Mon Dec 2 07:03:37 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 2 Dec 2024 07:03:37 GMT Subject: RFR: 8345247: Deproblemlist test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 12:19:43 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java is not failing in OCI but still listed in PL. > Removing as it is passing in OCI ubuntu22.04 system..Tested for 50 iterations in OCI.. Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22458#pullrequestreview-2471879840 From abhiscxk at openjdk.org Mon Dec 2 07:03:38 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Mon, 2 Dec 2024 07:03:38 GMT Subject: RFR: 8345247: Deproblemlist test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java In-Reply-To: References: <_dxrFcF1VS3vfQcD-oavFtz9ZXAJ2MllL__DueYWA6o=.6e1bf024-d68f-4e2a-9908-0eab55d82a98@github.com> Message-ID: On Mon, 2 Dec 2024 06:48:34 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java line 55: >> >>> 53: robot = new Robot(); >>> 54: robot.waitForIdle(); >>> 55: robot.delay(1000); >> >> Test is passing in my local machine without this extra delay. >> >> Does the test pass on CI machines without this increased delay or the delay is required to make the test more stable ? > > Its not needed strictly par se and it passed without it also but I modified as the test is using Robot class so better to use robot method.. Ok.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22458#discussion_r1865319232 From psadhukhan at openjdk.org Mon Dec 2 08:17:49 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 2 Dec 2024 08:17:49 GMT Subject: Integrated: 8345247: Deproblemlist test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 12:19:43 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java is not failing in OCI but still listed in PL. > Removing as it is passing in OCI ubuntu22.04 system..Tested for 50 iterations in OCI.. This pull request has now been integrated. Changeset: 1c4c6531 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/1c4c653168bd4f39544eca08f8256a6ac6e4477c Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8345247: Deproblemlist test/jdk/javax/swing/JRadioButton/8075609/bug8075609.java Reviewed-by: abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/22458 From jwaters at openjdk.org Mon Dec 2 12:04:43 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 2 Dec 2024 12:04:43 GMT Subject: RFR: 8342870: Errors related to unused code on Windows after 8339120 in accessibility [v3] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 05:41:58 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 > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into accessibility > - Remove now unused result > - Merge branch 'master' into accessibility > - 8342870 I am still not sure where to ask for A11Y people to look at this ------------- PR Comment: https://git.openjdk.org/jdk/pull/21656#issuecomment-2511349242 From psadhukhan at openjdk.org Mon Dec 2 12:57:56 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 2 Dec 2024 12:57:56 GMT Subject: RFR: 8345297: test/jdk/javax/swing/Action/8133039/bug8133039.java fails in ubuntu22.04 Message-ID: test/jdk/javax/swing/Action/8133039/bug8133039.java failed in OCI ubuntu 22.04 with exception "Method accept not invoked" Seems like robot keypress happened before testframe was visible..Added a delay.. Several iterations passed in OCI linux system.. ------------- Commit messages: - OCItest2 Changes: https://git.openjdk.org/jdk/pull/22480/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22480&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345297 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22480/head:pull/22480 PR: https://git.openjdk.org/jdk/pull/22480 From duke at openjdk.org Mon Dec 2 14:01:46 2024 From: duke at openjdk.org (ScientificWare) Date: Mon, 2 Dec 2024 14:01:46 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v7] In-Reply-To: References: Message-ID: On Sun, 1 Dec 2024 12:40:29 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 = """ >> >> >> >>

>> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 26 Nov 2024 17:17:09 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > 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 25 commits: > > - Merge branch 'master' into static-jdk-image > - Remove LDFLAGS_STATIC_JDK > - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt > - Find LIBZIP_OBJS automatically > - Find LIBJAVA_JPEG_OBJS automatically > - Just exclude the a11y libraries from static builds > - Copy debuginfo > - Restore SetExecname in java_md.c > - Fix incremental builds > - Merge branch 'master' into static-jdk-image > - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20837#pullrequestreview-2472889294 From azvegint at openjdk.org Mon Dec 2 14:42:44 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 2 Dec 2024 14:42:44 GMT Subject: RFR: 8345297: test/jdk/javax/swing/Action/8133039/bug8133039.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 12:52:32 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/Action/8133039/bug8133039.java failed in OCI ubuntu 22.04 with exception "Method accept not invoked" > Seems like robot keypress happened before testframe was visible..Added a delay.. > Several iterations passed in OCI linux system.. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22480#pullrequestreview-2472891185 From ihse at openjdk.org Mon Dec 2 14:45:47 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Dec 2024 14:45:47 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 Build changes look fine. I also believe the AWT change is sound, based on Kim's reasoning. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22039#pullrequestreview-2472901733 From coleenp at openjdk.org Mon Dec 2 15:15:59 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 2 Dec 2024 15:15:59 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v21] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 26 Nov 2024 17:17:09 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > 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 25 commits: > > - Merge branch 'master' into static-jdk-image > - Remove LDFLAGS_STATIC_JDK > - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt > - Find LIBZIP_OBJS automatically > - Find LIBJAVA_JPEG_OBJS automatically > - Just exclude the a11y libraries from static builds > - Copy debuginfo > - Restore SetExecname in java_md.c > - Fix incremental builds > - Merge branch 'master' into static-jdk-image > - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8 Hotspot code looks okay. src/hotspot/os/linux/os_linux.cpp line 590: > 588: > 589: // Found the full path to the binary. It is normally of this structure: > 590: // /lib//libjvm.so You could change to server I believe, since there isn't a client (I hope) version anymore. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20837#pullrequestreview-2472978117 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1866025164 From ihse at openjdk.org Mon Dec 2 15:16:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Dec 2024 15:16:00 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v21] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 26 Nov 2024 21:20:10 GMT, David Holmes 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 25 commits: >> >> - Merge branch 'master' into static-jdk-image >> - Remove LDFLAGS_STATIC_JDK >> - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt >> - Find LIBZIP_OBJS automatically >> - Find LIBJAVA_JPEG_OBJS automatically >> - Just exclude the a11y libraries from static builds >> - Copy debuginfo >> - Restore SetExecname in java_md.c >> - Fix incremental builds >> - Merge branch 'master' into static-jdk-image >> - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8 > > Hotspot changes look fine. > > Thanks @dholmes-ora @coleenp @erikj79 Thanks for your reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2511804187 From ihse at openjdk.org Mon Dec 2 15:16:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Dec 2024 15:16:01 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v21] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Mon, 2 Dec 2024 15:10:08 GMT, Coleen Phillimore 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 25 commits: >> >> - Merge branch 'master' into static-jdk-image >> - Remove LDFLAGS_STATIC_JDK >> - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt >> - Find LIBZIP_OBJS automatically >> - Find LIBJAVA_JPEG_OBJS automatically >> - Just exclude the a11y libraries from static builds >> - Copy debuginfo >> - Restore SetExecname in java_md.c >> - Fix incremental builds >> - Merge branch 'master' into static-jdk-image >> - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8 > > src/hotspot/os/linux/os_linux.cpp line 590: > >> 588: >> 589: // Found the full path to the binary. It is normally of this structure: >> 590: // /lib//libjvm.so > > You could change to server I believe, since there isn't a client (I hope) version anymore. Variant can also be e.g. `minimal`. And I do think the client variant is still supported, even if it is not actively built..? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1866028280 From ihse at openjdk.org Mon Dec 2 15:16:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 2 Dec 2024 15:16:02 GMT Subject: Integrated: 8339480: Build static-jdk image with a statically linked launcher In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). This pull request has now been integrated. Changeset: 1ca76445 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/1ca764454b1cb296f4aa38a4dfdf3d4abb5c19d6 Stats: 497 lines in 27 files changed: 399 ins; 23 del; 75 mod 8339480: Build static-jdk image with a statically linked launcher Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jiangli Zhou Reviewed-by: dholmes, erikj, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/20837 From coleenp at openjdk.org Mon Dec 2 15:22:53 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 2 Dec 2024 15:22:53 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v21] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Mon, 2 Dec 2024 15:11:54 GMT, Magnus Ihse Bursie wrote: >> src/hotspot/os/linux/os_linux.cpp line 590: >> >>> 588: >>> 589: // Found the full path to the binary. It is normally of this structure: >>> 590: // /lib//libjvm.so >> >> You could change to server I believe, since there isn't a client (I hope) version anymore. > > Variant can also be e.g. `minimal`. And I do think the client variant is still supported, even if it is not actively built..? Okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1866042498 From duke at openjdk.org Mon Dec 2 16:20:38 2024 From: duke at openjdk.org (lawrence.andrews) Date: Mon, 2 Dec 2024 16:20:38 GMT Subject: RFR: 8345297: test/jdk/javax/swing/Action/8133039/bug8133039.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 12:52:32 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/Action/8133039/bug8133039.java failed in OCI ubuntu 22.04 with exception "Method accept not invoked" > Seems like robot keypress happened before testframe was visible..Added a delay.. > Several iterations passed in OCI linux system.. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/22480#issuecomment-2512014131 From aivanov at openjdk.org Mon Dec 2 16:51:40 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 2 Dec 2024 16:51:40 GMT Subject: RFR: 8343418: Unnecessary Hashtable usage in CSS.htmlAttrToCssAttrMap [v4] In-Reply-To: References: Message-ID: <7UqaykzRL3EO_PIfKn5WTvjkF7at2TJxHZlflNg57ik=.b3c22740-02be-4bc5-93fa-9fc60a8d3516@github.com> On Tue, 12 Nov 2024 20:28:55 GMT, Andrey Turbanov wrote: >> If a thread-safe implementation is not needed, it is recommended to use HashMap instead of legacy synchronized Hashtable. >> Map `CSS.htmlAttrToCssAttrMap` is modified only within static initialization block and then only `get` method is called. >> >> The only subtle difference is that Hashtable doesn't allow `null` keys and throws NPE from `get` method. >> I've checked all possible keys which are passed to `htmlAttrToCssAttrMap.get`. >> Currently 3 different execution paths are possible: >> >> **1,2** >> When `HTML.Attribute.BORDER` is passed as a key. It's definitely non-null. >> >> javax.swing.text.html.CSS#translateHTMLToCSS >> translateAttribute(HTML.Attribute.BORDER, "1", cssAttrSet); >> CSS.Attribute[] cssAttrList = getCssAttribute(key); >> >> >> javax.swing.text.html.CSS#translateAttributes >> translateAttribute(HTML.Attribute.BORDER, Integer.toString(borderWidth), cssAttrSet); >> CSS.Attribute[] cssAttrList = getCssAttribute(key);` >> >> >> **3** >> When non-null `key` is passed as a key. >> >> javax.swing.text.html.CSS#translateAttributes >> >> if (name instanceof HTML.Attribute) { // from this `instanceof` we know that it's non-null >> HTML.Attribute key = (HTML.Attribute)name; >> >> translateAttribute(key, (String) htmlAttrSet.getAttribute(key), cssAttrSet); >> CSS.Attribute[] cssAttrList = getCssAttribute(key); >> >> >> ![idea_analyze_dataflow_to_here](https://github.com/user-attachments/assets/48ace4de-6d0a-468e-bb14-b579a193254b) >> >> >> I've used HashMap.newHashMap method instead of constructor to avoid resizing of internal HashMap array. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8343418: align more Looks good to me. I ran client tests once again, the tests pass. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21785#pullrequestreview-2473298051 From honkar at openjdk.org Mon Dec 2 17:16:46 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Dec 2024 17:16:46 GMT Subject: RFR: JDK-8344368 : IndependenceSwingTest.java and IndependenceAWTTest.java failed: Selected text & clipboard contents differs Message-ID: The following two tests failed intermittently due to stability issues after JEP486 (Removal of Security Manager). Tests have been updated for stability. This test is applicable for linux platform only, hence `@requires (os.family == "linux")` jtreg tag is added and the redundant OS check within the test is removed. - java/awt/datatransfer/Independence/IndependenceAWTTest.java - java/awt/datatransfer/Independence/IndependenceSwingTest.java Multiple runs of the test on CI looks good and the tests pass. ------------- Commit messages: - removed author tags, delay changes - added missing import - datatransfer test changes Changes: https://git.openjdk.org/jdk/pull/22490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344368 Stats: 166 lines in 2 files changed: 63 ins; 31 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/22490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22490/head:pull/22490 PR: https://git.openjdk.org/jdk/pull/22490 From honkar at openjdk.org Mon Dec 2 17:20:39 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Dec 2024 17:20:39 GMT Subject: RFR: 8343418: Unnecessary Hashtable usage in CSS.htmlAttrToCssAttrMap [v4] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 20:28:55 GMT, Andrey Turbanov wrote: >> If a thread-safe implementation is not needed, it is recommended to use HashMap instead of legacy synchronized Hashtable. >> Map `CSS.htmlAttrToCssAttrMap` is modified only within static initialization block and then only `get` method is called. >> >> The only subtle difference is that Hashtable doesn't allow `null` keys and throws NPE from `get` method. >> I've checked all possible keys which are passed to `htmlAttrToCssAttrMap.get`. >> Currently 3 different execution paths are possible: >> >> **1,2** >> When `HTML.Attribute.BORDER` is passed as a key. It's definitely non-null. >> >> javax.swing.text.html.CSS#translateHTMLToCSS >> translateAttribute(HTML.Attribute.BORDER, "1", cssAttrSet); >> CSS.Attribute[] cssAttrList = getCssAttribute(key); >> >> >> javax.swing.text.html.CSS#translateAttributes >> translateAttribute(HTML.Attribute.BORDER, Integer.toString(borderWidth), cssAttrSet); >> CSS.Attribute[] cssAttrList = getCssAttribute(key);` >> >> >> **3** >> When non-null `key` is passed as a key. >> >> javax.swing.text.html.CSS#translateAttributes >> >> if (name instanceof HTML.Attribute) { // from this `instanceof` we know that it's non-null >> HTML.Attribute key = (HTML.Attribute)name; >> >> translateAttribute(key, (String) htmlAttrSet.getAttribute(key), cssAttrSet); >> CSS.Attribute[] cssAttrList = getCssAttribute(key); >> >> >> ![idea_analyze_dataflow_to_here](https://github.com/user-attachments/assets/48ace4de-6d0a-468e-bb14-b579a193254b) >> >> >> I've used HashMap.newHashMap method instead of constructor to avoid resizing of internal HashMap array. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8343418: align more Marked as reviewed by honkar (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21785#pullrequestreview-2473389039 From honkar at openjdk.org Mon Dec 2 17:20:40 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Mon, 2 Dec 2024 17:20:40 GMT Subject: RFR: 8343418: Unnecessary Hashtable usage in CSS.htmlAttrToCssAttrMap [v3] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 19:17:39 GMT, Andrey Turbanov wrote: > Replaced to use immutable Map. It fits even better because it has the same null handling as Hashtable - it throw NPE in get/containsKey methods. Replacement with immutable Map sounds reasonable in the given context. LGTM ------------- PR Comment: https://git.openjdk.org/jdk/pull/21785#issuecomment-2512207938 From duke at openjdk.org Mon Dec 2 17:26:00 2024 From: duke at openjdk.org (ScientificWare) Date: Mon, 2 Dec 2024 17:26:00 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v8] In-Reply-To: References: Message-ID: > This is referenced in Java Bug Database as > - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731) > > This is tracked in JBS as > - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731) > > According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input) > > `alt` is not an attribute of the `input` element. > > According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : > >> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ... > > This feature is not implemented in `FormView.java`. > > ?? ~~This also affects the HTML 32 DTD~~ > > ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138) > > Left before the patch and right after the patch. > > > import java.awt.BorderLayout; > import java.awt.Dimension; > import javax.swing.JEditorPane; > import javax.swing.JFrame; > import javax.swing.JScrollPane; > import javax.swing.SwingUtilities; > import javax.swing.text.Document; > import javax.swing.text.html.HTMLEditorKit; > import javax.swing.text.html.StyleSheet; > > public class HTMLAddsSupportAltInputTag { > public static void main(String[] args) { > new HTMLAddsSupportAltInputTag(); > } > > public HTMLAddsSupportAltInputTag() { > SwingUtilities.invokeLater(new Runnable(){ > public void run(){ > JEditorPane jEditorPane = new JEditorPane(); > jEditorPane.setEditable(false); > JScrollPane scrollPane = new JScrollPane(jEditorPane); > HTMLEditorKit kit = new HTMLEditorKit(); > jEditorPane.setEditorKit(kit); > StyleSheet styleSheet = kit.getStyleSheet(); > styleSheet.addRule(""" > body { > color: #000; > font-family:times; > margin: 4px; > } > """); > String htmlString = """ > > > >

> >

>> > 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 > - Removes files > > make/javac.20231014_162919.args > make/javac.20231014_220237.args > make/javac.20231023_221655.args > - Adds a regression test for JDK-8314731. > - Others changes in the working directory. > - Merge Master > - Merge master > - ... and 10 more: https://git.openjdk.org/jdk/compare/352201dd...de644539 Changes requested by prr (Reviewer). src/java.desktop/share/classes/javax/swing/text/html/FormView.java line 196: > 194: AttributeSet attr = getElement().getAttributes(); > 195: HTML.Tag t = (HTML.Tag) > 196: attr.getAttribute(StyleConstants.NameAttribute); This PR has LOTS of completely unrelated changing to formatting. Please revert ALL of it, so we can see what is related to the change and not be distracted. test/jdk/javax/swing/text/html/bug8314731.java line 28: > 26: * @bug 8314731 > 27: * @summary FormView doesn't support the alt attribute > 28: * @library /java/swing/text/html What is this library ? I don't see it anywhere under the test/jdk folder. And there's no @build tag. Furthermore, this test clearly needs a display which means it needs to be marked @headful test/jdk/javax/swing/text/html/bug8314731.java line 51: > 49: > 50: public static void main(String[] args) throws Exception { > 51: new bug8314731(); the UI needs to be created on the EDT using SwingUtilities.invokeAndWait. And you need use a finally block to be SURE the Frame is disposed, else the test will just sit there. Please make sure you have used jtreg to validate this test. test/jdk/javax/swing/text/html/bug8314731.java line 53: > 51: new bug8314731(); > 52: if (testFailed) { > 53: System.out.println("ok"); I find this backwards - and hence confusing. You really mean "testPassed" not "testFailed". test/jdk/javax/swing/text/html/bug8314731.java line 80: > 78: 79: name=point > 80: src="file:logo.jpeg" and of course you don't need to supply logo.jpeg, because the point is that there should be no image found. ------------- PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-2476851661 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1868431626 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1868428214 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1868430794 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1868428906 PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1868429679 From abhiscxk at openjdk.org Wed Dec 4 04:14:38 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 4 Dec 2024 04:14:38 GMT Subject: RFR: 8345357: test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 07:19:43 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in OCI system citing > > > Radio Button Group Go To Next Component through Tab Key failed > ----------System.err:(30/2118)---------- > java.lang.reflect.InvocationTargetException > at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371) > at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346) > at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480) > at bug8033699.runTest1(bug8033699.java:163) > at bug8033699.main(bug8033699.java:71) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:573) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1575) > Caused by: java.lang.RuntimeException: Focus is not on Radio Button Single as Expected > > > in runTest1, the first subtest which seems to suggest test started before the frame is visible..Added a standard delay after frame visibility..Also added a token delay inbetween 8 subtests so that keypress(es) are not coming in one after other.. > Test passed in CI in several OCI systems.. Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22509#pullrequestreview-2477246915 From abhiscxk at openjdk.org Wed Dec 4 04:24:40 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 4 Dec 2024 04:24:40 GMT Subject: RFR: 8345357: test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 07:19:43 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in OCI system citing > > > Radio Button Group Go To Next Component through Tab Key failed > ----------System.err:(30/2118)---------- > java.lang.reflect.InvocationTargetException > at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371) > at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346) > at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480) > at bug8033699.runTest1(bug8033699.java:163) > at bug8033699.main(bug8033699.java:71) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:573) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1575) > Caused by: java.lang.RuntimeException: Focus is not on Radio Button Single as Expected > > > in runTest1, the first subtest which seems to suggest test started before the frame is visible..Added a standard delay after frame visibility..Also added a token delay inbetween 8 subtests so that keypress(es) are not coming in one after other.. > Test passed in CI in several OCI systems.. @prsadhuk Looks good to me, more like a stabilization fix. You may add CI testing link in JBS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22509#issuecomment-2516155144 From psadhukhan at openjdk.org Wed Dec 4 04:31:41 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 04:31:41 GMT Subject: Integrated: 8345357: test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 07:19:43 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in OCI system citing > > > Radio Button Group Go To Next Component through Tab Key failed > ----------System.err:(30/2118)---------- > java.lang.reflect.InvocationTargetException > at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1371) > at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1346) > at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480) > at bug8033699.runTest1(bug8033699.java:163) > at bug8033699.main(bug8033699.java:71) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:573) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1575) > Caused by: java.lang.RuntimeException: Focus is not on Radio Button Single as Expected > > > in runTest1, the first subtest which seems to suggest test started before the frame is visible..Added a standard delay after frame visibility..Also added a token delay inbetween 8 subtests so that keypress(es) are not coming in one after other.. > Test passed in CI in several OCI systems.. This pull request has now been integrated. Changeset: 521ed72b Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/521ed72b87d0fb1def6d94485e08be22632deef0 Stats: 18 lines in 1 file changed: 12 ins; 3 del; 3 mod 8345357: test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java fails in ubuntu22.04 Reviewed-by: abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/22509 From psadhukhan at openjdk.org Wed Dec 4 05:27:37 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 05:27:37 GMT Subject: RFR: 8343224: print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4 [v3] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 09:26:21 GMT, GennadiyKrivoshein wrote: >> Fix for https://bugs.openjdk.org/browse/JDK-8343224, print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4. >> >> **Reason of the bug:** >> The reason for the regression bug is a missed check for the standard media existence during CustomMediaSizeName creation. >> After the JDK-7001133 new MediaSize is created, regardless of whether a standard media size exists. >> >> For example, if a printer's PPD has two media with the same size, close to "iso_A4," with a small difference. >> *PaperDimension A4/A4: "595 842" >> *PaperDimension BrA4_B/A4 (Borderless): "595 842" >> After processing the first line, the MediaSize will contain the new size "A4" because of the missed check, and CustomMediaSize will match the "iso_a4" standard media size. >> After processing the second line, the MediaSize will contain the new size "BrA4_B", and CustomMediaSize will match not the "iso_a4" but the previously added "A4", because it was added by mistake and its size is exactly the same as "BrA4_B". >> >> **Fix description:** >> Create new MediaSize if there is no any other MediaSize with the same size. >> >> **Tests:** >> OS: MacOS 12, Linux Ubuntu 22, Windows 11. >> open/test/jdk/java/awt/print/Dialog/PaperSizeError.java >> test/jdk/javax/print/CustomMediaSizeNameOOMETest.java >> All tests from the test/jdk/javax/print/ > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > update test tag Marked as reviewed by psadhukhan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22429#pullrequestreview-2477320467 From psadhukhan at openjdk.org Wed Dec 4 07:10:12 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 07:10:12 GMT Subject: RFR: 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04 Message-ID: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in OCI system citing Caused by: java.lang.RuntimeException: setFloating does not work correctly at bug4529206.lambda$main$3(bug4529206.java:90) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308) which suggests that the focus is not shifted from main frame to toolbar.. Added a stability waitForIdle and test passed in several OCI systems ------------- Commit messages: - test fix Changes: https://git.openjdk.org/jdk/pull/22536/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22536&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345447 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22536/head:pull/22536 PR: https://git.openjdk.org/jdk/pull/22536 From psadhukhan at openjdk.org Wed Dec 4 09:24:15 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 09:24:15 GMT Subject: RFR: 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 Message-ID: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> Test is failing in OCI system citing java.lang.Error: The scrollbar block increment is incorect at bug4865918.main(bug4865918.java:68) seemingly because focus is not in scrollbar..Added stability delay to make test execution wait after frame visibility and made frame to center of screen. Test passed in several OCI systems with this modification... ------------- Commit messages: - 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 Changes: https://git.openjdk.org/jdk/pull/22540/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22540&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345468 Stats: 28 lines in 1 file changed: 7 ins; 12 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22540/head:pull/22540 PR: https://git.openjdk.org/jdk/pull/22540 From abhiscxk at openjdk.org Wed Dec 4 13:26:43 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 4 Dec 2024 13:26:43 GMT Subject: RFR: 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 In-Reply-To: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> References: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> Message-ID: On Wed, 4 Dec 2024 09:18:51 GMT, Prasanta Sadhukhan wrote: > Test is failing in OCI system citing > > java.lang.Error: The scrollbar block increment is incorect > at bug4865918.main(bug4865918.java:68) > > seemingly because focus is not in scrollbar..Added stability delay to make test execution wait after frame visibility and made frame to center of screen. > Test passed in several OCI systems with this modification... test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 1: > 1: /* L72 - L77 can be changed to use lambda expression.. `SwingUtilities.invokeAndWait(() -> result[0] = sbar.getValue());` test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 59: > 57: robot.delay(200); > 58: > 59: int value = getValue(); `getValue()` can be evaluated in if condition directly, no need to have `value` variable. typo in incorrect throw new Error("The scrollbar block increment is `incorrect`"); may be changed to RTE instead of Error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22540#discussion_r1869489694 PR Review Comment: https://git.openjdk.org/jdk/pull/22540#discussion_r1869477006 From aivanov at openjdk.org Wed Dec 4 13:32:48 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Dec 2024 13:32:48 GMT Subject: Integrated: 8341982: Simplify JButton/bug4323121.java In-Reply-To: References: Message-ID: On Fri, 11 Oct 2024 18:20:52 GMT, Alexey Ivanov wrote: > The test `javax/swing/JButton/bug4323121.java` contains lots of unused methods. > > I removed all the unused methods by extending `MouseAdapter`. > > I use `CountDownLatch` to synchronise actions in the test. > > The test still verifies `button.getModel().isArmed()` doesn't always return `true` for classes which extend `JButton`. I verified the updated test fails in 1.3.0 and passes in 1.4.0, so the test still reproduces the original problem. This pull request has now been integrated. Changeset: 6fa5cea9 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/6fa5cea984c31fbb74b39e1eec68daffea22ca92 Stats: 85 lines in 1 file changed: 24 ins; 40 del; 21 mod 8341982: Simplify JButton/bug4323121.java Reviewed-by: abhiscxk, honkar, dnguyen, achung ------------- PR: https://git.openjdk.org/jdk/pull/21475 From abhiscxk at openjdk.org Wed Dec 4 13:36:38 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 4 Dec 2024 13:36:38 GMT Subject: RFR: 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 07:04:58 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in OCI system citing > > Caused by: java.lang.RuntimeException: setFloating does not work correctly > at bug4529206.lambda$main$3(bug4529206.java:90) > at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308) > > which suggests that the focus is not shifted from main frame to toolbar.. > Added a stability waitForIdle and test passed in several OCI systems test/jdk/javax/swing/JToolBar/4529206/bug4529206.java line 1: > 1: /* Since you are modifying this test, couple of suggestions: 1. Please limit L67 to 80 cols. 2. I guess L91 and L92 can be merged, it's slightly over 80 cols but should be ok. If not then may be split like throw new RuntimeException("setFloating" + "does not work correctly"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22536#discussion_r1869508259 From psadhukhan at openjdk.org Wed Dec 4 13:47:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 13:47:24 GMT Subject: RFR: 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 [v2] In-Reply-To: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> References: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> Message-ID: <_BdiqNmVJuM7BJFOrf0HCl2eopRmnw-5tvbR1F2G0vo=.cb9c9ca3-057a-43c0-be61-f63f2e43d3c7@github.com> > Test is failing in OCI system citing > > java.lang.Error: The scrollbar block increment is incorect > at bug4865918.main(bug4865918.java:68) > > seemingly because focus is not in scrollbar..Added stability delay to make test execution wait after frame visibility and made frame to center of screen. > Test passed in several OCI systems with this modification... Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22540/files - new: https://git.openjdk.org/jdk/pull/22540/files/9455cfb0..1423bb75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22540&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22540&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22540/head:pull/22540 PR: https://git.openjdk.org/jdk/pull/22540 From psadhukhan at openjdk.org Wed Dec 4 13:47:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 13:47:24 GMT Subject: RFR: 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 [v2] In-Reply-To: References: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> Message-ID: <9_PvXGwqhrIIPjd-cZl6U3SA6SNA2mHcFGt1yuqezhY=.aee26677-54bc-48d0-a099-39361df7e12f@github.com> On Wed, 4 Dec 2024 13:17:14 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java line 59: > >> 57: robot.delay(200); >> 58: >> 59: int value = getValue(); > > `getValue()` can be evaluated in if condition directly, no need to have `value` variable. > > typo in incorrect > throw new Error("The scrollbar block increment is `incorrect`"); > > may be changed to RTE instead of Error. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22540#discussion_r1869530570 From aivanov at openjdk.org Wed Dec 4 13:47:42 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Dec 2024 13:47:42 GMT Subject: RFR: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:08:54 GMT, Andrey Turbanov wrote: > `Properties` doesn't allow `null` values. > We can replace containsKey+getProperty with getProperty+null check. > It's clearer and a bit faster. Anyway, it looks good to me. Messing around with `final` doesn't bring much value. However, it may make the code look more consistent. src/java.desktop/share/classes/java/awt/Cursor.java line 300: > 298: loadSystemCustomCursorProperties(); > 299: > 300: String prefix = CURSOR_DOT_PREFIX + name; I'd mark `prefix` as `final`, it's used throughout the method, which highlights the inconsistency in applying `final`. src/java.desktop/share/classes/java/awt/Cursor.java line 301: > 299: > 300: String prefix = CURSOR_DOT_PREFIX + name; > 301: String key = prefix + DOT_FILE_SUFFIX; After you removed `containsKey(key)`, `key` is used only once, and `prefix + DOT_FILE_SUFFIX` can be inline in the call to `systemCustomCursorProperties.getProperty` to get the file name. This would align with other usages of `prefix` in the method. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21824#pullrequestreview-2478650911 PR Review Comment: https://git.openjdk.org/jdk/pull/21824#discussion_r1869526952 PR Review Comment: https://git.openjdk.org/jdk/pull/21824#discussion_r1869519299 From aivanov at openjdk.org Wed Dec 4 13:47:43 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Dec 2024 13:47:43 GMT Subject: RFR: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor In-Reply-To: References: Message-ID: <7_TtV-XPXM9keWIqNqeVRIUILeOGsbA5xbpcCFSrUjE=.76b2bf92-0560-4051-aba4-43d3ff5de39a@github.com> On Tue, 3 Dec 2024 18:02:45 GMT, Andrey Turbanov wrote: >> src/java.desktop/share/classes/java/awt/Cursor.java line 303: >> >>> 301: String key = prefix + DOT_FILE_SUFFIX; >>> 302: >>> 303: String fileName = systemCustomCursorProperties.getProperty(key); >> >> You can keep the `final` modifier, probably. > > I really like how this line now fits in 80 characters limit. But if you insist - I will return it. That's what I thought. At the same time, it's only two columns longer than 80 chars a line. The usage of `final` modifiers seems inconsistent in the method. Maybe remove `final` from `localized` too? Then there would be no `final` modifiers till `hotPoint`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21824#discussion_r1869522599 From psadhukhan at openjdk.org Wed Dec 4 13:53:12 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 13:53:12 GMT Subject: RFR: 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04 [v2] In-Reply-To: References: Message-ID: <2O7GGuLK_QsL5geKbfkcVlO0XI_AwPm2a28ehyq-vy0=.2d94cdfa-e4c4-453f-9a61-afc80dbadeea@github.com> > test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in OCI system citing > > Caused by: java.lang.RuntimeException: setFloating does not work correctly > at bug4529206.lambda$main$3(bug4529206.java:90) > at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308) > > which suggests that the focus is not shifted from main frame to toolbar.. > Added a stability waitForIdle and test passed in several OCI systems Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22536/files - new: https://git.openjdk.org/jdk/pull/22536/files/80858d0b..7fec9941 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22536&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22536&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22536.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22536/head:pull/22536 PR: https://git.openjdk.org/jdk/pull/22536 From psadhukhan at openjdk.org Wed Dec 4 13:53:12 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 13:53:12 GMT Subject: RFR: 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 13:33:56 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > test/jdk/javax/swing/JToolBar/4529206/bug4529206.java line 1: > >> 1: /* > > Since you are modifying this test, couple of suggestions: > > 1. Please limit L67 to 80 cols. > 2. I guess L91 and L92 can be merged, it's slightly over 80 cols but should be ok. If not then may be split like > throw new RuntimeException("setFloating" + > "does not work correctly"); ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22536#discussion_r1869553180 From aturbanov at openjdk.org Wed Dec 4 14:51:14 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 4 Dec 2024 14:51:14 GMT Subject: RFR: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor [v2] In-Reply-To: References: Message-ID: > `Properties` doesn't allow `null` values. > We can replace containsKey+getProperty with getProperty+null check. > It's clearer and a bit faster. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: inline 'key' remove 'final' from 'localized' too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21824/files - new: https://git.openjdk.org/jdk/pull/21824/files/36553550..5fcd5339 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21824&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21824&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21824.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21824/head:pull/21824 PR: https://git.openjdk.org/jdk/pull/21824 From aturbanov at openjdk.org Wed Dec 4 14:51:14 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 4 Dec 2024 14:51:14 GMT Subject: RFR: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor [v2] In-Reply-To: <7_TtV-XPXM9keWIqNqeVRIUILeOGsbA5xbpcCFSrUjE=.76b2bf92-0560-4051-aba4-43d3ff5de39a@github.com> References: <7_TtV-XPXM9keWIqNqeVRIUILeOGsbA5xbpcCFSrUjE=.76b2bf92-0560-4051-aba4-43d3ff5de39a@github.com> Message-ID: On Wed, 4 Dec 2024 13:42:09 GMT, Alexey Ivanov wrote: >> I really like how this line now fits in 80 characters limit. But if you insist - I will return it. > > That's what I thought. At the same time, it's only two columns longer than 80 chars a line. > > The usage of `final` modifiers seems inconsistent in the method. Maybe remove `final` from `localized` too? Then there would be no `final` modifiers till `hotPoint`. Remove more `final`s. Code _feels_ cleaner without them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21824#discussion_r1869676986 From abhiscxk at openjdk.org Wed Dec 4 15:23:43 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 4 Dec 2024 15:23:43 GMT Subject: RFR: 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 [v2] In-Reply-To: <_BdiqNmVJuM7BJFOrf0HCl2eopRmnw-5tvbR1F2G0vo=.cb9c9ca3-057a-43c0-be61-f63f2e43d3c7@github.com> References: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> <_BdiqNmVJuM7BJFOrf0HCl2eopRmnw-5tvbR1F2G0vo=.cb9c9ca3-057a-43c0-be61-f63f2e43d3c7@github.com> Message-ID: On Wed, 4 Dec 2024 13:47:24 GMT, Prasanta Sadhukhan wrote: >> Test is failing in OCI system citing >> >> java.lang.Error: The scrollbar block increment is incorect >> at bug4865918.main(bug4865918.java:68) >> >> seemingly because focus is not in scrollbar..Added stability delay to make test execution wait after frame visibility and made frame to center of screen. >> Test passed in several OCI systems with this modification... > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > review LGTM. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22540#pullrequestreview-2479075340 From abhiscxk at openjdk.org Wed Dec 4 15:31:41 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 4 Dec 2024 15:31:41 GMT Subject: RFR: 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04 [v2] In-Reply-To: <2O7GGuLK_QsL5geKbfkcVlO0XI_AwPm2a28ehyq-vy0=.2d94cdfa-e4c4-453f-9a61-afc80dbadeea@github.com> References: <2O7GGuLK_QsL5geKbfkcVlO0XI_AwPm2a28ehyq-vy0=.2d94cdfa-e4c4-453f-9a61-afc80dbadeea@github.com> Message-ID: On Wed, 4 Dec 2024 13:53:12 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in OCI system citing >> >> Caused by: java.lang.RuntimeException: setFloating does not work correctly >> at bug4529206.lambda$main$3(bug4529206.java:90) >> at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308) >> >> which suggests that the focus is not shifted from main frame to toolbar.. >> Added a stability waitForIdle and test passed in several OCI systems > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > review Update test look good to me. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22536#pullrequestreview-2479102698 From psadhukhan at openjdk.org Wed Dec 4 15:36:52 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 15:36:52 GMT Subject: Integrated: 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 In-Reply-To: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> References: <6BmRbTaFgYiu9vEWljaihmOFiKBAtIKKVfDJTp4tluI=.cb5e76c3-a8bc-4fd9-9855-a2142d106897@github.com> Message-ID: On Wed, 4 Dec 2024 09:18:51 GMT, Prasanta Sadhukhan wrote: > Test is failing in OCI system citing > > java.lang.Error: The scrollbar block increment is incorect > at bug4865918.main(bug4865918.java:68) > > seemingly because focus is not in scrollbar..Added stability delay to make test execution wait after frame visibility and made frame to center of screen. > Test passed in several OCI systems with this modification... This pull request has now been integrated. Changeset: 6f307623 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/6f307623568efe4d90942cd22ec9a26b2e1ca1b1 Stats: 37 lines in 1 file changed: 7 ins; 17 del; 13 mod 8345468: test/jdk/javax/swing/JScrollBar/4865918/bug4865918.java fails in ubuntu22.04 Reviewed-by: abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/22540 From psadhukhan at openjdk.org Wed Dec 4 15:40:45 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 4 Dec 2024 15:40:45 GMT Subject: Integrated: 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 07:04:58 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in OCI system citing > > Caused by: java.lang.RuntimeException: setFloating does not work correctly > at bug4529206.lambda$main$3(bug4529206.java:90) > at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308) > > which suggests that the focus is not shifted from main frame to toolbar.. > Added a stability waitForIdle and test passed in several OCI systems This pull request has now been integrated. Changeset: 923321cf Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/923321cfb1a9c66ca0e8f843ff029fd161a19b5b Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04 Reviewed-by: abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/22536 From aivanov at openjdk.org Wed Dec 4 15:45:56 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Dec 2024 15:45:56 GMT Subject: RFR: 8340580: Characters in Document diagrams not in the middle Message-ID: This is a continuation to #20376, it moves the text in `Document-{insert,remove}.svg` down by 0.5 pixel. This change makes the text centred in the boxes. Here are quotes from https://github.com/openjdk/jdk/pull/20376#issuecomment-2353728939 and https://github.com/openjdk/jdk/pull/20376#issuecomment-2353743533: > At 200% scale and Arial font, there are 6 pixels on top of ?T? and ?h?, but there are 8 pixels on the bottom of ?q?. > > Moving the text position by 0.5 seems to help, and the values become equal: 7 on either side. ------------- Commit messages: - 8340580: Characters in Document diagrams not in the middle Changes: https://git.openjdk.org/jdk/pull/22549/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22549&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340580 Stats: 39 lines in 2 files changed: 0 ins; 0 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/22549.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22549/head:pull/22549 PR: https://git.openjdk.org/jdk/pull/22549 From azvegint at openjdk.org Wed Dec 4 15:55:39 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 4 Dec 2024 15:55:39 GMT Subject: RFR: 8340580: Characters in Document diagrams not in the middle In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 15:40:31 GMT, Alexey Ivanov wrote: > This is a continuation to #20376, it moves the text in `Document-{insert,remove}.svg` down by 0.5 pixel. > > This change makes the text centred in the boxes. > > Here are quotes from https://github.com/openjdk/jdk/pull/20376#issuecomment-2353728939 and https://github.com/openjdk/jdk/pull/20376#issuecomment-2353743533: > >> At 200% scale and Arial font, there are 6 pixels on top of ?T? and ?h?, but there are 8 pixels on the bottom of ?q?. >> >> Moving the text position by 0.5 seems to help, and the values become equal: 7 on either side. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22549#pullrequestreview-2479176022 From duke at openjdk.org Wed Dec 4 16:34:42 2024 From: duke at openjdk.org (duke) Date: Wed, 4 Dec 2024 16:34:42 GMT Subject: RFR: 8343224: print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4 [v3] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 09:26:21 GMT, GennadiyKrivoshein wrote: >> Fix for https://bugs.openjdk.org/browse/JDK-8343224, print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4. >> >> **Reason of the bug:** >> The reason for the regression bug is a missed check for the standard media existence during CustomMediaSizeName creation. >> After the JDK-7001133 new MediaSize is created, regardless of whether a standard media size exists. >> >> For example, if a printer's PPD has two media with the same size, close to "iso_A4," with a small difference. >> *PaperDimension A4/A4: "595 842" >> *PaperDimension BrA4_B/A4 (Borderless): "595 842" >> After processing the first line, the MediaSize will contain the new size "A4" because of the missed check, and CustomMediaSize will match the "iso_a4" standard media size. >> After processing the second line, the MediaSize will contain the new size "BrA4_B", and CustomMediaSize will match not the "iso_a4" but the previously added "A4", because it was added by mistake and its size is exactly the same as "BrA4_B". >> >> **Fix description:** >> Create new MediaSize if there is no any other MediaSize with the same size. >> >> **Tests:** >> OS: MacOS 12, Linux Ubuntu 22, Windows 11. >> open/test/jdk/java/awt/print/Dialog/PaperSizeError.java >> test/jdk/javax/print/CustomMediaSizeNameOOMETest.java >> All tests from the test/jdk/javax/print/ > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > update test tag @GennadiyKrivoshein Your change (at version e31e61613b3ec526053ad92a4148d3f856812872) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22429#issuecomment-2517962248 From kizune at openjdk.org Wed Dec 4 17:12:43 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 4 Dec 2024 17:12:43 GMT Subject: RFR: 8340580: Characters in Document diagrams not in the middle In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 15:40:31 GMT, Alexey Ivanov wrote: > This is a continuation to #20376, it moves the text in `Document-{insert,remove}.svg` down by 0.5 pixel. > > This change makes the text centred in the boxes. > > Here are quotes from https://github.com/openjdk/jdk/pull/20376#issuecomment-2353728939 and https://github.com/openjdk/jdk/pull/20376#issuecomment-2353743533: > >> At 200% scale and Arial font, there are 6 pixels on top of ?T? and ?h?, but there are 8 pixels on the bottom of ?q?. >> >> Moving the text position by 0.5 seems to help, and the values become equal: 7 on either side. Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22549#pullrequestreview-2479385099 From prr at openjdk.org Wed Dec 4 18:50:48 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Dec 2024 18:50:48 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. Thanks for the suggestion, but it isn't a path I want to go. The patch is still fine as it is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2518266042 From aivanov at openjdk.org Wed Dec 4 19:00:58 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Dec 2024 19:00:58 GMT Subject: Integrated: 8340580: Characters in Document diagrams not in the middle In-Reply-To: References: Message-ID: <54ZyVTmDWDtqrNN2gPFsMon4Pvv5WeYc-AcczcydO6c=.371ee1cf-f327-4bad-a65e-db26a8aad527@github.com> On Wed, 4 Dec 2024 15:40:31 GMT, Alexey Ivanov wrote: > This is a continuation to #20376, it moves the text in `Document-{insert,remove}.svg` down by 0.5 pixel. > > This change makes the text centred in the boxes. > > Here are quotes from https://github.com/openjdk/jdk/pull/20376#issuecomment-2353728939 and https://github.com/openjdk/jdk/pull/20376#issuecomment-2353743533: > >> At 200% scale and Arial font, there are 6 pixels on top of ?T? and ?h?, but there are 8 pixels on the bottom of ?q?. >> >> Moving the text position by 0.5 seems to help, and the values become equal: 7 on either side. This pull request has now been integrated. Changeset: faa109e8 Author: Alexey Ivanov URL: https://git.openjdk.org/jdk/commit/faa109e8d40dbe8c6beb26bd8f9e5f6f63e4cab1 Stats: 39 lines in 2 files changed: 0 ins; 0 del; 39 mod 8340580: Characters in Document diagrams not in the middle Move text in Document-{insert,remove}.svg by 0.5 of pixel Reviewed-by: azvegint, kizune ------------- PR: https://git.openjdk.org/jdk/pull/22549 From prr at openjdk.org Wed Dec 4 19:16:43 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Dec 2024 19:16:43 GMT Subject: RFR: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor [v2] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 14:51:14 GMT, Andrey Turbanov wrote: >> `Properties` doesn't allow `null` values. >> We can replace containsKey+getProperty with getProperty+null check. >> It's clearer and a bit faster. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > inline 'key' > remove 'final' from 'localized' too Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21824#pullrequestreview-2479688101 From prr at openjdk.org Wed Dec 4 19:20:48 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Dec 2024 19:20:48 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: On Mon, 25 Nov 2024 22:34:46 GMT, Jeremy wrote: >> The AWTEventMulticaster is a tree node with 2 children. This PR proposes rebalancing that tree after 500 additions to avoid potential StackOverflowErrors when trying to interact with a large AWTEventMulticaster. >> >> In the original headful test: >> We added 8,000 checkboxes, and when their parent panel was hidden the stack needed to grow to 24,000 lines. It took 8,000 lines to recursively call `java.awt.AWTEventMulticaster.componentHidden`, and then 16,000 additional lines to call two recursive methods to remove a listener: >> >> java.desktop/java.awt.AWTEventMulticaster.removeInternal() >> java.desktop/java.awt.AWTEventMulticaster.remove() >> >> >> With this current PR the max stack size reaches 1,267 instead. (If we rebalanced at EVERY addition, then that same scenario would reach a max stack size of 71.) >> >> JDK-8342782 included a headful test case, but I think the main problem it demonstrated can be represented by the headless test case attached to this PR. >> >> Depending on how this PR is received I may submit a separate ticket & PR to modify AquaButtonUI so it doesn't always attach an AncestorListener. (That is: if my GUI includes 8,000 checkboxes then I don't need 8,000 AncestorListeners.) But JDK-8342782's test case is currently written in a way that should reproduce across all L&F's, so that can be discussed separately. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8342782: expanding wildcard imports > > This is in response to: > https://github.com/openjdk/jdk/pull/21962#discussion_r1857389973 @azvegint @honkar-jdk @prsadhuk @TejeshR13 could one of you be the 2nd reviewer for this please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21962#issuecomment-2518355626 From prr at openjdk.org Wed Dec 4 19:21:44 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Dec 2024 19:21:44 GMT Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does not work on macOS [v4] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 07:28:25 GMT, GennadiyKrivoshein wrote: >> This update allows users to print with grayscale using color printers. >> Actually, it is not possible to use the "Monochrome" option from the "Color Appearance" panel. Also Chromaticity.MONOCHROME can't be used to print grayscale on color printers ([JDK-8315113](https://bugs.openjdk.org/browse/JDK-8315113)). >> >> **Fix description** >> When a printer supports color printing and a user adds Chromaticity.MONOCHROME attribute to a PrintRequestAttributeSet, then the final printing raster is transformed to the grayscale color using java.awt.image.ColorConvertOp. When the job is a PostScript job, then the "setColor" and "setPaint" methods of the Graphics are overridden, and user colors (paints) are transformed to the grayscale form using the new proxy class GrayscaleProxyGraphics2D. >> >> This approach is assumed to be platform, CUPS, and IPP protocol independent. >> >> **Tests** >> The fix was tested on Ubuntu 22.04 and MacOS 12.6.1. > > GennadiyKrivoshein 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 remote-tracking branch 'openjdk/master' into monochrome-printing > > # Conflicts: > # src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > - Merge remote-tracking branch 'openjdk/master' into monochrome-printing > - move grayscale methods to PSPathGraphics > - Update src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java > > Co-authored-by: Andrey Turbanov > - update copyright > - formatting > - grammar fixes > - 8315113: Print request Chromaticity.MONOCHROME attribute does not work on macOS @prsadhuk please look at this ------------- PR Comment: https://git.openjdk.org/jdk/pull/21930#issuecomment-2518357989 From prr at openjdk.org Wed Dec 4 19:22:45 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Dec 2024 19:22:45 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 00:20:36 GMT, Daniel Gredler wrote: > When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). > > Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. @azvegint @TejeshR13 @prsadhuk @honkar-jdk - this needs a 2nd reviewer ------------- PR Comment: https://git.openjdk.org/jdk/pull/22288#issuecomment-2518359987 From prr at openjdk.org Wed Dec 4 19:25:41 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Dec 2024 19:25:41 GMT Subject: RFR: 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. @prsadhuk please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/22110#issuecomment-2518372176 From achung at openjdk.org Wed Dec 4 19:53:38 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 4 Dec 2024 19:53:38 GMT Subject: RFR: 8268145: [macos] Rendering artifacts is seen when text inside the JTable with TableCellEditor having JTextfield [v2] In-Reply-To: <3_vX3P2Um340Vr9HCuhLxTYCTaqntCm_bnZun72byLI=.cc945e17-981d-450b-8b55-8854ddea3804@github.com> References: <3_vX3P2Um340Vr9HCuhLxTYCTaqntCm_bnZun72byLI=.cc945e17-981d-450b-8b55-8854ddea3804@github.com> Message-ID: <2KtcPR-x1ByPR9rXUtZB-IbHMdkE1JLfiGt6C2b2PFU=.abda0049-e63c-46ef-bad3-7e5fbf68e3d9@github.com> On Thu, 28 Nov 2024 03:05:27 GMT, Prasanta Sadhukhan wrote: >> When a textfield is embedded in a TableCellEditor in a JTable in Aqua L&F and space is entered and caret moved back and forth by pressing left/right arrow button, an artifact is seen, which is basically the caret is not properly repainted leaving behind its trails. >> >> When caret is moved, it is repainted every time by "damaging" the area surrounding the caret to cause it to be repainted in a new location. AquaCaret overrides the default "damage" code to intersect the caret area with the border insets so that it does not damage the AquaBorder area.. >> For TextField case, AquaTextFieldBorder insets is removed from AquaTextField and then intersected with AquaCaret to get the dirry region which is then repainted, so as to not damage the border but it is done irrespective of whether border is shown or not, so proper dirty region is not repainted leaving behind artifacts when the caret is moved around... >> >> Fix is to see if border to be painted is not opaque in which case the proper dirty region is calculated which is then used in repaint logic to repaint the component.. > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test fix test/jdk/javax/swing/JTable/TestCaretArtifact.java line 51: > 49: If artifact is seen, press Fail else press Pass."""; > 50: > 51: public static void main(String[] args) throws Exception { small nitpick but I think there's an extra whitespace here after void test/jdk/javax/swing/JTable/TestCaretArtifact.java line 62: > 60: > 61: > 62: public static JFrame createUI() { extra whitespace here too ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22416#discussion_r1870194336 PR Review Comment: https://git.openjdk.org/jdk/pull/22416#discussion_r1870194570 From achung at openjdk.org Wed Dec 4 20:00:41 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 4 Dec 2024 20:00:41 GMT Subject: RFR: 8343224: print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4 [v3] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 09:26:21 GMT, GennadiyKrivoshein wrote: >> Fix for https://bugs.openjdk.org/browse/JDK-8343224, print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4. >> >> **Reason of the bug:** >> The reason for the regression bug is a missed check for the standard media existence during CustomMediaSizeName creation. >> After the JDK-7001133 new MediaSize is created, regardless of whether a standard media size exists. >> >> For example, if a printer's PPD has two media with the same size, close to "iso_A4," with a small difference. >> *PaperDimension A4/A4: "595 842" >> *PaperDimension BrA4_B/A4 (Borderless): "595 842" >> After processing the first line, the MediaSize will contain the new size "A4" because of the missed check, and CustomMediaSize will match the "iso_a4" standard media size. >> After processing the second line, the MediaSize will contain the new size "BrA4_B", and CustomMediaSize will match not the "iso_a4" but the previously added "A4", because it was added by mistake and its size is exactly the same as "BrA4_B". >> >> **Fix description:** >> Create new MediaSize if there is no any other MediaSize with the same size. >> >> **Tests:** >> OS: MacOS 12, Linux Ubuntu 22, Windows 11. >> open/test/jdk/java/awt/print/Dialog/PaperSizeError.java >> test/jdk/javax/print/CustomMediaSizeNameOOMETest.java >> All tests from the test/jdk/javax/print/ > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > update test tag test/jdk/java/awt/print/Dialog/PaperSizeError.java line 23: > 21: * questions. > 22: */ > 23: could you expand wildcard imports on this test and update copyright year? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22429#discussion_r1870202797 From aivanov at openjdk.org Wed Dec 4 20:07:43 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 4 Dec 2024 20:07:43 GMT Subject: RFR: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor [v2] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 14:51:14 GMT, Andrey Turbanov wrote: >> `Properties` doesn't allow `null` values. >> We can replace containsKey+getProperty with getProperty+null check. >> It's clearer and a bit faster. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > inline 'key' > remove 'final' from 'localized' too Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21824#pullrequestreview-2479792155 From duke at openjdk.org Wed Dec 4 20:38:52 2024 From: duke at openjdk.org (GennadiyKrivoshein) Date: Wed, 4 Dec 2024 20:38:52 GMT Subject: RFR: 8343224: print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4 [v4] In-Reply-To: References: Message-ID: > Fix for https://bugs.openjdk.org/browse/JDK-8343224, print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4. > > **Reason of the bug:** > The reason for the regression bug is a missed check for the standard media existence during CustomMediaSizeName creation. > After the JDK-7001133 new MediaSize is created, regardless of whether a standard media size exists. > > For example, if a printer's PPD has two media with the same size, close to "iso_A4," with a small difference. > *PaperDimension A4/A4: "595 842" > *PaperDimension BrA4_B/A4 (Borderless): "595 842" > After processing the first line, the MediaSize will contain the new size "A4" because of the missed check, and CustomMediaSize will match the "iso_a4" standard media size. > After processing the second line, the MediaSize will contain the new size "BrA4_B", and CustomMediaSize will match not the "iso_a4" but the previously added "A4", because it was added by mistake and its size is exactly the same as "BrA4_B". > > **Fix description:** > Create new MediaSize if there is no any other MediaSize with the same size. > > **Tests:** > OS: MacOS 12, Linux Ubuntu 22, Windows 11. > open/test/jdk/java/awt/print/Dialog/PaperSizeError.java > test/jdk/javax/print/CustomMediaSizeNameOOMETest.java > All tests from the test/jdk/javax/print/ GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: expand imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22429/files - new: https://git.openjdk.org/jdk/pull/22429/files/e31e6161..987131c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22429&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22429&range=02-03 Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22429/head:pull/22429 PR: https://git.openjdk.org/jdk/pull/22429 From duke at openjdk.org Wed Dec 4 20:43:40 2024 From: duke at openjdk.org (GennadiyKrivoshein) Date: Wed, 4 Dec 2024 20:43:40 GMT Subject: RFR: 8343224: print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4 [v3] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 19:57:41 GMT, Alisen Chung wrote: >> GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: >> >> update test tag > > test/jdk/java/awt/print/Dialog/PaperSizeError.java line 23: > >> 21: * questions. >> 22: */ >> 23: > > could you expand wildcard imports on this test and update copyright year? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22429#discussion_r1870251256 From honkar at openjdk.org Wed Dec 4 21:23:40 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 4 Dec 2024 21:23:40 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 00:20:36 GMT, Daniel Gredler wrote: > When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). > > Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. @gredler There is one other place where `expandArray()` is called similarly - [TextLine.getComponents()](https://github.com/openjdk/jdk/blob/bb7a66ce7b08a7f50da3194390c1d077a0b1fb81/src/java.desktop/share/classes/java/awt/font/TextLine.java#L1078C1-L1081C22). ------------- PR Review: https://git.openjdk.org/jdk/pull/22288#pullrequestreview-2479929617 From philip.race at oracle.com Wed Dec 4 21:24:58 2024 From: philip.race at oracle.com (Philip Race) Date: Wed, 4 Dec 2024 13:24:58 -0800 Subject: FYI: Draft JEP : JDK-8345525: Remove the Terminally Deprecated Applet API Message-ID: I just submitted? - in draft state - https://bugs.openjdk.org/browse/JDK-8345525 which proposes to finally remove the Applet API. -phil. From achung at openjdk.org Wed Dec 4 22:37:50 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 4 Dec 2024 22:37:50 GMT Subject: RFR: 8345144: Robot does not specify all causes of IllegalThreadStateException Message-ID: 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. ------------- Commit messages: - init commit Changes: https://git.openjdk.org/jdk/pull/22564/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22564&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345144 Stats: 32 lines in 1 file changed: 32 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22564.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22564/head:pull/22564 PR: https://git.openjdk.org/jdk/pull/22564 From prr at openjdk.org Wed Dec 4 22:57:49 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Dec 2024 22:57:49 GMT Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does not work on macOS [v4] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 07:28:25 GMT, GennadiyKrivoshein wrote: >> This update allows users to print with grayscale using color printers. >> Actually, it is not possible to use the "Monochrome" option from the "Color Appearance" panel. Also Chromaticity.MONOCHROME can't be used to print grayscale on color printers ([JDK-8315113](https://bugs.openjdk.org/browse/JDK-8315113)). >> >> **Fix description** >> When a printer supports color printing and a user adds Chromaticity.MONOCHROME attribute to a PrintRequestAttributeSet, then the final printing raster is transformed to the grayscale color using java.awt.image.ColorConvertOp. When the job is a PostScript job, then the "setColor" and "setPaint" methods of the Graphics are overridden, and user colors (paints) are transformed to the grayscale form using the new proxy class GrayscaleProxyGraphics2D. >> >> This approach is assumed to be platform, CUPS, and IPP protocol independent. >> >> **Tests** >> The fix was tested on Ubuntu 22.04 and MacOS 12.6.1. > > GennadiyKrivoshein 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 remote-tracking branch 'openjdk/master' into monochrome-printing > > # Conflicts: > # src/java.desktop/share/classes/sun/print/RasterPrinterJob.java > - Merge remote-tracking branch 'openjdk/master' into monochrome-printing > - move grayscale methods to PSPathGraphics > - Update src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java > > Co-authored-by: Andrey Turbanov > - update copyright > - formatting > - grammar fixes > - 8315113: Print request Chromaticity.MONOCHROME attribute does not work on macOS I've pointed out some issues. That does not mean these are the only issues. src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 794: > 792: BufferedImage bufferedImage = new BufferedImage((int)page.getWidth(), (int)page.getHeight(), > 793: BufferedImage.TYPE_INT_ARGB); > 794: Graphics2D g2 = bufferedImage.createGraphics(); The problem here is that the image is not at printer resolution. So it will be VERY grainy when printed. If you are doing this band printing you need to do something like what is happening in RasterPrinterJob. In fact probably defer to that. And this is definitely a "mis-use" of path graphics. On top of that I think it odd to create an image of BufferedImage.TYPE_INT_ARGB and then convert it to greyscale. Why not just create a BI of type BufferedImage.TYPE_USHORT_GRAY ? And then the conversion is done by 2D when drawing into it and there's no need to filter the image. I tested that but for whatever reason I needed to clear the image to white first. But I don't think you should be "here" if the only way you can do monochrome on mac is by printing a greyscale image. It should go to the existing code in RasterPrinterJob which will handle the resolution. It would be wrong to replicate that code here. I am not sure that code is used today in the mac printing path,. but it is the code that does what you need .. mostly. src/java.desktop/share/classes/sun/print/PSPathGraphics.java line 858: > 856: * @return grayscale BufferedImage > 857: */ > 858: private BufferedImage getGrayscaleImage(Image img) { This code is bizarre. Why not just draw to a grayscale image ? src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 2: > 1: /* > 2: * Copyright (c) 1998, 2023, Oracle and/or its affiliates. All rights reserved. Nothing changed here! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 1173: > 1171: } > 1172: > 1173: protected boolean isAttributeCategorySupported(Class category) { hmm. Not sure why this isn't private, and why it has the same name as the PrintService method which can be confusing. It has one purpose and one use which is to ask if Chromaticity is supported so it can be clearer. src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2413: > 2411: painterGraphics.dispose(); > 2412: if (monochrome) { > 2413: monochromeConverter.filter(band, band); Like I mentioned elsewhere, I think a greyscale image would mean you don't need to do this. However the code that sends the image to the printer needs a version that handles that format. Currently the Postscript code handles only BGR .. Also, this code is used on WINDOWS as well as other platforms, and monochrome is handled natively by the printer, so this looks like it is doing things that are unnecessary on that platform. ------------- Changes requested by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21930#pullrequestreview-2480062758 PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1870376113 PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1870379822 PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1870376422 PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1870385907 PR Review Comment: https://git.openjdk.org/jdk/pull/21930#discussion_r1870377584 From achung at openjdk.org Wed Dec 4 23:03:57 2024 From: achung at openjdk.org (Alisen Chung) Date: Wed, 4 Dec 2024 23:03:57 GMT Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v14] In-Reply-To: References: Message-ID: <2kMU9VE7ZdEWMrFaD1SJROeFhsHdIfHVHxow0JHGb0U=.463948af-8fdc-4ec7-a3a4-09615c3267ad@github.com> > Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot). Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: update specifications, replace default values in specifications with links to default var ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22044/files - new: https://git.openjdk.org/jdk/pull/22044/files/97e2424a..c3e5671a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=12-13 Stats: 35 lines in 1 file changed: 3 ins; 13 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/22044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044 PR: https://git.openjdk.org/jdk/pull/22044 From lbourges at openjdk.org Wed Dec 4 23:40:42 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 4 Dec 2024 23:40:42 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: On Mon, 25 Nov 2024 22:34:46 GMT, Jeremy wrote: >> The AWTEventMulticaster is a tree node with 2 children. This PR proposes rebalancing that tree after 500 additions to avoid potential StackOverflowErrors when trying to interact with a large AWTEventMulticaster. >> >> In the original headful test: >> We added 8,000 checkboxes, and when their parent panel was hidden the stack needed to grow to 24,000 lines. It took 8,000 lines to recursively call `java.awt.AWTEventMulticaster.componentHidden`, and then 16,000 additional lines to call two recursive methods to remove a listener: >> >> java.desktop/java.awt.AWTEventMulticaster.removeInternal() >> java.desktop/java.awt.AWTEventMulticaster.remove() >> >> >> With this current PR the max stack size reaches 1,267 instead. (If we rebalanced at EVERY addition, then that same scenario would reach a max stack size of 71.) >> >> JDK-8342782 included a headful test case, but I think the main problem it demonstrated can be represented by the headless test case attached to this PR. >> >> Depending on how this PR is received I may submit a separate ticket & PR to modify AquaButtonUI so it doesn't always attach an AncestorListener. (That is: if my GUI includes 8,000 checkboxes then I don't need 8,000 AncestorListeners.) But JDK-8342782's test case is currently written in a way that should reproduce across all L&F's, so that can be discussed separately. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8342782: expanding wildcard imports > > This is in response to: > https://github.com/openjdk/jdk/pull/21962#discussion_r1857389973 Marked as reviewed by lbourges (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21962#pullrequestreview-2456369033 From lbourges at openjdk.org Wed Dec 4 23:40:44 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 4 Dec 2024 23:40:44 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: On Sat, 23 Nov 2024 08:18:52 GMT, Laurent Bourg?s wrote: >> src/java.desktop/share/classes/java/awt/AWTEventMulticaster.java line 991: >> >>> 989: while (true) { >>> 990: if (++level > 500) >>> 991: return true; >> >> our coding standards require that you always include the body in { .. } > > 500 is magic number ? > I recommend using a constant explaining how this magic value has been determined empirically ? Please move comments into the code (implementation details) instead of javadoc. Do not mention '500' but say the rebalance threshold... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1855148909 From lbourges at openjdk.org Wed Dec 4 23:40:46 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 4 Dec 2024 23:40:46 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: On Sun, 24 Nov 2024 08:10:28 GMT, Jeremy wrote: >> src/java.desktop/share/classes/java/awt/AWTEventMulticaster.java line 991: >> >>> 989: while (true) { >>> 990: if (++level > 500) >>> 991: return true; >> >> our coding standards require that you always include the body in { .. } > > @prrace : I added { .. } > > @bourgesl : I'm struggling to define this as a constant in a helpful way. Is there an example of a similar constant somewhere in the codebase you could refer me to for comparison? > > I think part of my challenge here is the AWTEventMulticaster doesn't promise to be any particular kind of tree. (For example: if it promised it was a self-balancing tree, then we'd know what our obligations were to meet that expectation.) > > This PR's implementation is intended to be a fast heuristic/educated guess, but it does not scan the entire height of the left or right node. This makes it ... hard for me to name. > > (Relatedly: the value 500 is arbitrary, and I'm happy to change it if someone would rather it be closer to 50 or 1000.) Here is a constant declaration (hotspot friendly): https://github.com/bourgesl/jdk-official/blob/d0b770c938be6b5b3a0176148265ef33184a9b8b/src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java#L38 private static final int ALL_BUT_LSB = 0xFFFFFFFE; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1855397860 From lbourges at openjdk.org Wed Dec 4 23:40:46 2024 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Wed, 4 Dec 2024 23:40:46 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: <7gp-NCHUoqWy8a-UuUICrvAIYbLfRsH3vOGnos7gx_s=.f5342625-2385-44fa-8ca0-6e40496b1e27@github.com> On Sun, 24 Nov 2024 08:51:59 GMT, Laurent Bourg?s wrote: >> @prrace : I added { .. } >> >> @bourgesl : I'm struggling to define this as a constant in a helpful way. Is there an example of a similar constant somewhere in the codebase you could refer me to for comparison? >> >> I think part of my challenge here is the AWTEventMulticaster doesn't promise to be any particular kind of tree. (For example: if it promised it was a self-balancing tree, then we'd know what our obligations were to meet that expectation.) >> >> This PR's implementation is intended to be a fast heuristic/educated guess, but it does not scan the entire height of the left or right node. This makes it ... hard for me to name. >> >> (Relatedly: the value 500 is arbitrary, and I'm happy to change it if someone would rather it be closer to 50 or 1000.) > > Here is a constant declaration (hotspot friendly): > https://github.com/bourgesl/jdk-official/blob/d0b770c938be6b5b3a0176148265ef33184a9b8b/src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java#L38 > > private static final int ALL_BUT_LSB = 0xFFFFFFFE; '500 iterations' looks high, maybe 100? It is a recursion ? You could try max recursion depth + 3 samples (first, middle, last) ? Or this magic threshold could be tunable ac runtime using special static getter using a System property + default value, used by constant declaration (final static is mandatory): https://github.com/bourgesl/jdk-official/blob/d0b770c938be6b5b3a0176148265ef33184a9b8b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java#L50 https://github.com/bourgesl/jdk-official/blob/d0b770c938be6b5b3a0176148265ef33184a9b8b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java#L303 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1855398578 From psadhukhan at openjdk.org Thu Dec 5 03:14:13 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 5 Dec 2024 03:14:13 GMT Subject: RFR: 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04 Message-ID: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java tests movement of caret between word and fails in OCI citing java.lang.RuntimeException: Test failed. at bug4278839.main(bug4278839.java:92) which suggests caret is not moved as per expectation..It also seems the focus is not in the frame when the test start executing. Added robot delay and waitForIdle and it passed in several OCI systems ------------- Commit messages: - test fix Changes: https://git.openjdk.org/jdk/pull/22566/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345547 Stats: 21 lines in 1 file changed: 3 ins; 10 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22566/head:pull/22566 PR: https://git.openjdk.org/jdk/pull/22566 From abhiscxk at openjdk.org Thu Dec 5 04:18:37 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 5 Dec 2024 04:18:37 GMT Subject: RFR: 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 03:09:27 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java tests movement of caret between word and fails in OCI citing > > > java.lang.RuntimeException: Test failed. > at bug4278839.main(bug4278839.java:92) > > which suggests caret is not moved as per expectation..It also seems the focus is not in the frame when the test start executing. > Added robot delay and waitForIdle and it passed in several OCI systems test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java line 1: > 1: /* Please update copyright year. Wild imports. Remove author tag from jtreg block. L109 to L114.. can be replaced with lambda. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22566#discussion_r1870594858 From abhiscxk at openjdk.org Thu Dec 5 04:24:38 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 5 Dec 2024 04:24:38 GMT Subject: RFR: 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. Needs a CSR ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22564#issuecomment-2519062673 From psadhukhan at openjdk.org Thu Dec 5 04:26:17 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 5 Dec 2024 04:26:17 GMT Subject: RFR: 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04 [v2] In-Reply-To: References: Message-ID: > test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java tests movement of caret between word and fails in OCI citing > > > java.lang.RuntimeException: Test failed. > at bug4278839.main(bug4278839.java:92) > > which suggests caret is not moved as per expectation..It also seems the focus is not in the frame when the test start executing. > Added robot delay and waitForIdle and it passed in several OCI systems Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22566/files - new: https://git.openjdk.org/jdk/pull/22566/files/64ea23e5..aee0cdbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22566&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22566&range=00-01 Stats: 16 lines in 1 file changed: 6 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22566.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22566/head:pull/22566 PR: https://git.openjdk.org/jdk/pull/22566 From psadhukhan at openjdk.org Thu Dec 5 04:26:17 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 5 Dec 2024 04:26:17 GMT Subject: RFR: 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04 [v2] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 04:15:36 GMT, Abhishek Kumar wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java line 1: > >> 1: /* > > Please update copyright year. > Wild imports. > Remove author tag from jtreg block. > L109 to L114.. can be replaced with lambda. ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22566#discussion_r1870598713 From abhiscxk at openjdk.org Thu Dec 5 06:36:38 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Thu, 5 Dec 2024 06:36:38 GMT Subject: RFR: 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04 [v2] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 04:26:17 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java tests movement of caret between word and fails in OCI citing >> >> >> java.lang.RuntimeException: Test failed. >> at bug4278839.main(bug4278839.java:92) >> >> which suggests caret is not moved as per expectation..It also seems the focus is not in the frame when the test start executing. >> Added robot delay and waitForIdle and it passed in several OCI systems > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > review LGTM. ------------- Marked as reviewed by abhiscxk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22566#pullrequestreview-2480604031 From psadhukhan at openjdk.org Thu Dec 5 07:32:41 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 5 Dec 2024 07:32:41 GMT Subject: Integrated: 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04 In-Reply-To: References: Message-ID: <5eKz51KIeDN3VLxF6epsOeGXXT233720RhgfZVQTlDI=.59df93cf-2b3f-418f-94cb-f00504be26eb@github.com> On Thu, 5 Dec 2024 03:09:27 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java tests movement of caret between word and fails in OCI citing > > > java.lang.RuntimeException: Test failed. > at bug4278839.main(bug4278839.java:92) > > which suggests caret is not moved as per expectation..It also seems the focus is not in the frame when the test start executing. > Added robot delay and waitForIdle and it passed in several OCI systems This pull request has now been integrated. Changeset: e46d822a Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/e46d822aebee02d3cb4862c204293d388f6f3466 Stats: 37 lines in 1 file changed: 9 ins; 14 del; 14 mod 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04 Reviewed-by: abhiscxk ------------- PR: https://git.openjdk.org/jdk/pull/22566 From aturbanov at openjdk.org Thu Dec 5 09:10:51 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 5 Dec 2024 09:10:51 GMT Subject: RFR: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor [v2] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 14:51:14 GMT, Andrey Turbanov wrote: >> `Properties` doesn't allow `null` values. >> We can replace containsKey+getProperty with getProperty+null check. >> It's clearer and a bit faster. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > inline 'key' > remove 'final' from 'localized' too Thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21824#issuecomment-2519687285 From aturbanov at openjdk.org Thu Dec 5 09:10:52 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 5 Dec 2024 09:10:52 GMT Subject: Integrated: 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:08:54 GMT, Andrey Turbanov wrote: > `Properties` doesn't allow `null` values. > We can replace containsKey+getProperty with getProperty+null check. > It's clearer and a bit faster. This pull request has now been integrated. Changeset: 3b7571d3 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/3b7571d37812472a2152f9c8cbfd2a4abdb35016 Stats: 10 lines in 1 file changed: 3 ins; 4 del; 3 mod 8345398: Avoid redundant Properties.containsKey call in Cursor.getSystemCustomCursor Reviewed-by: aivanov, prr ------------- PR: https://git.openjdk.org/jdk/pull/21824 From shade at openjdk.org Thu Dec 5 09:23:43 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 5 Dec 2024 09:23:43 GMT Subject: RFR: 8337505: Footprint and startup regressions up to 20% in GUI apps In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 18:47:52 GMT, Phil Race wrote: > Thanks for the suggestion, but it isn't a path I want to go. The patch is still fine as it is. Well, the point of the review process is to get at least some reviewers to agree. I do not see anyone agreeing so far. My problem with current version is that exposing non-constant-foldable `Method/VarHandle`-s is a performance anti-pattern. I poked around the font code, and I have not been able to convince myself these accesses are never on the hot-path. I see this is also a _cache_, so I would think there is an expectation that most, if not all things in it work as fast as reasonably possible. Therefore, I cannot put my approval on current version, sorry. I do not quite understand what is the problem with stamping `@Stable` over the now-non-`final` fields in your current PR, like below? Is this only about the conceptual uncleanliness of exposing `@Stable` to `java.desktop`, or is it about something else? diff --git a/src/java.base/share/classes/module-info.java b/src/java.base/share/classes/module-info.java index c3bcbed4e3b..66ffff5723a 100644 --- a/src/java.base/share/classes/module-info.java +++ b/src/java.base/share/classes/module-info.java @@ -261,6 +261,7 @@ jdk.internal.vm.ci, jdk.jfr; exports jdk.internal.vm.annotation to + java.desktop, java.instrument, jdk.internal.vm.ci, jdk.incubator.vector, diff --git a/src/java.desktop/share/classes/sun/font/StrikeCache.java b/src/java.desktop/share/classes/sun/font/StrikeCache.java index e71235d54c0..5271afbe611 100644 --- a/src/java.desktop/share/classes/sun/font/StrikeCache.java +++ b/src/java.desktop/share/classes/sun/font/StrikeCache.java @@ -43,6 +43,8 @@ import java.lang.ref.WeakReference; import java.util.*; +import jdk.internal.vm.annotation.Stable; + import sun.java2d.Disposer; import sun.java2d.pipe.BufferedContext; import sun.java2d.pipe.RenderQueue; @@ -136,16 +138,16 @@ private static VarHandle getVarHandle(StructLayout struct, String name) { return MethodHandles.insertCoordinates(h, 1, 0L).withInvokeExactBehavior(); } - private static VarHandle xAdvanceHandle; - private static VarHandle yAdvanceHandle; - private static VarHandle widthHandle; - private static VarHandle heightHandle; - private static VarHandle rowBytesHandle; - private static VarHandle managedHandle; - private static VarHandle topLeftXHandle; - private static VarHandle topLeftYHandle; - private static VarHandle cellInfoHandle; - private static VarHandle imageHandle; + @Stable private static VarHandle xAdvanceHandle; + @Stable private static VarHandle yAdvanceHandle; + @Stable private static VarHandle widthHandle; + @Stable private static VarHandle heightHandle; + @Stable private static VarHandle rowBytesHandle; + @Stable private static VarHandle managedHandle; + @Stable private static VarHandle topLeftXHandle; + @Stable private static VarHandle topLeftYHandle; + @Stable private static VarHandle cellInfoHandle; + @Stable private static VarHandle imageHandle; private static VarHandle getXAdvanceHandle() { if (xAdvanceHandle == null) { ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2519724561 From psadhukhan at openjdk.org Thu Dec 5 10:09:48 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 5 Dec 2024 10:09:48 GMT Subject: RFR: 8345566: Deproblemlist test/jdk/javax/swing/JComboBox/6559152/bug6559152.java Message-ID: test/jdk/javax/swing/JComboBox/6559152/bug6559152.java does not seem to fail in listed CI job but is problemlisted. Test is passing in several OCI systems so deproblemlisting.. ------------- Commit messages: - test fix Changes: https://git.openjdk.org/jdk/pull/22570/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22570&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345566 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22570.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22570/head:pull/22570 PR: https://git.openjdk.org/jdk/pull/22570 From tr at openjdk.org Thu Dec 5 11:51:37 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 5 Dec 2024 11:51:37 GMT Subject: RFR: 8345566: Deproblemlist test/jdk/javax/swing/JComboBox/6559152/bug6559152.java In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 10:04:25 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JComboBox/6559152/bug6559152.java does not seem to fail in listed CI job but is problemlisted. > Test is passing in several OCI systems so deproblemlisting.. LGTM. ------------- Marked as reviewed by tr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22570#pullrequestreview-2481443545 From psadhukhan at openjdk.org Thu Dec 5 11:54:39 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 5 Dec 2024 11:54:39 GMT Subject: Integrated: 8345566: Deproblemlist test/jdk/javax/swing/JComboBox/6559152/bug6559152.java In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 10:04:25 GMT, Prasanta Sadhukhan wrote: > test/jdk/javax/swing/JComboBox/6559152/bug6559152.java does not seem to fail in listed CI job but is problemlisted. > Test is passing in several OCI systems so deproblemlisting.. This pull request has now been integrated. Changeset: 7ee84d8f Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/7ee84d8f7096ccfc4666d5bff78e7e5ac6d614bd Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8345566: Deproblemlist test/jdk/javax/swing/JComboBox/6559152/bug6559152.java Reviewed-by: tr ------------- PR: https://git.openjdk.org/jdk/pull/22570 From tr at openjdk.org Thu Dec 5 13:04:42 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 5 Dec 2024 13:04:42 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: On Mon, 25 Nov 2024 22:34:46 GMT, Jeremy wrote: >> The AWTEventMulticaster is a tree node with 2 children. This PR proposes rebalancing that tree after 500 additions to avoid potential StackOverflowErrors when trying to interact with a large AWTEventMulticaster. >> >> In the original headful test: >> We added 8,000 checkboxes, and when their parent panel was hidden the stack needed to grow to 24,000 lines. It took 8,000 lines to recursively call `java.awt.AWTEventMulticaster.componentHidden`, and then 16,000 additional lines to call two recursive methods to remove a listener: >> >> java.desktop/java.awt.AWTEventMulticaster.removeInternal() >> java.desktop/java.awt.AWTEventMulticaster.remove() >> >> >> With this current PR the max stack size reaches 1,267 instead. (If we rebalanced at EVERY addition, then that same scenario would reach a max stack size of 71.) >> >> JDK-8342782 included a headful test case, but I think the main problem it demonstrated can be represented by the headless test case attached to this PR. >> >> Depending on how this PR is received I may submit a separate ticket & PR to modify AquaButtonUI so it doesn't always attach an AncestorListener. (That is: if my GUI includes 8,000 checkboxes then I don't need 8,000 AncestorListeners.) But JDK-8342782's test case is currently written in a way that should reproduce across all L&F's, so that can be discussed separately. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8342782: expanding wildcard imports > > This is in response to: > https://github.com/openjdk/jdk/pull/21962#discussion_r1857389973 test/jdk/java/awt/event/StressTest/LargeAWTEventMulticasterTest.java line 96: > 94: } > 95: } > 96: } Please add an empty line representing EOF. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1871348260 From tr at openjdk.org Thu Dec 5 13:30:42 2024 From: tr at openjdk.org (Tejesh R) Date: Thu, 5 Dec 2024 13:30:42 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: On Mon, 25 Nov 2024 22:34:46 GMT, Jeremy wrote: >> The AWTEventMulticaster is a tree node with 2 children. This PR proposes rebalancing that tree after 500 additions to avoid potential StackOverflowErrors when trying to interact with a large AWTEventMulticaster. >> >> In the original headful test: >> We added 8,000 checkboxes, and when their parent panel was hidden the stack needed to grow to 24,000 lines. It took 8,000 lines to recursively call `java.awt.AWTEventMulticaster.componentHidden`, and then 16,000 additional lines to call two recursive methods to remove a listener: >> >> java.desktop/java.awt.AWTEventMulticaster.removeInternal() >> java.desktop/java.awt.AWTEventMulticaster.remove() >> >> >> With this current PR the max stack size reaches 1,267 instead. (If we rebalanced at EVERY addition, then that same scenario would reach a max stack size of 71.) >> >> JDK-8342782 included a headful test case, but I think the main problem it demonstrated can be represented by the headless test case attached to this PR. >> >> Depending on how this PR is received I may submit a separate ticket & PR to modify AquaButtonUI so it doesn't always attach an AncestorListener. (That is: if my GUI includes 8,000 checkboxes then I don't need 8,000 AncestorListeners.) But JDK-8342782's test case is currently written in a way that should reproduce across all L&F's, so that can be discussed separately. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8342782: expanding wildcard imports > > This is in response to: > https://github.com/openjdk/jdk/pull/21962#discussion_r1857389973 src/java.desktop/share/classes/java/awt/AWTEventMulticaster.java line 1020: > 1018: return new AWTEventMulticaster(array[index0], array[index1]); > 1019: } > 1020: int mid = (index0 + index1)/2; Suggestion: int mid = (index0 + index1) / 2; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1871376542 From dgredler at openjdk.org Thu Dec 5 18:22:27 2024 From: dgredler at openjdk.org (Daniel Gredler) Date: Thu, 5 Dec 2024 18:22:27 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v2] In-Reply-To: References: Message-ID: > When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). > > Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: Fix second array expansion site ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22288/files - new: https://git.openjdk.org/jdk/pull/22288/files/bb7a66ce..4ca6782f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22288&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22288&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22288/head:pull/22288 PR: https://git.openjdk.org/jdk/pull/22288 From dgredler at openjdk.org Thu Dec 5 18:22:28 2024 From: dgredler at openjdk.org (Daniel Gredler) Date: Thu, 5 Dec 2024 18:22:28 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v2] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 21:20:37 GMT, Harshitha Onkar wrote: >> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix second array expansion site > > @gredler There is one other place where `expandArray()` is called similarly - [TextLine.getComponents()](https://github.com/openjdk/jdk/blob/bb7a66ce7b08a7f50da3194390c1d077a0b1fb81/src/java.desktop/share/classes/java/awt/font/TextLine.java#L1078C1-L1081C22). @honkar-jdk Good catch -- I've gone ahead and fixed that one, too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22288#issuecomment-2521103573 From aturbanov at openjdk.org Thu Dec 5 19:28:52 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 5 Dec 2024 19:28:52 GMT Subject: RFR: 8345616: Unnecessary Hashtable usage in javax.swing.text.html.parser.Element Message-ID: <-niCcMlDNUfllahrMsxSfIARJypyinVjjldTn-Swv-c=.9c275ad6-3c80-45f9-ac50-9febdb77b2c0@github.com> The Hashtable `javax.swing.text.html.parser.Element#contentTypes` is initialized only within `` block. We can replace it with immutable map to avoid Hashtable `synchronized` overhead. ------------- Commit messages: - [PATCH] Unnecessary Hashtable usage in javax.swing.text.html.parser.Element Changes: https://git.openjdk.org/jdk/pull/21825/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21825&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345616 Stats: 16 lines in 1 file changed: 0 ins; 5 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/21825.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21825/head:pull/21825 PR: https://git.openjdk.org/jdk/pull/21825 From achung at openjdk.org Thu Dec 5 19:52:40 2024 From: achung at openjdk.org (Alisen Chung) Date: Thu, 5 Dec 2024 19:52:40 GMT Subject: RFR: 8343224: print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4 [v4] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 20:38:52 GMT, GennadiyKrivoshein wrote: >> Fix for https://bugs.openjdk.org/browse/JDK-8343224, print/Dialog/PaperSizeError.java fails with MediaSizeName is not A4: A4. >> >> **Reason of the bug:** >> The reason for the regression bug is a missed check for the standard media existence during CustomMediaSizeName creation. >> After the JDK-7001133 new MediaSize is created, regardless of whether a standard media size exists. >> >> For example, if a printer's PPD has two media with the same size, close to "iso_A4," with a small difference. >> *PaperDimension A4/A4: "595 842" >> *PaperDimension BrA4_B/A4 (Borderless): "595 842" >> After processing the first line, the MediaSize will contain the new size "A4" because of the missed check, and CustomMediaSize will match the "iso_a4" standard media size. >> After processing the second line, the MediaSize will contain the new size "BrA4_B", and CustomMediaSize will match not the "iso_a4" but the previously added "A4", because it was added by mistake and its size is exactly the same as "BrA4_B". >> >> **Fix description:** >> Create new MediaSize if there is no any other MediaSize with the same size. >> >> **Tests:** >> OS: MacOS 12, Linux Ubuntu 22, Windows 11. >> open/test/jdk/java/awt/print/Dialog/PaperSizeError.java >> test/jdk/javax/print/CustomMediaSizeNameOOMETest.java >> All tests from the test/jdk/javax/print/ > > GennadiyKrivoshein has updated the pull request incrementally with one additional commit since the last revision: > > expand imports Marked as reviewed by achung (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22429#pullrequestreview-2482720843 From honkar at openjdk.org Thu Dec 5 20:09:41 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 5 Dec 2024 20:09:41 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v2] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 18:22:27 GMT, Daniel Gredler wrote: >> When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). >> >> Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Fix second array expansion site LGTM. Ran awt/font and java/awt/font/LineBreakMeasurer tests with fix and they work as expected. @gredler Missed mentioning it earlier, copyright year needs to be updated for TextLine.java ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22288#pullrequestreview-2482750639 From dgredler at openjdk.org Thu Dec 5 20:27:16 2024 From: dgredler at openjdk.org (Daniel Gredler) Date: Thu, 5 Dec 2024 20:27:16 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v3] In-Reply-To: References: Message-ID: > When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). > > Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. Daniel Gredler 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/22288/files - new: https://git.openjdk.org/jdk/pull/22288/files/4ca6782f..557a3b18 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22288&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22288&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22288/head:pull/22288 PR: https://git.openjdk.org/jdk/pull/22288 From dgredler at openjdk.org Thu Dec 5 20:27:16 2024 From: dgredler at openjdk.org (Daniel Gredler) Date: Thu, 5 Dec 2024 20:27:16 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v2] In-Reply-To: References: Message-ID: <_zEttKve0-iK2bp7UpLLQ1Guo5ydJUDieAtlrTqiUV8=.1343a7f8-71ae-40d2-bdf3-52775673473e@github.com> On Thu, 5 Dec 2024 20:07:18 GMT, Harshitha Onkar wrote: >> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix second array expansion site > > LGTM. Ran awt/font and java/awt/font/LineBreakMeasurer tests with fix and they work as expected. > > @gredler Missed mentioning it earlier, copyright year needs to be updated for TextLine.java @honkar-jdk Done! Let me know if there's anything else that catches your eye. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22288#issuecomment-2521320792 From honkar at openjdk.org Thu Dec 5 20:35:39 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Thu, 5 Dec 2024 20:35:39 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v3] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 20:27:16 GMT, Daniel Gredler wrote: >> When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). >> >> Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year > @honkar-jdk Done! Let me know if there's anything else that catches your eye. Looks good now. Re-approved. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22288#pullrequestreview-2482795873 From duke at openjdk.org Thu Dec 5 23:01:41 2024 From: duke at openjdk.org (duke) Date: Thu, 5 Dec 2024 23:01:41 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v3] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 20:27:16 GMT, Daniel Gredler wrote: >> When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). >> >> Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year @gredler Your change (at version 557a3b18f100b9b0302c2bdd2ad1ca6d73533b6a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22288#issuecomment-2521650827 From dgredler at openjdk.org Thu Dec 5 23:01:41 2024 From: dgredler at openjdk.org (Daniel Gredler) Date: Thu, 5 Dec 2024 23:01:41 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 19:20:11 GMT, Phil Race wrote: >> When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). >> >> Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. > > @azvegint @TejeshR13 @prsadhuk @honkar-jdk - this needs a 2nd reviewer @prrace I think this is ready to be sponsored. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22288#issuecomment-2521655008 From prr at openjdk.org Thu Dec 5 23:56:38 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 5 Dec 2024 23:56:38 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. A dependency on the internals of the base module is another reason not to do this. And as I have already said runtime performance is a complete non-issue here. This is about startup (not even warm-up, just startup). There's absolutely no (good) reason to worry about runtime here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2521748701 From liach at openjdk.org Fri Dec 6 02:19:42 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 6 Dec 2024 02:19:42 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. Are you sure all these var handles are rarely used (not on hot code path)? This current patch can slow down the use of these var handles by many times. If this is startup-only, we can probably just create the vh once, invoke it, and discard it, or look into FFM API and see if we have better one-time invocation solutions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2521939803 From prr at openjdk.org Fri Dec 6 02:54:40 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 6 Dec 2024 02:54:40 GMT Subject: RFR: 8337505: Footprint and startup regressions up to 20% in GUI apps In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 02:17:01 GMT, Chen Liang wrote: > Are you sure all these var handles are rarely used (not on hot code path)? This current patch can slow down the use of these var handles by many times. If this is startup-only, we can probably just create the vh once, invoke it, and discard it, or look into FFM API and see if we have better one-time invocation solutions. I don't know what you are thinking. Or perhaps you are overthinking it. You invented the reference to "rarely". Discarding would be silly. The FFM angle is understood by the Panama team. The patch stands. I've not seen a single suggestion to change it that makes sense for the problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2522011746 From psadhukhan at openjdk.org Fri Dec 6 03:21:49 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Dec 2024 03:21:49 GMT Subject: Integrated: 8268145: [macos] Rendering artifacts is seen when text inside the JTable with TableCellEditor having JTextfield In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 16:22:49 GMT, Prasanta Sadhukhan wrote: > When a textfield is embedded in a TableCellEditor in a JTable in Aqua L&F and space is entered and caret moved back and forth by pressing left/right arrow button, an artifact is seen, which is basically the caret is not properly repainted leaving behind its trails. > > When caret is moved, it is repainted every time by "damaging" the area surrounding the caret to cause it to be repainted in a new location. AquaCaret overrides the default "damage" code to intersect the caret area with the border insets so that it does not damage the AquaBorder area.. > For TextField case, AquaTextFieldBorder insets is removed from AquaTextField and then intersected with AquaCaret to get the dirry region which is then repainted, so as to not damage the border but it is done irrespective of whether border is shown or not, so proper dirty region is not repainted leaving behind artifacts when the caret is moved around... > > Fix is to see if border to be painted is not opaque in which case the proper dirty region is calculated which is then used in repaint logic to repaint the component.. This pull request has now been integrated. Changeset: 84032850 Author: Prasanta Sadhukhan URL: https://git.openjdk.org/jdk/commit/84032850dbe3add7b7c8d6a4b2fbd5d5cab4483a Stats: 103 lines in 2 files changed: 95 ins; 4 del; 4 mod 8268145: [macos] Rendering artifacts is seen when text inside the JTable with TableCellEditor having JTextfield Reviewed-by: kizune, abhiscxk, honkar ------------- PR: https://git.openjdk.org/jdk/pull/22416 From liach at openjdk.org Fri Dec 6 04:28:42 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 6 Dec 2024 04:28:42 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. >From the FFM API pov, we might be able to make the VarHandle lazy, that it contains symbolic information and is fully expanded upon first use, effectively the same as the laziness here. Don't know if this works for FFM, but this is how java lang invoke ones work if they have to initialize classes. If such laziness is implemented, we can always revisit the existing uses later. This patch is fine as long as there is no bad side effects. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2522095066 From prr at openjdk.org Fri Dec 6 04:57:41 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 6 Dec 2024 04:57:41 GMT Subject: RFR: 8337505: Footprint and startup regressions up to 20% in GUI apps In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 04:25:23 GMT, Chen Liang wrote: > From the FFM API pov, we might be able to make the VarHandle lazy, that it contains symbolic information and is fully expanded upon first use, effectively the same as the laziness here. Don't know if this works for FFM, but this is how java lang invoke ones work if they have to initialize classes. If such laziness is implemented, we can always revisit the existing uses later. This patch is fine as long as there is no bad side effects. So some day this patch may be obsolete ? So no reason to make it more complex. Bad side effects ? I think that is improbable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2522127979 From psadhukhan at openjdk.org Fri Dec 6 06:50:09 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 6 Dec 2024 06:50:09 GMT Subject: RFR: 8334581: Remove no-arg constructor BasicSliderUI() Message-ID: The no-arg constructor BasicSliderUI() was added accidentally. It should be removed. [JDK-8334580](https://bugs.openjdk.org/browse/JDK-8334580) deprecates the BasicSliderUI() constructor, and this follow-up is to remove the constructor. ------------- Commit messages: - jcheck - 8334581: Remove no-arg constructor BasicSliderUI() Changes: https://git.openjdk.org/jdk/pull/22598/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22598&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334581 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22598.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22598/head:pull/22598 PR: https://git.openjdk.org/jdk/pull/22598 From abhiscxk at openjdk.org Fri Dec 6 06:59:40 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 6 Dec 2024 06:59:40 GMT Subject: RFR: 8334581: Remove no-arg constructor BasicSliderUI() In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 06:37:28 GMT, Prasanta Sadhukhan wrote: > The no-arg constructor BasicSliderUI() was added accidentally. It should be removed. > > [JDK-8334580](https://bugs.openjdk.org/browse/JDK-8334580) deprecates the BasicSliderUI() constructor, and this follow-up is to remove the constructor. Marked as reviewed by abhiscxk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22598#pullrequestreview-2483792320 From abhiscxk at openjdk.org Fri Dec 6 07:05:41 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Fri, 6 Dec 2024 07:05:41 GMT Subject: RFR: 8334581: Remove no-arg constructor BasicSliderUI() In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 06:37:28 GMT, Prasanta Sadhukhan wrote: > The no-arg constructor BasicSliderUI() was added accidentally. It should be removed. > > [JDK-8334580](https://bugs.openjdk.org/browse/JDK-8334580) deprecates the BasicSliderUI() constructor, and this follow-up is to remove the constructor. Do we need a CSR for removal ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22598#issuecomment-2522282277 From aivanov at openjdk.org Fri Dec 6 11:09:40 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Dec 2024 11:09:40 GMT Subject: RFR: 8334581: Remove no-arg constructor BasicSliderUI() In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 06:37:28 GMT, Prasanta Sadhukhan wrote: > The no-arg constructor BasicSliderUI() was added accidentally. It should be removed. > > [JDK-8334580](https://bugs.openjdk.org/browse/JDK-8334580) deprecates the BasicSliderUI() constructor, and this follow-up is to remove the constructor. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22598#pullrequestreview-2484418144 From azvegint at openjdk.org Fri Dec 6 12:59:36 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 6 Dec 2024 12:59:36 GMT Subject: RFR: 8334581: Remove no-arg constructor BasicSliderUI() In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 06:37:28 GMT, Prasanta Sadhukhan wrote: > The no-arg constructor BasicSliderUI() was added accidentally. It should be removed. > > [JDK-8334580](https://bugs.openjdk.org/browse/JDK-8334580) deprecates the BasicSliderUI() constructor, and this follow-up is to remove the constructor. Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22598#pullrequestreview-2484774018 From azvegint at openjdk.org Fri Dec 6 13:10:46 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Fri, 6 Dec 2024 13:10:46 GMT Subject: RFR: 8344668: Unnecessary array allocations and copying in TextLine [v3] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 20:27:16 GMT, Daniel Gredler wrote: >> When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). >> >> Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by azvegint (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22288#pullrequestreview-2484796121 From dgredler at openjdk.org Fri Dec 6 13:10:48 2024 From: dgredler at openjdk.org (Daniel Gredler) Date: Fri, 6 Dec 2024 13:10:48 GMT Subject: Integrated: 8344668: Unnecessary array allocations and copying in TextLine In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 00:20:36 GMT, Daniel Gredler wrote: > When `LineBreakMeasurer` is used to break text into lines, internally it uses `TextMeasurer` and `TextLine` to do the job. In the common case, `TextLine.getComponents(...)` allocates a `TextLineComponent[]` with room for a single array entry, and passes it to `TextLine.createComponentsOnRun(...)`, which fills the array and returns it, optionally resizing to a larger array if necessary, after which the array is resized back down to actual size (if necessary). > > Unfortunately `TextLine.createComponentsOnRun(...)` is too eager in allocating larger arrays. In the most common case of a single component, this means that a single-element array is allocated, then a 9-element array is allocated (via `expandArray(...)`), and then another single-element array is allocated (to shrink the array back to actual size). Only one array allocation is necessary in this common case, and no array copying is needed. This pull request has now been integrated. Changeset: f6021a9c Author: Daniel Gredler URL: https://git.openjdk.org/jdk/commit/f6021a9c34da877bf954f5b90b4233949ec0ffc7 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8344668: Unnecessary array allocations and copying in TextLine Reviewed-by: honkar, azvegint, prr ------------- PR: https://git.openjdk.org/jdk/pull/22288 From mr at openjdk.org Fri Dec 6 14:11:39 2024 From: mr at openjdk.org (Mark Reinhold) Date: Fri, 6 Dec 2024 14:11:39 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. Phil, I don?t understand your resistance to using the `@Stable` annotation, which is already exported by the `java.base` module to five other JDK modules. Yes, it?s marked `internal`, but that means ?internal to the JDK,? not ?internal to the base module.? There?s no conceptual uncleanliness here. You could well be correct in saying that run-time performance is a complete non-issue, for all users at all times, but why not apply `@Stable` just in case it turns out to be an issue for some user at some time? Seems like cheap insurance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2523331075 From liach at openjdk.org Fri Dec 6 14:26:41 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 6 Dec 2024 14:26:41 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. Stable annotation requires the class to be loaded by the boot loader. Need to verify that for java.desktop first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2523359372 From aivanov at openjdk.org Fri Dec 6 14:40:36 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 6 Dec 2024 14:40:36 GMT Subject: RFR: 8345616: Unnecessary Hashtable usage in javax.swing.text.html.parser.Element In-Reply-To: <-niCcMlDNUfllahrMsxSfIARJypyinVjjldTn-Swv-c=.9c275ad6-3c80-45f9-ac50-9febdb77b2c0@github.com> References: <-niCcMlDNUfllahrMsxSfIARJypyinVjjldTn-Swv-c=.9c275ad6-3c80-45f9-ac50-9febdb77b2c0@github.com> Message-ID: On Fri, 1 Nov 2024 13:32:07 GMT, Andrey Turbanov wrote: > The Hashtable `javax.swing.text.html.parser.Element#contentTypes` is initialized only within `` block. > We can replace it with immutable map to avoid Hashtable `synchronized` overhead. Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21825#pullrequestreview-2485009600 From mr at openjdk.org Fri Dec 6 14:56:43 2024 From: mr at openjdk.org (Mark Reinhold) Date: Fri, 6 Dec 2024 14:56:43 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. `java.desktop` is loaded by the bootstrap class loader: https://github.com/openjdk/jdk/blob/496641955041c5e48359e6256a4a61812653d900/make/conf/module-loader-map.conf#L36 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2523426886 From liach at openjdk.org Fri Dec 6 15:26:43 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 6 Dec 2024 15:26:43 GMT Subject: RFR: 8337505: Footprint and startup regressions up to 20% in GUI apps In-Reply-To: References: Message-ID: <1zbaDxzno6NMokIVMy9sKQPYbuhjXZ-xyFwMqhQzEqw=.502fb002-5ac4-4ebc-ad93-9bb2529af7d2@github.com> 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. Thanks for the verification Mark. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21748#issuecomment-2523487153 From honkar at openjdk.org Fri Dec 6 23:59:52 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 6 Dec 2024 23:59:52 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 Testing looks good on Windows and no regressions are observed on other pages. ------------- Marked as reviewed by honkar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21980#pullrequestreview-2486168871 From honkar at openjdk.org Fri Dec 6 23:59:53 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 6 Dec 2024 23:59:53 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 Fri, 29 Nov 2024 18:12:06 GMT, Daniel Gredler wrote: >> src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java line 873: >> >>> 871: AffineTransform.getScaleInstance(scaleFactorX, scaleFactorY); >>> 872: advanceTransform.rotate(devangle); // radians >>> 873: advanceTransform.rotate(iangle * Math.PI / 1800.0); // 1/10 degrees -> radians >> >> Fix to WPathGraphics.java is a little more intricate and certainly requires a more expert review from @prrace. >> Was devangle fix added for the landscape issue observed on Pg#8 ? >> >> A earlier comment mentions that device space rotation must not be added. >> >> >> GDI advances must not include device space rotation. >> See earlier comment in printGlyphVector() for details. > > The two angles (`iangle` + `devangle`) need to be used to fix the Windows page 8 printed "GlyphVector with position adjustments" test case, here's what it looks like without these rotation angles (left side is printed and incorrect, right side is not printed and is correct): > > ![no-angle](https://github.com/user-attachments/assets/0366606d-b71c-4a4c-9d2c-402144aaf7d3) > > Adding `iangle` alone looks OK in the printed portrait page, but not in the printed landscape page (`devangle` is zero and therefore makes no difference when printing in portrait mode, but not so for landscape mode). > > This restores the rotation transformation that was being applied prior to commit 5c2672351683467fdeeda7796d971634fc3c51ae (prior to this commit the advance transform was a copy of the device transform, with the extra `iangle` rotation applied, meaning that both the device rotation and the `iangle` rotation were included). Thanks for including the details. Sounds reasonable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21980#discussion_r1874151081 From duke at openjdk.org Sun Dec 8 07:52:17 2024 From: duke at openjdk.org (Jeremy) Date: Sun, 8 Dec 2024 07:52:17 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v6] In-Reply-To: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: > The AWTEventMulticaster is a tree node with 2 children. This PR proposes rebalancing that tree after 500 additions to avoid potential StackOverflowErrors when trying to interact with a large AWTEventMulticaster. > > In the original headful test: > We added 8,000 checkboxes, and when their parent panel was hidden the stack needed to grow to 24,000 lines. It took 8,000 lines to recursively call `java.awt.AWTEventMulticaster.componentHidden`, and then 16,000 additional lines to call two recursive methods to remove a listener: > > java.desktop/java.awt.AWTEventMulticaster.removeInternal() > java.desktop/java.awt.AWTEventMulticaster.remove() > > > With this current PR the max stack size reaches 1,267 instead. (If we rebalanced at EVERY addition, then that same scenario would reach a max stack size of 71.) > > JDK-8342782 included a headful test case, but I think the main problem it demonstrated can be represented by the headless test case attached to this PR. > > Depending on how this PR is received I may submit a separate ticket & PR to modify AquaButtonUI so it doesn't always attach an AncestorListener. (That is: if my GUI includes 8,000 checkboxes then I don't need 8,000 AncestorListeners.) But JDK-8342782's test case is currently written in a way that should reproduce across all L&F's, so that can be discussed separately. Jeremy has updated the pull request incrementally with five additional commits since the last revision: - 8342782: move comments re implementation details inside method Also avoid restating constant, instead only refer to it as "threshold" This is in response to: https://github.com/openjdk/jdk/pull/21962#discussion_r1855148909 - 8342782: adding an empty line representing EOF This is in response to: https://github.com/openjdk/jdk/pull/21962#discussion_r1871348260 - 8342782: changing "/2" to " / 2" This is in response to: https://github.com/openjdk/jdk/pull/21962#discussion_r1871376542 - 8342782: change threshold from 500 to 100 This is in response to: https://github.com/openjdk/jdk/pull/21962#discussion_r1855398578 - 8342782: convert value (500) to named constant This is in response to: https://github.com/openjdk/jdk/pull/21962#discussion_r1855397860 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21962/files - new: https://git.openjdk.org/jdk/pull/21962/files/ed6a585a..f2212092 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21962&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21962&range=04-05 Stats: 14 lines in 2 files changed: 6 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21962.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21962/head:pull/21962 PR: https://git.openjdk.org/jdk/pull/21962 From duke at openjdk.org Sun Dec 8 07:52:17 2024 From: duke at openjdk.org (Jeremy) Date: Sun, 8 Dec 2024 07:52:17 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v6] In-Reply-To: <7gp-NCHUoqWy8a-UuUICrvAIYbLfRsH3vOGnos7gx_s=.f5342625-2385-44fa-8ca0-6e40496b1e27@github.com> References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> <7gp-NCHUoqWy8a-UuUICrvAIYbLfRsH3vOGnos7gx_s=.f5342625-2385-44fa-8ca0-6e40496b1e27@github.com> Message-ID: <8P1Txs_3sgpJ5DNgDCl9Vkhzg_U0gndc_E_vj-Mrrbg=.54aae5ed-ed9f-4776-b2aa-6fc3d0361d72@github.com> On Sun, 24 Nov 2024 08:55:20 GMT, Laurent Bourg?s wrote: >> Here is a constant declaration (hotspot friendly): >> https://github.com/bourgesl/jdk-official/blob/d0b770c938be6b5b3a0176148265ef33184a9b8b/src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java#L38 >> >> private static final int ALL_BUT_LSB = 0xFFFFFFFE; > > '500 iterations' looks high, maybe 100? > It is a recursion ? You could try max recursion depth + 3 samples (first, middle, last) ? > > Or this magic threshold could be tunable ac runtime using special static getter using a System property + default value, used by constant declaration (final static is mandatory): > > https://github.com/bourgesl/jdk-official/blob/d0b770c938be6b5b3a0176148265ef33184a9b8b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java#L50 > > https://github.com/bourgesl/jdk-official/blob/d0b770c938be6b5b3a0176148265ef33184a9b8b/src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java#L303 I added a constant `MAX_UNBALANCED_TOP_NODES = 100`, and I moved some comments from outside the method to inside the method. Regarding recursion: I'm reluctant to explore the tree recursively because I want `needsRebalance` to be a light/fast call. (It will be called with every addition.) The primary use case I'm worried about is code that resembles this example in Container.java: public synchronized void addContainerListener(ContainerListener l) { if (l == null) { return; } containerListener = AWTEventMulticaster.add(containerListener, l); newEventsOnly = true; } There are several of these static `AWTEventMulticaster.add(X, X)` methods. This is (IMO) the recommended/primary way to interact with the AWTEventMulticaster. This implementation (without rebalancing) created a tree where the *top* of the tree was guaranteed to be unbalanced. (Specifically: every left node may be a tree, and every right node will be a leaf.) It's not necessary to recursively scan the entire tree to identify this condition, so I'd prefer not to make `needsRebalance` more complex than it needs to be to identify this usage. (That is: there's no need to look at the middle or bottom of the tree, or even to identify the size or height of the tree.) Regarding a System property: I'm also reluctant to add this; it feels like bloat to me that nobody will ever use. Do you think you (or anyone else) will want to customize this property over time? My broad goal here is to prevent a StackOverflowError; not to fine-tune tree performance. I definitely appreciate seeing `System.getProperty("x")` in several important pieces of code, but IMO altering the `MAX_UNBALANCED_TOP_NODES` field will only ever yield negligible changes. (Or that could be the subject of another ticket, with another test case?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1874643208 From duke at openjdk.org Sun Dec 8 07:52:17 2024 From: duke at openjdk.org (Jeremy) Date: Sun, 8 Dec 2024 07:52:17 GMT Subject: RFR: 8342782: AWTEventMulticaster throws StackOverflowError using AquaButtonUI [v5] In-Reply-To: References: <7t-UgshCotHJ-oMhj4wjBYZQFlR6I6fY8hmco1llX3I=.350afe82-8afb-4409-911b-3324915756e1@github.com> Message-ID: On Thu, 5 Dec 2024 13:22:01 GMT, Tejesh R wrote: >> Jeremy has updated the pull request incrementally with one additional commit since the last revision: >> >> 8342782: expanding wildcard imports >> >> This is in response to: >> https://github.com/openjdk/jdk/pull/21962#discussion_r1857389973 > > src/java.desktop/share/classes/java/awt/AWTEventMulticaster.java line 1020: > >> 1018: return new AWTEventMulticaster(array[index0], array[index1]); >> 1019: } >> 1020: int mid = (index0 + index1)/2; > > Suggestion: > > int mid = (index0 + index1) / 2; OK; this is updated > test/jdk/java/awt/event/StressTest/LargeAWTEventMulticasterTest.java line 96: > >> 94: } >> 95: } >> 96: } > > Please add an empty line representing EOF. OK; this is updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1874638586 PR Review Comment: https://git.openjdk.org/jdk/pull/21962#discussion_r1874638707 From duke at openjdk.org Sun Dec 8 19:47:42 2024 From: duke at openjdk.org (ScientificWare) Date: Sun, 8 Dec 2024 19:47:42 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v8] In-Reply-To: <1CpHIs0qKh3uC4ay98jOj6Gj-k-qVAuSuDVHMnbKjuM=.73576799-e268-478d-9fcb-778c84f626a1@github.com> References: <1CpHIs0qKh3uC4ay98jOj6Gj-k-qVAuSuDVHMnbKjuM=.73576799-e268-478d-9fcb-778c84f626a1@github.com> Message-ID: On Tue, 3 Dec 2024 22:09:57 GMT, Phil Race wrote: >> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - 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 >> - Removes files >> >> make/javac.20231014_162919.args >> make/javac.20231014_220237.args >> make/javac.20231023_221655.args >> - Adds a regression test for JDK-8314731. >> - Others changes in the working directory. >> - Merge Master >> - Merge master >> - ... and 10 more: https://git.openjdk.org/jdk/compare/352201dd...de644539 > > test/jdk/javax/swing/text/html/bug8314731.java line 51: > >> 49: >> 50: public static void main(String[] args) throws Exception { >> 51: new bug8314731(); > > the UI needs to be created on the EDT using SwingUtilities.invokeAndWait. > And you need use a finally block to be SURE the Frame is disposed, else the test will just sit there. > > Please make sure you have used jtreg to validate this test. Test Passed with JDK master patched

----------System.out:(1/3)---------- ok ----------System.err:(1/15)---------- STATUS:Passed. ----------rerun:(40/2653)*---------- cd /home/scientificwaredev/Documents/openjdk-sources/JTwork/scratch && \\ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus \\ DESKTOP_SESSION=01plasma \\ DISPLAY=:0 \\ HOME=/home/scientificwaredev \\ LANG=fr_FR.UTF-8 \\ PATH=/bin:/usr/bin:/usr/sbin \\ XDG_CONFIG_DIRS=/home/scientificwaredev/.config/kdedefaults:/etc/xdg:/etc/xdg/kf5:/var/lib/plasma5-profiles/common/xdg \\ XDG_CURRENT_DESKTOP=KDE \\ XDG_DATA_DIRS=/home/scientificwaredev/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share \\ XDG_MENU_PREFIX=plasma- \\ XDG_RUNTIME_DIR=/run/user/1000 \\ XDG_SEAT=seat0 \\ XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 \\ XDG_SESSION_CLASS=user \\ XDG_SESSION_DESKTOP=KDE \\ XDG_SESSION_ID=c2 \\ XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 \\ XDG_SESSION_TYPE=x11 \\ XDG_VTNR=2 \\ XMODIFIERS=@im=none \\ CLASSPATH=/home/scientificwaredev/Documents/openjdk-sources/JTwork/classes/javax/swing/text/html/bug8314731.d:/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html:/home/scientificwaredev/Documents/jtreg/lib/javatest.jar:/home/scientificwaredev/Documents/jtreg/lib/jtreg.jar \\ /home/scientificwaredev/Documents/openjdk-sources/jdk/build/linux-x86_64-server-release/jdk/bin/java \\ -Dtest.vm.opts= \\ -Dtest.tool.vm.opts= \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/home/scientificwaredev/Documents/openjdk-sources/jdk/build/linux-x86_64-server-release/jdk \\ -Dcompile.jdk=/home/scientificwaredev/Documents/openjdk-sources/jdk/build/linux-x86_64-server-release/jdk \\ -Dtest.timeout.factor=1.0 \\ -Dtest.root=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk \\ -Dtest.name=javax/swing/text/html/bug8314731.java \\ -Dtest.file=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html/bug8314731.java \\ -Dtest.src=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html \\ -Dtest.src.path=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html \\ -Dtest.classes=/home/scientificwaredev/Documents/openjdk-sources/JTwork/classes/javax/swing/text/html/bug8314731.d \\ -Dtest.class.path=/home/scientificwaredev/Documents/openjdk-sources/JTwork/classes/javax/swing/text/html/bug8314731.d \\ -Dtest.modules=java.desktop \\ --add-modules java.desktop \\ com.sun.javatest.regtest.agent.MainWrapper /home/scientificwaredev/Documents/openjdk-sources/JTwork/javax/swing/text/html/bug8314731.d/main.0.jta result: Passed. Execution successful test result: Passed. Execution successful

Test Failed with JDK 23.0.1.

----------System.out:(0/0)---------- ----------System.err:(11/728)---------- java.lang.RuntimeException: FormView doesn't support the alt attribute, see JDK-8314731. at bug8314731.main(bug8314731.java:57) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575) JavaTest Message: Test threw exception: java.lang.RuntimeException: FormView doesn't support the alt attribute, see JDK-8314731. JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: FormView doesn't support the alt attribute, see JDK-8314731. ----------rerun:(40/2512)*---------- cd /home/scientificwaredev/Documents/openjdk-sources/JTwork/scratch && \\ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus \\ DESKTOP_SESSION=01plasma \\ DISPLAY=:0 \\ HOME=/home/scientificwaredev \\ LANG=fr_FR.UTF-8 \\ PATH=/bin:/usr/bin:/usr/sbin \\ XDG_CONFIG_DIRS=/home/scientificwaredev/.config/kdedefaults:/etc/xdg:/etc/xdg/kf5:/var/lib/plasma5-profiles/common/xdg \\ XDG_CURRENT_DESKTOP=KDE \\ XDG_DATA_DIRS=/home/scientificwaredev/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share \\ XDG_MENU_PREFIX=plasma- \\ XDG_RUNTIME_DIR=/run/user/1000 \\ XDG_SEAT=seat0 \\ XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 \\ XDG_SESSION_CLASS=user \\ XDG_SESSION_DESKTOP=KDE \\ XDG_SESSION_ID=c2 \\ XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 \\ XDG_SESSION_TYPE=x11 \\ XDG_VTNR=2 \\ XMODIFIERS=@im=none \\ CLASSPATH=/home/scientificwaredev/Documents/openjdk-sources/JTwork/classes/javax/swing/text/html/bug8314731.d:/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html:/home/scientificwaredev/Documents/jtreg/lib/javatest.jar:/home/scientificwaredev/Documents/jtreg/lib/jtreg.jar \\ /home/scientificwaredev/Documents/jdk-23.0.1/bin/java \\ -Dtest.vm.opts= \\ -Dtest.tool.vm.opts= \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/home/scientificwaredev/Documents/jdk-23.0.1 \\ -Dcompile.jdk=/home/scientificwaredev/Documents/jdk-23.0.1 \\ -Dtest.timeout.factor=1.0 \\ -Dtest.root=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk \\ -Dtest.name=javax/swing/text/html/bug8314731.java \\ -Dtest.file=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html/bug8314731.java \\ -Dtest.src=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html \\ -Dtest.src.path=/home/scientificwaredev/Documents/openjdk-sources/jdk/test/jdk/javax/swing/text/html \\ -Dtest.classes=/home/scientificwaredev/Documents/openjdk-sources/JTwork/classes/javax/swing/text/html/bug8314731.d \\ -Dtest.class.path=/home/scientificwaredev/Documents/openjdk-sources/JTwork/classes/javax/swing/text/html/bug8314731.d \\ -Dtest.modules=java.desktop \\ --add-modules java.desktop \\ com.sun.javatest.regtest.agent.MainWrapper /home/scientificwaredev/Documents/openjdk-sources/JTwork/javax/swing/text/html/bug8314731.d/main.0.jta result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: FormView doesn't support the alt attribute, see JDK-8314731. test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: FormView doesn't support the alt attribute, see JDK-8314731.

------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1875026909 From duke at openjdk.org Sun Dec 8 19:59:23 2024 From: duke at openjdk.org (ScientificWare) Date: Sun, 8 Dec 2024 19:59:23 GMT Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image type input HTML tag [v9] In-Reply-To: References: Message-ID: > This is referenced in Java Bug Database as > - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731) > > This is tracked in JBS as > - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731) > > According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input) > > `alt` is not an attribute of the `input` element. > > According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : > >> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ... > > This feature is not implemented in `FormView.java`. > > ?? ~~This also affects the HTML 32 DTD~~ > > ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138) > > Left before the patch and right after the patch. > > > import java.awt.BorderLayout; > import java.awt.Dimension; > import javax.swing.JEditorPane; > import javax.swing.JFrame; > import javax.swing.JScrollPane; > import javax.swing.SwingUtilities; > import javax.swing.text.Document; > import javax.swing.text.html.HTMLEditorKit; > import javax.swing.text.html.StyleSheet; > > public class HTMLAddsSupportAltInputTag { > public static void main(String[] args) { > new HTMLAddsSupportAltInputTag(); > } > > public HTMLAddsSupportAltInputTag() { > SwingUtilities.invokeLater(new Runnable(){ > public void run(){ > JEditorPane jEditorPane = new JEditorPane(); > jEditorPane.setEditable(false); > JScrollPane scrollPane = new JScrollPane(jEditorPane); > HTMLEditorKit kit = new HTMLEditorKit(); > jEditorPane.setEditorKit(kit); > StyleSheet styleSheet = kit.getStyleSheet(); > styleSheet.addRule(""" > body { > color: #000; > font-family:times; > margin: 4px; > } > """); > String htmlString = """ > > > >