From prr at openjdk.java.net Sun May 1 19:38:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 1 May 2022 19:38:03 GMT Subject: RFR: 8285397: JNI exception pending in CUPSfuncs.c:250 Message-ID: A tool checking for JNI errors complains that the call to JNU_NewStringPlatform(..) might throw an exception and subsequent JNI code isn't making sure of that. Clear the exception so the error handling code can do its thing. ------------- Commit messages: - 8285399 Changes: https://git.openjdk.java.net/jdk/pull/8491/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285397 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8491/head:pull/8491 PR: https://git.openjdk.java.net/jdk/pull/8491 From prr at openjdk.java.net Sun May 1 21:23:17 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 1 May 2022 21:23:17 GMT Subject: RFR: 8283705: Make javax.sound.midi.Track a final class Message-ID: This is the straggler from several PRs which were around making JDK classes sealed. There's nothing to be sealed here, but the same query pointed out that this class has no public or protected constructor (as well as no sub-classes) and so can be made final CSR for review here https://bugs.openjdk.java.net/browse/JDK-8285978 ------------- Commit messages: - 8283705 Changes: https://git.openjdk.java.net/jdk/pull/8492/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283705 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8492/head:pull/8492 PR: https://git.openjdk.java.net/jdk/pull/8492 From prr at openjdk.java.net Sun May 1 21:33:00 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 1 May 2022 21:33:00 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 Message-ID: This is a theoretical/potential case of calling JNI methods with a possible execption pending. As noted in the eval of the bug report, we no longer follow the practice that AWT_LOCK is called only at the start of a native method and AWT_UNLOCK at the end, if indeed we ever did. But it seems to be implied in how they are handling exceptions. ------------- Commit messages: - 8285399 Changes: https://git.openjdk.java.net/jdk/pull/8493/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8493&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285399 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8493.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8493/head:pull/8493 PR: https://git.openjdk.java.net/jdk/pull/8493 From duke at openjdk.java.net Mon May 2 03:10:14 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 03:10:14 GMT Subject: RFR: 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF Message-ID: In Button ToolTip Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. ------------- Commit messages: - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly - Merge branch 'openjdk:master' into branch_8233477 - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - Revert "8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF" - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - 8236987: Remove call to System.out.println from ImageIcon.loadImage - ... and 3 more: https://git.openjdk.java.net/jdk/compare/a7716006...7c46bba4 Changes: https://git.openjdk.java.net/jdk/pull/8496/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8496&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233477 Stats: 361 lines in 5 files changed: 272 ins; 76 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8496/head:pull/8496 PR: https://git.openjdk.java.net/jdk/pull/8496 From duke at openjdk.java.net Mon May 2 03:21:25 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 03:21:25 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v2] In-Reply-To: References: Message-ID: > In Button ToolTip Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. Tejesh R has updated the pull request incrementally with two additional commits since the last revision: - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8496/files - new: https://git.openjdk.java.net/jdk/pull/8496/files/7c46bba4..60da819c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8496&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8496&range=00-01 Stats: 121 lines in 2 files changed: 1 ins; 120 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8496/head:pull/8496 PR: https://git.openjdk.java.net/jdk/pull/8496 From psadhukhan at openjdk.java.net Mon May 2 05:06:43 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 2 May 2022 05:06:43 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 03:21:25 GMT, Tejesh R wrote: >> In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly > - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly I believe you can migrate the closed test to open and iterate through all L&Fs and add that to the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From tnakamura at openjdk.java.net Mon May 2 05:43:41 2022 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Mon, 2 May 2022 05:43:41 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 00:12:53 GMT, Phil Race wrote: >> The following diff seems to choose the right font: >> >> --- a/src/java.desktop/windows/data/fontconfig/fontconfig.properties >> +++ b/src/java.desktop/windows/data/fontconfig/fontconfig.properties >> @@ -230,7 +230,7 @@ sequence.dialog.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,ch >> inese-hkscs,dingbats >> sequence.dialoginput.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,chinese-hkscs,di >> ngbats,symbol,chinese-ms950-extb >> >> sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol >> -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol >> +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol >> >> sequence.allfonts.windows-1255=hebrew,alphabetic/1252,dingbats,symbol >> >> This diff intends to choose the `japanese` set before the `alphabetic` set, in case for `ja` locale in `UTF-8` file encoding. I am not saying this is the right fix, but could be a starting point. > >> The following diff seems to choose the right font: >> >> ``` >> --- a/src/java.desktop/windows/data/fontconfig/fontconfig.properties >> +++ b/src/java.desktop/windows/data/fontconfig/fontconfig.properties >> @@ -230,7 +230,7 @@ sequence.dialog.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,ch >> inese-hkscs,dingbats >> sequence.dialoginput.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,chinese-hkscs,di >> ngbats,symbol,chinese-ms950-extb >> >> sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol >> -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol >> +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol >> >> sequence.allfonts.windows-1255=hebrew,alphabetic/1252,dingbats,symbol >> ``` >> >> This diff intends to choose the `japanese` set before the `alphabetic` set, in case for `ja` locale in `UTF-8` file encoding. I am not saying this is the right fix, but could be a starting point. > > I've been looking at that exact line since I think it is what we'd use in the new default locale > and also thinking about the "allfonts" issue we've seen with Korean. > And which font is "japanese" in this case ? > Maybe we want to fill out the UTF8. based locales in this file now that is the default > > I suspect it is a lot safer to do what Toshio is doing but I just want to understand the mechanism. > I didn't have all the JA fonts installed on my system and I've been trying but they don't seem to have > appeared yet, so specifically I don't have MS Mincho, so there's not much I can test yet. > It migh Hi @prrace The key variable is `WFontConfiguration:textInputCharset`. In Japanese until Java 17, `textInputCharset` was "SHIFTJIS_CHARSET", which was set in `WFontConfiguration:initTables()`. `WFontConfiguration:getTextComponentFontName()`, which used the value, called `findFontWithCharset(,"SHIFTJIS_CHARSET")`, and it returned "MS Gothic,SHIFTJIS_CHARSET" or "MS Mincho,SHIFTJIS_CHARSET" by specified logical font name. > sequence.serif.windows-31j=alphabetic,japanese,dingbats,symbol In Japanese after Java 18, textInputCharset is "DEFAULT_CHARSET". findFontWithCharset(,"DEFAULT_CHARSET") retuned null, and the first font in the target line of fontconfig was used. It's alphabetic (mapped "Times New Roman,ANSI_CHARSET" or "Arial,ANSI_CHARSET"). > sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol When the first one was changed to "japanese", it was used (mapped "MS Gothic,SHIFTJIS_CHARSET" or "MS Mincho,SHIFTJIS_CHARSET"). > sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol So, I tried to modify `textInputCharset` value only. It almost worked. However, that couldn't pick up the proper line from fontconfig file for Chinese, because it couldn't tell GBK and GB18030 without the native encoding. That is, the following two lines have the same key. > sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-ms936,dingbats,symbol,chinese-ms936-extb > sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-gb18030,dingbats,symbol,chinese-gb18030-extb ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From smandalika at openjdk.java.net Mon May 2 05:52:40 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Mon, 2 May 2022 05:52:40 GMT Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v2] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 09:19:33 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362) >> >> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return >> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their >> AccessibleValue implementation. >> The real maximum value (due to the constraints on BoundedRangeModel) is >> model.getMaximum() - model.getExtent(). >> >> The test verifies that the above is adhered to as expected. >> >> This review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > 8284524: Create an automated test for JDK-4422362 Hi! Can someone please take a look at this PR and provide their valuable feedback ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8158 From smandalika at openjdk.java.net Mon May 2 05:52:41 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Mon, 2 May 2022 05:52:41 GMT Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v2] In-Reply-To: <1cZzZNkeKLMbo_-pRiMpaTbVQnRhEZdtJJ1tKQckWQA=.58617cb8-1e88-4bde-9936-f4a0788a72ea@github.com> References: <1cZzZNkeKLMbo_-pRiMpaTbVQnRhEZdtJJ1tKQckWQA=.58617cb8-1e88-4bde-9936-f4a0788a72ea@github.com> Message-ID: <8RQ6IsiQ5QrCfPNbRevKhQrSMmk_qT7XKYp82f1Qkfg=.dd8a8bd8-021d-44c6-a309-1f9e7ac57fe4@github.com> On Tue, 26 Apr 2022 09:28:28 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535) >> AccessibleValue implementation only accept Integers >> The AccessibleValue implementations of the following components: >> >> java.awt.Scrollbar >> javax.swing.AbstractButton >> javax.swing.JInternalFrame >> javax.swing.JSplitPane >> javax.swing.JScrollBar >> javax.swing.JProgressBar >> javax.swing.JSlider >> >> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that). >> >> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer. >> >> his review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Comments Fixed: Simplified test code with a loop over the JComponents being tested. @alisenchung Can you please review the changes after incorporating the earlier feedback ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8220 From smandalika at openjdk.java.net Mon May 2 05:53:34 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Mon, 2 May 2022 05:53:34 GMT Subject: RFR: 8285373: Create an automated test for JDK-4702233 [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 14:11:41 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4702233](https://bugs.openjdk.java.net/browse/JDK-4702233) >> >> Several new AccessibleRole and AccessibleRelation constants are needed in those classes in the java.accessibility package. These new contants codify additions made in the GNOME, Netscape, and UNO (StarOffice) accessibility APIs. >> StarOffice 6.1 and GNOME accessibility require new role, state and relation >> constants in the javax.accessibility package. The existing constants are >> inadequate for providing accessibility to StarOffice and GNOME applications >> as required by Section 508. >> >> Solution >> -------- >> Define new constants in the javax.accessibility package. >> AccessibleRelation >> AccessibleRoles >> AccessibleState >> AccessibleAction >> AccessibleContext >> >> The test validates the public fields of the above AccessibleConstants. >> >> This review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Added missing CopyRight Header Hi! Can someone please take a look at this PR and provide their valuable feedback ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8342 From smandalika at openjdk.java.net Mon May 2 05:53:35 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Mon, 2 May 2022 05:53:35 GMT Subject: RFR: 8285693: Create an automated test for JDK-4702199 In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 00:40:02 GMT, Sergey Bylokhov wrote: >> reate an automated test for [JDK-4702199](https://bugs.openjdk.java.net/browse/JDK-4702199) >> >> In order for spatial Braille to work and screen reader "review mode", we need bounding rectangle information for all text on the screen, and also the ability to get text substrings. StarOffice 6.1, Netscape and GNOME accessibility also require this new interface for describing text in their applications. This new interface is required for accessibility to StarOffice 6.1, Netscape and GNOME applications as required by Section 508 >> >> The solution is to define a new interface and related two helper classes. >> AccessibleExtendedText, >> AccessibleTextSequence. >> AccessibleAttributeSequence >> >> The test validates the public fields of the above classes. >> This review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. > > Marked as reviewed by serb (Reviewer). @mrserb Can you please sponsor my changes ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8416 From psadhukhan at openjdk.java.net Mon May 2 07:22:45 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 2 May 2022 07:22:45 GMT Subject: RFR: 8285397: JNI exception pending in CUPSfuncs.c:250 In-Reply-To: References: Message-ID: <1yuuuL_U9TZe4yoCJsFA3cLjFpW4aZWng8GhQ0ta6Bk=.f9718b9a-6a60-4b3d-ad6a-a53125566c66@github.com> On Sun, 1 May 2022 19:31:01 GMT, Phil Race wrote: > A tool checking for JNI errors complains that the call to JNU_NewStringPlatform(..) > might throw an exception and subsequent JNI code isn't making sure of that. > Clear the exception so the error handling code can do its thing. src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 249: > 247: utf_str = JNU_NewStringPlatform(env, dests[i].name); > 248: if (utf_str == NULL) { > 249: (*env)->ExceptionClear(env); Shouldn't we also need to do same in https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/common/awt/CUPSfuncs.c#L357, L367, L381 since we do at L348 ------------- PR: https://git.openjdk.java.net/jdk/pull/8491 From duke at openjdk.java.net Mon May 2 08:15:11 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 08:15:11 GMT Subject: RFR: 8134640 ( Left Insets Margin Test ) moved to open repo from closed Message-ID: The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. ------------- Commit messages: - Moved Test Case 4380543 from closed to open - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly - Merge branch 'openjdk:master' into branch_8233477 - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - Revert "8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF" - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - 8233477: [Win LAF]The tooltip doesn't display correctly in Win LAF - ... and 6 more: https://git.openjdk.java.net/jdk/compare/a7716006...29e9b9a6 Changes: https://git.openjdk.java.net/jdk/pull/8497/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8497&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8134640 Stats: 455 lines in 4 files changed: 367 ins; 75 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8497.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8497/head:pull/8497 PR: https://git.openjdk.java.net/jdk/pull/8497 From duke at openjdk.java.net Mon May 2 08:23:15 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 08:23:15 GMT Subject: RFR: 8134640 ( Left Insets Margin Test ) moved to open repo from closed [v2] In-Reply-To: References: Message-ID: > The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Copyright Added ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8497/files - new: https://git.openjdk.java.net/jdk/pull/8497/files/29e9b9a6..1d49d533 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8497&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8497&range=00-01 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8497.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8497/head:pull/8497 PR: https://git.openjdk.java.net/jdk/pull/8497 From psadhukhan at openjdk.java.net Mon May 2 11:04:46 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 2 May 2022 11:04:46 GMT Subject: RFR: 8134640 ( Left Insets Margin Test ) moved to open repo from closed [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 08:23:15 GMT, Tejesh R wrote: >> The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Copyright Added It contains fixes from another PR...please remove those changes...or create a fresh branch with only this test change... ------------- PR: https://git.openjdk.java.net/jdk/pull/8497 From duke at openjdk.java.net Mon May 2 11:21:42 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 11:21:42 GMT Subject: Withdrawn: 8134640 ( Left Insets Margin Test ) moved to open repo from closed In-Reply-To: References: Message-ID: On Mon, 2 May 2022 08:07:49 GMT, Tejesh R wrote: > The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8497 From duke at openjdk.java.net Mon May 2 11:39:18 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 11:39:18 GMT Subject: RFR: 8134640 ( Left Insets Margin Test ) moved to open repo from closed Message-ID: <5gw_QjIeWEr1uUcAzT0x-xcEnwJKWXGBlVJBSY9o1_0=.1e01015f-91d7-42c6-bb9f-68482c7ad55f@github.com> The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. ------------- Commit messages: - Moved Test Case 4380543 from closed to open - Merge branch 'master' of github.com:TejeshR13/jdk - Merge branch 'openjdk:master' into master - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge branch 'master' of github.com:TejeshR13/jdk - Initial Commit. Changes: https://git.openjdk.java.net/jdk/pull/8500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8500&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8134640 Stats: 237 lines in 1 file changed: 237 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8500/head:pull/8500 PR: https://git.openjdk.java.net/jdk/pull/8500 From duke at openjdk.java.net Mon May 2 11:53:43 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 11:53:43 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 05:03:40 GMT, Prasanta Sadhukhan wrote: > I believe you can migrate the closed test to open and iterate through all L&Fs and add that to the PR. Means to Iterate through all L&F's and wait for specific amount of time for user to validate and go on to next L&F.......? Because the Test case is manual. ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From duke at openjdk.java.net Mon May 2 11:53:43 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 2 May 2022 11:53:43 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 03:21:25 GMT, Tejesh R wrote: >> In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly > - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly Else can add L&F buttons to validate manually and proceed......? ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From psadhukhan at openjdk.java.net Mon May 2 16:08:35 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 2 May 2022 16:08:35 GMT Subject: RFR: 8285962: NimbusDefaults has a typo in a L&F property Message-ID: <1E9x3Ur0YF8znS8aud8ll9X5jPtulLXnTKikMB0pr54=.37e43dc8-bf2c-417f-a097-57693e772110@github.com> BasicLookAndFeel, BasicProgressBarUI, GTKLookAndFeel tries to find property by "ProgressBar.verticalSize" but the property defined in NimbusDefaults has a typo "vertictalSize ". Rectified the typo. ------------- Commit messages: - 8285962: NimbusDefaults has a typo in a L&F property Changes: https://git.openjdk.java.net/jdk/pull/8504/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8504&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285962 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8504.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8504/head:pull/8504 PR: https://git.openjdk.java.net/jdk/pull/8504 From mvs at openjdk.java.net Mon May 2 17:16:46 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Mon, 2 May 2022 17:16:46 GMT Subject: RFR: 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox In-Reply-To: References: Message-ID: <3SxWu2nlA130OTjHZeyfi0RAomwe5NpOPD21lZdCjLE=.c2cd6cb0-fa79-4582-b5c2-caa482c49a04@github.com> On Wed, 27 Apr 2022 11:22:48 GMT, Manukumar V S wrote: > This test verifies that showing a JPopupMenu shouldn't steal the focus out of current focused component.. > This fix moves an unstable closed test to open but updated to be more comprehensive in testing multiple Look and Feels and with some stabilisation improvements. The closed test had some dependencies with some proprietary libraries which are all removed here. > > Testing: > Tested using mach5 10 times per platform and got all Pass. Any volunteers? ------------- PR: https://git.openjdk.java.net/jdk/pull/8426 From prr at openjdk.java.net Mon May 2 18:41:14 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 May 2022 18:41:14 GMT Subject: RFR: 8278367: JNI critical region violation in CTextPipe.m:363 Message-ID: <94RlM2Gc3q80Qh7mr_hMKEPfcoxIixXGVLY71F9aDrY=.99bcdb9d-f8fb-496d-af20-6dfb8f09ffe8@github.com> This re-jigs some lines of code so that we do all the lookups of the arrays before calling the GetPrimitiveArrayCritical on both of them together. Thereby avoiding warnings about calling those other methods in that context. ------------- Commit messages: - 8278367 Changes: https://git.openjdk.java.net/jdk/pull/8506/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8506&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278367 Stats: 11 lines in 1 file changed: 9 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8506.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8506/head:pull/8506 PR: https://git.openjdk.java.net/jdk/pull/8506 From achung at openjdk.java.net Mon May 2 19:53:44 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 2 May 2022 19:53:44 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v10] In-Reply-To: References: Message-ID: > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: updated test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/4dc1287e..6c2efaf4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=08-09 Stats: 52 lines in 1 file changed: 6 ins; 22 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From achung at openjdk.java.net Mon May 2 19:53:46 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 2 May 2022 19:53:46 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v7] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 20:43:47 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> scale stroke width at higher scalings > > What if we don't reset the scale to 1.0 and use a thicker stroke to draw rectangles/lines but set the graphics scale to `floor(getCurrentScale())` instead? > > Dealing with the coordinates could be trickier though. @aivanov-jdk @mrserb I've updated the test to use EtchedBorder, please take a look ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Mon May 2 20:56:37 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 May 2022 20:56:37 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 23:11:20 GMT, Naoto Sato wrote: >> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the fix to WFontConfiguration > > The following diff seems to choose the right font: > > --- a/src/java.desktop/windows/data/fontconfig/fontconfig.properties > +++ b/src/java.desktop/windows/data/fontconfig/fontconfig.properties > @@ -230,7 +230,7 @@ sequence.dialog.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,ch > inese-hkscs,dingbats > sequence.dialoginput.x-MS950-HKSCS-XP=alphabetic,chinese-ms950,chinese-hkscs,di > ngbats,symbol,chinese-ms950-extb > > sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol > -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol > +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol > > sequence.allfonts.windows-1255=hebrew,alphabetic/1252,dingbats,symbol > > This diff intends to choose the `japanese` set before the `alphabetic` set, in case for `ja` locale in `UTF-8` file encoding. I am not saying this is the right fix, but could be a starting point. @naotoj So why can't I reproduce this ? I installed the Japanese (well all international) fonts and ran the test in the bug report using ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From duke at openjdk.java.net Mon May 2 21:09:57 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 2 May 2022 21:09:57 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" Message-ID: This test case tests the functionality of `setAlwaysOnTop`. Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. The test case tests `alwaysOnTop` for the following three cases: 1. JDialog with no parent/owner 2. JDialog with JFrame as owner 3. JDialog with another JDialog as owner Each of the three cases mentioned above is tested under 3 scenarios: ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) ------------- Commit messages: - test case changes for alwaysOnTop Changes: https://git.openjdk.java.net/jdk/pull/8509/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8222323 Stats: 203 lines in 2 files changed: 106 ins; 9 del; 88 mod Patch: https://git.openjdk.java.net/jdk/pull/8509.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8509/head:pull/8509 PR: https://git.openjdk.java.net/jdk/pull/8509 From naoto at openjdk.java.net Mon May 2 21:37:33 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 2 May 2022 21:37:33 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: <6DXxFV1WxforfuzL0OuciwpGF7V4QTPZ9IDPyRNEa70=.47971c3c-a198-4a62-9717-f6c7b36cdac4@github.com> On Mon, 25 Apr 2022 08:15:18 GMT, Toshio Nakamura wrote: >> Japanese logical fonts are drawn with wrong size since Java 18. >> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding. >> >> Tested: jdk_desktop on Windows, Linux, and macOS > > Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: > > Moved the fix to WFontConfiguration I believe this is only reproducible on Japanese Windows, where the system locale is set to Japanese. You can emulate this by ControlPanel -> Region -> "Administrative" tab -> "Change system locale..." button -> "Current system locale" to `Japanese(Japan)` on an English Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From prr at openjdk.java.net Tue May 3 00:04:33 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 3 May 2022 00:04:33 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: <6QaCrme647cMf210vTFrJechKOKLiKhNsSXTpmX19yQ=.3ae0fc7c-f302-4f26-9a91-e8c2cd5f51d6@github.com> On Mon, 25 Apr 2022 08:15:18 GMT, Toshio Nakamura wrote: >> Japanese logical fonts are drawn with wrong size since Java 18. >> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding. >> >> Tested: jdk_desktop on Windows, Linux, and macOS > > Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: > > Moved the fix to WFontConfiguration Ah, because even in the JDK context the behaviour of the native Text Control in this respect is determined in part by the system locale, not just the JDK's idea of locale .. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From shurailine at openjdk.java.net Tue May 3 02:36:19 2022 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Tue, 3 May 2022 02:36:19 GMT Subject: RFR: 8282771 : Create test case for JDK-8262981 [v4] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 15:14:34 GMT, lawrence.andrews wrote: >> Following methods are covered in this testcase >> getAccessibleAction() >> getAccessibleActionCount() >> doAccessibleAction(int direction) >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comments LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/7734 From shurailine at openjdk.java.net Tue May 3 02:37:18 2022 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Tue, 3 May 2022 02:37:18 GMT Subject: RFR: 8284316 : Support accessibility ManualTestFrame.java for non SwingSet tests [v2] In-Reply-To: <_3KQsjqFELr9Pn_bUlpNkqUoFEfzFXrXDpjqSx6wKLE=.362fb0dc-c796-4748-9123-bf08e3ec51a2@github.com> References: <_3KQsjqFELr9Pn_bUlpNkqUoFEfzFXrXDpjqSx6wKLE=.362fb0dc-c796-4748-9123-bf08e3ec51a2@github.com> Message-ID: <6LuvuYLSeVJkmUcO3ortxbD5vJVtsMBbaf6p1f1j3HA=.a9881ad4-68b3-4977-83e8-1060d97e370d@github.com> On Thu, 7 Apr 2022 22:59:33 GMT, lawrence.andrews wrote: >> 1) Modified ManualTestFrame.java to support non SwingSet2 and this include modification of SwingSetTest.java >> 2) Added new TestJProgressBarAccessibility.java testcase that uses ManualTestFrame >> 3) Added timeout support in case user does not interact with the ManualTestFrame >> >> @shurymury >> @azuev-java > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - minor change > - Set Default timeout value as well as read as parameter LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/8100 From kizune at openjdk.java.net Tue May 3 05:04:22 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 3 May 2022 05:04:22 GMT Subject: RFR: 8284316 : Support accessibility ManualTestFrame.java for non SwingSet tests [v2] In-Reply-To: <_3KQsjqFELr9Pn_bUlpNkqUoFEfzFXrXDpjqSx6wKLE=.362fb0dc-c796-4748-9123-bf08e3ec51a2@github.com> References: <_3KQsjqFELr9Pn_bUlpNkqUoFEfzFXrXDpjqSx6wKLE=.362fb0dc-c796-4748-9123-bf08e3ec51a2@github.com> Message-ID: On Thu, 7 Apr 2022 22:59:33 GMT, lawrence.andrews wrote: >> 1) Modified ManualTestFrame.java to support non SwingSet2 and this include modification of SwingSetTest.java >> 2) Added new TestJProgressBarAccessibility.java testcase that uses ManualTestFrame >> 3) Added timeout support in case user does not interact with the ManualTestFrame >> >> @shurymury >> @azuev-java > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - minor change > - Set Default timeout value as well as read as parameter Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8100 From mbaesken at openjdk.java.net Tue May 3 07:04:56 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:04:56 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v2] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: set _WIN32_WINNT=0x0601 centrally in flags-cflags.m4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/aef2486f..dff223c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 3 07:10:58 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 07:10:58 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust Copyright year in wepoll.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/dff223c5..23b63c5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From serb at openjdk.java.net Tue May 3 08:03:23 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 May 2022 08:03:23 GMT Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12 [v2] In-Reply-To: <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com> References: <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com> Message-ID: On Thu, 21 Apr 2022 18:50:16 GMT, Alexander Zuev wrote: >> Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting keyboard events to the system queue. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Adding test case. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8320 From serb at openjdk.java.net Tue May 3 08:03:23 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 3 May 2022 08:03:23 GMT Subject: RFR: 8273506: java Robot API did the 'm' keypress and caused /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12 [v2] In-Reply-To: References: <33wbZN4ZDtQ564BCCatIOTX2sVRXi308jFUzKbKOaVE=.4ecfdde4-74ed-4319-bf86-492c3e47a32b@github.com> <37TufUb6JsjhJ_XeyGHMDcBKynjT8g6wUzw8klRoWOA=.fd51e990-f13a-47da-abb1-4fdda23aba65@github.com> Message-ID: <1C32WzcsGGJf3CLOXR5gQ4ZwLKvB7IuwDf67KvS5vy8=.f5e1a210-c24e-43c7-a94b-1b71f57cac21@github.com> On Wed, 27 Apr 2022 03:42:51 GMT, Alexander Zuev wrote: > d not. I probably will but it is unlikely it will be addressed quickly so fixing this issue on our side seems to be required anyways. Please add a "feedback id" to the JBS, so it will be possible to refer that macOS bug later. ------------- PR: https://git.openjdk.java.net/jdk/pull/8320 From alanb at openjdk.java.net Tue May 3 08:27:22 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 3 May 2022 08:27:22 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> On Thu, 28 Apr 2022 07:13:24 GMT, Matthias Baesken wrote: >> src/java.base/windows/native/libnio/ch/wepoll.c line 159: >> >>> 157: >>> 158: #undef _WIN32_WINNT >>> 159: #define _WIN32_WINNT 0x0601 >> >> This is 3rd party code and would prefer not change it if possible. > > Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From erikj at openjdk.java.net Tue May 3 13:17:21 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 3 May 2022 13:17:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c If we define this centrally using compiler flags, then we should not also update each location in the source. Those need to either be removed or left alone. In the cases where the source definition is guarded with an ifndef and there is a comment explaining why a particular version of windows is required, keeping it around could make sense. But on the other hand, since those defines are overridden using flags, they are likely to bit rot over time so we might as well just remove all of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From dholmes at openjdk.java.net Tue May 3 13:31:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 13:31:12 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Tue May 3 14:00:21 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 3 May 2022 14:00:21 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> References: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com> Message-ID: <09w3bQ6aE-0lywGwhamYkRZeizTLHpYID7C5dzyuzTc=.44290269-9308-4969-ac52-2f0423883b2b@github.com> On Tue, 3 May 2022 08:23:52 GMT, Alan Bateman wrote: >> Hi Alan, I agree (thats why I did not change the define in harfbuzz, but I missed that wepoll.c is 3rd party code as well). > > I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now. Yes sure I did it . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From kizune at openjdk.java.net Tue May 3 17:12:28 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 3 May 2022 17:12:28 GMT Subject: Integrated: 8273506: java Robot API did the 'm' keypress and caused /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12 In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 17:04:09 GMT, Alexander Zuev wrote: > Clear the kCGEventFlagMaskSecondaryFn flag if it is set before posting keyboard events to the system queue. This pull request has now been integrated. Changeset: 39e50c2d Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/39e50c2d6900d73ab7ac8604b79ca2b6e0661056 Stats: 105 lines in 2 files changed: 105 ins; 0 del; 0 mod 8273506: java Robot API did the 'm' keypress and caused /awt/event/KeyEvent/KeyCharTest/KeyCharTest.html is timing out on macOS 12 Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/8320 From aivanov at openjdk.java.net Tue May 3 21:34:22 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 3 May 2022 21:34:22 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v10] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 19:53:44 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > updated test I'm afraid the test fails for me: 120 130 2 Exception in thread "main" java.lang.RuntimeException: Border drawn too thick. at TitledBorderTest.checkBorder(TitledBorderTest.java:96) at TitledBorderTest.main(TitledBorderTest.java:79) ![The captured image](https://user-images.githubusercontent.com/70774172/166569052-3cd4b223-6943-4c06-8d6d-2d3534fbfbcf.png) Visually inspecting the frame produces the same results: the borders are still inconsistent, I verified 200% and 175%. The test still verifies only one case out of four. You use image to render and check, the frame is not necessary in this case and the test can be made headless. However, I'd like to still have the option to create the frame for visual inspection. The test code still indents by two spaces instead of four. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Tue May 3 21:46:10 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 3 May 2022 21:46:10 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: <3PGyBglBD6UxM1Ab2bro6niOZT4c4HSca19eLw7am5E=.b4696806-e442-4ace-bf70-0e041e22e23b@github.com> On Mon, 25 Apr 2022 08:15:18 GMT, Toshio Nakamura wrote: >> Japanese logical fonts are drawn with wrong size since Java 18. >> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding. >> >> Tested: jdk_desktop on Windows, Linux, and macOS > > Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: > > Moved the fix to WFontConfiguration It looks to me as if we specify a latin font as the text component font, some windows fall back behaviour insists on a minimum size for the Japanese fallback font. And the way to avoid that is to specify a locale (Japanese) font instead which is what used to happen. ------- Naoto suggested : -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol This did't work for me because it isn't picking up that line anyway So what I see is that MS Mincho isn't even in the list of names it is considering ! Because we are finding this :- sequence.allfonts=alphabetic/default,dingbats,symbol I see Toshio says he saw the UTF-8 entry being used, but I don't see that. So I need to understand why not the UTF-8 entry - note that I have set my system locale to JA now. The consequence of this is that the fallback sequence is what provides Japanese and so it is from the Chinese MingLiu-ExtB font which I do have installed. Toshio is right that what matters here for the native text component is what is picked up in the logic around WFontConfiguration.getTextComponentFontName() The helper method for getTextComponentFontName() is findFontWithCharset() That has a bit of a questionable behaviour in that it returns the *last* font in the list that matches the charset it wants. So *hypothetically* if we had the charset as DEFAULT_CHARSET MS Mincho,DEFAULT_CHARSET Times New Roman,DEFAULT_CHARSET and if we had Times New Roman,DEFAULT_CHARSET MS Mincho,SHIFTJIS_CHARSET then in both cases we'd get Times and still have the problem The latter case seems to actually happen - and so even though the font is there, we ignore it. Clearly what we want is the "locale" font, and we are using encoding to identify any one that matches but this breaks down in UTF8. Toshio pointed out that code in WFontConfiguration initTables() basically says if we found a font tagged as "japanese" then its subsetCharMap entry is SHIFTJIS_CHARSET and this used to work because this also mapped windows-31j to SHIFTJIS_CHARSET. But what do you map UTF-8 to ? The current code maps it to DEFAULT_CHARSET. There needs to be a different way of doing this for UTF-8 locales. So this fix is a "band aid" on the problem that in the UTF 8 locale we don't seem to be picking up the entry we should. If Toshio confirms for SURE he's seeing the UTF-8 one picked up it would be a useful data point. I still need to debug why I am not getting it. Regarding what Toshio pointed out that we can't have both sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-ms936,dingbats,symbol,chinese-ms936-extb sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-gb18030,dingbats,symbol,chinese-gb18030-extb I think that's just a fact. Once you choose UTF-8 you have to decide which of these you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From prr at openjdk.java.net Tue May 3 23:52:25 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 3 May 2022 23:52:25 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 09:37:10 GMT, Prasanta Sadhukhan wrote: > Test used to fail in specific CI macos M1 system owing to miniscule color difference > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > SInce we already have color-tolerance check present, there is no need of exact color value check. > Also, made the frame undecorated and remove unneeded library being built. > Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) This is occuring only on the M1 imac where despite having the right profile we see "off by 1/255" errors sometimes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From andrew at openjdk.java.net Wed May 4 01:43:24 2022 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Wed, 4 May 2022 01:43:24 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 20:12:52 GMT, Zhengyu Gu wrote: > > > > Hmmm, you are right. Phil probably pointed out the same problem, but I misunderstood it. > > What's odd is that, I tested (made sure that `FcCharSetDestroy` indeed called), it did not crash and `valgrind` showed the leak site disappeared. > > With your suggested fix, I think we still leak last `unionCharset`. BTW, the API documentation is really unhelpful, Sigh! That's fixed by your addition at the end, right? I assumed the final unionCharset was used for something, but it never seems to actually be read, just continually added to and then drops out of scope. It may also need to be freed in the `if (result != FcResultMatch) {` block which frees everything else and returns from within the inner loop. ------------- PR: https://git.openjdk.java.net/jdk/pull/8187 From psadhukhan at openjdk.java.net Wed May 4 05:27:25 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 4 May 2022 05:27:25 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 03:21:25 GMT, Tejesh R wrote: >> In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly > - Feature moved to ToolTipUI and updated MetalToolTipUI Accordingly Either that or if you can convert to automated, then it's better.. ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From duke at openjdk.java.net Wed May 4 05:55:16 2022 From: duke at openjdk.java.net (Tejesh R) Date: Wed, 4 May 2022 05:55:16 GMT Subject: RFR: 8134640 ( Left Insets Margin Test ) moved to open repo from closed [v2] In-Reply-To: <5gw_QjIeWEr1uUcAzT0x-xcEnwJKWXGBlVJBSY9o1_0=.1e01015f-91d7-42c6-bb9f-68482c7ad55f@github.com> References: <5gw_QjIeWEr1uUcAzT0x-xcEnwJKWXGBlVJBSY9o1_0=.1e01015f-91d7-42c6-bb9f-68482c7ad55f@github.com> Message-ID: > The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Copyright Year updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8500/files - new: https://git.openjdk.java.net/jdk/pull/8500/files/94c9ea32..68a77836 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8500&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8500&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8500/head:pull/8500 PR: https://git.openjdk.java.net/jdk/pull/8500 From mbaesken at openjdk.java.net Wed May 4 07:37:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:37:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust Copyright year in wepoll.c Interesting fact : we run now into this compile error : d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1262): error C2065: 'NCRYPT_CIPHER_KEY_BLOB': undeclared identifier d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1280): error C2065: 'NCRYPT_PROTECTED_KEY_BLOB': undeclared identifier Reason seems that already for some time ( at least OpenJDK 11 (!) ) we have an implicit minimum requirement of Windows 8 / Windows 2012 APIs for this code, so enforcing Win 7 is too old : https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptexportkey NCRYPT_PROTECTED_KEY_BLOB Export a protected key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. NCRYPT_CIPHER_KEY_BLOB Export a cipher key in a NCRYPT_KEY_BLOB_HEADER structure. Windows 8 and Windows Server 2012: Support for this value begins. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 07:42:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 07:42:14 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3] In-Reply-To: References: Message-ID: <9KE3CEXRqW4z5bQgy9E5ydrFvcxY4LgV9zA-KGRH09M=.e21bbecb-5e37-4887-9a74-7e4227c70c07@github.com> On Tue, 3 May 2022 13:27:41 GMT, David Holmes wrote: > I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected? > > I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ... > > and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ? Hi David, I agree the other locations as long as they are not 3rd party code should be cleaned up. Someone using an API that is only available in later Windows versions would get a redefinition warning as long as no undefine is done. But we have to set _WIN32_WINNT anyway to a higher value (windows8, I think that's 0x0602) to compile src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp . ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From psadhukhan at openjdk.java.net Wed May 4 07:46:17 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 4 May 2022 07:46:17 GMT Subject: RFR: 8134640 ( Left Insets Margin Test ) moved to open repo from closed [v2] In-Reply-To: References: <5gw_QjIeWEr1uUcAzT0x-xcEnwJKWXGBlVJBSY9o1_0=.1e01015f-91d7-42c6-bb9f-68482c7ad55f@github.com> Message-ID: On Wed, 4 May 2022 05:55:16 GMT, Tejesh R wrote: >> The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Copyright Year updated test/jdk/javax/swing/JRadioButton/4380543/bug4380543.java line 2: > 1: /* > 2: * Copyright (c) 2002,2022, Oracle and/or its affiliates. All rights reserved. guess there should be a space between 2002, and 2022 else validate-source task might fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/8500 From duke at openjdk.java.net Wed May 4 07:48:17 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Wed, 4 May 2022 07:48:17 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v3] In-Reply-To: References: Message-ID: <5s-Ai3c0nGi0S-GWRkS9qqdeHEIB7p_Bjy5GPoKn0jQ=.cec42afa-e837-4503-b749-2125956937ce@github.com> > Hello, > Please review this fix for JDK-8282863. > > The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. > > The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: > > 1. `java.awt.Frame` is created and set as full-screen. > 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. > 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. > 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: > 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. > 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. > 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. > 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. > 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. > 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. > 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. > > Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. > > I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: Update the JavaDoc for added method ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7835/files - new: https://git.openjdk.java.net/jdk/pull/7835/files/cab8c316..008e9c19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7835&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7835&range=01-02 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7835.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7835/head:pull/7835 PR: https://git.openjdk.java.net/jdk/pull/7835 From mbaesken at openjdk.java.net Wed May 4 08:00:08 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 08:00:08 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: Message-ID: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust API level to Windows 8 for security.cpp and do some cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8428/files - new: https://git.openjdk.java.net/jdk/pull/8428/files/23b63c5b..721528c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8428&range=02-03 Stats: 31 lines in 7 files changed: 1 ins; 26 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428 PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Wed May 4 08:03:28 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Wed, 4 May 2022 08:03:28 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 11:03:37 GMT, Alexey Ivanov wrote: >> Dmitry Kulikov has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen >> - Revert "8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen" >> >> This reverts commit 23b40af8de9df4db9a1cc0137c0e875cf6595190. > > src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java line 447: > >> 445: >> 446: /** >> 447: * Reapplies the size of this device to the full-screen window. > > What is _this device_? There's no device in the parameters of the method. > > If you write javadoc, you should document the parameters too. @aivanov-jdk I've updated the JavaDoc to more specifically reference the GraphicsDevice that owns the added method (and documented the parameters) ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From mvs at openjdk.java.net Wed May 4 08:08:43 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Wed, 4 May 2022 08:08:43 GMT Subject: RFR: 8030121: java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java fails Message-ID: Removing MissingDragExitEventTest.java from ProblemList as JDK-8274597 already fixed the test and it's working fine now. Testing: MissingDragExitEventTest.java test has been run 10 times on all 3 platforms and got all Pass. ------------- Commit messages: - Removing MissingDragExitEventTest.java from ProblemList as JDK-8274597 already fixed the test and it's working fine now Changes: https://git.openjdk.java.net/jdk/pull/8529/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8529&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8030121 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8529.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8529/head:pull/8529 PR: https://git.openjdk.java.net/jdk/pull/8529 From duke at openjdk.java.net Wed May 4 08:14:12 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Wed, 4 May 2022 08:14:12 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v3] In-Reply-To: <5s-Ai3c0nGi0S-GWRkS9qqdeHEIB7p_Bjy5GPoKn0jQ=.cec42afa-e837-4503-b749-2125956937ce@github.com> References: <5s-Ai3c0nGi0S-GWRkS9qqdeHEIB7p_Bjy5GPoKn0jQ=.cec42afa-e837-4503-b749-2125956937ce@github.com> Message-ID: On Wed, 4 May 2022 07:48:17 GMT, Dmitry Kulikov wrote: >> Hello, >> Please review this fix for JDK-8282863. >> >> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. >> >> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: >> >> 1. `java.awt.Frame` is created and set as full-screen. >> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. >> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. >> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: >> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. >> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. >> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. >> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. >> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. >> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. >> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. >> >> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. >> >> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. > > Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: > > Update the JavaDoc for added method @aivanov-jdk @mrserb I've updated the PR according to your suggestions, could you please take another look? ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From duke at openjdk.java.net Wed May 4 08:14:12 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Wed, 4 May 2022 08:14:12 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 22:19:26 GMT, Sergey Bylokhov wrote: >> Dmitry Kulikov has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen >> - Revert "8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen" >> >> This reverts commit 23b40af8de9df4db9a1cc0137c0e875cf6595190. > > src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java line 482: > >> 480: // Note: window will get resized to actual full-screen dimensions >> 481: // in the upcoming display change event, when the DPI scales >> 482: // would already be correctly set etc. (see JDK-8282863) > > We usually do not mention the bugid in the comments, just the description of how it works is fine. @mrserb the mentioned bugid reference is now removed ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From dholmes at openjdk.java.net Wed May 4 08:38:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 08:38:24 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Wed May 4 09:11:17 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 4 May 2022 09:11:17 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:34:43 GMT, David Holmes wrote: > I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? I found this info here https://stackoverflow.com/questions/37668692/visual-studio-setting-winver-win32-winnt-to-windows-8-on-windows-7 "VS 2012 uses the Windows 8.0 SDK which defaults to _WIN32_WINNT=0x0602 (Windows 8). VS 2013 / 2015 uses the Windows 8.1 SDK which defaults to _WIN32_WINNT=0x0603 (Windows 8.1). If you use VS 2015 and the Windows 10 SDK, it defaults to _WIN32_WINNT=0x0A00 (Windows 10)." So it seems you get some more or less recent default when working with a not too old compiler/SDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From psadhukhan at openjdk.java.net Wed May 4 11:04:50 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 4 May 2022 11:04:50 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v2] In-Reply-To: References: Message-ID: > Test used to fail in specific CI macos M1 system owing to miniscule color difference > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > SInce we already have color-tolerance check present, there is no need of exact color value check. > Also, made the frame undecorated and remove unneeded library being built. > Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Reduce color tolerance ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8380/files - new: https://git.openjdk.java.net/jdk/pull/8380/files/c48274ad..a04c742b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8380/head:pull/8380 PR: https://git.openjdk.java.net/jdk/pull/8380 From psadhukhan at openjdk.java.net Wed May 4 11:04:51 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 4 May 2022 11:04:51 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." In-Reply-To: References: Message-ID: On Tue, 3 May 2022 23:49:22 GMT, Phil Race wrote: > This is occurring only on the M1 imac where despite having the right profile we see "off by 1/255" errors sometimes. So why do we need a color tolerance of 25 ? Why isn't it 1 ? It was there from start so did not tinker although I tested with tolerance of 10 which passed. Anyway, I have changed it to 1 which also passed in the intended system and all other platforms (CI job link in JBS) ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From psadhukhan at openjdk.java.net Wed May 4 11:26:45 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 4 May 2022 11:26:45 GMT Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java fails in macos12 Message-ID: 2 open tests were seen to be failing in macos12 which happen to have same root cause as 8273506: java Robot API did the 'm' keypress and caused /awt/event/Ke.... With that fix being committed, testing on intended macos12 systems are not able to reproduce this failures so we can remove from Problemlist. CI jobs links are in JBS. ------------- Commit messages: - 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java fails in macos12 Changes: https://git.openjdk.java.net/jdk/pull/8532/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8532&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278348 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8532.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8532/head:pull/8532 PR: https://git.openjdk.java.net/jdk/pull/8532 From dcubed at openjdk.java.net Wed May 4 14:44:26 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 14:44:26 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:00:43 GMT, Prasanta Sadhukhan wrote: >> This is occurring only on the M1 imac where despite having the right profile we see "off by 1/255" errors sometimes. >> So why do we need a color tolerance of 25 ? Why isn't it 1 ? > >> This is occurring only on the M1 imac where despite having the right profile we see "off by 1/255" errors sometimes. So why do we need a color tolerance of 25 ? Why isn't it 1 ? > > It was there from start so did not tinker although I tested with tolerance of 10 (which is the default tolerance used in other tests) which passed. Anyway, I have changed it to 1 which also passed in the intended system and all other platforms (CI job link in JBS) @prsadhuk and @prrace, We have 8 sightings of this failure mode on macosx-aarch64 in the jdk/jdk and loom CIs. I'm about to start my noise suppression phase in preparation for the potential Loom VT integration this weekend. Will this (potential) fix be integrated soon or should I go ahead and ProblemList this test on macosx-aarch64? ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From aivanov at openjdk.java.net Wed May 4 15:13:20 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 4 May 2022 15:13:20 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v10] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 21:31:18 GMT, Alexey Ivanov wrote: > The test still verifies only one case out of four. You use image to render and check, the frame is not necessary in this case and the test can be made headless. However, I'd like to still have the option to create the frame for visual inspection. I am sorry, I didn't read the code thoroughly: it does verify all four panels. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Wed May 4 15:19:31 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 4 May 2022 15:19:31 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v8] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 23:35:10 GMT, lukeu wrote: > > Made a small change with the bottom line to match the left line of the border > > Great, that looks like it'll fix it so I won't test again, I'll defer to the others now for the code review. (I'd be happy to chip in there too, but I'm not sure if "random guy on github" is qualified/authorized to?) I think it's perfectly okay for you, @lukeu, to approve this suggested fix. You actively participated in the discussion and performed testing of the fix, which makes you not so random in regards to this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From tnakamura at openjdk.java.net Wed May 4 15:34:29 2022 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Wed, 4 May 2022 15:34:29 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v3] In-Reply-To: References: Message-ID: > Japanese logical fonts are drawn with wrong size since Java 18. > It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding. > > Tested: jdk_desktop on Windows, Linux, and macOS Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: locale base fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8329/files - new: https://git.openjdk.java.net/jdk/pull/8329/files/2a409cc6..4297e21f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8329&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8329&range=01-02 Stats: 40 lines in 2 files changed: 1 ins; 19 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/8329.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8329/head:pull/8329 PR: https://git.openjdk.java.net/jdk/pull/8329 From tnakamura at openjdk.java.net Wed May 4 15:39:28 2022 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Wed, 4 May 2022 15:39:28 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: <3PGyBglBD6UxM1Ab2bro6niOZT4c4HSca19eLw7am5E=.b4696806-e442-4ace-bf70-0e041e22e23b@github.com> References: <3PGyBglBD6UxM1Ab2bro6niOZT4c4HSca19eLw7am5E=.b4696806-e442-4ace-bf70-0e041e22e23b@github.com> Message-ID: <5voTECmLJIAa9zLZiI-Z3WavNqIpEtB4PmdATSP7wTY=.926f621b-eeda-41c3-b3ff-c075684ef4e7@github.com> On Tue, 3 May 2022 21:42:35 GMT, Phil Race wrote: >> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the fix to WFontConfiguration > > It looks to me as if we specify a latin font as the text component font, some windows fall back behaviour insists > on a minimum size for the Japanese fallback font. > And the way to avoid that is to specify a locale (Japanese) font instead which is what used to happen. > > ------- > Naoto suggested : > -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol > +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol > > This did't work for me because it isn't picking up that line anyway > > So what I see is that MS Mincho isn't even in the list of names it is considering ! > Because we are finding this :- > sequence.allfonts=alphabetic/default,dingbats,symbol > > I see Toshio says he saw the UTF-8 entry being used, but I don't see that. > So I need to understand why not the UTF-8 entry - note that I have set my system locale to JA now. > The consequence of this is that the fallback sequence is what provides Japanese and > so it is from the Chinese MingLiu-ExtB font which I do have installed. > > > Toshio is right that what matters here for the native text component is what is picked up in > the logic around WFontConfiguration.getTextComponentFontName() > > The helper method for getTextComponentFontName() is findFontWithCharset() > > That has a bit of a questionable behaviour in that it returns the *last* font in the > list that matches the charset it wants. > So *hypothetically* if we had the charset as DEFAULT_CHARSET > MS Mincho,DEFAULT_CHARSET > Times New Roman,DEFAULT_CHARSET > and if we had > Times New Roman,DEFAULT_CHARSET > MS Mincho,SHIFTJIS_CHARSET > > then in both cases we'd get Times and still have the problem > The latter case seems to actually happen - and so even though the font is there, we ignore it. > Clearly what we want is the "locale" font, and we are using encoding to identify any one > that matches but this breaks down in UTF8. > Toshio pointed out that code in WFontConfiguration initTables() basically says > if we found a font tagged as "japanese" then its subsetCharMap entry is SHIFTJIS_CHARSET > and this used to work because this also mapped windows-31j to SHIFTJIS_CHARSET. > But what do you map UTF-8 to ? The current code maps it to DEFAULT_CHARSET. > There needs to be a different way of doing this for UTF-8 locales. > > So this fix is a "band aid" on the problem that in the UTF 8 locale we don't seem to be picking > up the entry we should. > If Toshio confirms for SURE he's seeing the UTF-8 one picked up it would be a useful data point. > I still need to debug why I am not getting it. > > UPDATE: pilot error on my part - I set lang to jp .. not ja .. > > So back to just the encoding case .. > > Regarding what Toshio pointed out that we can't have both > sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-ms936,dingbats,symbol,chinese-ms936-extb > sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-gb18030,dingbats,symbol,chinese-gb18030-extb > I think that's just a fact. Once you choose UTF-8 you have to decide which of these you want. Hi @prrace Yes, my system also picked up "UTF-8.ja" line. "ja" can be specified by locale data, such as "-Duser.language=ja". However, I was not able to recreate the wrong size issue on the system which changed the primary language from English to Japanese. There may be differences between pure Japanese Windows and English Windows changed the primary language to Japanese. Unicode (UTF-8) is language independent. So, we need to use a locale data. I created a trial patch to use locale data. If you prefer this way, I'll also adjust fontconfig file and test some environments I can prepare. > sequence.allfonts=alphabetic/default,dingbats,symbol "alphabetic/default" assigned to "DEFAULT_CHARSET", but it's only used on this line. > sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol "alphabetic" assigned to "ANSI_CHARSET". So, if we had "DEFAULT_CHARSET", nothing was matched. Then, the first one was used. (WFontConfiguration.java, l.165) ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From aivanov at openjdk.java.net Wed May 4 16:25:31 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 4 May 2022 16:25:31 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v10] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 19:53:44 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > updated test I was worried that had missed something when I tested it yesterday and I re-built and ran the tests once again. The test still fails for me, more on it later. I commented out disposing of the frame and I see issues with border rendering too. The border renders correctly at 150% and 175%. Yet at 200%, some parts of the border are rendered as 1-pixel line and some are 2-pixel line. That's the problem we're trying to fix. As for the failing test, I noticed that the saved image is different from what I see on the screen especially when the uiScale is different from 1.5 which is used in the test. I can't explain it; it could be the result of rendering the frame on main thread after it was laid out on the EDT. I played around with border rendering myself. To get exact lines, I always use 1-pixel stroke. At first I used two rectangles to render the border. It's simple and it gives good enough result, however it leaves some pixels painted with background colour. Then I reimplemented painting to the way browsers render `groove` and `ridge` border. ([Try it](https://developer.mozilla.org/en-US/docs/web/css/border-style#try_it).) I believe, @lukeu mentioned it in one of his comments. The border uiScale=4.0 looks like this: ![EtchedBorder rendered at 400%](https://user-images.githubusercontent.com/70774172/166720386-5a58e4b5-9ec7-43bd-8b34-67861a496361.png) I pushed the code for it to [alisen-8279614-border](https://github.com/aivanov-jdk/jdk/commits/alisen-8279614-border) branch. You can get it for testing using these commands: git fetch https://github.com/aivanov-jdk/jdk alisen-8279614-border git checkout alisen-8279614-border You can also [compare my branch to this PR](https://github.com/openjdk/jdk/compare/pr/7449...aivanov-jdk:alisen-8279614-border), which should give you a quick overview of the differences. At 150% and 175%, the border looks like this: ![EtchedBorder rendered at 150%](https://user-images.githubusercontent.com/70774172/166722510-e8fe6839-8820-451e-8434-f07b797edfed.png) ![EtchedBorder rendered at 175%](https://user-images.githubusercontent.com/70774172/166722689-928409f2-c51f-4e4d-a476-b7e50c524f19.png) The cyan colour is the background colour of the child panel in the test. It highlights rounding off to coordinates. The fourth panel in the 175% case lacks the yellow highlight on the right; at the same time, there are two cyan pixels. The highlight is likely painted outside of the panel clip. It may happen to bottom edge too. When I set `uiScale` to 1.0, the frame is displayed like this initially: ![Rendering bug at uiScale=1.0](https://user-images.githubusercontent.com/70774172/166723618-a61e2a0d-c61d-4177-9961-3d6f07670f3e.png) Weird, isn't it? After minimizing and restoring the window, it's painted correctly: ![Repainted at uiScale=1.0](https://user-images.githubusercontent.com/70774172/166723989-516644f9-9ffc-40f7-bf88-879fd2d8aef2.png) I can't understand why it happens? As for the test, I reformatted the code to use 4-space indents, changed the colours to stand out (white is too close to the grey background colour). The still fails with my implementation of border painting. It could be because there are some cyan background pixels where the test expects border? I haven't looked into it. The test needs updating. For each panel, it should verify _each edge_ has the correct thickness of both shadow and highlight colours. I still think the test can be made headless. Paint `content` panel to buffered image rather than the frame. Since we've seen different artefacts with different scales, the test should verify rendering at 1.0, 1.25, 1.5, 1.75, 2.0 rather than 1.5 only. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Wed May 4 16:29:46 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 4 May 2022 16:29:46 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v10] In-Reply-To: References: Message-ID: <5ZLOC3dGfSN7MBA_bh8QXQRZ_nMy-gZ4QVjg5AM4fXE=.7bc3a528-c8ef-432e-9f78-0ae9f064fe0c@github.com> On Mon, 2 May 2022 19:53:44 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > updated test src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 179: > 177: > 178: g.translate(-((int) (at.getScaleX()*x+at.getTranslateX())), > 179: -((int) (at.getScaleY()*y+at.getTranslateY()))); You used different values to move the translate at lines 170-171: `Math.ceil` is missing here. It's better to save the values above to make sure the translate is restored correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From dcubed at openjdk.java.net Wed May 4 16:40:27 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 16:40:27 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:04:50 GMT, Prasanta Sadhukhan wrote: >> Test used to fail in specific CI macos M1 system owing to miniscule color difference >> >> >> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 >> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 >> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 >> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 >> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 >> >> >> SInce we already have color-tolerance check present, there is no need of exact color value check. >> Also, made the frame undecorated and remove unneeded library being built. >> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reduce color tolerance I will be integrating a ProblemListing for javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 shortly. Please update this PR to include that ProblemListing changeset and then UnProblemList the test in the PR so that the test runs in your pre-integration testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From dcubed at openjdk.java.net Wed May 4 16:42:08 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 Message-ID: A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. ------------- Commit messages: - 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/8538/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8538&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286138 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8538.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8538/head:pull/8538 PR: https://git.openjdk.java.net/jdk/pull/8538 From bpb at openjdk.java.net Wed May 4 16:42:08 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From dcubed at openjdk.java.net Wed May 4 16:42:08 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:33:43 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From dcubed at openjdk.java.net Wed May 4 16:42:08 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 16:42:08 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. This pull request has now been integrated. Changeset: 497a94fe Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/497a94fead145788af6f196d2c7166efc46a9e9e Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From prr at openjdk.java.net Wed May 4 16:51:26 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 16:51:26 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: <3PGyBglBD6UxM1Ab2bro6niOZT4c4HSca19eLw7am5E=.b4696806-e442-4ace-bf70-0e041e22e23b@github.com> References: <3PGyBglBD6UxM1Ab2bro6niOZT4c4HSca19eLw7am5E=.b4696806-e442-4ace-bf70-0e041e22e23b@github.com> Message-ID: On Tue, 3 May 2022 21:42:35 GMT, Phil Race wrote: >> Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved the fix to WFontConfiguration > > It looks to me as if we specify a latin font as the text component font, some windows fall back behaviour insists > on a minimum size for the Japanese fallback font. > And the way to avoid that is to specify a locale (Japanese) font instead which is what used to happen. > > ------- > Naoto suggested : > -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol > +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol > > This did't work for me because it isn't picking up that line anyway > > So what I see is that MS Mincho isn't even in the list of names it is considering ! > Because we are finding this :- > sequence.allfonts=alphabetic/default,dingbats,symbol > > I see Toshio says he saw the UTF-8 entry being used, but I don't see that. > So I need to understand why not the UTF-8 entry - note that I have set my system locale to JA now. > The consequence of this is that the fallback sequence is what provides Japanese and > so it is from the Chinese MingLiu-ExtB font which I do have installed. > > > Toshio is right that what matters here for the native text component is what is picked up in > the logic around WFontConfiguration.getTextComponentFontName() > > The helper method for getTextComponentFontName() is findFontWithCharset() > > That has a bit of a questionable behaviour in that it returns the *last* font in the > list that matches the charset it wants. > So *hypothetically* if we had the charset as DEFAULT_CHARSET > MS Mincho,DEFAULT_CHARSET > Times New Roman,DEFAULT_CHARSET > and if we had > Times New Roman,DEFAULT_CHARSET > MS Mincho,SHIFTJIS_CHARSET > > then in both cases we'd get Times and still have the problem > The latter case seems to actually happen - and so even though the font is there, we ignore it. > Clearly what we want is the "locale" font, and we are using encoding to identify any one > that matches but this breaks down in UTF8. > Toshio pointed out that code in WFontConfiguration initTables() basically says > if we found a font tagged as "japanese" then its subsetCharMap entry is SHIFTJIS_CHARSET > and this used to work because this also mapped windows-31j to SHIFTJIS_CHARSET. > But what do you map UTF-8 to ? The current code maps it to DEFAULT_CHARSET. > There needs to be a different way of doing this for UTF-8 locales. > > So this fix is a "band aid" on the problem that in the UTF 8 locale we don't seem to be picking > up the entry we should. > If Toshio confirms for SURE he's seeing the UTF-8 one picked up it would be a useful data point. > I still need to debug why I am not getting it. > > UPDATE: pilot error on my part - I set lang to jp .. not ja .. > > So back to just the encoding case .. > > Regarding what Toshio pointed out that we can't have both > sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-ms936,dingbats,symbol,chinese-ms936-extb > sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-gb18030,dingbats,symbol,chinese-gb18030-extb > I think that's just a fact. Once you choose UTF-8 you have to decide which of these you want. > Hi @prrace > > Yes, my system also picked up "UTF-8.ja" line. "ja" can be specified by locale data, such as "-Duser.language=ja". > Yes, so did I after I fixed my typo. > However, I was not able to recreate the wrong size issue on the system which changed the primary language from English to Japanese. There may be differences between pure Japanese Windows and English Windows changed the primary language to Japanese. I definitely can reproduce this on my "English" windows by changing the system locale. > > Unicode (UTF-8) is language independent. So, we need to use a locale data. I created a trial patch to use locale data. If you prefer this way, If you mean those changes you have in this latest diff then I was thinking of something like that .. although not exactly. I'll also adjust fontconfig file and test some environments I can prepare. I'm not sure what fontconfig changes you are thinking of. > > > sequence.allfonts=alphabetic/default,dingbats,symbol > > "alphabetic/default" assigned to "DEFAULT_CHARSET", but it's only used on this line. > > > sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol > > "alphabetic" assigned to "ANSI_CHARSET". So, if we had "DEFAULT_CHARSET", nothing was matched. Then, the first one was used. (WFontConfiguration.java, l.165) Yes, I think we have issues there I'd like to look closely at. Really, I am at the point where I'd like to say "thank you for drawing this to our attention, but I'd prefer to do this fix myself" I can forsee a bunch of follow up work that we might want to do over time. This change to UTF-8 seems to be very impactful on this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From prr at openjdk.java.net Wed May 4 16:54:41 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 16:54:41 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: <3WoULE1UGIQ61UyWkiYyBONDsVjO6qHvAdAlkjiSO7Q=.73befc00-a227-423e-981a-1b65e9529d0f@github.com> On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. I didn't see the need to PL this. There's a fix under review ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From prr at openjdk.java.net Wed May 4 16:54:41 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 16:54:41 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:04:50 GMT, Prasanta Sadhukhan wrote: >> Test used to fail in specific CI macos M1 system owing to miniscule color difference >> >> >> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 >> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 >> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 >> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 >> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 >> >> >> SInce we already have color-tolerance check present, there is no need of exact color value check. >> Also, made the frame undecorated and remove unneeded library being built. >> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reduce color tolerance I believe this fix should be integrated before the weekend so there is no need to PL. We can do that if it is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From prr at openjdk.java.net Wed May 4 17:12:26 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 17:12:26 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:00:43 GMT, Prasanta Sadhukhan wrote: > > This is occurring only on the M1 imac where despite having the right profile we see "off by 1/255" errors sometimes. So why do we need a color tolerance of 25 ? Why isn't it 1 ? > > It was there from start so did not tinker although I tested with tolerance of 10 (which is the default tolerance used in other tests) which passed. Anyway, I have changed it to 1 which also passed in the intended system and all other platforms (CI job link in JBS) Yes .. I went back and looked at the thread started here : https://mail.openjdk.java.net/pipermail/swing-dev/2016-January/005286.html and it was in the first webrev and no one ever questioned why it was needed .. perhaps some shadow effects were touching on the icon which is near the edge of the top-level window but that could be cured easily in this test which is for JInternalFrame .. if it were actually an issue .. ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From prr at openjdk.java.net Wed May 4 17:27:25 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 17:27:25 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:04:50 GMT, Prasanta Sadhukhan wrote: >> Test used to fail in specific CI macos M1 system owing to miniscule color difference >> >> >> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 >> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 >> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 >> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 >> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 >> >> >> SInce we already have color-tolerance check present, there is no need of exact color value check. >> Also, made the frame undecorated and remove unneeded library being built. >> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reduce color tolerance OK so .. there's a difficulty facing this test. It has NO idea where the icon is. It randomly captures a chunk of the title bar and for Aqua it doesn't even come close to grabbing a single pixel of the icon - it is 100 pixels or more off. So we are not comparing what we want to be comparing. It is pointless. I think you need to come up with a way to make sure you are grabbing the right place which is L&F dependent ... If you can't then you might as well scrap this useless test which is really just comparing pixels from the title bar. ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From kizune at openjdk.java.net Wed May 4 18:01:35 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 4 May 2022 18:01:35 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Mon, 2 May 2022 21:02:02 GMT, Harshitha Onkar wrote: > This test case tests the functionality of `setAlwaysOnTop`. > Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) > > The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. > > The test case tests `alwaysOnTop` for the following three cases: > > 1. JDialog with no parent/owner > 2. JDialog with JFrame as owner > 3. JDialog with another JDialog as owner > > Each of the three cases mentioned above is tested under 3 scenarios: > ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) test/jdk/java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java line 165: > 163: throw new RuntimeException("Scenario 1: alwaysOnTop window is "+ > 164: "sent back by another child window with setVisible(). " > 165: + color); I see that we are doing a number of test scenarios but test fails immediately when first error occurs. Can we continue testing, save all screenshots and remember all the failures and then fail at the end if there were errors listing all the errors in all the LaF's that were happened during the run? ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From duke at openjdk.java.net Wed May 4 18:06:26 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Wed, 4 May 2022 18:06:26 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Wed, 4 May 2022 17:58:17 GMT, Alexander Zuev wrote: >> This test case tests the functionality of `setAlwaysOnTop`. >> Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) >> >> The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. >> >> The test case tests `alwaysOnTop` for the following three cases: >> >> 1. JDialog with no parent/owner >> 2. JDialog with JFrame as owner >> 3. JDialog with another JDialog as owner >> >> Each of the three cases mentioned above is tested under 3 scenarios: >> ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) > > test/jdk/java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java line 165: > >> 163: throw new RuntimeException("Scenario 1: alwaysOnTop window is "+ >> 164: "sent back by another child window with setVisible(). " >> 165: + color); > > I see that we are doing a number of test scenarios but test fails immediately when first error occurs. Can we continue testing, save all screenshots and remember all the failures and then fail at the end if there were errors listing all the errors in all the LaF's that were happened during the run? @azuev-java Thank you for the suggestion. I can definitely add this functionality to the test for better failure analysis. ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From prr at openjdk.java.net Wed May 4 18:13:16 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 18:13:16 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:02:48 GMT, Harshitha Onkar wrote: >> test/jdk/java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java line 165: >> >>> 163: throw new RuntimeException("Scenario 1: alwaysOnTop window is "+ >>> 164: "sent back by another child window with setVisible(). " >>> 165: + color); >> >> I see that we are doing a number of test scenarios but test fails immediately when first error occurs. Can we continue testing, save all screenshots and remember all the failures and then fail at the end if there were errors listing all the errors in all the LaF's that were happened during the run? > > @azuev-java Thank you for the suggestion. I can definitely add this functionality to the test for better failure analysis. I think that's a reasonable suggestion in general to bear in mind when writing tests. I've seen tests which bail at the first failure and you wish you knew how the rest of it worked out .. Like (say) a test that iterates over the 4 available L&Fs might be a case. ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From dcubed at openjdk.java.net Wed May 4 18:17:17 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 4 May 2022 18:17:17 GMT Subject: Integrated: 8286138: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:32:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on macosx-aarch64. This would be why I pinged in https://github.com/openjdk/jdk/pull/8380 this morning. That PR has been under review for more than a week and it wasn't clear to me from the comments that it was going to reach resolution soon. So.... I pinged @prrace and @prsadhuk in that PR and then waited a couple of hours before I created a ProblemListing PR. It should very easy to to merge in the ProblemListing changeset and then UnProblemList the test in https://github.com/openjdk/jdk/pull/8380. ------------- PR: https://git.openjdk.java.net/jdk/pull/8538 From duke at openjdk.java.net Wed May 4 18:19:15 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Wed, 4 May 2022 18:19:15 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:10:03 GMT, Phil Race wrote: >> @azuev-java Thank you for the suggestion. I can definitely add this functionality to the test for better failure analysis. > > I think that's a reasonable suggestion in general to bear in mind when writing tests. > I've seen tests which bail at the first failure and you wish you knew how the rest of it worked out .. > Like (say) a test that iterates over the 4 available L&Fs might be a case. @prrace Thank you for the inputs. Will make a note to add it for future similar test scenarios too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From prr at openjdk.java.net Wed May 4 19:57:27 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 19:57:27 GMT Subject: RFR: 8285397: JNI exception pending in CUPSfuncs.c:250 In-Reply-To: <1yuuuL_U9TZe4yoCJsFA3cLjFpW4aZWng8GhQ0ta6Bk=.f9718b9a-6a60-4b3d-ad6a-a53125566c66@github.com> References: <1yuuuL_U9TZe4yoCJsFA3cLjFpW4aZWng8GhQ0ta6Bk=.f9718b9a-6a60-4b3d-ad6a-a53125566c66@github.com> Message-ID: <8rYxwP8XBwszkqP7a6uub8dn12lYxu-9emXhW8iTmng=.a9855d6c-ffed-458f-8dff-b03a4efbbde4@github.com> On Mon, 2 May 2022 07:19:29 GMT, Prasanta Sadhukhan wrote: >> A tool checking for JNI errors complains that the call to JNU_NewStringPlatform(..) >> might throw an exception and subsequent JNI code isn't making sure of that. >> Clear the exception so the error handling code can do its thing. > > src/java.desktop/unix/native/common/awt/CUPSfuncs.c line 249: > >> 247: utf_str = JNU_NewStringPlatform(env, dests[i].name); >> 248: if (utf_str == NULL) { >> 249: (*env)->ExceptionClear(env); > > Shouldn't we also need to do same in https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/native/common/awt/CUPSfuncs.c#L357, L367, L381 since we do at L348 Nothing changed there, there's no complaint about that. Perhaps the tool thinks it is OK to make the call to throw another exception ? I'll ask about that. FWIW if I go making changes to these places where there is no complaint I don't think I'd automatically clear an exception in order to throw a different one .. I'd prefer to propagate the original. ------------- PR: https://git.openjdk.java.net/jdk/pull/8491 From prr at openjdk.java.net Wed May 4 20:14:35 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 20:14:35 GMT Subject: RFR: 8285397: JNI exception pending in CUPSfuncs.c:250 [v2] In-Reply-To: References: Message-ID: > A tool checking for JNI errors complains that the call to JNU_NewStringPlatform(..) > might throw an exception and subsequent JNI code isn't making sure of that. > Clear the exception so the error handling code can do its thing. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8285399 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8491/files - new: https://git.openjdk.java.net/jdk/pull/8491/files/d35677c6..a4c0f55d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8491&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8491&range=00-01 Stats: 15 lines in 1 file changed: 9 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8491/head:pull/8491 PR: https://git.openjdk.java.net/jdk/pull/8491 From duke at openjdk.java.net Wed May 4 22:39:12 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Wed, 4 May 2022 22:39:12 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v2] In-Reply-To: References: Message-ID: > This test case tests the functionality of `setAlwaysOnTop`. > Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) > > The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. > > The test case tests `alwaysOnTop` for the following three cases: > > 1. JDialog with no parent/owner > 2. JDialog with JFrame as owner > 3. JDialog with another JDialog as owner > > Each of the three cases mentioned above is tested under 3 scenarios: > ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: added changes to continue testing and exception thrown at end in case of failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8509/files - new: https://git.openjdk.java.net/jdk/pull/8509/files/1b7e59fe..396d5659 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=00-01 Stats: 89 lines in 1 file changed: 41 ins; 39 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8509.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8509/head:pull/8509 PR: https://git.openjdk.java.net/jdk/pull/8509 From duke at openjdk.java.net Wed May 4 22:39:12 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Wed, 4 May 2022 22:39:12 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:15:10 GMT, Harshitha Onkar wrote: >> I think that's a reasonable suggestion in general to bear in mind when writing tests. >> I've seen tests which bail at the first failure and you wish you knew how the rest of it worked out .. >> Like (say) a test that iterates over the 4 available L&Fs might be a case. > > @prrace Thank you for the inputs. Will make a note to add it for future similar test scenarios too. Updated test case to continue testing all scenarios and to throw Exception at the end (in case test fails in any of the scenarios) ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From duke at openjdk.java.net Wed May 4 22:45:15 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Wed, 4 May 2022 22:45:15 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v3] In-Reply-To: References: Message-ID: > This test case tests the functionality of `setAlwaysOnTop`. > Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) > > The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. > > The test case tests `alwaysOnTop` for the following three cases: > > 1. JDialog with no parent/owner > 2. JDialog with JFrame as owner > 3. JDialog with another JDialog as owner > > Each of the three cases mentioned above is tested under 3 scenarios: > ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into AlwaysOnTop_8222323 - added changes to continue testing and exception thrown at end in case of failure - test case changes for alwaysOnTop ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8509/files - new: https://git.openjdk.java.net/jdk/pull/8509/files/396d5659..e4b7740d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=01-02 Stats: 21206 lines in 574 files changed: 13670 ins; 3601 del; 3935 mod Patch: https://git.openjdk.java.net/jdk/pull/8509.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8509/head:pull/8509 PR: https://git.openjdk.java.net/jdk/pull/8509 From prr at openjdk.java.net Wed May 4 23:33:19 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 23:33:19 GMT Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails [v2] In-Reply-To: References: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com> Message-ID: On Thu, 28 Apr 2022 22:40:32 GMT, Sergey Bylokhov wrote: > > Modified the test to not show the frame which cause the problem to go away > > Does it mean that setVisible(true) cause some memory leak since it prevents the window to be disposed? Since 9 windows are freed .. I doubt it .. but what's the hold up with #10 ? I wonder if you need an extra System.gc() cycle ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8450 From prr at openjdk.java.net Wed May 4 23:34:24 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 23:34:24 GMT Subject: RFR: 8284613: invalid use of @serial tag In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:48:15 GMT, Alisen Chung wrote: > Removed serial tag in method documentation Marked as reviewed by prr (Reviewer). doc-only - my review should be enough ------------- PR: https://git.openjdk.java.net/jdk/pull/8432 From smandalika at openjdk.java.net Wed May 4 23:36:25 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 4 May 2022 23:36:25 GMT Subject: Integrated: 8285693: Create an automated test for JDK-4702199 In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 07:54:18 GMT, Srinivas Mandalika wrote: > reate an automated test for [JDK-4702199](https://bugs.openjdk.java.net/browse/JDK-4702199) > > In order for spatial Braille to work and screen reader "review mode", we need bounding rectangle information for all text on the screen, and also the ability to get text substrings. StarOffice 6.1, Netscape and GNOME accessibility also require this new interface for describing text in their applications. This new interface is required for accessibility to StarOffice 6.1, Netscape and GNOME applications as required by Section 508 > > The solution is to define a new interface and related two helper classes. > AccessibleExtendedText, > AccessibleTextSequence. > AccessibleAttributeSequence > > The test validates the public fields of the above classes. > This review is for migrating tests from a closed test suite to open. > > Testing: > The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. This pull request has now been integrated. Changeset: 158d871d Author: Srinivas Mandalika Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/158d871d0574970c9e5609dd037aaa0ead668a3b Stats: 96 lines in 1 file changed: 96 ins; 0 del; 0 mod 8285693: Create an automated test for JDK-4702199 Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/8416 From prr at openjdk.java.net Wed May 4 23:43:19 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 4 May 2022 23:43:19 GMT Subject: RFR: 8285867 : Convert applet manual tests SelectionVisible.java to Frame and automate In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:39:28 GMT, lawrence.andrews wrote: > 1) Removed Applet dependent code and used Frame as top level. > 2) Automated the manual test. > > @shurymury test/jdk/java/awt/TextArea/SelectionVisible/SelectionVisible.java line 51: > 49: > 50: frame.add(ta); > 51: frame.setAlwaysOnTop(true); Is that important ? Remember it is conditionally supported functionality ? test/jdk/java/awt/TextArea/SelectionVisible/SelectionVisible.java line 65: > 63: disposeFrame(); > 64: throw new RuntimeException("Expected '34\n567' to be " + > 65: "selected text, but got " + selectedText); It probably doesn't matter but I'd like to see disposeFrame called with invokeAndWait And you could restructure this to be simpler invokeAndWait(::disposeFrame) if (!selectedText ...) { } else { System.out.println("test passed"); } and then you only need one call site for the dispose ------------- PR: https://git.openjdk.java.net/jdk/pull/8477 From psadhukhan at openjdk.java.net Thu May 5 04:10:16 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 5 May 2022 04:10:16 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:04:50 GMT, Prasanta Sadhukhan wrote: >> Test used to fail in specific CI macos M1 system owing to miniscule color difference >> >> >> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 >> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 >> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 >> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 >> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 >> >> >> SInce we already have color-tolerance check present, there is no need of exact color value check. >> Also, made the frame undecorated and remove unneeded library being built. >> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Reduce color tolerance Yes, it looks for Aqua the icon is "after" the disabled close, maximize, resizable buttons whereas for other L&F those buttons are not there so for other L&F the icon is at extreme left but it is strange that the images captured during the failure "imageicon-fail.png" and "iconimage-fail.png" (attached in JBS) shows the image which resembles the icon image (a black square) I tried to create JInternalFrame(String title, boolean resizable, boolean closable, boolean maximizable, boolean iconifiable) with false for all but it still shows those buttons for Aqua.. I am not sure if there is an y deterministic way to find out the location of the icon ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From smandalika at openjdk.java.net Thu May 5 07:08:47 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Thu, 5 May 2022 07:08:47 GMT Subject: RFR: 8286172: Create an automated test for JDK-4516019 Message-ID: Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019) Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children. The test validates the same. This review is for migrating tests from a closed test suite to open. Testing: The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. ------------- Commit messages: - Whitespace error fixed. - 8286172: Create an automated test for JDK-4516019 Changes: https://git.openjdk.java.net/jdk/pull/8546/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8546&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286172 Stats: 122 lines in 1 file changed: 122 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8546.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8546/head:pull/8546 PR: https://git.openjdk.java.net/jdk/pull/8546 From psadhukhan at openjdk.java.net Thu May 5 08:54:23 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 5 May 2022 08:54:23 GMT Subject: Integrated: 7132796: [macosx] closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 06:50:10 GMT, Prasanta Sadhukhan wrote: > JDK-4517214 was fixed for Metal L&F where JComboBox having TitledBorder used to have double height compared to normal JComboBox. > The issue is still observed for macos for Aqua L&F where still double height is seen. > Fix is to prevent adding border insets height to combobox size as was done for [MetalComboxUI.getMinimumSize[](url)](https://github.com/openjdk/jdk/blame/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java#L384) > The closed test is automated and moved to open. CI testing on all platform is ok. This pull request has now been integrated. Changeset: 81d7475d Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/81d7475d20133fd7dfb0ad66caee4e929e0291af Stats: 107 lines in 2 files changed: 100 ins; 7 del; 0 mod 7132796: [macosx] closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/8237 From psadhukhan at openjdk.java.net Thu May 5 08:58:01 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 5 May 2022 08:58:01 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v3] In-Reply-To: References: Message-ID: > Test used to fail in specific CI macos M1 system owing to miniscule color difference > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > SInce we already have color-tolerance check present, there is no need of exact color value check. > Also, made the frame undecorated and remove unneeded library being built. > Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Modify icon capture area ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8380/files - new: https://git.openjdk.java.net/jdk/pull/8380/files/a04c742b..4413bccc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=01-02 Stats: 36 lines in 1 file changed: 17 ins; 4 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8380/head:pull/8380 PR: https://git.openjdk.java.net/jdk/pull/8380 From psadhukhan at openjdk.java.net Thu May 5 08:59:51 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 5 May 2022 08:59:51 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v4] In-Reply-To: References: Message-ID: <9hTlvRh5C2diZApBibtWeICFLH0uIVROpB77SX4ho60=.2fe207a3-1be3-4b5d-bb7a-9a4ba3ea9ce2@github.com> > Test used to fail in specific CI macos M1 system owing to miniscule color difference > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > SInce we already have color-tolerance check present, there is no need of exact color value check. > Also, made the frame undecorated and remove unneeded library being built. > Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Modify icon capture area ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8380/files - new: https://git.openjdk.java.net/jdk/pull/8380/files/4413bccc..efc31786 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8380/head:pull/8380 PR: https://git.openjdk.java.net/jdk/pull/8380 From psadhukhan at openjdk.java.net Thu May 5 09:09:18 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 5 May 2022 09:09:18 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 04:06:46 GMT, Prasanta Sadhukhan wrote: > I am not sure if there is an y deterministic way to find out the location of the icon Modified to use the capture area as used in the original webrev for Aqua which will capture the title bar with icon ![iconImage-fail](https://user-images.githubusercontent.com/43534309/166893097-8d64f43c-130f-4d31-838e-f03f6fab294f.png) Testing in iMacs and other mac systems and other platforms are green. ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From psadhukhan at openjdk.java.net Thu May 5 09:16:04 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 5 May 2022 09:16:04 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v5] In-Reply-To: References: Message-ID: > Test used to fail in specific CI macos M1 system owing to miniscule color difference > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > SInce we already have color-tolerance check present, there is no need of exact color value check. > Also, made the frame undecorated and remove unneeded library being built. > Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Remove from PL - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8284888 - Modify icon capture area - Modify icon capture area - Reduce color tolerance - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8380/files - new: https://git.openjdk.java.net/jdk/pull/8380/files/efc31786..1558e7b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8380&range=03-04 Stats: 33981 lines in 866 files changed: 23387 ins; 4712 del; 5882 mod Patch: https://git.openjdk.java.net/jdk/pull/8380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8380/head:pull/8380 PR: https://git.openjdk.java.net/jdk/pull/8380 From martin.desruisseaux at geomatys.com Thu May 5 10:26:29 2022 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Thu, 5 May 2022 12:26:29 +0200 Subject: ImageReaderSpi.canDecodeInput sometime throw EOFException Message-ID: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> Hello all Invoking ImageReaderSpi.canDecodeInput(Object) with stream having less that 8 bytes causes an EOFException to be throw, while the expected behavior would be for the method to return false. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations which assume that those bytes always exist and do not check EOF conditions. The JPEG reader is not impacted. I have prepared a patch together with a test that reproduces the problem and verifies that the patch solves it. The changes in canDecodeInput(Object) method bodies are: * Use ImageInputStream.read() instead of readByte() and check for -1 (EOF) return value. * Replace ImageInputStream.readFully(byte[]) calls by a private tryReadFully method. The patch together with the tests are at [1]. Before to submit a pull request to JDK repository, if I remember correctly from my previous contribution I think that we need to fill a bug report on JIRA but it can not be done by myself. Can someone provides some guidance about the process and things that need to be changed in the proposed patch? ??? Thanks, ?? ???? Martin [1]https://github.com/Geomatys/jdk/commit/c996e83d5899b7ead0f8837aaea4cf991687a20e From tnakamura at openjdk.java.net Thu May 5 12:55:19 2022 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Thu, 5 May 2022 12:55:19 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 15:34:29 GMT, Toshio Nakamura wrote: >> Japanese logical fonts are drawn with wrong size since Java 18. >> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding. >> >> Tested: jdk_desktop on Windows, Linux, and macOS > > Toshio Nakamura has updated the pull request incrementally with one additional commit since the last revision: > > locale base fix OK, I'll leave it to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From tnakamura at openjdk.java.net Thu May 5 12:55:19 2022 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Thu, 5 May 2022 12:55:19 GMT Subject: Withdrawn: 8285308: Win: Japanese logical fonts are drawn with wrong size In-Reply-To: References: Message-ID: On Thu, 21 Apr 2022 09:14:14 GMT, Toshio Nakamura wrote: > Japanese logical fonts are drawn with wrong size since Java 18. > It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` (and `sun.awt.windows.WFontConfiguration`) seems to expect the native encoding instead of the default encoding. This patch changes to use native encoding. > > Tested: jdk_desktop on Windows, Linux, and macOS This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329 From duke at openjdk.java.net Thu May 5 13:36:29 2022 From: duke at openjdk.java.net (Nikita Gubarkov) Date: Thu, 5 May 2022 13:36:29 GMT Subject: RFR: 8269806: Emoji rendering on Linux [v3] In-Reply-To: References: Message-ID: <-R_qZY6A32lNe_UgLCT-BQuphOJaaZUVLfUFowCschU=.79cb0784-6ccb-480a-b311-0011e4021b4d@github.com> On Wed, 30 Mar 2022 17:08:37 GMT, Nikita Gubarkov wrote: >> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR >> It includes: >> - Bitmap glyph loading via Freetype >> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint >> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs >> - Small fixes in related code like null-checks which could cause NPE & comment typos > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8269806: Fix emoji rendering with -Dsun.java2d.xrender=false and AA=OFF Sure big font sizes & printing probably wouldn't work, I'll try to figure out what to do with it ------------- PR: https://git.openjdk.java.net/jdk/pull/4798 From kizune at openjdk.java.net Thu May 5 15:58:17 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 5 May 2022 15:58:17 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v2] In-Reply-To: References: Message-ID: <7r2gJaUqcA6vI_k_QZ24KdOec4Bbqi4-lljBfgKmPPY=.704ff449-f471-47ce-956d-3486d16015f2@github.com> On Wed, 4 May 2022 22:39:12 GMT, Harshitha Onkar wrote: >> This test case tests the functionality of `setAlwaysOnTop`. >> Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) >> >> The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. >> >> The test case tests `alwaysOnTop` for the following three cases: >> >> 1. JDialog with no parent/owner >> 2. JDialog with JFrame as owner >> 3. JDialog with another JDialog as owner >> >> Each of the three cases mentioned above is tested under 3 scenarios: >> ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added changes to continue testing and exception thrown at end in case of failure test/jdk/java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java line 243: > 241: System.out.println("Case "+ caseNo + errorMsg[scenarioNo - 1] > 242: +" Expected Color: "+ expectedColor +" vs Actual Color: " > 243: + actualColor); Here instead of just printing out the error i would save it into the static StringBuilder that i would allocate at the beginning of the test. Then when we are concluding testing i would just check if the buffer is empty and if it is not i would throw an RuntimeException with the buffer content. This way we would have all the errors reported by the JavaTest suite in the HTML report and this will make it into the whatever testing environment report we are running tests in. Also that would replace the errorFlag variable since emptiness of the buffer will be an indication of test pass. ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From duke at openjdk.java.net Thu May 5 16:07:26 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 5 May 2022 16:07:26 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v2] In-Reply-To: <7r2gJaUqcA6vI_k_QZ24KdOec4Bbqi4-lljBfgKmPPY=.704ff449-f471-47ce-956d-3486d16015f2@github.com> References: <7r2gJaUqcA6vI_k_QZ24KdOec4Bbqi4-lljBfgKmPPY=.704ff449-f471-47ce-956d-3486d16015f2@github.com> Message-ID: On Thu, 5 May 2022 15:54:33 GMT, Alexander Zuev wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> added changes to continue testing and exception thrown at end in case of failure > > test/jdk/java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java line 243: > >> 241: System.out.println("Case "+ caseNo + errorMsg[scenarioNo - 1] >> 242: +" Expected Color: "+ expectedColor +" vs Actual Color: " >> 243: + actualColor); > > Here instead of just printing out the error i would save it into the static StringBuilder that i would allocate at the beginning of the test. Then when we are concluding testing i would just check if the buffer is empty and if it is not i would throw an RuntimeException with the buffer content. This way we would have all the errors reported by the JavaTest suite in the HTML report and this will make it into the whatever testing environment report we are running tests in. Also that would replace the errorFlag variable since emptiness of the buffer will be an indication of test pass. @azuev-java Thank you and will incorporate the suggested changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From achung at openjdk.java.net Thu May 5 18:00:16 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Thu, 5 May 2022 18:00:16 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v11] In-Reply-To: References: Message-ID: > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: saved translation values in EtchedBorder, updated test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/6c2efaf4..a7935828 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=09-10 Stats: 177 lines in 2 files changed: 83 ins; 41 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Thu May 5 18:04:19 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 18:04:19 GMT Subject: RFR: 8285397: JNI exception pending in CUPSfuncs.c:250 [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 20:14:35 GMT, Phil Race wrote: >> A tool checking for JNI errors complains that the call to JNU_NewStringPlatform(..) >> might throw an exception and subsequent JNI code isn't making sure of that. >> Clear the exception so the error handling code can do its thing. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285399 FYI .. I asked about the cases that did not get reported and turns out they only reported *new* problems and I was pointed to a report that identifies the 4 cases I fixed in my last incremental update. So I think we should be good now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8491 From duke at openjdk.java.net Thu May 5 18:20:12 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 5 May 2022 18:20:12 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v4] In-Reply-To: References: Message-ID: > This test case tests the functionality of `setAlwaysOnTop`. > Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) > > The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. > > The test case tests `alwaysOnTop` for the following three cases: > > 1. JDialog with no parent/owner > 2. JDialog with JFrame as owner > 3. JDialog with another JDialog as owner > > Each of the three cases mentioned above is tested under 3 scenarios: > ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: added error msgs to StringBuffer ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8509/files - new: https://git.openjdk.java.net/jdk/pull/8509/files/e4b7740d..79120c79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=02-03 Stats: 17 lines in 1 file changed: 2 ins; 7 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8509.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8509/head:pull/8509 PR: https://git.openjdk.java.net/jdk/pull/8509 From duke at openjdk.java.net Thu May 5 18:31:01 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 5 May 2022 18:31:01 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v5] In-Reply-To: References: Message-ID: > This test case tests the functionality of `setAlwaysOnTop`. > Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) > > The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. > > The test case tests `alwaysOnTop` for the following three cases: > > 1. JDialog with no parent/owner > 2. JDialog with JFrame as owner > 3. JDialog with another JDialog as owner > > Each of the three cases mentioned above is tested under 3 scenarios: > ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: removed commented line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8509/files - new: https://git.openjdk.java.net/jdk/pull/8509/files/79120c79..666a285a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8509&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8509.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8509/head:pull/8509 PR: https://git.openjdk.java.net/jdk/pull/8509 From prr at openjdk.java.net Thu May 5 19:13:06 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 19:13:06 GMT Subject: RFR: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java fails in macos12 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:16:17 GMT, Prasanta Sadhukhan wrote: > 2 open tests were seen to be failing in macos12 which happen to have same root cause as > 8273506: java Robot API did the 'm' keypress and caused /awt/event/Ke.... > > With that fix being committed, testing on intended macos12 systems are not able to reproduce this failures so we can remove from Problemlist. CI jobs links are in JBS. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8532 From prr at openjdk.java.net Thu May 5 19:13:10 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 19:13:10 GMT Subject: RFR: 8285962: NimbusDefaults has a typo in a L&F property In-Reply-To: <1E9x3Ur0YF8znS8aud8ll9X5jPtulLXnTKikMB0pr54=.37e43dc8-bf2c-417f-a097-57693e772110@github.com> References: <1E9x3Ur0YF8znS8aud8ll9X5jPtulLXnTKikMB0pr54=.37e43dc8-bf2c-417f-a097-57693e772110@github.com> Message-ID: <0zBFkHqsC8Vcoz04hx3dpIAV_0Nh_YCuavsuuTbDA8Q=.04d9a696-e874-47fe-87ab-c6e71369c830@github.com> On Mon, 2 May 2022 16:01:02 GMT, Prasanta Sadhukhan wrote: > BasicLookAndFeel, BasicProgressBarUI, GTKLookAndFeel tries to find property by "ProgressBar.verticalSize" but the property defined in NimbusDefaults has a typo "vertictalSize ". > Rectified the typo. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8504 From prr at openjdk.java.net Thu May 5 19:15:20 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 19:15:20 GMT Subject: RFR: 8134640 ( Left Insets Margin Test ) moved to open repo from closed [v2] In-Reply-To: References: <5gw_QjIeWEr1uUcAzT0x-xcEnwJKWXGBlVJBSY9o1_0=.1e01015f-91d7-42c6-bb9f-68482c7ad55f@github.com> Message-ID: On Wed, 4 May 2022 05:55:16 GMT, Tejesh R wrote: >> The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Copyright Year updated You need to submit this under a NEW bug ID. You already used 8134640 to push an update to the test whilst it was still closed and it was resolved in a build a couple of weeks ago. We can't re-use it for this in a different build, that would be wrong ! Actually withdraw this PR and let's re-do it properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8500 From prr at openjdk.java.net Thu May 5 19:13:21 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 19:13:21 GMT Subject: RFR: 8286172: Create an automated test for JDK-4516019 In-Reply-To: References: Message-ID: <9PRdC_vzAG9oUVqGXtDacghU4z1tYp8OQj2ZRcH1FQs=.f19eb8ef-af26-4fcb-9ff9-20cd38c2c818@github.com> On Thu, 5 May 2022 06:58:26 GMT, Srinivas Mandalika wrote: > Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019) > > Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children. > > The test validates the same. > > This review is for migrating tests from a closed test suite to open. > > Testing: > The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. Changes requested by prr (Reviewer). test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 29: > 27: * @bug 4516019 > 28: * @summary Clicking on the increment/decrement buttons of the spinner > 29: * does not get focus onto the spinner. That summary is surely describing the bug, not what the test is verifying. Shouldn't it read something like "Verify clicking on inc/dec gives focus to the spinner" test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 81: > 79: "Clicking on JSpinner buttons did not" > 80: + " shift foucs to the JSpinner"); > 81: } foucs -> focus test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 100: > 98: robot.mouseMove(bounds.x + bounds.width/2 , > 99: bounds.y + bounds.height /2); > 100: robot.delay(300); why not use setAutoDelay(300) and then you don't need all these extra lines of code. test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 105: > 103: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); > 104: Thread.sleep(300); > 105: // Move cursor to click spinner up arrow button and why is this one (anomalously) Thread.sleep(..) ? test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 113: > 111: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); > 112: } catch (Exception e) { > 113: e.printStackTrace(); Shouldn't the test fail if we get an exception ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8546 From prr at openjdk.java.net Thu May 5 19:13:21 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 19:13:21 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v5] In-Reply-To: References: Message-ID: <2HW7BgTqhuhh3XUzv1VddujFs3esmNAiqPZn76M-mHc=.a8407a5d-1488-488a-849e-29ab18e11221@github.com> On Thu, 5 May 2022 18:31:01 GMT, Harshitha Onkar wrote: >> This test case tests the functionality of `setAlwaysOnTop`. >> Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) >> >> The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. >> >> The test case tests `alwaysOnTop` for the following three cases: >> >> 1. JDialog with no parent/owner >> 2. JDialog with JFrame as owner >> 3. JDialog with another JDialog as owner >> >> Each of the three cases mentioned above is tested under 3 scenarios: >> ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > removed commented line Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From kizune at openjdk.java.net Thu May 5 20:13:41 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 5 May 2022 20:13:41 GMT Subject: RFR: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" [v5] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 18:31:01 GMT, Harshitha Onkar wrote: >> This test case tests the functionality of `setAlwaysOnTop`. >> Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) >> >> The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. >> >> The test case tests `alwaysOnTop` for the following three cases: >> >> 1. JDialog with no parent/owner >> 2. JDialog with JFrame as owner >> 3. JDialog with another JDialog as owner >> >> Each of the three cases mentioned above is tested under 3 scenarios: >> ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > removed commented line Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From prr at openjdk.java.net Thu May 5 20:13:46 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 20:13:46 GMT Subject: RFR: 8030121: java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java fails In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:59:41 GMT, Manukumar V S wrote: > Removing MissingDragExitEventTest.java from ProblemList as JDK-8274597 already fixed the test and it's working fine now. > > Testing: > MissingDragExitEventTest.java test has been run 10 times on all 3 platforms and got all Pass. So a comment in the bug report says -- I am not seeing this test fail but I think it needs to be problem listed anyway as it "drops" (pastes) "1234567890" into the terminal window that runs jtreg. Need to figure out how to clean up what it is dragging. This is occurring on Mac. -- Is that resolved ? If so by what ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8529 From duke at openjdk.java.net Thu May 5 21:22:48 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 5 May 2022 21:22:48 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes In-Reply-To: <3HBkT_7SmunSZ1cby1bQtYO_qZ_XQtQHV42fQsI7_vg=.b1043cdc-3e4c-45d6-be69-24b67c1b9e8b@github.com> References: <3HBkT_7SmunSZ1cby1bQtYO_qZ_XQtQHV42fQsI7_vg=.b1043cdc-3e4c-45d6-be69-24b67c1b9e8b@github.com> Message-ID: On Fri, 29 Apr 2022 00:36:15 GMT, Sergey Bylokhov wrote: >> In Windows when desktop scaling was changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Did you have a chance to check why the WM_DPICHANGED does not work, any specific cases? It is used by checking the scale change for windows in AWT, and no issues were reported for that as far as I know. @mrserb Wanted to follow up on this PR and previous feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Thu May 5 23:58:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 May 2022 23:58:50 GMT Subject: RFR: 8286172: Create an automated test for JDK-4516019 In-Reply-To: References: Message-ID: <84yCEDKwGXhQU9c1TYYrxdCLDXQjnIaAkP7FyHW1vpI=.0165d348-59cb-44d9-a09e-f35084e01616@github.com> On Thu, 5 May 2022 06:58:26 GMT, Srinivas Mandalika wrote: > Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019) > > Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children. > > The test validates the same. > > This review is for migrating tests from a closed test suite to open. > > Testing: > The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. Also you are doing the same thing I've told others not to - look at the path name test/jdk/javax/swing/4516019/JSpinnerFocusTest.java what is the point of 4516019 ? Do NOT create an extra directory for no reason. especially one just numbered for a bugid and in this case this test should go in the pre-existing JSpinner directory ! ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8546 From prr at openjdk.java.net Fri May 6 00:01:56 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 00:01:56 GMT Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 08:08:32 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286) >> >> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection. >> When cell selection is not enabled, there is no way, using >> accessibility, to select rows or columns. It seems logical that selecting a cell >> using accessibility should have the same effect as clicking on a cell with the >> mouse. That is, if row or column selection is enabled, then selecting a cell >> should instead cause the row or column to be selected. >> The proposed test verifies that the above behavior is fixed. >> >> This review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed: Typo in Copyright Header Get rid of the useless extra directory level ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8333 From prr at openjdk.java.net Fri May 6 00:02:06 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 00:02:06 GMT Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v2] In-Reply-To: <1cZzZNkeKLMbo_-pRiMpaTbVQnRhEZdtJJ1tKQckWQA=.58617cb8-1e88-4bde-9936-f4a0788a72ea@github.com> References: <1cZzZNkeKLMbo_-pRiMpaTbVQnRhEZdtJJ1tKQckWQA=.58617cb8-1e88-4bde-9936-f4a0788a72ea@github.com> Message-ID: On Tue, 26 Apr 2022 09:28:28 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535) >> AccessibleValue implementation only accept Integers >> The AccessibleValue implementations of the following components: >> >> java.awt.Scrollbar >> javax.swing.AbstractButton >> javax.swing.JInternalFrame >> javax.swing.JSplitPane >> javax.swing.JScrollBar >> javax.swing.JProgressBar >> javax.swing.JSlider >> >> require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that). >> >> The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer. >> >> his review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Comments Fixed: Simplified test code with a loop over the JComponents being tested. again, get rid of the useless directory ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8220 From prr at openjdk.java.net Fri May 6 00:02:48 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 00:02:48 GMT Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v2] In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 09:19:33 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362) >> >> The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return >> BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their >> AccessibleValue implementation. >> The real maximum value (due to the constraints on BoundedRangeModel) is >> model.getMaximum() - model.getExtent(). >> >> The test verifies that the above is adhered to as expected. >> >> This review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > 8284524: Create an automated test for JDK-4422362 and again .. no bug id directory .. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8158 From prr at openjdk.java.net Fri May 6 00:03:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 00:03:49 GMT Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v3] In-Reply-To: <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com> References: <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com> Message-ID: <4268RdqAOZAa1pNZWp2RkkESloO4VNXMhHpC00XyxNg=.2aced7e2-5607-4cd4-a09c-aad1c09f6781@github.com> On Wed, 6 Apr 2022 07:02:25 GMT, Srinivas Mandalika wrote: >> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690) >> >> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane). >> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with. >> >> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items. >> >> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar. >> This review is for migrating tests from a closed test suite to open. > > Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: > > - Review Comments Fixed: Swing Components on EDT, 80 chars lines > - Review Comments Fixed: Swing Components on EDT, 80 chars lines and again .. just go through all your PRs and get rid of bugid directories where there's just one file in it ! ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7753 From psadhukhan at openjdk.java.net Fri May 6 03:23:50 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 6 May 2022 03:23:50 GMT Subject: RFR: 8285397: JNI exception pending in CUPSfuncs.c:250 [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 20:14:35 GMT, Phil Race wrote: >> A tool checking for JNI errors complains that the call to JNU_NewStringPlatform(..) >> might throw an exception and subsequent JNI code isn't making sure of that. >> Clear the exception so the error handling code can do its thing. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285399 Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8491 From duke at openjdk.java.net Fri May 6 03:50:31 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 03:50:31 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max Message-ID: Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. ------------- Commit messages: - Use Math.min and Math.max in more places - Use java.lang.Math in Marlin renderer Changes: https://git.openjdk.java.net/jdk/pull/7097/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7097&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286271 Stats: 682 lines in 54 files changed: 0 ins; 529 del; 153 mod Patch: https://git.openjdk.java.net/jdk/pull/7097.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7097/head:pull/7097 PR: https://git.openjdk.java.net/jdk/pull/7097 From jwaters at openjdk.java.net Fri May 6 03:50:29 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 03:50:29 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement In-Reply-To: References: Message-ID: <92o3NbMExBuvBt4ejwlmht81Ez6RAX9StXB4km3FZ2E=.0e4df1c7-1251-4a7b-82c5-76c3288a568f@github.com> On Thu, 7 Apr 2022 15:27:11 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > Keeping open. Hey there @SWinxy, same thing with this PR, this time rename the title to just 8286270 ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From duke at openjdk.java.net Fri May 6 03:50:29 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 03:50:29 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement Message-ID: The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. ------------- Commit messages: - Merge identical branches in XColors switch search - Replace color search in XColors with a switch statement Changes: https://git.openjdk.java.net/jdk/pull/7096/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7096&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286270 Stats: 1302 lines in 1 file changed: 510 ins; 784 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7096.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7096/head:pull/7096 PR: https://git.openjdk.java.net/jdk/pull/7096 From jwaters at openjdk.java.net Fri May 6 03:50:31 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 03:50:31 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. Comment to keep PR active ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From duke at openjdk.java.net Fri May 6 03:50:32 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 03:50:32 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. Keeping open. ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From jwaters at openjdk.java.net Fri May 6 03:50:32 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 03:50:32 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 15:27:56 GMT, SWinxy wrote: >> Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. >> This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. > > Keeping open. @SWinxy Issue ID is 8286271 ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From duke at openjdk.java.net Fri May 6 03:50:29 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 03:50:29 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 03:44:17 GMT, SWinxy wrote: > The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. Keeping this alive; the PR is being blocked by the OCA. Keeping open. ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From duke at openjdk.java.net Fri May 6 04:00:23 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 04:00:23 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible Message-ID: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). ------------- Commit messages: - Merge branch 'master' into instanceof - Use new instanceof in platform-specific classes - Use instanceof language feature wherever possible Changes: https://git.openjdk.java.net/jdk/pull/7000/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7000&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286269 Stats: 4652 lines in 368 files changed: 474 ins; 1329 del; 2849 mod Patch: https://git.openjdk.java.net/jdk/pull/7000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7000/head:pull/7000 PR: https://git.openjdk.java.net/jdk/pull/7000 From jwaters at openjdk.java.net Fri May 6 04:00:23 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 04:00:23 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: <6is4IEDxw7YAurtA0Xv85VHE_4GstzgFjEJIOgGGehM=.275b3b06-2c03-48cd-b830-f9b7294e69fa@github.com> On Sat, 8 Jan 2022 18:13:45 GMT, SWinxy wrote: > The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. > There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. > This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). Try to merge instead of rebasing and force-pushing, it helps with later reviews. I can try to help you get a JBS issue for this too, since you need one for the PR to be accepted (No guarantees though) ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From duke at openjdk.java.net Fri May 6 04:00:23 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 04:00:23 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <6is4IEDxw7YAurtA0Xv85VHE_4GstzgFjEJIOgGGehM=.275b3b06-2c03-48cd-b830-f9b7294e69fa@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> <6is4IEDxw7YAurtA0Xv85VHE_4GstzgFjEJIOgGGehM=.275b3b06-2c03-48cd-b830-f9b7294e69fa@github.com> Message-ID: On Fri, 4 Feb 2022 09:28:55 GMT, Julian Waters wrote: > Try to merge instead of rebasing and force-pushing, it helps with later reviews. Good to know. I'm not a git master, and the purpose of the force push was to consolidate some missed changes into a single commit, but I know it can mess up PRs. > I can try to help you get a JBS issue for this too Thanks. I've been having some frustrations with the OCA process, and I don't want my commits to languish. ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From jwaters at openjdk.java.net Fri May 6 04:00:24 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 04:00:24 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> <6is4IEDxw7YAurtA0Xv85VHE_4GstzgFjEJIOgGGehM=.275b3b06-2c03-48cd-b830-f9b7294e69fa@github.com> Message-ID: On Sat, 5 Feb 2022 03:35:10 GMT, SWinxy wrote: > > Try to merge instead of rebasing and force-pushing, it helps with later reviews. > > Good to know. I'm not a git master, and the purpose of the force push was to consolidate some missed changes into a single commit, but I know it can mess up PRs. > > > I can try to help you get a JBS issue for this too > > Thanks. I've been having some frustrations with the OCA process, and I don't want my commits to languish. @SWinxy I haven't been able to contact anyone to create an issue yet, but I'm now able to create them directly myself, that said, it's probably best if i wait for your contributor agreement to be approved before I do so. Would you like me to create entries corresponding to your PRs now anyway or hold off for now? (Do remind me to do so once the agreement gets approved if you want me to wait first) ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From jwaters at openjdk.java.net Fri May 6 04:00:24 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 04:00:24 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: On Tue, 8 Mar 2022 18:22:23 GMT, SWinxy wrote: > The OCA process is back in my court, and I've been overwhelmed these past few weeks to get it over with. Thank you, genuinely, for offering. If you have time to create those issues on the JBS, I would greatly appreciate it. The OCA can be an absolute pain, I feel you since my process took almost 2 months to be approved. I can't create the issues until you're approved though, unfortunately :( Don't worry though, I'll be watching your PRs and waiting for you to get approved, and I'll create the issues the moment that happens ;) Have a great day! > Keeping open. @SWinxy Gratz on getting the contributor status! I've created an issue on the tracker for you, please rename the title of this PR to just 8286269 and the automated system should take care of the rest and send your PR for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From jwaters at openjdk.java.net Fri May 6 04:00:25 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 04:00:25 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: <1ksy6uzABs9VP9PswY2Zzy4mw5meTr0MQMUZVEf28x4=.60cb931b-28da-4363-89dc-769580b8ce4d@github.com> On Fri, 6 May 2022 03:05:30 GMT, Julian Waters wrote: >> Keeping open. > > @SWinxy Gratz on getting the contributor status! I've created an issue on the tracker for you, please rename the title of this PR to just 8286269 and the automated system should take care of the rest and send your PR for review! > @TheShermanTanker You are a legend! Thank you for all this. I've added it to #7096 and #7097, too, though I wanna double check that my changes in #7098 are right before doing it to that one. I have time tomorrow to merge the conflicts for this PR. Can't thank you enough, btw. You have been super helpful, being there when it feels like I'm screaming into the void. No problems mate, this was what I faced too when joining as a contributor, so I know how it feels ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From duke at openjdk.java.net Fri May 6 04:00:24 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 04:00:24 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: On Sat, 8 Jan 2022 18:13:45 GMT, SWinxy wrote: > The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. > There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. > This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). The OCA process is back in my court, and I've been overwhelmed these past few weeks to get it over with. Thank you, genuinely, for offering. If you have time to create those issues on the JBS, I would greatly appreciate it. Keeping open. ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From duke at openjdk.java.net Fri May 6 04:00:25 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 04:00:25 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: On Fri, 6 May 2022 03:05:30 GMT, Julian Waters wrote: >> Keeping open. > > @SWinxy Gratz on getting the contributor status! I've created an issue on the tracker for you, please rename the title of this PR to just 8286269 and the automated system should take care of the rest and send your PR for review! @TheShermanTanker You are a legend! Thank you for all this. I've added it to #7096 and #7097, too, though I wanna double check that my changes in #7098 are right before doing it to that one. I have time tomorrow to merge the conflicts for this PR. Can't thank you enough, btw. You have been super helpful, being there when it feels like I'm screaming into the void. ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From duke at openjdk.java.net Fri May 6 04:00:25 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 04:00:25 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <1ksy6uzABs9VP9PswY2Zzy4mw5meTr0MQMUZVEf28x4=.60cb931b-28da-4363-89dc-769580b8ce4d@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> <1ksy6uzABs9VP9PswY2Zzy4mw5meTr0MQMUZVEf28x4=.60cb931b-28da-4363-89dc-769580b8ce4d@github.com> Message-ID: On Fri, 6 May 2022 03:53:50 GMT, Julian Waters wrote: > No problems mate, this was what I faced too when joining as a contributor, so I know how it feels ;) Then I should pass the wisdom on. (I also fixed the conflict from the web view rather than having to go into my IDE, which must be new. Super quick!) ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From jwaters at openjdk.java.net Fri May 6 04:06:48 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 6 May 2022 04:06:48 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: On Sat, 8 Jan 2022 18:13:45 GMT, SWinxy wrote: > The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. > There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. > This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). You do need to become a registered Author to properly help new contributors though, but the requirement is only that you have 2 accepted PRs in the codebase. With the 4 PRs you already have, you should be able to get to Author in no time if all 4 get through :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From duke at openjdk.java.net Fri May 6 04:34:50 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 04:34:50 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: On Sat, 8 Jan 2022 18:13:45 GMT, SWinxy wrote: > The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. > There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. > This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From psadhukhan at openjdk.java.net Fri May 6 05:25:50 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 6 May 2022 05:25:50 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 09:06:02 GMT, Prasanta Sadhukhan wrote: > > I am not sure if there is an y deterministic way to find out the location of the icon > > Modified to use the capture area as used in the original webrev for Aqua which will capture the title bar with icon ![iconImage-fail](https://user-images.githubusercontent.com/43534309/166893097-8d64f43c-130f-4d31-838e-f03f6fab294f.png) > > Capture area is modified slightly to omit the top inset too to remove the blue background from captured image. > > Testing in iMacs and other mac systems and other platforms are green. The original issue was apart from ImageIcon all other`icon is displayed lower than it should be and to the right of where it should be, covering part of the title text.` Screenshot 2022-05-06 at 9 40 41 AM whereas for ImageIcon Screenshot 2022-05-06 at 10 47 47 AM so I think it should be ok testing the titlebar the bufferedimage with ImageIcon and Icon will be different thus testing the fix as well keeping all platforms happy ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From lbourges at openjdk.java.net Fri May 6 06:59:52 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 6 May 2022 06:59:52 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. Hi, Concerning the Marlin renderer, I made FloatMath for performance reasons, highly tuned impl. I doubt calling Math.ceil/floor or Math.min/max is really faster. I should test performance with your changes or write a jmh benchmark... ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From mbaesken at openjdk.java.net Fri May 6 07:36:48 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 07:36:48 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 09:08:28 GMT, Matthias Baesken wrote: > Does this mean that not setting _WIN32_WINNT means :any API is allowed" ? Hi David , I did one more try with my current setup (VS2017 on a Win10 notebook). I did not set _WIN32_WINNT. My little test program #include #include int main() { #ifdef _WIN32_WINNT printf("_WIN32_WINNT is defined .\n"); #if (_WIN32_WINNT == 0x0600) printf("Vista API setting\n"); #endif #if (_WIN32_WINNT == 0x0601) printf("Win 7 API setting\n"); #endif #if (_WIN32_WINNT == 0x0602) printf("Win 8 API setting\n"); #endif #if (_WIN32_WINNT == 0x0603) printf("Win 8.1 API setting\n"); #endif #if (_WIN32_WINNT == 0x0A00) printf("Win 10 API setting\n"); #endif #endif return 0; } shows me _WIN32_WINNT is defined . Win 10 API setting So I think with our current compilers in use like VS2017 / VS2019 we allow Win10 APIs in most of our code except a few places where we set _WIN32_WINNT and go back to some mixture of older APIs. Not sure if this is a good thing, we could break for example Win 8.1/Win2012 compatibility easily this way. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From dholmes at openjdk.java.net Fri May 6 09:52:47 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 09:52:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This seems okay to me in this form. I agree that explicitly setting this is better than unknowingly using API's that might not be available on supported platforms. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From mbaesken at openjdk.java.net Fri May 6 09:57:47 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 6 May 2022 09:57:47 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Hi David, thanks for the review ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From aivanov at openjdk.java.net Fri May 6 10:42:40 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 6 May 2022 10:42:40 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v8] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 15:16:20 GMT, Alexey Ivanov wrote: > > Made a small change with the bottom line to match the left line of the border > > Great, that looks like it'll fix it so I won't test again, I'll defer to the others now for the code review. (I'd be happy to chip in there too, but I'm not sure if "random guy on github" is qualified/authorized to?) With the latest version, the lines align at the left edge. Yet at scales of 200% and 300%, the bottom highlight line is 1 pixel and 2 pixels shorter, it isn't drawn to the start of the shadow line. I can't see it happening in the right top edge though. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From mvs at openjdk.java.net Fri May 6 11:16:47 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Fri, 6 May 2022 11:16:47 GMT Subject: RFR: 8030121: java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java fails In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:59:41 GMT, Manukumar V S wrote: > Removing MissingDragExitEventTest.java from ProblemList as JDK-8274597 already fixed the test and it's working fine now. > > Testing: > MissingDragExitEventTest.java test has been run 10 times on all 3 platforms and got all Pass. > Yes, that issue is resolved by setting the 'outer.translate(-20, 0)' instead of 'outer.translate(-40, 0)'. It will drag the contents(the text "1234567890") from inside and just go -20px from the frame(just enough to generate the DragExit event) and will again come back, but it will never drop the content anywhere. I have tested it manually in MacOS with a terminal window open behind and it never pasted anything there. ------------- PR: https://git.openjdk.java.net/jdk/pull/8529 From aivanov at openjdk.java.net Fri May 6 11:56:47 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 6 May 2022 11:56:47 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v11] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 18:00:16 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > saved translation values in EtchedBorder, updated test src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 137: > 135: > 136: g.drawLine((3*stkWidth/2)-1, h-(stkWidth-stkWidth/2), > 137: w-(stkWidth-stkWidth/2), h-(stkWidth-stkWidth/2)); // bottom line Suggestion: g.drawLine(stkWidth/2, h-(stkWidth-stkWidth/2), w-(stkWidth-stkWidth/2), h-(stkWidth-stkWidth/2)); // bottom line If you change the initial `x` to be `stkWidth/2`, it always aligns with the rectangle drawn in `paintBorderRect`. Thus the issue where the bottom highlight line is short of a few pixels gets resolved. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From erikj at openjdk.java.net Fri May 6 12:47:41 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 6 May 2022 12:47:41 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <5t5qsNQ4XMMB_1ACFCDIKGj1BxBnsmAAq5d4C5z3yQU=.c1c2bb90-57dc-4754-a2cd-56b0e5d58843@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ihse at openjdk.java.net Fri May 6 14:38:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 6 May 2022 14:38:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Looks good, thanks for doing this cleanup. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Fri May 6 14:47:39 2022 From: duke at openjdk.java.net (Tejesh R) Date: Fri, 6 May 2022 14:47:39 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v3] In-Reply-To: References: Message-ID: > In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Added Regression Test JToolTip/5047379/bug5047379.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8496/files - new: https://git.openjdk.java.net/jdk/pull/8496/files/60da819c..143be931 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8496&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8496&range=01-02 Stats: 227 lines in 1 file changed: 227 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8496/head:pull/8496 PR: https://git.openjdk.java.net/jdk/pull/8496 From duke at openjdk.java.net Fri May 6 15:45:49 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 15:45:49 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. I see... It's something similar to JOML's [FASTMATH](https://joml-ci.github.io/JOML/apidocs/org/joml/Options.html#FASTMATH) option. Even if calling Math.min/max wouldn't be faster (I would hope so, being tagged with @IntrinsicCandidate), it would still be unnecessary code duplication. The Java code is identical, save for the `final` modifier in the parameter list. `ceil_f`, `floor_f`, and `floor_int(float)` are not used. `ceil_int(float)` is only used once, in `MarlinProperties.align`. `align` is used only three times, with the callers being constants in `MarlinConst`. This is to say the performance benefit would be pointless assuming the three callers to `align` aren't called in other peoples' code (I doubt, but who knows). For `ceil_int(double)` and `floor_int(double)`, that is where performance would matter. What I can end up doing is adding back `FloatMath` with those two methods, and rename it to `FastMath` or something. ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From lbourges at openjdk.java.net Fri May 6 16:03:58 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 6 May 2022 16:03:58 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. Thanks for your detailed analysis, it matches my variant, so I prefer keeping FloatMath with fewer methods. I agree min/max can use jdk math as I manually inlined important calls inside very hot loops in Renderer. Here is my latest version of FloatMath (jdk branch): https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/marlin/FloatMath.java Marlin renderer 0.9.4.5 has few more patches that I have to propose to openjdk/jdk as I did for openjfx: https://github.com/openjdk/jfx/pull/674 Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From duke at openjdk.java.net Fri May 6 16:16:56 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 16:16:56 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. Sick. Should I implement these changes in this PR or do you want to do them? ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From asemenov at openjdk.java.net Fri May 6 16:54:08 2022 From: asemenov at openjdk.java.net (Artem Semenov) Date: Fri, 6 May 2022 16:54:08 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method Message-ID: A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. @forantar @azuev-java @mrserb please review. Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". ------------- Commit messages: - [whitespace fix - 8271846 a11y API lacks setSelectedIndex method Changes: https://git.openjdk.java.net/jdk/pull/8578/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8578&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271846 Stats: 663 lines in 4 files changed: 643 ins; 14 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8578/head:pull/8578 PR: https://git.openjdk.java.net/jdk/pull/8578 From lbourges at openjdk.java.net Fri May 6 16:56:57 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Fri, 6 May 2022 16:56:57 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. Please keep FloatMath alive to have floor/ceil (double) and I will anyway merge in my repo. Go on ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From prr at openjdk.java.net Fri May 6 17:17:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 17:17:03 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method In-Reply-To: References: Message-ID: On Fri, 6 May 2022 16:10:35 GMT, Artem Semenov wrote: > A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. > > @forantar @azuev-java @mrserb please review. > > Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". Since you are propsosing new API, you can't backport this. I hope that is understood. src/java.desktop/share/classes/javax/accessibility/AccessibleList.java line 27: > 25: * This interface provides list specific data. > 26: * > 27: * @author Artem Semenov We don't do @author tags in openjdk test/jdk/java/awt/a11y/AccessibleListTest.java line 3: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2021, JetBrains s.r.o.. All rights reserved. Not 2022 ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8578 From prr at openjdk.java.net Fri May 6 17:28:59 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 17:28:59 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. I would like to caution that in a previous bug fix where this form was replaced it was determined not to be 100% compatible https://mail.openjdk.java.net/pipermail/client-libs-dev/2021-December/001694.html In short, this is pointless churn and I reject this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From duke at openjdk.java.net Fri May 6 17:54:09 2022 From: duke at openjdk.java.net (Mark Powers) Date: Fri, 6 May 2022 17:54:09 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults Message-ID: JDK-6725221 Standardize obtaining boolean properties with defaults ------------- Commit messages: - Merge - first iteration Changes: https://git.openjdk.java.net/jdk/pull/8559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6725221 Stats: 27 lines in 10 files changed: 1 ins; 4 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559 PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Fri May 6 17:59:39 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 6 May 2022 17:59:39 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v2] In-Reply-To: References: Message-ID: > In Windows when desktop scaling was changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: resized instruction window and formatted line lengths ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/8222a27a..71a10fca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=00-01 Stats: 19 lines in 1 file changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From alanb at openjdk.java.net Fri May 6 17:59:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 6 May 2022 17:59:50 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777: > 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) { > 776: printStackWhenAccessFails = GetBooleanAction. > 777: privilegedGetProperty("sun.reflect.debugModuleAccessChecks"); Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From prr at openjdk.java.net Fri May 6 18:29:44 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 18:29:44 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults The xtoolkit change is fine. I've not looked at anything else You'll clearly need multiple reviewers for this one. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8559 From kcr at openjdk.java.net Fri May 6 21:25:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 6 May 2022 21:25:48 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. I agree with Phil. Whatever small benefit there might be in doing this isn't justified by the cost of reviewing and testing it, especially given the very real risk of introducing regressions. This PR should be withdrawn and the JBS bug closed as "Won't fix" ------------- Changes requested by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/7097 From achung at openjdk.java.net Fri May 6 22:09:30 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Fri, 6 May 2022 22:09:30 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v12] In-Reply-To: References: Message-ID: > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: - changed error message for gap between highlight and shadow - fixed coordinate checks - fixed bottom edge border starting x value, updated test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/a7935828..6767407d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=10-11 Stats: 169 lines in 2 files changed: 92 ins; 19 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From achung at openjdk.java.net Fri May 6 22:09:31 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Fri, 6 May 2022 22:09:31 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v11] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 18:00:16 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > saved translation values in EtchedBorder, updated test I verified the newest version of the test fails before the fix and passes after the fix ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From achung at openjdk.java.net Fri May 6 22:09:32 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Fri, 6 May 2022 22:09:32 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v11] In-Reply-To: References: Message-ID: <3oOuyRiYjJEbURX13SXCjFfAdvcp_K6dRUYLGouHBEQ=.a98737c0-8e08-46b2-af60-aa22bec881b0@github.com> On Fri, 6 May 2022 11:53:03 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> saved translation values in EtchedBorder, updated test > > src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 137: > >> 135: >> 136: g.drawLine((3*stkWidth/2)-1, h-(stkWidth-stkWidth/2), >> 137: w-(stkWidth-stkWidth/2), h-(stkWidth-stkWidth/2)); // bottom line > > Suggestion: > > g.drawLine(stkWidth/2, h-(stkWidth-stkWidth/2), > w-(stkWidth-stkWidth/2), h-(stkWidth-stkWidth/2)); // bottom line > > If you change the initial `x` to be `stkWidth/2`, it always aligns with the rectangle drawn in `paintBorderRect`. Thus the issue where the bottom highlight line is short of a few pixels gets resolved. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From duke at openjdk.java.net Fri May 6 23:17:55 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 6 May 2022 23:17:55 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes In-Reply-To: <3HBkT_7SmunSZ1cby1bQtYO_qZ_XQtQHV42fQsI7_vg=.b1043cdc-3e4c-45d6-be69-24b67c1b9e8b@github.com> References: <3HBkT_7SmunSZ1cby1bQtYO_qZ_XQtQHV42fQsI7_vg=.b1043cdc-3e4c-45d6-be69-24b67c1b9e8b@github.com> Message-ID: On Fri, 29 Apr 2022 00:36:15 GMT, Sergey Bylokhov wrote: >> In Windows when desktop scaling was changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Did you have a chance to check why the WM_DPICHANGED does not work, any specific cases? It is used by checking the scale change for windows in AWT, and no issues were reported for that as far as I know. @mrserb I wanted to add few more details about various window messages received during DPI changes. The order in which messages are received- 1. WM_DPICHANGED - if update is triggered at this point, the tray icons get distorted 2. WM_POSCHANGING - if update is triggered at this point, tray icons are rendered without any distortion. 3. WM_POSCHANGED - message received when tray icon is removed or exited. Kevin (@kevinrushforth) mentioned the usage of `WM_WINDOWPOSCHANGING` in JavaFX. Adding him to this PR conversation for suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Fri May 6 23:52:36 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 6 May 2022 23:52:36 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Fri, 6 May 2022 16:52:47 GMT, Laurent Bourg?s wrote: >> Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. >> This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. > > Please keep FloatMath alive to have floor/ceil (double) and I will anyway merge in my repo. > Go on Say the `Double.compare` change is dropped (makes sense; the method is not the same as the replaced code), the changes to RowFilter are undone (i.e. `abs()`), and the performance-critical code @bourgesl wants is kept. This leaves the ternary operators and FloatMath as changed. Does the risk of regression make readability improvements unworthy? Take this line for instance: int y = (itemBounds.y + itemBounds.height > screenBounds.y) ? itemBounds.y + itemBounds.height : screenBounds.y; // from int y = Math.max(itemBounds.y + itemBounds.height, screenBounds.y); // to I get that you're cautious, but this is more understandable to maintain. It takes much effort to really understand what the ternary operators are doing, and I believe that it is worth changing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From prr at openjdk.java.net Fri May 6 23:59:40 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 6 May 2022 23:59:40 GMT Subject: RFR: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. As per my request, please withdraw this PR and close the bug as will not fix. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7097 From wetmore at openjdk.java.net Sat May 7 00:08:45 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Sat, 7 May 2022 00:08:45 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults Sorry for the confusion. The original intent of this bug 14 years ago was to standardize the seclibs code where simple getProperty calls were needed in the context of an AccessController, without having to provide the doProvided calls. i.e. GetBooleanAction.privilegedGetProperty(). This was not intended not other parts of the JDK. For example: ChannelImpl.java provides a getBooleanProperty() method, which is very similar to GetBooleanAction. I noticed other places in the security where this was being done. Some of the classes like Debug have been rewritten (SSLLogger), so the issue does not appear to exist there any logger. The certpath code is working with Security.getProperty(), so that was a red herring. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From jjg at openjdk.java.net Sat May 7 01:10:14 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Sat, 7 May 2022 01:10:14 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` Message-ID: Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. ------------- Commit messages: - JDK-8286348: incorrect use of `@serial` Changes: https://git.openjdk.java.net/jdk/pull/8586/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286348 Stats: 13 lines in 13 files changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586 PR: https://git.openjdk.java.net/jdk/pull/8586 From iris at openjdk.java.net Sat May 7 01:35:42 2022 From: iris at openjdk.java.net (Iris Clark) Date: Sat, 7 May 2022 01:35:42 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: <_QHTrTTzgqDutXsASdnudMpPvx8ruKtR7xUvlMqf6a4=.28645e0b-0b22-46aa-9e56-5b6572229dad@github.com> On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From kcr at openjdk.java.net Sat May 7 13:04:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 7 May 2022 13:04:49 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:59:39 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > resized instruction window and formatted line lengths The fix looks good to me, but someone more familiar with the code will need to review it. I can confirm that the new test program fails without the fix and passes with the fix. One problem with the test is that it doesn't exit for me, regardless of whether the test passes or fails (or times out). To partially answer Sergey's question, the problem with just using `WM_DPICHANGED` to trigger the update is that the scale of the default screen transform used by `WTrayIconPeer::updateNativeImage` hasn't yet been updated to reflect that new DPI scale. I don't know _why_ that is the case here, but it is. I do know that in JavaFX we stopped relying on `WM_DPICHANGED` for anything related to HiDPI several years ago when fixing some multi-monitor HiDPI issues in [JDK-8146920](https://bugs.openjdk.java.net/browse/JDK-8146920). To show that triggering the update on `WM_DPICHANGED` is insufficient, I applied the patch from this PR, added some debugging output, and modified the fix to also update the image on a `WM_DPICHANGED` event. Here is the output when I start the program with a screen scale of 1.25 and then change it to 1.5: WM_WINDOWPOSCHANGING AwtTrayIcon::UpdateTrayIconHandler SystemTray::updateTrayIcons WTrayIconPeer::updateNativeImage : scale = (1.25, 1.25) WM_DPICHANGED AwtTrayIcon::UpdateTrayIconHandler SystemTray::updateTrayIcons WM_WINDOWPOSCHANGING AwtTrayIcon::UpdateTrayIconHandler SystemTray::updateTrayIcons WTrayIconPeer::updateNativeImage : scale = (1.25, 1.25) <----- This is from the WM_DPICHANGED event WTrayIconPeer::updateNativeImage : scale = (1.25, 1.25) WM_WINDOWPOSCHANGING AwtTrayIcon::UpdateTrayIconHandler SystemTray::updateTrayIcons WTrayIconPeer::updateNativeImage : scale = (1.5, 1.5) <----- Transform has now been updated WM_WINDOWPOSCHANGING AwtTrayIcon::UpdateTrayIconHandler SystemTray::updateTrayIcons WTrayIconPeer::updateNativeImage : scale = (1.5, 1.5) WM_WINDOWPOSCHANGING AwtTrayIcon::UpdateTrayIconHandler SystemTray::updateTrayIcons WTrayIconPeer::updateNativeImage : scale = (1.5, 1.5) So I think the fix using `WM_WINDOWPOSCHANGING` to trigger the update is good. I left a couple minor comments inline. src/java.desktop/share/classes/java/awt/SystemTray.java line 294: > 292: SwingUtilities.invokeLater(()->{ > 293: TrayIcon[] trayIconList = null; > 294: trayIconList = systemTray.getTrayIcons(); Minor: you can combine this into a single statement (no need to set it to `null` first). src/java.desktop/share/classes/java/awt/SystemTray.java line 300: > 298: return; > 299: } > 300: for (TrayIcon trayIcon: trayIconList) { Minor: we usually put a space both before and after the `:` when used as a for-each operator. src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 227: > 225: void AwtTrayIcon::UpdateTrayIconHandler() > 226: { > 227: jmethodID updateTrayFn; Minor: indentation not right ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Sun May 8 02:22:41 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 May 2022 02:22:41 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Jon, all of the changes in java.desktop are already underway in https://github.com/openjdk/jdk/pull/8432/files and have been approved and even have an approved CSR .. just waiting for @alisenchung to type /integrate .. ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From prr at openjdk.java.net Sun May 8 02:25:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 May 2022 02:25:50 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults I did wonder why it has security-libs as the sub-category and if the intent was not what we see here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From prr at openjdk.java.net Sun May 8 02:36:48 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 May 2022 02:36:48 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: On Sat, 8 Jan 2022 18:13:45 GMT, SWinxy wrote: > The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. > There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. > This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). Please do NOT just show up with a changeset. It is a waste of your time and ours. Send email to the client mailing list to discuss first. The amount of attention needed to review these changes and test them is out of all proportion to the absolutely zero benefit to users. As client lead, I suggest you find changes that actually make the product better, not these where the only possible change anyone can detect is a regression. Withdraw and close as will not fix. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7000 From prr at openjdk.java.net Sun May 8 02:47:37 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 May 2022 02:47:37 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement In-Reply-To: References: Message-ID: On Sat, 15 Jan 2022 03:44:17 GMT, SWinxy wrote: > The current implementation creates ~750 new objects on load Whereas yours creates an un-bounded number .. and changes that two lookups for the same name will return the same "==" object. If you can find a compatible way, that avoids both these problems . I can reconsider src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/XColors.java line 35: > 33: * @author Shannon Hickey > 34: * @author SWinxy > 35: */ You aren't the author, you are changing the file, and if we go anywhere near @author tags it is to remove them, not add them. Plus "Swinxy" is not very professional ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7096 From alanb at openjdk.java.net Sun May 8 05:18:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 8 May 2022 05:18:49 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: On Sun, 8 May 2022 02:22:08 GMT, Phil Race wrote: > I did wonder why it has security-libs as the sub-category and if the intent was not what we see here. I suspect the JBS issue was initially created to to look at the usages of getProperty in the security code but it has been extended. The issue is that it changes the meaning of the empty value case in at least two places so each one will require careful attention. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Sun May 8 13:37:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sun, 8 May 2022 13:37:40 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement In-Reply-To: References: Message-ID: On Sun, 8 May 2022 02:44:24 GMT, Phil Race wrote: > > The current implementation creates ~750 new objects on load > > Whereas yours creates an un-bounded number .. and changes that two lookups for the same name will return the same "==" object. That?s?not what?happens, since?`XColors::lookupColor` always?calls `new?ColorUIResource(?)` in?both the?old and?new?version. -------------------------------------------------------------------------------- The difference is that the old version would perform **O**(log?n) lookups with **O**(n) string comparisons per?lookup, whereas?the?new?one performs?a?single `String.hashCode()` invocation (the?result of?which is?cached[^1]) followed?by an?**O**(log?n)?`lookupswitch` and then an?**O**(1)?`tableswitch`. [^1]: https://github.com/openjdk/jdk/blob/9583e3657e43cc1c6f2101a64534564db2a9bd84/src/java.base/share/classes/java/lang/String.java#L2335-L2355 ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From duke at openjdk.java.net Sun May 8 19:36:33 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Sun, 8 May 2022 19:36:33 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: formatting changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/71a10fca..165a20b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=01-02 Stats: 19 lines in 2 files changed: 0 ins; 2 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Sun May 8 19:36:34 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Sun, 8 May 2022 19:36:34 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v2] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 13:01:53 GMT, Kevin Rushforth wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> resized instruction window and formatted line lengths > > The fix looks good to me, but someone more familiar with the code will need to review it. I can confirm that the new test program fails without the fix and passes with the fix. One problem with the test is that it doesn't exit for me, regardless of whether the test passes or fails (or times out). > > To partially answer Sergey's question, the problem with just using `WM_DPICHANGED` to trigger the update is that the scale of the default screen transform used by `WTrayIconPeer::updateNativeImage` hasn't yet been updated to reflect that new DPI scale. I don't know _why_ that is the case here, but it is. I do know that in JavaFX we stopped relying on `WM_DPICHANGED` for anything related to HiDPI several years ago when fixing some multi-monitor HiDPI issues in [JDK-8146920](https://bugs.openjdk.java.net/browse/JDK-8146920). > > To show that triggering the update on `WM_DPICHANGED` is insufficient, I applied the patch from this PR, added some debugging output, and modified the fix to also update the image on a `WM_DPICHANGED` event. Here is the output when I start the program with a screen scale of 1.25 and then change it to 1.5: > > > WM_WINDOWPOSCHANGING > AwtTrayIcon::UpdateTrayIconHandler > SystemTray::updateTrayIcons > WTrayIconPeer::updateNativeImage : scale = (1.25, 1.25) > WM_DPICHANGED > AwtTrayIcon::UpdateTrayIconHandler > SystemTray::updateTrayIcons > WM_WINDOWPOSCHANGING > AwtTrayIcon::UpdateTrayIconHandler > SystemTray::updateTrayIcons > WTrayIconPeer::updateNativeImage : scale = (1.25, 1.25) <----- This is from the WM_DPICHANGED event > WTrayIconPeer::updateNativeImage : scale = (1.25, 1.25) > WM_WINDOWPOSCHANGING > AwtTrayIcon::UpdateTrayIconHandler > SystemTray::updateTrayIcons > WTrayIconPeer::updateNativeImage : scale = (1.5, 1.5) <----- Transform has now been updated > WM_WINDOWPOSCHANGING > AwtTrayIcon::UpdateTrayIconHandler > SystemTray::updateTrayIcons > WTrayIconPeer::updateNativeImage : scale = (1.5, 1.5) > WM_WINDOWPOSCHANGING > AwtTrayIcon::UpdateTrayIconHandler > SystemTray::updateTrayIcons > WTrayIconPeer::updateNativeImage : scale = (1.5, 1.5) > > > So I think the fix using `WM_WINDOWPOSCHANGING` to trigger the update is good. I left a couple minor comments inline. @kevinrushforth Thank you for taking time to look into the fix and providing informative feedback. I'll check the test case exit issues and add the suggested changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From achung at openjdk.java.net Sun May 8 21:25:36 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Sun, 8 May 2022 21:25:36 GMT Subject: Integrated: 8284613: invalid use of @serial tag In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 19:48:15 GMT, Alisen Chung wrote: > Removed serial tag in method documentation This pull request has now been integrated. Changeset: cdd1b0da Author: Alisen Chung Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/cdd1b0da14837f4bf65a3450ab671ccc18c497f6 Stats: 12 lines in 12 files changed: 0 ins; 2 del; 10 mod 8284613: invalid use of @serial tag Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8432 From jjg at openjdk.java.net Mon May 9 01:02:46 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 01:02:46 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: <6Y-lOuoOL1sErefHH6psl-ADUySYCnXi5v1XqceO_Vo=.5b6bb529-e3e3-42f9-a318-16b11bc803cd@github.com> On Sun, 8 May 2022 02:19:09 GMT, Phil Race wrote: > Jon, all of the changes in java.desktop are already underway in https://github.com/openjdk/jdk/pull/8432/files and > have been approved and even have an approved CSR .. just waiting for @alisenchung to type /integrate .. Thanks for the heads up; I'll merge with Alisen's changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From duke at openjdk.java.net Mon May 9 01:55:37 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Mon, 9 May 2022 01:55:37 GMT Subject: RFR: 8285867 : Convert applet manual tests SelectionVisible.java to Frame and automate [v2] In-Reply-To: References: Message-ID: > 1) Removed Applet dependent code and used Frame as top level. > 2) Automated the manual test. > > @shurymury lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: Fixed disposing of frame with in EDT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8477/files - new: https://git.openjdk.java.net/jdk/pull/8477/files/f5cbf47a..b0839985 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8477&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8477&range=00-01 Stats: 15 lines in 2 files changed: 4 ins; 9 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8477.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8477/head:pull/8477 PR: https://git.openjdk.java.net/jdk/pull/8477 From psadhukhan at openjdk.java.net Mon May 9 05:48:01 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 9 May 2022 05:48:01 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v3] In-Reply-To: References: Message-ID: <38Bs6S4PRd9AC7g3wteV25vbss5jidtgSCJ8uZd_7yk=.c8cb8a80-e1a0-4d84-aabf-542f0ce4d780@github.com> On Fri, 6 May 2022 14:47:39 GMT, Tejesh R wrote: >> In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Added Regression Test JToolTip/5047379/bug5047379.java This will require CSR src/java.desktop/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java line 63: > 61: * The space between strings. > 62: */ > 63: public static final int padSpaceBetweenStrings = 12; I guess this can be removed from here and BasicToolTipUI as it is being defined in ToolTipUI src/java.desktop/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java line 199: > 197: // shared. > 198: @SuppressWarnings("deprecation") > 199: public String getAcceleratorString() { Although it is being placed in its super class so it can still be accessed but am still not sure if you can remove this public method from this public class without notifying via @deprecated or @forRemoval tag test/jdk/javax/swing/JToolTip/5047379/bug5047379.java line 4: > 2: @bug 5047379 > 3: @summary Checks that tooltips are rendered properly > 4: @author Shannon Hickey Remove @author tag test/jdk/javax/swing/JToolTip/5047379/bug5047379.java line 127: > 125: toolTipObj = (MetalToolTipUI) MetalToolTipUI.createUI(tooltip); > 126: break; > 127: case "WindowsClassic": Since it is supposed to be run on all platforms, this L&F cannot be hardcoded as this will not be applicable/present in all platforms ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From psadhukhan at openjdk.java.net Mon May 9 05:50:39 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 9 May 2022 05:50:39 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v7] In-Reply-To: References: Message-ID: <1yFa7xD-A3wPb7R6e9IAPjvAPMIYsn6RU7zyDc-MmWU=.ea1998a5-6b7b-477c-89c5-25442b5e193a@github.com> > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8141/files - new: https://git.openjdk.java.net/jdk/pull/8141/files/3cee561e..f5634e80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=05-06 Stats: 23 lines in 1 file changed: 12 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141 PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Mon May 9 05:50:40 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 9 May 2022 05:50:40 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v6] In-Reply-To: <90HJ1IkePEPjEC_84YWQEBhdiPg45Fhdk8bl8opy1Yg=.0e82edc6-20d3-4cf3-97b7-c06145fd0572@github.com> References: <90HJ1IkePEPjEC_84YWQEBhdiPg45Fhdk8bl8opy1Yg=.0e82edc6-20d3-4cf3-97b7-c06145fd0572@github.com> Message-ID: On Fri, 8 Apr 2022 12:41:29 GMT, Prasanta Sadhukhan wrote: >> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. >> This is because when the table is scrolled down to last page, the bounds.y becomes -ve >> [x=0,y=-15260,width=968,height=16000] >> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] >> but subsequent pages clip >> [[x=0,y=1296,width=968,height=1296], >> [x=0,y=2592,width=968,height=1296], >> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed >> >> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI >> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 >> >> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test fix > > I will rather not make the test more complicated...it's not a test fix..it just to verify the product fix.. > > I am not able to close in windows using ALT+F4 anyway... > > Other suggestions accepted... > > It doesn't make the code _too_ complicated. And it makes it complete so that it can be used as the start for other tests. > > Would you be able to apply the following patch? > @aivanov-jdk Thanks for your suggestions. I have updated the test ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Mon May 9 06:08:49 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 9 May 2022 06:08:49 GMT Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted padding [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 18:52:46 GMT, DamonGuy wrote: >> The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text. >> >> The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device. > > DamonGuy has updated the pull request incrementally with one additional commit since the last revision: > > Changed approach to fix. src/java.desktop/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java line 394: > 392: Insets insets = SynthLookAndFeel.getPaintingInsets(ss, paintInsets); > 393: > 394: final View v = (View)c.getClientProperty(BasicHTML.propertyKey); I guess this issue is only for JButton so is it needed to apply this for all components or we need to put a check for `c instance of JButton` test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 29: > 27: * @summary Tests HTML image as JButton text for unwanted padding on macOS Aqua LAF > 28: * @run main HtmlButtonImageTest > 29: */ I believe you have run this test on CI systems on all platforms ------------- PR: https://git.openjdk.java.net/jdk/pull/8407 From aghaisas at openjdk.java.net Mon May 9 07:10:10 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 9 May 2022 07:10:10 GMT Subject: RFR: 8261650: Add a comment with details for MTLVC_MAX_INDEX Message-ID: This is a trivial fix which adds more details about the constant MTLVC_MAX_INDEX. This had come up during the review of [JDK-8261632](https://bugs.openjdk.java.net/browse/JDK-8261632). ------------- Commit messages: - Add details about MTLVC_MAX_INDEX Changes: https://git.openjdk.java.net/jdk/pull/8592/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8592&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261650 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8592.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8592/head:pull/8592 PR: https://git.openjdk.java.net/jdk/pull/8592 From jdv at openjdk.java.net Mon May 9 07:54:48 2022 From: jdv at openjdk.java.net (Jayathirth D V) Date: Mon, 9 May 2022 07:54:48 GMT Subject: RFR: 8261650: Add a comment with details for MTLVC_MAX_INDEX In-Reply-To: References: Message-ID: On Mon, 9 May 2022 07:02:51 GMT, Ajit Ghaisas wrote: > This is a trivial fix which adds more details about the constant MTLVC_MAX_INDEX. > This had come up during the review of [JDK-8261632](https://bugs.openjdk.java.net/browse/JDK-8261632). Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8592 From avu at openjdk.java.net Mon May 9 09:23:00 2022 From: avu at openjdk.java.net (Alexey Ushakov) Date: Mon, 9 May 2022 09:23:00 GMT Subject: RFR: 8261650: Add a comment with details for MTLVC_MAX_INDEX In-Reply-To: References: Message-ID: <4TmawgyyoW3v793NTTinWzrU6j3wbeAgSH3hN6X-aaU=.51683484-5da5-4b2d-afdd-ee5a56103724@github.com> On Mon, 9 May 2022 07:02:51 GMT, Ajit Ghaisas wrote: > This is a trivial fix which adds more details about the constant MTLVC_MAX_INDEX. > This had come up during the review of [JDK-8261632](https://bugs.openjdk.java.net/browse/JDK-8261632). Marked as reviewed by avu (Committer). Looks good for me ------------- PR: https://git.openjdk.java.net/jdk/pull/8592 From duke at openjdk.java.net Mon May 9 12:19:49 2022 From: duke at openjdk.java.net (limck599) Date: Mon, 9 May 2022 12:19:49 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Marked as reviewed by limck599 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From kcr at openjdk.java.net Mon May 9 12:36:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 12:36:56 GMT Subject: RFR: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: On Sat, 8 Jan 2022 18:13:45 GMT, SWinxy wrote: > The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. > There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. > This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). For future contributions, I invite you to familiarize yourself with the [OpenJDK Contributing Guide](https://openjdk.java.net/guide/), and particularly the ["Socialize your change"](https://openjdk.java.net/guide/#socialize-your-change) section, which highlights the importance of discussing non-trivial changes ahead of time on the appropriate mailing list (client-libs-dev "at" openjdk.java.net, in this case), rather than just showing up with a pull request. ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From asotona at openjdk.java.net Mon May 9 16:05:46 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 9 May 2022 16:05:46 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments Message-ID: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. Thanks for your review, Adam ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments - 8244681: Add a warning for possibly lossy conversion in compound assignments Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244681 Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From duke at openjdk.java.net Mon May 9 16:15:48 2022 From: duke at openjdk.java.net (DamonGuy) Date: Mon, 9 May 2022 16:15:48 GMT Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted padding [v3] In-Reply-To: References: Message-ID: > The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text. > > The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device. DamonGuy has updated the pull request incrementally with one additional commit since the last revision: Fixed test summary. Added check for JButton. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8407/files - new: https://git.openjdk.java.net/jdk/pull/8407/files/05bd9a42..cc5091fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8407&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8407&range=01-02 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8407.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8407/head:pull/8407 PR: https://git.openjdk.java.net/jdk/pull/8407 From duke at openjdk.java.net Mon May 9 16:15:50 2022 From: duke at openjdk.java.net (DamonGuy) Date: Mon, 9 May 2022 16:15:50 GMT Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted padding [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 06:04:05 GMT, Prasanta Sadhukhan wrote: >> DamonGuy has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed approach to fix. > > src/java.desktop/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java line 394: > >> 392: Insets insets = SynthLookAndFeel.getPaintingInsets(ss, paintInsets); >> 393: >> 394: final View v = (View)c.getClientProperty(BasicHTML.propertyKey); > > I guess this issue is only for JButton so is it needed to apply this for all components or we need to put a check for `c instance of JButton` Wasn't completely sure if it was necessary to add the check since it passed without, meaning I wouldn't need to import JButton into this class. However, it does make sense to check for JButtons, so I made the change. Tested the change and everything still passes. > test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 29: > >> 27: * @summary Tests HTML image as JButton text for unwanted padding on macOS Aqua LAF >> 28: * @run main HtmlButtonImageTest >> 29: */ > > I believe you have run this test on CI systems on all platforms Thanks for catching that unedited summary. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8407 From aivanov at openjdk.java.net Mon May 9 16:29:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 9 May 2022 16:29:57 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v12] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:09:30 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with three additional commits since the last revision: > > - changed error message for gap between highlight and shadow > - fixed coordinate checks > - fixed bottom edge border starting x value, updated test Changes requested by aivanov (Reviewer). src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 31: > 29: import java.awt.Graphics2D; > 30: import java.awt.Insets; > 31: import java.awt.Rectangle; `Rectangle` is not used, please remove the import. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 66: > 64: public static JPanel parentPanel; > 65: public static JPanel childPanel; > 66: public static BufferedImage buff; The `buff` field is no longer used, it should be removed. All the panels can be local variables, they're only used in `createAndShowGUI`. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 69: > 67: public static Color highlight = Color.RED; > 68: public static Color shadow = Color.BLUE; > 69: public static boolean showFrame = false; The `showFrame` field can be local variable in `main` as you pass it to `createAndShowGUI`. Shall `createAndShowGUI` be renamed to `createGUI`? It doesn't always show GUI now. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 144: > 142: y, img, shadow, scaling); > 143: hBorderLoop(img.getWidth() - ((int) (Math.floor(scaling)+5*scaling)), img.getWidth(), > 144: y, img, highlight, scaling); According to your comment above, the check for horizontal should actually look the same as `checkVerticalBorder` but you change `x` rather than `y`. The current code doesn't catch the case where border lines are not adjacent. For the sake of simplicity, I'd add empty border on the right side of the panel: parentPanel.setBorder(BorderFactory.createEmptyBorder(0, i, 4, 4)); This makes sure the highlight colour is always followed by the background colour, thus you don't have to handle the case where the highlight colour is the last colour in the image. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 152: > 150: + thickness + " Scaling: " + scaling + " x: " + x); > 151: if (thickness > expected) throw new RuntimeException("Vertical Border drawn too thick. Thickness: " > 152: + thickness + " Scaling: " + scaling + " x: " + x); I guess `thickness != expected` is enough. I'd print both `x` and `y` where the error is detected. On the other hand, it's usually clear where the error is when you look at the image. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 169: > 167: + " Scaling: " + scaling + " x: " + x); > 168: } else { > 169: continue; `continue` statement is redundant because you can't get into another `if` block. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 266: > 264: } > 265: } > 266: } It's recommended to have a blank line in the end of files. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Mon May 9 16:30:01 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 9 May 2022 16:30:01 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v3] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 19:28:32 GMT, Alexey Ivanov wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> added functions for drawing border, fixed translate > > src/java.desktop/share/classes/javax/swing/border/TitledBorder.java line 36: > >> 34: import java.awt.Rectangle; >> 35: import java.awt.geom.Path2D; >> 36: import java.awt.geom.Rectangle2D; > > This import isn't used. There are no other changes to this file but this added import. > > In addition to it, you can also remove java.beans.PropertyChangeEvent from imports which is unused as well. Either revert the changes to `TitledBorder` or remove the two unused imports: `java.awt.geom.Rectangle2D` and `java.beans.PropertyChangeEvent`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From erikj at openjdk.java.net Mon May 9 16:33:56 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 9 May 2022 16:33:56 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8599 From duke at openjdk.java.net Mon May 9 17:00:50 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 9 May 2022 17:00:50 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Sun, 8 May 2022 19:36:33 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > formatting changes Following are the approaches tried for Tray icon issue fix ? **1. Using WM_DPICHANGED** ? issue with this approach is the delay in scale values update as @kevinrushforth pointed out earlier. **2. Using DisplayChangedListener** - To deal with delay in scale updates, @aivanov-jdk suggested to try DisplayChangedListener approach. This worked well, but tray icon distortion was still observed when the scales were changed in quick succession and especially when scaled down to 125%. Details of this approach - ? Implemented a DisplayChangedListener on WTrayIconPeer ? Added displayChangedListener to local graphics environment to listen for DPI changes in WTrayIconPeer ? Override the displayChanged() so that WTrayIconPeer?s updateImage() is called whenever the DPI changes for the default/main display. **3. Using WM_WINDOWPOSCHANGING** ? With present testing, there is no distortion observed when an update to tray icon is triggered on this message. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Mon May 9 17:31:52 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 9 May 2022 17:31:52 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v7] In-Reply-To: <1yFa7xD-A3wPb7R6e9IAPjvAPMIYsn6RU7zyDc-MmWU=.ea1998a5-6b7b-477c-89c5-25442b5e193a@github.com> References: <1yFa7xD-A3wPb7R6e9IAPjvAPMIYsn6RU7zyDc-MmWU=.ea1998a5-6b7b-477c-89c5-25442b5e193a@github.com> Message-ID: On Mon, 9 May 2022 05:50:39 GMT, Prasanta Sadhukhan wrote: >> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. >> This is because when the table is scrolled down to last page, the bounds.y becomes -ve >> [x=0,y=-15260,width=968,height=16000] >> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] >> but subsequent pages clip >> [[x=0,y=1296,width=968,height=1296], >> [x=0,y=2592,width=968,height=1296], >> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed >> >> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI >> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 >> >> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test updated Changes requested by aivanov (Reviewer). test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 27: > 25: * @bug 8257810 > 26: * @summary Verifies if all pages are printed if scrollRectToVisible is set. > 27: * @run main/manual PrintAllPagesTest Should the test have `@key printer` in its description? test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 136: > 134: > 135: dialog = new JDialog(f, "Instructions for Table Print Test"); > 136: dialog.setTitle("textselectionTest"); I guess this line should be removed now. The title for the dialog is provided in its constructor. test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 156: > 154: mainPanel.add(buttonPanel, BorderLayout.SOUTH); > 155: dialog.add(mainPanel); > 156: dialog.setUndecorated(true); Let's remove `dialog.setUndecorated(true);` line now that closing the dialog is properly handled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From duke at openjdk.java.net Mon May 9 17:42:12 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 9 May 2022 17:42:12 GMT Subject: Integrated: JDK-8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" In-Reply-To: References: Message-ID: On Mon, 2 May 2022 21:02:02 GMT, Harshitha Onkar wrote: > This test case tests the functionality of `setAlwaysOnTop`. > Documentation on `setAlwaysOnTop`: [Link](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/Window.html#setAlwaysOnTop(boolean)) > > The following test case was seen to fail on windows and linux platforms. With the proposed fix, the test case works on all platforms. > > The test case tests `alwaysOnTop` for the following three cases: > > 1. JDialog with no parent/owner > 2. JDialog with JFrame as owner > 3. JDialog with another JDialog as owner > > Each of the three cases mentioned above is tested under 3 scenarios: > ![Screen Shot 2022-05-02 at 2 02 30 PM](https://user-images.githubusercontent.com/95945681/166327299-0fb5ce14-478d-4dee-a03a-1009a8e17047.png) This pull request has now been integrated. Changeset: 837928ba Author: Harshitha Onkar Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/837928ba7955dbfd4a9c966209c3469c0fb5e195 Stats: 223 lines in 2 files changed: 128 ins; 35 del; 60 mod 8222323: ChildAlwaysOnTopTest.java fails with "RuntimeException: Failed to unset alwaysOnTop" Reviewed-by: prr, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/8509 From prr at openjdk.java.net Mon May 9 17:57:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 17:57:49 GMT Subject: RFR: 8261650: Add a comment with details for MTLVC_MAX_INDEX In-Reply-To: References: Message-ID: <7N-NfKMGN1QuEfEwNHWW9cUhz9OTE_9a3W3RQXU9Pjk=.43f64452-c585-4fea-bb18-55763b8afff9@github.com> On Mon, 9 May 2022 07:02:51 GMT, Ajit Ghaisas wrote: > This is a trivial fix which adds more details about the constant MTLVC_MAX_INDEX. > This had come up during the review of [JDK-8261632](https://bugs.openjdk.java.net/browse/JDK-8261632). Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8592 From prr at openjdk.java.net Mon May 9 17:55:55 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 17:55:55 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Marked as reviewed by prr (Reviewer). test/langtools/tools/javac/lint/LossyConversions.java line 131: > 129: @SuppressWarnings("lossy-conversions") > 130: public void supressedLossyConversions() { > 131: byte a = 0; you might want to spell suppressed correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From prr at openjdk.java.net Mon May 9 18:01:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:01:03 GMT Subject: RFR: 8030121: java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java fails In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:59:41 GMT, Manukumar V S wrote: > Removing MissingDragExitEventTest.java from ProblemList as JDK-8274597 already fixed the test and it's working fine now. > > Testing: > MissingDragExitEventTest.java test has been run 10 times on all 3 platforms and got all Pass. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8529 From prr at openjdk.java.net Mon May 9 18:03:17 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:03:17 GMT Subject: RFR: 8285867 : Convert applet manual tests SelectionVisible.java to Frame and automate [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 01:55:37 GMT, lawrence.andrews wrote: >> 1) Removed Applet dependent code and used Frame as top level. >> 2) Automated the manual test. >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed disposing of frame with in EDT Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8477 From prr at openjdk.java.net Mon May 9 18:06:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:06:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: <4TPEAEob1ukdLvqdnzddoOBEGrsVfkaQEG5-307Mxjw=.130e42ef-8170-4dcf-bce5-3b69615a6c2a@github.com> On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From prr at openjdk.java.net Mon May 9 18:13:11 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:13:11 GMT Subject: RFR: 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 11:22:48 GMT, Manukumar V S wrote: > This test verifies that showing a JPopupMenu shouldn't steal the focus out of current focused component.. > This fix moves an unstable closed test to open but updated to be more comprehensive in testing multiple Look and Feels and with some stabilisation improvements. The closed test had some dependencies with some proprietary libraries which are all removed here. > > Testing: > Tested using mach5 10 times per platform and got all Pass. test/jdk/javax/swing/JPopupMenu/JPopupMenuFocusStealTest.java line 104: > 102: SwingUtilities > 103: .invokeAndWait(JPopupMenuFocusStealTest::disposeFrame); > 104: } I know it'll work but similarly to another review (https://github.com/openjdk/jdk/pull/8477/files) it seems to me that you can recode as SwingUtilities.invokeAndWait( () -> isFocusOwner.set(comboBox.isFocusOwner())); SwingUtilities .invokeAndWait(JPopupMenuFocusStealTest::disposeFrame); if (isFocusOwner.get()) { System.out.println("Test Passed for " + laf); } else { throw new RuntimeException("Test Failed for " + laf); } and don't need the finally block ------------- PR: https://git.openjdk.java.net/jdk/pull/8426 From prr at openjdk.java.net Mon May 9 18:14:02 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:14:02 GMT Subject: RFR: 8285612 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 23:55:28 GMT, lawrence.andrews wrote: >> 1) Removed yesno to eliminate parserException >> 2) Added code to fit into manual framework so that timeout, pass & fail is handled. >> 3) Added code to mark the test as pass if printer service is not available >> 4) Added code to handle pressing or clicking of 'Cancel' button. >> >> @shurymury >> @aivanov-jdk > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Added @key printer Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8391 From jjg at openjdk.java.net Mon May 9 18:14:35 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 18:14:35 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v2] In-Reply-To: References: Message-ID: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge with upstream/master - JDK-8286348: incorrect use of `@serial` ------------- Changes: https://git.openjdk.java.net/jdk/pull/8586/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=01 Stats: 11 lines in 11 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586 PR: https://git.openjdk.java.net/jdk/pull/8586 From prr at openjdk.java.net Mon May 9 18:18:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:18:49 GMT Subject: RFR: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." [v5] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 09:16:04 GMT, Prasanta Sadhukhan wrote: >> Test used to fail in specific CI macos M1 system owing to miniscule color difference >> >> >> x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 >> x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 >> x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 >> x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 >> x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 >> >> >> SInce we already have color-tolerance check present, there is no need of exact color value check. >> Also, made the frame undecorated and remove unneeded library being built. >> Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Remove from PL > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8284888 > - Modify icon capture area > - Modify icon capture area > - Reduce color tolerance > - Fix I still think it is possible to enhance this by deliberating drawing the icons in different colors and expecting to see the rendered colours be the only difference and that they are in the same place in both cases .. but maybe what you have here is enough for now. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8380 From prr at openjdk.java.net Mon May 9 18:23:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:23:03 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset [v2] In-Reply-To: <2fPQGLdkv7f9ThHEpS9RleMYUPHhBMK6GHGFJ0mnwbQ=.df2d6df8-6e4e-4ef4-93db-6e13bf369ea3@github.com> References: <2fPQGLdkv7f9ThHEpS9RleMYUPHhBMK6GHGFJ0mnwbQ=.df2d6df8-6e4e-4ef4-93db-6e13bf369ea3@github.com> Message-ID: On Fri, 29 Apr 2022 12:43:41 GMT, Zhengyu Gu wrote: >> Please review this small patch that releases temporary charsets to avoid memory leak. >> >> Test: >> >> - [x] jdk_2d > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Andrew's comment Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8187 From prr at openjdk.java.net Mon May 9 18:25:59 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:25:59 GMT Subject: RFR: 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 05:10:23 GMT, Alexander Zuev wrote: > Only check that insets of the fully expanded undecorated window is not bigger than device insets. They can be smaller, it is a normal situation. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8314 From duke at openjdk.java.net Mon May 9 18:35:00 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Mon, 9 May 2022 18:35:00 GMT Subject: Integrated: 8284316 : Support accessibility ManualTestFrame.java for non SwingSet tests In-Reply-To: References: Message-ID: On Mon, 4 Apr 2022 23:39:33 GMT, lawrence.andrews wrote: > 1) Modified ManualTestFrame.java to support non SwingSet2 and this include modification of SwingSetTest.java > 2) Added new TestJProgressBarAccessibility.java testcase that uses ManualTestFrame > 3) Added timeout support in case user does not interact with the ManualTestFrame > > @shurymury > @azuev-java This pull request has now been integrated. Changeset: 6a7c0237 Author: lawrence.andrews Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/6a7c023796b0f39f54d0335f4723c1f06ff0032d Stats: 236 lines in 4 files changed: 189 ins; 29 del; 18 mod 8284316: Support accessibility ManualTestFrame.java for non SwingSet tests Reviewed-by: kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/8100 From prr at openjdk.java.net Mon May 9 18:36:59 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:36:59 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2] In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> >> if (clazz.isInstance(obj)) { >> >> Replacement is equivalent if it's known that `obj != null`. >> In JDK codebase there are many such places. >> >> I tried to measure performance via JMH >> >> Class integerClass = Integer.class; >> Class numberClass = Number.class; >> >> Object integerObject = 45666; >> Object doubleObject = 8777d; >> >> @Benchmark >> public boolean integerInteger_isInstance() { >> return integerClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean integerInteger_isAssignableFrom() { >> return integerClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public boolean integerDouble_isInstance() { >> return integerClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean integerDouble_isAssignableFrom() { >> return integerClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberDouble_isInstance() { >> return numberClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean numberDouble_isAssignableFrom() { >> return numberClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberInteger_isInstance() { >> return numberClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean numberInteger_isAssignableFrom() { >> return numberClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public void numberIntegerDouble_isInstance(Blackhole bh) { >> bh.consume(numberClass.isInstance(integerObject)); >> bh.consume(numberClass.isInstance(doubleObject)); >> } >> >> @Benchmark >> public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { >> bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); >> bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); >> } >> >> `isInstance` is a bit faster than `isAssignableFrom` >> >> Benchmark Mode Cnt Score Error Units >> integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op >> integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op >> integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op >> numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op >> integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op >> integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op >> numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op >> numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op >> numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op >> numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable > apply suggestion to avoid second Method.invoke call Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From prr at openjdk.java.net Mon May 9 18:41:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:41:49 GMT Subject: RFR: 8276849: Refresh the window icon on graphics configuration changes [v5] In-Reply-To: <8ubPWqU0vTLZW-eX7r2v9GAvrlp_4-mRKwuz8jwPHlM=.ee58d4d6-1ad0-409a-98cb-2d839e8187d6@github.com> References: <8ubPWqU0vTLZW-eX7r2v9GAvrlp_4-mRKwuz8jwPHlM=.ee58d4d6-1ad0-409a-98cb-2d839e8187d6@github.com> Message-ID: <7oii_TyaKIew4kFC_1vz7DXKTUg4kY2Sd-HbwztXPWE=.e76a15c7-a80e-4854-9642-dc50d4a86b88@github.com> On Fri, 25 Feb 2022 12:39:50 GMT, Emmanuel Bourg wrote: >> When a list of icons is set on a window, the most appropiate icon is selected depending on the graphics configuration. But if the graphics configuration changes (because the window is moved to a different screen, or because the DPI settings of the screen is changed), the frame icon isn't updated. >> >> Here is an example illustrating the issue: >> >> public static void main(String[] args) throws Exception { >> SwingUtilities.invokeLater(() -> { >> JFrame frame = new JFrame("Window Icon Test"); >> frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); >> frame.setSize(400, 300); >> frame.setVisible(true); >> >> List images = new ArrayList<>(); >> for (int size = 16; size <= 32; size++) { >> // create an image displaying the size used >> BufferedImage image = new BufferedImage(size, size, BufferedImage.TYPE_INT_ARGB); >> Graphics2D g = image.createGraphics(); >> g.setFont(new Font("dialog", Font.BOLD, 12)); >> g.setColor(Color.BLACK); >> g.drawString(String.valueOf(size), 0, size - (size - g.getFont().getSize()) / 2); >> images.add(image); >> } >> >> frame.setIconImages(images); >> }); >> } >> >> On Windows if the screen scaling is set to 100% the 16x16 icon is picked from the list. If the scaling of the screen is set to 150% while the application is running, the 16x16 icon is upscaled and looks blurry. >> >> A way to work around this issue is to listen for graphics configuration changes with: >> >> frame.addPropertyChangeListener("graphicsConfiguration", event -> frame.setIconImages(frame.getIconImages())); >> >> >> Ideally this should be done automatically by the JDK. Maybe the `WindowPeer` could call `updateIconImages()` when `updateGraphicsData()` or `displayChanged()` is invoked? > > Emmanuel Bourg has updated the pull request incrementally with one additional commit since the last revision: > > Don't refresh the frame icon on graphics configuration changes on macOS (not applicable) I think we are good here, modulo the requires !=mac for the test ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6180 From prr at openjdk.java.net Mon May 9 18:44:16 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:44:16 GMT Subject: RFR: 7124282: [macosx] Can't see table cell highlighter when the highlight border is the same color as the cell. [v13] In-Reply-To: <14wuJKRV_wzf0QtTpOODhGOghNcbGpHqN3daYz_wDJU=.90c0cc59-d36b-4ab9-ac1e-13c2bf965a1b@github.com> References: <14wuJKRV_wzf0QtTpOODhGOghNcbGpHqN3daYz_wDJU=.90c0cc59-d36b-4ab9-ac1e-13c2bf965a1b@github.com> Message-ID: On Wed, 27 Apr 2022 04:36:27 GMT, Harshitha Onkar wrote: >> Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. >> >> Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned. >> >> A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background. A note on the test case, since the test case is automated it tests the cell focus ring with colors loaded during the start of program execution and any on-the-fly accent color changes were tested manually. >> >> **Edge Cases** >> ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png) >> >> The edge case condition consists of two parts ? >> >> - To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions >> >> >> - To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors. (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite. The returned color is not exactly gray but grayish (r=135, g=135, b=140)). To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or tolerance of 0.10 or 10%. >> >> Used the following resources to test out different grayish colors and optimal saturation offsets used in `deriveLighterFocusRing()`. >> >> - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) >> - [Colorizer](http://colorizer.org/). >> - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo) >> >> **A note on the system-colors:** >> >> _For Mac 10.14 below:_ >> [keyboardfocusindicatorcolor](https://developer.apple.com/documentation/appkit/nscolor/1532031-keyboardfocusindicatorcolor) >> Issue: Works well for most of the scenarios (including on-the-fly changes) and follows the accent color changes except when we start the application with accent color set to Graphite and then change accent color on-the-fly The cell focus ring remains gray. The issue is with the system color returned by the type-property "keyboardfocusindicatorcolor" under this setting and NOT a JDK product bug. >> >> _For Mac 10.14+:_ >> [controlAccentColor](https://developer.apple.com/documentation/appkit/nscolor/3000782-controlaccentcolor) >> is available and it follows accent color changes (even when application started with Graphite as accent color). The proposed fix uses this type property when mac version is 10.14+ >> >> PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: > > - Merge branch 'master' into focusRing_7124282 > - chnaged variable name > - added new color to CSystemColors.m - CELL_HIGHLIGHT_COLOR > - Merge branch 'master' into focusRing_7124282 > - added new type property and changed method name > - Merge branch 'master' into focusRing_7124282 > - added more generic condition for edge case and formatted line lengths > - Merge branch 'openjdk:master' into focusRing_7124282 > - on-the-fly focus ring color changes added > - updated deriveContrastFocusRing method > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b74bd325...e82a1ca0 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7768 From prr at openjdk.java.net Mon May 9 18:46:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 18:46:54 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:14:35 GMT, Jonathan Gibbons wrote: >> Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. >> >> There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. >> >> Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge with upstream/master > - JDK-8286348: incorrect use of `@serial` Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From kcr at openjdk.java.net Mon May 9 19:01:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 19:01:47 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Sun, 8 May 2022 19:36:33 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > formatting changes Thanks for the additional comments. As far as I'm concerned, the only remaining question is the fact that the manual test doesn't exit for me when run from the command line. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Mon May 9 19:10:55 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 9 May 2022 19:10:55 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:57:57 GMT, Kevin Rushforth wrote: > Thanks for the additional comments. As far as I'm concerned, the only remaining question is the fact that the manual test doesn't exit for me when run from the command line. @kevinrushforth Thank you for the update Kevin. I'm currently looking into the test case exit issues when run from command line. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From dcubed at openjdk.java.net Mon May 9 19:28:13 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 19:28:13 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 Message-ID: A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. ------------- Commit messages: - 8286435: JDK-8284316 caused validate-source to fail in Tier1 Changes: https://git.openjdk.java.net/jdk/pull/8607/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8607&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286435 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8607.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8607/head:pull/8607 PR: https://git.openjdk.java.net/jdk/pull/8607 From mikael at openjdk.java.net Mon May 9 19:28:13 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Mon, 9 May 2022 19:28:13 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 19:16:46 GMT, Daniel D. Daugherty wrote: > A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8607 From dcubed at openjdk.java.net Mon May 9 19:28:14 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 19:28:14 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 19:18:23 GMT, Mikael Vidstedt wrote: >> A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8607 From dcubed at openjdk.java.net Mon May 9 19:28:15 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 9 May 2022 19:28:15 GMT Subject: Integrated: 8286435: JDK-8284316 caused validate-source to fail in Tier1 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 19:16:46 GMT, Daniel D. Daugherty wrote: > A trivial to solve JDK-8284316 caused validate-source to fail in Tier1. This pull request has now been integrated. Changeset: 02e5fc04 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/02e5fc04ccd046e9904302548f131b89d5f2954a Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8286435: JDK-8284316 caused validate-source to fail in Tier1 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/8607 From zgu at openjdk.java.net Mon May 9 19:45:49 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 19:45:49 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset [v3] In-Reply-To: References: Message-ID: > Please review this small patch that releases temporary charsets to avoid memory leak. > > Test: > > - [x] jdk_2d Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Cleanup at early return ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8187/files - new: https://git.openjdk.java.net/jdk/pull/8187/files/92ed6a78..2c74ef96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8187&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8187&range=01-02 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8187.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8187/head:pull/8187 PR: https://git.openjdk.java.net/jdk/pull/8187 From zgu at openjdk.java.net Mon May 9 19:45:49 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 19:45:49 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset In-Reply-To: References: Message-ID: On Wed, 4 May 2022 01:39:49 GMT, Andrew John Hughes wrote: > > > > > > > > > Hmmm, you are right. Phil probably pointed out the same problem, but I misunderstood it. > > What's odd is that, I tested (made sure that `FcCharSetDestroy` indeed called), it did not crash and `valgrind` showed the leak site disappeared. > > With your suggested fix, I think we still leak last `unionCharset`. BTW, the API documentation is really unhelpful, Sigh! > > That's fixed by your addition at the end, right? > > I assumed the final unionCharset was used for something, but it never seems to actually be read, just continually added to and then drops out of scope. ` if ((*FcCharSetSubtractCount)(charset, unionCharset) > minGlyphs) { ` Seems this is the only use of unionCharset. > > It may also need to be freed in the `if (result != FcResultMatch) {` block which frees everything else and returns from within the inner loop. Right, updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8187 From prr at openjdk.java.net Mon May 9 20:04:55 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 20:04:55 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset [v3] In-Reply-To: References: Message-ID: <2e2kIVfQYeb4i_yl7ElW3znBL9B7krwe2cHqsCi-Bpg=.1f548044-f895-4ddc-8d2b-1dc05376baf0@github.com> On Mon, 9 May 2022 19:45:49 GMT, Zhengyu Gu wrote: >> Please review this small patch that releases temporary charsets to avoid memory leak. >> >> Test: >> >> - [x] jdk_2d > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup at early return Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8187 From jjg at openjdk.java.net Mon May 9 20:19:45 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 20:19:45 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v3] In-Reply-To: References: Message-ID: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com> > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace (blank lines) after merge ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8586/files - new: https://git.openjdk.java.net/jdk/pull/8586/files/d1920183..8684b44b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8586&range=01-02 Stats: 10 lines in 10 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8586/head:pull/8586 PR: https://git.openjdk.java.net/jdk/pull/8586 From prr at openjdk.java.net Mon May 9 20:24:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 20:24:50 GMT Subject: RFR: JDK-8286348: incorrect use of `@serial` [v3] In-Reply-To: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com> References: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com> Message-ID: On Mon, 9 May 2022 20:19:45 GMT, Jonathan Gibbons wrote: >> Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. >> >> There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. >> >> Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace (blank lines) after merge Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From prr at openjdk.java.net Mon May 9 20:24:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 20:24:54 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement In-Reply-To: References: Message-ID: On Sun, 8 May 2022 13:33:53 GMT, ExE Boss wrote: > That?s not what happens, since XColors::lookupColor always calls new ColorUIResource(?) in both the old and new version. You are correct. I over-looked the toColor() implementation. Ok. this should be fine once the author tag is removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From darcy at openjdk.java.net Mon May 9 20:26:56 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 9 May 2022 20:26:56 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <8O_QfMi1b_fhddBS7yzm9cwzf-l6nWbfNs6qFJWdtuU=.22f44b80-54e8-4249-8ece-d02be29f4267@github.com> On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From aivanov at openjdk.java.net Mon May 9 20:28:53 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 9 May 2022 20:28:53 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: <98aoE1GBPwsXFYZEoKJcJjyicTd_-MOdH9smmUdi5pM=.e106b9e7-ddd5-4f79-8f9b-ca1c0fa9ae7a@github.com> On Sun, 8 May 2022 19:36:33 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > formatting changes Yes, with `WM_DPICHANGED` we faced the problem that Kevin describes: the update method gets called before the transform is updated. Thus it doesn't work. Updating the transform, in its turn, calls `DisplayChangedListener`. It worked. Yet Harshitha's testing showed it wasn't reliable. That's why she went for the third approach, which proved to work reliably. However, I haven't tested the latest version myself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Mon May 9 20:31:46 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 20:31:46 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v7] In-Reply-To: References: <1yFa7xD-A3wPb7R6e9IAPjvAPMIYsn6RU7zyDc-MmWU=.ea1998a5-6b7b-477c-89c5-25442b5e193a@github.com> Message-ID: On Mon, 9 May 2022 17:09:10 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test updated > > test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 136: > >> 134: >> 135: dialog = new JDialog(f, "Instructions for Table Print Test"); >> 136: dialog.setTitle("textselectionTest"); > > I guess this line should be removed now. The title for the dialog is provided in its constructor. Why can't this use the new PassFailJFrame ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From jjg at openjdk.java.net Mon May 9 20:38:52 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 9 May 2022 20:38:52 GMT Subject: Integrated: JDK-8286348: incorrect use of `@serial` In-Reply-To: References: Message-ID: On Sat, 7 May 2022 01:04:03 GMT, Jonathan Gibbons wrote: > Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. > > There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. > > Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. This pull request has now been integrated. Changeset: 54e33082 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/54e33082105dcbcfc795839c954f6e63402edff1 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8286348: incorrect use of `@serial` Reviewed-by: iris, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From achung at openjdk.java.net Mon May 9 20:42:06 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 9 May 2022 20:42:06 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v13] In-Reply-To: References: Message-ID: > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: made changes according to comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/6767407d..e7b27064 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=11-12 Stats: 91 lines in 3 files changed: 23 ins; 33 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Mon May 9 21:04:14 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 9 May 2022 21:04:14 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Sun, 8 May 2022 19:36:33 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > formatting changes src/java.desktop/share/classes/java/awt/SystemTray.java line 297: > 295: // no tray icons present so do nothing > 296: return; > 297: } According to the spec, [`SystemTray.getTrayIcons()`](https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/SystemTray.html#getTrayIcons()) never returns `null`. So the condition could be removed completely. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 38: > 36: import java.awt.image.BaseMultiResolutionImage; > 37: import java.awt.image.BufferedImage; > 38: import java.awt.*; Could you please expand wildcard imports? And sort the imports too? test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 73: > 71: System.out.println("SystemTray is not supported"); > 72: return; > 73: } This should be the first statement in main. If icons aren't supported, there's no need to create the instruction frame. The test will still wait for user's response but no tray icon is added. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 79: > 77: for (int size = 16; size <= 34; size++) { > 78: createIcon(size, images); > 79: } You should go up to 48 at least, which corresponds to 300% scale in Windows settings; it's not as uncommon these days on UHD laptops. The step could be 4: `size += 4`, it's the number of pixels an icon scales with each step 25% of scale in Windows settings. Windows still allows setting an arbitrary scale but it's discouraged, so we may assume the scale is changed via the main Settings app. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 84: > 82: > 83: SystemTray tray = SystemTray.getSystemTray(); > 84: TrayIcon icon = new TrayIcon((Image) multiResolutionImage); You can change the type of `multiResolutionImage` to `Image` to avoid casting when creating `TrayIcon`. The fact that it's a `MultiResolutionImage` isn't used down the code. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 100: > 98: tray.remove(icon); > 99: System.exit(0); > 100: }); You shouldn't call `System.exit` from a jtreg test. The icon should probably be removed after pressing Pass or Fail button, this is likely what prevents the test from exiting. The popup menu isn't important for this test case. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 115: > 113: g.setColor(Color.WHITE); > 114: g.fillRect(0, 0, size, size); > 115: g.setFont(new Font("Dialog", Font.BOLD, 12)); It could be more effective to create `Font` once and use it for rendering text for each icon size but it's not really important for a short-lived test. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 126: > 124: g.dispose(); > 125: } > 126: } Usually, files end with a new line. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Mon May 9 21:06:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 9 May 2022 21:06:57 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v7] In-Reply-To: References: <1yFa7xD-A3wPb7R6e9IAPjvAPMIYsn6RU7zyDc-MmWU=.ea1998a5-6b7b-477c-89c5-25442b5e193a@github.com> Message-ID: <88A8ji0q-G1SsoQ5JdG2bymwuJfZHjMxzM_Hv723Le0=.5bcc47ae-a415-4473-8ecc-c87f760d5f26@github.com> On Mon, 9 May 2022 20:28:37 GMT, Phil Race wrote: >> test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 136: >> >>> 134: >>> 135: dialog = new JDialog(f, "Instructions for Table Print Test"); >>> 136: dialog.setTitle("textselectionTest"); >> >> I guess this line should be removed now. The title for the dialog is provided in its constructor. > > Why can't this use the new PassFailJFrame ? It can. Yet the test had been written before `PassFailJFrame` was integrated. I'm fine with either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From prr at openjdk.java.net Mon May 9 21:10:58 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 9 May 2022 21:10:58 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> On Sun, 8 May 2022 19:36:33 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > formatting changes Changes requested by prr (Reviewer). src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 238: > 236: if (updateTrayFn != NULL) { > 237: env->CallStaticVoidMethod(systemTrayClass, > 238: updateTrayFn); Most of these JNI methods can leave an exception pending https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#findclass https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#getstaticmethodid https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#callstatictypemethod-routines-callstatictypemethoda-routines-callstatictypemethodv-routines I think you should be calling ExceptionClear() because subsequent methods should not be called with an exception pending. And this is a windows thread attached to the VM and it never "returns to Java" but will be called back to handle later events. src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 262: > 260: // (generated when DPI changes) > 261: case WM_WINDOWPOSCHANGING: > 262: if (hwnd == AwtTrayIcon::sm_msgWindow) { I'd just like to be sure .. this message is not sent when an application window is moved, right ? It is just sent to the tray icon window .. and so happens only if someone did something like re-orged tray icons .. or the dpi changes ? In other words I'd like to be sure it is a rare event. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 72: > 70: if (!SystemTray.isSupported()) { > 71: System.out.println("SystemTray is not supported"); > 72: return; Hmm. When you get here, you already displayed the instructions window, and in the jtreg harness, the user will not see this message. They'll just not see the tray icon and assume it failed. I think you should be making use of the "forcePass()" code in PassFailJFrame test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 99: > 97: exitItem.addActionListener(e -> { > 98: tray.remove(icon); > 99: System.exit(0); Even if it is manual etc, we don't call System.exit() in jtreg tests .. we just shut down all the windows and dispose them so there is nothing to keep the main thread from exiting. If this is called, I don't know why Kevin didn't see the app exit. I suspect it cannot have been and he exited via some other path which left windows in existence which meant the toolkit thread didn't exit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Mon May 9 21:26:57 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 9 May 2022 21:26:57 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> References: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> Message-ID: On Mon, 9 May 2022 21:07:49 GMT, Phil Race wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting changes > > Changes requested by prr (Reviewer). @prrace @aivanov-jdk Thank you for all the feedback and suggestions. I'll make sure to address all of them in the next update. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Mon May 9 21:34:00 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 9 May 2022 21:34:00 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> References: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> Message-ID: <6q__td8K33ttE-8vfCrPZGnl3_YJH_kkiW_aZnBFzjE=.95630f6d-fbf2-43a1-89c2-7eb6ebe1e3bb@github.com> On Mon, 9 May 2022 20:50:56 GMT, Phil Race wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting changes > > src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 262: > >> 260: // (generated when DPI changes) >> 261: case WM_WINDOWPOSCHANGING: >> 262: if (hwnd == AwtTrayIcon::sm_msgWindow) { > > I'd just like to be sure .. this message is not sent when an application window is moved, right ? > It is just sent to the tray icon window .. and so happens only if someone did something like re-orged tray icons .. > or the dpi changes ? In other words I'd like to be sure it is a rare event. @prrace So far, based on testing the message is received only for tray icon window. To be doubly sure, I'll test the scenarios when we receive this message on Tray Icon's Window procedure. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Mon May 9 21:40:54 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 9 May 2022 21:40:54 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v13] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 20:42:06 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > made changes according to comments Changes requested by aivanov (Reviewer). test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 102: > 100: for (Point p : panelLocations) { > 101: int y = (int) (p.y * scaling) + SIZE.height / 2; > 102: System.out.println(scaling + " : " + y); Probably printing of `scale` and `y` can be removed. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 109: > 107: } > 108: > 109: private static void checkHorizontalBorder(int y, BufferedImage img, double scaling) throws RuntimeException { There's no need to declare `RuntimeException` in throws clause. If you prefer to, please wrap the line, it's longer than 100 columns. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 149: > 147: private static void verifyThickness(int x, int thickness, double scaling, String orientation) { > 148: int expected = (int) Math.floor(scaling); > 149: if (thickness != expected) throw new RuntimeException("Unexpected " + orientation + " Border thickness."); Suggestion: if (thickness != expected) { throw new RuntimeException("Unexpected " + orientation + " Border thickness."); } Please always use braces even for blocks with one statement only. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From kcr at openjdk.java.net Mon May 9 21:59:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:59:48 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: <6q__td8K33ttE-8vfCrPZGnl3_YJH_kkiW_aZnBFzjE=.95630f6d-fbf2-43a1-89c2-7eb6ebe1e3bb@github.com> References: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> <6q__td8K33ttE-8vfCrPZGnl3_YJH_kkiW_aZnBFzjE=.95630f6d-fbf2-43a1-89c2-7eb6ebe1e3bb@github.com> Message-ID: On Mon, 9 May 2022 21:30:13 GMT, Harshitha Onkar wrote: > So far, based on testing the message is received only for tray icon window. That matches what I see as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From kcr at openjdk.java.net Mon May 9 21:59:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 9 May 2022 21:59:49 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> References: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> Message-ID: On Mon, 9 May 2022 21:02:11 GMT, Phil Race wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting changes > > test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 99: > >> 97: exitItem.addActionListener(e -> { >> 98: tray.remove(icon); >> 99: System.exit(0); > > Even if it is manual etc, we don't call System.exit() in jtreg tests .. we just shut down all the windows and dispose them so there is nothing to keep the main thread from exiting. > If this is called, I don't know why Kevin didn't see the app exit. > I suspect it cannot have been and he exited via some other path which left windows in existence which meant the toolkit thread didn't exit. The `actionListener` is only called if you right click on the tray icon and select the Exit option. I didn't do that, so it never got here. Maybe the "Exit" button in the icon should be turned into a no-op, since you want the tester to press Pass or Fail to exit? I think Alexey may have pointed out the problem with the test not exiting: it doesn't dispose the tray icon. That needs to be confirmed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From achung at openjdk.java.net Mon May 9 22:04:38 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 9 May 2022 22:04:38 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v14] In-Reply-To: References: Message-ID: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: made suggested changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/e7b27064..b84cf51a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=12-13 Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From sebastian.luckner at st.oth-regensburg.de Mon May 9 23:28:20 2022 From: sebastian.luckner at st.oth-regensburg.de (Sebastian Luckner) Date: Mon, 9 May 2022 23:28:20 +0000 Subject: AW: [EXT] Re: RFR: JDK-8286348: incorrect use of `@serial` [v3] In-Reply-To: References: <_j4p9lLYLNTExFqEbx6Uwwwohdj7PY9nfOIh10fWQ60=.d5d107a5-6565-4fa9-abec-fe806e4d35ab@github.com>, Message-ID: public class bam0 { private static long parseLong(/*private **/String w) { long m = 1; long i = 2; long _q = 5; long value = 0; for(int p = w.length() - 1; p >= 0; --p) { if( w.charAt(p) == '1' ) value = value + m; m = m * 2; } return value; } /** * * 1 + (512 + 32 + 4) * 5 - 1 * * 1 + (512 + 32 + 4) * 5 - 1 + 2 * 548 * 5 * 1 - (1 + (512 + 32 + 4) * 5 - 1) * 2 * * 1 + (512 + 32 + 4) * 5 - 1 + 1 + (512 + 32 + 4) * 5 - 1 + 2 * 548 * 1 - 1 * 2 + 3 * (512 + 32 + 4) * ( 4 + 1 ) * 1 - ( 1 + (512 + 32 + 4) * 5 - 1 ) * (1 + (512 + 32 + 4) * ( 5 - 1 + 2 * 548 * 1 - 1 * 2 ) * 3) * * :[ * * */ public static void main(String[] args) { int i = (0b101010101010101010 | 0b0101101010101010) % 0b0110101010101010101001; while(i > 0) { main0(null); --i; } } public static void main0(String[] args) { long x, y, z; final long b = parseLong("1000100100"); final long a = parseLong("101"); //=!!=!=!=!=!=!==!!=!=!=!=!=!==!!=!=!=!==!!=!=!=!=!=!=!==!!=!=!==!=!!==!=!=!!= final long m = parseLong("1"); x = 1; y = 0; z = 0; for(int _b = 0; _b < 3; ++_b) { x = x + b*a - m; y = 2; for(int _a = 0; _a < 4; ++_a) { y = x + y * b * a * m - x * y; z = 3; for(int _m = 0; _m < 5; ++_m) { z = x + y + z * b * a * m - x * y * z; System.out.println(x); // 2740 System.out.println(y); // 2740 System.out.println(z); // -22509100 } } } //System.out.println("x:" + x + "|y:" + y + "|z:" + z); } } ________________________________ Von: client-libs-dev im Auftrag von Phil Race Gesendet: Montag, 9. Mai 2022 22:24:50 An: client-libs-dev at openjdk.java.net; security-dev at openjdk.java.net Betreff: [EXT] Re: RFR: JDK-8286348: incorrect use of `@serial` [v3] On Mon, 9 May 2022 20:19:45 GMT, Jonathan Gibbons wrote: >> Please review a fix to remove incorrect use of the `@serial` tag from the doc comments for methods such as `readObject` and `readResolve`. The tag has no effect in this position other than to trigger warnings from the standard doclet when running javadoc. >> >> There is no change to the generated documentation as a result off this change. In particular, there is no change to the API docs for any of the modified files, or to the overall top-level serialized-form.html file. >> >> Although most of the affected files are in the `java.desktop` module, there is one outlier, in `java.security.Provider`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace (blank lines) after merge Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8586 From psadhukhan at openjdk.java.net Tue May 10 04:07:46 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 10 May 2022 04:07:46 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v8] In-Reply-To: References: Message-ID: > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8257810 - Test updated - Test fix - Test fix - Test fix - Test updated - Test updated - Test updated - Fix - Fix - ... and 1 more: https://git.openjdk.java.net/jdk/compare/04708cc9...d94ae83d ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8141/files - new: https://git.openjdk.java.net/jdk/pull/8141/files/f5634e80..d94ae83d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=06-07 Stats: 442880 lines in 6156 files changed: 342765 ins; 43394 del; 56721 mod Patch: https://git.openjdk.java.net/jdk/pull/8141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141 PR: https://git.openjdk.java.net/jdk/pull/8141 From aghaisas at openjdk.java.net Tue May 10 04:14:48 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 10 May 2022 04:14:48 GMT Subject: Integrated: 8261650: Add a comment with details for MTLVC_MAX_INDEX In-Reply-To: References: Message-ID: <_LJJ8vCNqL_RqCqt2WWswqPIW8_e58bBiw8f6HR1pt0=.76be96eb-0726-4650-a961-75ec6c769464@github.com> On Mon, 9 May 2022 07:02:51 GMT, Ajit Ghaisas wrote: > This is a trivial fix which adds more details about the constant MTLVC_MAX_INDEX. > This had come up during the review of [JDK-8261632](https://bugs.openjdk.java.net/browse/JDK-8261632). This pull request has now been integrated. Changeset: ace42306 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jdk/commit/ace42306345da21345d4d18931f879811615f9d9 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod 8261650: Add a comment with details for MTLVC_MAX_INDEX Reviewed-by: jdv, avu, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8592 From mvs at openjdk.java.net Tue May 10 04:39:58 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Tue, 10 May 2022 04:39:58 GMT Subject: Integrated: 8030121: java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java fails In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:59:41 GMT, Manukumar V S wrote: > Removing MissingDragExitEventTest.java from ProblemList as JDK-8274597 already fixed the test and it's working fine now. > > Testing: > MissingDragExitEventTest.java test has been run 10 times on all 3 platforms and got all Pass. This pull request has now been integrated. Changeset: 9a3cb930 Author: Manukumar V S Committer: Abdul Kolarkunnu URL: https://git.openjdk.java.net/jdk/commit/9a3cb930387d136af2cb6dea4cb7f452b37508bd Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8030121: java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java fails Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8529 From alanb at openjdk.java.net Tue May 10 05:46:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 05:46:40 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From psadhukhan at openjdk.java.net Tue May 10 06:03:33 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 10 May 2022 06:03:33 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v9] In-Reply-To: References: Message-ID: > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Use PassFailJFrame ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8141/files - new: https://git.openjdk.java.net/jdk/pull/8141/files/d94ae83d..6e19fbed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=07-08 Stats: 109 lines in 1 file changed: 30 ins; 68 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141 PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Tue May 10 06:11:26 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 10 May 2022 06:11:26 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v10] In-Reply-To: References: Message-ID: > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8141/files - new: https://git.openjdk.java.net/jdk/pull/8141/files/6e19fbed..df0f7c74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=08-09 Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141 PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Tue May 10 06:26:29 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 10 May 2022 06:26:29 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v11] In-Reply-To: References: Message-ID: > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8141/files - new: https://git.openjdk.java.net/jdk/pull/8141/files/df0f7c74..863b5e4c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141 PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Tue May 10 06:26:29 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 10 May 2022 06:26:29 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v7] In-Reply-To: <88A8ji0q-G1SsoQ5JdG2bymwuJfZHjMxzM_Hv723Le0=.5bcc47ae-a415-4473-8ecc-c87f760d5f26@github.com> References: <1yFa7xD-A3wPb7R6e9IAPjvAPMIYsn6RU7zyDc-MmWU=.ea1998a5-6b7b-477c-89c5-25442b5e193a@github.com> <88A8ji0q-G1SsoQ5JdG2bymwuJfZHjMxzM_Hv723Le0=.5bcc47ae-a415-4473-8ecc-c87f760d5f26@github.com> Message-ID: <7lVub-B8wfHgqh6pf_aMu-V6BkjkLoeo3b4yPMokNYM=.9852e31c-4a8a-4c6c-9a85-bd2b3175d840@github.com> On Mon, 9 May 2022 21:04:51 GMT, Alexey Ivanov wrote: >> Why can't this use the new PassFailJFrame ? > > It can. Yet the test had been written before `PassFailJFrame` was integrated. > > I'm fine with either way. I thought it was only for applet/manual test conversion to normal manual. Anyway, modifited test to use PassFailJFrame.. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Tue May 10 06:32:45 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 10 May 2022 06:32:45 GMT Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted padding [v3] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 16:15:48 GMT, DamonGuy wrote: >> The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text. >> >> The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device. > > DamonGuy has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test summary. Added check for JButton. test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 116: > 114: ImageIO.write(image, "png", > 115: new File(testDir + "/fail_image.png")); > 116: throw new RuntimeException("HTML image not centered in button"); overall looks ok. Only thing is during failure, it does not show for which L&F the test is failing since you are iterating for all L&Fs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8407 From duke at openjdk.java.net Tue May 10 06:37:53 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Tue, 10 May 2022 06:37:53 GMT Subject: Integrated: 7124282: [macosx] Can't see table cell highlighter when the highlight border is the same color as the cell. In-Reply-To: References: Message-ID: <6VytuJVAqaeuPj9hix6MXFdMxvc-U94VE2uAuKDjEx0=.bb3166f9-1089-40b4-91f7-88d3300aefd5@github.com> On Thu, 10 Mar 2022 02:42:00 GMT, Harshitha Onkar wrote: > Previously while tabbing through the JTable cell, the cell highlighter/focus ring was not visible against the selection background. > > Changes are made to Aqua LAF to derive a lighter focus ring color by changing saturation and setting brightness component to 100% of original focus ring color so that it is visible while tabbing through `JTable` cells. A new method is added for this purpose which takes in `focusRingColor`, does adjustment to saturation and brightness and returns a new focus ring color. There are edge cases where the HSB transformation does not yield the right focus ring color, for these cases a default color is returned. > > A test case is added to compare the RGB difference between the original focus ring color & selection background and the new focus ring color & selection background. A note on the test case, since the test case is automated it tests the cell focus ring with colors loaded during the start of program execution and any on-the-fly accent color changes were tested manually. > > **Edge Cases** > ![image](https://user-images.githubusercontent.com/95945681/161360456-3929acf1-282b-4c2b-95d1-1d5707c1e238.png) > > The edge case condition consists of two parts ? > > - To handle white/black colors - (hsbValues[0] == 0 && hsbValues[1] == 0) - representing hue and saturation of zero obtained for black, white or exactly grey (red=green=color) conditions > > > - To handle grayish colors - hsbValues[1] <= satGrayScale where satGrayScale <= 0.10 . For any given hue and brightness, a saturation of less than or equal to 10% represents grayish tint colors. (The second case was added to accommodate grayish focus ring color returned by system when Accent color = Graphite. The returned color is not exactly gray but grayish (r=135, g=135, b=140)). To accommodate a more generic case of grayish colors, the satGrayScale has a threshold or tolerance of 0.10 or 10%. > > Used the following resources to test out different grayish colors and optimal saturation offsets used in `deriveLighterFocusRing()`. > > - [RapidTables](https://www.rapidtables.com/convert/color/rgb-to-hsl.html) > - [Colorizer](http://colorizer.org/). > - [Chart Link](https://codepen.io/HunorMarton/details/eWvewo) > > **A note on the system-colors:** > > _For Mac 10.14 below:_ > [keyboardfocusindicatorcolor](https://developer.apple.com/documentation/appkit/nscolor/1532031-keyboardfocusindicatorcolor) > Issue: Works well for most of the scenarios (including on-the-fly changes) and follows the accent color changes except when we start the application with accent color set to Graphite and then change accent color on-the-fly The cell focus ring remains gray. The issue is with the system color returned by the type-property "keyboardfocusindicatorcolor" under this setting and NOT a JDK product bug. > > _For Mac 10.14+:_ > [controlAccentColor](https://developer.apple.com/documentation/appkit/nscolor/3000782-controlaccentcolor) > is available and it follows accent color changes (even when application started with Graphite as accent color). The proposed fix uses this type property when mac version is 10.14+ > > PS: The native L&F (Mac OS) and Swing L&F for JTable cell tabbing differs (on native tables the cell background turns white on focus with a cell focus ring). Since the background for Swing tables can be set by users and also overridden by subclassing `DefaultTableCellRenderer`, and to adhere to current implementation of Swing, the white cell background changes are not incorporated. Only the Focus Ring/ Cell Highlighter is made more prominent. This pull request has now been integrated. Changeset: bd6026c1 Author: Harshitha Onkar Committer: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/bd6026c10c5b24d816be9a5bf248c2aa3d8c1f4e Stats: 263 lines in 6 files changed: 249 ins; 0 del; 14 mod 7124282: [macosx] Can't see table cell highlighter when the highlight border is the same color as the cell. Reviewed-by: psadhukhan, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/7768 From mbaesken at openjdk.java.net Tue May 10 06:48:40 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 10 May 2022 06:48:40 GMT Subject: Integrated: JDK-8285730: unify _WIN32_WINNT settings In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken wrote: > Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : > https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt > Macros for Conditional Declarations > "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." > > However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). This pull request has now been integrated. Changeset: 4fd79a6a Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/4fd79a6ad2683e4863bd4e311cb01cbc30ebf57f Stats: 33 lines in 7 files changed: 2 ins; 25 del; 6 mod 8285730: unify _WIN32_WINNT settings Reviewed-by: dholmes, erikj, ihse, prr, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From psadhukhan at openjdk.java.net Tue May 10 06:57:49 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 10 May 2022 06:57:49 GMT Subject: RFR: 8283705: Make javax.sound.midi.Track a final class In-Reply-To: References: Message-ID: On Sun, 1 May 2022 21:15:33 GMT, Phil Race wrote: > This is the straggler from several PRs which were around making JDK classes sealed. > There's nothing to be sealed here, but the same query pointed out that this class has > no public or protected constructor (as well as no sub-classes) and so can be made final > > CSR for review here https://bugs.openjdk.java.net/browse/JDK-8285978 Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8492 From asotona at openjdk.java.net Tue May 10 08:46:45 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 10 May 2022 08:46:45 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam I agree with the priority to keep java.base and java.desktop clean from possibly lossy conversions, so the related issues should probably raise from P4 priority level. However this lint warning as a part of the javac is critical to confirm that the situations have been correctly addressed. If we want to avoid "blind" patching, we only two possible scenarios: 1. big homogenous patch including hundreds of fixed lines of code across many "moving-target" classes, together with lint warning implemented and enabled 2. javac lint patch (disabled for affected JDK modules build) goes first, so each case can be resolved, reviewed and validated in individual patch >From complexity and cost perspective I prefer the second scenario. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Tue May 10 09:07:44 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 10 May 2022 09:07:44 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v2] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/47779ba5..6b3942b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From mvs at openjdk.java.net Tue May 10 11:02:45 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Tue, 10 May 2022 11:02:45 GMT Subject: RFR: 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox [v2] In-Reply-To: References: Message-ID: > This test verifies that showing a JPopupMenu shouldn't steal the focus out of current focused component.. > This fix moves an unstable closed test to open but updated to be more comprehensive in testing multiple Look and Feels and with some stabilisation improvements. The closed test had some dependencies with some proprietary libraries which are all removed here. > > Testing: > Tested using mach5 10 times per platform and got all Pass. Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: Review comment fixed: Removed finally block and added the call to disposeFrame() before the exception is thrown ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8426/files - new: https://git.openjdk.java.net/jdk/pull/8426/files/b22649d6..1c2230b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8426&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8426&range=00-01 Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8426/head:pull/8426 PR: https://git.openjdk.java.net/jdk/pull/8426 From mvs at openjdk.java.net Tue May 10 11:02:46 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Tue, 10 May 2022 11:02:46 GMT Subject: RFR: 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox [v2] In-Reply-To: References: Message-ID: <_sTQVz9_pyuIXXO3BC2lNaXp8VkaYLS54VQv69WxleE=.f26f8c2d-b997-42a4-831f-80a4b03b82b3@github.com> On Mon, 9 May 2022 18:08:55 GMT, Phil Race wrote: >> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comment fixed: Removed finally block and added the call to disposeFrame() before the exception is thrown > > test/jdk/javax/swing/JPopupMenu/JPopupMenuFocusStealTest.java line 104: > >> 102: SwingUtilities >> 103: .invokeAndWait(JPopupMenuFocusStealTest::disposeFrame); >> 104: } > > I know it'll work but similarly to another review (https://github.com/openjdk/jdk/pull/8477/files) > it seems to me that you can recode as > SwingUtilities.invokeAndWait( > () -> isFocusOwner.set(comboBox.isFocusOwner())); > SwingUtilities > .invokeAndWait(JPopupMenuFocusStealTest::disposeFrame); > if (isFocusOwner.get()) { > System.out.println("Test Passed for " + laf); > } else { > throw new RuntimeException("Test Failed for " + laf); > } > > and don't need the finally block Changed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8426 From dfuchs at openjdk.java.net Tue May 10 11:16:48 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 10 May 2022 11:16:48 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2] In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> >> if (clazz.isInstance(obj)) { >> >> Replacement is equivalent if it's known that `obj != null`. >> In JDK codebase there are many such places. >> >> I tried to measure performance via JMH >> >> Class integerClass = Integer.class; >> Class numberClass = Number.class; >> >> Object integerObject = 45666; >> Object doubleObject = 8777d; >> >> @Benchmark >> public boolean integerInteger_isInstance() { >> return integerClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean integerInteger_isAssignableFrom() { >> return integerClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public boolean integerDouble_isInstance() { >> return integerClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean integerDouble_isAssignableFrom() { >> return integerClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberDouble_isInstance() { >> return numberClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean numberDouble_isAssignableFrom() { >> return numberClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberInteger_isInstance() { >> return numberClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean numberInteger_isAssignableFrom() { >> return numberClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public void numberIntegerDouble_isInstance(Blackhole bh) { >> bh.consume(numberClass.isInstance(integerObject)); >> bh.consume(numberClass.isInstance(doubleObject)); >> } >> >> @Benchmark >> public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { >> bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); >> bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); >> } >> >> `isInstance` is a bit faster than `isAssignableFrom` >> >> Benchmark Mode Cnt Score Error Units >> integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op >> integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op >> integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op >> numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op >> integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op >> integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op >> numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op >> numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op >> numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op >> numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable > apply suggestion to avoid second Method.invoke call src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230: > 228: List l = new ArrayList<>(); > 229: for (Class c : categoryMap.keySet()) { > 230: if (c.isInstance(provider)) { Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From aturbanov at openjdk.java.net Tue May 10 11:35:04 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 10 May 2022 11:35:04 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 11:10:50 GMT, Daniel Fuchs wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable >> apply suggestion to avoid second Method.invoke call > > src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230: > >> 228: List l = new ArrayList<>(); >> 229: for (Class c : categoryMap.keySet()) { >> 230: if (c.isInstance(provider)) { > > Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE. No. This method is called from 3 places, and there 3 null checks before the method call. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From dfuchs at openjdk.java.net Tue May 10 11:43:55 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 10 May 2022 11:43:55 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 11:31:16 GMT, Andrey Turbanov wrote: >> src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230: >> >>> 228: List l = new ArrayList<>(); >>> 229: for (Class c : categoryMap.keySet()) { >>> 230: if (c.isInstance(provider)) { >> >> Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE. > > No. This method is called from 3 places, and there 3 null checks before the method call. Thanks for double checking! LGTM then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From aivanov at openjdk.java.net Tue May 10 14:12:06 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 10 May 2022 14:12:06 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v14] In-Reply-To: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> References: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> Message-ID: On Mon, 9 May 2022 22:04:38 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > made suggested changes Overall, it looks very good. The test catches bad rendering of both horizontal and vertical border. It passes successfully with the fix. Except for the minor notes I left, I have one more suggestion: run the test for all the scales / images that we have rather than failing the test at a encountered first error. It'll give the an overview of all border rendering. On the other hand, we don't expect the test to fail in the future? One more thing: the test now uses `EtchedBorder` only, shall it be moved to `test/jdk/java/awt/EtchedBorder`? And adding the word _Scaled_ to the title ? `ScaledEtchedBorderTest` ? would clarify the purpose of the test. What do you think? src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 177: > 175: : getShadowColor(c), w, h, stkWidth); > 176: paintBorderRect(g, (etchType == LOWERED) ? getShadowColor(c) > 177: : getHighlightColor(c), w, h, stkWidth); I suggest aligning the colon `:` with `?` and wrapping following parameters: Suggestion: paintBorderShadow(g, (etchType == LOWERED) ? getHighlightColor(c) : getShadowColor(c), w, h, stkWidth); paintBorderRect(g, (etchType == LOWERED) ? getShadowColor(c) : getHighlightColor(c), w, h, stkWidth); I think it's clearer this way. Alternatively, leave the ternary operator on the first line and wrap the following parameters to the second line. Should `paintBorderRect` be `paintBorderHighlight`? The first method is `paintBorderShadow`. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 95: > 93: BufferedImage img = images.get(i); > 94: double scaling = scales[i]; > 95: Does it make sense to print the current scale being tested? System.out.printf("Scaling: %.2f\n", scaling); It may be especially useful for error message which don't include the current scale. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 112: > 110: boolean checkHighlight = false; > 111: for (int i = 0; i < img.getWidth(); i++) { > 112: int color = img.getRGB(i,y); Suggestion: for (int x = 0; x < img.getWidth(); x++) { int color = img.getRGB(x, y); The loop is for `x` coordinate. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 124: > 122: thickness++; > 123: } else if (color == highlight.getRGB()) { > 124: verifyThickness(y, thickness, scaling, "Horizontal"); Here, the IDE warns `y` probably shouldn't be passed as `x` parameter. In fact, `verifyThickness` doesn't use it at the moment. To make the error message more informative, you may pass both `x` and `y` and also include the real vs expected thickness. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 157: > 155: boolean checkHighlight = false; > 156: for (int i = 0; i < img.getHeight(); i++) { > 157: int color = img.getRGB(x,i); Suggestion: for (int y = 0; y < img.getHeight(); y++) { int color = img.getRGB(x, y); Here we're changing `y` coordinate. test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 248: > 246: } > 247: > 248: private static void setLookAndFeel(UIManager.LookAndFeelInfo laf) { Please remove this unused method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Tue May 10 15:25:53 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 10 May 2022 15:25:53 GMT Subject: RFR: 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 11:02:45 GMT, Manukumar V S wrote: >> This test verifies that showing a JPopupMenu shouldn't steal the focus out of current focused component.. >> This fix moves an unstable closed test to open but updated to be more comprehensive in testing multiple Look and Feels and with some stabilisation improvements. The closed test had some dependencies with some proprietary libraries which are all removed here. >> >> Testing: >> Tested using mach5 10 times per platform and got all Pass. > > Manukumar V S has updated the pull request incrementally with one additional commit since the last revision: > > Review comment fixed: Removed finally block and added the call to disposeFrame() before the exception is thrown Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8426 From aivanov at openjdk.java.net Tue May 10 16:01:55 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 10 May 2022 16:01:55 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v14] In-Reply-To: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> References: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> Message-ID: On Mon, 9 May 2022 22:04:38 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > made suggested changes test/jdk/java/awt/TitledBorder/TitledBorderTest.java line 36: > 34: import java.io.IOException; > 35: import java.util.ArrayList; > 36: import java.util.Arrays; `java.util.Arrays` is not used any more. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From kizune at openjdk.java.net Tue May 10 17:41:17 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 10 May 2022 17:41:17 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes Message-ID: Moving cache invalidation from the clearCache method to a createRowWithIndex method eliminating race condition that causes crash. Now clearCache just notifies that cache is invalid and should be regenerated next time it is being accessed. ------------- Commit messages: - 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes Changes: https://git.openjdk.java.net/jdk/pull/8636/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8636&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286266 Stats: 19 lines in 2 files changed: 10 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8636.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8636/head:pull/8636 PR: https://git.openjdk.java.net/jdk/pull/8636 From aivanov at openjdk.java.net Tue May 10 17:46:52 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 10 May 2022 17:46:52 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Sun, 8 May 2022 19:36:33 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > formatting changes Unfortunately, the icon is distorted on Windows 11. When I tested on Windows 10, it updates correctly most of the time, but rarely the icon becomes distorted. When the icon is distorted, enabling taskbar auto-hide and disabling it repaints the icon correctly; this works both on Windows 10 and 11. ![Tray Icon 125% -> 150%](https://user-images.githubusercontent.com/70774172/167689269-2d41884a-a5cd-4cb5-b3b5-21b02f0f46b5.png) I got the above image on Windows 10 after switching from 125% to 150%. The icon should display 24 at 150%, one can see the number with some paint artefacts. I don't understand why it happens this way. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Tue May 10 18:05:40 2022 From: duke at openjdk.java.net (DamonGuy) Date: Tue, 10 May 2022 18:05:40 GMT Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted padding [v3] In-Reply-To: References: Message-ID: <70UGhVDGp1XaQSNi1WDl__-hy4PcNL3OIctvB_f8wbo=.b0b95189-e85d-4bd2-bcbd-868d38191fbe@github.com> On Tue, 10 May 2022 06:29:47 GMT, Prasanta Sadhukhan wrote: >> DamonGuy has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test summary. Added check for JButton. > > test/jdk/javax/swing/JButton/HtmlButtonImageTest/HtmlButtonImageTest.java line 116: > >> 114: ImageIO.write(image, "png", >> 115: new File(testDir + "/fail_image.png")); >> 116: throw new RuntimeException("HTML image not centered in button"); > > overall looks ok. Only thing is during failure, it does not show for which L&F the test is failing since you are iterating for all L&Fs. Sure, this can be changed. I can instead iterate through all L&F's and track all failing L&F's in a buffer to be displayed in the runtime exception in the end. How should the images be handled? Should I just generate X images where X is the number of failed L&F's? ------------- PR: https://git.openjdk.java.net/jdk/pull/8407 From duke at openjdk.java.net Tue May 10 19:03:23 2022 From: duke at openjdk.java.net (DamonGuy) Date: Tue, 10 May 2022 19:03:23 GMT Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted padding [v4] In-Reply-To: References: Message-ID: > The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text. > > The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device. DamonGuy has updated the pull request incrementally with one additional commit since the last revision: Added string buffer. Separated fail images. Changed exception to throw at the end of test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8407/files - new: https://git.openjdk.java.net/jdk/pull/8407/files/cc5091fa..82d9ca27 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8407&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8407&range=02-03 Stats: 18 lines in 1 file changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8407.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8407/head:pull/8407 PR: https://git.openjdk.java.net/jdk/pull/8407 From duke at openjdk.java.net Tue May 10 19:27:50 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 10 May 2022 19:27:50 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> References: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> Message-ID: On Fri, 6 May 2022 17:56:44 GMT, Alan Bateman wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777: > >> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) { >> 776: printStackWhenAccessFails = GetBooleanAction. >> 777: privilegedGetProperty("sun.reflect.debugModuleAccessChecks"); > > Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false. You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From achung at openjdk.java.net Tue May 10 19:52:41 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Tue, 10 May 2022 19:52:41 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: Message-ID: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: renamed test, renamed some methods, updated error messages, updated test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/b84cf51a..e32e6c08 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=13-14 Stats: 513 lines in 3 files changed: 250 ins; 259 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From kizune at openjdk.java.net Tue May 10 20:21:56 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 10 May 2022 20:21:56 GMT Subject: RFR: 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows In-Reply-To: References: Message-ID: <56uhZFWkFV7B3jgzB_dly3_GIXXWhVPpQY2SqF8kmF0=.4a5cc629-1768-4997-9c8a-0de5011cb751@github.com> On Thu, 28 Apr 2022 23:26:30 GMT, Sergey Bylokhov wrote: > It is a bug, it prevents the creation of the custom window decorations which behave like the native ones This is exactly the way native applications are working so should we treat this as a bug is questionable. Many applications - namely games and video editing software - using this feature on Windows to create a borderless window that covers the entire screen basically engaging in a "soft full screen mode" where no additional virtual screen is created. So if anything this feature would require some way of controlling of should we honor the native Windows behavior or not and i see it as that - a new feature that might be never implemented. Said that - this test is not valid because it does not test the behavior of the window - it tests the correct calculation of screen insets by assuming that window behaves to the set of properties in a certain way which it does not. So i am going to fix the test so it works with a current state of the Frame. ------------- PR: https://git.openjdk.java.net/jdk/pull/8314 From duke at openjdk.java.net Tue May 10 23:17:36 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Tue, 10 May 2022 23:17:36 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v4] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: test case exit issue fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/165a20b2..2de3ef48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=02-03 Stats: 61 lines in 2 files changed: 25 ins; 27 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Tue May 10 23:17:37 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Tue, 10 May 2022 23:17:37 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Sun, 8 May 2022 19:36:33 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > formatting changes Changes related to the test case and the test case exit issue is updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Tue May 10 23:28:48 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Tue, 10 May 2022 23:28:48 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 17:43:51 GMT, Alexey Ivanov wrote: > Unfortunately, the icon is distorted on Windows 11. When I tested on Windows 10, it updates correctly most of the time, but rarely the icon becomes distorted. When the icon is distorted, enabling taskbar auto-hide and disabling it repaints the icon correctly; this works both on Windows 10 and 11. > > ![Tray Icon 125% -> 150%](https://user-images.githubusercontent.com/70774172/167689269-2d41884a-a5cd-4cb5-b3b5-21b02f0f46b5.png) I got the above image on Windows 10 after switching from 125% to 150%. The icon should display 24 at 150%, one can see the number with some paint artefacts. > > I don't understand why it happens this way. @aivanov-jdk Thank you for testing it on Win 10 & 11. I'm unable to replicate this issue on windows 10. But as you mentioned earlier, I was able to see similar icon distortion when using the DisplayChangedListener approach. I'll check what might be causing the issue on Win 11 and if it is replicable on Win 10 for any particular scenario. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Wed May 11 03:16:43 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 03:16:43 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 23:25:04 GMT, Harshitha Onkar wrote: > > Unfortunately, the icon is distorted on Windows 11. When I tested on Windows 10, it updates correctly most of the time, but rarely the icon becomes distorted. When the icon is distorted, enabling taskbar auto-hide and disabling it repaints the icon correctly; this works both on Windows 10 and 11. > > ![Tray Icon 125% -> 150%](https://user-images.githubusercontent.com/70774172/167689269-2d41884a-a5cd-4cb5-b3b5-21b02f0f46b5.png) I got the above image on Windows 10 after switching from 125% to 150%. The icon should display 24 at 150%, one can see the number with some paint artefacts. > > I don't understand why it happens this way. > > @aivanov-jdk Thank you for testing it on Win 10 & 11. I'm unable to replicate this issue on windows 10. But as you mentioned earlier, I was able to see similar icon distortion when using the DisplayChangedListener approach. I'll check what might be causing the issue on Win 11 and if it is replicable on Win 10 for any particular scenario. @aivanov-jdk were both windows 10 and windows 11 using the same pipeline ? (meaning GDI or D3D). Otherwise on our side I'd expect all the same code path .. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From psadhukhan at openjdk.java.net Wed May 11 03:59:49 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 11 May 2022 03:59:49 GMT Subject: RFR: JDK-8282772: JButton text set as HTML content has unwanted padding [v4] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 19:03:23 GMT, DamonGuy wrote: >> The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text. >> >> The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device. > > DamonGuy has updated the pull request incrementally with one additional commit since the last revision: > > Added string buffer. Separated fail images. Changed exception to throw at the end of test. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8407 From ysuenaga at openjdk.java.net Wed May 11 06:03:58 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 06:03:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings Message-ID: I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. As you can see, the warnings spreads several areas. Let me know if I should separate them by area. * -Wstringop-overflow * src/hotspot/share/oops/array.hpp * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: ------------- Commit messages: - 8286562: GCC 12 reports some compiler warnings Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286562 Stats: 63 lines in 13 files changed: 51 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From jrose at openjdk.java.net Wed May 11 06:28:37 2022 From: jrose at openjdk.java.net (John R Rose) Date: Wed, 11 May 2022 06:28:37 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v2] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Tue, 10 May 2022 09:07:44 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > 8244681: Add a warning for possibly lossy conversion in compound assignments > recommended correction of the warning wording > fixed typo in test method name src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 210: > 208: > 209: javac.opt.Xlint.desc.lossy-conversions=\ > 210: Warn about compiler possible lossy conversions. I like this warning. But the documentation doesn't even parse as English. I suggest this, as more grammatical and precise: > Warn about possible lossy conversions in compound assignments ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Wed May 11 07:45:39 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 07:45:39 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/6b3942b8..f0729396 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From ysuenaga at openjdk.java.net Wed May 11 08:40:21 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 08:40:21 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Avoid pragma error in before GCC 12 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/8154f6ea..7f155256 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From asemenov at openjdk.java.net Wed May 11 10:01:48 2022 From: asemenov at openjdk.java.net (Artem Semenov) Date: Wed, 11 May 2022 10:01:48 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes In-Reply-To: References: Message-ID: On Tue, 10 May 2022 17:34:34 GMT, Alexander Zuev wrote: > Moving cache invalidation from the clearCache method to a createRowWithIndex method > eliminating race condition that causes crash. Now clearCache just notifies that cache > is invalid and should be regenerated next time it is being accessed. src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 141: > 139: [rowCache removeObjectForKey:key]; > 140: } > 141: cacheValid = YES; It seems to me that here it is necessary to release the cache. [rowCache release]; rowCache = nil; ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From asemenov at openjdk.java.net Wed May 11 10:07:45 2022 From: asemenov at openjdk.java.net (Artem Semenov) Date: Wed, 11 May 2022 10:07:45 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes In-Reply-To: References: Message-ID: On Tue, 10 May 2022 17:34:34 GMT, Alexander Zuev wrote: > Moving cache invalidation from the clearCache method to a createRowWithIndex method > eliminating race condition that causes crash. Now clearCache just notifies that cache > is invalid and should be regenerated next time it is being accessed. If possible, please add this case to the regression test test/jdk/java/awt/a11y/AccessibleJTableTest.java ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From ihse at openjdk.java.net Wed May 11 11:50:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 11:50:50 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes. While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From mvs at openjdk.java.net Wed May 11 11:51:45 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Wed, 11 May 2022 11:51:45 GMT Subject: Integrated: 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 11:22:48 GMT, Manukumar V S wrote: > This test verifies that showing a JPopupMenu shouldn't steal the focus out of current focused component.. > This fix moves an unstable closed test to open but updated to be more comprehensive in testing multiple Look and Feels and with some stabilisation improvements. The closed test had some dependencies with some proprietary libraries which are all removed here. > > Testing: > Tested using mach5 10 times per platform and got all Pass. This pull request has now been integrated. Changeset: 7612bba0 Author: Manukumar V S Committer: Abdul Kolarkunnu URL: https://git.openjdk.java.net/jdk/commit/7612bba0f1ae63b2c762eb103544dc43d4e8304f Stats: 179 lines in 1 file changed: 179 ins; 0 del; 0 mod 8285698: Create a test to check the focus stealing of JPopupMenu from JComboBox Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8426 From ysuenaga at openjdk.java.net Wed May 11 12:38:58 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 12:38:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> References: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> Message-ID: On Wed, 11 May 2022 11:48:00 GMT, Magnus Ihse Bursie wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes. > > While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... Thanks @magicus for your review! > While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... Agree, so I fixed bugs which were found out by compiler warnings in this PR - they are in libjli. I think we can ignore the others because they are already checked in other methods (e.g. `assert`), or due to structure of `Array` class which has payload in `_data[1]` (and it is also checked in `assert`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Wed May 11 12:43:01 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 12:43:01 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: <2NpNw3Q9tkAShuydzhDKopMf3mLCyAwmSFoWzC665pI=.dbe3b460-d267-42ab-b08d-553bf133b796@github.com> On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 It is better to add pragma to `Array::at_put()` in src/hotspot/share/oops/array.hpp , but I couldn't suppress warnings. So I added pragmas to its caller - bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp . ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From asemenov at openjdk.java.net Wed May 11 12:49:34 2022 From: asemenov at openjdk.java.net (Artem Semenov) Date: Wed, 11 May 2022 12:49:34 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: > A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index. > > @forantar @azuev-java @mrserb please review. > > Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode". Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: We don't do @author tags in openjdk Not 2022 ? ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8578/files - new: https://git.openjdk.java.net/jdk/pull/8578/files/4a507b2b..4a9bc8e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8578&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8578&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8578/head:pull/8578 PR: https://git.openjdk.java.net/jdk/pull/8578 From asemenov at openjdk.java.net Wed May 11 12:49:35 2022 From: asemenov at openjdk.java.net (Artem Semenov) Date: Wed, 11 May 2022 12:49:35 GMT Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:12:26 GMT, Phil Race wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> We don't do @author tags in openjdk >> Not 2022 ? > > src/java.desktop/share/classes/javax/accessibility/AccessibleList.java line 27: > >> 25: * This interface provides list specific data. >> 26: * >> 27: * @author Artem Semenov > > We don't do @author tags in openjdk Done > test/jdk/java/awt/a11y/AccessibleListTest.java line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2021, JetBrains s.r.o.. All rights reserved. > > Not 2022 ? Done ------------- PR: https://git.openjdk.java.net/jdk/pull/8578 From alanb at openjdk.java.net Wed May 11 12:51:56 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 12:51:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; > 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 135: #pragma GCC diagnostic pop Can we just replace this code rather than putting pragmas here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ihse at openjdk.java.net Wed May 11 13:05:46 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 13:05:46 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > 8244681: Add a warning for possibly lossy conversion in compound assignments > recommended correction of the warning description Check updates on JDK-8286374 subtasks. make/modules/jdk.jfr/Java.gmk line 26: > 24: # > 25: > 26: DISABLED_WARNINGS_java += exports lossy-conversions Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix. (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.) ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8599 From egahlin at openjdk.java.net Wed May 11 13:05:46 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 11 May 2022 13:05:46 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > 8244681: Add a warning for possibly lossy conversion in compound assignments > recommended correction of the warning description Lossy conversion issues for jdk.jfr and jdk.management.jfr. have been fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From egahlin at openjdk.java.net Wed May 11 13:08:49 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 11 May 2022 13:08:49 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> On Wed, 11 May 2022 12:59:49 GMT, Magnus Ihse Bursie wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> 8244681: Add a warning for possibly lossy conversion in compound assignments >> recommended correction of the warning description > > make/modules/jdk.jfr/Java.gmk line 26: > >> 24: # >> 25: >> 26: DISABLED_WARNINGS_java += exports lossy-conversions > > Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. > > In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix. > > (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.) I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From aivanov at openjdk.java.net Wed May 11 13:11:49 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 11 May 2022 13:11:49 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 17:43:51 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting changes > > Unfortunately, the icon is distorted on Windows 11. When I tested on Windows 10, it updates correctly most of the time, but rarely the icon becomes distorted. When the icon is distorted, enabling taskbar auto-hide and disabling it repaints the icon correctly; this works both on Windows 10 and 11. > > ![Tray Icon 125% -> 150%](https://user-images.githubusercontent.com/70774172/167689269-2d41884a-a5cd-4cb5-b3b5-21b02f0f46b5.png) > I got the above image on Windows 10 after switching from 125% to 150%. The icon should display 24 at 150%, one can see the number with some paint artefacts. > > I don't understand why it happens this way. > @aivanov-jdk were both windows 10 and windows 11 using the same pipeline ? (meaning GDI or D3D). Otherwise on our side I'd expect all the same code path .. Good question. The output from `WindowsFlags` is the same on both machines: WindowsFlags (Java): d3dEnabled: true d3dSet: false oglEnabled: false oglVerbose: false gdiBlitEnabled: true offscreenSharingEnabled: false Setting `-Dsun.java2d.d3d=True` produces Direct3D pipeline enabled on screen 0 in both cases. Disabling Direct3D with `-Dsun.java2d.d3d=false` changes nothing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From ihse at openjdk.java.net Wed May 11 13:13:43 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 13:13:43 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> Message-ID: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin wrote: >> make/modules/jdk.jfr/Java.gmk line 26: >> >>> 24: # >>> 25: >>> 26: DISABLED_WARNINGS_java += exports lossy-conversions >> >> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. >> >> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix. >> >> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.) > > I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement. That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From ysuenaga at openjdk.java.net Wed May 11 13:24:38 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 13:24:38 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:48:38 GMT, Alan Bateman wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; >> 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 135: #pragma GCC diagnostic pop > > Can we just replace this code rather than putting pragmas here? I tried several patterns, but I couldn't find out a solution other than pragmas. Do you have any ideas? For example: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) < sizeof(name)) { JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); } else { return 0; } Compiler warnings: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From asotona at openjdk.java.net Wed May 11 13:30:43 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 13:30:43 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: On Wed, 11 May 2022 13:10:10 GMT, Magnus Ihse Bursie wrote: >> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement. > > That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue. Thanks for quick reaction. I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From rriggs at openjdk.java.net Wed May 11 13:34:49 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 11 May 2022 13:34:49 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona wrote: >> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue. > > Thanks for quick reaction. > I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR. I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From kbarrett at openjdk.java.net Wed May 11 14:01:52 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 11 May 2022 14:01:52 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 Changes requested by kbarrett (Reviewer). make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: > 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing > 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ > 462: maybe-uninitialized class-memaccess unused-result extra use-after-free Globally disabling use-after-free warnings for this package seems really questionable. If these are problems in the code, just suppressing the warning and leaving the problems to bite us seems like a bad idea. And the problems ought to be reported upstream to the HarfBuzz folks. src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51: > 49: > 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \ > 51: PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") Are the reported problems with format/stringop-overflow real? Or are they false positives? If they are real then I'm not going to approve ignoring them, unless there is some urgent reason and there are followup bug reports for fixing them. src/java.base/share/native/libjli/java.c line 1629: > 1627: const char *arg = jargv[i]; > 1628: if (arg[0] == '-' && arg[1] == 'J') { > 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); Wow! src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; > 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 135: #pragma GCC diagnostic pop Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated? I think that kind of check is supposed to make gcc's truncation checker happy. src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193: > 191: #if defined(__GNUC__) && __GNUC__ >= 12 > 192: #pragma GCC diagnostic pop > 193: #endif Rather than all this warning suppression cruft and the comment explaining why it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few lines earlier, before the realloc. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Wed May 11 14:31:02 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 11 May 2022 14:31:02 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:56:44 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/share/native/libjli/java.c line 1629: > >> 1627: const char *arg = jargv[i]; >> 1628: if (arg[0] == '-' && arg[1] == 'J') { >> 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); > > Wow! I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string? If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From asotona at openjdk.java.net Wed May 11 13:41:30 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 13:41:30 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v4] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <3RgMbsaSwgdBXE2qlIwjVI680aN7Ovi6OOfu9eeNtJo=.a76eff60-8652-40ce-ae40-20f9095b1b93@github.com> > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments jdk.internal.le make patch to disable warnings - 8244681: Add a warning for possibly lossy conversion in compound assignments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/f0729396..a59dfa4f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02-03 Stats: 9179 lines in 255 files changed: 5253 ins; 2422 del; 1504 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Wed May 11 13:41:30 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 13:41:30 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: <6EkEbNxPc3RKNGprHlBhqM574oY7iPI9z3PpR91IMok=.9019963f-8085-49a8-951f-f8a2b2137fb0@github.com> On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs wrote: >> Thanks for quick reaction. >> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR. > > I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time. Feel free to go ahead with the java.base PR as this one still needs CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Wed May 11 14:45:12 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 11 May 2022 14:45:12 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v5] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/a59dfa4f..32282515 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From mkartashev at openjdk.java.net Wed May 11 16:03:54 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Wed, 11 May 2022 16:03:54 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken wrote: >> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information : >> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt >> Macros for Conditional Declarations >> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows." >> >> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at java_props_md.c (so targeting older Windows versions at other places is most likely not useful). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust API level to Windows 8 for security.cpp and do some cleanup This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From kizune at openjdk.java.net Wed May 11 16:24:00 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 11 May 2022 16:24:00 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes In-Reply-To: References: Message-ID: On Wed, 11 May 2022 09:56:46 GMT, Artem Semenov wrote: > It seems to me that here it is necessary to release the cache. I am not so sure. Why would we do that? I mean - we removed all the records from the cache and even if we would release it we would have to immediately re-create it otherwise the very next operation will crash since we will be trying to call objectForKey selector upon nil. So what is the point in releasing the now empty dictionary? ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From asemenov at openjdk.java.net Wed May 11 16:39:50 2022 From: asemenov at openjdk.java.net (Artem Semenov) Date: Wed, 11 May 2022 16:39:50 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:20:00 GMT, Alexander Zuev wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m line 141: >> >>> 139: [rowCache removeObjectForKey:key]; >>> 140: } >>> 141: cacheValid = YES; >> >> It seems to me that here it is necessary to release the cache. >> >> [rowCache release]; >> rowCache = nil; > >> It seems to me that here it is necessary to release the cache. > > I am not so sure. Why would we do that? I mean - we removed all the records from the cache and even if we would release it we would have to immediately re-create it otherwise the very next operation will crash since we will be trying to call objectForKey selector upon nil. So what is the point in releasing the now empty dictionary? Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From andrew at openjdk.java.net Wed May 11 16:57:50 2022 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Wed, 11 May 2022 16:57:50 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset [v3] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 19:45:49 GMT, Zhengyu Gu wrote: >> Please review this small patch that releases temporary charsets to avoid memory leak. >> >> Test: >> >> - [x] jdk_2d > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup at early return Looks good to me. Hopefully we caught everything. ------------- Marked as reviewed by andrew (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8187 From achung at openjdk.java.net Wed May 11 17:01:55 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 11 May 2022 17:01:55 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v8] In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 23:35:10 GMT, lukeu wrote: >> Made a small change with the bottom line to match the left line of the border > >> Made a small change with the bottom line to match the left line of the border > > Great, that looks like it'll fix it so I won't test again, I'll defer to the others now for the code review. (I'd be happy to chip in there too, but I'm not sure if "random guy on github" is qualified/authorized to?) @lukeu @prrace I've updated the fix and test, can you guys take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From chen.j.patrick at gmail.com Wed May 11 14:08:28 2022 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Wed, 11 May 2022 16:08:28 +0200 Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v3] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com> <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com> Message-ID: I checked you pr look good to me @Roger Le mer. 11 mai 2022 ? 15:35, Roger Riggs a ?crit : > On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona wrote: > > >> That's good to know. I think the tricky part is mostly about keeping > track of all these disabled warnings, so they are not kept around longer > than necessary. And that needs coordination with all the subtasks of the > umbrella issue. > > > > Thanks for quick reaction. > > I'll keep my eyes on this race of patches and update this pull request > accordingly or create a new PR. > > I put out a PR for java.base, but thought I'd wait until the javac fixe > were pushed before integrating and would re-enable the warnings at the same > time. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8599 > From aivanov at openjdk.java.net Wed May 11 18:11:07 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 11 May 2022 18:11:07 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v11] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 06:26:29 GMT, Prasanta Sadhukhan wrote: >> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. >> This is because when the table is scrolled down to last page, the bounds.y becomes -ve >> [x=0,y=-15260,width=968,height=16000] >> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] >> but subsequent pages clip >> [[x=0,y=1296,width=968,height=1296], >> [x=0,y=2592,width=968,height=1296], >> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed >> >> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI >> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 >> >> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test updated test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 63: > 61: + " Test cannot continue."); > 62: PassFailJFrame.forcePass(); > 63: } This could be the first statements in main, as you don't even need to show the instructions in this case. test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 69: > 67: }); > 68: > 69: Thread.sleep(1000); The delay is not required here. test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 80: > 78: try { > 79: if (!table.print()) { > 80: throw new RuntimeException("Printing cancelled"); When run outside of jtreg, this exception doesn't stop the test. In jtreg, it does. So it works as expected when run in jtreg but it could be confusing if run as a stand-alone test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From prr at openjdk.java.net Wed May 11 18:42:21 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 18:42:21 GMT Subject: RFR: 8286447: [Linux] AWT should start in Headless mode if headful AWT library not installed Message-ID: As per the bug report and the CSR (please review that too), this makes AWT load in headless mode if only headless libraries are installed. It passes all our normal testing which at least should show that this doesn't regress anything. I had to manually remove libawt_xawt.so to verify that it will do as expected in such a case, and it would not be easy to create a test for that. CSR : https://bugs.openjdk.java.net/browse/JDK-8286598 ------------- Commit messages: - 8286447 - 8286447 Changes: https://git.openjdk.java.net/jdk/pull/8659/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8659&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286447 Stats: 35 lines in 1 file changed: 30 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8659.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8659/head:pull/8659 PR: https://git.openjdk.java.net/jdk/pull/8659 From prr at openjdk.java.net Wed May 11 18:48:15 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 18:48:15 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size Message-ID: This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 It is similar in the idea from what we converged on towards the end there but 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. @toshiona you very likely want to take a look at it. ------------- Commit messages: - 8285308 Changes: https://git.openjdk.java.net/jdk/pull/8662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285308 Stats: 27 lines in 1 file changed: 21 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8662/head:pull/8662 PR: https://git.openjdk.java.net/jdk/pull/8662 From prr at openjdk.java.net Wed May 11 19:00:56 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 19:00:56 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:08:11 GMT, Alexey Ivanov wrote: >>Disabling Direct3D with -Dsun.java2d.d3d=false changes nothing. That rules out a pipeline issue so I've no idea. Fortunately Windows 11 still has lower adoption than Windows XP usage :-) That's a real stat btw. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Wed May 11 19:14:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 19:14:03 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:35:00 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: > >> 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing >> 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ >> 462: maybe-uninitialized class-memaccess unused-result extra use-after-free > > Globally disabling use-after-free warnings for this package seems really > questionable. If these are problems in the code, just suppressing the warning > and leaving the problems to bite us seems like a bad idea. And the problems > ought to be reported upstream to the HarfBuzz folks. I don't understand what the actual warning is getting at .. can anyone explain it ? FWIW the code is still the same in upstream harfbuzz https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From asemenyuk at openjdk.java.net Wed May 11 19:27:47 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 11 May 2022 19:27:47 GMT Subject: RFR: 8286447: [Linux] AWT should start in Headless mode if headful AWT library not installed In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:27:38 GMT, Phil Race wrote: > As per the bug report and the CSR (please review that too), this makes AWT load in headless mode > if only headless libraries are installed. > > It passes all our normal testing which at least should show that this doesn't regress anything. > I had to manually remove libawt_xawt.so to verify that it will do as expected in such a case, > and it would not be easy to create a test for that. > > CSR : https://bugs.openjdk.java.net/browse/JDK-8286598 Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8659 From kcr at openjdk.java.net Wed May 11 19:27:47 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 11 May 2022 19:27:47 GMT Subject: RFR: 8286447: [Linux] AWT should start in Headless mode if headful AWT library not installed In-Reply-To: References: Message-ID: <844Zc8jg0YjPAkof048bTW_coO-nL8lQ68SLQ94FJXY=.abe93f17-fdd5-49f4-9ce6-672e0603f469@github.com> On Wed, 11 May 2022 17:27:38 GMT, Phil Race wrote: > As per the bug report and the CSR (please review that too), this makes AWT load in headless mode > if only headless libraries are installed. > > It passes all our normal testing which at least should show that this doesn't regress anything. > I had to manually remove libawt_xawt.so to verify that it will do as expected in such a case, > and it would not be easy to create a test for that. > > CSR : https://bugs.openjdk.java.net/browse/JDK-8286598 Looks good. I verified that it does what I would expect. src/java.desktop/unix/classes/sun/awt/PlatformGraphicsInfo.java line 70: > 68: * to try headful and then unwind that and then retry as headless. > 69: */ > 70: final String[] libDirs = System.getProperty("sun.boot.library.path", "").split(":"); Does reading this property also need to be in a `doPrivileged`? ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/8659 From naoto at openjdk.java.net Wed May 11 20:43:58 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 11 May 2022 20:43:58 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size In-Reply-To: References: Message-ID: On Wed, 11 May 2022 18:25:09 GMT, Phil Race wrote: > This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 > It is similar in the idea from what we converged on towards the end there but > 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) > 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? > 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. > > I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. > > @toshiona you very likely want to take a look at it. src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java line 267: > 265: case "ru" -> "RUSSIAN_CHARSET"; > 266: case "el" -> "GREEK_CHARSET"; > 267: case "iw" -> "HEBREW_CHARSET"; It would be safe to specify both old(iw)/new(he) language codes for Hebrew, as "he" is now returned for Hebrew by default (https://bugs.openjdk.java.net/browse/JDK-8263202) ------------- PR: https://git.openjdk.java.net/jdk/pull/8662 From prr at openjdk.java.net Wed May 11 20:58:37 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 20:58:37 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: > This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 > It is similar in the idea from what we converged on towards the end there but > 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) > 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? > 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. > > I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. > > @toshiona you very likely want to take a look at it. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8285308 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8662/files - new: https://git.openjdk.java.net/jdk/pull/8662/files/49d5465e..79d246bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8662&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8662&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8662/head:pull/8662 PR: https://git.openjdk.java.net/jdk/pull/8662 From prr at openjdk.java.net Wed May 11 20:58:37 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 20:58:37 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:40:17 GMT, Naoto Sato wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8285308 > > src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java line 267: > >> 265: case "ru" -> "RUSSIAN_CHARSET"; >> 266: case "el" -> "GREEK_CHARSET"; >> 267: case "iw" -> "HEBREW_CHARSET"; > > It would be safe to specify both old(iw)/new(he) language codes for Hebrew, as "he" is now returned for Hebrew by default (https://bugs.openjdk.java.net/browse/JDK-8263202) ok - fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/8662 From duke at openjdk.java.net Wed May 11 23:32:38 2022 From: duke at openjdk.java.net (DamonGuy) Date: Wed, 11 May 2022 23:32:38 GMT Subject: Integrated: JDK-8282772: JButton text set as HTML content has unwanted padding In-Reply-To: References: Message-ID: <6hJGYVMSIrNSu5aMyxdU8P0z7lSB4lM17_1cjI4EbdM=.d35731f1-44b0-4254-97fb-4b19f6cde99d@github.com> On Tue, 26 Apr 2022 19:42:05 GMT, DamonGuy wrote: > The insets for buttons were incorrect for L&Fs except for Aqua when the text is set to HTML. This was fixed in Aqua by adding a conditional to check for the BasicHTML property key in the button component. This same logic can be used to fix Metal & Motif L&Fs in BasicButtonUI, but Nimbus is not fixed by this. Nimbus gets its default values from a skin.laf file, and when the defaults here are set to have left & right insets to 0 for ButtonUI, the issue is fixed. I also tested for non-HTML text after the changes, and the changes do not affect normal text. > > The HtmlButtonImageTest has been changed to cycle through all L&Fs available on a device. This pull request has now been integrated. Changeset: ccbe8faa Author: Damon Nguyen Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/ccbe8faa00b85a71ba84115c3321e20b661213c5 Stats: 118 lines in 3 files changed: 82 ins; 7 del; 29 mod 8282772: JButton text set as HTML content has unwanted padding Reviewed-by: prr, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/8407 From duke at openjdk.java.net Wed May 11 23:38:02 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Wed, 11 May 2022 23:38:02 GMT Subject: Integrated: 8285867 : Convert applet manual tests SelectionVisible.java to Frame and automate In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 22:39:28 GMT, lawrence.andrews wrote: > 1) Removed Applet dependent code and used Frame as top level. > 2) Automated the manual test. > > @shurymury This pull request has now been integrated. Changeset: 44a60ce1 Author: lawrence.andrews Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/44a60ce1724dc3e39faf1d7a68de2e6376894534 Stats: 208 lines in 4 files changed: 67 ins; 117 del; 24 mod 8285867: Convert applet manual tests SelectionVisible.java to Frame and automate Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8477 From duke at openjdk.java.net Wed May 11 23:39:48 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Wed, 11 May 2022 23:39:48 GMT Subject: Integrated: 8285612 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 22:36:59 GMT, lawrence.andrews wrote: > 1) Removed yesno to eliminate parserException > 2) Added code to fit into manual framework so that timeout, pass & fail is handled. > 3) Added code to mark the test as pass if printer service is not available > 4) Added code to handle pressing or clicking of 'Cancel' button. > > @shurymury > @aivanov-jdk This pull request has now been integrated. Changeset: 57a76708 Author: lawrence.andrews Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/57a76708864c3fed5fc2543f6a8552f38670488c Stats: 168 lines in 1 file changed: 71 ins; 55 del; 42 mod 8285612: Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8391 From duke at openjdk.java.net Thu May 12 00:02:35 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 12 May 2022 00:02:35 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v5] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: trayicon update triggered on taskbar reload ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/2de3ef48..532868e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=03-04 Stats: 9 lines in 1 file changed: 2 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Thu May 12 00:02:35 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 12 May 2022 00:02:35 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v4] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 23:17:36 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test case exit issue fix I think the icon distortion observed on Win10 and 11 might be due to race condition between update triggered by WM_WINDOWPOSCHANGING and the re-addition of tray icons when taskbar is reloaded (occurs when DPI changes) Whenever DPI changes, the taskbar is reloaded and all the existing tray icons are re-added by `WmTaskbarCreated()` in `awt_TrayIcon.cpp`. Here is the link to the relevant doc: [Taskbar creation and reload](https://docs.microsoft.com/en-us/windows/win32/shell/taskbar#taskbar-creation-notification) **The reason for distortion:** When update to tray icons (creating new scaled icon and deleting the old one) is called on `WM_WINDOWPOSCHANGING`, it might create race condition - updating the tray icon and deleting the previous ones while the WmTaskbarCreated is trying to re-add the icons at the same time. To overcome the race condition, I have removed the call to **UpdateTrayIconHandler()** on WM_WINDOWPOSCHANGING and added it when taskbar gets reloaded and before `WmTaskbarCreated` is called. When tested on Win10, it works as well. @aivanov-jdk Can you please test on Win10 & 11 with the new fix and let me know if it works? ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From ysuenaga at openjdk.java.net Thu May 12 00:29:47 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 00:29:47 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 19:11:16 GMT, Phil Race wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: >> >>> 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing >>> 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ >>> 462: maybe-uninitialized class-memaccess unused-result extra use-after-free >> >> Globally disabling use-after-free warnings for this package seems really >> questionable. If these are problems in the code, just suppressing the warning >> and leaving the problems to bite us seems like a bad idea. And the problems >> ought to be reported upstream to the HarfBuzz folks. > > I don't understand what the actual warning is getting at .. can anyone explain it ? > > FWIW the code is still the same in upstream harfbuzz > https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc I've pasted a part of warning messages to description of this PR, all of messages are here: In function 'void trampoline_reference(hb_trampoline_closure_t*)', inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 00:38:34 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 00:38:34 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:35:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51: > >> 49: >> 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \ >> 51: PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") > > Are the reported problems with format/stringop-overflow real? Or are they > false positives? If they are real then I'm not going to approve ignoring them, > unless there is some urgent reason and there are followup bug reports for > fixing them. I think all of warnings in HotSpot are false-positives, so I added new pragmas to compilerWarnings.hpp, and use it in HotSpot code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:11:39 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:11:39 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:27:27 GMT, Kim Barrett wrote: >> src/java.base/share/native/libjli/java.c line 1629: >> >>> 1627: const char *arg = jargv[i]; >>> 1628: if (arg[0] == '-' && arg[1] == 'J') { >>> 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); >> >> Wow! > > I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string? If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate). `NULL` affects as a loop stopper in `ParseArguments()` as following: static jboolean ParseArguments(int *pargc, char ***pargv, int *pmode, char **pwhat, int *pret, const char *jrepath) { int argc = *pargc; char **argv = *pargv; int mode = LM_UNKNOWN; char *arg; *pret = 0; while ((arg = *argv) != 0 && *arg == '-') { But I'm not sure it is valid, I think it might be discussed as another issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:17:36 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:17:36 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v3] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use return value from JLI_Snprintf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/7f155256..8d608414 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=01-02 Stats: 11 lines in 1 file changed: 4 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:17:37 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:17:37 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:43:55 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; >> 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 135: #pragma GCC diagnostic pop > > Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated? I think that kind of check is supposed to make gcc's truncation checker happy. The warning has gone when using return value from `JLI_Snprintf()` in new commit! ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:27:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:27:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Calculate char offset before realloc() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/8d608414..b3afa3e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02-03 Stats: 18 lines in 1 file changed: 3 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:27:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:27:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:47:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193: > >> 191: #if defined(__GNUC__) && __GNUC__ >= 12 >> 192: #pragma GCC diagnostic pop >> 193: #endif > > Rather than all this warning suppression cruft and the comment explaining why > it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few > lines earlier, before the realloc. I did do that in new commit, and the warning has gone! ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:32:42 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:32:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Calculate char offset before realloc() Thanks for all to review this PR! I think we should separate this issue as following: * Suppress warnings * make/modules/java.desktop/lib/Awt2dLibraries.gmk * src/hotspot/share/classfile/bytecodeAssembler.cpp * src/hotspot/share/classfile/classFileParser.cpp * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp * src/hotspot/share/opto/memnode.cpp * src/hotspot/share/opto/type.cpp * src/hotspot/share/utilities/compilerWarnings.hpp * src/hotspot/share/utilities/compilerWarnings_gcc.hpp * src/java.base/unix/native/libjli/java_md_common.c * Bug fixes * src/java.base/share/native/libjli/java.c * src/java.base/share/native/libjli/parse_manifest.c * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From tnakamura at openjdk.java.net Thu May 12 01:50:40 2022 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Thu, 12 May 2022 01:50:40 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:58:37 GMT, Phil Race wrote: >> This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 >> It is similar in the idea from what we converged on towards the end there but >> 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) >> 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? >> 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. >> >> I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. >> >> @toshiona you very likely want to take a look at it. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285308 I agree with your fix. It works on my Japanese environment as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8662 From psadhukhan at openjdk.java.net Thu May 12 04:09:29 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 12 May 2022 04:09:29 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: References: Message-ID: > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8141/files - new: https://git.openjdk.java.net/jdk/pull/8141/files/863b5e4c..c7db6ed8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=10-11 Stats: 15 lines in 1 file changed: 6 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141 PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Thu May 12 04:09:31 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 12 May 2022 04:09:31 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v11] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 18:01:27 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test updated > > test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 63: > >> 61: + " Test cannot continue."); >> 62: PassFailJFrame.forcePass(); >> 63: } > > This could be the first statements in main, as you don't even need to show the instructions in this case. ok. done > test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 69: > >> 67: }); >> 68: >> 69: Thread.sleep(1000); > > The delay is not required here. ok > test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 80: > >> 78: try { >> 79: if (!table.print()) { >> 80: throw new RuntimeException("Printing cancelled"); > > When run outside of jtreg, this exception doesn't stop the test. In jtreg, it does. > > So it works as expected when run in jtreg but it could be confusing if run as a stand-alone test. I amnot sure if anyone will try to run it outside jtreg as it has dependancy on jtreg helper class PassFailJFrame but anyway I have tried to address the concern. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From dholmes at openjdk.java.net Thu May 12 04:28:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 04:28:43 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust API level to Windows 8 for security.cpp and do some cleanup > > This change seem to have made this group of declarations obsolete: > `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( > https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From duke at openjdk.java.net Thu May 12 04:49:53 2022 From: duke at openjdk.java.net (Tejesh R) Date: Thu, 12 May 2022 04:49:53 GMT Subject: Withdrawn: 8134640 ( Left Insets Margin Test ) moved to open repo from closed In-Reply-To: <5gw_QjIeWEr1uUcAzT0x-xcEnwJKWXGBlVJBSY9o1_0=.1e01015f-91d7-42c6-bb9f-68482c7ad55f@github.com> References: <5gw_QjIeWEr1uUcAzT0x-xcEnwJKWXGBlVJBSY9o1_0=.1e01015f-91d7-42c6-bb9f-68482c7ad55f@github.com> Message-ID: On Mon, 2 May 2022 11:31:17 GMT, Tejesh R wrote: > The Test had been updated to use all Supported Look and Feel in closed repo. The same has been moved to open repo. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8500 From duke at openjdk.java.net Thu May 12 07:25:22 2022 From: duke at openjdk.java.net (Tejesh R) Date: Thu, 12 May 2022 07:25:22 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v4] In-Reply-To: References: Message-ID: > In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Removed the test from open, updated in closed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8496/files - new: https://git.openjdk.java.net/jdk/pull/8496/files/143be931..b81138b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8496&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8496&range=02-03 Stats: 227 lines in 1 file changed: 0 ins; 227 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8496/head:pull/8496 PR: https://git.openjdk.java.net/jdk/pull/8496 From mbaesken at openjdk.java.net Thu May 12 07:31:50 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 12 May 2022 07:31:50 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev wrote: > This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. Hi Maxim, no plans from me, so feel free to do further cleanups. ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From psadhukhan at openjdk.java.net Thu May 12 08:56:58 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 12 May 2022 08:56:58 GMT Subject: Integrated: 8284888 : [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 09:37:10 GMT, Prasanta Sadhukhan wrote: > Test used to fail in specific CI macos M1 system owing to miniscule color difference > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > SInce we already have color-tolerance check present, there is no need of exact color value check. > Also, made the frame undecorated and remove unneeded library being built. > Several iterations of the test passed in the same system (where it used to fail 4/10) along with other platforms (link in JBS) This pull request has now been integrated. Changeset: ff17f496 Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/ff17f496f4bcd8f775eb1ba6d962e963428322d3 Stats: 36 lines in 2 files changed: 18 ins; 5 del; 13 mod 8284888: [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java failed with "NimbusLookAndFeel] : ERROR: icon and imageIcon not same." Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8380 From psadhukhan at openjdk.java.net Thu May 12 09:31:55 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 12 May 2022 09:31:55 GMT Subject: Integrated: 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java fails in macos12 In-Reply-To: References: Message-ID: On Wed, 4 May 2022 11:16:17 GMT, Prasanta Sadhukhan wrote: > 2 open tests were seen to be failing in macos12 which happen to have same root cause as > 8273506: java Robot API did the 'm' keypress and caused /awt/event/Ke.... > > With that fix being committed, testing on intended macos12 systems are not able to reproduce this failures so we can remove from Problemlist. CI jobs links are in JBS. This pull request has now been integrated. Changeset: be97b4bc Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/be97b4bc83d4d3b2edfe6d9157a8d5bc079bdade Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8278348: [macos12] javax/swing/JTree/4908142/bug4908142.java fails in macos12 Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8532 From mkartashev at openjdk.java.net Thu May 12 11:00:49 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 12 May 2022 11:00:49 GMT Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4] In-Reply-To: References: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com> Message-ID: On Thu, 12 May 2022 04:25:24 GMT, David Holmes wrote: >> This change seem to have made this group of declarations obsolete: >> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link]( >> https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself. > > @mkartashev all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced. @dholmes-ora @MBaesken Thank you! Filed [JDK-8286634](https://bugs.openjdk.java.net/browse/JDK-8286634). ------------- PR: https://git.openjdk.java.net/jdk/pull/8428 From ihse at openjdk.java.net Thu May 12 11:04:08 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 May 2022 11:04:08 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this issue as following: > > * Suppress warnings > * make/modules/java.desktop/lib/Awt2dLibraries.gmk > * src/hotspot/share/classfile/bytecodeAssembler.cpp > * src/hotspot/share/classfile/classFileParser.cpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > * src/hotspot/share/opto/memnode.cpp > * src/hotspot/share/opto/type.cpp > * src/hotspot/share/utilities/compilerWarnings.hpp > * src/hotspot/share/utilities/compilerWarnings_gcc.hpp > * src/java.base/unix/native/libjli/java_md_common.c > * Bug fixes > * src/java.base/share/native/libjli/java.c > * src/java.base/share/native/libjli/parse_manifest.c > * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c > > I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. > > I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. @YaSuenag From my PoV this sounds like a good suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From zgu at openjdk.java.net Thu May 12 12:27:07 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 12 May 2022 12:27:07 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:54:28 GMT, Andrew John Hughes wrote: > Looks good to me. Hopefully we caught everything. Thanks @gnu-andrew. ------------- PR: https://git.openjdk.java.net/jdk/pull/8187 From zgu at openjdk.java.net Thu May 12 12:27:09 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 12 May 2022 12:27:09 GMT Subject: RFR: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset [v3] In-Reply-To: <2e2kIVfQYeb4i_yl7ElW3znBL9B7krwe2cHqsCi-Bpg=.1f548044-f895-4ddc-8d2b-1dc05376baf0@github.com> References: <2e2kIVfQYeb4i_yl7ElW3znBL9B7krwe2cHqsCi-Bpg=.1f548044-f895-4ddc-8d2b-1dc05376baf0@github.com> Message-ID: On Mon, 9 May 2022 20:01:24 GMT, Phil Race wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup at early return > > Marked as reviewed by prr (Reviewer). Thanks @prrace for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8187 From zgu at openjdk.java.net Thu May 12 12:29:32 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 12 May 2022 12:29:32 GMT Subject: Integrated: 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 18:05:09 GMT, Zhengyu Gu wrote: > Please review this small patch that releases temporary charsets to avoid memory leak. > > Test: > > - [x] jdk_2d This pull request has now been integrated. Changeset: dea6e886 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/dea6e886af20457597dd02dacf1e80273a7165a7 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod 8284680: sun.font.FontConfigManager.getFontConfig() leaks charset Reviewed-by: prr, andrew ------------- PR: https://git.openjdk.java.net/jdk/pull/8187 From duke at openjdk.java.net Thu May 12 16:00:15 2022 From: duke at openjdk.java.net (Tejesh R) Date: Thu, 12 May 2022 16:00:15 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v4] In-Reply-To: <38Bs6S4PRd9AC7g3wteV25vbss5jidtgSCJ8uZd_7yk=.c8cb8a80-e1a0-4d84-aabf-542f0ce4d780@github.com> References: <38Bs6S4PRd9AC7g3wteV25vbss5jidtgSCJ8uZd_7yk=.c8cb8a80-e1a0-4d84-aabf-542f0ce4d780@github.com> Message-ID: On Mon, 9 May 2022 05:27:54 GMT, Prasanta Sadhukhan wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed the test from open, updated in closed > > src/java.desktop/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java line 199: > >> 197: // shared. >> 198: @SuppressWarnings("deprecation") >> 199: public String getAcceleratorString() { > > Although it is being placed in its super class so it can still be accessed > but am still not sure if you can remove this public method from this public class without notifying via @deprecated or @forRemoval tag I guess the deprecation was due to `getKeyModifiersText()`, which has been replaced with `getModifiersExText()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From kizune at openjdk.java.net Thu May 12 16:32:49 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 12 May 2022 16:32:49 GMT Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v3] In-Reply-To: <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com> References: <1MCuz4h2_IMc9oR2q-DP_O5xoiS_7j1cQ8DTHaQxDlU=.a5b07c51-39fa-4c39-aa2d-74643c22cf0f@github.com> Message-ID: On Wed, 6 Apr 2022 07:02:25 GMT, Srinivas Mandalika wrote: >> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690) >> >> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane). >> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with. >> >> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items. >> >> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar. >> This review is for migrating tests from a closed test suite to open. > > Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: > > - Review Comments Fixed: Swing Components on EDT, 80 chars lines > - Review Comments Fixed: Swing Components on EDT, 80 chars lines Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7753 From kbarrett at openjdk.java.net Thu May 12 18:31:49 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 12 May 2022 18:31:49 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this issue as following: > > * Suppress warnings > * make/modules/java.desktop/lib/Awt2dLibraries.gmk > * src/hotspot/share/classfile/bytecodeAssembler.cpp > * src/hotspot/share/classfile/classFileParser.cpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > * src/hotspot/share/opto/memnode.cpp > * src/hotspot/share/opto/type.cpp > * src/hotspot/share/utilities/compilerWarnings.hpp > * src/hotspot/share/utilities/compilerWarnings_gcc.hpp > * src/java.base/unix/native/libjli/java_md_common.c > * Bug fixes > * src/java.base/share/native/libjli/java.c > * src/java.base/share/native/libjli/parse_manifest.c > * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c > > I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. > > I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > @YaSuenag From my PoV this sounds like a good suggestion. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From aivanov at openjdk.java.net Thu May 12 19:02:41 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 12 May 2022 19:02:41 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v5] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 00:02:35 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > trayicon update triggered on taskbar reload Yeah, this version works correctly on both test systems that I have. I think the solution could be simplified. First of all, there's no need to call `UpdateTrayIconHandler` if DPI hasn't changed. A handler for `WM_DPICHANGED` sets a flag; then `WmTaskbarCreated` uses the flag to call updateImage. `WmTaskbarCreated` iterates over all the icons, you can use this loop to call `WTrayIconPeer.updateImage`. This way all the icons will be updated on the toolkit thread. I'm not sure whether the handler should still sent both `NIM_MODIFY` and `NIM_ADD`; the former should be enough for DPI change (called from `updateNativeImage`), and the latter should be enough for the case where the Taskbar is really recreated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Thu May 12 19:10:51 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 12 May 2022 19:10:51 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Calculate char offset before realloc() I will see what upstream thinks about the harfbuzz warning but in the mean time we can just disable it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From duke at openjdk.java.net Thu May 12 19:14:40 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 12 May 2022 19:14:40 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v5] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 18:59:47 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> trayicon update triggered on taskbar reload > > Yeah, this version works correctly on both test systems that I have. > > I think the solution could be simplified. First of all, there's no need to call `UpdateTrayIconHandler` if DPI hasn't changed. A handler for `WM_DPICHANGED` sets a flag; then `WmTaskbarCreated` uses the flag to call updateImage. > > `WmTaskbarCreated` iterates over all the icons, you can use this loop to call `WTrayIconPeer.updateImage`. This way all the icons will be updated on the toolkit thread. I'm not sure whether the handler should still sent both `NIM_MODIFY` and `NIM_ADD`; the former should be enough for DPI change (called from `updateNativeImage`), and the latter should be enough for the case where the Taskbar is really recreated. @aivanov-jdk Thank you for looking into this issue and suggesting a better & optimized approach. Additionally adding you as a contributor for this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Thu May 12 23:58:02 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 12 May 2022 23:58:02 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v4] In-Reply-To: References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> Message-ID: On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan wrote: >> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > korean fallback added I'm confused since your images with and without the font pack look the same yet they should be using different fonts - ie Gulimche should be used for monospaced when you have the font pack - although maybe it is always installed, but also the rendering of each group looks the same so serif == sanserif == monospaced == dialoginput == dialog - why ? Which should not be the case at least with the font pack ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From duke at openjdk.java.net Fri May 13 00:58:48 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 13 May 2022 00:58:48 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v6] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: new changes - trayicon update triggered in WmTaskbarCreated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/532868e7..eff226f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=04-05 Stats: 71 lines in 5 files changed: 30 ins; 29 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Fri May 13 01:01:49 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 13 May 2022 01:01:49 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v5] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 18:59:47 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> trayicon update triggered on taskbar reload > > Yeah, this version works correctly on both test systems that I have. > > I think the solution could be simplified. First of all, there's no need to call `UpdateTrayIconHandler` if DPI hasn't changed. A handler for `WM_DPICHANGED` sets a flag; then `WmTaskbarCreated` uses the flag to call updateImage. > > `WmTaskbarCreated` iterates over all the icons, you can use this loop to call `WTrayIconPeer.updateImage`. This way all the icons will be updated on the toolkit thread. I'm not sure whether the handler should still sent both `NIM_MODIFY` and `NIM_ADD`; the former should be enough for DPI change (called from `updateNativeImage`), and the latter should be enough for the case where the Taskbar is really recreated. Based on @aivanov-jdk suggestions, new code changes have been incorporated. With the new change - tray icon update is triggered only when DPI change event is received and in WmTaskbarCreated(). Changes have been tested on Win 10 & 11 and works as expected. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Fri May 13 01:27:40 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 13 May 2022 01:27:40 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v7] In-Reply-To: References: Message-ID: <0Syo4XvqYjnfQyOJKYBh5FcA0R2M3SEb_I4i67Mhq9g=.a35faaa4-c776-421d-9353-b287095af906@github.com> > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: reverted SystemTray changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/eff226f9..8f144b3b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From psadhukhan at openjdk.java.net Fri May 13 03:30:48 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 13 May 2022 03:30:48 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v4] In-Reply-To: References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> Message-ID: <3kwTjJiEX4CfrvtF6QnXVhn6vxs31fGUrLT8K9WswLE=.6e0377e0-468c-431e-b9c0-dea8628381c6@github.com> On Thu, 12 May 2022 23:54:47 GMT, Phil Race wrote: > I'm confused since your images with and without the font pack look the same yet they should be using different fonts - ie Gulimche should be used for monospaced when you have the font pack - although maybe it is always installed, but also the rendering of each group looks the same so serif == sanserif == monospaced == dialoginput == dialog - why ? > > Which should not be the case at least with the font pack Are you asking this "with the fix"? As I mentioned, > Now in my WIndows 10, I have these font files irrespective of Korean font pack installed or not, > so I guess that is why there is no difference in the font image **with the fix** with/without korean font pack ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From asotona at openjdk.java.net Fri May 13 08:32:29 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Fri, 13 May 2022 08:32:29 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v6] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base new case appeared in java.base by moving jdk.incubator.foreign code under java.base - Merge remote-tracking branch 'upstream/master' into JDK-8244681 # Conflicts: # make/test/BuildMicrobenchmark.gmk - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments jdk.internal.le make patch to disable warnings - 8244681: Add a warning for possibly lossy conversion in compound assignments ------------- Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=05 Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From ysuenaga at openjdk.java.net Fri May 13 10:02:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 13 May 2022 10:02:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Revert change for java.c , parse_manifest.c , LinuxPackage.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/b3afa3e0..d5ef2c63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03-04 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From shade at openjdk.java.net Fri May 13 12:55:46 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 13 May 2022 12:55:46 GMT Subject: RFR: 8284956: Potential leak awtImageData/color_data when initializes X11GraphicsEnvironment [v2] In-Reply-To: References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com> Message-ID: On Thu, 28 Apr 2022 14:58:28 GMT, Zhengyu Gu wrote: >> During initializing native data of `X11GraphicsEnvironment`, a single `AwtGraphicsConfigData` is used/reused, not only failed cases, but also succeeded cases. So `AwtGraphicsConfigData` internal states need to be cleanup properly to avoid memory leaks. >> >> Test: >> - [x] jdk_awt > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Aleksey and Andrew's comments Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8317 From zgu at openjdk.java.net Fri May 13 13:15:00 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 13 May 2022 13:15:00 GMT Subject: RFR: 8284956: Potential leak awtImageData/color_data when initializes X11GraphicsEnvironment [v2] In-Reply-To: References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com> Message-ID: On Wed, 27 Apr 2022 17:59:01 GMT, Phil Race wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Aleksey and Andrew's comments > > Marked as reviewed by prr (Reviewer). Thanks for the reviews, @prrace @shipilev and @gnu-andrew ------------- PR: https://git.openjdk.java.net/jdk/pull/8317 From zgu at openjdk.java.net Fri May 13 13:15:02 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 13 May 2022 13:15:02 GMT Subject: Integrated: 8284956: Potential leak awtImageData/color_data when initializes X11GraphicsEnvironment In-Reply-To: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com> References: <3POzEJ3BfvLSZncFAN7pluxsSz9_UB_wyeCMV53X-CQ=.e24bef4e-3638-4338-bd3e-3d341e21428a@github.com> Message-ID: <_pvPITTL-7j9vR3UTzPcWqyXRC8RdWj-fLoKJ9tMLbA=.26a34d88-d5f5-463c-be62-293688293182@github.com> On Wed, 20 Apr 2022 13:48:19 GMT, Zhengyu Gu wrote: > During initializing native data of `X11GraphicsEnvironment`, a single `AwtGraphicsConfigData` is used/reused, not only failed cases, but also succeeded cases. So `AwtGraphicsConfigData` internal states need to be cleanup properly to avoid memory leaks. > > Test: > - [x] jdk_awt This pull request has now been integrated. Changeset: cbe7e7bd Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/cbe7e7bd7f7e7ea9f7221ef206917c58baff7696 Stats: 42 lines in 1 file changed: 31 ins; 4 del; 7 mod 8284956: Potential leak awtImageData/color_data when initializes X11GraphicsEnvironment Reviewed-by: prr, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8317 From ysuenaga at openjdk.java.net Fri May 13 14:17:44 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 13 May 2022 14:17:44 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c I've sent another review request for bug fixes as #8694 and #8696 , and I reverted change for them from this PR. Could you review this PR to suppress warnings which we can ignore? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From prr at openjdk.java.net Fri May 13 15:08:06 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 13 May 2022 15:08:06 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v4] In-Reply-To: References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> Message-ID: On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan wrote: >> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > korean fallback added No, I am asking why every font looks the same? They should be different fonts for Dialog and Serif - shouldn't they ??? ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From ihse at openjdk.java.net Fri May 13 16:11:04 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:11:04 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v2] In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> Message-ID: > I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos. > > I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie has updated the pull request incrementally with 14 additional commits since the last revision: - Update src/java.desktop/share/classes/javax/swing/ActionPropertyChangeListener.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/windows/native/libawt/windows/awt_PrintDialog.cpp Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/windows/native/libawt/windows/awt_Label.h Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c0e79d...d11ef860 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8328/files - new: https://git.openjdk.java.net/jdk/pull/8328/files/e5c0e79d..d11ef860 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=00-01 Stats: 18 lines in 14 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328 PR: https://git.openjdk.java.net/jdk/pull/8328 From ihse at openjdk.java.net Fri May 13 16:17:56 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:17:56 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v3] In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> Message-ID: > I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos. > > I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision: - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/JCheckBox.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8328/files - new: https://git.openjdk.java.net/jdk/pull/8328/files/d11ef860..42656f52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=01-02 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328 PR: https://git.openjdk.java.net/jdk/pull/8328 From ihse at openjdk.java.net Fri May 13 16:17:59 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:17:59 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v3] In-Reply-To: <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> Message-ID: On Thu, 28 Apr 2022 16:48:04 GMT, Alexey Ivanov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision: >> >> - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/JCheckBox.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/share/classes/javax/swing/GroupLayout.java line 1654: > >> 1652: /** >> 1653: * Used to compute how the two values representing two springs >> 1654: * will be combined. For example, a group that laid things out > > Suggestion: > > * will be combined. For example, a group that laid out things > > Not sure which one is correct. Usually the particle in a phrasal verb follows the verb is the object is a noun. If you're not sure, I prefer to leave it as it is. ------------- PR: https://git.openjdk.java.net/jdk/pull/8328 From ihse at openjdk.java.net Fri May 13 16:20:11 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:20:11 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v4] In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> Message-ID: <6Hmf5mjZoahwM1ZkGvSOp7dOYsVlDme8M2FKh96JdmM=.afe9dd13-b975-4fc8-a75b-0884d2c9927b@github.com> > I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos. > > I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.desktop/share/classes/javax/swing/JPopupMenu.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/JMenu.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8328/files - new: https://git.openjdk.java.net/jdk/pull/8328/files/42656f52..b6025570 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328 PR: https://git.openjdk.java.net/jdk/pull/8328 From ihse at openjdk.java.net Fri May 13 16:32:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:32:48 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v5] In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> Message-ID: <3SlpqjTO1Y6zx6N-uF9RuZSZFqX7oqZXnjczEUgCQ3Y=.6c5e356f-848e-426d-a3c0-bd9548cf6ac8@github.com> > I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos. > > I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision: - Update src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/SwingWorker.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/JSpinner.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8328/files - new: https://git.openjdk.java.net/jdk/pull/8328/files/b6025570..40c585cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=03-04 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328 PR: https://git.openjdk.java.net/jdk/pull/8328 From ihse at openjdk.java.net Fri May 13 16:53:00 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:53:00 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v6] In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> Message-ID: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com> > I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos. > > I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay. > > I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder). > > The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR. Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision: - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/40c585cd...98e635a5 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8328/files - new: https://git.openjdk.java.net/jdk/pull/8328/files/40c585cd..98e635a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=04-05 Stats: 21 lines in 14 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/8328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328 PR: https://git.openjdk.java.net/jdk/pull/8328 From ihse at openjdk.java.net Fri May 13 16:53:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:53:02 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v6] In-Reply-To: <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> Message-ID: On Thu, 28 Apr 2022 20:37:22 GMT, Alexey Ivanov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision: >> >> - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/40c585cd...98e635a5 > > src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 772: > >> 770: /* >> 771: * we do not store the same value as previous. in our >> 772: * documents it is often for consequent positions to have > > Looks this actually means _consecutive_ positions? Possibly. I suggest you file a follow up PR to address additional documentation errors. ------------- PR: https://git.openjdk.java.net/jdk/pull/8328 From ihse at openjdk.java.net Fri May 13 16:56:54 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 16:56:54 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v6] In-Reply-To: <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> Message-ID: On Thu, 28 Apr 2022 21:25:02 GMT, Alexey Ivanov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision: >> >> - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/40c585cd...98e635a5 > > Nearly 500 files are too many. Smaller chunks would be easier to review. > > Some of the native code files could come from upstream libraries. @aivanov-jdk While I approve of finding and fixing spelling mistakes, grammatical or semantic errors, the mistakes you posted suggestions for was not at all associated with the mechanical changes made by codespell that this PR included, and I assume you noticed them just because you read the text around the typo my PR fixed. In hindsight, it would have been better if you've made these changes yourself, in a separate PR. But since you had spent the effort of looking for these problems, and suggesting fixes, I have now accepted all of them. Due to how the Github UI works, this was quite tedious, so please refrain from submitting more than a handful suggestions next time you review a PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8328 From duke at openjdk.java.net Fri May 13 18:01:47 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 13 May 2022 18:01:47 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into WinTrayIcon - reverted SystemTray changes - new changes - trayicon update triggered in WmTaskbarCreated - trayicon update triggered on taskbar reload - test case exit issue fix - formatting changes - resized instruction window and formatted line lengths - removed whitespaces error due to CRLF - removed whitespace error - added manual to test case - ... and 1 more: https://git.openjdk.java.net/jdk/compare/9ac0120d...60391f28 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/8f144b3b..60391f28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=06-07 Stats: 216539 lines in 2758 files changed: 164744 ins; 37288 del; 14507 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Fri May 13 18:34:01 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 May 2022 18:34:01 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v6] In-Reply-To: References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> Message-ID: On Fri, 13 May 2022 16:53:31 GMT, Magnus Ihse Bursie wrote: >> Nearly 500 files are too many. Smaller chunks would be easier to review. >> >> Some of the native code files could come from upstream libraries. > > @aivanov-jdk While I approve of finding and fixing spelling mistakes, grammatical or semantic errors, the mistakes you posted suggestions for was not at all associated with the mechanical changes made by codespell that this PR included, and I assume you noticed them just because you read the text around the typo my PR fixed. > > In hindsight, it would have been better if you've made these changes yourself, in a separate PR. > > But since you had spent the effort of looking for these problems, and suggesting fixes, I have now accepted all of them. Due to how the Github UI works, this was quite tedious, so please refrain from submitting more than a handful suggestions next time you review a PR. Thank you, @magicus, I should've noted the changes and created a branch on top yours. That's right. Even looking through all the changes in this PR was tedious, more than hundred files doesn't work well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8328 From kizune at openjdk.java.net Fri May 13 18:36:37 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 May 2022 18:36:37 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes [v2] In-Reply-To: References: Message-ID: > Moving cache invalidation from the clearCache method to a createRowWithIndex method > eliminating race condition that causes crash. Now clearCache just notifies that cache > is invalid and should be regenerated next time it is being accessed. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Add a test case. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8636/files - new: https://git.openjdk.java.net/jdk/pull/8636/files/3a391d34..11f25a16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8636&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8636&range=00-01 Stats: 28 lines in 1 file changed: 28 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8636.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8636/head:pull/8636 PR: https://git.openjdk.java.net/jdk/pull/8636 From kizune at openjdk.java.net Fri May 13 18:39:39 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 May 2022 18:39:39 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes In-Reply-To: References: Message-ID: On Wed, 11 May 2022 10:03:59 GMT, Artem Semenov wrote: > If possible, please add this case to the regression test > > test/jdk/java/awt/a11y/AccessibleJTableTest.java Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From aivanov at openjdk.java.net Fri May 13 18:42:01 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 May 2022 18:42:01 GMT Subject: RFR: 8285306: Fix typos in java.desktop [v6] In-Reply-To: References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com> Message-ID: On Fri, 13 May 2022 16:48:35 GMT, Magnus Ihse Bursie wrote: >> src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 772: >> >>> 770: /* >>> 771: * we do not store the same value as previous. in our >>> 772: * documents it is often for consequent positions to have >> >> Looks this actually means _consecutive_ positions? > > Possibly. I suggest you file a follow up PR to address additional documentation errors. I've submitted [JDK-8286759](https://bugs.openjdk.java.net/browse/JDK-8286759): TextComponentPrintable: consequent -> consecutive positions. ------------- PR: https://git.openjdk.java.net/jdk/pull/8328 From kcr at openjdk.java.net Fri May 13 19:04:04 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 May 2022 19:04:04 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: Message-ID: <92oUwasvoTrAbkjoIlym95BNo9ydUscYqO6oP6b1VwQ=.1ee9034b-04c7-4d25-9bca-02ca598c6b57@github.com> On Fri, 13 May 2022 18:01:47 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - trayicon update triggered on taskbar reload > - test case exit issue fix > - formatting changes > - resized instruction window and formatted line lengths > - removed whitespaces error due to CRLF > - removed whitespace error > - added manual to test case > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/eabce393...60391f28 The latest version of the fix looks good, and is simpler than the earlier one. I tested it on Windows 10 and it works well. There are two files that can be reverted, `TrayIcon.java` and `WTrayIconPeer.java`, since the only remaining changes after your last update are unrelated changes in the copyright year and the import statements. The easiest way to do this is `git checkout master -- filename1 filename2 ...`, presuming that the HEAD of `master` matches what you have merged into your branch. src/java.desktop/share/classes/java/awt/TrayIcon.java line 2: > 1: /* > 2: * Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved. You can revert this file, since the only remaining changes are this copyright year and import statements, which are relating to your fix. src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java line 2: > 1: /* > 2: * Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved. You can revert this file, since the only remaining changes are this copyright year and import statements, which are relating to your fix. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 129: > 127: } > 128: } > 129: Minor: there is an extra blank line here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From kcr at openjdk.java.net Fri May 13 19:09:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 May 2022 19:09:53 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 18:01:47 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - trayicon update triggered on taskbar reload > - test case exit issue fix > - formatting changes > - resized instruction window and formatted line lengths > - removed whitespaces error due to CRLF > - removed whitespace error > - added manual to test case > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2deb193e...60391f28 One more thing to look at is that there is a failure in the GitHub Action run for the Windows x64 debug build that looks related to your changes. Make sure that you do a CI build with your latest changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Fri May 13 19:17:00 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 13 May 2022 19:17:00 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: <92oUwasvoTrAbkjoIlym95BNo9ydUscYqO6oP6b1VwQ=.1ee9034b-04c7-4d25-9bca-02ca598c6b57@github.com> References: <92oUwasvoTrAbkjoIlym95BNo9ydUscYqO6oP6b1VwQ=.1ee9034b-04c7-4d25-9bca-02ca598c6b57@github.com> Message-ID: On Fri, 13 May 2022 18:07:02 GMT, Kevin Rushforth wrote: >> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into WinTrayIcon >> - reverted SystemTray changes >> - new changes - trayicon update triggered in WmTaskbarCreated >> - trayicon update triggered on taskbar reload >> - test case exit issue fix >> - formatting changes >> - resized instruction window and formatted line lengths >> - removed whitespaces error due to CRLF >> - removed whitespace error >> - added manual to test case >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/8429be8e...60391f28 > > src/java.desktop/share/classes/java/awt/TrayIcon.java line 2: > >> 1: /* >> 2: * Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved. > > You can revert this file, since the only remaining changes are this copyright year and import statements, which are relating to your fix. @kevinrushforth Thank you for your suggestions . Will revert the files TrayIcon.java and WTrayIconPeer.java as suggested. > test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 129: > >> 127: } >> 128: } >> 129: > > Minor: there is an extra blank line here. > One more thing to look at is that there is a failure in the GitHub Action run for the Windows x64 debug build that looks related to your changes. Make sure that you do a CI build with your latest changes. Yes, there might have been a mix-up with variable name when I pushed the changes. Currently working on it. I'll check the CI build status before pushing the next update. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Fri May 13 19:21:07 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 May 2022 19:21:07 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: <92oUwasvoTrAbkjoIlym95BNo9ydUscYqO6oP6b1VwQ=.1ee9034b-04c7-4d25-9bca-02ca598c6b57@github.com> References: <92oUwasvoTrAbkjoIlym95BNo9ydUscYqO6oP6b1VwQ=.1ee9034b-04c7-4d25-9bca-02ca598c6b57@github.com> Message-ID: On Fri, 13 May 2022 18:08:23 GMT, Kevin Rushforth wrote: >> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into WinTrayIcon >> - reverted SystemTray changes >> - new changes - trayicon update triggered in WmTaskbarCreated >> - trayicon update triggered on taskbar reload >> - test case exit issue fix >> - formatting changes >> - resized instruction window and formatted line lengths >> - removed whitespaces error due to CRLF >> - removed whitespace error >> - added manual to test case >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/ebb69ea9...60391f28 > > src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java line 2: > >> 1: /* >> 2: * Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved. > > You can revert this file, since the only remaining changes are this copyright year and import statements, which are relating to your fix. I'm for keeping the expanded imports in WTrayIconPeer.java, even it's the only change left now. I'd probably remove the unused import from `TrayIcon.java` too. However, the change in this case is too minor. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Fri May 13 19:22:52 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 May 2022 19:22:52 GMT Subject: RFR: 8285306: Fix typos in java.desktop In-Reply-To: <4QVTblMgjEo2KBoDGn1G67qqvHtOkdmqeU4e88o2eHU=.faf55412-6b4a-4fe4-ac84-82ee0cea2f8d@github.com> References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com> <4QVTblMgjEo2KBoDGn1G67qqvHtOkdmqeU4e88o2eHU=.faf55412-6b4a-4fe4-ac84-82ee0cea2f8d@github.com> Message-ID: <-jePZ8ESH0oSeqb03Bpr7kJUSkAOEsme4nNWfR4JuKU=.1ad19f01-d116-4e82-b530-4c5f13fe7e43@github.com> On Wed, 27 Apr 2022 03:38:09 GMT, Phil Race wrote: > Please exclude ALL 3rd party libraries from this PR. Are these the only files to be excluded? src/java.desktop/share/native/libfreetype/src/autofit/afcjk.c src/java.desktop/share/native/libfreetype/src/autofit/aflatin.c src/java.desktop/share/native/libfreetype/src/base/ftsynth.c src/java.desktop/share/native/libfreetype/src/raster/ftraster.c ------------- PR: https://git.openjdk.java.net/jdk/pull/8328 From kcr at openjdk.java.net Fri May 13 19:31:50 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 May 2022 19:31:50 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: <92oUwasvoTrAbkjoIlym95BNo9ydUscYqO6oP6b1VwQ=.1ee9034b-04c7-4d25-9bca-02ca598c6b57@github.com> Message-ID: On Fri, 13 May 2022 19:16:52 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved. >> >> You can revert this file, since the only remaining changes are this copyright year and import statements, which are relating to your fix. > > I'm for keeping the expanded imports in WTrayIconPeer.java, even it's the only change left now. > > I'd probably remove the unused import from `TrayIcon.java` too. However, the change in this case is too minor. My preference would be to revert it. Once all of the actual changes associated with this fix were reverted, fixing the imports (or any similar type cleanup) in a file that otherwise doesn't need to be touched at all becomes an unrelated change. Maybe Phil can weigh in on this point. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Fri May 13 19:34:54 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 May 2022 19:34:54 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 04:09:29 GMT, Prasanta Sadhukhan wrote: >> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. >> This is because when the table is scrolled down to last page, the bounds.y becomes -ve >> [x=0,y=-15260,width=968,height=16000] >> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] >> but subsequent pages clip >> [[x=0,y=1296,width=968,height=1296], >> [x=0,y=2592,width=968,height=1296], >> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed >> >> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI >> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 >> >> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From aivanov at openjdk.java.net Fri May 13 19:34:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 May 2022 19:34:57 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v11] In-Reply-To: References: Message-ID: <5qhPsniRLv4oBlsMs5azR6IbNEFMu4Uu0hq73hdl1Ts=.2f81fd35-f266-494b-9dad-1504c7a3308e@github.com> On Thu, 12 May 2022 04:05:48 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 80: >> >>> 78: try { >>> 79: if (!table.print()) { >>> 80: throw new RuntimeException("Printing cancelled"); >> >> When run outside of jtreg, this exception doesn't stop the test. In jtreg, it does. >> >> So it works as expected when run in jtreg but it could be confusing if run as a stand-alone test. > > I amnot sure if anyone will try to run it outside jtreg as it has dependancy on jtreg helper class PassFailJFrame > but anyway I have tried to address the concern. I usually do. In fact, your change doesn't resolve the problem. However, you've made it easier to resolve now. The thing is disposing of frames is hidden inside `awaitAndCheck`. Anyway I see no reason to keep this PR open. The problem can be addressed later if required. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From aivanov at openjdk.java.net Fri May 13 19:37:42 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 13 May 2022 19:37:42 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: <92oUwasvoTrAbkjoIlym95BNo9ydUscYqO6oP6b1VwQ=.1ee9034b-04c7-4d25-9bca-02ca598c6b57@github.com> Message-ID: <0EtGFVlnwnDv49Z52d_kMf2u_wWHtc7iWgCOUlfjesg=.95331472-5ff1-4445-9bfc-6e0f69ddeb11@github.com> On Fri, 13 May 2022 19:28:26 GMT, Kevin Rushforth wrote: >> I'm for keeping the expanded imports in WTrayIconPeer.java, even it's the only change left now. >> >> I'd probably remove the unused import from `TrayIcon.java` too. However, the change in this case is too minor. > > My preference would be to revert it. Once all of the actual changes associated with this fix were reverted, fixing the imports (or any similar type cleanup) in a file that otherwise doesn't need to be touched at all becomes an unrelated change. Maybe Phil can weigh in on this point. Your approach makes the changeset _cleaner_, I agree. Nothing's changed in these two files. Better to avoid touching them and creating confusion. Let's leave these clean-up changes until the files are modified. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From kizune at openjdk.java.net Fri May 13 22:12:46 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 13 May 2022 22:12:46 GMT Subject: Integrated: 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows In-Reply-To: References: Message-ID: <_joLrI6WJqK7vQEGrr1DU_MKwiXsQPpWx_Cl0SmUYOk=.f4e4d21e-9722-4e28-9ab7-a727ebe1b5c1@github.com> On Wed, 20 Apr 2022 05:10:23 GMT, Alexander Zuev wrote: > Only check that insets of the fully expanded undecorated window is not bigger than device insets. They can be smaller, it is a normal situation. This pull request has now been integrated. Changeset: f56396f1 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/f56396f1689ea7e13dea78dcb1d14dcce94da898 Stats: 10 lines in 2 files changed: 6 ins; 2 del; 2 mod 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8314 From prr at openjdk.java.net Fri May 13 22:12:58 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 13 May 2022 22:12:58 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 18:01:47 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - trayicon update triggered on taskbar reload > - test case exit issue fix > - formatting changes > - resized instruction window and formatted line lengths > - removed whitespaces error due to CRLF > - removed whitespace error > - added manual to test case > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f228d55a...60391f28 src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 239: > 237: env->ExceptionDescribe(); > 238: env->ExceptionClear(); > 239: } Reduce this to ExceptionClear() (1) ExceptionDescribe() per the docs https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptions prints a message .. which we don't want .. it is meant for debugging not production and FWIW it clears the pending exception so any time you see Describe() followed by Clear() the code seems odd (well pointless) 2) safe_ExceptionOccurred is only useful if you are coming from a JNI method that uses C++ exception handling. Here the call originates from native doesn't it ? And we don't return to Java since it is a native event loop. Ah I see we also have it called from _initIDs. Well I think for simplicity my advice stands. So JUST env->ExceptionClear() will do ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Fri May 13 22:13:00 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 13 May 2022 22:13:00 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: <3Gsk9aV8CIHXwivkLKTSeG1fb-WbY8TiaqCCvWdZFEI=.61556ada-97fe-4638-8487-77e75fed01de@github.com> On Mon, 9 May 2022 20:42:05 GMT, Alexey Ivanov wrote: > This should be the first statement in main. If icons aren't supported, there's no need to create the instruction frame. The test will still wait for user's response but no tray icon is added. It won't wait if you haven't created it .. it will just exit without showing anything and be counted as pass, that's probably OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Fri May 13 22:22:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 13 May 2022 22:22:50 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v4] In-Reply-To: References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> Message-ID: On Wed, 16 Mar 2022 06:02:28 GMT, Prasanta Sadhukhan wrote: >> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > korean fallback added I still don't understand why they are the same for you .. I added korean-fallback to my local fontconfig and ran in the Korean locale (changed my windows region to Korea and rebooted) and they are different for me. What I do seem to be seeing is that because we now have UTF-8 as the default encoding and that we have no UTF-8.ko that it goes the fallback route .. and so although you get korean by fallback it prefers Chinese and Japanese fonts which isn't right for a Korean locale I believe we need to add a line like the ja one sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol +sequence.allfonts.UTF-8.ko=alphabetic,korean,dingbats,symbol [See https://git.openjdk.java.net/jdk/pull/8662 for more info and we likely need to do more of these lines and perhaps you need that PR pushed to include in your testing .. alas I don't even have a single approver yet, so nowhere near the two I need !] .. even without that I was OK perhaps so long as the fallback seqeuence had "korean" - I'd have to re-test that So I don't know if that will cure them all being the same for you but it might. ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From duke at openjdk.java.net Fri May 13 22:30:49 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Fri, 13 May 2022 22:30:49 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: Message-ID: <8jeb8BWhST_8X7OyYIo-alQTwzMD1j8Zu20c9WsbXhE=.e019c5dd-94cb-4def-9569-035c64569ae6@github.com> On Fri, 13 May 2022 22:04:39 GMT, Phil Race wrote: >> Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into WinTrayIcon >> - reverted SystemTray changes >> - new changes - trayicon update triggered in WmTaskbarCreated >> - trayicon update triggered on taskbar reload >> - test case exit issue fix >> - formatting changes >> - resized instruction window and formatted line lengths >> - removed whitespaces error due to CRLF >> - removed whitespace error >> - added manual to test case >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f004848d...60391f28 > > src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 239: > >> 237: env->ExceptionDescribe(); >> 238: env->ExceptionClear(); >> 239: } > > Reduce this to ExceptionClear() > (1) ExceptionDescribe() per the docs https://docs.oracle.com/en/java/javase/17/docs/specs/jni/functions.html#exceptions > prints a message .. which we don't want .. it is meant for debugging not production and FWIW it clears the pending exception so any time you see Describe() followed by Clear() the code seems odd (well pointless) > 2) safe_ExceptionOccurred is only useful if you are coming from a JNI method that uses C++ exception handling. Here the call originates from native doesn't it ? And we don't return to Java since it is a native event loop. > > Ah I see we also have it called from _initIDs. Well I think for simplicity my advice stands. > > So JUST env->ExceptionClear() will do @prrace Thanks for the details on ExceptionClear and its usage. Makes sense. I'll have it fixed on my next commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Fri May 13 22:43:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 13 May 2022 22:43:50 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v4] In-Reply-To: References: Message-ID: <0iVBmYJATX9y0RLJWjYLCMt0EDRXA9vTBjM9jYocS5Y=.819767c3-03d6-486e-8745-db566d3961a5@github.com> On Thu, 12 May 2022 07:25:22 GMT, Tejesh R wrote: >> In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Removed the test from open, updated in closed I find it very strange that https://bugs.openjdk.java.net/browse/JDK-5047379 was fixed in 2005 and the bug report there says > This fix only affects tooltips. It can be tested on any platform as it is platform independent. And by platforms it really means for the default L&F which is Metal on Windows .. So I think the reason it took 14 years for anyone to notice it wasn't behaving the same on Windows L&F is that it wasn't designed for the Windows L&F Which begs two questions, 1) why was someone testing it on a non-default L&F .. "we run all tests on all L&Fs" isn't really something you should do without careful thought 2) Does this mean it is actually a Metal "special" behaviour .. do Windows NATIVE apps display mnemonics on tool tips ? And since per the eval of 5047379 > the only time we'll show an accelerator key in the tooltip is if someone has added a WHEN_IN_FOCUSED_WINDOW binding to the component's InputMap. Perhaps no one should be caring about this ? Maybe we just update the test to hardwire Metal and move on ? That'll mean the test will always pass no matter what L&F SQE specify as the default .. I find it very strange that https://bugs.openjdk.java.net/browse/JDK-5047379 was fixed in 2005 and the bug report there says > This fix only affects tooltips. It can be tested on any platform as it is platform independent. And by platforms it really means for the default L&F which is Metal on Windows .. So I think the reason it took 14 years for anyone to notice it wasn't behaving the same on Windows L&F is that it wasn't designed for the Windows L&F Which begs two questions, 1) why was someone testing it on a non-default L&F .. "we run all tests on all L&Fs" isn't really something you should do without careful thought 2) Does this mean it is actually a Metal "special" behaviour .. do Windows NATIVE apps display mnemonics on tool tips ? And since per the eval of 5047379 > the only time we'll show an accelerator key in the tooltip is if someone has added a WHEN_IN_FOCUSED_WINDOW binding to the component's InputMap. Perhaps no one should be caring about this ? Maybe we just update the test to hardwire Metal and move on ? That'll mean the test will always pass no matter what L&F SQE specify as the default .. ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From serb at openjdk.java.net Sat May 14 00:22:50 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 14 May 2022 00:22:50 GMT Subject: RFR: 7131823: bug in GIFImageReader [v3] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 22:10:43 GMT, Dan Lutker wrote: >> ?xception: Index 4096 out of bounds for length 4096 >> >> Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4 >> >> # Testing done >> Build locally on linux and ran jdk_imageio tests. > > Dan Lutker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 7131823: bug in GIFImageReader Marked as reviewed by serb (Reviewer). We got the similar bug report and I can confirm that this patch fixed the problem, so it looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8371 From serb at openjdk.java.net Sat May 14 00:27:40 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 14 May 2022 00:27:40 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v3] In-Reply-To: <5s-Ai3c0nGi0S-GWRkS9qqdeHEIB7p_Bjy5GPoKn0jQ=.cec42afa-e837-4503-b749-2125956937ce@github.com> References: <5s-Ai3c0nGi0S-GWRkS9qqdeHEIB7p_Bjy5GPoKn0jQ=.cec42afa-e837-4503-b749-2125956937ce@github.com> Message-ID: On Wed, 4 May 2022 07:48:17 GMT, Dmitry Kulikov wrote: >> Hello, >> Please review this fix for JDK-8282863. >> >> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. >> >> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: >> >> 1. `java.awt.Frame` is created and set as full-screen. >> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. >> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. >> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: >> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. >> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. >> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. >> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. >> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. >> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. >> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. >> >> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. >> >> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. > > Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: > > Update the JavaDoc for added method Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From serb at openjdk.java.net Sat May 14 00:55:43 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 14 May 2022 00:55:43 GMT Subject: RFR: 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 05:10:23 GMT, Alexander Zuev wrote: > Only check that insets of the fully expanded undecorated window is not bigger than device insets. They can be smaller, it is a normal situation. That a mistake to consider that as a correct behavior even based on the amount of bugs we have. The MAXIMIZED_BOTH property was considered as a "maximize" action, and should allow such behavior for the custom application when the decorations are rendered by the app. You can check all that bugs and see how many people report it and then accept, for example this one: https://bugs.openjdk.java.net/browse/JDK-4976497 which shows that even Swing is broken if setDefaultLookAndFeelDecorated is used. Note that this test is not for the borderless window which should cover the full screen but specifically for the MAXIMIZED_BOTH action which expected to maximize the window in the same way as for decorated frame. And I think this is how it works on other platforms since the test passed there. This is why this test created 20 years ago was not changed, it was expected that we fix the JDK. I suggest to rollback this and apply the fix to JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8314 From asemenov at openjdk.java.net Sat May 14 13:40:48 2022 From: asemenov at openjdk.java.net (Artem Semenov) Date: Sat, 14 May 2022 13:40:48 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes [v2] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 18:36:37 GMT, Alexander Zuev wrote: >> Moving cache invalidation from the clearCache method to a createRowWithIndex method >> eliminating race condition that causes crash. Now clearCache just notifies that cache >> is invalid and should be regenerated next time it is being accessed. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add a test case. Everything suits me. ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From duke at openjdk.java.net Sat May 14 17:30:58 2022 From: duke at openjdk.java.net (SWinxy) Date: Sat, 14 May 2022 17:30:58 GMT Subject: Withdrawn: 8286269: [java.desktop] Use newer instanceof language feature wherever possible In-Reply-To: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> References: <78emrcpVxvVXg9HiSWAt6o-EhV4BpWbSFZL6TQtld9U=.dacf6c26-48d3-4a66-8461-281141004cb3@github.com> Message-ID: <3_StHaexerUSG57VDB1oDAR0-7cZN-9TZ89mwPS8r7A=.936534f6-250a-4391-b4be-392e1d4f078b@github.com> On Sat, 8 Jan 2022 18:13:45 GMT, SWinxy wrote: > The old java.desktop package needs dusting off. It hasn't been kept up to pace with the Java language, but it should. The purpose of this PR is to replace most or all `instanceof` checks with the new `instanceof` with a variable. Some methods that used `instanceof` were also reworked alongside the change (such as `.equals()`) if they were small and they could be clearer. > There should be no actual change in outcomes from this PR. I have triple checked my work. Some cases are kinda 'wut?'. > This is also a large change. When pattern matching for switch arrives, many methods can be reworked to take advantage of it (when it comes.. eventually ;w;). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7000 From duke at openjdk.java.net Sat May 14 17:30:59 2022 From: duke at openjdk.java.net (SWinxy) Date: Sat, 14 May 2022 17:30:59 GMT Subject: Withdrawn: 8286271: [java.desktop] Replace ternary operators with java.lang.Math min/max In-Reply-To: References: Message-ID: <9WvEhfsWfCkBAAH4VPrqLOTmyKaEm09Zpvn9xvx4G5k=.1e7262fa-a2f2-479d-94f9-68ef642fd851@github.com> On Sat, 15 Jan 2022 04:23:33 GMT, SWinxy wrote: > Delete `sun.java2d.marlin.FloatMath` class in favor of methods in `java.lang.Math`. The methods in `Math.java` are intrinsics and can gain from significant speedups. Hand-written min/max operations are also replaced with calls. 5 uses of `ceil` and 2 uses of `floor` were replaced. > This should not cause any rendering differences from the different algorithms being used, as they theoretically will end up at the same outcomes. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7097 From duke at openjdk.java.net Sat May 14 17:33:37 2022 From: duke at openjdk.java.net (SWinxy) Date: Sat, 14 May 2022 17:33:37 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v2] In-Reply-To: References: Message-ID: > The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. SWinxy has updated the pull request incrementally with one additional commit since the last revision: Remove @author tags per request ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7096/files - new: https://git.openjdk.java.net/jdk/pull/7096/files/67335f7d..79f3ddf7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7096&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7096&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7096.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7096/head:pull/7096 PR: https://git.openjdk.java.net/jdk/pull/7096 From duke at openjdk.java.net Sat May 14 17:37:46 2022 From: duke at openjdk.java.net (SWinxy) Date: Sat, 14 May 2022 17:37:46 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v2] In-Reply-To: References: Message-ID: <9gnxvxWtmw0BCCvOGvJ8rsh3N_fLG0OTir_kj9Rzpuw=.c1906c38-83ea-4570-864e-d3f23560ce90@github.com> On Sun, 8 May 2022 02:44:16 GMT, Phil Race wrote: >> SWinxy has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove @author tags per request > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/XColors.java line 35: > >> 33: * @author Shannon Hickey >> 34: * @author SWinxy >> 35: */ > > You aren't the author, you are changing the file, and if we go anywhere near @author tags it is to remove them, not add them. Plus "Swinxy" is not very professional Done. I wasn't aware of the intent to get rid of the `@author` tags, but it's very valid. They've been removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From prr at openjdk.java.net Sat May 14 21:25:44 2022 From: prr at openjdk.java.net (Phil Race) Date: Sat, 14 May 2022 21:25:44 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v2] In-Reply-To: References: Message-ID: On Sat, 14 May 2022 17:33:37 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > SWinxy has updated the pull request incrementally with one additional commit since the last revision: > > Remove @author tags per request Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From duke at openjdk.java.net Sat May 14 21:30:42 2022 From: duke at openjdk.java.net (SWinxy) Date: Sat, 14 May 2022 21:30:42 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v2] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 20:21:21 GMT, Phil Race wrote: >>> > The current implementation creates ~750 new objects on load >>> >>> Whereas yours creates an un-bounded number .. and changes that two lookups for the same name will return the same "==" object. >> >> That?s?not what?happens, since?`XColors::lookupColor` always?calls `new?ColorUIResource(?)` in?both the?old and?new?version. >> >> -------------------------------------------------------------------------------- >> >> The difference is that the old version would perform **O**(log?n) lookups with **O**(n) string comparisons per?lookup, whereas?the?new?one performs?a?single `String.hashCode()` invocation (the?result of?which is?cached[^1]) followed?by an?**O**(log?n)?`lookupswitch` and then an?**O**(1)?`tableswitch`. >> >> [^1]: https://github.com/openjdk/jdk/blob/9583e3657e43cc1c6f2101a64534564db2a9bd84/src/java.base/share/classes/java/lang/String.java#L2335-L2355 > >> That?s not what happens, since XColors::lookupColor always calls new ColorUIResource(?) in both the old and new version. > > You are correct. I over-looked the toColor() implementation. > > Ok. this should be fine once the author tag is removed. Thank you @prrace! I will start communicating on the mailing list before making any changes from now on. ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From darcy at openjdk.java.net Sun May 15 21:12:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 15 May 2022 21:12:12 GMT Subject: RFR: JDK-8286787: Expand use of @inheritDoc in AudioInputStream Message-ID: Client libs counterpart of JDK-8286783, refactor the docs in AudioInputStream to inhertiDoc text from InputStream. I'll update copyrights before pushing. ------------- Commit messages: - JDK-8286787: Expand use of @inheritDoc in AudioInputStream Changes: https://git.openjdk.java.net/jdk/pull/8719/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8719&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286787 Stats: 10 lines in 1 file changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8719/head:pull/8719 PR: https://git.openjdk.java.net/jdk/pull/8719 From serb at openjdk.java.net Mon May 16 05:36:35 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 16 May 2022 05:36:35 GMT Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails [v2] In-Reply-To: References: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com> Message-ID: On Wed, 4 May 2022 23:29:34 GMT, Phil Race wrote: > > Does it mean that setVisible(true) cause some memory leak since it prevents the window to be disposed? > > Since 9 windows are freed .. I doubt it .. but what's the hold up with #10 ? I wonder if you need an extra System.gc() cycle Then why we delete the "setVisible(true)"? probably we leak the latest visible window? ------------- PR: https://git.openjdk.java.net/jdk/pull/8450 From duke at openjdk.java.net Mon May 16 06:54:25 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 16 May 2022 06:54:25 GMT Subject: RFR: 8286620: Move bug4380543 from closed to open Message-ID: Moving bug4380543.java from closed repo to open repo. ------------- Commit messages: - Moving bug4380543.java from closed to open - Merge branch 'master' of github.com:TejeshR13/jdk - Merge branch 'openjdk:master' into master - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge branch 'master' of github.com:TejeshR13/jdk - Initial Commit. Changes: https://git.openjdk.java.net/jdk/pull/8721/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286620 Stats: 233 lines in 1 file changed: 233 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8721.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8721/head:pull/8721 PR: https://git.openjdk.java.net/jdk/pull/8721 From duke at openjdk.java.net Mon May 16 09:09:02 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 16 May 2022 09:09:02 GMT Subject: RFR: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF [v4] In-Reply-To: <0iVBmYJATX9y0RLJWjYLCMt0EDRXA9vTBjM9jYocS5Y=.819767c3-03d6-486e-8745-db566d3961a5@github.com> References: <0iVBmYJATX9y0RLJWjYLCMt0EDRXA9vTBjM9jYocS5Y=.819767c3-03d6-486e-8745-db566d3961a5@github.com> Message-ID: On Fri, 13 May 2022 22:39:55 GMT, Phil Race wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed the test from open, updated in closed > > I find it very strange that https://bugs.openjdk.java.net/browse/JDK-5047379 was fixed in 2005 > and the bug report there says >> This fix only affects tooltips. It can be tested on any platform as it is platform independent. > > And by platforms it really means for the default L&F which is Metal on Windows .. > > So I think the reason it took 14 years for anyone to notice it wasn't behaving the same on Windows L&F > is that it wasn't designed for the Windows L&F > > Which begs two questions, > 1) why was someone testing it on a non-default L&F .. "we run all tests on all L&Fs" isn't really something you should do without careful thought > 2) Does this mean it is actually a Metal "special" behaviour .. do Windows NATIVE apps display mnemonics on tool tips ? > And since per the eval of 5047379 >> the only time we'll show an accelerator key in the tooltip is if someone has added a WHEN_IN_FOCUSED_WINDOW binding to the component's InputMap. > > Perhaps no one should be caring about this ? > > Maybe we just update the test to hardwire Metal and move on ? That'll mean the test will always pass no matter what L&F SQE specify as the default .. Yeah, agree with you @prrace. If it is meant for Metal alone, then let me update the test case by setting Metal look and feel in the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From dbatrak at openjdk.java.net Mon May 16 11:05:49 2022 From: dbatrak at openjdk.java.net (Dmitry Batrak) Date: Mon, 16 May 2022 11:05:49 GMT Subject: RFR: 8185261: Font fallback sometimes doesn't work in Swing text components [v2] In-Reply-To: <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com> References: <5qQoyooaZzlKSp4iMudwLZ16MotrGrPB7GhQ3aAVYjo=.8e97ba6f-4aab-40d7-944f-4f68dc2b7b1c@github.com> <4SfhJKrUWWmdo2ZioTjqiU5b3a4cZBwWhMX89auZBRg=.5bf8b903-dbb2-4e7c-adaf-59c5e8212e72@github.com> Message-ID: On Tue, 1 Feb 2022 21:40:53 GMT, Dmitry Batrak wrote: >> The proposed fix makes fonts with and without fallback components distinguishable (in terms of `equals` method), so that >> font metrics cache (and other similar code) can handle them separately. This is achieved by adding a new boolean field >> to `Font` class, specifically denoting fonts with fallback components. The latter ones don't need to pretend to be >> 'created' fonts anymore, to preserve their `Font2D` handle. >> It's not possible to use the existing `createdFont` field in `equals` implementation, as JCK requires a 'real' created >> font (the one obtained using `Font.createFont` method) to be equal to the same font after serialization and >> deserialization. > > Dmitry Batrak has updated the pull request incrementally with one additional commit since the last revision: > > remove 'headful' requirement from test case Not having a feedback on PR for months is pretty discouraging. If any help in solving this issue isn't going to be accepted, let me know - I'll stop pinging then. Just in case, let me re-iterate on the available options, as I see them: - We don't modify `Font.equals` behaviour. In this case, modifications will need to be made in font metrics cache code (and, potentially, other affected places going forward as needed). That code would either access `Font2D` instance directly (making the approach available only for JDK-internal code), or we can introduce some public method in `Font` class, e.g. `rendersEquallyTo(Font)`, which can perform `Font2D` comparison internally. - We do modify `Font.equals` behaviour One option here is to use `Font2D` reference for comparison, but this needs to force font resolution before the comparison, and, I'm afraid, that would be too breaking a change. And if we cannot compare `Font2D` instances, we can only add some more state to `Font` object, either 'hidden' or made available via new API method(s). ------------- PR: https://git.openjdk.java.net/jdk/pull/7313 From asotona at openjdk.java.net Mon May 16 14:45:25 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 16 May 2022 14:45:25 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v7] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'openjdk:master' into JDK-8244681 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base new case appeared in java.base by moving jdk.incubator.foreign code under java.base - Merge remote-tracking branch 'upstream/master' into JDK-8244681 # Conflicts: # make/test/BuildMicrobenchmark.gmk - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments jdk.internal.le make patch to disable warnings - 8244681: Add a warning for possibly lossy conversion in compound assignments ------------- Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06 Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Mon May 16 14:58:33 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 16 May 2022 14:58:33 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v8] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <6fMaRe1U4N-Uz4oe8QKOqIwy-bqkQRVR75XJJpLSXgY=.c8072af3-f0e1-430e-9ab2-33db617c5d77@github.com> > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/a72644e9..74f9f4b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06-07 Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From duke at openjdk.java.net Mon May 16 16:21:40 2022 From: duke at openjdk.java.net (Dan Lutker) Date: Mon, 16 May 2022 16:21:40 GMT Subject: Integrated: 7131823: bug in GIFImageReader In-Reply-To: References: Message-ID: On Fri, 22 Apr 2022 20:04:32 GMT, Dan Lutker wrote: > ?xception: Index 4096 out of bounds for length 4096 > > Adapted from https://github.com/openjdk/jfx/commit/7b7050c46299c0e6771ae02fbb5ceaf22104d3e4 > > # Testing done > Build locally on linux and ran jdk_imageio tests. This pull request has now been integrated. Changeset: a31130fd Author: Dan Lutker Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/a31130fd4056907edcb420761722c629a33273eb Stats: 175 lines in 2 files changed: 158 ins; 4 del; 13 mod 7131823: bug in GIFImageReader Reviewed-by: kizune, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/8371 From duke at openjdk.java.net Mon May 16 17:04:20 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 16 May 2022 17:04:20 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v9] In-Reply-To: References: Message-ID: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: added ExceptionClear, fixed CI debug build issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/60391f28..9228a6f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=07-08 Stats: 24 lines in 4 files changed: 5 ins; 11 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Mon May 16 17:04:28 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 16 May 2022 17:04:28 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v8] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 18:01:47 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - trayicon update triggered on taskbar reload > - test case exit issue fix > - formatting changes > - resized instruction window and formatted line lengths > - removed whitespaces error due to CRLF > - removed whitespace error > - added manual to test case > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/0f7d36fd...60391f28 Changes incorporated: - Added env->ExceptionClear() - Fixed CI debug build issue due to variable mismatch - Added changes suggested by @prrace , @kevinrushforth and @aivanov-jdk ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Mon May 16 17:14:41 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 16 May 2022 17:14:41 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: <3Gsk9aV8CIHXwivkLKTSeG1fb-WbY8TiaqCCvWdZFEI=.61556ada-97fe-4638-8487-77e75fed01de@github.com> References: <3Gsk9aV8CIHXwivkLKTSeG1fb-WbY8TiaqCCvWdZFEI=.61556ada-97fe-4638-8487-77e75fed01de@github.com> Message-ID: On Fri, 13 May 2022 22:09:08 GMT, Phil Race wrote: >> test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 73: >> >>> 71: System.out.println("SystemTray is not supported"); >>> 72: return; >>> 73: } >> >> This should be the first statement in main. If icons aren't supported, there's no need to create the instruction frame. The test will still wait for user's response but no tray icon is added. > >> This should be the first statement in main. If icons aren't supported, there's no need to create the instruction frame. The test will still wait for user's response but no tray icon is added. > > It won't wait if you haven't created it .. it will just exit without showing anything and be counted as pass, that's probably OK. Added the **!SystemTray.isSupported()** check as first line in main(). In case the system tray is not supported, the test is counted as pass and does not proceed to display instruction frame. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From kizune at openjdk.java.net Mon May 16 17:40:42 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 16 May 2022 17:40:42 GMT Subject: RFR: 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows In-Reply-To: References: Message-ID: On Sat, 14 May 2022 00:53:34 GMT, Sergey Bylokhov wrote: > That a mistake to consider that as a correct behavior even based on the amount of bugs we have. The MAXIMIZED_BOTH property was considered as a "maximize" action, and should allow such behavior for the custom application when the decorations are rendered by the app. You can check all that bugs and see how many people report it and then accept, for example this one: https://bugs.openjdk.java.net/browse/JDK-4976497 which shows that even Swing is broken if setDefaultLookAndFeelDecorated is used. > > Note that this test is not for the borderless window which should cover the full screen but specifically for the MAXIMIZED_BOTH action which expected to maximize the window in the same way as for decorated frame. And I think this is how it works on other platforms since the test passed there. This is why this test created 20 years ago was not changed, it was expected that we fix the JDK. > > I suggest to rollback this and apply the fix to JDK. You probably meant https://bugs.openjdk.java.net/browse/JDK-4737788 because 4976497 is closed as a duplicate of it. And i still think it is debatable if this behavior constitutes a bug by itself. As pointed out in 2004: "I think, there is no problem in covering taskbar after maximizing for undecorated frames. For example, Internet Explorer covers taskbar after pressing F11. I think, this is a normal behaviour. But may be we should modify documentation to describe this." So this is at beast a questionable feature that might not be implemented ever. I will not roll back this test change but i will ad the comment to the JDK-4737788 pointing out that change in behavior can warrant revisiting of this test should this bug be addressed at any point in time. There, i just did that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8314 From prr at openjdk.java.net Mon May 16 19:04:38 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:04:38 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v9] In-Reply-To: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> References: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> Message-ID: On Mon, 16 May 2022 17:04:20 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added ExceptionClear, fixed CI debug build issue Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Mon May 16 19:04:39 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 16 May 2022 19:04:39 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> References: <3Q3j5oBlJZixsZsaG2TcJOYjiH8xT_dsYMEzdLAHsQE=.90706668-e620-4076-988b-5e37c3f2ac91@github.com> Message-ID: <025yqERp5cBplgwaDBtSnG5aoSThfoe1m4RK9ZHgneE=.e223ded8-2c17-4dee-8492-77c074fbb04c@github.com> On Mon, 9 May 2022 21:05:26 GMT, Phil Race wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> formatting changes > > test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 72: > >> 70: if (!SystemTray.isSupported()) { >> 71: System.out.println("SystemTray is not supported"); >> 72: return; > > Hmm. When you get here, you already displayed the instructions window, and in the jtreg harness, the user will not see this message. They'll just not see the tray icon and assume it failed. > I think you should be making use of the "forcePass()" code in PassFailJFrame Resolved by adding the check as first statement in main() ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Mon May 16 19:07:32 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:07:32 GMT Subject: RFR: JDK-8286787: Expand use of @inheritDoc in AudioInputStream In-Reply-To: References: Message-ID: On Sun, 15 May 2022 21:05:47 GMT, Joe Darcy wrote: > Client libs counterpart of JDK-8286783, refactor the docs in AudioInputStream to inhertiDoc text from InputStream. > > I'll update copyrights before pushing. Marked as reviewed by prr (Reviewer). one reviewer should be fine for this doc only change ------------- PR: https://git.openjdk.java.net/jdk/pull/8719 From prr at openjdk.java.net Mon May 16 19:25:45 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:25:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From prr at openjdk.java.net Mon May 16 19:25:45 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:25:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 00:26:41 GMT, Yasumasa Suenaga wrote: >> I don't understand what the actual warning is getting at .. can anyone explain it ? >> >> FWIW the code is still the same in upstream harfbuzz >> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc > > I've pasted a part of warning messages to description of this PR, all of messages are here: > > > In function 'void trampoline_reference(hb_trampoline_closure_t*)', > inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24: So upstream say it is not a problem since the analysis overlooks that it would not reach that free if it were immutable because of a previous check. I guess we disable the false positive warning for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From darcy at openjdk.java.net Mon May 16 19:28:14 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 16 May 2022 19:28:14 GMT Subject: RFR: JDK-8286787: Expand use of @inheritDoc in AudioInputStream [v2] In-Reply-To: References: Message-ID: > Client libs counterpart of JDK-8286783, refactor the docs in AudioInputStream to inhertiDoc text from InputStream. > > I'll update copyrights before pushing. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Update copyright. - Merge branch 'master' into JDK-8286787 - JDK-8286787: Expand use of @inheritDoc in AudioInputStream ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8719/files - new: https://git.openjdk.java.net/jdk/pull/8719/files/3de6c571..4ed9c73b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8719&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8719&range=00-01 Stats: 2973 lines in 114 files changed: 2098 ins; 424 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/8719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8719/head:pull/8719 PR: https://git.openjdk.java.net/jdk/pull/8719 From darcy at openjdk.java.net Mon May 16 19:28:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 16 May 2022 19:28:15 GMT Subject: Integrated: JDK-8286787: Expand use of @inheritDoc in AudioInputStream In-Reply-To: References: Message-ID: On Sun, 15 May 2022 21:05:47 GMT, Joe Darcy wrote: > Client libs counterpart of JDK-8286783, refactor the docs in AudioInputStream to inhertiDoc text from InputStream. > > I'll update copyrights before pushing. This pull request has now been integrated. Changeset: af2918ff Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/af2918ff9afbc18840cc21ba2f9e229fd163a01f Stats: 11 lines in 1 file changed: 0 ins; 3 del; 8 mod 8286787: Expand use of @inheritDoc in AudioInputStream Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8719 From aivanov at openjdk.java.net Mon May 16 20:28:45 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 16 May 2022 20:28:45 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v9] In-Reply-To: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> References: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> Message-ID: On Mon, 16 May 2022 17:04:20 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added ExceptionClear, fixed CI debug build issue I clean-built it and tested it, it works correctly on both Windows 10 and 11. src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 73: > 71: jfieldID AwtTrayIcon::idID; > 72: jfieldID AwtTrayIcon::actionCommandID; > 73: jmethodID AwtTrayIcon::updateImageDpiID; I'd rather drop 'Dpi' from the name because the name of the Java method is `updateImage`. If you prefer, the C++ class method could also be changed to `UpdateImage`, dropping 'DPI'. ------------- Marked as reviewed by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8441 From prr at openjdk.java.net Mon May 16 20:56:46 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 20:56:46 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v9] In-Reply-To: References: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> Message-ID: On Mon, 16 May 2022 20:19:55 GMT, Alexey Ivanov wrote: >> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: >> >> added ExceptionClear, fixed CI debug build issue > > src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 73: > >> 71: jfieldID AwtTrayIcon::idID; >> 72: jfieldID AwtTrayIcon::actionCommandID; >> 73: jmethodID AwtTrayIcon::updateImageDpiID; > > I'd rather drop 'Dpi' from the name because the name of the Java method is `updateImage`. > > If you prefer, the C++ class method could also be changed to `UpdateImage`, dropping 'DPI'. yes, that's a good point on the naming ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Mon May 16 21:23:38 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 16 May 2022 21:23:38 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v3] In-Reply-To: <5s-Ai3c0nGi0S-GWRkS9qqdeHEIB7p_Bjy5GPoKn0jQ=.cec42afa-e837-4503-b749-2125956937ce@github.com> References: <5s-Ai3c0nGi0S-GWRkS9qqdeHEIB7p_Bjy5GPoKn0jQ=.cec42afa-e837-4503-b749-2125956937ce@github.com> Message-ID: On Wed, 4 May 2022 07:48:17 GMT, Dmitry Kulikov wrote: >> Hello, >> Please review this fix for JDK-8282863. >> >> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. >> >> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: >> >> 1. `java.awt.Frame` is created and set as full-screen. >> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. >> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. >> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: >> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. >> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. >> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. >> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. >> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. >> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. >> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. >> >> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. >> >> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. > > Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: > > Update the JavaDoc for added method Marked as reviewed by aivanov (Reviewer). src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java line 485: > 483: // Note: window will get resized to actual full-screen dimensions > 484: // in the upcoming display change event, when the DPI scales > 485: // would already be correctly set etc. Suggestion: // Note: the window will get resized to the actual full-screen dimensions // in the upcoming display change event, when the DPI scales // would already be correctly set etc. Or to re-use the original comment: Suggestion: // Note: the full-screen window will get resized to the dimensions of the new // display mode in the upcoming display change event, when the DPI scales // would already be correctly set etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From aivanov at openjdk.java.net Mon May 16 21:28:33 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 16 May 2022 21:28:33 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 08:00:09 GMT, Dmitry Kulikov wrote: >> src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java line 447: >> >>> 445: >>> 446: /** >>> 447: * Reapplies the size of this device to the full-screen window. >> >> What is _this device_? There's no device in the parameters of the method. >> >> If you write javadoc, you should document the parameters too. > > @aivanov-jdk I've updated the JavaDoc to more specifically reference the GraphicsDevice that owns the added method (and documented the parameters) Ah, I overlooked the fact that it's a method of a `GraphicsDevice`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From duke at openjdk.java.net Mon May 16 22:13:22 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 16 May 2022 22:13:22 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v10] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: renamed method id variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/9228a6f0..268abbfb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=08-09 Stats: 25 lines in 3 files changed: 1 ins; 9 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Mon May 16 22:13:24 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Mon, 16 May 2022 22:13:24 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v9] In-Reply-To: References: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> Message-ID: On Mon, 16 May 2022 20:53:45 GMT, Phil Race wrote: >> src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp line 73: >> >>> 71: jfieldID AwtTrayIcon::idID; >>> 72: jfieldID AwtTrayIcon::actionCommandID; >>> 73: jmethodID AwtTrayIcon::updateImageDpiID; >> >> I'd rather drop 'Dpi' from the name because the name of the Java method is `updateImage`. >> >> If you prefer, the C++ class method could also be changed to `UpdateImage`, dropping 'DPI'. > > yes, that's a good point on the naming Update PR with the suggested changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From ysuenaga at openjdk.java.net Tue May 17 01:28:49 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 01:28:49 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> References: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> Message-ID: On Thu, 12 May 2022 11:02:02 GMT, Magnus Ihse Bursie wrote: >> Thanks for all to review this PR! I think we should separate this issue as following: >> >> * Suppress warnings >> * make/modules/java.desktop/lib/Awt2dLibraries.gmk >> * src/hotspot/share/classfile/bytecodeAssembler.cpp >> * src/hotspot/share/classfile/classFileParser.cpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> * src/hotspot/share/opto/memnode.cpp >> * src/hotspot/share/opto/type.cpp >> * src/hotspot/share/utilities/compilerWarnings.hpp >> * src/hotspot/share/utilities/compilerWarnings_gcc.hpp >> * src/java.base/unix/native/libjli/java_md_common.c >> * Bug fixes >> * src/java.base/share/native/libjli/java.c >> * src/java.base/share/native/libjli/parse_manifest.c >> * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c >> >> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. >> >> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > > @YaSuenag From my PoV this sounds like a good suggestion. @magicus @prrace Thanks for your review! Can I get the review from HotSpot folks? @kimbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 02:20:56 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 02:20:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 18:28:02 GMT, Kim Barrett wrote: >> Thanks for all to review this PR! I think we should separate this issue as following: >> >> * Suppress warnings >> * make/modules/java.desktop/lib/Awt2dLibraries.gmk >> * src/hotspot/share/classfile/bytecodeAssembler.cpp >> * src/hotspot/share/classfile/classFileParser.cpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> * src/hotspot/share/opto/memnode.cpp >> * src/hotspot/share/opto/type.cpp >> * src/hotspot/share/utilities/compilerWarnings.hpp >> * src/hotspot/share/utilities/compilerWarnings_gcc.hpp >> * src/java.base/unix/native/libjli/java_md_common.c >> * Bug fixes >> * src/java.base/share/native/libjli/java.c >> * src/java.base/share/native/libjli/parse_manifest.c >> * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c >> >> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. >> >> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > >> @YaSuenag From my PoV this sounds like a good suggestion. > > +1 > Can I get the review from HotSpot folks? @kimbarrett Already working on it. There are some I don't understand yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 03:19:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 03:19:55 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c Some suggestions for code changes instead of warning suppression. And some warnings that I don't yet understand and don't think should be suppressed without more details or investigation. src/hotspot/share/classfile/bytecodeAssembler.cpp line 95: > 93: ShouldNotReachHere(); > 94: } > 95: PRAGMA_DIAG_POP One of these is another of the symbol_at_put cases that I don't understand. Are there other cases in the switch that warn? And if so, which ones and how? There are no details of this one in the PR cover description. src/hotspot/share/classfile/classFileParser.cpp line 5970: > 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED > 5969: _cp->symbol_at_put(hidden_index, _class_name); > 5970: PRAGMA_DIAG_POP I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: > 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED > 102: *dest = op(bits, *dest); > 103: PRAGMA_DIAG_POP I see no stringop here. I'm still trying to understand what the compiler is complaining about. src/hotspot/share/opto/memnode.cpp line 1413: > 1411: bt == T_BYTE || bt == T_SHORT || > 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); > 1413: PRAGMA_DIAG_POP The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. src/hotspot/share/opto/type.cpp line 4300: > 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED > 4299: fatal("not an element type: %s", type2name(etype)); > 4300: PRAGMA_DIAG_POP Another occurrence of type2name returning NULL for unknown BasicType. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 04:56:00 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 04:56:00 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 03:05:09 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/opto/memnode.cpp line 1413: > >> 1411: bt == T_BYTE || bt == T_SHORT || >> 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); >> 1413: PRAGMA_DIAG_POP > > The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From aivanov at openjdk.java.net Tue May 17 12:24:01 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 12:24:01 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v10] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 22:13:22 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > renamed method id variable Changes requested by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Tue May 17 12:24:04 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 12:24:04 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v9] In-Reply-To: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> References: <_owBEc5c1XHqTJ5ME6WCCzOQt0PK-oZsdRK52oreuyk=.be994409-f7be-4aa9-89ba-5c549e5f8502@github.com> Message-ID: On Mon, 16 May 2022 17:04:20 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > added ExceptionClear, fixed CI debug build issue test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 54: > 52: private static SystemTray tray; > 53: private static TrayIcon icon; > 54: I'm nitpicking but I guess the blank line between the fields used in the test and the instructions was in its own place to separate the two different groups. test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java line 87: > 85: } > 86: } > 87: There's usually a blank line between methods to visually separate the end of the previous method from the start of the following one. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From smandalika at openjdk.java.net Tue May 17 12:29:56 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Tue, 17 May 2022 12:29:56 GMT Subject: RFR: 8286172: Create an automated test for JDK-4516019 In-Reply-To: <84yCEDKwGXhQU9c1TYYrxdCLDXQjnIaAkP7FyHW1vpI=.0165d348-59cb-44d9-a09e-f35084e01616@github.com> References: <84yCEDKwGXhQU9c1TYYrxdCLDXQjnIaAkP7FyHW1vpI=.0165d348-59cb-44d9-a09e-f35084e01616@github.com> Message-ID: On Thu, 5 May 2022 23:55:42 GMT, Phil Race wrote: > Also you are doing the same thing I've told others not to - look at the path name > > test/jdk/javax/swing/4516019/JSpinnerFocusTest.java > > what is the point of 4516019 ? Do NOT create an extra directory for no reason. especially one just numbered for a bugid and in this case this test should go in the pre-existing JSpinner directory ! As suggested: Test removed from the original location. Test added under pre-existing JSpinner directory. > test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 29: > >> 27: * @bug 4516019 >> 28: * @summary Clicking on the increment/decrement buttons of the spinner >> 29: * does not get focus onto the spinner. > > That summary is surely describing the bug, not what the test is verifying. > > Shouldn't it read something like > "Verify clicking on inc/dec gives focus to the spinner" Changed appropriately. > test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 81: > >> 79: "Clicking on JSpinner buttons did not" >> 80: + " shift foucs to the JSpinner"); >> 81: } > > foucs -> focus Done > test/jdk/javax/swing/4516019/JSpinnerFocusTest.java line 100: > >> 98: robot.mouseMove(bounds.x + bounds.width/2 , >> 99: bounds.y + bounds.height /2); >> 100: robot.delay(300); > > why not use setAutoDelay(300) and then you don't need all these extra lines of code. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/8546 From smandalika at openjdk.java.net Tue May 17 12:33:43 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Tue, 17 May 2022 12:33:43 GMT Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v4] In-Reply-To: References: Message-ID: > Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690) > > In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane). > In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with. > > This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items. > > The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar. > This review is for migrating tests from a closed test suite to open. Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: - Review comments fixed: Added Test without 'bug id' folder structure - Review comments fixed: Removed file under the 'bug id' folder structure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7753/files - new: https://git.openjdk.java.net/jdk/pull/7753/files/01f8c430..86a5715c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7753&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7753&range=02-03 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7753.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7753/head:pull/7753 PR: https://git.openjdk.java.net/jdk/pull/7753 From smandalika at openjdk.java.net Tue May 17 12:36:04 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Tue, 17 May 2022 12:36:04 GMT Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v2] In-Reply-To: References: Message-ID: > Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019) > > Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children. > > The test validates the same. > > This review is for migrating tests from a closed test suite to open. > > Testing: > The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: - Review comments fixed: Fixed file path, removed redundant sleep call etc. - Review comments fixed: Removed file under the 'bug id' folder structure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8546/files - new: https://git.openjdk.java.net/jdk/pull/8546/files/f1c4278e..b4fef8cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8546&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8546&range=00-01 Stats: 237 lines in 2 files changed: 115 ins; 122 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8546.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8546/head:pull/8546 PR: https://git.openjdk.java.net/jdk/pull/8546 From ysuenaga at openjdk.java.net Tue May 17 12:41:16 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 12:41:16 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 01:43:25 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/classfile/classFileParser.cpp line 5970: > >> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED >> 5969: _cp->symbol_at_put(hidden_index, _class_name); >> 5970: PRAGMA_DIAG_POP > > I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) Like the others, it is caused by `Array::at_put()`. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 12:46:03 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 12:46:03 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 03:02:55 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: > >> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED >> 102: *dest = op(bits, *dest); >> 103: PRAGMA_DIAG_POP > > I see no stringop here. I'm still trying to understand what the compiler is complaining about. I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From martin.desruisseaux at geomatys.com Tue May 17 12:48:46 2022 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Tue, 17 May 2022 14:48:46 +0200 Subject: Unexpected EOFException in ImageReaderSpi.canDecodeInput In-Reply-To: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> References: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> Message-ID: <5f1eed65-78a6-f7a5-ed6b-a6c5bb09a106@geomatys.com> Hello I prepared a pull request at [1] for fixing an unexpected EOFException thrown by ImageReaderSpi.canDecodeInput(Object) in JDK implementations for BMP, WBMP, GIF, PNG and TIFF formats (JPEG is not impacted). This exception occurs when the stream has less than 8 bytes. For example, it occurs when probing all files in a directory if that directory contains empty files. If believe that in order to process, a bug report must be filled on https://bugs.openjdk.java.net/ ? Can someone hint me about how to do that (since I can not create a report myself)? ??? Regards, ??? ??? Martin [1]https://github.com/openjdk/jdk/pull/8700 From smandalika at openjdk.java.net Tue May 17 12:48:49 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Tue, 17 May 2022 12:48:49 GMT Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v4] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:33:43 GMT, Srinivas Mandalika wrote: >> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690) >> >> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane). >> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with. >> >> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items. >> >> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar. >> This review is for migrating tests from a closed test suite to open. > > Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: > > - Review comments fixed: Added Test without 'bug id' folder structure > - Review comments fixed: Removed file under the 'bug id' folder structure As suggested, bug id folder structure is removed and test is under pre-existing accessibility directory. Test code has not changed but it has been run mach5 after the change.(Link provided in the JBS Issue) Can someone take a look and this be marked as approved/sponsored after the above changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/7753 From aivanov at openjdk.java.net Tue May 17 13:11:14 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 13:11:14 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) Message-ID: Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/8441 Commit messages: - 8286872: Refactor add/modify notification icon (TrayIcon) Changes: https://git.openjdk.java.net/jdk/pull/8749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8749&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286872 Stats: 26 lines in 2 files changed: 17 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8749/head:pull/8749 PR: https://git.openjdk.java.net/jdk/pull/8749 From ysuenaga at openjdk.java.net Tue May 17 13:15:24 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:15:24 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v6] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Add assert to check the range of BasicType - Merge remote-tracking branch 'upstream/master' into HEAD - Revert change for java.c , parse_manifest.c , LinuxPackage.c - Calculate char offset before realloc() - Use return value from JLI_Snprintf - Avoid pragma error in before GCC 12 - 8286562: GCC 12 reports some compiler warnings ------------- Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05 Stats: 56 lines in 11 files changed: 46 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From aturbanov at openjdk.java.net Tue May 17 13:21:48 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 17 May 2022 13:21:48 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2] In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> >> if (clazz.isInstance(obj)) { >> >> Replacement is equivalent if it's known that `obj != null`. >> In JDK codebase there are many such places. >> >> I tried to measure performance via JMH >> >> Class integerClass = Integer.class; >> Class numberClass = Number.class; >> >> Object integerObject = 45666; >> Object doubleObject = 8777d; >> >> @Benchmark >> public boolean integerInteger_isInstance() { >> return integerClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean integerInteger_isAssignableFrom() { >> return integerClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public boolean integerDouble_isInstance() { >> return integerClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean integerDouble_isAssignableFrom() { >> return integerClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberDouble_isInstance() { >> return numberClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean numberDouble_isAssignableFrom() { >> return numberClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberInteger_isInstance() { >> return numberClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean numberInteger_isAssignableFrom() { >> return numberClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public void numberIntegerDouble_isInstance(Blackhole bh) { >> bh.consume(numberClass.isInstance(integerObject)); >> bh.consume(numberClass.isInstance(doubleObject)); >> } >> >> @Benchmark >> public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { >> bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); >> bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); >> } >> >> `isInstance` is a bit faster than `isAssignableFrom` >> >> Benchmark Mode Cnt Score Error Units >> integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op >> integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op >> integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op >> numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op >> integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op >> integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op >> numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op >> numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op >> numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op >> numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable > apply suggestion to avoid second Method.invoke call Any more reviewers, please?) ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From ysuenaga at openjdk.java.net Tue May 17 13:24:50 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:24:50 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <63OHghBxNm4xJxaud2ThDD4e3TN_ENSU4Yeh2wZcqR4=.0bcbd897-c9a3-4e48-9416-47deb17c777e@github.com> On Tue, 17 May 2022 03:14:05 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/classfile/bytecodeAssembler.cpp line 95: > >> 93: ShouldNotReachHere(); >> 94: } >> 95: PRAGMA_DIAG_POP > > One of these is another of the symbol_at_put cases that I don't understand. Are there other cases in the switch that warn? And if so, which ones and how? There are no details of this one in the PR cover description. Most of switch cases are warned. Please see [logs](https://github.com/openjdk/jdk/files/8708578/hotspot_variant-server_libjvm_objs_bytecodeAssembler.o.log) ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From azvegint at openjdk.java.net Tue May 17 13:31:48 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 17 May 2022 13:31:48 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:02:49 GMT, Alexey Ivanov wrote: > Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). > > Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. > > To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From ysuenaga at openjdk.java.net Tue May 17 13:32:42 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: revert changes for memnode.cpp and type.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/73c306d7..88cbf46d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05-06 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:43 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 04:52:44 GMT, Kim Barrett wrote: >> src/hotspot/share/opto/memnode.cpp line 1413: >> >>> 1411: bt == T_BYTE || bt == T_SHORT || >>> 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); >>> 1413: PRAGMA_DIAG_POP >> >> The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. > > While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong. The warning has gone in new commit, and I fixed the comment for `type2name_tab` in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <-VtXM4fP_wQp_OWiDuU5FmEvFfDK8Y6_lJ7xHI2doYM=.0a7e6002-9b6a-4bdd-b508-7510fe82230c@github.com> On Tue, 17 May 2022 03:06:49 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/opto/type.cpp line 4300: > >> 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED >> 4299: fatal("not an element type: %s", type2name(etype)); >> 4300: PRAGMA_DIAG_POP > > Another occurrence of type2name returning NULL for unknown BasicType. The warning has gone in new commit due to change of `type2name`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From michal.babacek at gmail.com Tue May 17 14:04:46 2022 From: michal.babacek at gmail.com (Michal Karm) Date: Tue, 17 May 2022 16:04:46 +0200 Subject: JDK-8274735, JPEG compression in a TIFF container, openjdk/jdk/pull/7849 Message-ID: <4b94671b-6cb3-0ff3-a646-018e7cf33ba4@gmail.com> Hello, There used to be an Unsupported Image Type exception thrown when one wanted to decode a TIFF container with JPEG compressed image. That behavior has changed, there is no exception now, although the resulting image is incorrect. I outlined the details in this doc [1], including a small reproducer. The test image is not anything from a fuzzer, it's just me clicking Export As in GIMP. Thanks for feedback Cheers Karm [1] https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md Karm Michal Babacek -- Sent from my Hosaka Ono-Sendai Cyberspace 7 From mvs at openjdk.java.net Tue May 17 15:59:11 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Tue, 17 May 2022 15:59:11 GMT Subject: RFR: 8286822: Write a test to check the DND functionality between two InternalFrames Message-ID: This test verifies that dragging from one InternalFrame and a drop target in another InternalFrame functions properly. This fix moves an unstable closed applet based test to open regression based java test, but updated to be more comprehensive with some stabilisation improvements. The closed test was creating noise in CI as it often fails in Windows platform, especially in Windows 11. Testing: 1. Tested using mach5 20 times per platform and got all Pass. 2. Tested using mach5 5 times specifically on Windows 11 and got all Pass. ------------- Commit messages: - 8286822: Write a test to check the DND functionality between two InternalFrames Changes: https://git.openjdk.java.net/jdk/pull/8753/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8753&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286822 Stats: 384 lines in 1 file changed: 384 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8753.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8753/head:pull/8753 PR: https://git.openjdk.java.net/jdk/pull/8753 From duke at openjdk.java.net Tue May 17 16:29:42 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Tue, 17 May 2022 16:29:42 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v11] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: formatting changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/268abbfb..d938e44c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=09-10 Stats: 6 lines in 1 file changed: 4 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Tue May 17 18:29:44 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Tue, 17 May 2022 18:29:44 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v12] In-Reply-To: References: Message-ID: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: test case instructions updated ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8441/files - new: https://git.openjdk.java.net/jdk/pull/8441/files/d938e44c..59cf0fc8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8441&range=10-11 Stats: 19 lines in 1 file changed: 5 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8441/head:pull/8441 PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Tue May 17 18:35:03 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 18:35:03 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v12] In-Reply-To: References: Message-ID: <6vIi0hKIdou7RkKsfHD4kgznP7dzy7dA1lomcwP7WTY=.15b15ccf-4954-48cc-ac80-314bcf2e06e6@github.com> On Tue, 17 May 2022 18:29:44 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test case instructions updated Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From philip.race at oracle.com Tue May 17 18:36:09 2022 From: philip.race at oracle.com (Philip Race) Date: Tue, 17 May 2022 11:36:09 -0700 Subject: Unexpected EOFException in ImageReaderSpi.canDecodeInput In-Reply-To: <5f1eed65-78a6-f7a5-ed6b-a6c5bb09a106@geomatys.com> References: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> <5f1eed65-78a6-f7a5-ed6b-a6c5bb09a106@geomatys.com> Message-ID: Why is it unexpected ? The method declares that it throws IOException .. which if thrown clearly means the stream can't be de-coded. Perhaps your point is that this then prevents control reaching the reset, so that the next plugin doesn't get its turn to also reject the truncated file. I suppose I can see that might be a reasonable thing to do in the event there's some image format that has a large read requirement for the header validation and that the following plugin may see that there's a small valid image ? But this fix is still putting it on each plugin to behave itself .. and we already handle that in the ImageIO class although I think it isn't perfect, as it still relies on co-operation with regard to mark() And if you call this directly, you can handle that just as well yourself .. and still can't trust extra plugins to behave ..,. so what is the use case for this fix ? -phil. On 5/17/22 5:48 AM, Martin Desruisseaux wrote: > Hello > > I prepared a pull request at [1] for fixing an unexpected EOFException > thrown by ImageReaderSpi.canDecodeInput(Object) in JDK implementations > for BMP, WBMP, GIF, PNG and TIFF formats (JPEG is not impacted). This > exception occurs when the stream has less than 8 bytes. For example, > it occurs when probing all files in a directory if that directory > contains empty files. > > If believe that in order to process, a bug report must be filled on > https://bugs.openjdk.java.net/ ? Can someone hint me about how to do > that (since I can not create a report myself)? > > ??? Regards, > > ??? ??? Martin > > [1]https://github.com/openjdk/jdk/pull/8700 From duke at openjdk.java.net Tue May 17 18:58:59 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Tue, 17 May 2022 18:58:59 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v3] In-Reply-To: References: Message-ID: <-ndDe5uyfqLylerX9o-qUpPARXVi-K5_Bt7wEhiwW4s=.35d61bcb-4e68-4655-b49c-7f2c8bb0bca5@github.com> On Wed, 11 May 2022 18:57:00 GMT, Phil Race wrote: >>> @aivanov-jdk were both windows 10 and windows 11 using the same pipeline ? (meaning GDI or D3D). Otherwise on our side I'd expect all the same code path .. >> >> Good question. The output from `WindowsFlags` is the same on both machines: >> >> WindowsFlags (Java): >> d3dEnabled: true >> d3dSet: false >> oglEnabled: false >> oglVerbose: false >> gdiBlitEnabled: true >> offscreenSharingEnabled: false >> >> Setting `-Dsun.java2d.d3d=True` produces >> >> Direct3D pipeline enabled on screen 0 >> >> in both cases. >> >> Disabling Direct3D with `-Dsun.java2d.d3d=false` changes nothing. > >>>Disabling Direct3D with -Dsun.java2d.d3d=false changes nothing. > > That rules out a pipeline issue so I've no idea. > Fortunately Windows 11 still has lower adoption than Windows XP usage :-) That's a real stat btw. @prrace This PR might require a re-review and re-approval on the latest commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Tue May 17 19:19:42 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 19:19:42 GMT Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java [v5] In-Reply-To: References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> Message-ID: On Fri, 29 Apr 2022 20:37:30 GMT, lawrence.andrews wrote: >> 1) Fixed Parser error by removing yesno from @run main/manual=yesno >> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. >> 3) If printer is not configured then mark the test as passed. >> >> @shurymury >> @aivanov-jdk > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Added jtreg.SkippedException > - Added jtreg.SkippedException Can't we use existing `jtreg.SkippedException` in `test/lib`? Modify PageRangesDlgTest: diff --git a/test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java b/test/jdk/java/awt/print/Pri nterJob/PageRangesDlgTest.java index 77be99107d1..0d8ce30057a 100644 --- a/test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java +++ b/test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java @@ -37,9 +37,9 @@ import jtreg.SkippedException; * @bug 8061267 * @key printer * @library /java/awt/regtesthelpers - * @library /java/awt/jtreg + * @library /test/lib * @build PassFailJFrame - * @build SkippedException + * @build jtreg.SkippedException * @summary The specified page range should be displayed in the dialog * @run main/manual PageRangesDlgTest */ The test can't pass when the native Print dialog is displayed: `aset` should be passed to it: @@ -58,7 +58,7 @@ public class PageRangesDlgTest implements Printable { job = PrinterJob.getPrinterJob(); job.setPrintable(new PageRangesDlgTest()); aset.add(DialogTypeSelection.NATIVE); - if (job.printDialog()) { + if (job.printDialog(aset)) { job.print(); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8412 From aivanov at openjdk.java.net Tue May 17 19:23:47 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 19:23:47 GMT Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java [v5] In-Reply-To: References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> Message-ID: On Fri, 29 Apr 2022 20:37:30 GMT, lawrence.andrews wrote: >> 1) Fixed Parser error by removing yesno from @run main/manual=yesno >> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. >> 3) If printer is not configured then mark the test as passed. >> >> @shurymury >> @aivanov-jdk > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Added jtreg.SkippedException > - Added jtreg.SkippedException Changes requested by aivanov (Reviewer). test/jdk/java/awt/print/PrinterJob/PageRangesDlgTest.java line 67: > 65: > 66: public static void main(String[] args) throws Exception { > 67: if (PrinterJob.lookupPrintServices().length > 0) { The inverted condition produces cleaner code with less indentation: if (PrinterJob.lookupPrintServices().length == 0) { throw new SkippedException("Printer not configured or available." + " Test cannot continue."); } // Rest of the test code ------------- PR: https://git.openjdk.java.net/jdk/pull/8412 From prr at openjdk.java.net Tue May 17 19:45:38 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 17 May 2022 19:45:38 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v12] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 18:29:44 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test case instructions updated Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From philip.race at oracle.com Tue May 17 19:52:24 2022 From: philip.race at oracle.com (Philip Race) Date: Tue, 17 May 2022 12:52:24 -0700 Subject: JDK-8274735, JPEG compression in a TIFF container, openjdk/jdk/pull/7849 In-Reply-To: <4b94671b-6cb3-0ff3-a646-018e7cf33ba4@gmail.com> References: <4b94671b-6cb3-0ff3-a646-018e7cf33ba4@gmail.com> Message-ID: <82f5f75e-cf0f-d447-ce58-0cacf00dcb6e@oracle.com> This could be a bug in the TIFF plugin. Hard to say without debugging it. -phil. On 5/17/22 7:04 AM, Michal Karm wrote: > Hello, > > There used to be an Unsupported Image Type exception thrown > when one wanted to decode a TIFF container with JPEG compressed image. > > That behavior has changed, there is no exception now, although the > resulting image is incorrect. > > I outlined the details in this doc [1], including a small reproducer. > > The test image is not anything from a fuzzer, it's just me > clicking Export As in GIMP. > > Thanks for feedback > > Cheers > Karm > > > [1] > https://urldefense.com/v3/__https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md__;!!ACWV5N9M2RV99hQ!Kw41ShsuTSfpVPMZFrXmdQ7ZETNdkLTk9Xd1NDWELvCXV0fyIqg4sXi5Z1aYfjMoG-5fS0gki8dnN8bQjSYM0g$ > > > Karm Michal Babacek > From aivanov at openjdk.java.net Tue May 17 20:03:44 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 20:03:44 GMT Subject: RFR: 8282526: Default icon is not painted properly [v3] In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 22:06:09 GMT, Alexander Zuev wrote: >> Detect the situation where we do need to perform interpolation during ImageIcon >> painting and set a hint to the rendering to perform bicubic approximation so >> image details are preserved during transition. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Take into account scale factor; > Create a new Graphics2D object instead of juggle the rendering hints; It could be that the new API that we use on Windows ignores the passed in size and returns the icon of the default size. If possible, we should explore options to make this work correctly. Is a test case available for that? Do I simply start JFileChooser on standard screen which uses 100% scale and look for files without a defined type? On the other hand, @azuev-java demonstrates the problem exists in general: if an icon is scaled down, it may lose relevant details and become white square ? it doesn't look good, does it? It's possible to give user/programmer control by adding a property: if it's defined, ImageIcon paints as before without switching to bicubic interpolation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7805 From prr at openjdk.java.net Tue May 17 20:36:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 17 May 2022 20:36:50 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 10 May 2022 19:52:41 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > renamed test, renamed some methods, updated error messages, updated test Changes requested by prr (Reviewer). src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 132: > 130: private void paintBorderShadow(Graphics g, Color c, int w, int h, int stkWidth) { > 131: g.setColor(c); > 132: g.drawLine((3*stkWidth/2), h-(3*stkWidth/2), (3*stkWidth/2), (3*stkWidth/2)); // left line what do you want to be the order of operations here ((3*stkWidth)/2) or (3*(stkWidth/2) ? Make it clear with parens. src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 159: > 157: int stkWidth = 1; > 158: if (g instanceof Graphics2D) { > 159: at = ((Graphics2D) g).getTransform(); We more usually write Graphics2D g2d = (Graphics2D)g then just use g2d instead of repeated casting. src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 164: > 162: stkWidth = (int) Math.floor(Math.min(at.getScaleX(),at.getScaleY())); > 163: ((Graphics2D) g).setStroke(new BasicStroke((float) stkWidth)); > 164: } This reminds me .. did you try STROKE_PURE ? If so does it make any difference ? https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/RenderingHints.html#KEY_STROKE_CONTROL src/java.desktop/share/classes/javax/swing/border/TitledBorder.java line 37: > 35: import java.awt.geom.Path2D; > 36: import java.beans.ConstructorProperties; > 37: import java.beans.PropertyChangeListener; Is removing an unused import the only change to TitledBorder ? I think you should revert this to make the change cleaner. test/jdk/java/awt/TitledBorder/ScaledEtchedBorderTest.java line 9: > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided > 9: * by Oracle in the LICENSE file that accompanied this code. This is wrong .. we do not put the classpath exception on tests. test/jdk/java/awt/TitledBorder/ScaledEtchedBorderTest.java line 80: > 78: try { > 79: UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel"); > 80: } catch (Exception e) { Can we instead call (https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/UIManager.html#getSystemLookAndFeelClassName()) Actually I'm not sure why only Win L&F is tested .. it is cross-platform and cross L&F code being changed test/jdk/java/awt/TitledBorder/ScaledEtchedBorderTest.java line 237: > 235: } else { > 236: frame.dispose(); > 237: } That looks odd. I mean if you show the frame, how is it disposed ? And more broadly ... why do you even create the frame if you never show it ? And if you don't create the frame, this test can be headless, can't it ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Tue May 17 20:36:50 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 20:36:50 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 10 May 2022 19:52:41 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > renamed test, renamed some methods, updated error messages, updated test [As discussed](https://github.com/openjdk/jdk/pull/8441#pullrequestreview-972614622) in #8441, the changes to `TitledBorder.java` should be reverted as unrelated. src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 162: > 160: ((Graphics2D) g).setTransform(new AffineTransform()); > 161: oldStk = ((Graphics2D) g).getStroke(); > 162: stkWidth = (int) Math.floor(Math.min(at.getScaleX(),at.getScaleY())); Suggestion: stkWidth = (int) Math.floor(Math.min(at.getScaleX(), at.getScaleY())); src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 178: > 176: w, h, stkWidth); > 177: paintBorderHighlight(g, (etchType == LOWERED) ? getShadowColor(c) > 178: : getHighlightColor(c), After you updated the name of the method, `:` isn't aligned to `?`. test/jdk/java/awt/TitledBorder/ScaledEtchedBorderTest.java line 112: > 110: boolean checkHighlight = false; > 111: for (int x = 0; x < img.getWidth(); x++) { > 112: int color = img.getRGB(x,y); Suggestion: int color = img.getRGB(x, y); test/jdk/java/awt/TitledBorder/ScaledEtchedBorderTest.java line 158: > 156: boolean checkHighlight = false; > 157: for (int y = 0; y < img.getHeight(); y++) { > 158: int color = img.getRGB(x,y); Suggestion: int color = img.getRGB(x, y); ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Tue May 17 20:36:52 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 17 May 2022 20:36:52 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 17 May 2022 20:18:33 GMT, Phil Race wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed test, renamed some methods, updated error messages, updated test > > test/jdk/java/awt/TitledBorder/ScaledEtchedBorderTest.java line 237: > >> 235: } else { >> 236: frame.dispose(); >> 237: } > > That looks odd. I mean if you show the frame, how is it disposed ? > > And more broadly ... why do you even create the frame if you never show it ? > And if you don't create the frame, this test can be headless, can't it ? Perhaps you are trying to get layout to happen ? That should be possible but it might be tricky. But I think if you are going so far as pack() and can't change that, then show the frame regardless. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Tue May 17 20:42:04 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 20:42:04 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 17 May 2022 20:25:22 GMT, Phil Race wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed test, renamed some methods, updated error messages, updated test > > src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 159: > >> 157: int stkWidth = 1; >> 158: if (g instanceof Graphics2D) { >> 159: at = ((Graphics2D) g).getTransform(); > > We more usually write > Graphics2D g2d = (Graphics2D)g > > then just use g2d instead of repeated casting. This could even use pattern matching: if (g instanceof Graphics2D g2d) { at = g2d.getTransform(); ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Tue May 17 20:46:55 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 17 May 2022 20:46:55 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 17 May 2022 20:20:46 GMT, Phil Race wrote: >> test/jdk/java/awt/TitledBorder/ScaledEtchedBorderTest.java line 237: >> >>> 235: } else { >>> 236: frame.dispose(); >>> 237: } >> >> That looks odd. I mean if you show the frame, how is it disposed ? >> >> And more broadly ... why do you even create the frame if you never show it ? >> And if you don't create the frame, this test can be headless, can't it ? > > Perhaps you are trying to get layout to happen ? That should be possible but it might be tricky. > But I think if you are going so far as pack() and can't change that, then show the frame regardless. Right, JPanel isn't laid out without being added to a peered component. Maybe setting explicit positions to child panels will work, then the test can be headless. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From vladislav.volodin at sap.com Wed May 18 08:04:41 2022 From: vladislav.volodin at sap.com (Volodin, Vladislav) Date: Wed, 18 May 2022 08:04:41 +0000 Subject: Unexpected EOFException in ImageReaderSpi.canDecodeInput In-Reply-To: References: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> <5f1eed65-78a6-f7a5-ed6b-a6c5bb09a106@geomatys.com> Message-ID: Hello Philip, I have never used this object, but according to JavaDocs it says that IOException is thrown "if an I/O error occurs while reading the stream". So in theory, if we can read the file, but its size is less than we expect (e.g. a magic number length), why cannot we simply return "false" instead of throwing an exception? We can read the file, but it is small... Isn't it a purpose of all "canXXXX" methods to return Boolean when expecting something, and throwing an exception under unpredictable circumstances? For example, File.canRead / File.canWrite don't throw an exception. Probably this is a bad example, and there maybe other examples that demonstrate a different result. Kind regards, Vlad -----Original Message----- From: client-libs-dev On Behalf Of Philip Race Sent: Dienstag, 17. Mai 2022 20:36 To: Martin Desruisseaux ; client-libs-dev at openjdk.java.net Subject: Re: Unexpected EOFException in ImageReaderSpi.canDecodeInput Why is it unexpected ? The method declares that it throws IOException .. which if thrown clearly means the stream can't be de-coded. Perhaps your point is that this then prevents control reaching the reset, so that the next plugin doesn't get its turn to also reject the truncated file. I suppose I can see that might be a reasonable thing to do in the event there's some image format that has a large read requirement for the header validation and that the following plugin may see that there's a small valid image ? But this fix is still putting it on each plugin to behave itself .. and we already handle that in the ImageIO class although I think it isn't perfect, as it still relies on co-operation with regard to mark() And if you call this directly, you can handle that just as well yourself .. and still can't trust extra plugins to behave ..,. so what is the use case for this fix ? -phil. On 5/17/22 5:48 AM, Martin Desruisseaux wrote: > Hello > > I prepared a pull request at [1] for fixing an unexpected EOFException > thrown by ImageReaderSpi.canDecodeInput(Object) in JDK implementations > for BMP, WBMP, GIF, PNG and TIFF formats (JPEG is not impacted). This > exception occurs when the stream has less than 8 bytes. For example, > it occurs when probing all files in a directory if that directory > contains empty files. > > If believe that in order to process, a bug report must be filled on > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2F&data=05%7C01%7Cvladislav.volodin%40sap.com%7Ca6be9a838e654ba01c1b08da38342f9f%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884094036465515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s1VG8nCH9pJKY65IwOYcvKK%2Bk0QnLmLRol%2BJIdPOfTs%3D&reserved=0 ? Can someone hint me about how to do > that (since I can not create a report myself)? > > ??? Regards, > > ??? ??? Martin > > [1]https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fpull%2F8700&data=05%7C01%7Cvladislav.volodin%40sap.com%7Ca6be9a838e654ba01c1b08da38342f9f%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637884094036465515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=r%2BR8qM4b8BHMiFSN2vF2nEsLSZAbUFagi5BY3pLnJzE%3D&reserved=0 From smandalika at openjdk.java.net Wed May 18 08:20:47 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 18 May 2022 08:20:47 GMT Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v3] In-Reply-To: References: Message-ID: > Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286) > > AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection. > When cell selection is not enabled, there is no way, using > accessibility, to select rows or columns. It seems logical that selecting a cell > using accessibility should have the same effect as clicking on a cell with the > mouse. That is, if row or column selection is enabled, then selecting a cell > should instead cause the row or column to be selected. > The proposed test verifies that the above behavior is fixed. > > This review is for migrating tests from a closed test suite to open. > > Testing: > The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review comments fixed: moved the file directly under the a11y folder ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8333/files - new: https://git.openjdk.java.net/jdk/pull/8333/files/98c96eb4..ba645346 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8333&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8333&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8333/head:pull/8333 PR: https://git.openjdk.java.net/jdk/pull/8333 From smandalika at openjdk.java.net Wed May 18 08:20:47 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 18 May 2022 08:20:47 GMT Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 23:58:01 GMT, Phil Race wrote: > Get rid of the useless extra directory level Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8333 From smandalika at openjdk.java.net Wed May 18 08:20:48 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 18 May 2022 08:20:48 GMT Subject: RFR: 8285305: Create an automated test for JDK-4495286 [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 08:08:32 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4495286](https://bugs.openjdk.java.net/browse/JDK-4495286) >> >> AccessibleJTable.setAccessibleSelction should select rows/cols when cell selection. >> When cell selection is not enabled, there is no way, using >> accessibility, to select rows or columns. It seems logical that selecting a cell >> using accessibility should have the same effect as clicking on a cell with the >> mouse. That is, if row or column selection is enabled, then selecting a cell >> should instead cause the row or column to be selected. >> The proposed test verifies that the above behavior is fixed. >> >> This review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (40) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review comments fixed: Typo in Copyright Header Hi! Can someone please take a look at this PR and provide their valuable feedback & approval? ------------- PR: https://git.openjdk.java.net/jdk/pull/8333 From smandalika at openjdk.java.net Wed May 18 08:37:03 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 18 May 2022 08:37:03 GMT Subject: RFR: 8284767: Create an automated test for JDK-4422535 [v3] In-Reply-To: References: Message-ID: <3rXFVh7JvLK-ycYNRlmK8tTqTpmrs7GuF0lxiaO78kQ=.9f972f36-f57f-4cf1-a2d8-58feba441f71@github.com> > Create an automated test for [JDK-4422535](https://bugs.openjdk.java.net/browse/JDK-4422535) > AccessibleValue implementation only accept Integers > The AccessibleValue implementations of the following components: > > java.awt.Scrollbar > javax.swing.AbstractButton > javax.swing.JInternalFrame > javax.swing.JSplitPane > javax.swing.JScrollBar > javax.swing.JProgressBar > javax.swing.JSlider > > require the argument to setCurrentAccessibleValue(Number) to be an Integer, else they completely ignore it - it returns a false indicating that the value has not been set by the return value, but they cannot know the reason for that). > > The test verifies that for each of the above components, the AccessibleValue is set when it is set to a Number (Float, Double, long etc) and not just for an Integer. > > his review is for migrating tests from a closed test suite to open. > > Testing: > The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review Comments Fixed: Fixed File location path. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8220/files - new: https://git.openjdk.java.net/jdk/pull/8220/files/8536a648..4a57e660 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8220&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8220&range=01-02 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8220.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8220/head:pull/8220 PR: https://git.openjdk.java.net/jdk/pull/8220 From smandalika at openjdk.java.net Wed May 18 08:38:49 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 18 May 2022 08:38:49 GMT Subject: RFR: 8284524: Create an automated test for JDK-4422362 [v3] In-Reply-To: References: Message-ID: > Create an automated test for [JDK-4422362](https://bugs.openjdk.java.net/browse/JDK-4422362) > > The BoundedRangeModel components (JScrollBar, JSlider, JProgressBar) return > BoundedRangeModel.getMaximum() from getMaximumAccessibleValue() in their > AccessibleValue implementation. > The real maximum value (due to the constraints on BoundedRangeModel) is > model.getMaximum() - model.getExtent(). > > The test verifies that the above is adhered to as expected. > > This review is for migrating tests from a closed test suite to open. > > Testing: > The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review Comments Fixed: Fixed File location path. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8158/files - new: https://git.openjdk.java.net/jdk/pull/8158/files/0dd792c1..33d7b2b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8158&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8158&range=01-02 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8158.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8158/head:pull/8158 PR: https://git.openjdk.java.net/jdk/pull/8158 From martin.desruisseaux at geomatys.com Wed May 18 09:47:20 2022 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Wed, 18 May 2022 11:47:20 +0200 Subject: Unexpected EOFException in ImageReaderSpi.canDecodeInput In-Reply-To: References: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> <5f1eed65-78a6-f7a5-ed6b-a6c5bb09a106@geomatys.com> Message-ID: <0376c10d-d9f6-d28c-8bad-776307d6724f@geomatys.com> Hello Philip Le 17/05/2022 ? 20:36, Philip Race a ?crit?: > Why is it unexpected ? > The purpose of ImageReaderSpi.canDecodeInput(Object) is to tell if the source object seems to be supported by the reader. If the file is too small, it is not supported by the reader. So a return value of false is what I would expect from the method contract, because the method is capable to provide a clear answer to the question "does it seems a valid file?" By contrast, I would expect IOException to be thrown only if an unexpected error prevents canDecodeInput(Object) from fulfilling its method contract, e.g. a lost of internet connection prevents the reader to check the magic number. EOFException does not met that criterion for the reason stated above. > The method declares that it throws IOException .. which if thrown > clearly means the stream can't be de-coded. > In my understanding of the method contract, if the stream can not be decoded, this is indicated by a return value of false rather than an IOException. In the context of ImageReaderSpi.canDecodeInput(Object), I interpret IOException as an error that prevent the method from answering the question "does it seems a valid file?" > But this fix is still putting it on each plugin to behave itself .. > and we already handle that in the ImageIO class > although I think it isn't perfect, as it still relies on co-operation > with regard to mark() > > And if you call this directly, you can handle that just as well > yourself .. and still can't trust extra > plugins to behave ..,. so what is the use case for this fix ? In my case I handle the search of ImageReader myself. Contrarily to ImageIO I do not catch IOException, because it may be a serious error that prevent the plugin from answering its question. The stream may now be in a corrupted state (it is not always a local file; it can be on the cloud, a database BLOB, etc), and continuing with other readers after the initial error can cause a series of confusing error messages. Instead I let the first IOException propagates. The meaning is very different than "unsupported format". I could catch the specific case of EOFException, but I don't because 1) it relies on assumptions about how the plugin behave, 2) the input may be an object other than ImageInputStream that we don't know how to mark, and 3) EOFException can in some circumstances be a serious error (i.e. EOFException occurring not in the stream given to the canDecodeInput(Object) method, but is some auxiliary file that the plugin needs to read). Only the plugin knows for sure if EOFException means "unsupported format" or "serious error". ??? Regards, ?? ???? Martin From smandalika at openjdk.java.net Wed May 18 10:04:53 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 18 May 2022 10:04:53 GMT Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v5] In-Reply-To: References: Message-ID: > Create a regression test for JDK-4699544 > > The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs. > > The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately. > The test added verifies the same. > This review is for migrating tests from a closed test suite to open. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review Comments Fixed: Fixed File location path. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7739/files - new: https://git.openjdk.java.net/jdk/pull/7739/files/15bc3210..aae05a20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7739&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7739&range=03-04 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7739.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7739/head:pull/7739 PR: https://git.openjdk.java.net/jdk/pull/7739 From smandalika at openjdk.java.net Wed May 18 10:09:30 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Wed, 18 May 2022 10:09:30 GMT Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v4] In-Reply-To: References: Message-ID: > Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031) > > The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser. > The test added verifies the same. > This review is for migrating tests from a closed test suite to open. Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: Review Comments Fixed: Fixed File location path. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7738/files - new: https://git.openjdk.java.net/jdk/pull/7738/files/76db0fa6..2dc9771d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7738&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7738&range=02-03 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7738.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7738/head:pull/7738 PR: https://git.openjdk.java.net/jdk/pull/7738 From prr at openjdk.java.net Wed May 18 10:37:18 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 18 May 2022 10:37:18 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: <5_UNIzVE-hMMkzpBv8JgACfd6d1ZsaekSEzWWDbXj3U=.3ba15bea-c389-4d66-a098-c4deac16841f@github.com> On Tue, 17 May 2022 20:38:07 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 159: >> >>> 157: int stkWidth = 1; >>> 158: if (g instanceof Graphics2D) { >>> 159: at = ((Graphics2D) g).getTransform(); >> >> We more usually write >> Graphics2D g2d = (Graphics2D)g >> >> then just use g2d instead of repeated casting. > > This could even use pattern matching: > > if (g instanceof Graphics2D g2d) { > at = g2d.getTransform(); I thought about that but (1) couldn't remember off-hand if it was still preview, (2) I was sure it would impede a backport ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Wed May 18 10:37:19 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 10:37:19 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: <5_UNIzVE-hMMkzpBv8JgACfd6d1ZsaekSEzWWDbXj3U=.3ba15bea-c389-4d66-a098-c4deac16841f@github.com> References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> <5_UNIzVE-hMMkzpBv8JgACfd6d1ZsaekSEzWWDbXj3U=.3ba15bea-c389-4d66-a098-c4deac16841f@github.com> Message-ID: On Tue, 17 May 2022 20:59:37 GMT, Phil Race wrote: >> This could even use pattern matching: >> >> if (g instanceof Graphics2D g2d) { >> at = g2d.getTransform(); > > I thought about that but (1) couldn't remember off-hand if it was still preview, (2) I was sure it would impede a backport ... [JEP 394: Pattern Matching for instanceof](https://openjdk.java.net/jeps/394) was delivered in JDK 16, I've seen it used a few times in JDK code. It would impede backporting to JDK 11. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Wed May 18 12:22:43 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 12:22:43 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v2] In-Reply-To: References: Message-ID: > Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). > > Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. > > To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: 8286872: Replace SendTrayMessage(NIM_MODIFY) with ModifyTrayIcon() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8749/files - new: https://git.openjdk.java.net/jdk/pull/8749/files/2e85731c..67625852 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8749&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8749&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8749/head:pull/8749 PR: https://git.openjdk.java.net/jdk/pull/8749 From kcr at openjdk.java.net Wed May 18 12:46:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 18 May 2022 12:46:06 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v12] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 18:29:44 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test case instructions updated Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From aivanov at openjdk.java.net Wed May 18 14:06:14 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 14:06:14 GMT Subject: RFR: 8284213: Replace usages of 'a the' in xml Message-ID: Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? I tried to avoid changing external libraries, there are quite a few such typos. Let me know if I should revert any files. ------------- Commit messages: - 8284213: Replace usages of 'the a' in xml - 8284213: Replace usages of 'the the' in xml - 8284213: Replace usages of 'the the' in xml - 8284213: Replace usages of 'the the' in xml - 8284213: Replace usages of 'an? an?' in xml Changes: https://git.openjdk.java.net/jdk/pull/8769/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8769&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284213 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8769/head:pull/8769 PR: https://git.openjdk.java.net/jdk/pull/8769 From lancea at openjdk.java.net Wed May 18 14:47:56 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 18 May 2022 14:47:56 GMT Subject: RFR: 8284213: Replace usages of 'a the' in xml In-Reply-To: References: Message-ID: <84WIsg1mRZYleHRSABqIypeQmbgGl-TOSdX8qnbKFIE=.0f21a12c-ac80-4473-9d23-2d4d3d24f822@github.com> On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > I tried to avoid changing external libraries, there are quite a few such typos. > Let me know if I should revert any files. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8769 From dmarkov at openjdk.java.net Wed May 18 15:07:48 2022 From: dmarkov at openjdk.java.net (Dmitry Markov) Date: Wed, 18 May 2022 15:07:48 GMT Subject: RFR: 8284213: Replace usages of 'a the' in xml In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > I tried to avoid changing external libraries, there are quite a few such typos. > Let me know if I should revert any files. Marked as reviewed by dmarkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8769 From duke at openjdk.java.net Wed May 18 16:24:38 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Wed, 18 May 2022 16:24:38 GMT Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for ava/awt/print/PrinterJob/PageRangesDlgTest.java [v6] In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> Message-ID: <-9FDaG9KnpVU2iGAUsnXLeFgWksYQceiXD0Pf1Tlajc=.fc3be673-cba1-412b-8635-3a53a3ca7c58@github.com> > 1) Fixed Parser error by removing yesno from @run main/manual=yesno > 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. > 3) If printer is not configured then mark the test as passed. > > @shurymury > @aivanov-jdk lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: - Removed SkippedException.java - Used the existing SkippedException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8412/files - new: https://git.openjdk.java.net/jdk/pull/8412/files/44f8aee3..1c4c2280 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8412&range=04-05 Stats: 75 lines in 2 files changed: 15 ins; 56 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8412/head:pull/8412 PR: https://git.openjdk.java.net/jdk/pull/8412 From iris at openjdk.java.net Wed May 18 16:44:49 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 May 2022 16:44:49 GMT Subject: RFR: 8284213: Replace usages of 'a the' in xml In-Reply-To: References: Message-ID: <7fkS7t7YAVxAGVO7abeDDMweepFcoOD-DiooZpdLpQ0=.f70a04e9-9206-426d-a81f-2cc1510ec790@github.com> On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > I tried to avoid changing external libraries, there are quite a few such typos. > Let me know if I should revert any files. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8769 From prr at openjdk.java.net Wed May 18 16:49:40 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 18 May 2022 16:49:40 GMT Subject: RFR: 8284213: Replace usages of 'a the' in xml In-Reply-To: References: Message-ID: <7k0T22HtUdVnlTISxOlZ0gNxLdS6HZTgmkbwpAd4o7c=.e23eb78f-982d-43e6-a7a2-165834a34474@github.com> On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > I tried to avoid changing external libraries, there are quite a few such typos. > Let me know if I should revert any files. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8769 From prr at openjdk.java.net Wed May 18 16:56:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 18 May 2022 16:56:50 GMT Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PageRangesDlgTest.java [v6] In-Reply-To: <-9FDaG9KnpVU2iGAUsnXLeFgWksYQceiXD0Pf1Tlajc=.fc3be673-cba1-412b-8635-3a53a3ca7c58@github.com> References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> <-9FDaG9KnpVU2iGAUsnXLeFgWksYQceiXD0Pf1Tlajc=.fc3be673-cba1-412b-8635-3a53a3ca7c58@github.com> Message-ID: <4ZL3qr34Foy7cBGx72GgilwUkDVKniG-djxh9-gah0M=.2b5d4196-cf12-465a-a7fa-f9bb2a7e6625@github.com> On Wed, 18 May 2022 16:24:38 GMT, lawrence.andrews wrote: >> 1) Fixed Parser error by removing yesno from @run main/manual=yesno >> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. >> 3) If printer is not configured then mark the test as passed. >> >> @shurymury >> @aivanov-jdk > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Removed SkippedException.java > - Used the existing SkippedException Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8412 From joehw at openjdk.java.net Wed May 18 16:59:49 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 18 May 2022 16:59:49 GMT Subject: RFR: 8284213: Replace usages of 'a the' in xml In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > I tried to avoid changing external libraries, there are quite a few such typos. > Let me know if I should revert any files. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8769 From prr at openjdk.java.net Wed May 18 17:15:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 18 May 2022 17:15:49 GMT Subject: Integrated: 8285397: JNI exception pending in CUPSfuncs.c:250 In-Reply-To: References: Message-ID: On Sun, 1 May 2022 19:31:01 GMT, Phil Race wrote: > A tool checking for JNI errors complains that the call to JNU_NewStringPlatform(..) > might throw an exception and subsequent JNI code isn't making sure of that. > Clear the exception so the error handling code can do its thing. This pull request has now been integrated. Changeset: a03438cb Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/a03438cb1b915c89739fc974e5b84adc38bd14bf Stats: 16 lines in 1 file changed: 10 ins; 0 del; 6 mod 8285397: JNI exception pending in CUPSfuncs.c:250 Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/8491 From prr at openjdk.java.net Wed May 18 17:21:59 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 18 May 2022 17:21:59 GMT Subject: Integrated: 8283705: Make javax.sound.midi.Track a final class In-Reply-To: References: Message-ID: On Sun, 1 May 2022 21:15:33 GMT, Phil Race wrote: > This is the straggler from several PRs which were around making JDK classes sealed. > There's nothing to be sealed here, but the same query pointed out that this class has > no public or protected constructor (as well as no sub-classes) and so can be made final > > CSR for review here https://bugs.openjdk.java.net/browse/JDK-8285978 This pull request has now been integrated. Changeset: 9becf7d5 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/9becf7d5780860a92e018638dafb1b0a02b07048 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8283705: Make javax.sound.midi.Track a final class Reviewed-by: psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/8492 From aivanov at openjdk.java.net Wed May 18 17:51:44 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 17:51:44 GMT Subject: RFR: 8285687 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PageRangesDlgTest.java [v6] In-Reply-To: <-9FDaG9KnpVU2iGAUsnXLeFgWksYQceiXD0Pf1Tlajc=.fc3be673-cba1-412b-8635-3a53a3ca7c58@github.com> References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> <-9FDaG9KnpVU2iGAUsnXLeFgWksYQceiXD0Pf1Tlajc=.fc3be673-cba1-412b-8635-3a53a3ca7c58@github.com> Message-ID: On Wed, 18 May 2022 16:24:38 GMT, lawrence.andrews wrote: >> 1) Fixed Parser error by removing yesno from @run main/manual=yesno >> 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. >> 3) If printer is not configured then mark the test as passed. >> >> @shurymury >> @aivanov-jdk > > lawrence.andrews has updated the pull request incrementally with two additional commits since the last revision: > > - Removed SkippedException.java > - Used the existing SkippedException Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8412 From aivanov at openjdk.java.net Wed May 18 17:54:30 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 17:54:30 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v3] In-Reply-To: References: Message-ID: > Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). > > Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. > > To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision: - Inline AddTrayIcon and ModifyTrayIcon - Make SendTrayMessage private - it's used internally only ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8749/files - new: https://git.openjdk.java.net/jdk/pull/8749/files/67625852..52f5ecae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8749&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8749&range=01-02 Stats: 28 lines in 2 files changed: 11 ins; 15 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8749/head:pull/8749 PR: https://git.openjdk.java.net/jdk/pull/8749 From aivanov at openjdk.java.net Wed May 18 18:00:45 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 18:00:45 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v3] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 17:54:30 GMT, Alexey Ivanov wrote: >> Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). >> >> Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. >> >> To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. > > Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision: > > - Inline AddTrayIcon and ModifyTrayIcon > - Make SendTrayMessage private - it's used internally only I replaced the calls to `SendTrayMessage(NIM_MODIFY)` with `ModifyTrayIcon()` for consistency and changed both `AddTrayIcon()` and `ModifyTrayIcon()` to inline methods which should remove an overhead of additional function call. I also moved `SendTrayMessage` into private section of the class, it's used internally only. ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From prr at openjdk.java.net Wed May 18 19:49:08 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 18 May 2022 19:49:08 GMT Subject: RFR: JDK-8255439: System Tray icons get corrupted when windows scaling changes [v12] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 18:29:44 GMT, Harshitha Onkar wrote: >> In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. >> >> With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. >> >> When DPI changes usually two messages are sent by windows - >> >> - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) >> - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) >> >> I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > test case instructions updated type something to see if it wakes up the bots ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Wed May 18 19:49:09 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Wed, 18 May 2022 19:49:09 GMT Subject: Integrated: JDK-8255439: System Tray icons get corrupted when windows scaling changes In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 02:26:28 GMT, Harshitha Onkar wrote: > In Windows, when desktop scaling is changed the tray icons was distorted/blurred a bit each time scaling changes. > > With the proposed fix, the tray icon scales according to on-the-fly DPI scale settings. A test case has been added which adds a MRI icon to system tray, to observe the icon scaling when DPI is changed. Since the scale cannot be programmatically changed (for dynamic on-the-fly scale changes), I have used a manual test case to test this scenario. > > When DPI changes usually two messages are sent by windows - > > - [WM_DPICHANGED](https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged) > - [WMPOSCHANGING](https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanging) > > I'm triggering an update on tray icons on receiving WMPOSCHANGING msg through the Tray icon's Window Procedure. Triggering an update on WM_DPICHANGED was still causing the icons to be distorted, hence WMPOSCHANGING is being used as the message to trigger the update. This pull request has now been integrated. Changeset: 8323787c Author: Harshitha Onkar Committer: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/8323787c07ced4fa8ce852995df4c0e2de4d7ccc Stats: 166 lines in 3 files changed: 164 ins; 0 del; 2 mod 8255439: System Tray icons get corrupted when windows scaling changes Co-authored-by: Alexey Ivanov Reviewed-by: kcr, prr, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/8441 From duke at openjdk.java.net Wed May 18 19:53:49 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Wed, 18 May 2022 19:53:49 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v3] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 17:54:30 GMT, Alexey Ivanov wrote: >> Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). >> >> Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. >> >> To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. > > Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision: > > - Inline AddTrayIcon and ModifyTrayIcon > - Make SendTrayMessage private - it's used internally only The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout 8286872-addModifyTrayIcon git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From duke at openjdk.java.net Thu May 19 01:55:41 2022 From: duke at openjdk.java.net (DamonGuy) Date: Thu, 19 May 2022 01:55:41 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 19:20:16 GMT, DamonGuy wrote: > Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc. I still believe HTML script tags aren't supported for rendering in Java's Parser. I have made a new local test. This test generates an HTML file that has an alert function within HTML script tags. An input button calls this alert function and generates a pop-up alert, and this works when the HTML file is opened in a browser. When I open the same HTML file in a JEditorPane, the script tag itself is displayed along with its contents. The script tag is displayed in a directional text input field and its contents are within these boxes. Screen Shot 2022-05-18 at 6 49 22 PM I looked into TagElement and HTML.java and "SCRIPT" is shown in the list of known tags, so that means "SCRIPT" is not labeled as an "Unknown tag" by the parser, which I confirmed in testing. I also looked into the strict flag, which enforces SGML compatibility, in Parser as @jayathirthrao suggested. With the flag set to true, the output to JEditorPane remains the same, but with no error logged. The normal sequence continues and the strict flag seems to mostly be associated with syntax issues such as extra spacing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7446 From duke at openjdk.java.net Thu May 19 04:49:42 2022 From: duke at openjdk.java.net (Tejesh R) Date: Thu, 19 May 2022 04:49:42 GMT Subject: Withdrawn: 8233477 [Win LAF]The tooltip doesn't display correctly in Win LAF In-Reply-To: References: Message-ID: On Mon, 2 May 2022 02:56:01 GMT, Tejesh R wrote: > In Button ToolTip, Mnemonic key string was shown only in Metal Look and Feel, since the feature is implemented in it. In other L&F especially Windows L&F the feature is not available. In order to make it available for other L&F's, the getAcceleratedString method and calculateAcceleratedStringSpace method is Implemented in ToolTipUI class. These methods are used in BasicToolTipUI class which uses the feature and shows/paints the ToolTip String along with the set Mnemonic key. In similar way other L&F which doesn't Inherit BasicToolTipUI can make use of the feature available in ToolTipUI. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8496 From jdv at openjdk.java.net Thu May 19 06:06:42 2022 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 19 May 2022 06:06:42 GMT Subject: RFR: 8286822: Write a test to check the DND functionality between two InternalFrames In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:52:03 GMT, Manukumar V S wrote: > This test verifies that dragging from one InternalFrame and a drop target in another InternalFrame functions properly. > This fix moves an unstable closed applet based test to open regression based java test, but updated to be more comprehensive with some stabilisation improvements. The closed test was creating noise in CI as it often fails in Windows platform, especially in Windows 11. > > Testing: > 1. Tested using mach5 20 times per platform and got all Pass. > 2. Tested using mach5 5 times specifically on Windows 11 and got all Pass. I dont see an internal PR to remove the applet based closed test. Also why https://bugs.openjdk.java.net/browse/JDK-8286822 is created as enhancement ? If this test is failing intermittently how many times we have seen this test fail? Like out of 20 times how many times it will fail on Windows 11? This will help us understand how many times we need to test updated test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8753 From mvs at openjdk.java.net Thu May 19 06:31:54 2022 From: mvs at openjdk.java.net (Manukumar V S) Date: Thu, 19 May 2022 06:31:54 GMT Subject: RFR: 8286822: Write a test to check the DND functionality between two InternalFrames In-Reply-To: References: Message-ID: On Thu, 19 May 2022 06:03:51 GMT, Jayathirth D V wrote: > I dont see an internal PR to remove the applet based closed test. Also why https://bugs.openjdk.java.net/browse/JDK-8286822 is created as enhancement ? > > If this test is failing intermittently how many times we have seen this test fail? Like out of 20 times how many times it will fail on Windows 11? This will help us understand how many times we need to test updated test. I will create an Internal PR to remove the closed test after this PR is integrated(for now I have created a closed bug to track this JDK-8286772). This test is added as a new test in open space, that's why JDK-8286822 was created as an enhancement. This test was failing 1/20 times in Windows 10, but it was failing almost 100% on Windows 11 before the fix. I have attached the failed mach5 runs also in the bug as a confidential comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8753 From duke at openjdk.java.net Thu May 19 08:07:48 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Thu, 19 May 2022 08:07:48 GMT Subject: Integrated: 8285687 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PageRangesDlgTest.java In-Reply-To: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> References: <2idh0qf39qyWBz8CH620Sobt-sulmfTt5UH6s2hbHVI=.8df8e571-079e-4314-9cab-20ea23f0dc31@github.com> Message-ID: On Wed, 27 Apr 2022 00:06:41 GMT, lawrence.andrews wrote: > 1) Fixed Parser error by removing yesno from @run main/manual=yesno > 2) Used PassFaileJFrame to show the test instruction to the user instead of printing the test instruction on the console or jtreg log file. > 3) If printer is not configured then mark the test as passed. > > @shurymury > @aivanov-jdk This pull request has now been integrated. Changeset: fc3edf24 Author: lawrence.andrews Committer: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/fc3edf2412461f41ac4dfd8b047257432620ba6d Stats: 68 lines in 1 file changed: 38 ins; 22 del; 8 mod 8285687: Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/PageRangesDlgTest.java Reviewed-by: prr, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/8412 From aivanov at openjdk.java.net Thu May 19 08:23:16 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 08:23:16 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v4] In-Reply-To: References: Message-ID: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> > Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). > > Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. > > To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge master - Inline AddTrayIcon and ModifyTrayIcon - Make SendTrayMessage private - it's used internally only - 8286872: Replace SendTrayMessage(NIM_MODIFY) with ModifyTrayIcon() - 8286872: Refactor add/modify notification icon (TrayIcon) - renamed method id variable - added ExceptionClear, fixed CI debug build issue - Merge branch 'master' into WinTrayIcon - reverted SystemTray changes - new changes - trayicon update triggered in WmTaskbarCreated - ... and 8 more: https://git.openjdk.java.net/jdk/compare/fc3edf24...44d20dc5 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8749&range=03 Stats: 26 lines in 2 files changed: 14 ins; 5 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8749/head:pull/8749 PR: https://git.openjdk.java.net/jdk/pull/8749 From azvegint at openjdk.java.net Thu May 19 15:28:43 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 19 May 2022 15:28:43 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v4] In-Reply-To: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> References: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> Message-ID: On Thu, 19 May 2022 08:23:16 GMT, Alexey Ivanov wrote: >> Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). >> >> Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. >> >> To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. > > Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge master > - Inline AddTrayIcon and ModifyTrayIcon > - Make SendTrayMessage private - it's used internally only > - 8286872: Replace SendTrayMessage(NIM_MODIFY) with ModifyTrayIcon() > - 8286872: Refactor add/modify notification icon (TrayIcon) > - renamed method id variable > - added ExceptionClear, fixed CI debug build issue > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/fc3edf24...44d20dc5 Still looks good. ------------- Marked as reviewed by azvegint (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8749 From kizune at openjdk.java.net Thu May 19 15:40:54 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 19 May 2022 15:40:54 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v4] In-Reply-To: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> References: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> Message-ID: On Thu, 19 May 2022 08:23:16 GMT, Alexey Ivanov wrote: >> Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). >> >> Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. >> >> To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. > > Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge master > - Inline AddTrayIcon and ModifyTrayIcon > - Make SendTrayMessage private - it's used internally only > - 8286872: Replace SendTrayMessage(NIM_MODIFY) with ModifyTrayIcon() > - 8286872: Refactor add/modify notification icon (TrayIcon) > - renamed method id variable > - added ExceptionClear, fixed CI debug build issue > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/fc3edf24...44d20dc5 Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From kizune at openjdk.java.net Thu May 19 15:42:01 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 19 May 2022 15:42:01 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:58:37 GMT, Phil Race wrote: >> This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 >> It is similar in the idea from what we converged on towards the end there but >> 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) >> 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? >> 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. >> >> I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. >> >> @toshiona you very likely want to take a look at it. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285308 Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8662 From kizune at openjdk.java.net Thu May 19 15:43:44 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 19 May 2022 15:43:44 GMT Subject: RFR: 8278367: JNI critical region violation in CTextPipe.m:363 In-Reply-To: <94RlM2Gc3q80Qh7mr_hMKEPfcoxIixXGVLY71F9aDrY=.99bcdb9d-f8fb-496d-af20-6dfb8f09ffe8@github.com> References: <94RlM2Gc3q80Qh7mr_hMKEPfcoxIixXGVLY71F9aDrY=.99bcdb9d-f8fb-496d-af20-6dfb8f09ffe8@github.com> Message-ID: On Mon, 2 May 2022 18:32:19 GMT, Phil Race wrote: > This re-jigs some lines of code so that we do all the lookups of the arrays before calling the GetPrimitiveArrayCritical on both of them together. Thereby avoiding warnings about calling those other methods in that context. Looks good to me. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8506 From jdv at openjdk.java.net Thu May 19 16:05:50 2022 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 19 May 2022 16:05:50 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton In-Reply-To: References: Message-ID: On Mon, 16 May 2022 06:45:04 GMT, Tejesh R wrote: > Added test for checking setMargin() of JRadioButton. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From vdyakov at openjdk.java.net Thu May 19 16:10:44 2022 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Thu, 19 May 2022 16:10:44 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes [v2] In-Reply-To: References: Message-ID: <-4E8VjMwPkxmkpgDQsjCY3EFg-sZEqugAI_VoCCK77o=.a5e5fe33-e11d-4fe9-92fe-4972de3257c2@github.com> On Fri, 13 May 2022 18:36:37 GMT, Alexander Zuev wrote: >> Moving cache invalidation from the clearCache method to a createRowWithIndex method >> eliminating race condition that causes crash. Now clearCache just notifies that cache >> is invalid and should be regenerated next time it is being accessed. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add a test case. @prsadhuk @prrace please review. @savoptik approved that but he is not (R)eviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From jdv at openjdk.java.net Thu May 19 16:19:53 2022 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 19 May 2022 16:19:53 GMT Subject: RFR: 8286822: Write a test to check the DND functionality between two InternalFrames In-Reply-To: References: Message-ID: On Thu, 19 May 2022 06:26:24 GMT, Manukumar V S wrote: > > I dont see an internal PR to remove the applet based closed test. Also why https://bugs.openjdk.java.net/browse/JDK-8286822 is created as enhancement ? > > If this test is failing intermittently how many times we have seen this test fail? Like out of 20 times how many times it will fail on Windows 11? This will help us understand how many times we need to test updated test. > > I will create an Internal PR to remove the closed test after this PR is integrated(for now I have created a closed bug to track this JDK-8286772). This test is added as a new test in open space, that's why JDK-8286822 was created as an enhancement. This test was failing 1/20 times in Windows 10, but it was failing almost 100% on Windows 11 before the fix. I have attached the failed mach5 runs also in the bug as a confidential comment. We dont create 2 separate JBS ID's for opening up closed test case. Opening up of test case and deleting closed test case should be handled in single JBS bug ID. Opening up a regression test case should not be handled as enhancement. We add so many of these regression tests as part of normal bugs along with product change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8753 From azvegint at openjdk.java.net Thu May 19 17:28:40 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 19 May 2022 17:28:40 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 In-Reply-To: References: Message-ID: <6xlBBeuSjwt-NOMwDSlWOu2S4YN6r6hYmdXuo3M7x68=.de94f25a-9535-4506-a381-8fabfc25eff9@github.com> On Sun, 1 May 2022 21:25:27 GMT, Phil Race wrote: > This is a theoretical/potential case of calling JNI methods with a possible execption pending. > As noted in the eval of the bug report, we no longer follow the practice that AWT_LOCK is > called only at the start of a native method and AWT_UNLOCK at the end, if indeed we ever did. > But it seems to be implied in how they are handling exceptions. src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1432: > 1430: } > 1431: (*env)->CallVoidMethod(env, this, midAddVisual, (visInfo[i]).visual); > 1432: if ((*env)->ExceptionCheck(env)) { Looks like this `if` block can be removed, since it is effectively handled by check above. ------------- PR: https://git.openjdk.java.net/jdk/pull/8493 From azvegint at openjdk.java.net Thu May 19 17:33:41 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 19 May 2022 17:33:41 GMT Subject: RFR: 8278367: JNI critical region violation in CTextPipe.m:363 In-Reply-To: <94RlM2Gc3q80Qh7mr_hMKEPfcoxIixXGVLY71F9aDrY=.99bcdb9d-f8fb-496d-af20-6dfb8f09ffe8@github.com> References: <94RlM2Gc3q80Qh7mr_hMKEPfcoxIixXGVLY71F9aDrY=.99bcdb9d-f8fb-496d-af20-6dfb8f09ffe8@github.com> Message-ID: <5YrClA5mLiEdHBZIdKKs3mrizQb-CKIQ7CsZ8sCOr7A=.02a3d4dc-8b01-4b62-bc56-9d55a6af689d@github.com> On Mon, 2 May 2022 18:32:19 GMT, Phil Race wrote: > This re-jigs some lines of code so that we do all the lookups of the arrays before calling the GetPrimitiveArrayCritical on both of them together. Thereby avoiding warnings about calling those other methods in that context. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8506 From prr at openjdk.java.net Thu May 19 18:00:04 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 18:00:04 GMT Subject: Integrated: 8278367: JNI critical region violation in CTextPipe.m:363 In-Reply-To: <94RlM2Gc3q80Qh7mr_hMKEPfcoxIixXGVLY71F9aDrY=.99bcdb9d-f8fb-496d-af20-6dfb8f09ffe8@github.com> References: <94RlM2Gc3q80Qh7mr_hMKEPfcoxIixXGVLY71F9aDrY=.99bcdb9d-f8fb-496d-af20-6dfb8f09ffe8@github.com> Message-ID: <47uHOUg91yhHNzoGgywa_dQECZRzHCw9CoMKy4RzNHA=.f80d3958-8320-4f48-845a-f67d0a1bf32b@github.com> On Mon, 2 May 2022 18:32:19 GMT, Phil Race wrote: > This re-jigs some lines of code so that we do all the lookups of the arrays before calling the GetPrimitiveArrayCritical on both of them together. Thereby avoiding warnings about calling those other methods in that context. This pull request has now been integrated. Changeset: ac6a7d7b Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/ac6a7d7b36fc79161320b6e4082cff8fb4924811 Stats: 11 lines in 1 file changed: 9 ins; 2 del; 0 mod 8278367: JNI critical region violation in CTextPipe.m:363 Reviewed-by: kizune, azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/8506 From prr at openjdk.java.net Thu May 19 18:08:44 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 18:08:44 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 In-Reply-To: <6xlBBeuSjwt-NOMwDSlWOu2S4YN6r6hYmdXuo3M7x68=.de94f25a-9535-4506-a381-8fabfc25eff9@github.com> References: <6xlBBeuSjwt-NOMwDSlWOu2S4YN6r6hYmdXuo3M7x68=.de94f25a-9535-4506-a381-8fabfc25eff9@github.com> Message-ID: On Thu, 19 May 2022 17:23:58 GMT, Alexander Zvegintsev wrote: >> This is a theoretical/potential case of calling JNI methods with a possible execption pending. >> As noted in the eval of the bug report, we no longer follow the practice that AWT_LOCK is >> called only at the start of a native method and AWT_UNLOCK at the end, if indeed we ever did. >> But it seems to be implied in how they are handling exceptions. > > src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1432: > >> 1430: } >> 1431: (*env)->CallVoidMethod(env, this, midAddVisual, (visInfo[i]).visual); >> 1432: if ((*env)->ExceptionCheck(env)) { > > Looks like this `if` block can be removed, since it is effectively handled by check above. No .. that check is needed since CallVoidMethod() could raise an exception ------------- PR: https://git.openjdk.java.net/jdk/pull/8493 From duke at openjdk.java.net Thu May 19 18:09:54 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 19 May 2022 18:09:54 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v4] In-Reply-To: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> References: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> Message-ID: On Thu, 19 May 2022 08:23:16 GMT, Alexey Ivanov wrote: >> Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). >> >> Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. >> >> To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. > > Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge master > - Inline AddTrayIcon and ModifyTrayIcon > - Make SendTrayMessage private - it's used internally only > - 8286872: Replace SendTrayMessage(NIM_MODIFY) with ModifyTrayIcon() > - 8286872: Refactor add/modify notification icon (TrayIcon) > - renamed method id variable > - added ExceptionClear, fixed CI debug build issue > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/fc3edf24...44d20dc5 Changes tested on Win10 and works well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From duke at openjdk.java.net Thu May 19 18:14:03 2022 From: duke at openjdk.java.net (Harshitha Onkar) Date: Thu, 19 May 2022 18:14:03 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v4] In-Reply-To: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> References: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> Message-ID: On Thu, 19 May 2022 08:23:16 GMT, Alexey Ivanov wrote: >> Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). >> >> Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. >> >> To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. > > Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge master > - Inline AddTrayIcon and ModifyTrayIcon > - Make SendTrayMessage private - it's used internally only > - 8286872: Replace SendTrayMessage(NIM_MODIFY) with ModifyTrayIcon() > - 8286872: Refactor add/modify notification icon (TrayIcon) > - renamed method id variable > - added ExceptionClear, fixed CI debug build issue > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/fc3edf24...44d20dc5 Marked as reviewed by honkar-jdk at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From azvegint at openjdk.java.net Thu May 19 18:15:40 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 19 May 2022 18:15:40 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 In-Reply-To: References: <6xlBBeuSjwt-NOMwDSlWOu2S4YN6r6hYmdXuo3M7x68=.de94f25a-9535-4506-a381-8fabfc25eff9@github.com> Message-ID: <7-o8bXNYTOyXqey-iKRaV3pS5SrTO_tNE2QxisOJtrM=.3766a6f9-de36-434b-86c8-8d728d1b8ba4@github.com> On Thu, 19 May 2022 18:05:10 GMT, Phil Race wrote: >> src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1432: >> >>> 1430: } >>> 1431: (*env)->CallVoidMethod(env, this, midAddVisual, (visInfo[i]).visual); >>> 1432: if ((*env)->ExceptionCheck(env)) { >> >> Looks like this `if` block can be removed, since it is effectively handled by check above. > > No .. that check is needed since CallVoidMethod() could raise an exception Sure, it can, but: - if there is another iteration to do it will be handled by check on line `1428` and will break the cycle. - if it is the last iteration there is no need to break since `CallVoidMethod()` is last statement in cycle. Do I missing something? ------------- PR: https://git.openjdk.java.net/jdk/pull/8493 From prr at openjdk.java.net Thu May 19 18:26:52 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 18:26:52 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 In-Reply-To: <7-o8bXNYTOyXqey-iKRaV3pS5SrTO_tNE2QxisOJtrM=.3766a6f9-de36-434b-86c8-8d728d1b8ba4@github.com> References: <6xlBBeuSjwt-NOMwDSlWOu2S4YN6r6hYmdXuo3M7x68=.de94f25a-9535-4506-a381-8fabfc25eff9@github.com> <7-o8bXNYTOyXqey-iKRaV3pS5SrTO_tNE2QxisOJtrM=.3766a6f9-de36-434b-86c8-8d728d1b8ba4@github.com> Message-ID: On Thu, 19 May 2022 18:11:49 GMT, Alexander Zvegintsev wrote: >> No .. that check is needed since CallVoidMethod() could raise an exception > > Sure, it can, but: > > - if there is another iteration to do it will be handled by check on line `1428` and will break the cycle. > - if it is the last iteration there is no need to break since `CallVoidMethod()` is last statement in cycle. > > Do I missing something? yep, ok. It is redundant. Update coming shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8493 From prr at openjdk.java.net Thu May 19 18:33:48 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 18:33:48 GMT Subject: RFR: 8286447: [Linux] AWT should start in Headless mode if headful AWT library not installed [v2] In-Reply-To: References: Message-ID: > As per the bug report and the CSR (please review that too), this makes AWT load in headless mode > if only headless libraries are installed. > > It passes all our normal testing which at least should show that this doesn't regress anything. > I had to manually remove libawt_xawt.so to verify that it will do as expected in such a case, > and it would not be easy to create a test for that. > > CSR : https://bugs.openjdk.java.net/browse/JDK-8286598 Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8286447 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8659/files - new: https://git.openjdk.java.net/jdk/pull/8659/files/68b9ec2a..885e1eab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8659&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8659&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8659.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8659/head:pull/8659 PR: https://git.openjdk.java.net/jdk/pull/8659 From prr at openjdk.java.net Thu May 19 18:34:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 18:34:57 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 [v2] In-Reply-To: References: Message-ID: > This is a theoretical/potential case of calling JNI methods with a possible execption pending. > As noted in the eval of the bug report, we no longer follow the practice that AWT_LOCK is > called only at the start of a native method and AWT_UNLOCK at the end, if indeed we ever did. > But it seems to be implied in how they are handling exceptions. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8285399 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8493/files - new: https://git.openjdk.java.net/jdk/pull/8493/files/16726225..67611235 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8493&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8493&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8493.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8493/head:pull/8493 PR: https://git.openjdk.java.net/jdk/pull/8493 From kcr at openjdk.java.net Thu May 19 18:39:43 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 19 May 2022 18:39:43 GMT Subject: RFR: 8286447: [Linux] AWT should start in Headless mode if headful AWT library not installed [v2] In-Reply-To: References: Message-ID: <8e1WxBLPcFMCQP1UoQtDJFbIxhqGv9GGUvVNGfc9pUY=.4068a947-f5f9-4b48-a778-f09bb488464f@github.com> On Thu, 19 May 2022 18:33:48 GMT, Phil Race wrote: >> As per the bug report and the CSR (please review that too), this makes AWT load in headless mode >> if only headless libraries are installed. >> >> It passes all our normal testing which at least should show that this doesn't regress anything. >> I had to manually remove libawt_xawt.so to verify that it will do as expected in such a case, >> and it would not be easy to create a test for that. >> >> CSR : https://bugs.openjdk.java.net/browse/JDK-8286598 > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8286447 Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8659 From azvegint at openjdk.java.net Thu May 19 18:39:47 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 19 May 2022 18:39:47 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 18:34:57 GMT, Phil Race wrote: >> This is a theoretical/potential case of calling JNI methods with a possible execption pending. >> As noted in the eval of the bug report, we no longer follow the practice that AWT_LOCK is >> called only at the start of a native method and AWT_UNLOCK at the end, if indeed we ever did. >> But it seems to be implied in how they are handling exceptions. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285399 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8493 From prr at openjdk.java.net Thu May 19 18:42:59 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 18:42:59 GMT Subject: Integrated: 8286447: [Linux] AWT should start in Headless mode if headful AWT library not installed In-Reply-To: References: Message-ID: <-lCylb2K4cfjWn_a3DSRG6poxpmPpACABt6OWl6RpkI=.a4c4f308-8707-4905-a48d-b9ed913e8305@github.com> On Wed, 11 May 2022 17:27:38 GMT, Phil Race wrote: > As per the bug report and the CSR (please review that too), this makes AWT load in headless mode > if only headless libraries are installed. > > It passes all our normal testing which at least should show that this doesn't regress anything. > I had to manually remove libawt_xawt.so to verify that it will do as expected in such a case, > and it would not be easy to create a test for that. > > CSR : https://bugs.openjdk.java.net/browse/JDK-8286598 This pull request has now been integrated. Changeset: aa506258 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/aa5062584c5a17d1ad21e31ce3f4768f6a5edbc8 Stats: 35 lines in 1 file changed: 30 ins; 0 del; 5 mod 8286447: [Linux] AWT should start in Headless mode if headful AWT library not installed Reviewed-by: asemenyuk, kcr ------------- PR: https://git.openjdk.java.net/jdk/pull/8659 From azvegint at openjdk.java.net Thu May 19 18:47:12 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 19 May 2022 18:47:12 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v2] In-Reply-To: References: Message-ID: On Sat, 14 May 2022 17:33:37 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > SWinxy has updated the pull request incrementally with one additional commit since the last revision: > > Remove @author tags per request Changes requested by azvegint (Reviewer). src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/XColors.java line 402: > 400: case "olivedrab1" -> new ColorUIResource(192, 255, 62); > 401: case "olivedrab2" -> new ColorUIResource(179, 238, 58); > 402: case "olivedrab3", "yellow green", "yellowgreen" -> new ColorUIResource(154, 205, 50); `yellowgreen` was originally `new XColor("yellowgreen", 154, 205, 5)` src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/XColors.java line 487: > 485: case "sienna3" -> new ColorUIResource(205, 104, 57); > 486: case "sienna4" -> new ColorUIResource(139, 71, 38); > 487: case "sky blue", "skyblue", "skyblue1" -> new ColorUIResource(135, 206, 255); "sky blue", "skyblue" were new XColor("sky blue", 135, 206, 235), new XColor("skyblue", 135, 206, 235), ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From honkar at openjdk.java.net Thu May 19 18:50:56 2022 From: honkar at openjdk.java.net (Harshitha Onkar) Date: Thu, 19 May 2022 18:50:56 GMT Subject: RFR: 8286872: Refactor add/modify notification icon (TrayIcon) [v4] In-Reply-To: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> References: <7yiugy4sAftmwM_kX4qrqkrHBa---jyeMo3zi04i4Zs=.8b32a9a1-2138-49e2-96f4-7d8985362ecd@github.com> Message-ID: On Thu, 19 May 2022 08:23:16 GMT, Alexey Ivanov wrote: >> Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). >> >> Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. >> >> To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. > > Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge master > - Inline AddTrayIcon and ModifyTrayIcon > - Make SendTrayMessage private - it's used internally only > - 8286872: Replace SendTrayMessage(NIM_MODIFY) with ModifyTrayIcon() > - 8286872: Refactor add/modify notification icon (TrayIcon) > - renamed method id variable > - added ExceptionClear, fixed CI debug build issue > - Merge branch 'master' into WinTrayIcon > - reverted SystemTray changes > - new changes - trayicon update triggered in WmTaskbarCreated > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/fc3edf24...44d20dc5 Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From prr at openjdk.java.net Thu May 19 19:25:45 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 19:25:45 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v2] In-Reply-To: References: Message-ID: <-9wVCOlJGD1pBKp11__hYnqM1maUsrVwt0c5NPnrthk=.5f84c05f-9f2c-4a17-b187-cddf6414f2f0@github.com> On Sat, 14 May 2022 17:33:37 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > SWinxy has updated the pull request incrementally with one additional commit since the last revision: > > Remove @author tags per request good catch. These need to be fixed. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7096 From prr at openjdk.java.net Thu May 19 19:32:48 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 19:32:48 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes [v2] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 18:36:37 GMT, Alexander Zuev wrote: >> Moving cache invalidation from the clearCache method to a createRowWithIndex method >> eliminating race condition that causes crash. Now clearCache just notifies that cache >> is invalid and should be regenerated next time it is being accessed. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add a test case. Marked as reviewed by prr (Reviewer). test/jdk/java/awt/a11y/AccessibleJTableTest.java line 81: > 79: public void createUIDraggable() { > 80: INSTRUCTIONS = "INSTRUCTIONS:\n" > 81: + "Check that table is properly updated when culumn order is changed.\n\n" culumn -> column ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From aivanov at openjdk.java.net Thu May 19 20:08:42 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 20:08:42 GMT Subject: Integrated: 8286872: Refactor add/modify notification icon (TrayIcon) In-Reply-To: References: Message-ID: <05LSNiM3D705imMb5OPi_clWJAC4ZCpOYdtOND_Xuvw=.f5a35ca4-01cd-4462-b2bb-cc9e1b10eb67@github.com> On Tue, 17 May 2022 13:02:49 GMT, Alexey Ivanov wrote: > Encapsulate the logic of adding or modifying a notification icon aka tray icon. This is to avoid code duplication between [`AwtTrayIcon::WmTaskbarCreated`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L477) and [`AwtTrayIcon::_UpdateIcon`](https://github.com/openjdk/jdk/blob/7b988b31c661c6e3e58cf8ced81732e40a79d4f5/src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp#L796). > > Separating adding and modifying the icon simplifies the methods, the actions are clearer: adding the icon requires sending `NIM_SETVERSION` message whereas modifying the icon doesn't. > > To verify the code works as before, I used `TrayIconScalingTest.java`. I killed explorer.exe process to verify the notification icon gets added. Changing DPI of the main display updates the displayed icon as expected. This pull request has now been integrated. Changeset: 9f562ef7 Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/9f562ef7546c80e6ddce7b932f3f5ca17c741d21 Stats: 26 lines in 2 files changed: 14 ins; 5 del; 7 mod 8286872: Refactor add/modify notification icon (TrayIcon) Reviewed-by: azvegint, kizune, honkar ------------- PR: https://git.openjdk.java.net/jdk/pull/8749 From rriggs at openjdk.java.net Thu May 19 20:59:01 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 19 May 2022 20:59:01 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2] In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> >> if (clazz.isInstance(obj)) { >> >> Replacement is equivalent if it's known that `obj != null`. >> In JDK codebase there are many such places. >> >> I tried to measure performance via JMH >> >> Class integerClass = Integer.class; >> Class numberClass = Number.class; >> >> Object integerObject = 45666; >> Object doubleObject = 8777d; >> >> @Benchmark >> public boolean integerInteger_isInstance() { >> return integerClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean integerInteger_isAssignableFrom() { >> return integerClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public boolean integerDouble_isInstance() { >> return integerClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean integerDouble_isAssignableFrom() { >> return integerClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberDouble_isInstance() { >> return numberClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean numberDouble_isAssignableFrom() { >> return numberClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberInteger_isInstance() { >> return numberClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean numberInteger_isAssignableFrom() { >> return numberClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public void numberIntegerDouble_isInstance(Blackhole bh) { >> bh.consume(numberClass.isInstance(integerObject)); >> bh.consume(numberClass.isInstance(doubleObject)); >> } >> >> @Benchmark >> public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { >> bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); >> bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); >> } >> >> `isInstance` is a bit faster than `isAssignableFrom` >> >> Benchmark Mode Cnt Score Error Units >> integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op >> integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op >> integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op >> numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op >> integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op >> integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op >> numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op >> numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op >> numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op >> numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable > apply suggestion to avoid second Method.invoke call Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From aturbanov at openjdk.java.net Thu May 19 21:23:45 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 19 May 2022 21:23:45 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable [v2] In-Reply-To: References: Message-ID: On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov wrote: >> Method `Class.isAssignableFrom` is often used in form of: >> >> if (clazz.isAssignableFrom(obj.getClass())) { >> Such condition could be simplified to more shorter and performarnt code >> >> if (clazz.isInstance(obj)) { >> >> Replacement is equivalent if it's known that `obj != null`. >> In JDK codebase there are many such places. >> >> I tried to measure performance via JMH >> >> Class integerClass = Integer.class; >> Class numberClass = Number.class; >> >> Object integerObject = 45666; >> Object doubleObject = 8777d; >> >> @Benchmark >> public boolean integerInteger_isInstance() { >> return integerClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean integerInteger_isAssignableFrom() { >> return integerClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public boolean integerDouble_isInstance() { >> return integerClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean integerDouble_isAssignableFrom() { >> return integerClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberDouble_isInstance() { >> return numberClass.isInstance(doubleObject); >> } >> >> @Benchmark >> public boolean numberDouble_isAssignableFrom() { >> return numberClass.isAssignableFrom(doubleObject.getClass()); >> } >> >> @Benchmark >> public boolean numberInteger_isInstance() { >> return numberClass.isInstance(integerObject); >> } >> >> @Benchmark >> public boolean numberInteger_isAssignableFrom() { >> return numberClass.isAssignableFrom(integerObject.getClass()); >> } >> >> @Benchmark >> public void numberIntegerDouble_isInstance(Blackhole bh) { >> bh.consume(numberClass.isInstance(integerObject)); >> bh.consume(numberClass.isInstance(doubleObject)); >> } >> >> @Benchmark >> public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { >> bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); >> bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); >> } >> >> `isInstance` is a bit faster than `isAssignableFrom` >> >> Benchmark Mode Cnt Score Error Units >> integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op >> integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op >> integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op >> numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op >> integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op >> integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op >> numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op >> numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op >> numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op >> numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable > apply suggestion to avoid second Method.invoke call Thank you for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From aturbanov at openjdk.java.net Thu May 19 21:46:09 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 19 May 2022 21:46:09 GMT Subject: Integrated: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote: > Method `Class.isAssignableFrom` is often used in form of: > > if (clazz.isAssignableFrom(obj.getClass())) { > Such condition could be simplified to more shorter and performarnt code > > if (clazz.isInstance(obj)) { > > Replacement is equivalent if it's known that `obj != null`. > In JDK codebase there are many such places. > > I tried to measure performance via JMH > > Class integerClass = Integer.class; > Class numberClass = Number.class; > > Object integerObject = 45666; > Object doubleObject = 8777d; > > @Benchmark > public boolean integerInteger_isInstance() { > return integerClass.isInstance(integerObject); > } > > @Benchmark > public boolean integerInteger_isAssignableFrom() { > return integerClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public boolean integerDouble_isInstance() { > return integerClass.isInstance(doubleObject); > } > > @Benchmark > public boolean integerDouble_isAssignableFrom() { > return integerClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberDouble_isInstance() { > return numberClass.isInstance(doubleObject); > } > > @Benchmark > public boolean numberDouble_isAssignableFrom() { > return numberClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberInteger_isInstance() { > return numberClass.isInstance(integerObject); > } > > @Benchmark > public boolean numberInteger_isAssignableFrom() { > return numberClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public void numberIntegerDouble_isInstance(Blackhole bh) { > bh.consume(numberClass.isInstance(integerObject)); > bh.consume(numberClass.isInstance(doubleObject)); > } > > @Benchmark > public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { > bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); > bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); > } > > `isInstance` is a bit faster than `isAssignableFrom` > > Benchmark Mode Cnt Score Error Units > integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op > integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op > integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op > numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op > integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op > integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op > numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op > numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op > numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op > numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op This pull request has now been integrated. Changeset: de74e0e2 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/de74e0e25a195084745891419f0c4a8ad286560c Stats: 25 lines in 10 files changed: 0 ins; 3 del; 22 mod 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable Reviewed-by: prr, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From prr at openjdk.java.net Thu May 19 22:02:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 22:02:49 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:58:37 GMT, Phil Race wrote: >> This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 >> It is similar in the idea from what we converged on towards the end there but >> 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) >> 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? >> 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. >> >> I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. >> >> @toshiona you very likely want to take a look at it. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285308 @naotoj @toshiona would one of you be the 2nd APPROVER for this ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8662 From naoto at openjdk.java.net Thu May 19 22:32:46 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 19 May 2022 22:32:46 GMT Subject: RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 20:58:37 GMT, Phil Race wrote: >> This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 >> It is similar in the idea from what we converged on towards the end there but >> 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) >> 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? >> 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. >> >> I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. >> >> @toshiona you very likely want to take a look at it. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285308 Looks good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8662 From prr at openjdk.java.net Thu May 19 23:45:48 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 23:45:48 GMT Subject: Integrated: 8285308: Win: Japanese logical fonts are drawn with wrong size In-Reply-To: References: Message-ID: On Wed, 11 May 2022 18:25:09 GMT, Phil Race wrote: > This replaces the PR from Toshio https://git.openjdk.java.net/jdk/pull/8329 > It is similar in the idea from what we converged on towards the end there but > 1) I'd like to preserve all the support for the old encodings since JEP-400 explicitly supports using -Dfile.encoding=windows-31j (for example) > 2) I wanted to have the look up for the font to use in the windows text control succeed on the first font it finds not the last. In practice I expect this to be a no-op but if someone did have two that match .. don't you think they mean the first one to be the primary ? > 3) I needed to update the encoding match to ensure that some optional re-ordering for Japanese logical fonts works in the UTF-8.ja locale as that is now the default. > > I verified this fix by changing regional settings as well as passing -Duser.language=ja -Duser.country=JP and logical fonts on lightweights (verified in Font2DTest) are as expected and the "fonttest.java" now behaves as it did in JDK 17 and earlier. Since you need to switch regional settings automating this test was not possible. > > @toshiona you very likely want to take a look at it. This pull request has now been integrated. Changeset: 40e99a19 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/40e99a19f20dde0916684f93c17c51c7c5de109a Stats: 27 lines in 1 file changed: 21 ins; 2 del; 4 mod 8285308: Win: Japanese logical fonts are drawn with wrong size Reviewed-by: kizune, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/8662 From prr at openjdk.java.net Thu May 19 23:54:13 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 19 May 2022 23:54:13 GMT Subject: RFR: 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver Message-ID: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> This adds the Microsoft Basic Render Driver to our "bad hardware" list so that we don't use that pipeline there. We have at least the one test that fails there and I am not sure we get any benefit from this. I'm sure Microsoft need to provide for apps that have only a D3D option, but that isn't the JDK case. FYI there was a PR a while back about problem listing that failing test : https://github.com/openjdk/jdk/pull/5930 but we don't need to do that with this change - nor worry about similar problems with other tests. ------------- Commit messages: - 8275303 Changes: https://git.openjdk.java.net/jdk/pull/8797/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8797&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275303 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8797/head:pull/8797 PR: https://git.openjdk.java.net/jdk/pull/8797 From duke at openjdk.java.net Fri May 20 00:53:27 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 20 May 2022 00:53:27 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v3] In-Reply-To: References: Message-ID: > The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. SWinxy has updated the pull request incrementally with one additional commit since the last revision: Accidental mergers. I created a quick check to see if any other colors were different (only these three). For some odd reason "yellowgreen" and "yellow green" are different. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7096/files - new: https://git.openjdk.java.net/jdk/pull/7096/files/79f3ddf7..32640e43 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7096&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7096&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7096.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7096/head:pull/7096 PR: https://git.openjdk.java.net/jdk/pull/7096 From duke at openjdk.java.net Fri May 20 00:53:27 2022 From: duke at openjdk.java.net (SWinxy) Date: Fri, 20 May 2022 00:53:27 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v2] In-Reply-To: References: Message-ID: On Sat, 14 May 2022 17:33:37 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > SWinxy has updated the pull request incrementally with one additional commit since the last revision: > > Remove @author tags per request I did an automated test to see if those were the only other things wrong. Those were the only things that were wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From duke at openjdk.java.net Fri May 20 07:54:53 2022 From: duke at openjdk.java.net (Tejesh R) Date: Fri, 20 May 2022 07:54:53 GMT Subject: RFR: 8286822: Write a test to check the DND functionality between two InternalFrames In-Reply-To: References: Message-ID: <98d4QKHKLIaozF4R_bRk78e-ibxr7_ot6NBPbnqEw8U=.e4290fae-2a18-41cb-824c-a61541c4b27a@github.com> On Tue, 17 May 2022 15:52:03 GMT, Manukumar V S wrote: > This test verifies that dragging from one InternalFrame and a drop target in another InternalFrame functions properly. > This fix moves an unstable closed applet based test to open regression based java test, but updated to be more comprehensive with some stabilisation improvements. The closed test was creating noise in CI as it often fails in Windows platform, especially in Windows 11. > > Testing: > 1. Tested using mach5 20 times per platform and got all Pass. > 2. Tested using mach5 5 times specifically on Windows 11 and got all Pass. test/jdk/java/awt/dnd/DropTargetInInternalFrameTest.java line 244: > 242: private final Dimension preferredDimension = new Dimension(200, 100); > 243: private final CountDownLatch dropLatch; > 244: private volatile int calledMethods = 0; Any reason for changing calledMethods to volatile? ------------- PR: https://git.openjdk.java.net/jdk/pull/8753 From psadhukhan at openjdk.java.net Fri May 20 09:02:47 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 20 May 2022 09:02:47 GMT Subject: Integrated: 8285962: NimbusDefaults has a typo in a L&F property In-Reply-To: <1E9x3Ur0YF8znS8aud8ll9X5jPtulLXnTKikMB0pr54=.37e43dc8-bf2c-417f-a097-57693e772110@github.com> References: <1E9x3Ur0YF8znS8aud8ll9X5jPtulLXnTKikMB0pr54=.37e43dc8-bf2c-417f-a097-57693e772110@github.com> Message-ID: <438o2I9gdUJzZ_GcO0f_GVtuuT-eXbSDPXTYokbFquw=.f0d6bc27-62d0-4d83-af95-e70f4de1c4f0@github.com> On Mon, 2 May 2022 16:01:02 GMT, Prasanta Sadhukhan wrote: > BasicLookAndFeel, BasicProgressBarUI, GTKLookAndFeel tries to find property by "ProgressBar.verticalSize" but the property defined in NimbusDefaults has a typo "vertictalSize ". > Rectified the typo. This pull request has now been integrated. Changeset: 6d56caff Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/6d56caff3d7b06bb75f741bc503797edf94e9889 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8285962: NimbusDefaults has a typo in a L&F property Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8504 From psadhukhan at openjdk.java.net Fri May 20 09:15:20 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 20 May 2022 09:15:20 GMT Subject: RFR: 8286786: [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java still fails Message-ID: In PR#[8380](https://github.com/openjdk/jdk/pull/8380) we have reduced the error tolerance from 25 to 1 so no need of exact color check which is causing failure in specific M1 iMac system because of minimalistic color difference of "1" x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 `so modified to use the tolerance check for all L&Fs. ------------- Commit messages: - 8286786: [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java still fails Changes: https://git.openjdk.java.net/jdk/pull/8804/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8804&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286786 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8804/head:pull/8804 PR: https://git.openjdk.java.net/jdk/pull/8804 From psadhukhan at openjdk.java.net Fri May 20 09:33:01 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 20 May 2022 09:33:01 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 16:36:26 GMT, Artem Semenov wrote: >>> It seems to me that here it is necessary to release the cache. >> >> I am not so sure. Why would we do that? I mean - we removed all the records from the cache and even if we would release it we would have to immediately re-create it otherwise the very next operation will crash since we will be trying to call objectForKey selector upon nil. So what is the point in releasing the now empty dictionary? > > Ok. If we are removing "all records from the cache", can't we use [removeAllObjects](https://developer.apple.com/documentation/foundation/nsmutabledictionary/1408955-removeallobjects?language=objc) Guess that will be more optimized.. ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From azvegint at openjdk.java.net Fri May 20 10:32:42 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 20 May 2022 10:32:42 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v3] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 00:53:27 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > SWinxy has updated the pull request incrementally with one additional commit since the last revision: > > Accidental mergers. > > I created a quick check to see if any other colors were different (only these three). For some odd reason "yellowgreen" and "yellow green" are different. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From aivanov at openjdk.java.net Fri May 20 12:05:59 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 May 2022 12:05:59 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 17 May 2022 20:43:00 GMT, Alexey Ivanov wrote: >> Perhaps you are trying to get layout to happen ? That should be possible but it might be tricky. >> But I think if you are going so far as pack() and can't change that, then show the frame regardless. > > Right, JPanel isn't laid out without being added to a peered component. > > Maybe setting explicit positions to child panels will work, then the test can be headless. > That looks odd. I mean if you show the frame, how is it disposed ? The idea for that is that frame is shown only if `-show` parameter is passed. In this case, it's assumed the user runs the test from the IDE or on command line. So the frame is disposed of when the user closes it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From michal.babacek at gmail.com Fri May 20 13:11:32 2022 From: michal.babacek at gmail.com (Michal Karm) Date: Fri, 20 May 2022 15:11:32 +0200 Subject: JDK-8274735, JPEG compression in a TIFF container, openjdk/jdk/pull/7849 In-Reply-To: <82f5f75e-cf0f-d447-ce58-0cacf00dcb6e@oracle.com> References: <4b94671b-6cb3-0ff3-a646-018e7cf33ba4@gmail.com> <82f5f75e-cf0f-d447-ce58-0cacf00dcb6e@oracle.com> Message-ID: I stepped the flow in a debugger and I narrowed down the reproducer to a more focused, simpler description and test data: https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md TL;DR: JPEG compressed RGB image in TIFF with transparency makes the TIFF decoder to push 4 components data to the JPEG reader. The JPEG reader wrongly guesses that the data is CMYK now (based on the number of components). If the image is GRAYSCALE though, it ends up in Unsupported Image Type because JPEG reader doesn't try to guess it's CMYK. Solution...I don't know. Would it make sense if I transform the data to the number of components the JPEG reader expects? All the necessary information is there in the TIFF metadata, e.g. it knows the space is RGB and not CMYK, it knows that there is a transparency saved with the tile. THX for hints Karm On 5/17/22 21:52, Philip Race wrote: > This could be a bug in the TIFF plugin. > Hard to say without debugging it. > > -phil. > > > On 5/17/22 7:04 AM, Michal Karm wrote: >> Hello, >> >> There used to be an Unsupported Image Type exception thrown >> when one wanted to decode a TIFF container with JPEG compressed image. >> >> That behavior has changed, there is no exception now, although the >> resulting image is incorrect. >> >> I outlined the details in this doc [1], including a small reproducer. >> >> The test image is not anything from a fuzzer, it's just me >> clicking Export As in GIMP. >> >> Thanks for feedback >> >> Cheers >> Karm >> >> >> [1] >> https://urldefense.com/v3/__https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md__;!!ACWV5N9M2RV99hQ!Kw41ShsuTSfpVPMZFrXmdQ7ZETNdkLTk9Xd1NDWELvCXV0fyIqg4sXi5Z1aYfjMoG-5fS0gki8dnN8bQjSYM0g$ >> >> >> Karm Michal Babacek >> > Michal Karm Babacek -- Sent from my Hosaka Ono-Sendai Cyberspace 7 From aivanov at openjdk.java.net Fri May 20 13:17:07 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 May 2022 13:17:07 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Fri, 20 May 2022 12:02:42 GMT, Alexey Ivanov wrote: >> Right, JPanel isn't laid out without being added to a peered component. >> >> Maybe setting explicit positions to child panels will work, then the test can be headless. > >> That looks odd. I mean if you show the frame, how is it disposed ? > > The idea for that is that frame is shown only if `-show` parameter is passed. In this case, it's assumed the user runs the test from the IDE or on command line. So the frame is disposed of when the user closes it. > > Perhaps you are trying to get layout to happen ? That should be possible but it might be tricky. > > Right, JPanel isn't laid out without being added to a peered component. > > Maybe setting explicit positions to child panels will work, then the test can be headless. Indeed, it works with explicitly set size and positions. Here's [a working sample](https://github.com/alisenchung/jdk/compare/8279614...aivanov-jdk:alisen-8279614-titledBorder). (Add `.diff` or `.patch` to the URL to get the changeset to apply.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Fri May 20 13:37:49 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 May 2022 13:37:49 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v14] In-Reply-To: References: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> Message-ID: On Tue, 10 May 2022 14:08:50 GMT, Alexey Ivanov wrote: > One more thing: the test now uses `EtchedBorder` only, shall it be moved to `test/jdk/java/awt/EtchedBorder`? And adding the word _Scaled_ to the title ? `ScaledEtchedBorderTest` ? would clarify the purpose of the test. > > What do you think? Thank you, Alisen, for renaming the test file. I am also for moving the test from `test/jdk/java/awt/TitledBorder` to `test/jdk/java/awt/EtchedBorder` where it belongs. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Fri May 20 13:35:00 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 May 2022 13:35:00 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 17 May 2022 20:05:45 GMT, Phil Race wrote: > Actually I'm not sure why only Win L&F is tested .. it is cross-platform and cross L&F code being changed It was exactly my point, we already [discussed it above](https://github.com/openjdk/jdk/pull/7449#discussion_r836586231). The updated test uses `EtchedBorder` explicitly and it is not Look-and-Feel-specific, it can run on any platform. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From brett.okken.os at gmail.com Fri May 20 14:07:05 2022 From: brett.okken.os at gmail.com (Brett Okken) Date: Fri, 20 May 2022 09:07:05 -0500 Subject: JDK-8274735, JPEG compression in a TIFF container, openjdk/jdk/pull/7849 In-Reply-To: References: <4b94671b-6cb3-0ff3-a646-018e7cf33ba4@gmail.com> <82f5f75e-cf0f-d447-ce58-0cacf00dcb6e@oracle.com> Message-ID: JPEG support for RGB with transparency/alpha channel is pretty spotty. https://stackoverflow.com/a/57626892/676877 On Fri, May 20, 2022 at 8:12 AM Michal Karm wrote: > I stepped the flow in a debugger and I narrowed > down the reproducer to a more focused, simpler > description and test data: > > https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md > > TL;DR: > > JPEG compressed RGB image in TIFF with transparency makes > the TIFF decoder to push 4 components data to the JPEG reader. > > The JPEG reader wrongly guesses that the data is CMYK now (based on the > number > of components). > > If the image is GRAYSCALE though, it ends up in Unsupported Image Type > because JPEG reader doesn't try to guess it's CMYK. > > > Solution...I don't know. > > Would it make sense if I transform the data to the number of > components the JPEG reader expects? > All the necessary information is there in the TIFF metadata, > e.g. it knows the space is RGB and not CMYK, it knows that there > is a transparency saved with the tile. > > THX for hints > > Karm > > > On 5/17/22 21:52, Philip Race wrote: > > This could be a bug in the TIFF plugin. > > Hard to say without debugging it. > > > > -phil. > > > > > > On 5/17/22 7:04 AM, Michal Karm wrote: > >> Hello, > >> > >> There used to be an Unsupported Image Type exception thrown > >> when one wanted to decode a TIFF container with JPEG compressed image. > >> > >> That behavior has changed, there is no exception now, although the > >> resulting image is incorrect. > >> > >> I outlined the details in this doc [1], including a small reproducer. > >> > >> The test image is not anything from a fuzzer, it's just me > >> clicking Export As in GIMP. > >> > >> Thanks for feedback > >> > >> Cheers > >> Karm > >> > >> > >> [1] > >> > https://urldefense.com/v3/__https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md__;!!ACWV5N9M2RV99hQ!Kw41ShsuTSfpVPMZFrXmdQ7ZETNdkLTk9Xd1NDWELvCXV0fyIqg4sXi5Z1aYfjMoG-5fS0gki8dnN8bQjSYM0g$ > >> > >> > >> Karm Michal Babacek > >> > > > > > Michal Karm Babacek > > -- > Sent from my Hosaka Ono-Sendai Cyberspace 7 > From achung at openjdk.java.net Fri May 20 16:52:07 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Fri, 20 May 2022 16:52:07 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v16] In-Reply-To: References: Message-ID: <-VoKpWfZtpc1rIB5H1Ie_mxkajmzfY3td8P1ZctTTvQ=.eedac556-5b85-4cf3-8fa7-0a65c77f3fd5@github.com> > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: made suggested changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/e32e6c08..b17cdab0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=14-15 Stats: 513 lines in 4 files changed: 255 ins; 248 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From achung at openjdk.java.net Fri May 20 16:52:10 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Fri, 20 May 2022 16:52:10 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v15] In-Reply-To: References: <4PMfzG5CywuNzqt1H0kVm8DKIyOR1CLp7j4BTcrwqzU=.efd72427-4ba9-4543-b847-a9d5d3478af3@github.com> Message-ID: On Tue, 17 May 2022 20:29:16 GMT, Phil Race wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed test, renamed some methods, updated error messages, updated test > > src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java line 164: > >> 162: stkWidth = (int) Math.floor(Math.min(at.getScaleX(),at.getScaleY())); >> 163: ((Graphics2D) g).setStroke(new BasicStroke((float) stkWidth)); >> 164: } > > This reminds me .. did you try STROKE_PURE ? If so does it make any difference ? > https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/RenderingHints.html#KEY_STROKE_CONTROL I don't think setting it to STROKE_PURE changed anything ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From achung at openjdk.java.net Fri May 20 16:55:43 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Fri, 20 May 2022 16:55:43 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v17] In-Reply-To: References: Message-ID: > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: reverted copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/b17cdab0..65200a23 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Fri May 20 17:38:56 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 20 May 2022 17:38:56 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v14] In-Reply-To: References: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> Message-ID: On Fri, 20 May 2022 13:34:43 GMT, Alexey Ivanov wrote: > > One more thing: the test now uses `EtchedBorder` only, shall it be moved to `test/jdk/java/awt/EtchedBorder`? And adding the word _Scaled_ to the title ? `ScaledEtchedBorderTest` ? would clarify the purpose of the test. > > What do you think? > > Thank you, Alisen, for renaming the test file. I am also for moving the test from `test/jdk/java/awt/TitledBorder` to `test/jdk/java/awt/EtchedBorder` where it belongs. The test should be under test/jdk/javax/swing/border/ not java/awt ! ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Fri May 20 17:42:46 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 20 May 2022 17:42:46 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v17] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 16:55:43 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > reverted copyright year test/jdk/java/awt/EtchedBorder/ScaledEtchedBorderTest.java line 77: > 75: } > 76: > 77: frame.dispose(); the dispose needs to be inside invokeAndWait too .. oh there's more than that you are creating a frame in each call to createGUI() and yet only ever dispose the last frame. so that call to dispose needs to be an invokeAndWait inside the loop ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From philip.race at oracle.com Fri May 20 17:50:31 2022 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 May 2022 10:50:31 -0700 Subject: JDK-8274735, JPEG compression in a TIFF container, openjdk/jdk/pull/7849 In-Reply-To: References: <4b94671b-6cb3-0ff3-a646-018e7cf33ba4@gmail.com> <82f5f75e-cf0f-d447-ce58-0cacf00dcb6e@oracle.com> Message-ID: <9add3fda-3246-be8c-0b71-e340900563cb@oracle.com> Identifying the intended color space of a JPEG is so much guesswork .. and we've not had support for ARGB since JDK 10 which was the last release to contain the Sun/Oracle "closed" support for that (from Kodak!) and OpenJDK NEVER had it. See https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/imageio/metadata/doc-files/jpeg_metadata.html Optional ColorSpace support: Handling of PhotoYCC (YCC), PhotoYCCA (YCCA), RGBA and YCbCrA color spaces by the standard plugin, as described below, is dependent on capabilities of the libraries used to interpret the JPEG data. Thus all consequential behaviors are optional. If the support is not available when decoding, the color space will be treated as unrecognized and the appropriate default color space for the specified number of component channels may be used So if you have ARGB you are in the lap of the Gods .. I think before the latest change there was no default 4 component space, so you got an exception, now there's something we default to assuming we are seeing .. -phil On 5/20/22 7:07 AM, Brett Okken wrote: > JPEG support for RGB with transparency/alpha channel is pretty spotty. > https://stackoverflow.com/a/57626892/676877 > > On Fri, May 20, 2022 at 8:12 AM Michal Karm > wrote: > > I stepped the flow in a debugger and I narrowed > down the reproducer to a more focused, simpler > description and test data: > > https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md > > TL;DR: > > JPEG compressed RGB image in TIFF with transparency makes > the TIFF decoder to push 4 components data to the JPEG reader. > > The JPEG reader wrongly guesses that the data is CMYK now (based > on the number > of components). > > If the image is GRAYSCALE though, it ends up in Unsupported Image Type > because JPEG reader doesn't try to guess it's CMYK. > > > Solution...I don't know. > > Would it make sense if I transform the data to the number of > components the JPEG reader expects? > All the necessary information is there in the TIFF metadata, > e.g. it knows the space is RGB and not CMYK, it knows that there > is a transparency saved with the tile. > > THX for hints > > Karm > > > On 5/17/22 21:52, Philip Race wrote: > > This could be a bug in the TIFF plugin. > > Hard to say without debugging it. > > > > -phil. > > > > > > On 5/17/22 7:04 AM, Michal Karm wrote: > >> Hello, > >> > >> There used to be an Unsupported Image Type exception thrown > >> when one wanted to decode a TIFF container with JPEG compressed > image. > >> > >> That behavior has changed, there is no exception now, although the > >> resulting image is incorrect. > >> > >> I outlined the details in this doc [1], including a small > reproducer. > >> > >> The test image is not anything from a fuzzer, it's just me > >> clicking Export As in GIMP. > >> > >> Thanks for feedback > >> > >> Cheers > >> Karm > >> > >> > >> [1] > >> > https://urldefense.com/v3/__https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md__;!!ACWV5N9M2RV99hQ!Kw41ShsuTSfpVPMZFrXmdQ7ZETNdkLTk9Xd1NDWELvCXV0fyIqg4sXi5Z1aYfjMoG-5fS0gki8dnN8bQjSYM0g$ > > >> > >> > >> Karm Michal Babacek > >> > > > > > Michal Karm Babacek > > -- > Sent from my Hosaka Ono-Sendai Cyberspace 7 > From philip.race at oracle.com Fri May 20 18:00:30 2022 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 May 2022 11:00:30 -0700 Subject: Unexpected EOFException in ImageReaderSpi.canDecodeInput In-Reply-To: <0376c10d-d9f6-d28c-8bad-776307d6724f@geomatys.com> References: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> <5f1eed65-78a6-f7a5-ed6b-a6c5bb09a106@geomatys.com> <0376c10d-d9f6-d28c-8bad-776307d6724f@geomatys.com> Message-ID: <6a2549f2-3dba-8404-76fa-64ac827cc299@oracle.com> OK .. we can probably take the proposed change, but there's no guarantee it won't still happen with 3rd party external plugins. I've filed the bug for you : https://bugs.openjdk.java.net/browse/JDK-8287102 -phil. On 5/18/22 2:47 AM, Martin Desruisseaux wrote: > Hello Philip > > Le 17/05/2022 ? 20:36, Philip Race a ?crit?: > >> Why is it unexpected ? >> > The purpose of ImageReaderSpi.canDecodeInput(Object) is to tell if the > source object seems to be supported by the reader. If the file is too > small, it is not supported by the reader. So a return value of false > is what I would expect from the method contract, because the method is > capable to provide a clear answer to the question "does it seems a > valid file?" > > By contrast, I would expect IOException to be thrown only if an > unexpected error prevents canDecodeInput(Object) from fulfilling its > method contract, e.g. a lost of internet connection prevents the > reader to check the magic number. EOFException does not met that > criterion for the reason stated above. > > >> The method declares that it throws IOException .. which if thrown >> clearly means the stream can't be de-coded. >> > In my understanding of the method contract, if the stream can not be > decoded, this is indicated by a return value of false rather than an > IOException. In the context of ImageReaderSpi.canDecodeInput(Object), > I interpret IOException as an error that prevent the method from > answering the question "does it seems a valid file?" > > >> But this fix is still putting it on each plugin to behave itself .. >> and we already handle that in the ImageIO class >> although I think it isn't perfect, as it still relies on co-operation >> with regard to mark() >> >> And if you call this directly, you can handle that just as well >> yourself .. and still can't trust extra >> plugins to behave ..,. so what is the use case for this fix ? > > In my case I handle the search of ImageReader myself. Contrarily to > ImageIO I do not catch IOException, because it may be a serious error > that prevent the plugin from answering its question. The stream may > now be in a corrupted state (it is not always a local file; it can be > on the cloud, a database BLOB, etc), and continuing with other readers > after the initial error can cause a series of confusing error > messages. Instead I let the first IOException propagates. The meaning > is very different than "unsupported format". > > I could catch the specific case of EOFException, but I don't because > 1) it relies on assumptions about how the plugin behave, 2) the input > may be an object other than ImageInputStream that we don't know how to > mark, and 3) EOFException can in some circumstances be a serious error > (i.e. EOFException occurring not in the stream given to the > canDecodeInput(Object) method, but is some auxiliary file that the > plugin needs to read). Only the plugin knows for sure if EOFException > means "unsupported format" or "serious error". > > ??? Regards, > > ?? ???? Martin > > From prr at openjdk.java.net Fri May 20 18:09:47 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 20 May 2022 18:09:47 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v3] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 00:53:27 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > SWinxy has updated the pull request incrementally with one additional commit since the last revision: > > Accidental mergers. > > I created a quick check to see if any other colors were different (only these three). For some odd reason "yellowgreen" and "yellow green" are different. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From aivanov at openjdk.java.net Fri May 20 18:31:03 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 May 2022 18:31:03 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v14] In-Reply-To: References: <724-pRZdDu_wUrqIU_yho7wCiJ7FaO6ep9d7aq0aXvI=.687f1a69-fa06-43bf-9dc9-205428a96cbc@github.com> Message-ID: <0plxobFUyt8wZ-lGeODbFs2uTFsnZ0bFYnG1eBWje0M=.38463095-21ea-486f-a33d-195b8420a747@github.com> On Fri, 20 May 2022 17:35:40 GMT, Phil Race wrote: > The test should be under test/jdk/javax/swing/border/ not java/awt ! Good catch! I never noticed the wrong package, I just copied the path. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Fri May 20 18:31:07 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 20 May 2022 18:31:07 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v17] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 16:55:43 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > reverted copyright year test/jdk/java/awt/EtchedBorder/ScaledEtchedBorderTest.java line 73: > 71: public static void main(String[] args) throws Exception { > 72: for (UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) { > 73: SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf)); I don't think there's a need to iterate over available Look-and-Feels, you use `EtchedBorder` directly. The default L&F or system L&F on each platform is enough. test/jdk/java/awt/EtchedBorder/ScaledEtchedBorderTest.java line 201: > 199: } > 200: > 201: frame = new JFrame("Swing Test"); Don't you want to go frameless? It would make the test headless. In [this comment](https://github.com/openjdk/jdk/pull/7449#discussion_r878130575), I provided [sample code](https://github.com/alisenchung/jdk/compare/8279614...aivanov-jdk:alisen-8279614-titledBorder) which works without creating frame: just panels and borders. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Fri May 20 19:25:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 20 May 2022 19:25:57 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked with sound keyword [v2] In-Reply-To: References: Message-ID: > This fix adds "headful sound" keywords to a number of javax/sound jtreg tests > > The jtreg javax.sound tests are written in such a way that if a needed audio device > or other platform resource is not available, they just exit with a "pass" for the test. > It is as if headful tests just swallowed HeadlessException and issued a pass. > If we allowed that we'd be effectively testing almost nothing of real importance. > > Currently almost all sound tests have no keyword like "headful" to indicate they > may need access to a hardware resource to do anything useful so a similar > situation arises there except when someone runs those tests manually on > a local system which has audio devices. > > Of course "headful" and "audio device" aren't exactly interchangeable terms > but if tests are allowed to be run - or worse usually or always run - in a situation > where they potentially are on a system without an audio device (a headless VM) or are running in > a session which doesn't have full desktop access - which may in some > cases be how audio device access is granted, then they are more likely > to be running in this scenario where the testing isn't valid. > > Another point is that headful tests must be run one at a time - no concurrency because > you can't have multiple tests moving the mouse at the same time > Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM > When tests that really need access to an audio device are run it is probably safer to consider > the headful attribute as implying one test at a time is best .. granted on a desktop it isn't > usual for a single app to be able to monopolize access to a speaker, but for input devices > that is what you'd generally expect. > > By no means am I sure that the tests being updated here are the full set that need tagging. > There are a lot of tests and they are all known to pass on systems with NO audio > devices, so the search has been for tests which call APIs which will definitely > need access to some device in order to do anything useful. > So likely there are more to be added - either by a reviewer pointing them out or by later discovery. > Alternatively we could mark ALL sound tests headful .. but given where we are starting from > that might be erring unnecessarily far in the opposite direction. > > By adding both headful and sound keywords it gives options to someone who > wants to identify the tests and perhaps run just tests which need "sound" on some > config they know supports audio but isn't headful. Phil Race has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into sound_tests Merge master - 8275170: Some jtreg sound tests should be marked headful ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6086/files - new: https://git.openjdk.java.net/jdk/pull/6086/files/5439d6c7..98d02ae2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=00-01 Stats: 1918540 lines in 11028 files changed: 1139190 ins; 686368 del; 92982 mod Patch: https://git.openjdk.java.net/jdk/pull/6086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6086/head:pull/6086 PR: https://git.openjdk.java.net/jdk/pull/6086 From kizune at openjdk.java.net Fri May 20 21:20:18 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 20 May 2022 21:20:18 GMT Subject: RFR: 8284690: [macos] VoiceOver : Getting java.lang.IllegalArgumentException: Invalid location on Editable JComboBox Message-ID: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> Check for the available range on the document model and adjust text range request accordingly. ------------- Commit messages: - 8284690: [macos] VoiceOver : Getting java.lang.IllegalArgumentException: Invalid location on Editable JComboBoxaaaa Changes: https://git.openjdk.java.net/jdk/pull/8820/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8820&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284690 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8820.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8820/head:pull/8820 PR: https://git.openjdk.java.net/jdk/pull/8820 From kizune at openjdk.java.net Fri May 20 21:22:50 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 20 May 2022 21:22:50 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes [v3] In-Reply-To: References: Message-ID: > Moving cache invalidation from the clearCache method to a createRowWithIndex method > eliminating race condition that causes crash. Now clearCache just notifies that cache > is invalid and should be regenerated next time it is being accessed. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8636/files - new: https://git.openjdk.java.net/jdk/pull/8636/files/11f25a16..ffee6ee6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8636&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8636&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8636.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8636/head:pull/8636 PR: https://git.openjdk.java.net/jdk/pull/8636 From kizune at openjdk.java.net Fri May 20 21:22:50 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 20 May 2022 21:22:50 GMT Subject: RFR: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:29:42 GMT, Phil Race wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a test case. > > test/jdk/java/awt/a11y/AccessibleJTableTest.java line 81: > >> 79: public void createUIDraggable() { >> 80: INSTRUCTIONS = "INSTRUCTIONS:\n" >> 81: + "Check that table is properly updated when culumn order is changed.\n\n" > > culumn -> column Oops. Thanks, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From kizune at openjdk.java.net Fri May 20 21:22:52 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 20 May 2022 21:22:52 GMT Subject: Integrated: 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes In-Reply-To: References: Message-ID: On Tue, 10 May 2022 17:34:34 GMT, Alexander Zuev wrote: > Moving cache invalidation from the clearCache method to a createRowWithIndex method > eliminating race condition that causes crash. Now clearCache just notifies that cache > is invalid and should be regenerated next time it is being accessed. This pull request has now been integrated. Changeset: b33c6e52 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/b33c6e52c1ba675efdae6e48a9ff022b2b24513c Stats: 47 lines in 3 files changed: 38 ins; 4 del; 5 mod 8286266: [macos] Voice over moving JTable column to be the first column JVM crashes Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8636 From kizune at openjdk.java.net Fri May 20 21:25:49 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 20 May 2022 21:25:49 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked with sound keyword [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 19:25:57 GMT, Phil Race wrote: >> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests >> >> The jtreg javax.sound tests are written in such a way that if a needed audio device >> or other platform resource is not available, they just exit with a "pass" for the test. >> It is as if headful tests just swallowed HeadlessException and issued a pass. >> If we allowed that we'd be effectively testing almost nothing of real importance. >> >> Currently almost all sound tests have no keyword like "headful" to indicate they >> may need access to a hardware resource to do anything useful so a similar >> situation arises there except when someone runs those tests manually on >> a local system which has audio devices. >> >> Of course "headful" and "audio device" aren't exactly interchangeable terms >> but if tests are allowed to be run - or worse usually or always run - in a situation >> where they potentially are on a system without an audio device (a headless VM) or are running in >> a session which doesn't have full desktop access - which may in some >> cases be how audio device access is granted, then they are more likely >> to be running in this scenario where the testing isn't valid. >> >> Another point is that headful tests must be run one at a time - no concurrency because >> you can't have multiple tests moving the mouse at the same time >> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM >> When tests that really need access to an audio device are run it is probably safer to consider >> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't >> usual for a single app to be able to monopolize access to a speaker, but for input devices >> that is what you'd generally expect. >> >> By no means am I sure that the tests being updated here are the full set that need tagging. >> There are a lot of tests and they are all known to pass on systems with NO audio >> devices, so the search has been for tests which call APIs which will definitely >> need access to some device in order to do anything useful. >> So likely there are more to be added - either by a reviewer pointing them out or by later discovery. >> Alternatively we could mark ALL sound tests headful .. but given where we are starting from >> that might be erring unnecessarily far in the opposite direction. >> >> By adding both headful and sound keywords it gives options to someone who >> wants to identify the tests and perhaps run just tests which need "sound" on some >> config they know supports audio but isn't headful. > > Phil Race has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sound_tests > Merge master > - 8275170: Some jtreg sound tests should be marked headful Looks right to me. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6086 From prr at openjdk.java.net Fri May 20 22:31:38 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 20 May 2022 22:31:38 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked with sound keyword [v3] In-Reply-To: References: Message-ID: > This fix adds "headful sound" keywords to a number of javax/sound jtreg tests > > The jtreg javax.sound tests are written in such a way that if a needed audio device > or other platform resource is not available, they just exit with a "pass" for the test. > It is as if headful tests just swallowed HeadlessException and issued a pass. > If we allowed that we'd be effectively testing almost nothing of real importance. > > Currently almost all sound tests have no keyword like "headful" to indicate they > may need access to a hardware resource to do anything useful so a similar > situation arises there except when someone runs those tests manually on > a local system which has audio devices. > > Of course "headful" and "audio device" aren't exactly interchangeable terms > but if tests are allowed to be run - or worse usually or always run - in a situation > where they potentially are on a system without an audio device (a headless VM) or are running in > a session which doesn't have full desktop access - which may in some > cases be how audio device access is granted, then they are more likely > to be running in this scenario where the testing isn't valid. > > Another point is that headful tests must be run one at a time - no concurrency because > you can't have multiple tests moving the mouse at the same time > Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM > When tests that really need access to an audio device are run it is probably safer to consider > the headful attribute as implying one test at a time is best .. granted on a desktop it isn't > usual for a single app to be able to monopolize access to a speaker, but for input devices > that is what you'd generally expect. > > By no means am I sure that the tests being updated here are the full set that need tagging. > There are a lot of tests and they are all known to pass on systems with NO audio > devices, so the search has been for tests which call APIs which will definitely > need access to some device in order to do anything useful. > So likely there are more to be added - either by a reviewer pointing them out or by later discovery. > Alternatively we could mark ALL sound tests headful .. but given where we are starting from > that might be erring unnecessarily far in the opposite direction. > > By adding both headful and sound keywords it gives options to someone who > wants to identify the tests and perhaps run just tests which need "sound" on some > config they know supports audio but isn't headful. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8275170 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6086/files - new: https://git.openjdk.java.net/jdk/pull/6086/files/98d02ae2..b7e0443e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6086&range=01-02 Stats: 57 lines in 57 files changed: 0 ins; 0 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/6086.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6086/head:pull/6086 PR: https://git.openjdk.java.net/jdk/pull/6086 From prr at openjdk.java.net Fri May 20 22:31:47 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 20 May 2022 22:31:47 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked with sound keyword [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 19:25:57 GMT, Phil Race wrote: >> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests >> >> The jtreg javax.sound tests are written in such a way that if a needed audio device >> or other platform resource is not available, they just exit with a "pass" for the test. >> It is as if headful tests just swallowed HeadlessException and issued a pass. >> If we allowed that we'd be effectively testing almost nothing of real importance. >> >> Currently almost all sound tests have no keyword like "headful" to indicate they >> may need access to a hardware resource to do anything useful so a similar >> situation arises there except when someone runs those tests manually on >> a local system which has audio devices. >> >> Of course "headful" and "audio device" aren't exactly interchangeable terms >> but if tests are allowed to be run - or worse usually or always run - in a situation >> where they potentially are on a system without an audio device (a headless VM) or are running in >> a session which doesn't have full desktop access - which may in some >> cases be how audio device access is granted, then they are more likely >> to be running in this scenario where the testing isn't valid. >> >> Another point is that headful tests must be run one at a time - no concurrency because >> you can't have multiple tests moving the mouse at the same time >> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM >> When tests that really need access to an audio device are run it is probably safer to consider >> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't >> usual for a single app to be able to monopolize access to a speaker, but for input devices >> that is what you'd generally expect. >> >> By no means am I sure that the tests being updated here are the full set that need tagging. >> There are a lot of tests and they are all known to pass on systems with NO audio >> devices, so the search has been for tests which call APIs which will definitely >> need access to some device in order to do anything useful. >> So likely there are more to be added - either by a reviewer pointing them out or by later discovery. >> Alternatively we could mark ALL sound tests headful .. but given where we are starting from >> that might be erring unnecessarily far in the opposite direction. >> >> By adding both headful and sound keywords it gives options to someone who >> wants to identify the tests and perhaps run just tests which need "sound" on some >> config they know supports audio but isn't headful. > > Phil Race has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into sound_tests > Merge master > - 8275170: Some jtreg sound tests should be marked headful The current version only adds the 'sound' keyword. So it doesn't carry any of the implications of headful. ------------- PR: https://git.openjdk.java.net/jdk/pull/6086 From serb at openjdk.java.net Sat May 21 06:45:48 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 21 May 2022 06:45:48 GMT Subject: RFR: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 18:34:57 GMT, Phil Race wrote: >> This is a theoretical/potential case of calling JNI methods with a possible execption pending. >> As noted in the eval of the bug report, we no longer follow the practice that AWT_LOCK is >> called only at the start of a native method and AWT_UNLOCK at the end, if indeed we ever did. >> But it seems to be implied in how they are handling exceptions. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8285399 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8493 From serb at openjdk.java.net Sat May 21 06:50:40 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 21 May 2022 06:50:40 GMT Subject: RFR: 8284690: [macos] VoiceOver : Getting java.lang.IllegalArgumentException: Invalid location on Editable JComboBox In-Reply-To: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> References: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> Message-ID: <9mEda0lfLVBkwsQpo7uPp4HSSTAzxeKWxCEx45HU1ic=.4bf3c523-6642-4993-9642-3de365273410@github.com> On Fri, 20 May 2022 21:13:35 GMT, Alexander Zuev wrote: > Check for the available range on the document model and adjust text range request accordingly. src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibleText.java line 293: > 291: int currentLength = aet.getCharCount(); > 292: return aet.getTextRange(Math.min(currentLength, location), > 293: Math.min(currentLength, location + length)); It will be good to update the spec of the AccessibleEditableText by this or separate PR, right now it does not mention any exceptions. ------------- PR: https://git.openjdk.java.net/jdk/pull/8820 From serb at openjdk.java.net Sat May 21 06:51:55 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 21 May 2022 06:51:55 GMT Subject: RFR: 8286786: [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java still fails In-Reply-To: References: Message-ID: On Fri, 20 May 2022 09:07:29 GMT, Prasanta Sadhukhan wrote: > In PR#[8380](https://github.com/openjdk/jdk/pull/8380) we have reduced the error tolerance from 25 to 1 so no need of exact color check which is causing failure in specific M1 iMac system because of minimalistic color difference of "1" > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > `so modified to use the tolerance check for all L&Fs. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8804 From serb at openjdk.java.net Sat May 21 06:52:43 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 21 May 2022 06:52:43 GMT Subject: RFR: 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver In-Reply-To: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> References: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> Message-ID: On Thu, 19 May 2022 23:46:48 GMT, Phil Race wrote: > This adds the Microsoft Basic Render Driver to our "bad hardware" list so that we don't use that pipeline there. > We have at least the one test that fails there and I am not sure we get any benefit from this. > I'm sure Microsoft need to provide for apps that have only a D3D option, but that isn't the JDK case. > > FYI there was a PR a while back about problem listing that failing test : https://github.com/openjdk/jdk/pull/5930 > but we don't need to do that with this change - nor worry about similar problems with other tests. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8797 From ysuenaga at openjdk.java.net Sat May 21 13:11:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 21 May 2022 13:11:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:32:42 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > revert changes for memnode.cpp and type.cpp In case of stringop-overflow errors (bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp) noted that offset of `Array::_data` might be [-2147483648, -1]. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From prr at openjdk.java.net Sat May 21 16:08:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Sat, 21 May 2022 16:08:50 GMT Subject: Integrated: 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 In-Reply-To: References: Message-ID: On Sun, 1 May 2022 21:25:27 GMT, Phil Race wrote: > This is a theoretical/potential case of calling JNI methods with a possible execption pending. > As noted in the eval of the bug report, we no longer follow the practice that AWT_LOCK is > called only at the start of a native method and AWT_UNLOCK at the end, if indeed we ever did. > But it seems to be implied in how they are handling exceptions. This pull request has now been integrated. Changeset: c156bcc5 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/c156bcc599534ae989bc9cbd001e7c150da8096c Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod 8285399: JNI exception pending in awt_GraphicsEnv.c:1432 Reviewed-by: azvegint, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/8493 From kbarrett at openjdk.java.net Sun May 22 03:18:48 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 03:18:48 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:38:55 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5970: >> >>> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 5969: _cp->symbol_at_put(hidden_index, _class_name); >>> 5970: PRAGMA_DIAG_POP >> >> I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) > > Like the others, it is caused by `Array::at_put()`. > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, > inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ doesn't have flexible array members. The compiler is completely justified in complaining about the apparently out-of-bounds accesses. There is a "well-known" (though moderately ugly) approach to doing flexible array members in C++. Something like this: T* data() { return reinterpret_cast( reinterpret_cast(this) + data_offset()); } where `data_offset()` is new and private: static size_t data_offset() { return offset_of(Array, _data); } Use `data()` everywhere instead of using `_data` directly. There are other places in HotSpot that use this kind of approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 05:03:57 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 05:03:57 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:43:02 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: >> >>> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 102: *dest = op(bits, *dest); >>> 103: PRAGMA_DIAG_POP >> >> I see no stringop here. I'm still trying to understand what the compiler is complaining about. > > I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: > In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', > inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, > inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, > inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, > inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: I don't think this warning has anything to do with that NULL check. But I'm still not understanding what it is warning about. The "region of size 0" part of the warning message seems important, but I'm not (yet?) seeing how it could be coming up with that. The code involved here is pretty contorted... ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:40:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:40:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge remote-tracking branch 'upstream/master' into gcc12-warnings - Use getter function to access "_data" - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp - revert changes for memnode.cpp and type.cpp - Add assert to check the range of BasicType - Merge remote-tracking branch 'upstream/master' into HEAD - Revert change for java.c , parse_manifest.c , LinuxPackage.c - Calculate char offset before realloc() - Use return value from JLI_Snprintf - Avoid pragma error in before GCC 12 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07 Stats: 42 lines in 7 files changed: 26 ins; 1 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:40:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:40:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 03:15:20 GMT, Kim Barrett wrote: >> Like the others, it is caused by `Array::at_put()`. >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, >> inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: > > `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ > doesn't have flexible array members. The compiler is completely justified in > complaining about the apparently out-of-bounds accesses. > > There is a "well-known" (though moderately ugly) approach to doing flexible > array members in C++. Something like this: > > > T* data() { > return reinterpret_cast( > reinterpret_cast(this) + data_offset()); > } > > > where `data_offset()` is new and private: > > > static size_t data_offset() { > return offset_of(Array, _data); > } > > > Use `data()` everywhere instead of using `_data` directly. > > There are other places in HotSpot that use this kind of approach. Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:48:47 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:48:47 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 05:00:21 GMT, Kim Barrett wrote: >> I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: >> In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', >> inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, >> inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, >> inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, >> inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: > > I don't think this warning has anything to do with that NULL check. But I'm > still not understanding what it is warning about. The "region of size 0" part > of the warning message seems important, but I'm not (yet?) seeing how it could > be coming up with that. The code involved here is pretty contorted... It might be GCC bug... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From duke at openjdk.java.net Sun May 22 09:15:15 2022 From: duke at openjdk.java.net (Jeremy) Date: Sun, 22 May 2022 09:15:15 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Message-ID: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> This resolves an occasional unit test failure in Path2D.UnitTest. The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. ------------- Commit messages: - Merge branch 'master' into JDK-8176501 - Merge pull request #1 from openjdk/master - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box - ... and 16 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...5aebb1b7 Changes: https://git.openjdk.java.net/jdk/pull/8828/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8828&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8176501 Stats: 68 lines in 2 files changed: 37 ins; 5 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/8828.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8828/head:pull/8828 PR: https://git.openjdk.java.net/jdk/pull/8828 From lbourges at openjdk.java.net Sun May 22 10:33:54 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 22 May 2022 10:33:54 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box In-Reply-To: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: On Sun, 22 May 2022 09:08:03 GMT, Jeremy wrote: > This resolves an occasional unit test failure in Path2D.UnitTest. > > The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. > > This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. > > This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. A general comment from an openjdk comitter, not reviewer: It looks overall good, I would have named moveX/Y as startX/Y, as usual. Should we test closed paths and non-closed paths to ensure bounds2d is correct in both case ? Maybe it is already the case. Congratulations, Laurent ------------- PR: https://git.openjdk.java.net/jdk/pull/8828 From kbarrett at openjdk.java.net Sun May 22 16:44:58 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 16:44:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <3CBxbI5futoRYrvWQY5-0hUsWNb8fsZWF2goyqFOgY0=.0328a1d2-126e-4f5f-a6d7-ba638499eefd@github.com> On Sun, 22 May 2022 08:35:54 GMT, Yasumasa Suenaga wrote: >> `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ >> doesn't have flexible array members. The compiler is completely justified in >> complaining about the apparently out-of-bounds accesses. >> >> There is a "well-known" (though moderately ugly) approach to doing flexible >> array members in C++. Something like this: >> >> >> T* data() { >> return reinterpret_cast( >> reinterpret_cast(this) + data_offset()); >> } >> >> >> where `data_offset()` is new and private: >> >> >> static size_t data_offset() { >> return offset_of(Array, _data); >> } >> >> >> Use `data()` everywhere instead of using `_data` directly. >> >> There are other places in HotSpot that use this kind of approach. > > Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion. Good. I see you found and used the existing `base_offset_in_bytes` (which I'd overlooked), rather than using my suggested `data_offset`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 16:48:42 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 16:48:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 08:45:48 GMT, Yasumasa Suenaga wrote: >> I don't think this warning has anything to do with that NULL check. But I'm >> still not understanding what it is warning about. The "region of size 0" part >> of the warning message seems important, but I'm not (yet?) seeing how it could >> be coming up with that. The code involved here is pretty contorted... > > It might be GCC bug... > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 > > This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). I don't see the similarity. That gcc bug is about literals used as addresses, which get treated (suggested inappropriately) as NULL+offset, with NULL+offset being a cause of warnings. I don't see that happening in our case. That is, in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL that I can see. It's hard for me to investigate this any further just by perusing the code, so I'm in the process of getting set up to build with gcc12.x. That will let me do some experiments. It may take me a few days to get to that point though. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From duke at openjdk.java.net Sun May 22 17:38:07 2022 From: duke at openjdk.java.net (Martin Desruisseaux) Date: Sun, 22 May 2022 17:38:07 GMT Subject: RFR: 8287102: ImageReaderSPI.canDecode should not throw EOFException Message-ID: Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted. The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are: * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value. * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method. ------------- Commit messages: - 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short Changes: https://git.openjdk.java.net/jdk/pull/8700/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8700&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287102 Stats: 150 lines in 8 files changed: 129 ins; 9 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8700.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8700/head:pull/8700 PR: https://git.openjdk.java.net/jdk/pull/8700 From martin.desruisseaux at geomatys.com Sun May 22 17:44:54 2022 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Sun, 22 May 2022 19:44:54 +0200 Subject: Unexpected EOFException in ImageReaderSpi.canDecodeInput In-Reply-To: <6a2549f2-3dba-8404-76fa-64ac827cc299@oracle.com> References: <57d6b1ba-224b-8178-07d0-0e3f9320ddf8@geomatys.com> <5f1eed65-78a6-f7a5-ed6b-a6c5bb09a106@geomatys.com> <0376c10d-d9f6-d28c-8bad-776307d6724f@geomatys.com> <6a2549f2-3dba-8404-76fa-64ac827cc299@oracle.com> Message-ID: <244288ea-f643-4e37-1adb-55c33ca8c121@geomatys.com> Le 20/05/2022 ? 20:00, Philip Race a ?crit?: > OK .. we can probably take the proposed change, but there's no > guarantee it won't > still happen with 3rd party external plugins. > > I've filed the bug for you : > https://bugs.openjdk.java.net/browse/JDK-8287102 Thanks! I have rebased the pull request and edited the title to reference the bug. ??? Martin From duke at openjdk.java.net Sun May 22 17:57:27 2022 From: duke at openjdk.java.net (Jeremy) Date: Sun, 22 May 2022 17:57:27 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box [v2] In-Reply-To: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: > This resolves an occasional unit test failure in Path2D.UnitTest. > > The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. > > This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. > > This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. Jeremy has updated the pull request incrementally with one additional commit since the last revision: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8828/files - new: https://git.openjdk.java.net/jdk/pull/8828/files/5aebb1b7..88346f4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8828&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8828&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8828.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8828/head:pull/8828 PR: https://git.openjdk.java.net/jdk/pull/8828 From prr at openjdk.java.net Sun May 22 20:05:35 2022 From: prr at openjdk.java.net (Phil Race) Date: Sun, 22 May 2022 20:05:35 GMT Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short In-Reply-To: References: Message-ID: On Fri, 13 May 2022 12:23:24 GMT, Martin Desruisseaux wrote: > Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted. > > The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are: > > * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value. > * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method. test/jdk/javax/imageio/plugins/shared/CanDecodeTest.java line 49: > 47: ImageReader reader = > 48: ImageIO.getImageReadersByFormatName("BMP").next(); > 49: ImageReaderSpi spi = reader.getOriginatingProvider(); Isn't that supposed to have format, not "BMP" as the arg ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8700 From mickleness at gmail.com Sun May 22 21:56:56 2022 From: mickleness at gmail.com (Jeremy Wood) Date: Sun, 22 May 2022 21:56:56 +0000 Subject: Debugging Pre-Submit Test Failures Message-ID: I have a PR that is failing some Linux pre-submit tests, but I don?t have a linux machine handy to test against. I tried running the tests 3 times in case the failure was random, but it persists. Any pointers on how to debug/resolve this? The error mentions: # newfailures.txt # other_errors.txt Do those files explain the failures, and if so how do I access them? If I can get to a place where I understand Java code that is failing I can probably solve that, but I could use some help making sense of this output. Regards, - Jeremy From philip.race at oracle.com Sun May 22 22:14:39 2022 From: philip.race at oracle.com (Philip Race) Date: Sun, 22 May 2022 15:14:39 -0700 Subject: Debugging Pre-Submit Test Failures In-Reply-To: References: Message-ID: <0a653e5a-aae4-fe93-feba-5153681c7d46@oracle.com> Where are these files ? I can't see them. Is it something under? "Pre-submit tests - Linux x86" in the list of "Some checks were not successful" ? The reason I see for errors under there is just the odd "Error: Unable to find an artifact with the name: transient_jtreg_mickleness_88346f4d" Means nothing to me I'm afraid. And if you look at the open PRs https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr All of them seem to have *some* failures .. so I treat these as completely untrustworthy In any case NONE of the tests these actions will run are REMOTELY related to anything you can affect with changes to Path2D .. they only run hotspot, javac compiler tests and some very critical "core" tests for packages like java/lang They run NO java.desktop tests *at all* -phil. On 5/22/22 2:56 PM, Jeremy Wood wrote: > I have a PR that is failing > some Linux > pre-submit tests, but I don?t have a linux machine handy to test against. > > I tried running the tests 3 times in case the failure was random, but > it persists. > > Any pointers on how to debug/resolve this? The error mentions: > # newfailures.txt > # other_errors.txt > > Do those files explain the failures, and if so how do I access them? > > If I can get to a place where I understand Java code that is failing I > can probably solve that, but I could use some help making sense of > this output. > > Regards, > ?- Jeremy From philip.race at oracle.com Sun May 22 22:21:33 2022 From: philip.race at oracle.com (Philip Race) Date: Sun, 22 May 2022 15:21:33 -0700 Subject: Debugging Pre-Submit Test Failures In-Reply-To: <0a653e5a-aae4-fe93-feba-5153681c7d46@oracle.com> References: <0a653e5a-aae4-fe93-feba-5153681c7d46@oracle.com> Message-ID: Oh and if it "x86" then it really isn't something you need to worry about much since "x64" is passing and maintaining x86 is someone's hobby perhaps .. but not a big issue for mainline. I don't know why we even have that there. -phil On 5/22/22 3:14 PM, Philip Race wrote: > Where are these files ? I can't see them. > > Is it something under? "Pre-submit tests - Linux x86" in the list of > "Some checks were not successful" ? > > The reason I see for errors under there is just the odd > "Error: Unable to find an artifact with the name: > transient_jtreg_mickleness_88346f4d" > > Means nothing to me I'm afraid. > > And if you look at the open PRs > https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr > All of them seem to have *some* failures .. so I treat these as > completely untrustworthy > > In any case NONE of the tests these actions will run are REMOTELY > related to anything you > can affect with changes to Path2D .. they only run hotspot, javac > compiler tests and some > very critical "core" tests for packages like java/lang > They run NO java.desktop tests *at all* > > > -phil. > > On 5/22/22 2:56 PM, Jeremy Wood wrote: >> I have a PR that is >> failing >> some Linux pre-submit tests, but I don?t have a linux machine handy >> to test against. >> >> I tried running the tests 3 times in case the failure was random, but >> it persists. >> >> Any pointers on how to debug/resolve this? The error mentions: >> # newfailures.txt >> # other_errors.txt >> >> Do those files explain the failures, and if so how do I access them? >> >> If I can get to a place where I understand Java code that is failing >> I can probably solve that, but I could use some help making sense of >> this output. >> >> Regards, >> ?- Jeremy > From duke at openjdk.java.net Sun May 22 23:05:54 2022 From: duke at openjdk.java.net (lukeu) Date: Sun, 22 May 2022 23:05:54 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v8] In-Reply-To: References: Message-ID: <9JIXYKfRmt9AEzDeUYtDraJJIxriSR41AkRXqEeuXOM=.8ac622cf-97d6-4da0-a02a-68ab5ef512fc@github.com> On Wed, 20 Apr 2022 23:35:10 GMT, lukeu wrote: >> Made a small change with the bottom line to match the left line of the border > >> Made a small change with the bottom line to match the left line of the border > > Great, that looks like it'll fix it so I won't test again, I'll defer to the others now for the code review. (I'd be happy to chip in there too, but I'm not sure if "random guy on github" is qualified/authorized to?) > @lukeu I've updated the fix and test, can you guys take a look? Hi, sorry for the delay! (i seem to be in crunch mode at work and home...) In my interactive testing, it all looks good at a range of scaling levels (Tested: 125, 150, 175, 225, 300, 350) ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From philip.race at oracle.com Sun May 22 23:13:38 2022 From: philip.race at oracle.com (Philip Race) Date: Sun, 22 May 2022 16:13:38 -0700 Subject: Debugging Pre-Submit Test Failures In-Reply-To: References: <0a653e5a-aae4-fe93-feba-5153681c7d46@oracle.com> Message-ID: Apparently Linux 86 is broken because Loom needs work for that port .. so really completely ignore it for now. -phil On 5/22/22 3:21 PM, Philip Race wrote: > Oh and if it "x86" then it really isn't something you need to worry > about much > since "x64" is passing and maintaining x86 is someone's hobby perhaps > .. but > not a big issue for mainline. I don't know why we even have that there. > > -phil > > On 5/22/22 3:14 PM, Philip Race wrote: >> Where are these files ? I can't see them. >> >> Is it something under? "Pre-submit tests - Linux x86" in the list of >> "Some checks were not successful" ? >> >> The reason I see for errors under there is just the odd >> "Error: Unable to find an artifact with the name: >> transient_jtreg_mickleness_88346f4d" >> >> Means nothing to me I'm afraid. >> >> And if you look at the open PRs >> https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr >> All of them seem to have *some* failures .. so I treat these as >> completely untrustworthy >> >> In any case NONE of the tests these actions will run are REMOTELY >> related to anything you >> can affect with changes to Path2D .. they only run hotspot, javac >> compiler tests and some >> very critical "core" tests for packages like java/lang >> They run NO java.desktop tests *at all* >> >> >> -phil. >> >> On 5/22/22 2:56 PM, Jeremy Wood wrote: >>> I have a PR that is >>> failing >>> some Linux pre-submit tests, but I don?t have a linux machine handy >>> to test against. >>> >>> I tried running the tests 3 times in case the failure was random, >>> but it persists. >>> >>> Any pointers on how to debug/resolve this? The error mentions: >>> # newfailures.txt >>> # other_errors.txt >>> >>> Do those files explain the failures, and if so how do I access them? >>> >>> If I can get to a place where I understand Java code that is failing >>> I can probably solve that, but I could use some help making sense of >>> this output. >>> >>> Regards, >>> ?- Jeremy >> > From duke at openjdk.java.net Mon May 23 07:11:15 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 23 May 2022 07:11:15 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F Message-ID: _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE. ------------- Commit messages: - header object set - Merge remote-tracking branch 'upstream/master' into branch_6429812 - Merge remote-tracking branch 'upstream/master' - Merge branch 'master' of github.com:TejeshR13/jdk - Merge branch 'openjdk:master' into master - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge branch 'master' of github.com:TejeshR13/jdk - Initial Commit. Changes: https://git.openjdk.java.net/jdk/pull/8830/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6429812 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8830.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8830/head:pull/8830 PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Mon May 23 08:09:20 2022 From: duke at openjdk.java.net (Martin Desruisseaux) Date: Mon, 23 May 2022 08:09:20 GMT Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short [v2] In-Reply-To: References: Message-ID: > Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted. > > The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are: > > * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value. > * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method. Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: Test all plugins, not only "BMP". ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8700/files - new: https://git.openjdk.java.net/jdk/pull/8700/files/a8737570..38f0cf34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8700&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8700&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8700.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8700/head:pull/8700 PR: https://git.openjdk.java.net/jdk/pull/8700 From duke at openjdk.java.net Mon May 23 08:56:49 2022 From: duke at openjdk.java.net (Jeremy) Date: Mon, 23 May 2022 08:56:49 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box [v2] In-Reply-To: References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: On Sun, 22 May 2022 17:57:27 GMT, Jeremy wrote: >> This resolves an occasional unit test failure in Path2D.UnitTest. >> >> The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. >> >> This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. >> >> This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box > > Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. I reworded the variables as Laurent suggested. Regarding explicitly testing certain paths: I don't mind adding more test cases, but for me the catch is exactly *which* cases to add? Since we don't have a specific known failure/concern in mind, what should we test? (for ex: an open/closed triangle? a C-shaped cubic bezier curve? something else?) Also (unrelated): I ran the current Path2D.UnitTest tonight on my Mac for a few hours. I reached 32,220 iterations without any errors. ------------- PR: https://git.openjdk.java.net/jdk/pull/8828 From aturbanov at openjdk.java.net Mon May 23 09:03:40 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 23 May 2022 09:03:40 GMT Subject: RFR: 8287148: Avoid redundant HashMap.containsKey calls in ExtendedKeyCodes.getExtendedKeyCodeForChar Message-ID: `sun.awt.ExtendedKeyCodes#regularKeyCodesMap` contains only non-null values. It means we can replace containsKey+get with get+null check. It's clearer and a bit faster. ------------- Commit messages: - [PATCH] Avoid redundant HashMap.containsKey calls in ExtendedKeyCodes Changes: https://git.openjdk.java.net/jdk/pull/8489/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8489&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287148 Stats: 18 lines in 1 file changed: 3 ins; 5 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8489.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8489/head:pull/8489 PR: https://git.openjdk.java.net/jdk/pull/8489 From asotona at openjdk.java.net Mon May 23 10:40:40 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 23 May 2022 10:40:40 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v9] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - Merge branch 'openjdk:master' into JDK-8244681 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base new case appeared in java.base by moving jdk.incubator.foreign code under java.base - Merge remote-tracking branch 'upstream/master' into JDK-8244681 # Conflicts: # make/test/BuildMicrobenchmark.gmk - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning description - 8244681: Add a warning for possibly lossy conversion in compound assignments recommended correction of the warning wording fixed typo in test method name - Merge branch 'openjdk:master' into JDK-8244681 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c9065915...455720ef ------------- Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08 Stats: 441 lines in 18 files changed: 438 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From asotona at openjdk.java.net Mon May 23 11:02:32 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 23 May 2022 11:02:32 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v10] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with two additional commits since the last revision: - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8599/files - new: https://git.openjdk.java.net/jdk/pull/8599/files/455720ef..4978c2a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08-09 Stats: 5 lines in 3 files changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599 From michal.babacek at gmail.com Mon May 23 15:39:14 2022 From: michal.babacek at gmail.com (Michal Karm) Date: Mon, 23 May 2022 17:39:14 +0200 Subject: JDK-8274735, JPEG compression in a TIFF container, openjdk/jdk/pull/7849 In-Reply-To: <9add3fda-3246-be8c-0b71-e340900563cb@oracle.com> References: <4b94671b-6cb3-0ff3-a646-018e7cf33ba4@gmail.com> <82f5f75e-cf0f-d447-ce58-0cacf00dcb6e@oracle.com> <9add3fda-3246-be8c-0b71-e340900563cb@oracle.com> Message-ID: <1e2a6dc8-a60e-f35f-699a-36cc8196850f@gmail.com> Thanks for taking the time to explain it. Inline... On 5/20/22 19:50, Philip Race wrote: > Identifying the intended color space of a JPEG is so much guesswork .. > > and we've not had support for ARGB since JDK 10 which was the last release > to contain the Sun/Oracle "closed" support for that (from Kodak!) and OpenJDK > NEVER had it. > > See > https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/imageio/metadata/doc-files/jpeg_metadata.html > > Optional ColorSpace support: Handling of PhotoYCC (YCC), PhotoYCCA (YCCA), RGBA > and YCbCrA color spaces by the standard plugin, as described below, is dependent > on capabilities of the libraries used to interpret the JPEG data. Thus all > consequential behaviors are optional. If the support is not available when > decoding, the color space will be treated as unrecognized and the appropriate > default color space for the specified number of component channels may be used > > So if you have ARGB you are in the lap of the Gods .. > thx, I digested the content and I think I get it. > I think before the latest change there was no default 4 component space, so you > got an exception, > now there's something we default to assuming we are seeing .. That is exactly the case. I would like a meaningful exception to be thrown so as one knows that the data are being interpreted incorrectly though. Something along these lines (tests included): https://github.com/openjdk/jdk/pull/8846 Why in TIFF reader and not in JPEG decompressor: Both GIMP and ImageMagic can create RGBA JPEG compressed TIFF without any warning for you, while producing RGBA JPEG with these common tools is something I didn't encounter. Cheers Karm > > -phil > > On 5/20/22 7:07 AM, Brett Okken wrote: >> JPEG support for RGB with transparency/alpha channel is pretty spotty. >> https://stackoverflow.com/a/57626892/676877 >> >> On Fri, May 20, 2022 at 8:12 AM Michal Karm wrote: >> >> I stepped the flow in a debugger and I narrowed >> down the reproducer to a more focused, simpler >> description and test data: >> >> https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md >> >> TL;DR: >> >> JPEG compressed RGB image in TIFF with transparency makes >> the TIFF decoder to push 4 components data to the JPEG reader. >> >> The JPEG reader wrongly guesses that the data is CMYK now (based on the >> number >> of components). >> >> If the image is GRAYSCALE though, it ends up in Unsupported Image Type >> because JPEG reader doesn't try to guess it's CMYK. >> >> >> Solution...I don't know. >> >> Would it make sense if I transform the data to the number of >> components the JPEG reader expects? >> All the necessary information is there in the TIFF metadata, >> e.g. it knows the space is RGB and not CMYK, it knows that there >> is a transparency saved with the tile. >> >> THX for hints >> >> Karm >> >> >> On 5/17/22 21:52, Philip Race wrote: >> > This could be a bug in the TIFF plugin. >> > Hard to say without debugging it. >> > >> > -phil. >> > >> > >> > On 5/17/22 7:04 AM, Michal Karm wrote: >> >> Hello, >> >> >> >> There used to be an Unsupported Image Type exception thrown >> >> when one wanted to decode a TIFF container with JPEG compressed image. >> >> >> >> That behavior has changed, there is no exception now, although the >> >> resulting image is incorrect. >> >> >> >> I outlined the details in this doc [1], including a small reproducer. >> >> >> >> The test image is not anything from a fuzzer, it's just me >> >> clicking Export As in GIMP. >> >> >> >> Thanks for feedback >> >> >> >> Cheers >> >> Karm >> >> >> >> >> >> [1] >> >> >> https://urldefense.com/v3/__https://github.com/Karm/dev-null/blob/main/jpegtiff/README.md__;!!ACWV5N9M2RV99hQ!Kw41ShsuTSfpVPMZFrXmdQ7ZETNdkLTk9Xd1NDWELvCXV0fyIqg4sXi5Z1aYfjMoG-5fS0gki8dnN8bQjSYM0g$ >> >> >> >> >> >> >> Karm Michal Babacek >> >> >> > >> >> >> Michal Karm Babacek >> >> -- >> Sent from my Hosaka Ono-Sendai Cyberspace 7 >> > Michal Karm Babacek -- Sent from my Hosaka Ono-Sendai Cyberspace 7 From shurailine at openjdk.java.net Mon May 23 16:32:06 2022 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Mon, 23 May 2022 16:32:06 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux Message-ID: Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. Additional instrumentation is added to save useful information on the UI state, should the failure happen again. ------------- Commit messages: - A public method to capture the whole screen. - 1. Wait for ScrollPaneDemo container to be loaded. Changes: https://git.openjdk.java.net/jdk/pull/8848/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8848&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225013 Stats: 52 lines in 3 files changed: 45 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8848.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8848/head:pull/8848 PR: https://git.openjdk.java.net/jdk/pull/8848 From shurailine at openjdk.java.net Mon May 23 16:32:06 2022 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Mon, 23 May 2022 16:32:06 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:25:37 GMT, Alexandre Iline wrote: > Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. > Additional instrumentation is added to save useful information on the UI state, should the failure happen again. @prrace @lawrence-andrew , can you take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/8848 From prr at openjdk.java.net Mon May 23 16:48:53 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 16:48:53 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:25:37 GMT, Alexandre Iline wrote: > Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. > Additional instrumentation is added to save useful information on the UI state, should the failure happen again. I don't know anything about Jemmy, so I have no idea what these changes do. Importantly I can't tell what you've done which makes the test stable and why. Can you explain both the problem and the solution ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8848 From aivanov at openjdk.java.net Mon May 23 16:50:13 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 16:50:13 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray Message-ID: **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports. **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`. ------------- Commit messages: - Resolve IDE warnings: redundant initializer, sized array in toArray - Remove 2nd call to popupParent.dispose() Changes: https://git.openjdk.java.net/jdk/pull/8850/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8850&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286663 Stats: 20 lines in 2 files changed: 8 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8850/head:pull/8850 PR: https://git.openjdk.java.net/jdk/pull/8850 From kizune at openjdk.java.net Mon May 23 17:08:57 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 23 May 2022 17:08:57 GMT Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v5] In-Reply-To: References: Message-ID: <4zTcqHsdwfocF-6HX3ungAZ5SRiVR_BknqwIwhcsOm0=.aaa0fd33-da2d-45d9-b13d-7aeff488f6b4@github.com> On Wed, 18 May 2022 10:04:53 GMT, Srinivas Mandalika wrote: >> Create a regression test for JDK-4699544 >> >> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs. >> >> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately. >> The test added verifies the same. >> This review is for migrating tests from a closed test suite to open. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Comments Fixed: Fixed File location path. Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7739 From prr at openjdk.java.net Mon May 23 17:09:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 17:09:57 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box [v2] In-Reply-To: References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: On Sun, 22 May 2022 17:57:27 GMT, Jeremy wrote: >> This resolves an occasional unit test failure in Path2D.UnitTest. >> >> The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. >> >> This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. >> >> This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box > > Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. I ran our full battery of automated tests and results look good. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8828 From kizune at openjdk.java.net Mon May 23 17:14:57 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 23 May 2022 17:14:57 GMT Subject: RFR: JDK-8282777: Create a Regression test for JDK-4515031 [v4] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 10:09:30 GMT, Srinivas Mandalika wrote: >> Create a Regression test for [JDK-4515031](https://bugs.openjdk.java.net/browse/JDK-4515031) >> >> The issue indicates the need for a a getAccessibleDescription being implemented for the JFileChooser. >> The test added verifies the same. >> This review is for migrating tests from a closed test suite to open. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Comments Fixed: Fixed File location path. test/jdk/javax/accessibility/JFileChooserAccessibleDescriptionTest.java line 89: > 87: robot.keyPress(KeyEvent.VK_C); > 88: robot.keyRelease(KeyEvent.VK_C); > 89: robot.keyRelease(KeyEvent.VK_ALT); What is the purpose of the pressing Alt-C here? Looks like on Mac OS X it does nothing and when i comment them out the test runs in the same way as with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7738 From prr at openjdk.java.net Mon May 23 17:21:59 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 17:21:59 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:43:05 GMT, Alexey Ivanov wrote: > **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports. > > **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`. src/java.desktop/share/classes/java/awt/SystemTray.java line 349: > 347: if (icons != null) { > 348: return icons.toArray(new TrayIcon[0]); > 349: } Actually, the old code is more efficient than your new code. Per the spec https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Vector.html#toArray(T%5B%5D) Returns an array containing all of the elements in this Vector in the correct order; the runtime type of the returned array is that of the specified array. If the Vector fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this Vector. So your new code allocates one more array than the old code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From kizune at openjdk.java.net Mon May 23 17:22:02 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 23 May 2022 17:22:02 GMT Subject: RFR: 8282771 : Create test case for JDK-8262981 [v4] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 15:14:34 GMT, lawrence.andrews wrote: >> Following methods are covered in this testcase >> getAccessibleAction() >> getAccessibleActionCount() >> doAccessibleAction(int direction) >> >> @shurymury > > lawrence.andrews has updated the pull request incrementally with one additional commit since the last revision: > > Fixed review comments Looks good to me. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7734 From kizune at openjdk.java.net Mon May 23 17:24:10 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 23 May 2022 17:24:10 GMT Subject: RFR: 8276266: Clean up incorrect client-libs ProblemList.txt entries [v2] In-Reply-To: References: <-gLIqdVcPOaZgxCVSkMNQ6FzygLGTk7O710l-Mwc4zc=.8b8a3124-9d44-4893-af45-89c22d49b589@github.com> Message-ID: On Tue, 2 Nov 2021 01:29:37 GMT, Phil Race wrote: >> We have a few stale entries in the Problem list. >> We need to remap some tests to still open bugs >> 7100044 -> 6849371 >> 8203047 -> 8072110 >> 8233703 -> 8238436 >> 8273618 -> 8273617 >> >> We need to remove these FIXED bugs >> java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.java 7185258 macosx-all >> >> java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java 8000171 windows-all >> (actually closed as a dup of 8196100 which is fixed) >> >> And this RESOLVED / not reproducible. >> java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java 8061235 macosx-all >> >> I've verified that the removed ones do pass in the CI test system so we should be OK unless they are very intermittent or environment specific > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8276266: Clean up incorrect client-libs ProblemList.txt entries Looks good. ------------- Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6203 From achung at openjdk.java.net Mon May 23 17:26:58 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 23 May 2022 17:26:58 GMT Subject: RFR: 8286172: Create an automated test for JDK-4516019 [v2] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:36:04 GMT, Srinivas Mandalika wrote: >> Create an automated test for [JDK-4516019](https://bugs.openjdk.java.net/browse/JDK-4516019) >> >> Clicking on the increment/decrement buttons of the spinner does not install focus on the spinner or one of its focusable children. >> >> The test validates the same. >> >> This review is for migrating tests from a closed test suite to open. >> >> Testing: >> The test ran successfully on Mach5 with multiple runs (30) on windows-x64, linux-x64 and macos-x64. > > Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: > > - Review comments fixed: Fixed file path, removed redundant sleep call etc. > - Review comments fixed: Removed file under the 'bug id' folder structure Changes requested by achung (Author). test/jdk/javax/swing/JSpinner/JSpinnerFocusTest.java line 69: > 67: try { > 68: SwingUtilities.invokeAndWait(() -> createGUI()); > 69: Thread.sleep(1000); Would it be better to make robot a global variable and use Robot.waitForIdle() here? Sleeping might slow down the test unnecessarily test/jdk/javax/swing/JSpinner/JSpinnerFocusTest.java line 71: > 69: Thread.sleep(1000); > 70: runTest(); > 71: Thread.sleep(1000); same here ------------- PR: https://git.openjdk.java.net/jdk/pull/8546 From shurailine at openjdk.java.net Mon May 23 17:29:55 2022 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Mon, 23 May 2022 17:29:55 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux In-Reply-To: References: Message-ID: <9qkwcwuWNciWjy2edHR-xWBeXZyQ6AAiH7lqnVIthMg=.0f85de4a-5adc-4c2d-8f2b-94945cd2cf03@github.com> On Mon, 23 May 2022 16:45:09 GMT, Phil Race wrote: > Can you explain both the problem and the solution ? >From what I have observed, the test starts before the window is painted. The window is basically gray. My hypothesis is then that it takes time to load the background image and the test starts before that. So the fix is to wait for the image to be loaded. To do that I find the label (by description of the icon) and wait for getImageLoadStatus() == MediaTracker.COMPLETE of that icon. Additionally, after the image is loaded, I capture an image of the screen and also save UI state in an xml file. Should the test fail again, there will hopefully be more information available. ------------- PR: https://git.openjdk.java.net/jdk/pull/8848 From duke at openjdk.java.net Mon May 23 17:33:55 2022 From: duke at openjdk.java.net (Jeremy) Date: Mon, 23 May 2022 17:33:55 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box [v2] In-Reply-To: References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: On Sun, 22 May 2022 17:57:27 GMT, Jeremy wrote: >> This resolves an occasional unit test failure in Path2D.UnitTest. >> >> The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. >> >> This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. >> >> This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box > > Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. I just realized there's an explicit openJDK ticket for these failures ( https://bugs.openjdk.java.net/browse/JDK-8286093 ). Should I... close this PR and open a new one? Simply rename this one? (Or my favorite: do nothing?) ------------- PR: https://git.openjdk.java.net/jdk/pull/8828 From prr at openjdk.java.net Mon May 23 17:48:55 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 17:48:55 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box [v2] In-Reply-To: References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: On Sun, 22 May 2022 17:57:27 GMT, Jeremy wrote: >> This resolves an occasional unit test failure in Path2D.UnitTest. >> >> The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. >> >> This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. >> >> This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box > > Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. Oh, I hadn't noticed. yes you will need to fix this, the tooling won't let you re-use the same id (I hope!) there's a /issue command which should work for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8828 From prr at openjdk.java.net Mon May 23 17:55:44 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 17:55:44 GMT Subject: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box [v2] In-Reply-To: References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: On Sun, 22 May 2022 17:57:27 GMT, Jeremy wrote: >> This resolves an occasional unit test failure in Path2D.UnitTest. >> >> The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. >> >> This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. >> >> This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. > > Jeremy has updated the pull request incrementally with one additional commit since the last revision: > > 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box > > Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. Seems I can't change this for you - maybe because you didn't check the option to allow other committers to edit the PR ? So you will need to fix it yourself. ------------- PR: https://git.openjdk.java.net/jdk/pull/8828 From shurailine at openjdk.java.net Mon May 23 18:00:39 2022 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Mon, 23 May 2022 18:00:39 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux [v2] In-Reply-To: References: Message-ID: > Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. > Additional instrumentation is added to save useful information on the UI state, should the failure happen again. Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: Using modern language features. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8848/files - new: https://git.openjdk.java.net/jdk/pull/8848/files/03e6c206..2aa1c9e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8848&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8848&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8848.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8848/head:pull/8848 PR: https://git.openjdk.java.net/jdk/pull/8848 From duke at openjdk.java.net Mon May 23 18:28:46 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Mon, 23 May 2022 18:28:46 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:00:39 GMT, Alexandre Iline wrote: >> Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. >> Additional instrumentation is added to save useful information on the UI state, should the failure happen again. > > Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: > > Using modern language features. LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/8848 From rriggs at openjdk.java.net Mon May 23 18:37:51 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 23 May 2022 18:37:51 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> Message-ID: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com> On Tue, 10 May 2022 19:24:24 GMT, Mark Powers wrote: >> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777: >> >>> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) { >>> 776: printStackWhenAccessFails = GetBooleanAction. >>> 777: privilegedGetProperty("sun.reflect.debugModuleAccessChecks"); >> >> Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false. > > You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes. This change still needs to be reversed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Mon May 23 18:58:34 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 23 May 2022 18:58:34 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: > JDK-6725221 Standardize obtaining boolean properties with defaults Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Alan and Jamil comments - Merge - reverse true.equals and false.equals changes - Merge - Merge - first iteration ------------- Changes: https://git.openjdk.java.net/jdk/pull/8559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=01 Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559 PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Mon May 23 19:03:51 2022 From: duke at openjdk.java.net (Mark Powers) Date: Mon, 23 May 2022 19:03:51 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com> References: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com> <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com> Message-ID: On Mon, 23 May 2022 18:34:41 GMT, Roger Riggs wrote: >> You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes. > > This change still needs to be reversed. The change has been reversed. We had an internal discussion about IntelliJ's unboxing recommendation, and decided to let unboxing be a matter of personal preference. Those changes have been reversed too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From vdyakov at openjdk.java.net Mon May 23 19:58:45 2022 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Mon, 23 May 2022 19:58:45 GMT Subject: RFR: 8284690: [macos] VoiceOver : Getting java.lang.IllegalArgumentException: Invalid location on Editable JComboBox In-Reply-To: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> References: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> Message-ID: On Fri, 20 May 2022 21:13:35 GMT, Alexander Zuev wrote: > Check for the available range on the document model and adjust text range request accordingly. @prsadhuk please review ------------- PR: https://git.openjdk.java.net/jdk/pull/8820 From rriggs at openjdk.java.net Mon May 23 20:00:01 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 23 May 2022 20:00:01 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:58:34 GMT, Mark Powers wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Alan and Jamil comments > - Merge > - reverse true.equals and false.equals changes > - Merge > - Merge > - first iteration LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8559 From serb at openjdk.java.net Mon May 23 20:18:56 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 May 2022 20:18:56 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 17:18:17 GMT, Phil Race wrote: >> **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports. >> >> **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`. > > src/java.desktop/share/classes/java/awt/SystemTray.java line 349: > >> 347: if (icons != null) { >> 348: return icons.toArray(new TrayIcon[0]); >> 349: } > > Actually, the old code is more efficient than your new code. > Per the spec https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Vector.html#toArray(T%5B%5D) > Returns an array containing all of the elements in this Vector in the correct order; the runtime type of the returned array is that of the specified array. If the Vector fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this Vector. > > So your new code allocates one more array than the old code. It is not intuitive but the "zero version" is actually faster: ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From prr at openjdk.java.net Mon May 23 20:27:40 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 20:27:40 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 20:15:12 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/java/awt/SystemTray.java line 349: >> >>> 347: if (icons != null) { >>> 348: return icons.toArray(new TrayIcon[0]); >>> 349: } >> >> Actually, the old code is more efficient than your new code. >> Per the spec https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Vector.html#toArray(T%5B%5D) >> Returns an array containing all of the elements in this Vector in the correct order; the runtime type of the returned array is that of the specified array. If the Vector fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this Vector. >> >> So your new code allocates one more array than the old code. > > It is not intuitive but the "zero version" is actually faster: ok ... why ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From aivanov at openjdk.java.net Mon May 23 20:27:41 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 20:27:41 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 20:23:08 GMT, Phil Race wrote: >> It is not intuitive but the "zero version" is actually faster: > > ok ... why ? It's explained in Aleksey Shipil?v's article https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_conclusion ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From aivanov at openjdk.java.net Mon May 23 20:31:42 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 20:31:42 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 20:24:52 GMT, Alexey Ivanov wrote: >> ok ... why ? > > It's explained in Aleksey Shipil?v's article > https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_conclusion In fact, there's no need to create zero-sized array, there's one already: `EMPTY_TRAY_ARRAY`. Yet the code may look weird with it. return icons.toArray(EMPTY_TRAY_ARRAY); ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From dnguyen at openjdk.java.net Mon May 23 20:33:04 2022 From: dnguyen at openjdk.java.net (Damon Nguyen) Date: Mon, 23 May 2022 20:33:04 GMT Subject: RFR: 8286786: [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java still fails In-Reply-To: References: Message-ID: On Fri, 20 May 2022 09:07:29 GMT, Prasanta Sadhukhan wrote: > In PR#[8380](https://github.com/openjdk/jdk/pull/8380) we have reduced the error tolerance from 25 to 1 so no need of exact color check which is causing failure in specific M1 iMac system because of minimalistic color difference of "1" > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > `so modified to use the tolerance check for all L&Fs. Looks good. Tested the changes on my local machine. It's even ever so slightly faster per L&F iteration. ------------- Marked as reviewed by dnguyen (Author). PR: https://git.openjdk.java.net/jdk/pull/8804 From serb at openjdk.java.net Mon May 23 20:37:46 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 May 2022 20:37:46 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 20:28:30 GMT, Alexey Ivanov wrote: >> It's explained in Aleksey Shipil?v's article >> https://shipilev.net/blog/2016/arrays-wisdom-ancients/ >> >> In short, zero-sized array avoids the need for JVM to zero all array elements before they're overwritten with real values. On the other hand, this is likely negligible with very small arrays. > > In fact, there's no need to create zero-sized array, there's one already: `EMPTY_TRAY_ARRAY`. > > Yet the code may look weird with it. > > > return icons.toArray(EMPTY_TRAY_ARRAY); We probably can extract this to the separate cleanup, the resulted code is smaller and faster. PS I have added a link to my previous message accidentally hit submit button. ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From prr at openjdk.java.net Mon May 23 20:38:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 20:38:49 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:00:39 GMT, Alexandre Iline wrote: >> Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. >> Additional instrumentation is added to save useful information on the UI state, should the failure happen again. > > Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: > > Using modern language features. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8848 From serb at openjdk.java.net Mon May 23 20:38:49 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 23 May 2022 20:38:49 GMT Subject: RFR: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:00:39 GMT, Alexandre Iline wrote: >> Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. >> Additional instrumentation is added to save useful information on the UI state, should the failure happen again. > > Alexandre Iline has updated the pull request incrementally with one additional commit since the last revision: > > Using modern language features. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8848 From prr at openjdk.java.net Mon May 23 20:44:28 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 20:44:28 GMT Subject: RFR: 8286159: Memory leak in getAllConfigs of awt_GraphicsEnv.c:585 Message-ID: <8kfUsrwVx96D8gvusJtwYwwFLW1WieMXeWlB7qMZpK0=.05cca9e8-9169-46e3-baef-aa46b02d5156@github.com> If we don't store the memory allocated for graphicsConfigs because we failed/bail, we need to free it. ------------- Commit messages: - 8286159 Changes: https://git.openjdk.java.net/jdk/pull/8857/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8857&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286159 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8857.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8857/head:pull/8857 PR: https://git.openjdk.java.net/jdk/pull/8857 From prr at openjdk.java.net Mon May 23 21:14:58 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 21:14:58 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 20:34:27 GMT, Sergey Bylokhov wrote: >> In fact, there's no need to create zero-sized array, there's one already: `EMPTY_TRAY_ARRAY`. >> >> Yet the code may look weird with it. >> >> >> return icons.toArray(EMPTY_TRAY_ARRAY); > > We probably can extract this to the separate cleanup, the resulted code is smaller and faster. > PS I have added a link to my previous message accidentally hit submit button. I'm sure I've used this pattern return icons.toArray(EMPTY_TRAY_ARRAY); in code that runs often and may be performance sensitive, so I don't see anything weird about it. OTOH I am not sure this code is anything that needs super-optimising .. we seem to have gone down that discussion route because it was the justification for the change. BTW the shiplev article, which I skimmed must be suggesting that the array initialisation must be faster if it is on the array it allocates itself because of the APIs used .. but as he also notes things can change. Anyway this is mildly interesting discussion but no one will ever, ever be able to measure a difference when it used here since it is probably 0.0001 % of the work ... ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From shurailine at openjdk.java.net Mon May 23 22:34:11 2022 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Mon, 23 May 2022 22:34:11 GMT Subject: Integrated: JDK-8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:25:37 GMT, Alexandre Iline wrote: > Before the fix the test was failing around 1 time in fifty runs. After the fix the test did not fail in ~ 1k runs. > Additional instrumentation is added to save useful information on the UI state, should the failure happen again. This pull request has now been integrated. Changeset: 9f73fb5a Author: Alexandre Iline URL: https://git.openjdk.java.net/jdk/commit/9f73fb5a72157adb4edb07ead2d9a6745c21e9f4 Stats: 42 lines in 3 files changed: 35 ins; 1 del; 6 mod 8225013: sanity/client/SwingSet/src/ScrollPaneDemoTest.java fails on Linux Reviewed-by: prr, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/8848 From serb at openjdk.java.net Tue May 24 00:08:49 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 00:08:49 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray In-Reply-To: References: Message-ID: On Mon, 23 May 2022 21:11:34 GMT, Phil Race wrote: >> We probably can extract this to the separate cleanup, the resulted code is smaller and faster. >> PS I have added a link to my previous message, accidentally hit submit button. > > I'm sure I've used this pattern > return icons.toArray(EMPTY_TRAY_ARRAY); > in code that runs often and may be performance sensitive, so I don't see anything weird about it. > OTOH I am not sure this code is anything that needs super-optimising .. we seem to have gone down that discussion route because it was the justification for the change. > > BTW the shiplev article, which I skimmed must be suggesting that the array initialisation must be faster if it is on the array it allocates itself because of the APIs used .. but as he also notes things can change. > > Anyway this is mildly interesting discussion but no one will ever, ever be able to measure a difference when it used here since it is probably 0.0001 % of the work ... It also has a functional implication, in the old code the "size" on a Vector is called outside of the lock. So the resulted array after "icons.toArray" can be bigger than the number of icons. This is similar to this: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/classes/javax/sound/midi/Sequence.java#L281 I think that race can even be triggered by the new test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From serb at openjdk.java.net Tue May 24 00:13:38 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 00:13:38 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:03:03 GMT, Tejesh R wrote: > _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE. Is it possible to create a new test case for this patch, or can we add @bug to some existed one? ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From serb at openjdk.java.net Tue May 24 00:22:58 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 00:22:58 GMT Subject: RFR: 8284690: [macos] VoiceOver : Getting java.lang.IllegalArgumentException: Invalid location on Editable JComboBox In-Reply-To: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> References: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> Message-ID: On Fri, 20 May 2022 21:13:35 GMT, Alexander Zuev wrote: > Check for the available range on the document model and adjust text range request accordingly. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8820 From serb at openjdk.java.net Tue May 24 00:41:57 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 00:41:57 GMT Subject: RFR: 8282526: Default icon is not painted properly [v3] In-Reply-To: References: <7zYHFtn9L54eIDP49ZZtZA_kDPWwhwWTo1Zzy82gyYc=.21baf5bc-9604-4242-92d7-65bfb68cf9a0@github.com> <9YGqKP4x5N0miiskVwMoF201g7ng3JjTnJF5ctGkD5w=.9b763d6a-469d-49b0-83cd-79cc46cdfecd@github.com> Message-ID: On Wed, 27 Apr 2022 15:41:33 GMT, Alexander Zuev wrote: >>> We are setting the BICUBIC only in place where we draw the image part of ImageIcon. There is no benefit in pushing this change down the pipeline. >> >> We don't need to push change down to the pipeline, we should push it up to the place where we paint this ImageIcon, eventually where we call ImageIcon.paintIcon() >> >>> It is not a regression, it is a side effect of the JDK-8182043 combined with the Windows 10 update that changed the default windows file icon to the blank white sheet with 1 pixel wide dark gray border. >>> Because we can not read this icon from the native, when we ask Windows API to provide this icon it ignores the icon size and gives the same 32x32 icon instead. We knew this upfront and the consensus was that we will provide the icon in the MultiResolutionImage and scaling during painting will be good enough to scale it properly. But it is not. >> >> Then why, as described in the JBS, it worked before? Did we request different image, or size, or did we skip scaling? > >> We don't need to push change down to the pipeline, we should push it up to the place where we paint this ImageIcon, eventually where we call ImageIcon.paintIcon() > > Why? As i shown in the test case the problem affects any ImageIcon based on the MultiResolutionImage. I'm not trying to solve the singular issue that in the Windows LaF - i am trying to eliminate the reason this problem can show up. > >> Then why, as described in the JBS, it worked before? Did we request different image, or size, or did we skip scaling? > > Because before that change we were using different binary API to retrieve icons. This API only allows gathering 8x8 and 16x16 icons. The new API can be used for requesting icons of any size but for some files it ignores the requested size and only returns 32x32 icon. In this case we creating the multi resolution image with that icon inside and allow icon painting routine do the scaling. As i shown in my test for this bug the scaling works poorly and here i'm trying to enhance it. Can it be done in WinLAF? Yes, absolutely, but it will not solve the more generic issue. > On the other hand, @azuev-java demonstrates the problem exists in general: if an icon is scaled down, it may lose relevant details and become white square ? it doesn't look good, does it? Yes, but if we downscale then this is applicable for any other types of icons, or images. If the user render it directly then he can turn on the bicubic option, if we render it ourselves (like in this case) we can provide a solution I referenced above, similar to the text anti-aliasing, when the user may set a special client_property. But these are two different issues, one of them - specific to MRI and the previous fix where we changed the behavior, and another one - an addition customization of how the Swing renders the images. But before we provide such customization we need to check how slow it will be, in some cases it could be x10(or x1000? I do not remember) times slower. ------------- PR: https://git.openjdk.java.net/jdk/pull/7805 From serb at openjdk.java.net Tue May 24 00:49:47 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 00:49:47 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton In-Reply-To: References: Message-ID: On Mon, 16 May 2022 06:45:04 GMT, Tejesh R wrote: > Added test for checking setMargin() of JRadioButton. Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803 ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From serb at openjdk.java.net Tue May 24 01:00:56 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 01:00:56 GMT Subject: RFR: 8282857: Create a regression test for JDK-4702690 [v4] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:33:43 GMT, Srinivas Mandalika wrote: >> Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690) >> >> In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane). >> In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with. >> >> This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items. >> >> The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar. >> This review is for migrating tests from a closed test suite to open. > > Srinivas Mandalika has updated the pull request incrementally with two additional commits since the last revision: > > - Review comments fixed: Added Test without 'bug id' folder structure > - Review comments fixed: Removed file under the 'bug id' folder structure Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7753 From serb at openjdk.java.net Tue May 24 01:04:46 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 01:04:46 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked with sound keyword [v3] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 22:31:38 GMT, Phil Race wrote: >> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests >> >> The jtreg javax.sound tests are written in such a way that if a needed audio device >> or other platform resource is not available, they just exit with a "pass" for the test. >> It is as if headful tests just swallowed HeadlessException and issued a pass. >> If we allowed that we'd be effectively testing almost nothing of real importance. >> >> Currently almost all sound tests have no keyword like "headful" to indicate they >> may need access to a hardware resource to do anything useful so a similar >> situation arises there except when someone runs those tests manually on >> a local system which has audio devices. >> >> Of course "headful" and "audio device" aren't exactly interchangeable terms >> but if tests are allowed to be run - or worse usually or always run - in a situation >> where they potentially are on a system without an audio device (a headless VM) or are running in >> a session which doesn't have full desktop access - which may in some >> cases be how audio device access is granted, then they are more likely >> to be running in this scenario where the testing isn't valid. >> >> Another point is that headful tests must be run one at a time - no concurrency because >> you can't have multiple tests moving the mouse at the same time >> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM >> When tests that really need access to an audio device are run it is probably safer to consider >> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't >> usual for a single app to be able to monopolize access to a speaker, but for input devices >> that is what you'd generally expect. >> >> By no means am I sure that the tests being updated here are the full set that need tagging. >> There are a lot of tests and they are all known to pass on systems with NO audio >> devices, so the search has been for tests which call APIs which will definitely >> need access to some device in order to do anything useful. >> So likely there are more to be added - either by a reviewer pointing them out or by later discovery. >> Alternatively we could mark ALL sound tests headful .. but given where we are starting from >> that might be erring unnecessarily far in the opposite direction. >> >> By adding both headful and sound keywords it gives options to someone who >> wants to identify the tests and perhaps run just tests which need "sound" on some >> config they know supports audio but isn't headful. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8275170 Looks fine. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6086 From serb at openjdk.java.net Tue May 24 01:12:56 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 01:12:56 GMT Subject: RFR: JDK-8282778: Create a regression test for JDK-4699544 [v5] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 10:04:53 GMT, Srinivas Mandalika wrote: >> Create a regression test for JDK-4699544 >> >> The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs. >> >> The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately. >> The test added verifies the same. >> This review is for migrating tests from a closed test suite to open. > > Srinivas Mandalika has updated the pull request incrementally with one additional commit since the last revision: > > Review Comments Fixed: Fixed File location path. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7739 From serb at openjdk.java.net Tue May 24 01:22:04 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 01:22:04 GMT Subject: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v3] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 00:53:27 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a binary array search with a Comparable implementation. This implementation is probably bad. Instead, we can use the enhanced switch feature to possibly save time, resources, and code size. The new implementation means that the array doesn't have to be sorted alphanumerically necessarily, and it creates the colors on demand. > > SWinxy has updated the pull request incrementally with one additional commit since the last revision: > > Accidental mergers. > > I created a quick check to see if any other colors were different (only these three). For some odd reason "yellowgreen" and "yellow green" are different. Do you have any numbers to compare possible performance improvements in lookupColor()? I'll assume it should be faster but can we prove that? ------------- PR: https://git.openjdk.java.net/jdk/pull/7096 From serb at openjdk.java.net Tue May 24 01:31:58 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 01:31:58 GMT Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short [v2] In-Reply-To: References: Message-ID: <5NWKHiv1vPMNVu7dlDUA2ujKveOyrDD_OM0BPz1ivp0=.9ba15366-a0f0-4443-a158-7e033d285039@github.com> On Mon, 23 May 2022 08:09:20 GMT, Martin Desruisseaux wrote: >> Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted. >> >> The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are: >> >> * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value. >> * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method. > > Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: > > Test all plugins, not only "BMP". src/java.desktop/share/classes/com/sun/imageio/plugins/common/ReaderUtil.java line 284: > 282: } while (offset < b.length); > 283: return true; > 284: } Any reason not to catch EOFException exception in the exceptional situation? ------------- PR: https://git.openjdk.java.net/jdk/pull/8700 From duke at openjdk.java.net Tue May 24 04:09:45 2022 From: duke at openjdk.java.net (Tejesh R) Date: Tue, 24 May 2022 04:09:45 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F In-Reply-To: References: Message-ID: On Tue, 24 May 2022 00:10:34 GMT, Sergey Bylokhov wrote: > Is it possible to create a new test case for this patch, or can we add @bug to some existed one? I don't think there exist a bug for this fix, I will create a new test case for this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From psadhukhan at openjdk.java.net Tue May 24 04:38:47 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 24 May 2022 04:38:47 GMT Subject: Integrated: 8286786: [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java still fails In-Reply-To: References: Message-ID: On Fri, 20 May 2022 09:07:29 GMT, Prasanta Sadhukhan wrote: > In PR#[8380](https://github.com/openjdk/jdk/pull/8380) we have reduced the error tolerance from 25 to 1 so no need of exact color check which is causing failure in specific M1 iMac system because of minimalistic color difference of "1" > > > x 0 y 0 red1 171 red2 171 green1 174 green2 175 blue1 184 blue2 184 > x 0 y 1 red1 172 red2 173 green1 177 green2 177 blue1 185 blue2 185 > x 0 y 2 red1 173 red2 174 green1 177 green2 178 blue1 187 blue2 187 > x 0 y 6 red1 0 red2 0 green1 1 green2 0 blue1 0 blue2 0 > x 0 y 15 red1 1 red2 0 green1 0 green2 0 blue1 0 blue2 0 > > > `so modified to use the tolerance check for all L&Fs. This pull request has now been integrated. Changeset: a5caffd4 Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/a5caffd4a5dfac44a925f783bc1f72e0a7b85869 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod 8286786: [macos] javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java still fails Reviewed-by: serb, dnguyen ------------- PR: https://git.openjdk.java.net/jdk/pull/8804 From duke at openjdk.java.net Tue May 24 05:32:56 2022 From: duke at openjdk.java.net (Tejesh R) Date: Tue, 24 May 2022 05:32:56 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton In-Reply-To: References: Message-ID: On Tue, 24 May 2022 00:46:21 GMT, Sergey Bylokhov wrote: > Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803 Means you are suggesting to use the passfailFrame? ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From serb at openjdk.java.net Tue May 24 05:41:50 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 May 2022 05:41:50 GMT Subject: RFR: 6829250: Reg test: java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java fails in Windows In-Reply-To: References: Message-ID: On Wed, 20 Apr 2022 05:10:23 GMT, Alexander Zuev wrote: > Only check that insets of the fully expanded undecorated window is not bigger than device insets. They can be smaller, it is a normal situation. No I mean the JDK-4976497 which was closed as duplicate of another one(as well as some others). It has a test case which shows that the Swing does not work as expected when the custom decorations are used. Note that bug is not directly related to the case when the undercoated window cover or not the taskbar this could be done by simple setSize() method, but only to the case when we maximize such window. ------------- PR: https://git.openjdk.java.net/jdk/pull/8314 From duke at openjdk.java.net Tue May 24 07:51:46 2022 From: duke at openjdk.java.net (Martin Desruisseaux) Date: Tue, 24 May 2022 07:51:46 GMT Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short [v2] In-Reply-To: <5NWKHiv1vPMNVu7dlDUA2ujKveOyrDD_OM0BPz1ivp0=.9ba15366-a0f0-4443-a158-7e033d285039@github.com> References: <5NWKHiv1vPMNVu7dlDUA2ujKveOyrDD_OM0BPz1ivp0=.9ba15366-a0f0-4443-a158-7e033d285039@github.com> Message-ID: On Tue, 24 May 2022 01:28:29 GMT, Sergey Bylokhov wrote: >> Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: >> >> Test all plugins, not only "BMP". > > src/java.desktop/share/classes/com/sun/imageio/plugins/common/ReaderUtil.java line 284: > >> 282: } while (offset < b.length); >> 283: return true; >> 284: } > > Any reason not to catch EOFException exception in the exceptional situation? No strong reason. I thought it was safer because a -1 return value means that the stream reached EOF on normal condition, while `EOFException` could still be a problem with the stream for example if the stream wraps another `InputStream` for applying decompression on-the-fly (e.g. a ZIP file), and the compressed stream is truncated before the end of the compression chunk. ------------- PR: https://git.openjdk.java.net/jdk/pull/8700 From psadhukhan at openjdk.java.net Tue May 24 08:35:11 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 24 May 2022 08:35:11 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 Message-ID: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 x 13 y 0 refRGB ffeeeeee customRGB ffefeeee x 0 y 0 refRGB ffefefef customRGB ffefeeef so added color tolerance check. Also, added other stability fixes.. Several iteration of test passed in intended M1 and x64 system. ------------- Commit messages: - 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 - 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 Changes: https://git.openjdk.java.net/jdk/pull/8864/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8864&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286846 Stats: 38 lines in 1 file changed: 20 ins; 8 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8864.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8864/head:pull/8864 PR: https://git.openjdk.java.net/jdk/pull/8864 From aivanov at openjdk.java.net Tue May 24 10:39:52 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 10:39:52 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:29:43 GMT, Tejesh R wrote: > > Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803 > > Means you are suggesting to use the passfailFrame? Why not? The framework allows you to re-use the functionality for creating the UI and for handling Pass/Fail buttons instead of creating your own. ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From aivanov at openjdk.java.net Tue May 24 10:47:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 10:47:57 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton In-Reply-To: References: Message-ID: On Mon, 16 May 2022 06:45:04 GMT, Tejesh R wrote: > Added test for checking setMargin() of JRadioButton. test/jdk/javax/swing/JRadioButton/bug4380543.java line 143: > 141: { > 142: disposeUI(); > 143: if (res.toString() == "false") This looks weird. Why can't you use `res.get()`? It returns a `Boolean` object which can be used directly in an if-condition. test/jdk/javax/swing/JRadioButton/bug4380543.java line 208: > 206: getContentPane().add(p,BorderLayout.SOUTH); > 207: > 208: setDefaultCloseOperation(EXIT_ON_CLOSE); You should never call `System.exit` in a jtreg test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From aivanov at openjdk.java.net Tue May 24 10:53:38 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 10:53:38 GMT Subject: RFR: 8275170: Some jtreg sound tests should be marked with sound keyword [v3] In-Reply-To: References: Message-ID: <15zd77CFFKEPOMiBE8ZONbDMuekOIaYPBsrUq--abT0=.9562f073-5a6b-4b7f-b0f1-7953fa5ee654@github.com> On Fri, 20 May 2022 22:31:38 GMT, Phil Race wrote: >> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests >> >> The jtreg javax.sound tests are written in such a way that if a needed audio device >> or other platform resource is not available, they just exit with a "pass" for the test. >> It is as if headful tests just swallowed HeadlessException and issued a pass. >> If we allowed that we'd be effectively testing almost nothing of real importance. >> >> Currently almost all sound tests have no keyword like "headful" to indicate they >> may need access to a hardware resource to do anything useful so a similar >> situation arises there except when someone runs those tests manually on >> a local system which has audio devices. >> >> Of course "headful" and "audio device" aren't exactly interchangeable terms >> but if tests are allowed to be run - or worse usually or always run - in a situation >> where they potentially are on a system without an audio device (a headless VM) or are running in >> a session which doesn't have full desktop access - which may in some >> cases be how audio device access is granted, then they are more likely >> to be running in this scenario where the testing isn't valid. >> >> Another point is that headful tests must be run one at a time - no concurrency because >> you can't have multiple tests moving the mouse at the same time >> Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM >> When tests that really need access to an audio device are run it is probably safer to consider >> the headful attribute as implying one test at a time is best .. granted on a desktop it isn't >> usual for a single app to be able to monopolize access to a speaker, but for input devices >> that is what you'd generally expect. >> >> By no means am I sure that the tests being updated here are the full set that need tagging. >> There are a lot of tests and they are all known to pass on systems with NO audio >> devices, so the search has been for tests which call APIs which will definitely >> need access to some device in order to do anything useful. >> So likely there are more to be added - either by a reviewer pointing them out or by later discovery. >> Alternatively we could mark ALL sound tests headful .. but given where we are starting from >> that might be erring unnecessarily far in the opposite direction. >> >> By adding both headful and sound keywords it gives options to someone who >> wants to identify the tests and perhaps run just tests which need "sound" on some >> config they know supports audio but isn't headful. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8275170 Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6086 From aivanov at openjdk.java.net Tue May 24 11:20:36 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 11:20:36 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray [v2] In-Reply-To: References: Message-ID: > **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports. > > **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`. Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision: - toArray: new TrayIcon[0] -> EMPTY_TRAY_ARRAY - use existing empty array - Drop explicit type argument - Make popupParent final ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8850/files - new: https://git.openjdk.java.net/jdk/pull/8850/files/e2beded7..a2f8c952 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8850&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8850&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8850/head:pull/8850 PR: https://git.openjdk.java.net/jdk/pull/8850 From aivanov at openjdk.java.net Tue May 24 11:20:37 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 11:20:37 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 00:03:54 GMT, Sergey Bylokhov wrote: >> I'm sure I've used this pattern >> return icons.toArray(EMPTY_TRAY_ARRAY); >> in code that runs often and may be performance sensitive, so I don't see anything weird about it. >> OTOH I am not sure this code is anything that needs super-optimising .. we seem to have gone down that discussion route because it was the justification for the change. >> >> BTW the shiplev article, which I skimmed must be suggesting that the array initialisation must be faster if it is on the array it allocates itself because of the APIs used .. but as he also notes things can change. >> >> Anyway this is mildly interesting discussion but no one will ever, ever be able to measure a difference when it used here since it is probably 0.0001 % of the work ... > > It also has a functional implication, in the old code the "size" on a Vector is called outside of the lock. So the resulted array after "icons.toArray" can be bigger than the number of icons. This is similar to this: > https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.desktop/share/classes/javax/sound/midi/Sequence.java#L281 > I think that race can even be triggered by the new test. I remember IDEs used to suggest using correctly sized arrays in the calls to `toArray`. Now they suggest using zero-sized array. My idea was to resolve the warning raised by the IDE to reduce the number of yellow highlights on the file outline. I agree the performance gain if any is negligible in this case: we don't expect many icons, probably no more than 3. ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From aivanov at openjdk.java.net Tue May 24 11:39:50 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 11:39:50 GMT Subject: Integrated: 8284213: Replace usages of 'a the' in xml In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > I tried to avoid changing external libraries, there are quite a few such typos. > Let me know if I should revert any files. This pull request has now been integrated. Changeset: 5974f5fe Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/5974f5fed3ef888e8e64b1bf33793a7bcc4ca77c Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod 8284213: Replace usages of 'a the' in xml Reviewed-by: lancea, dmarkov, iris, prr, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/8769 From duke at openjdk.java.net Tue May 24 16:23:59 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 24 May 2022 16:23:59 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:58:34 GMT, Mark Powers wrote: >> JDK-6725221 Standardize obtaining boolean properties with defaults > > Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Alan and Jamil comments > - Merge > - reverse true.equals and false.equals changes > - Merge > - Merge > - first iteration Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot? ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From achung at openjdk.java.net Tue May 24 17:02:24 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Tue, 24 May 2022 17:02:24 GMT Subject: RFR: 8286481: Exception printed to stdout on Windows when storing transparent image in clipboard Message-ID: Removed stacktrace from WClipboard ------------- Commit messages: - removed printing stack trace Changes: https://git.openjdk.java.net/jdk/pull/8871/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8871&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286481 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8871.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8871/head:pull/8871 PR: https://git.openjdk.java.net/jdk/pull/8871 From honkar at openjdk.java.net Tue May 24 17:30:51 2022 From: honkar at openjdk.java.net (Harshitha Onkar) Date: Tue, 24 May 2022 17:30:51 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:29:43 GMT, Tejesh R wrote: >> Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803 > >> Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803 > > Means you are suggesting to use the passfailFrame? @TejeshR13 As mentioned by @aivanov-jdk, @mrserb [PassFailJFrame Framework](https://github.com/openjdk/jdk/blob/45180633d34b6cbb679bae0753d9f422e76d6297/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L47), allows you to create the required UI for manual tests and automatically handles the disposal of any test resources. ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From mickleness at gmail.com Tue May 24 17:52:08 2022 From: mickleness at gmail.com (Jeremy Wood) Date: Tue, 24 May 2022 17:52:08 +0000 Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin) Message-ID: This is a P3 ticket currently assigned to Philip Race: https://bugs.openjdk.java.net/browse/JDK-8264999 If I put together a PR: Is anyone available/willing to help review it? I made a rough draft of a potential solution last night. I can continue to work on this, or I can move on if the interest isn?t there. (No urgency at all.) Regards, - Jeremy From honkar at openjdk.java.net Tue May 24 17:54:57 2022 From: honkar at openjdk.java.net (Harshitha Onkar) Date: Tue, 24 May 2022 17:54:57 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 In-Reply-To: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Message-ID: On Tue, 24 May 2022 08:28:57 GMT, Prasanta Sadhukhan wrote: > Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 > > x 13 y 0 refRGB ffeeeeee customRGB ffefeeee > x 0 y 0 refRGB ffefefef customRGB ffefeeef > > > so added color tolerance check. > Also, added other stability fixes.. > Several iteration of test passed in intended M1 and x64 system. test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java line 64: > 62: > 63: public static void main(String[] args) throws Exception { > 64: if (!System.getProperty("os.name").toLowerCase().contains("os x")) { @prsadhuk Since the tag **@requires (os.family == "mac")** is added, is this check necessary or is it added for standalone testing purpose? ------------- PR: https://git.openjdk.java.net/jdk/pull/8864 From prr at openjdk.java.net Tue May 24 17:57:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 24 May 2022 17:57:57 GMT Subject: Integrated: 8275170: Some jtreg sound tests should be marked with sound keyword In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race wrote: > This fix adds "headful sound" keywords to a number of javax/sound jtreg tests > > The jtreg javax.sound tests are written in such a way that if a needed audio device > or other platform resource is not available, they just exit with a "pass" for the test. > It is as if headful tests just swallowed HeadlessException and issued a pass. > If we allowed that we'd be effectively testing almost nothing of real importance. > > Currently almost all sound tests have no keyword like "headful" to indicate they > may need access to a hardware resource to do anything useful so a similar > situation arises there except when someone runs those tests manually on > a local system which has audio devices. > > Of course "headful" and "audio device" aren't exactly interchangeable terms > but if tests are allowed to be run - or worse usually or always run - in a situation > where they potentially are on a system without an audio device (a headless VM) or are running in > a session which doesn't have full desktop access - which may in some > cases be how audio device access is granted, then they are more likely > to be running in this scenario where the testing isn't valid. > > Another point is that headful tests must be run one at a time - no concurrency because > you can't have multiple tests moving the mouse at the same time > Whereas for headless tests, a test harness may choose to run concurrently - perhaps even in the same VM > When tests that really need access to an audio device are run it is probably safer to consider > the headful attribute as implying one test at a time is best .. granted on a desktop it isn't > usual for a single app to be able to monopolize access to a speaker, but for input devices > that is what you'd generally expect. > > By no means am I sure that the tests being updated here are the full set that need tagging. > There are a lot of tests and they are all known to pass on systems with NO audio > devices, so the search has been for tests which call APIs which will definitely > need access to some device in order to do anything useful. > So likely there are more to be added - either by a reviewer pointing them out or by later discovery. > Alternatively we could mark ALL sound tests headful .. but given where we are starting from > that might be erring unnecessarily far in the opposite direction. > > By adding both headful and sound keywords it gives options to someone who > wants to identify the tests and perhaps run just tests which need "sound" on some > config they know supports audio but isn't headful. This pull request has now been integrated. Changeset: 25669bb6 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/25669bb667466b3cc814f8f08d4e3a2982a4cf2e Stats: 63 lines in 58 files changed: 59 ins; 0 del; 4 mod 8275170: Some jtreg sound tests should be marked with sound keyword Reviewed-by: kizune, serb, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/6086 From wetmore at openjdk.java.net Tue May 24 18:14:56 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Tue, 24 May 2022 18:14:56 GMT Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:20:10 GMT, Mark Powers wrote: > Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot? IIUC, these are due to Loom failures in some of the other platforms supported by OpenJDK but not by Oracle. They are being resolved. ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From duke at openjdk.java.net Tue May 24 18:20:00 2022 From: duke at openjdk.java.net (Mark Powers) Date: Tue, 24 May 2022 18:20:00 GMT Subject: Integrated: JDK-6725221 Standardize obtaining boolean properties with defaults In-Reply-To: References: Message-ID: <6NZWhFHhhJI3m2-DVm8Jzfla_Z7hPbnhGf4H8cBpM6c=.9e3988f9-cefd-4399-9e83-6ef6ae5ad29e@github.com> On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults This pull request has now been integrated. Changeset: 6cc4bb11 Author: Mark Powers Committer: Bradford Wetmore URL: https://git.openjdk.java.net/jdk/commit/6cc4bb1169f34bc091cad3e2deec37cd5585e8d5 Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod 6725221: Standardize obtaining boolean properties with defaults Reviewed-by: prr, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/8559 From dnguyen at openjdk.java.net Tue May 24 18:21:34 2022 From: dnguyen at openjdk.java.net (Damon Nguyen) Date: Tue, 24 May 2022 18:21:34 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v2] In-Reply-To: References: Message-ID: > Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc. Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into 8012675/htmlTagParserDocChange - Updated Parser class doc to include info regarding lack of support for html script tags. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7446/files - new: https://git.openjdk.java.net/jdk/pull/7446/files/cf3e3b8e..c366a241 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=00-01 Stats: 979753 lines in 9653 files changed: 631499 ins; 269549 del; 78705 mod Patch: https://git.openjdk.java.net/jdk/pull/7446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7446/head:pull/7446 PR: https://git.openjdk.java.net/jdk/pull/7446 From duke at openjdk.java.net Tue May 24 20:31:32 2022 From: duke at openjdk.java.net (Jeremy) Date: Tue, 24 May 2022 20:31:32 GMT Subject: RFR: 8286093: java/awt/geom/Path2D/UnitTest.java failed with "RuntimeException: 2D bounds too small" [v3] In-Reply-To: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: > This resolves an occasional unit test failure in Path2D.UnitTest. > > The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. > > This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. > > This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. Jeremy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge remote-tracking branch 'origin/master' into JDK-8176501 - Merge pull request #2 from openjdk/master Merge openjdk/jdk - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. - Merge branch 'master' into JDK-8176501 # Conflicts: # src/java.desktop/share/classes/java/awt/geom/Path2D.java # test/jdk/java/awt/geom/Path2D/UnitTest.java - Merge pull request #1 from openjdk/master Merge openjdk/jdk into mickleness/jdk - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Restoring original behavior. The "10_000_000 : 10_000_000" line should never have been committed. - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box This resolves occasional unit test failures in java.awt.geom.Path2D.UnitTest. (For ex, see seeds 4603421469924484958L, 4596019360892069260L, 4604586530476373958L, 4603766396818608126L) The problem appears to be that the UnitTest class randomly creates PathIterator segments in a way that can place lines/quads/cubics immediately after a SEG_CLOSE. That is: after a SEG_CLOSE there was no SEG_MOVETO as new segments followed. The previous Path2D#getBounds2D(PathIterator) method assumed each subpath *always* started with a SEG_MOVETO. (I don't know if this is formally stated in a specification anywhere or not?) The unit test failures show this is a bad assumption. With this change: when a SEG_CLOSE is encountered: we reset the cursor to the last (moveX, moveY) point. This appears to resolve the unit test failures, which suggests this is consistent with what existing awt.geom classes also do. - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Turn on "verbose" mode before running any tests - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Isolating 4 test case failures to focus on. - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Modify the unit test so we log random seeds. Because these unit tests use random numbers: failures can appear randomly. With this commit: we'll log the random seeds so we can easily reproduce specific failures. Also we'll be able to say with certainty if we fixed a failure or not. - ... and 19 more: https://git.openjdk.java.net/jdk/compare/9b7e42c0...3d1cbc94 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8828/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8828&range=02 Stats: 68 lines in 2 files changed: 37 ins; 5 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/8828.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8828/head:pull/8828 PR: https://git.openjdk.java.net/jdk/pull/8828 From bourges.laurent at gmail.com Tue May 24 20:35:21 2022 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 24 May 2022 22:35:21 +0200 Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin) In-Reply-To: References: Message-ID: Thanks Jereremy for the notification I was not aware of this one. I wonder if the problem should be fixed inside the marlin renderer Stroker that should ignore such useless lineTo... I will read your code and try to figure out potential causes in stroker and give you my feedback. Laurent Le mar. 24 mai 2022, 19:52, Jeremy Wood a ?crit : > This is a P3 ticket currently assigned to Philip Race: > https://bugs.openjdk.java.net/browse/JDK-8264999 > > If I put together a PR: Is anyone available/willing to help review it? > > I made a rough draft > < > https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1> > > of a potential solution last night. I can continue to work on this, or I > can move on if the interest isn?t there. > > (No urgency at all.) > > Regards, > - Jeremy > > From philip.race at oracle.com Tue May 24 20:37:34 2022 From: philip.race at oracle.com (Philip Race) Date: Tue, 24 May 2022 13:37:34 -0700 Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin) In-Reply-To: References: Message-ID: <6c3df0cb-b00c-84fb-7440-1c55c6193b91@oracle.com> I haven't investigated this issue at all .. so sure. -phil. On 5/24/22 10:52 AM, Jeremy Wood wrote: > This is a P3 ticket currently assigned to Philip Race: > https://bugs.openjdk.java.net/browse/JDK-8264999 > > If I put together a PR: Is anyone available/willing to help review it? > > I made a rough draft > > of a potential solution last night. I can continue to work on this, or > I can move on if the interest isn?t there. > > (No urgency at all.) > > Regards, > ?- Jeremy > From mickleness at gmail.com Tue May 24 20:55:24 2022 From: mickleness at gmail.com (Jeremy Wood) Date: Tue, 24 May 2022 20:55:24 +0000 Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin) In-Reply-To: References: Message-ID: I may still move it in the Stroker classes. There are a few other things I want to look at, too. This is a very rough draft I put together in under an hour; I just wanted to make sure it was worth pursuing before I put more time into it. - Jeremy ------ Original Message ------ >From "Laurent Bourg?s" To "Jeremy Wood" Cc client-libs-dev at openjdk.java.net Date 5/24/2022 4:35:21 PM Subject Re: Any interest in JDK-8264999 (stroke miter edge case in Marlin) >Thanks Jereremy for the notification I was not aware of this one. > >I wonder if the problem should be fixed inside the marlin renderer >Stroker that should ignore such useless lineTo... > >I will read your code and try to figure out potential causes in stroker >and give you my feedback. > >Laurent > >Le mar. 24 mai 2022, 19:52, Jeremy Wood a ?crit >: >>This is a P3 ticket currently assigned to Philip Race: >>https://bugs.openjdk.java.net/browse/JDK-8264999 >> >>If I put together a PR: Is anyone available/willing to help review it? >> >>I made a rough draft >> >>of a potential solution last night. I can continue to work on this, or >>I >>can move on if the interest isn?t there. >> >>(No urgency at all.) >> >>Regards, >> - Jeremy >> From prr at openjdk.java.net Tue May 24 20:55:59 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 24 May 2022 20:55:59 GMT Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 08:09:20 GMT, Martin Desruisseaux wrote: >> Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted. >> >> The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are: >> >> * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value. >> * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method. > > Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: > > Test all plugins, not only "BMP". I've just kicked off a test job. Results tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/8700 From chen.j.patrick at gmail.com Mon May 23 09:13:35 2022 From: chen.j.patrick at gmail.com (Patrick Chen) Date: Mon, 23 May 2022 11:13:35 +0200 Subject: RFR: 8287148: Avoid redundant HashMap.containsKey calls in ExtendedKeyCodes.getExtendedKeyCodeForChar In-Reply-To: References: Message-ID: "It's clearer and a bit faster." yeah totally agree Le lun. 23 mai 2022 ? 11:03, Andrey Turbanov a ?crit : > `sun.awt.ExtendedKeyCodes#regularKeyCodesMap` contains only non-null > values. It means we can replace containsKey+get with get+null check. > It's clearer and a bit faster. > > ------------- > > Commit messages: > - [PATCH] Avoid redundant HashMap.containsKey calls in ExtendedKeyCodes > > Changes: https://git.openjdk.java.net/jdk/pull/8489/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8489&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8287148 > Stats: 18 lines in 1 file changed: 3 ins; 5 del; 10 mod > Patch: https://git.openjdk.java.net/jdk/pull/8489.diff > Fetch: git fetch https://git.openjdk.java.net/jdk > pull/8489/head:pull/8489 > > PR: https://git.openjdk.java.net/jdk/pull/8489 > From kirill.grouchnikov at gmail.com Tue May 24 23:48:35 2022 From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov) Date: Tue, 24 May 2022 19:48:35 -0400 Subject: Hairline strokes under fractional display metrics Message-ID: I'm trying to figure out what is the right way to draw paths such rectangles or rounded rectangles, such that horizontal and vertical parts always fall on a full pixel and are displayed at hairline stroke width. A long time ago there was an option to specify stroke width of 0 for that, but then it was quickly reverted. My understanding is that I need to query scale x and scale y of the device's config's transform, and use that to compute the stroke width. Here's my code - https://github.com/kirill-grouchnikov/radiance/blob/sunshine/demos/theming-demo/src/main/java/org/pushingpixels/radiance/demo/theming/main/Hairlines.java (no dependency on anything from Radiance, just the core Swing / AWT stuff). Now, running this on a Windows 10 laptop with recommended / default 250% scale factor gets the correct value of 2.5 as scale. But the visuals switch between hairline and "smudged" as I horizontally resize the frame one pixel at a time and the component shifts horizontally - https://raw.githubusercontent.com/kirill-grouchnikov/radiance/sunshine/docs/images/hairlines.png (and the horizontal lines are also not hairline) How do I make this work in Java2D across all display scale factors so that I get consistent hairlines? I see the same behavior on Java 9 and Java 17 Thanks Kirill From kbarrett at openjdk.java.net Wed May 25 01:54:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 25 May 2022 01:54:55 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 08:40:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge remote-tracking branch 'upstream/master' into gcc12-warnings > - Use getter function to access "_data" > - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp > - revert changes for memnode.cpp and type.cpp > - Add assert to check the range of BasicType > - Merge remote-tracking branch 'upstream/master' into HEAD > - Revert change for java.c , parse_manifest.c , LinuxPackage.c > - Calculate char offset before realloc() > - Use return value from JLI_Snprintf > - Avoid pragma error in before GCC 12 > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 Changes requested by kbarrett (Reviewer). src/hotspot/share/oops/array.hpp line 102: > 100: // standard operations > 101: int length() const { return _length; } > 102: T* data() const { return reinterpret_cast(reinterpret_cast(this) + base_offset_in_bytes()); } Adding the const-qualifier to the `data()` function and then implicitly casting it away (by casting through intptr_t) is wrong. Either don't const-qualify (and leave it to some future use that needs such to address appropriately), or have two functions. Also, the line length is excessive. So this: T* data() { return reinterpret_cast( reinterpret_cast(this) + base_offset_in_bytes()); } and optionally add this: const T* data() const { return reinterpret_cast( reinterpret_cast(this) + base_offset_in_bytes()); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Wed May 25 01:54:56 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 25 May 2022 01:54:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <2Fd9HKYBsrWvMvJoKwAL2tN010yXbzMGA15Vz1e9aRU=.80246fcf-ba7e-4ec7-aea3-ec2aa011e863@github.com> On Sun, 22 May 2022 16:45:11 GMT, Kim Barrett wrote: >> It might be GCC bug... >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 >> >> This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). > > I don't see the similarity. That gcc bug is about literals used as addresses, > which get treated (suggested inappropriately) as NULL+offset, with NULL+offset > being a cause of warnings. I don't see that happening in our case. That is, > in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL > that I can see. > > It's hard for me to investigate this any further just by perusing the code, so > I'm in the process of getting set up to build with gcc12.x. That will let me > do some experiments. It may take me a few days to get to that point though. I spent some time looking into this one. I agree there is a false positive here, and there doesn't seem to be a better solution than suppressing the warning. I would prefer the change below, rather than what's proposed. Also eliminate the changes to utilities/compilerWarnings files. This is a very gcc-specific issue; there's no reason to generalize the solution. The reason for relocating the suppression is to be able to describe the issue in more detail in a context where that description makes sense. template inline void JfrTraceIdBits::store(jbyte bits, const T* ptr) { assert(ptr != NULL, "invariant"); // gcc12 warns "writing 1 byte into a region of size 0" when T == Klass. // The warning seems to be a false positive. And there is no warning for // other types that use the same mechanisms. The warning also sometimes // goes away with minor code perturbations, such as replacing function calls // with equivalent code directly inlined. PRAGMA_DIAG_PUSH PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") set(bits, traceid_tag_byte(ptr)); PRAGMA_DIAG_POP } ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kirill.grouchnikov at gmail.com Tue May 24 00:14:41 2022 From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov) Date: Mon, 23 May 2022 20:14:41 -0400 Subject: Hairline strokes under fractional display metrics Message-ID: I'm trying to figure out what is the right way to draw paths such rectangles or rounded rectangles, such that horizontal and vertical parts always fall on a full pixel and are displayed at hairline stroke width. A long time ago there was an option to specify stroke width of 0 for that, but then it was quickly reverted. My understanding is that I need to query scale x and scale y of the device's config's transform, and use that to compute the stroke width. Here's my code: import javax.swing.*; import java.awt.*; import java.awt.geom.AffineTransform; import java.awt.geom.Rectangle2D; abstract class Base extends JComponent { protected float strokeWidth; public Base() { this.setOpaque(false); this.setPreferredSize(new Dimension(80, 24)); this.strokeWidth = 1.0f / (float) getScaleFactor(); } private static double getScaleFactor(GraphicsDevice device) { GraphicsConfiguration graphicsConfig = device.getDefaultConfiguration(); AffineTransform tx = graphicsConfig.getDefaultTransform(); double scaleX = tx.getScaleX(); double scaleY = tx.getScaleY(); return Math.max(scaleX, scaleY); } private static double getScaleFactor() { double result = 1.0; GraphicsEnvironment e = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice[] devices = e.getScreenDevices(); // now get the configurations for each device for (GraphicsDevice device : devices) { result = Math.max(result, getScaleFactor(device)); } return result; } } class Version1 extends Base { @Override protected void paintComponent(Graphics g) { Graphics2D g2d = (Graphics2D) g.create(); g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); g2d.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE); g2d.setStroke(new BasicStroke(this.strokeWidth, BasicStroke.JOIN_ROUND, BasicStroke.CAP_BUTT)); g2d.setColor(Color.BLACK); g2d.draw(new Rectangle2D.Float(this.strokeWidth, this.strokeWidth, this.getWidth() - 2 * this.strokeWidth, this.getHeight() - 2 * this.strokeWidth)); for (int i = 1; i < 5; i++) { float inset = 2 * i; g2d.draw(new Rectangle2D.Float(this.strokeWidth + inset, this.strokeWidth + inset, this.getWidth() - 2 * this.strokeWidth - 2 * inset, this.getHeight() - 2 * this.strokeWidth - 2 * inset)); } g2d.dispose(); } } public class Hairlines { public static void main(String[] args) { SwingUtilities.invokeLater(() -> { JFrame frame = new JFrame("Hairlines"); frame.setLayout(new FlowLayout()); JComponent version1 = new Version1(); frame.add(version1); frame.setVisible(true); frame.pack(); frame.setLocationRelativeTo(null); frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); }); } } Now, running this on a Windows 10 laptop with recommended / default 250% scale factor gets the correct value of 2.5 as scale. But the visuals switch between hairline and "smudged" as I horizontally resize the frame one pixel at a time and the component shifts horizontally: [image: image.png] (and the horizontal lines are also not hairline) How do I make this work in Java2D across all display scale factors so that I get consistent hairlines? I see the same behavior on Java 9 and Java 17 Thanks Kirill From psadhukhan at openjdk.java.net Wed May 25 02:59:51 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 25 May 2022 02:59:51 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 In-Reply-To: References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Message-ID: On Tue, 24 May 2022 17:51:27 GMT, Harshitha Onkar wrote: >> Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 >> >> x 13 y 0 refRGB ffeeeeee customRGB ffefeeee >> x 0 y 0 refRGB ffefefef customRGB ffefeeef >> >> >> so added color tolerance check. >> Also, added other stability fixes.. >> Several iteration of test passed in intended M1 and x64 system. > > test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java line 64: > >> 62: >> 63: public static void main(String[] args) throws Exception { >> 64: if (!System.getProperty("os.name").toLowerCase().contains("os x")) { > > @prsadhuk Since the tag **@requires (os.family == "mac")** is added, is this check necessary or is it added for standalone testing purpose? Yes for standalone testing for which I also removed dependancy on jtreg Platform class ------------- PR: https://git.openjdk.java.net/jdk/pull/8864 From prr at openjdk.java.net Wed May 25 06:12:56 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 May 2022 06:12:56 GMT Subject: RFR: 8286481: Exception printed to stdout on Windows when storing transparent image in clipboard In-Reply-To: References: Message-ID: <5VOzdLxj1QvYShp_gm2dey0vMFUM0-wd85AmXLgsGjY=.9c56c8d1-d0ee-448c-8ff8-d1f429fc8cc7@github.com> On Tue, 24 May 2022 16:54:55 GMT, Alisen Chung wrote: > Removed stacktrace from WClipboard src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java line 89: > 87: // javaJVMLocalObjectMimeType failed to serialize. > 88: // May remove this if-check when 5078787 is fixed. > 89: if (!(flavor.isMimeTypeEqual(DataFlavor.javaJVMLocalObjectMimeType) && https://bugs.openjdk.java.net/browse/JDK-5078787 is not fixed .. so .. ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8871 From bourges.laurent at gmail.com Wed May 25 06:15:10 2022 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 25 May 2022 08:15:10 +0200 Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin) In-Reply-To: References: Message-ID: Jeremy, Probably your fix could be plugged in marlin pathTo() : https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768 Or in Stroker lineTo... Laurent Le mar. 24 mai 2022, 22:55, Jeremy Wood a ?crit : > I may still move it in the Stroker classes. There are a few other things > I want to look at, too. This is a very rough draft I put together in > under an hour; I just wanted to make sure it was worth pursuing before I > put more time into it. > > - Jeremy > > > ------ Original Message ------ > From "Laurent Bourg?s" > To "Jeremy Wood" > Cc client-libs-dev at openjdk.java.net > Date 5/24/2022 4:35:21 PM > Subject Re: Any interest in JDK-8264999 (stroke miter edge case in > Marlin) > > >Thanks Jereremy for the notification I was not aware of this one. > > > >I wonder if the problem should be fixed inside the marlin renderer > >Stroker that should ignore such useless lineTo... > > > >I will read your code and try to figure out potential causes in stroker > >and give you my feedback. > > > >Laurent > > > >Le mar. 24 mai 2022, 19:52, Jeremy Wood a ?crit > >: > >>This is a P3 ticket currently assigned to Philip Race: > >>https://bugs.openjdk.java.net/browse/JDK-8264999 > >> > >>If I put together a PR: Is anyone available/willing to help review it? > >> > >>I made a rough draft > >>< > https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1 > > > >>of a potential solution last night. I can continue to work on this, or > >>I > >>can move on if the interest isn?t there. > >> > >>(No urgency at all.) > >> > >>Regards, > >> - Jeremy > >> > From bourges.laurent at gmail.com Wed May 25 06:57:01 2022 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 25 May 2022 08:57:01 +0200 Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin) In-Reply-To: References: Message-ID: In Stroker, this lines seems causing the problem: https://github.com/openjdk/jdk/blob/a0cccb54791d954bf08da5aac9b9794e370617c8/src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java#L568 If delta is 0, then tangent is (1, 0) ! Should be: If drawOp was lineTo and delta is 0, return (skip). I wonder if there are other renderer suffering the same problem. Phil, how could we generalize this kind of path operation filtering ? My 2 cents, Laurent Le mer. 25 mai 2022, 08:15, Laurent Bourg?s a ?crit : > Jeremy, > > Probably your fix could be plugged in marlin pathTo() : > > https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768 > > Or in Stroker lineTo... > > Laurent > > Le mar. 24 mai 2022, 22:55, Jeremy Wood a ?crit : > >> I may still move it in the Stroker classes. There are a few other things >> I want to look at, too. This is a very rough draft I put together in >> under an hour; I just wanted to make sure it was worth pursuing before I >> put more time into it. >> >> - Jeremy >> >> >> ------ Original Message ------ >> From "Laurent Bourg?s" >> To "Jeremy Wood" >> Cc client-libs-dev at openjdk.java.net >> Date 5/24/2022 4:35:21 PM >> Subject Re: Any interest in JDK-8264999 (stroke miter edge case in >> Marlin) >> >> >Thanks Jereremy for the notification I was not aware of this one. >> > >> >I wonder if the problem should be fixed inside the marlin renderer >> >Stroker that should ignore such useless lineTo... >> > >> >I will read your code and try to figure out potential causes in stroker >> >and give you my feedback. >> > >> >Laurent >> > >> >Le mar. 24 mai 2022, 19:52, Jeremy Wood a ?crit >> >: >> >>This is a P3 ticket currently assigned to Philip Race: >> >>https://bugs.openjdk.java.net/browse/JDK-8264999 >> >> >> >>If I put together a PR: Is anyone available/willing to help review it? >> >> >> >>I made a rough draft >> >>< >> https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1 >> > >> >>of a potential solution last night. I can continue to work on this, or >> >>I >> >>can move on if the interest isn?t there. >> >> >> >>(No urgency at all.) >> >> >> >>Regards, >> >> - Jeremy >> >> >> > From ysuenaga at openjdk.java.net Wed May 25 09:16:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 25 May 2022 09:16:43 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Change Array::data() implementation - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/042c1c70..17cda224 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07-08 Stats: 39 lines in 4 files changed: 18 ins; 18 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Wed May 25 09:16:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 25 May 2022 09:16:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: <9kogffvvtXsQPgsozHqM-4XQlGBFZv8JVURdlpX0W4s=.68aa1f9e-4abd-405a-accf-e931090623ea@github.com> On Wed, 25 May 2022 01:50:57 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge remote-tracking branch 'upstream/master' into gcc12-warnings >> - Use getter function to access "_data" >> - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp >> - revert changes for memnode.cpp and type.cpp >> - Add assert to check the range of BasicType >> - Merge remote-tracking branch 'upstream/master' into HEAD >> - Revert change for java.c , parse_manifest.c , LinuxPackage.c >> - Calculate char offset before realloc() >> - Use return value from JLI_Snprintf >> - Avoid pragma error in before GCC 12 >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 > > src/hotspot/share/oops/array.hpp line 102: > >> 100: // standard operations >> 101: int length() const { return _length; } >> 102: T* data() const { return reinterpret_cast(reinterpret_cast(this) + base_offset_in_bytes()); } > > Adding the const-qualifier to the `data()` function and then implicitly > casting it away (by casting through intptr_t) is wrong. Either don't > const-qualify (and leave it to some future use that needs such to address > appropriately), or have two functions. Also, the line length is excessive. > So this: > > > T* data() { > return reinterpret_cast( > reinterpret_cast(this) + base_offset_in_bytes()); > } > > and optionally add this: > > const T* data() const { > return reinterpret_cast( > reinterpret_cast(this) + base_offset_in_bytes()); > } Thanks a lot @kimbarrett ! I updated around stringop-overflow warning in jfrTraceIdBits.inline.hpp , and added two `data()` in `Array` class. They works fine on my GCC 12 on Fedora 36. Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kizune at openjdk.java.net Wed May 25 10:42:56 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Wed, 25 May 2022 10:42:56 GMT Subject: Integrated: 8284690: [macos] VoiceOver : Getting java.lang.IllegalArgumentException: Invalid location on Editable JComboBox In-Reply-To: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> References: <2i-JrRSudblCAV8PLToMaV1QCfgjnC0xkD0ioAUG3HI=.aef70da6-9098-430f-96ed-bb997b6ced9c@github.com> Message-ID: On Fri, 20 May 2022 21:13:35 GMT, Alexander Zuev wrote: > Check for the available range on the document model and adjust text range request accordingly. This pull request has now been integrated. Changeset: ebfa27b9 Author: Alexander Zuev URL: https://git.openjdk.java.net/jdk/commit/ebfa27b9f06aee8ceceabc564a78a351903ce9a1 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8284690: [macos] VoiceOver : Getting java.lang.IllegalArgumentException: Invalid location on Editable JComboBox Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/8820 From psadhukhan at openjdk.java.net Wed May 25 12:00:55 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 25 May 2022 12:00:55 GMT Subject: RFR: 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver In-Reply-To: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> References: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> Message-ID: On Thu, 19 May 2022 23:46:48 GMT, Phil Race wrote: > This adds the Microsoft Basic Render Driver to our "bad hardware" list so that we don't use that pipeline there. > We have at least the one test that fails there and I am not sure we get any benefit from this. > I'm sure Microsoft need to provide for apps that have only a D3D option, but that isn't the JDK case. > > FYI there was a PR a while back about problem listing that failing test : https://github.com/openjdk/jdk/pull/5930 > but we don't need to do that with this change - nor worry about similar problems with other tests. Marked as reviewed by psadhukhan (Reviewer). src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h line 58: > 56: > 57: // Microsoft Basic Render Driver (as maybe used in VMs such as VirtualBox) > 58: { 0x1414, 0x008c, NO_VERSION, OS_ALL }, Any particular reason for not putting ALL_DEVICEIDS? ------------- PR: https://git.openjdk.java.net/jdk/pull/8797 From duke at openjdk.java.net Wed May 25 12:21:51 2022 From: duke at openjdk.java.net (Tejesh R) Date: Wed, 25 May 2022 12:21:51 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton [v2] In-Reply-To: References: Message-ID: > Added test for checking setMargin() of JRadioButton. Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Updated based on review comments - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8286620 - Moving bug4380543.java from closed to open - Merge branch 'master' of github.com:TejeshR13/jdk - Merge branch 'openjdk:master' into master - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - Merge branch 'master' of github.com:TejeshR13/jdk - Initial Commit. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8721/files - new: https://git.openjdk.java.net/jdk/pull/8721/files/0c5ff984..2635e935 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=00-01 Stats: 456757 lines in 6203 files changed: 315635 ins; 83038 del; 58084 mod Patch: https://git.openjdk.java.net/jdk/pull/8721.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8721/head:pull/8721 PR: https://git.openjdk.java.net/jdk/pull/8721 From duke at openjdk.java.net Wed May 25 12:21:53 2022 From: duke at openjdk.java.net (Tejesh R) Date: Wed, 25 May 2022 12:21:53 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton In-Reply-To: References: Message-ID: On Tue, 24 May 2022 10:36:09 GMT, Alexey Ivanov wrote: > Just an idea for discussion: I remember that we added some support for the manual tests, kind of framework or something. Probably it will be useful to reuse when we add "new" tests? https://bugs.openjdk.java.net/browse/JDK-8283803 Thank you for the suggestion @mrserb , it did good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From duke at openjdk.java.net Wed May 25 12:21:55 2022 From: duke at openjdk.java.net (Tejesh R) Date: Wed, 25 May 2022 12:21:55 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton [v2] In-Reply-To: References: Message-ID: <0dwm9fKufahVttcKmfT85qwVKXTF_ir-LsFgLm_NmhM=.0a71a0a2-db54-426b-9e06-5729759de1df@github.com> On Tue, 24 May 2022 10:42:34 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: >> >> - Updated based on review comments >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8286620 >> - Moving bug4380543.java from closed to open >> - Merge branch 'master' of github.com:TejeshR13/jdk >> - Merge branch 'openjdk:master' into master >> - Merge remote-tracking branch 'upstream/master' >> - Merge remote-tracking branch 'upstream/master' >> - Merge branch 'master' of github.com:TejeshR13/jdk >> - Initial Commit. > > test/jdk/javax/swing/JRadioButton/bug4380543.java line 143: > >> 141: { >> 142: disposeUI(); >> 143: if (res.toString() == "false") > > This looks weird. Why can't you use `res.get()`? It returns a `Boolean` object which can be used directly in an if-condition. Updated as per the review comments @aivanov-jdk . ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From duke at openjdk.java.net Wed May 25 12:33:45 2022 From: duke at openjdk.java.net (Tejesh R) Date: Wed, 25 May 2022 12:33:45 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: References: Message-ID: <1MZn6WiVfWrH6n3ahMC-670apWTt0P8MdrU7ykspfyo=.034cb55d-9b2a-43ec-b993-0169097e7291@github.com> On Thu, 12 May 2022 04:09:29 GMT, Prasanta Sadhukhan wrote: >> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. >> This is because when the table is scrolled down to last page, the bounds.y becomes -ve >> [x=0,y=-15260,width=968,height=16000] >> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] >> but subsequent pages clip >> [[x=0,y=1296,width=968,height=1296], >> [x=0,y=2592,width=968,height=1296], >> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed >> >> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI >> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 >> >> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test update Yeah, similar issue with bounds was found w.r.t JDK-8236907. This fix looks good to me. Changes requested by TejeshR13 at github.com (no known OpenJDK username). test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 115: > 113: f.add(scrollpane); > 114: f.setSize(1000, 800); > 115: f.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); setDefaultCloseOperation() is required.....? ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From aivanov at openjdk.java.net Wed May 25 12:49:56 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 25 May 2022 12:49:56 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: <1MZn6WiVfWrH6n3ahMC-670apWTt0P8MdrU7ykspfyo=.034cb55d-9b2a-43ec-b993-0169097e7291@github.com> References: <1MZn6WiVfWrH6n3ahMC-670apWTt0P8MdrU7ykspfyo=.034cb55d-9b2a-43ec-b993-0169097e7291@github.com> Message-ID: On Wed, 25 May 2022 12:30:12 GMT, Tejesh R wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Test update > > test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 115: > >> 113: f.add(scrollpane); >> 114: f.setSize(1000, 800); >> 115: f.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); > > setDefaultCloseOperation() is required.....? Good catch! Not really? It must not be `EXIT_ON_CLOSE`. The default value is `HIDE_ON_CLOSE` and it would work well because the frame will be disposed of after the latch is released. And here I see another problem: the frame that's created by test has to handle `WindowListener.windowClosing`. Since it's required by all tests, `PassFailJFrame` should provide a default listener for this purpose. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From aturbanov at openjdk.java.net Wed May 25 13:10:58 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 25 May 2022 13:10:58 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:03:03 GMT, Tejesh R wrote: > _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE. src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java line 92: > 90: this.hasFocus = hasFocus; > 91: this.column = column; > 92: if(table != null) let's add space after `if` ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From aivanov at openjdk.java.net Wed May 25 13:19:56 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 25 May 2022 13:19:56 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F In-Reply-To: References: Message-ID: On Wed, 25 May 2022 13:06:50 GMT, Andrey Turbanov wrote: >> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE. > > src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java line 92: > >> 90: this.hasFocus = hasFocus; >> 91: this.column = column; >> 92: if(table != null) > > let's add space after `if` And put the opening brace on the same line as `if` itself to follow the Java coding style and the style that's used in below. ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From psadhukhan at openjdk.java.net Wed May 25 13:39:57 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 25 May 2022 13:39:57 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: References: <1MZn6WiVfWrH6n3ahMC-670apWTt0P8MdrU7ykspfyo=.034cb55d-9b2a-43ec-b993-0169097e7291@github.com> Message-ID: On Wed, 25 May 2022 12:45:53 GMT, Alexey Ivanov wrote: >> test/jdk/javax/swing/JTable/PrintAllPagesTest.java line 115: >> >>> 113: f.add(scrollpane); >>> 114: f.setSize(1000, 800); >>> 115: f.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE); >> >> setDefaultCloseOperation() is required.....? > > Good catch! Not really? It must not be `EXIT_ON_CLOSE`. The default value is `HIDE_ON_CLOSE` and it would work well because the frame will be disposed of after the latch is released. > > And here I see another problem: the frame that's created by test has to handle `WindowListener.windowClosing`. Since it's required by all tests, `PassFailJFrame` should provide a default listener for this purpose. There are many swing tests that has EXIT_ON_CLOSE so not sure if it's a problem .There are couple which have DISPOSE_ON_CLOSE which I can changed to but not sure if it will have any effect.. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Wed May 25 13:53:57 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 25 May 2022 13:53:57 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v13] In-Reply-To: References: Message-ID: <0hxYVsc-vybTuP3GBhRkUCAvIxpcDBpS3nUCTJe-WDQ=.4560951a-aa1d-4c9a-b6e7-fd115023edb4@github.com> > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Remove setDefaultCloseOperation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8141/files - new: https://git.openjdk.java.net/jdk/pull/8141/files/c7db6ed8..54aaab9f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8141&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8141.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8141/head:pull/8141 PR: https://git.openjdk.java.net/jdk/pull/8141 From aivanov at openjdk.java.net Wed May 25 13:53:59 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 25 May 2022 13:53:59 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: References: <1MZn6WiVfWrH6n3ahMC-670apWTt0P8MdrU7ykspfyo=.034cb55d-9b2a-43ec-b993-0169097e7291@github.com> Message-ID: On Wed, 25 May 2022 13:36:09 GMT, Prasanta Sadhukhan wrote: >> Good catch! Not really? It must not be `EXIT_ON_CLOSE`. The default value is `HIDE_ON_CLOSE` and it would work well because the frame will be disposed of after the latch is released. >> >> And here I see another problem: the frame that's created by test has to handle `WindowListener.windowClosing`. Since it's required by all tests, `PassFailJFrame` should provide a default listener for this purpose. > > There are many swing tests that has EXIT_ON_CLOSE so not sure if it's a problem .There are couple which have DISPOSE_ON_CLOSE which I can changed to but not sure if it will have any effect.. It is a problem for jtreg tests: `System.exit` shouldn't be called. We should not use it for new tests even if there are tests which use it. `DISPOSE_ON_CLOSE` is fine: it disposes of the frame; once there are no frames left, the JVM exits. For this test, `DO_NOTHING_ON_CLOSE` could also work well. After all, the user is not expected to interact with the secondary frame at all. ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Wed May 25 14:22:53 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 25 May 2022 14:22:53 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: References: <1MZn6WiVfWrH6n3ahMC-670apWTt0P8MdrU7ykspfyo=.034cb55d-9b2a-43ec-b993-0169097e7291@github.com> Message-ID: On Wed, 25 May 2022 13:48:26 GMT, Alexey Ivanov wrote: >> There are many swing tests that has EXIT_ON_CLOSE so not sure if it's a problem .There are couple which have DISPOSE_ON_CLOSE which I can changed to but not sure if it will have any effect.. > > It is a problem for jtreg tests: `System.exit` shouldn't be called. We should not use it for new tests even if there are tests which use it. > > `DISPOSE_ON_CLOSE` is fine: it disposes of the frame; once there are no frames left, the JVM exits. > > For this test, `DO_NOTHING_ON_CLOSE` could also work well. After all, the user is not expected to interact with the secondary frame at all. I dont think it is a problem now..As the tests are now run in othervm mode and not in samevm mode as we used to do pre2018.. there's a comment on this aspect too https://github.com/openjdk/jdk/pull/8293#discussion_r854488853 ANyway, I have removed the contentious call ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From aivanov at openjdk.java.net Wed May 25 14:32:59 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 25 May 2022 14:32:59 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v12] In-Reply-To: References: <1MZn6WiVfWrH6n3ahMC-670apWTt0P8MdrU7ykspfyo=.034cb55d-9b2a-43ec-b993-0169097e7291@github.com> Message-ID: <2x5aly5SwB4agIrJKXiRqlBseWxwvQisKSBQKqR_KHA=.893bda13-1725-4e77-b592-e193e7d58e10@github.com> On Wed, 25 May 2022 14:19:49 GMT, Prasanta Sadhukhan wrote: >> It is a problem for jtreg tests: `System.exit` shouldn't be called. We should not use it for new tests even if there are tests which use it. >> >> `DISPOSE_ON_CLOSE` is fine: it disposes of the frame; once there are no frames left, the JVM exits. >> >> For this test, `DO_NOTHING_ON_CLOSE` could also work well. After all, the user is not expected to interact with the secondary frame at all. > > I dont think it is a problem now..As the tests are now run in othervm mode and not in samevm mode as we used to do pre2018.. > there's a comment on this aspect too https://github.com/openjdk/jdk/pull/8293#discussion_r854488853 > > ANyway, I have removed the contentious call That's right. _?it is still fine to fix this.?_ ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From prr at openjdk.java.net Wed May 25 15:27:07 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 May 2022 15:27:07 GMT Subject: RFR: 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver In-Reply-To: References: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> Message-ID: <1U6UaJTVwDU3pLc2faC7ZMimKVWsagcI5QnCY07TjyU=.2c7b5c9b-a1cd-4938-a88e-434ef7e23743@github.com> On Wed, 25 May 2022 11:56:47 GMT, Prasanta Sadhukhan wrote: >> This adds the Microsoft Basic Render Driver to our "bad hardware" list so that we don't use that pipeline there. >> We have at least the one test that fails there and I am not sure we get any benefit from this. >> I'm sure Microsoft need to provide for apps that have only a D3D option, but that isn't the JDK case. >> >> FYI there was a PR a while back about problem listing that failing test : https://github.com/openjdk/jdk/pull/5930 >> but we don't need to do that with this change - nor worry about similar problems with other tests. > > src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h line 58: > >> 56: >> 57: // Microsoft Basic Render Driver (as maybe used in VMs such as VirtualBox) >> 58: { 0x1414, 0x008c, NO_VERSION, OS_ALL }, > > Any particular reason for not putting ALL_DEVICEIDS? er, yeah, because it would be wrong. If Microsoft had a graphics card of their own, say in a Surface Pro, all device ids would disable that too .. and I have no reason to do that without evidence that all MS drivers for all theoretical MS hardware will have problems ------------- PR: https://git.openjdk.java.net/jdk/pull/8797 From aivanov at openjdk.java.net Wed May 25 15:37:04 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 25 May 2022 15:37:04 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v13] In-Reply-To: <0hxYVsc-vybTuP3GBhRkUCAvIxpcDBpS3nUCTJe-WDQ=.4560951a-aa1d-4c9a-b6e7-fd115023edb4@github.com> References: <0hxYVsc-vybTuP3GBhRkUCAvIxpcDBpS3nUCTJe-WDQ=.4560951a-aa1d-4c9a-b6e7-fd115023edb4@github.com> Message-ID: <5ijaHXSsWhJTy2J8BP6p-Knw6AZvJOfSOfxGlwuNWAU=.ae03adf6-8cde-4da3-ad6e-1a14f52f3579@github.com> On Wed, 25 May 2022 13:53:57 GMT, Prasanta Sadhukhan wrote: >> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. >> This is because when the table is scrolled down to last page, the bounds.y becomes -ve >> [x=0,y=-15260,width=968,height=16000] >> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] >> but subsequent pages clip >> [[x=0,y=1296,width=968,height=1296], >> [x=0,y=2592,width=968,height=1296], >> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed >> >> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI >> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 >> >> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove setDefaultCloseOperation Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From prr at openjdk.java.net Wed May 25 16:35:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 May 2022 16:35:57 GMT Subject: Integrated: 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver In-Reply-To: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> References: <5WPqakUq1V0C9N3uT3bDyTPcuD7ua_tHNSlmlbNtS-A=.a8837874-d981-4f2b-9bba-4f23585d0263@github.com> Message-ID: On Thu, 19 May 2022 23:46:48 GMT, Phil Race wrote: > This adds the Microsoft Basic Render Driver to our "bad hardware" list so that we don't use that pipeline there. > We have at least the one test that fails there and I am not sure we get any benefit from this. > I'm sure Microsoft need to provide for apps that have only a D3D option, but that isn't the JDK case. > > FYI there was a PR a while back about problem listing that failing test : https://github.com/openjdk/jdk/pull/5930 > but we don't need to do that with this change - nor worry about similar problems with other tests. This pull request has now been integrated. Changeset: bc0379ea Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/bc0379ea1a22a2631b49ecd6a331352bec81c1c6 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8275303: sun/java2d/pipe/InterpolationQualityTest.java fails with D3D basic render driver Reviewed-by: serb, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/8797 From honkar at openjdk.java.net Wed May 25 17:56:50 2022 From: honkar at openjdk.java.net (Harshitha Onkar) Date: Wed, 25 May 2022 17:56:50 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray [v2] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 11:20:36 GMT, Alexey Ivanov wrote: >> **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports. >> >> **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`. > > Alexey Ivanov has updated the pull request incrementally with three additional commits since the last revision: > > - toArray: new TrayIcon[0] -> EMPTY_TRAY_ARRAY - use existing empty array > - Drop explicit type argument > - Make popupParent final @aivanov-jdk In SystemTray.java the following line can be simplified using method reference or lambda expression. https://github.com/openjdk/jdk/blob/a2f8c9523438ca63380b0b7d4909d5e5e7fbf88a/src/java.desktop/share/classes/java/awt/SystemTray.java#L135 @aivanov-jdk In SystemTray.java the following line can be simplified using method reference or lambda expression. https://github.com/openjdk/jdk/blob/a2f8c9523438ca63380b0b7d4909d5e5e7fbf88a/src/java.desktop/share/classes/java/awt/SystemTray.java#L135 ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From aivanov at openjdk.java.net Wed May 25 18:18:42 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 25 May 2022 18:18:42 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray [v2] In-Reply-To: References: Message-ID: <46fGX3zDzE1Nh7GihF9f0cAvVkQKc5A6P4BvzjsglD4=.78157656-c67d-4c50-890f-efd22773be4b@github.com> On Wed, 25 May 2022 17:53:31 GMT, Harshitha Onkar wrote: > @aivanov-jdk In SystemTray.java the following line can be simplified using method reference or lambda expression. > > https://github.com/openjdk/jdk/blob/a2f8c9523438ca63380b0b7d4909d5e5e7fbf88a/src/java.desktop/share/classes/java/awt/SystemTray.java#L135 I left it out intentionally, it's still unclear to me what style the client-libs follow. I prefer using method references where possible. If method reference is used, the code becomes much shorter: AWTAccessor.setSystemTrayAccessor(SystemTray::firePropertyChange); What do others think? ------------- PR: https://git.openjdk.java.net/jdk/pull/8850 From dnguyen at openjdk.java.net Wed May 25 19:11:47 2022 From: dnguyen at openjdk.java.net (Damon Nguyen) Date: Wed, 25 May 2022 19:11:47 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v3] In-Reply-To: References: Message-ID: > Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc. Damon Nguyen has updated the pull request incrementally with three additional commits since the last revision: - Updated java doc for clarity. Added test to show behavior. - Merge branch '8012675/htmlTagParserDocChange' of github.com:DamonGuy/jdk into 8012675/htmlTagParserDocChange - Added debugging statements to better trace handleComments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7446/files - new: https://git.openjdk.java.net/jdk/pull/7446/files/c366a241..c7030add Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=01-02 Stats: 105 lines in 5 files changed: 95 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7446/head:pull/7446 PR: https://git.openjdk.java.net/jdk/pull/7446 From dnguyen at openjdk.java.net Wed May 25 19:17:41 2022 From: dnguyen at openjdk.java.net (Damon Nguyen) Date: Wed, 25 May 2022 19:17:41 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 19:11:47 GMT, Damon Nguyen wrote: >> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc. > > Damon Nguyen has updated the pull request incrementally with three additional commits since the last revision: > > - Updated java doc for clarity. Added test to show behavior. > - Merge branch '8012675/htmlTagParserDocChange' of github.com:DamonGuy/jdk into 8012675/htmlTagParserDocChange > - Added debugging statements to better trace handleComments I have re-opened this PR. I added a test to show script tag's current behavior that can be manually passed or failed. I have confirmed that the unsupported tags are handled by HiddenTagView, which creates JTextFields for the unsupported tags and creates JTextAreas for the contents within the tags. This is what is being displayed when an unsupported tag is encountered, with script tags being one of them. The parseScript method identifies the script tags and extracts its contents to a buffer. The chars in this buffer are then being used for handleComment. The parser uses this comment as the text to display in the JTextArea, and the tags are displayed in the JTextField with HiddenTagView. This is further confirmed when the handleComment line in parseContent is removed, the contents of the tag are no longer shown. This behavior is consistent regardless of the strict flag being true or false since that flag mainly deals with syntax and spacing issues. As such, I believe this java doc update still needs to happen as I do not see this behavior documented anywhere. I believe it's better suited for the class's doc rather than specifically parse's doc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7446 From achung at openjdk.java.net Wed May 25 19:26:30 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 25 May 2022 19:26:30 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v18] In-Reply-To: References: Message-ID: > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: updated test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/65200a23..61fc0ae9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=16-17 Stats: 241 lines in 1 file changed: 241 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Wed May 25 19:50:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 May 2022 19:50:54 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v18] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 19:26:30 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > updated test So you've updated the test so it can be headless but left it marked headful .. the -showFrame arg isn't used in jtreg .. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From achung at openjdk.java.net Wed May 25 19:58:46 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 25 May 2022 19:58:46 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v18] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 19:47:25 GMT, Phil Race wrote: > the -showFrame arg isn't used in jtreg .. Should the test not have the -showFrame arg at all? The intention was to allow showing the frame for debugging purposes if needed ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Wed May 25 20:35:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 May 2022 20:35:03 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v18] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 19:55:33 GMT, Alisen Chung wrote: > the -showFrame arg isn't used in jtreg .. > Should the test not have the -showFrame arg at all? The intention was to allow showing the frame for debugging purposes if needed It is is fine .. but unless it passed, isn't the test now headless ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Wed May 25 20:35:05 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 May 2022 20:35:05 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v18] In-Reply-To: References: Message-ID: <8q4gy23hY9uJRNjZCAGRMWiHi92A7IaotUnUxtLSLY4=.4c7ac68b-d047-4804-8d27-739af962fb4f@github.com> On Wed, 25 May 2022 19:26:30 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > updated test so -showFrame is just for a person to use "standalone" to see the results, never used by jtreg ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From achung at openjdk.java.net Wed May 25 21:37:07 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 25 May 2022 21:37:07 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: > Changed the drawing area to be increased by 0.5 on the left side to prevent clipping Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: changed test to headless ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7449/files - new: https://git.openjdk.java.net/jdk/pull/7449/files/61fc0ae9..935ec438 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7449&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7449.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7449/head:pull/7449 PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Wed May 25 21:41:50 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 25 May 2022 21:41:50 GMT Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short [v2] In-Reply-To: References: Message-ID: <17Q0kM6WsPX_96AX0_YEhvqzwoNjU4RvuDIqWuyWvLM=.ee8063c1-6686-42d6-b7e1-470424a390e3@github.com> On Mon, 23 May 2022 08:09:20 GMT, Martin Desruisseaux wrote: >> Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted. >> >> The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are: >> >> * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value. >> * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method. > > Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: > > Test all plugins, not only "BMP". Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8700 From honkar at openjdk.java.net Wed May 25 23:50:15 2022 From: honkar at openjdk.java.net (Harshitha Onkar) Date: Wed, 25 May 2022 23:50:15 GMT Subject: RFR: JDK-8287261: [macos] JList Focus Ring color doesn't follow Accent color changes on macOS Message-ID: With the proposed fix, JList's focus ring color follows accent color changes. Previously the focus ring for JList was not prominently visible and did not follow accent color changes. While investing a similar issue related to JTable (https://github.com/openjdk/jdk/pull/7768#discussion_r839813517), it was observed that List.focusCellHighlightBorder was using the cellFocusRing color as well. This PR extends the focus ring accent color changes to JLists. Related issues: [JDK-7124282](https://bugs.openjdk.java.net/browse/JDK-7124282) , [JDK-8261243](https://bugs.openjdk.java.net/browse/JDK-8261243) #### Summary of changes - focusCellHighlightBorder in `AquaLookAndFeel` changed which is used for cell border for lists and tables - code related to on-the-fly focus ring color refactored into a separate method (`changeFocusRingColor()`) for re-usability - `changeFocusRingColor()` called when PropertyChangeEvent == FRAME_ACTIVE_PROPERTY and the frame gains focus, instead of calling in individual `swapSelectionColors` in `AquaFocusHandler.java` - Common test added - `CellFocusRingTest`, which tests for both cases - Tables & Lists. **Before and After screenshots of JList** _(Screenshots from SwingSet2 demo)_ ![Screen Shot 2022-05-25 at 3 55 49 PM](https://user-images.githubusercontent.com/95945681/170382727-54ed155b-6f08-4c75-8657-89c15764e1cd.png) ------------- Commit messages: - focus ring changes for JList Changes: https://git.openjdk.java.net/jdk/pull/8896/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8896&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287261 Stats: 377 lines in 4 files changed: 189 ins; 162 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/8896.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8896/head:pull/8896 PR: https://git.openjdk.java.net/jdk/pull/8896 From kbarrett at openjdk.java.net Thu May 26 04:03:54 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 May 2022 04:03:54 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:16:43 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Change Array::data() implementation > - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp Mostly good, but I missed a problem with an earlier part of the change. Sorry I didn't notice sooner. src/java.base/unix/native/libjli/java_md_common.c line 133: > 131: > 132: snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { That should be `||` rather than `&&`. src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { > 134: return 0; > 135: } Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`. I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`. Something to report and clean up separately from this change. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From duke at openjdk.java.net Thu May 26 04:56:44 2022 From: duke at openjdk.java.net (Tejesh R) Date: Thu, 26 May 2022 04:56:44 GMT Subject: RFR: 8257810: Only First page are printed in JTable.scrollRectToVisible [v13] In-Reply-To: <0hxYVsc-vybTuP3GBhRkUCAvIxpcDBpS3nUCTJe-WDQ=.4560951a-aa1d-4c9a-b6e7-fd115023edb4@github.com> References: <0hxYVsc-vybTuP3GBhRkUCAvIxpcDBpS3nUCTJe-WDQ=.4560951a-aa1d-4c9a-b6e7-fd115023edb4@github.com> Message-ID: On Wed, 25 May 2022 13:53:57 GMT, Prasanta Sadhukhan wrote: >> Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. >> This is because when the table is scrolled down to last page, the bounds.y becomes -ve >> [x=0,y=-15260,width=968,height=16000] >> so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] >> but subsequent pages clip >> [[x=0,y=1296,width=968,height=1296], >> [x=0,y=2592,width=968,height=1296], >> [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed >> >> This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI >> We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 >> >> Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Remove setDefaultCloseOperation Marked as reviewed by TejeshR13 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Thu May 26 06:36:44 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 26 May 2022 06:36:44 GMT Subject: Integrated: 8257810: Only First page are printed in JTable.scrollRectToVisible In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 09:17:02 GMT, Prasanta Sadhukhan wrote: > Issue was when printing a JTable which sits inside a JScrollPane and the table is scrolled down to the end to about 1000th row, only the first page is printed. > This is because when the table is scrolled down to last page, the bounds.y becomes -ve > [x=0,y=-15260,width=968,height=16000] > so the check `if (!((table.getBounds()).intersects(clip)))` is satisfied only for 1st page where bounds just intersects the clip [x=0,y=0,width=968,height=1296] > but subsequent pages clip > [[x=0,y=1296,width=968,height=1296], > [x=0,y=2592,width=968,height=1296], > [x=0,y=3888,width=968,height=1296] etc is not intesecting so they are not printed > > This is a regression of JDK-8081491 which was **reworked** in JDK-8236907 where the bounds calculation and usage is made same as in BasicTableUI > We need to use the same resetted bounds for this intersection calculation too as was done for JDK-8236907 > > Tested against JDK-8081491, 8170349, JDK-8236907 testcases along with other regression tests and all are OK (link in JBS) This pull request has now been integrated. Changeset: f710393e Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/f710393e352b0945ad64df3ee5ccd34f082c2b63 Stats: 124 lines in 2 files changed: 121 ins; 2 del; 1 mod 8257810: Only First page are printed in JTable.scrollRectToVisible Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/8141 From psadhukhan at openjdk.java.net Thu May 26 07:52:28 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 26 May 2022 07:52:28 GMT Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails [v2] In-Reply-To: References: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com> Message-ID: <3cFgKe1kh2sMLag9N4n4xEAR2Z9ZyGqc514s4aBbM6Q=.3b0fb8bf-a295-48af-910c-424012dc4307@github.com> On Mon, 16 May 2022 05:33:24 GMT, Sergey Bylokhov wrote: > > > Does it mean that setVisible(true) cause some memory leak since it prevents the window to be disposed? > > > > > > Since 9 windows are freed .. I doubt it .. but what's the hold up with #10 ? I wonder if you need an extra System.gc() cycle > > Then why we delete the "setVisible(true)"? probably we leak the latest visible window? I dont think this is related to TitledBorder fix done in JDK-8204963. Even if we remove TitledBorder code from the test and only keep JFrame, then also I see `java.lang.RuntimeException: Expected Total to be freed : 10 Freed 9 ` so I think it's a generic JFrame dispose issue with CleanerFactory in linux (last JFrame is not cleaned up by CleanerFactory) which can be worked upon in a separate PR. As I see, TitledBorder leak is fixed and there's no point having the test problemlisted for linux due to JFrame issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8450 From psadhukhan at openjdk.java.net Thu May 26 08:49:42 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 26 May 2022 08:49:42 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v5] In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> Message-ID: <0L6zr9ZBlYfBwXtHFBoHkqp4LMupdzyD9eoYtDTXG6w=.39f04a5a-9d85-4f07-846f-f797d8ffbf77@github.com> > Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8190907 - korean fallback added - Revert dialogInput. Add Bolditalic - Add bold version - 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7643/files - new: https://git.openjdk.java.net/jdk/pull/7643/files/1b7a5993..a6867d26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=03-04 Stats: 729130 lines in 8283 files changed: 489779 ins; 169343 del; 70008 mod Patch: https://git.openjdk.java.net/jdk/pull/7643.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7643/head:pull/7643 PR: https://git.openjdk.java.net/jdk/pull/7643 From ysuenaga at openjdk.java.net Thu May 26 10:55:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 26 May 2022 10:55:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10] In-Reply-To: References: Message-ID: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/17cda224..851279ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 26 10:55:29 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 26 May 2022 10:55:29 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: <4B8Ib70PFV8uvUPrVUSiLk5560QAhHhUkJFpyyzUmRk=.c1f7b721-e51a-4e24-b8b3-a896bff7e1b4@github.com> On Thu, 26 May 2022 03:48:31 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change Array::data() implementation >> - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp > > src/java.base/unix/native/libjli/java_md_common.c line 133: > >> 131: >> 132: snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { > > That should be `||` rather than `&&`. Good catch! I fixed it in new commit. > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { >> 134: return 0; >> 135: } > > Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`. I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`. Something to report and clean up separately from this change. I was wondering about that too. I use `NULL` at L134, and have filed it as [JDK-8287363](https://bugs.openjdk.java.net/browse/JDK-8287363). I will work for it after this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From duke at openjdk.java.net Thu May 26 11:27:17 2022 From: duke at openjdk.java.net (Tejesh R) Date: Thu, 26 May 2022 11:27:17 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v2] In-Reply-To: References: Message-ID: > _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Updated based on review comments and Added Test case TableRenderTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8830/files - new: https://git.openjdk.java.net/jdk/pull/8830/files/b71b4a36..df184f0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=00-01 Stats: 174 lines in 2 files changed: 172 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8830.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8830/head:pull/8830 PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Thu May 26 11:46:40 2022 From: duke at openjdk.java.net (Martin Desruisseaux) Date: Thu, 26 May 2022 11:46:40 GMT Subject: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 08:09:20 GMT, Martin Desruisseaux wrote: >> Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions. The JPEG reader is not impacted. >> >> The `CanDecodeTest` class in this pull request reproduces the problem and verifies that the patch solves it. The changes in `canDecodeInput(Object)` method bodies are: >> >> * Use `ImageInputStream.read()` instead of `readByte()` and check for -1 (EOF) return value. >> * Replace `ImageInputStream.readFully(byte[])` calls by a private `tryReadFully` method. > > Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision: > > Test all plugins, not only "BMP". As a minor note, in `com.sun.imageio.plugins.common.ReaderUtil` class the `readMultiByteInteger(ImageInputStream)` method is used only by `WBMPImageReader`. Would it be worth to move (in a separated pull request) that method in `WBMPImageReader` for saving a few bytes in the common case where WBMP format is not used? ------------- PR: https://git.openjdk.java.net/jdk/pull/8700 From psadhukhan at openjdk.java.net Thu May 26 12:27:41 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 26 May 2022 12:27:41 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v4] In-Reply-To: References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> Message-ID: On Fri, 13 May 2022 22:19:12 GMT, Phil Race wrote: > I still don't understand why they are the same for you .. I added korean-fallback to my local fontconfig and ran in the Korean locale (changed my windows region to Korea and rebooted) and they are different for me. > > What I do seem to be seeing is that because we now have UTF-8 as the default encoding and that we have no UTF-8.ko that it goes the fallback route .. and so although you get korean by fallback it prefers Chinese and Japanese fonts which isn't right for a Korean locale > > I believe we need to add a line like the ja one sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol +sequence.allfonts.UTF-8.ko=alphabetic,korean,dingbats,symbol > > [See https://git.openjdk.java.net/jdk/pull/8662 for more info and we likely need to do more of these lines and perhaps you need that PR pushed to include in your testing .. alas I don't even have a single approver yet, so nowhere near the two I need !] > > .. even without that I was OK perhaps so long as the fallback seqeuence had "korean" - I'd have to re-test that > > So I don't know if that will cure them all being the same for you but it might. I tried the same way of changing region to Korean and rebooting and tried this testcase (changed keyboard IM to Korean too) I have also added sequence.allfonts.UTF-8.ko=alphabetic,korean,dingbats,symbol public class HelloWorld { private static void createAndShowGUI() { JFrame frame = new JFrame("??? Swing"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); JLabel label = new JLabel("???"); frame.getContentPane().add(label); frame.setSize(400,200); frame.setVisible(true); } public static void main(String[] args) throws Exception { Locale.setDefault(Locale.KOREAN); javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { createAndShowGUI(); } }); BufferedImage bi = new BufferedImage(600, 900, BufferedImage.TYPE_INT_RGB); Graphics2D g = bi.createGraphics(); g.setColor(Color.WHITE); g.fillRect(0,0,600,900); g.setColor(Color.BLACK); g.setFont(new Font("sansserif", Font.PLAIN, 20)); g.drawString("Sansserif Plain: ???", 100, 40); g.setFont(new Font("sansserif", Font.BOLD, 20)); g.drawString("Sansserif Bold: ???", 100, 80); g.setFont(new Font("sansserif", Font.ITALIC, 20)); g.drawString("Sansserif Italic: ???", 100, 120); g.setFont(new Font("sansserif", Font.BOLD|Font.ITALIC, 20)); g.drawString("Sansserif BoldItalic: ???", 100, 160); g.setFont(new Font("serif", Font.PLAIN, 20)); g.drawString("Serif Plain: ???", 100, 200); g.setFont(new Font("serif", Font.BOLD, 20)); g.drawString("Serif Bold: ???", 100, 240); g.setFont(new Font("serif", Font.ITALIC, 20)); g.drawString("Serif Italic: ???", 100, 280); g.setFont(new Font("serif", Font.BOLD|Font.ITALIC, 20)); g.drawString("Serif BoldItalic: ???", 100, 320); g.setFont(new Font("monospaced", Font.PLAIN, 20)); g.drawString("Monospaced Plain: ???", 100, 360); g.setFont(new Font("monospaced", Font.BOLD, 20)); g.drawString("Monospaced Bold: ???", 100, 400); g.setFont(new Font("monospaced", Font.ITALIC, 20)); g.drawString("Monospaced Italic: ???", 100, 440); g.setFont(new Font("monospaced", Font.BOLD|Font.ITALIC, 20)); g.drawString("Monospaced BoldItalic: ???", 100, 480); g.setFont(new Font("dialog", Font.PLAIN, 20)); g.drawString("Dialog Plain: ???", 100, 520); g.setFont(new Font("dialog", Font.BOLD, 20)); g.drawString("Dialog Bold: ???", 100, 560); g.setFont(new Font("dialog", Font.ITALIC, 20)); g.drawString("Dialog Italic: ???", 100, 600); g.setFont(new Font("dialog", Font.BOLD|Font.ITALIC, 20)); g.drawString("Dialog Bold Italic: ???", 100, 640); g.setFont(new Font("dialoginput", Font.PLAIN, 20)); g.drawString("DialogInput Plain: ???", 100, 680); g.setFont(new Font("dialoginput", Font.BOLD, 20)); g.drawString("DialogInput Bold: ???", 100, 720); g.setFont(new Font("dialoginput", Font.ITALIC, 20)); g.drawString("Dialog Input Italic: ???", 100, 760); g.setFont(new Font("dialoginput", Font.BOLD|Font.ITALIC, 20)); g.drawString("Dialog Input BoldItalic: ???", 100, 800); ImageIO.write(bi, "png", new File("image.png")); } } and I am getting this rendered fonts ![image](https://user-images.githubusercontent.com/43534309/170485724-51909f48-db09-4a4f-bec4-61c78e5baff7.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From kbarrett at openjdk.java.net Thu May 26 18:18:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 May 2022 18:18:41 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10] In-Reply-To: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> References: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> Message-ID: On Thu, 26 May 2022 10:55:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From prr at openjdk.java.net Thu May 26 18:45:52 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 26 May 2022 18:45:52 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: <1wCV6MUM-zZNx50iOVSE4F838_4deUXGZ-t50fujGM0=.a2c0c83f-78dd-45b0-95e7-7f2d31e7b336@github.com> On Wed, 25 May 2022 21:37:07 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > changed test to headless Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From duke at openjdk.java.net Thu May 26 21:23:49 2022 From: duke at openjdk.java.net (lukeu) Date: Thu, 26 May 2022 21:23:49 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: <5S8X5w_BzJlw2QDO-goUR66IGIBReRW9nOSwloNemqc=.d746ac85-ace4-49d7-9830-5355c8594409@github.com> On Wed, 25 May 2022 21:37:07 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > changed test to headless Hi, I've thought of another problem: this use of an unscaled AffineTransform has discarded the rotation/skew parameters, if folks are doing something funky like painting a control with these applied: ![image](https://user-images.githubusercontent.com/2722420/170580815-a2ea8e23-168f-432a-91a7-189b9189881f.png) (Like maybe to render a normally-horizontal control vertically or something.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From kirill.grouchnikov at gmail.com Thu May 26 21:47:18 2022 From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov) Date: Thu, 26 May 2022 17:47:18 -0400 Subject: Hairline strokes under fractional display metrics In-Reply-To: References: Message-ID: Haven't heard anything here, but in the meanwhile I got great pointers from Karl, the developer of JFormDesigner and FlatLaf over at https://github.com/kirill-grouchnikov/radiance/issues/39#issuecomment-1137649208 and subsequent comments. The core of the idea is to force scale factor of 1.0 on the graphics context, compute new origin and bounding box similar to how it's done in the internals of Java2D, and then strokes with width of 1.0f will be treated as full pixels (if no VALUE_STROKE_PURE hint is set). On Tue, May 24, 2022 at 7:48 PM Kirill Grouchnikov < kirill.grouchnikov at gmail.com> wrote: > I'm trying to figure out what is the right way to draw paths such > rectangles or rounded rectangles, such that horizontal and vertical parts > always fall on a full pixel and are displayed at hairline stroke width. > > A long time ago there was an option to specify stroke width of 0 for that, > but then it was quickly reverted. > > My understanding is that I need to query scale x and scale y of the > device's config's transform, and use that to compute the stroke width. > Here's my code - > https://github.com/kirill-grouchnikov/radiance/blob/sunshine/demos/theming-demo/src/main/java/org/pushingpixels/radiance/demo/theming/main/Hairlines.java > (no dependency on anything from Radiance, just the core Swing / AWT stuff). > > Now, running this on a Windows 10 laptop with recommended / default 250% > scale factor gets the correct value of 2.5 as scale. But the visuals switch > between hairline and "smudged" as I horizontally resize the frame one pixel > at a time and the component shifts horizontally - > https://raw.githubusercontent.com/kirill-grouchnikov/radiance/sunshine/docs/images/hairlines.png > (and the horizontal lines are also not hairline) > > How do I make this work in Java2D across all display scale factors so that > I get consistent hairlines? I see the same behavior on Java 9 and Java 17 > > Thanks > Kirill > From psadhukhan at openjdk.java.net Fri May 27 06:14:52 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Fri, 27 May 2022 06:14:52 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v5] In-Reply-To: <0L6zr9ZBlYfBwXtHFBoHkqp4LMupdzyD9eoYtDTXG6w=.39f04a5a-9d85-4f07-846f-f797d8ffbf77@github.com> References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> <0L6zr9ZBlYfBwXtHFBoHkqp4LMupdzyD9eoYtDTXG6w=.39f04a5a-9d85-4f07-846f-f797d8ffbf77@github.com> Message-ID: On Thu, 26 May 2022 08:49:42 GMT, Prasanta Sadhukhan wrote: >> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8190907 > - korean fallback added > - Revert dialogInput. Add Bolditalic > - Add bold version > - 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack I used unicode characters (\ud14c\uc2a4\ud2b8) in testcase and run with user.language=ko and user.country=KR and now I can see the difference between Dialog and Serif ![image](https://user-images.githubusercontent.com/43534309/170640958-70d6b34d-63e6-475e-8321-b1723fc6438e.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From honkar at openjdk.java.net Fri May 27 17:06:52 2022 From: honkar at openjdk.java.net (Harshitha Onkar) Date: Fri, 27 May 2022 17:06:52 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton [v2] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 12:21:51 GMT, Tejesh R wrote: >> Added test for checking setMargin() of JRadioButton. > > Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Updated based on review comments > - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8286620 > - Moving bug4380543.java from closed to open > - Merge branch 'master' of github.com:TejeshR13/jdk > - Merge branch 'openjdk:master' into master > - Merge remote-tracking branch 'upstream/master' > - Merge remote-tracking branch 'upstream/master' > - Merge branch 'master' of github.com:TejeshR13/jdk > - Initial Commit. Tested on Win10, visually the insets look fine. Minor formatting changes suggested. test/jdk/javax/swing/JRadioButton/bug4380543.java line 24: > 22: */ > 23: /* @test > 24: @bug 4380543 We usually have "*" for all the jtreg header lines similar to copyright test/jdk/javax/swing/JRadioButton/bug4380543.java line 51: > 49: import java.util.Map; > 50: > 51: public class bug4380543 { Based on previous test class name reviews, we usually follow non-bug id names. ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From duke at openjdk.java.net Fri May 27 17:21:29 2022 From: duke at openjdk.java.net (Tejesh R) Date: Fri, 27 May 2022 17:21:29 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton [v3] In-Reply-To: References: Message-ID: <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com> > Added test for checking setMargin() of JRadioButton. Tejesh R has updated the pull request incrementally with two additional commits since the last revision: - Updated based on review comments - Added headful key ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8721/files - new: https://git.openjdk.java.net/jdk/pull/8721/files/2635e935..3001e8a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8721&range=01-02 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8721.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8721/head:pull/8721 PR: https://git.openjdk.java.net/jdk/pull/8721 From duke at openjdk.java.net Fri May 27 17:21:36 2022 From: duke at openjdk.java.net (Tejesh R) Date: Fri, 27 May 2022 17:21:36 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 17:03:08 GMT, Harshitha Onkar wrote: >> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: >> >> - Updated based on review comments >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8286620 >> - Moving bug4380543.java from closed to open >> - Merge branch 'master' of github.com:TejeshR13/jdk >> - Merge branch 'openjdk:master' into master >> - Merge remote-tracking branch 'upstream/master' >> - Merge remote-tracking branch 'upstream/master' >> - Merge branch 'master' of github.com:TejeshR13/jdk >> - Initial Commit. > > test/jdk/javax/swing/JRadioButton/bug4380543.java line 24: > >> 22: */ >> 23: /* @test >> 24: @bug 4380543 > > We usually have "*" for all the jtreg header lines similar to copyright Accepted and updated. > test/jdk/javax/swing/JRadioButton/bug4380543.java line 51: > >> 49: import java.util.Map; >> 50: >> 51: public class bug4380543 { > > Based on previous test class name reviews, we usually follow non-bug id names. Yeah, but since its an existing regression test which is been moved here, keeping the same test/class names would be better I feel. It would also help in traceability in future I guess. ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From honkar at openjdk.java.net Fri May 27 17:25:50 2022 From: honkar at openjdk.java.net (Harshitha Onkar) Date: Fri, 27 May 2022 17:25:50 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton [v3] In-Reply-To: <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com> References: <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com> Message-ID: On Fri, 27 May 2022 17:21:29 GMT, Tejesh R wrote: >> Added test for checking setMargin() of JRadioButton. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Updated based on review comments > - Added headful key Marked as reviewed by honkar (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8721 From prr at openjdk.java.net Fri May 27 17:55:54 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 27 May 2022 17:55:54 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v5] In-Reply-To: <0L6zr9ZBlYfBwXtHFBoHkqp4LMupdzyD9eoYtDTXG6w=.39f04a5a-9d85-4f07-846f-f797d8ffbf77@github.com> References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> <0L6zr9ZBlYfBwXtHFBoHkqp4LMupdzyD9eoYtDTXG6w=.39f04a5a-9d85-4f07-846f-f797d8ffbf77@github.com> Message-ID: On Thu, 26 May 2022 08:49:42 GMT, Prasanta Sadhukhan wrote: >> Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts > > Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8190907 > - korean fallback added > - Revert dialogInput. Add Bolditalic > - Add bold version > - 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack Good to know. I still believe we should add sequence.allfonts.UTF-8.ko=alphabetic,korean,dingbats,symbol since UTF-8 is now the default encoding. ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From prr at openjdk.java.net Fri May 27 17:58:05 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 27 May 2022 17:58:05 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 21:37:07 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > changed test to headless You are right. We should extract the scale part of the transform and leave any rotation still in effect. In fact this would almost certainly be a problem if you printed the UI in landscape mode ! I can't vouch for the same perfection at acute angles but we should be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From philip.race at oracle.com Fri May 27 18:00:40 2022 From: philip.race at oracle.com (Philip Race) Date: Fri, 27 May 2022 11:00:40 -0700 Subject: Hairline strokes under fractional display metrics In-Reply-To: References: Message-ID: Indeed .. something very close to that is what is being proposed in a current PR here : https://github.com/openjdk/jdk/pull/7449/files Just bear in mind some of the same constraints and that if printed on a 1200dpi printer with a scale of 16.67 .. your one pixel line might be too thin to be seen at all. I suggest you should have an upper limit on the unscaling. I don't remember why the change a long time ago was backed out .. indeed I am not sure I remember it will enough for it to be more than a figment of my imagination but "0" used to have a special meaning in some graphics systems - X11 took it to mean "draw a line the fastest way you can, I do not care about accuracy". -phil. On 5/26/22 2:47 PM, Kirill Grouchnikov wrote: > Haven't heard anything here, but in the meanwhile I got great pointers from > Karl, the developer of JFormDesigner and FlatLaf over at > https://github.com/kirill-grouchnikov/radiance/issues/39#issuecomment-1137649208 > and subsequent comments. > > The core of the idea is to force scale factor of 1.0 on the graphics > context, compute new origin and bounding box similar to how it's done in > the internals of Java2D, and then strokes with width of 1.0f will be > treated as full pixels (if no VALUE_STROKE_PURE hint is set). > > On Tue, May 24, 2022 at 7:48 PM Kirill Grouchnikov < > kirill.grouchnikov at gmail.com> wrote: > >> I'm trying to figure out what is the right way to draw paths such >> rectangles or rounded rectangles, such that horizontal and vertical parts >> always fall on a full pixel and are displayed at hairline stroke width. >> >> A long time ago there was an option to specify stroke width of 0 for that, >> but then it was quickly reverted. >> >> My understanding is that I need to query scale x and scale y of the >> device's config's transform, and use that to compute the stroke width. >> Here's my code - >> https://github.com/kirill-grouchnikov/radiance/blob/sunshine/demos/theming-demo/src/main/java/org/pushingpixels/radiance/demo/theming/main/Hairlines.java >> (no dependency on anything from Radiance, just the core Swing / AWT stuff). >> >> Now, running this on a Windows 10 laptop with recommended / default 250% >> scale factor gets the correct value of 2.5 as scale. But the visuals switch >> between hairline and "smudged" as I horizontally resize the frame one pixel >> at a time and the component shifts horizontally - >> https://raw.githubusercontent.com/kirill-grouchnikov/radiance/sunshine/docs/images/hairlines.png >> (and the horizontal lines are also not hairline) >> >> How do I make this work in Java2D across all display scale factors so that >> I get consistent hairlines? I see the same behavior on Java 9 and Java 17 >> >> Thanks >> Kirill >> From kizune at openjdk.java.net Fri May 27 18:02:51 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 27 May 2022 18:02:51 GMT Subject: RFR: 8282526: Default icon is not painted properly [v4] In-Reply-To: References: Message-ID: > Detect the situation where we do need to perform interpolation during ImageIcon > painting and set a hint to the rendering to perform bicubic approximation so > image details are preserved during transition. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Use small icon pointer for icons less than 24 pixels wide - this way we get the 16x16 icon which is better for scaling purposes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7805/files - new: https://git.openjdk.java.net/jdk/pull/7805/files/a6aef9a9..b6e099b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7805&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7805&range=02-03 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7805.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7805/head:pull/7805 PR: https://git.openjdk.java.net/jdk/pull/7805 From kizune at openjdk.java.net Fri May 27 18:16:42 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 27 May 2022 18:16:42 GMT Subject: RFR: 8282526: Default icon is not painted properly [v4] In-Reply-To: References: Message-ID: <8vrDNTJTPocLihty5ZMoBaqGEX23B4gXxis8TtBvuZ8=.5700255b-33a0-4b17-bbb2-523f5a19e9c8@github.com> On Fri, 27 May 2022 18:02:51 GMT, Alexander Zuev wrote: >> Detect the situation where we do need to perform interpolation during ImageIcon >> painting and set a hint to the rendering to perform bicubic approximation so >> image details are preserved during transition. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Use small icon pointer for icons less than 24 pixels wide - this way we > get the 16x16 icon which is better for scaling purposes. I have fixed the 16x16 icon generation on Windows, but this will not help the generic problem that i demonstrated with the test case, on the magnification factors like 125% or 175% without the proposed fix for the ImageIcon the result looks trashy - jagged lines, missing details. I have done testing with the modified regression test case to see how my change affects performance. Notice that this is the worst case scenario, when all of the paintings trigger the fix (which is only triggered for MultiResolutionImage based icons and only when this MRI does not have the exact match for the requested resolution and scaling is required - this is like 0.01% of overall cases because for majority of image icons they are either single image based or MRI has the variant requested ready for display. And even in this worst case scenario on 1000 iterations test does not show any difference. On 10000 iterations the difference is measurable in tens of milliseconds between test runs. On 100000 iterati ons test execution with BICUBIC approximation is noticeable (like test run takes more than a second longer). We can limit the maximum size of icon we process by some reasonable number, like do not process icons bigger than 256 pixel wide or high so we do not cause any noticeable slowdown, but i still think this needs to be done - otherwise on these odd magnifications we look nothing alike the native applications (windows looks like using some sort of bicubic interpolation for their icons) and just plain bad. ------------- PR: https://git.openjdk.java.net/jdk/pull/7805 From kirill.grouchnikov at gmail.com Fri May 27 18:36:13 2022 From: kirill.grouchnikov at gmail.com (Kirill Grouchnikov) Date: Fri, 27 May 2022 14:36:13 -0400 Subject: Hairline strokes under fractional display metrics In-Reply-To: References: Message-ID: I also found https://github.com/apache/netbeans/blob/master/platform/o.n.swing.plaf/src/org/netbeans/swing/plaf/windows8/DPIUnscaledBorder.java through that OpenJDK thread that I was reading yesterday, which looks to be taking a similar approach. Probably in a world of 4x+ monitors, I would indeed want to go from 1-pixel to 2+ pixel "hairlines" as otherwise they would be almost invisible. As for the 0 meaning hairline, I was mostly thinking of SkPaint::setStrokeWidth in Skia. https://bugs.openjdk.java.net/browse/JDK-8090551 has been open for quite some time now on JDK. On Fri, May 27, 2022 at 2:00 PM Philip Race wrote: > Indeed .. something very close to that is what is being proposed in a > current PR here : > https://github.com/openjdk/jdk/pull/7449/files > > Just bear in mind some of the same constraints and that if printed on a > 1200dpi printer > with a scale of 16.67 .. your one pixel line might be too thin to be > seen at all. > > I suggest you should have an upper limit on the unscaling. > > I don't remember why the change a long time ago was backed out .. indeed I > am not sure I remember it will enough for it to be more than a figment > of my imagination > but "0" used to have a special meaning in some graphics systems - X11 > took it to > mean "draw a line the fastest way you can, I do not care about accuracy". > > -phil. > > On 5/26/22 2:47 PM, Kirill Grouchnikov wrote: > > Haven't heard anything here, but in the meanwhile I got great pointers > from > > Karl, the developer of JFormDesigner and FlatLaf over at > > > https://github.com/kirill-grouchnikov/radiance/issues/39#issuecomment-1137649208 > > and subsequent comments. > > > > The core of the idea is to force scale factor of 1.0 on the graphics > > context, compute new origin and bounding box similar to how it's done in > > the internals of Java2D, and then strokes with width of 1.0f will be > > treated as full pixels (if no VALUE_STROKE_PURE hint is set). > > > > On Tue, May 24, 2022 at 7:48 PM Kirill Grouchnikov < > > kirill.grouchnikov at gmail.com> wrote: > > > >> I'm trying to figure out what is the right way to draw paths such > >> rectangles or rounded rectangles, such that horizontal and vertical > parts > >> always fall on a full pixel and are displayed at hairline stroke width. > >> > >> A long time ago there was an option to specify stroke width of 0 for > that, > >> but then it was quickly reverted. > >> > >> My understanding is that I need to query scale x and scale y of the > >> device's config's transform, and use that to compute the stroke width. > >> Here's my code - > >> > https://github.com/kirill-grouchnikov/radiance/blob/sunshine/demos/theming-demo/src/main/java/org/pushingpixels/radiance/demo/theming/main/Hairlines.java > >> (no dependency on anything from Radiance, just the core Swing / AWT > stuff). > >> > >> Now, running this on a Windows 10 laptop with recommended / default 250% > >> scale factor gets the correct value of 2.5 as scale. But the visuals > switch > >> between hairline and "smudged" as I horizontally resize the frame one > pixel > >> at a time and the component shifts horizontally - > >> > https://raw.githubusercontent.com/kirill-grouchnikov/radiance/sunshine/docs/images/hairlines.png > >> (and the horizontal lines are also not hairline) > >> > >> How do I make this work in Java2D across all display scale factors so > that > >> I get consistent hairlines? I see the same behavior on Java 9 and Java > 17 > >> > >> Thanks > >> Kirill > >> > > From avu at openjdk.java.net Fri May 27 19:04:21 2022 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 27 May 2022 19:04:21 GMT Subject: RFR: 8287453: RenderPerfTest incorrectly measures performance Message-ID: Improved RenderPerfTest: - removed RenderPerfLCD.java (we have LCD tests in RenderPerfTest.java) - corrected and simplified test logic - added timeout on low performant rendering - used several markers to recover from missing frames - protected measurements from multiple paint invocations ------------- Commit messages: - 8287453: RenderPerfTest incorrectly measures performance Changes: https://git.openjdk.java.net/jdk/pull/8928/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8928&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287453 Stats: 478 lines in 4 files changed: 34 ins; 402 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/8928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8928/head:pull/8928 PR: https://git.openjdk.java.net/jdk/pull/8928 From prr at openjdk.java.net Fri May 27 20:34:43 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 27 May 2022 20:34:43 GMT Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails [v2] In-Reply-To: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com> References: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com> Message-ID: On Thu, 28 Apr 2022 13:34:31 GMT, Prasanta Sadhukhan wrote: >> Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 ` >> As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd >> there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail. >> >> Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations. >> >> Also removed the deprecated `System.runFinalization` > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test fix Can you confirm we still need the Frame ? I mean when does the used-to-be-leaky listener get installed ? If it is sufficient to add it to the panel and the panel doesn't need to be added to the frame then the test can be headless. But we need to be sure that doesn't skip what we want to test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8450 From aivanov at openjdk.java.net Fri May 27 20:48:30 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 27 May 2022 20:48:30 GMT Subject: RFR: 8286663: Resolve IDE warnings in WTrayIconPeer and SystemTray [v3] In-Reply-To: References: Message-ID: > **WTrayIconPeer**: removed duplicate call to `popupParent.dispose()` that might cause NPE (it looks `popupParent` cannot be `null`); organised imports. > > **SystemTray**: removed redundant initialisers; replaced sized array with empty array in `toArray` call; dropped `newValue != null` chained with `equals`. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Use method reference in setSystemTrayAccessor instead of anonymous class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8850/files - new: https://git.openjdk.java.net/jdk/pull/8850/files/a2f8c952..1f47fe4f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8850&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8850&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8850/head:pull/8850 PR: https://git.openjdk.java.net/jdk/pull/8850 From ysuenaga at openjdk.java.net Sat May 28 02:12:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 28 May 2022 02:12:43 GMT Subject: Integrated: 8286562: GCC 12 reports some compiler warnings In-Reply-To: References: Message-ID: On Wed, 11 May 2022 05:58:31 GMT, Yasumasa Suenaga wrote: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: This pull request has now been integrated. Changeset: 410a25d5 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464 Stats: 41 lines in 5 files changed: 26 ins; 1 del; 14 mod 8286562: GCC 12 reports some compiler warnings Reviewed-by: ihse, kbarrett, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From psadhukhan at openjdk.java.net Sat May 28 03:41:29 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 28 May 2022 03:41:29 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v6] In-Reply-To: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> Message-ID: > Malgun_Gothic(https://en.wikipedia.org/wiki/Malgun_Gothic) had replaced Gulim korean font so it needs to be updated to show korean fonts Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Added UTF-8 korean fallback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7643/files - new: https://git.openjdk.java.net/jdk/pull/7643/files/a6867d26..2a01a58b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7643&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7643.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7643/head:pull/7643 PR: https://git.openjdk.java.net/jdk/pull/7643 From psadhukhan at openjdk.java.net Sat May 28 03:41:30 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 28 May 2022 03:41:30 GMT Subject: RFR: 8190907: Windows 10 default Korean Font Malgun Gothic available not used by GUI elements even though available without Korean Language Pack [v5] In-Reply-To: References: <_cAab99k8SxU4y3G_FwRT3fg8t39fYQUDTdEwOZYZmc=.5d71beab-25a0-4c29-b194-d4680961b530@github.com> <0L6zr9ZBlYfBwXtHFBoHkqp4LMupdzyD9eoYtDTXG6w=.39f04a5a-9d85-4f07-846f-f797d8ffbf77@github.com> Message-ID: <8eDRalnD5D1fpl84PMLW4iTWmQEB9DU1FpXUJcIeTrI=.82c5ad03-94d1-40f8-bb16-e59dada5f30f@github.com> On Fri, 27 May 2022 17:51:45 GMT, Phil Race wrote: > Good to know. I still believe we should add sequence.allfonts.UTF-8.ko=alphabetic,korean,dingbats,symbol since UTF-8 is now the default encoding. Added UTF-8 korean fallback. I get the same above rendering with the same commandline as above.. ------------- PR: https://git.openjdk.java.net/jdk/pull/7643 From psadhukhan at openjdk.java.net Sat May 28 08:41:35 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 28 May 2022 08:41:35 GMT Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails [v3] In-Reply-To: References: Message-ID: > Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 ` > As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd > there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail. > > Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations. > > Also removed the deprecated `System.runFinalization` Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Made test headless ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8450/files - new: https://git.openjdk.java.net/jdk/pull/8450/files/8bf50cca..ae7a4a4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8450&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8450&range=01-02 Stats: 84 lines in 1 file changed: 16 ins; 57 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8450.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8450/head:pull/8450 PR: https://git.openjdk.java.net/jdk/pull/8450 From psadhukhan at openjdk.java.net Sat May 28 08:41:35 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Sat, 28 May 2022 08:41:35 GMT Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails [v2] In-Reply-To: References: <7f6imhO_fmNXVejmC3boQyV0uNjoHOJCiVzetcCOHpY=.b2d95eab-e3f7-45db-83ad-92e91e3a5585@github.com> Message-ID: On Fri, 27 May 2022 20:31:08 GMT, Phil Race wrote: > Can you confirm we still need the Frame ? I mean when does the used-to-be-leaky listener get installed ? If it is sufficient to add it to the panel and the panel doesn't need to be added to the frame then the test can be headless. But we need to be sure that doesn't skip what we want to test. No, we dont need the frame. The leaky listener gets installed when we call `new TitledBorder()` I have made the test headless which still fails without the fix and passes with TitledBorder fix and also pass in all CI headless platforms ------------- PR: https://git.openjdk.java.net/jdk/pull/8450 From duke at openjdk.java.net Sat May 28 09:36:46 2022 From: duke at openjdk.java.net (kristylee88) Date: Sat, 28 May 2022 09:36:46 GMT Subject: RFR: 8213531: Test javax/swing/border/TestTitledBorderLeak.java fails [v3] In-Reply-To: References: Message-ID: On Sat, 28 May 2022 08:41:35 GMT, Prasanta Sadhukhan wrote: >> Test was failing in linux citing `java.lang.RuntimeException: Expected Total TitledBorder to be freed : 10 Freed 9 ` >> As per the fix done in JDK-8204963 http://hg.openjdk.java.net/jdk/jdk/rev/cd7d2f9154fd >> there was no platform specific code done for the fix and logs in `TitledBorder.installPropertyChangeListeners` shows it was called 10 times for the test but `CleanerFactory.cleaner().register` action was only called 9 times in linux causing it to fail. >> >> Modified the test to not show the frame which cause the problem to go away and also it can still be used as 8204963 regression test as it still fails without the fix and pass with it. Modified test has passed in all platforms for several iterations. >> >> Also removed the deprecated `System.runFinalization` > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Made test headless Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8450 From bourges.laurent at gmail.com Sun May 29 07:31:36 2022 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sun, 29 May 2022 09:31:36 +0200 Subject: Any interest in JDK-8264999 (stroke miter edge case in Marlin) In-Reply-To: References: Message-ID: One more general comment on this bug: what is expected when lineTo() does not change last point after all other possible operations ? - lineTo, lineto (this bug) - quadTo, lineto - cubicTo, lineto - moveto, lineto: point (ok) - close, lineto(star: equiv to close, move start, lineto start: point start (ok ?) If any drawing operation in progress (lineto, quadto, curveto), then skip repeated end point is the specified behaviour. Laurent Le mer. 25 mai 2022, 08:57, Laurent Bourg?s a ?crit : > In Stroker, this lines seems causing the problem: > > https://github.com/openjdk/jdk/blob/a0cccb54791d954bf08da5aac9b9794e370617c8/src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java#L568 > > If delta is 0, then tangent is (1, 0) ! > Should be: > If drawOp was lineTo and delta is 0, return (skip). > > I wonder if there are other renderer suffering the same problem. > Phil, how could we generalize this kind of path operation filtering ? > > My 2 cents, > Laurent > > Le mer. 25 mai 2022, 08:15, Laurent Bourg?s a > ?crit : > >> Jeremy, >> >> Probably your fix could be plugged in marlin pathTo() : >> >> https://github.com/openjdk/jdk/blob/742644e291039e4f2f30cf80718669c06da5809c/src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java#L768 >> >> Or in Stroker lineTo... >> >> Laurent >> >> Le mar. 24 mai 2022, 22:55, Jeremy Wood a ?crit : >> >>> I may still move it in the Stroker classes. There are a few other things >>> I want to look at, too. This is a very rough draft I put together in >>> under an hour; I just wanted to make sure it was worth pursuing before I >>> put more time into it. >>> >>> - Jeremy >>> >>> >>> ------ Original Message ------ >>> From "Laurent Bourg?s" >>> To "Jeremy Wood" >>> Cc client-libs-dev at openjdk.java.net >>> Date 5/24/2022 4:35:21 PM >>> Subject Re: Any interest in JDK-8264999 (stroke miter edge case in >>> Marlin) >>> >>> >Thanks Jereremy for the notification I was not aware of this one. >>> > >>> >I wonder if the problem should be fixed inside the marlin renderer >>> >Stroker that should ignore such useless lineTo... >>> > >>> >I will read your code and try to figure out potential causes in stroker >>> >and give you my feedback. >>> > >>> >Laurent >>> > >>> >Le mar. 24 mai 2022, 19:52, Jeremy Wood a ?crit >>> >: >>> >>This is a P3 ticket currently assigned to Philip Race: >>> >>https://bugs.openjdk.java.net/browse/JDK-8264999 >>> >> >>> >>If I put together a PR: Is anyone available/willing to help review it? >>> >> >>> >>I made a rough draft >>> >>< >>> https://github.com/openjdk/jdk/compare/master...mickleness:JDK-8264999?expand=1 >>> > >>> >>of a potential solution last night. I can continue to work on this, or >>> >>I >>> >>can move on if the interest isn?t there. >>> >> >>> >>(No urgency at all.) >>> >> >>> >>Regards, >>> >> - Jeremy >>> >> >>> >> From duke at openjdk.java.net Sun May 29 23:45:30 2022 From: duke at openjdk.java.net (Jeremy) Date: Sun, 29 May 2022 23:45:30 GMT Subject: RFR: 8286093: java/awt/geom/Path2D/UnitTest.java failed with "RuntimeException: 2D bounds too small" [v4] In-Reply-To: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: > This resolves an occasional unit test failure in Path2D.UnitTest. > > The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. > > This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. > > This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. Jeremy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'master' into JDK-8176501 - Merge pull request #3 from openjdk/master Merge from openjdk/jdk - Merge remote-tracking branch 'origin/master' into JDK-8176501 - Merge pull request #2 from openjdk/master Merge openjdk/jdk - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Renaming "moveX"/"moveY" to "startX"/"startY" at Laurent's suggestion. - Merge branch 'master' into JDK-8176501 # Conflicts: # src/java.desktop/share/classes/java/awt/geom/Path2D.java # test/jdk/java/awt/geom/Path2D/UnitTest.java - Merge pull request #1 from openjdk/master Merge openjdk/jdk into mickleness/jdk - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Restoring original behavior. The "10_000_000 : 10_000_000" line should never have been committed. - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box This resolves occasional unit test failures in java.awt.geom.Path2D.UnitTest. (For ex, see seeds 4603421469924484958L, 4596019360892069260L, 4604586530476373958L, 4603766396818608126L) The problem appears to be that the UnitTest class randomly creates PathIterator segments in a way that can place lines/quads/cubics immediately after a SEG_CLOSE. That is: after a SEG_CLOSE there was no SEG_MOVETO as new segments followed. The previous Path2D#getBounds2D(PathIterator) method assumed each subpath *always* started with a SEG_MOVETO. (I don't know if this is formally stated in a specification anywhere or not?) The unit test failures show this is a bad assumption. With this change: when a SEG_CLOSE is encountered: we reset the cursor to the last (moveX, moveY) point. This appears to resolve the unit test failures, which suggests this is consistent with what existing awt.geom classes also do. - 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box Turn on "verbose" mode before running any tests - ... and 21 more: https://git.openjdk.java.net/jdk/compare/3d2d0395...c3f26e9d ------------- Changes: https://git.openjdk.java.net/jdk/pull/8828/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8828&range=03 Stats: 68 lines in 2 files changed: 37 ins; 5 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/8828.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8828/head:pull/8828 PR: https://git.openjdk.java.net/jdk/pull/8828 From duke at openjdk.java.net Mon May 30 01:24:22 2022 From: duke at openjdk.java.net (Jeremy) Date: Mon, 30 May 2022 01:24:22 GMT Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines Message-ID: Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied. The new unit test tests the original steps plus several variations. I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale. ------------- Commit messages: - JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines - Merge pull request #3 from openjdk/master - Merge pull request #2 from openjdk/master - Merge pull request #1 from openjdk/master Changes: https://git.openjdk.java.net/jdk/pull/8943/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8943&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264999 Stats: 218 lines in 2 files changed: 217 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8943.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8943/head:pull/8943 PR: https://git.openjdk.java.net/jdk/pull/8943 From duke at openjdk.java.net Mon May 30 01:24:22 2022 From: duke at openjdk.java.net (Jeremy) Date: Mon, 30 May 2022 01:24:22 GMT Subject: RFR: 8264999: GeneralPath.lineTo() to itself produces jagged lines In-Reply-To: References: Message-ID: On Mon, 30 May 2022 01:15:01 GMT, Jeremy wrote: > Previously when you drew a line that moved exactly (+0, +0) with a miter stroke the Stroker class acted like a horizontal miter was appropriate. Now we abort instead, so no miter is applied. > > The new unit test tests the original steps plus several variations. > > I'm a little nervous about this change because it looks like someone previously considered this exact condition and implemented a different behavior. I don't think I understand the original rationale. @bourgesl as the (or one of the?) resident Marlin experts: what do you think of this approach and the accompanying unit test? ------------- PR: https://git.openjdk.java.net/jdk/pull/8943 From duke at openjdk.java.net Mon May 30 05:55:38 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Mon, 30 May 2022 05:55:38 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v4] In-Reply-To: References: Message-ID: > Hello, > Please review this fix for JDK-8282863. > > The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. > > The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: > > 1. `java.awt.Frame` is created and set as full-screen. > 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. > 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. > 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: > 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. > 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. > 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. > 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. > 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. > 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. > 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. > > Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. > > I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java Comments clean-up Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7835/files - new: https://git.openjdk.java.net/jdk/pull/7835/files/008e9c19..a5d4a68f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7835&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7835&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7835.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7835/head:pull/7835 PR: https://git.openjdk.java.net/jdk/pull/7835 From duke at openjdk.java.net Mon May 30 06:04:03 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 30 May 2022 06:04:03 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: References: Message-ID: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> > _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE. Tejesh R has updated the pull request incrementally with one additional commit since the last revision: Removal of White space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8830/files - new: https://git.openjdk.java.net/jdk/pull/8830/files/df184f0f..f7b44322 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8830&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8830.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8830/head:pull/8830 PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Mon May 30 06:08:50 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Mon, 30 May 2022 06:08:50 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v4] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 05:55:38 GMT, Dmitry Kulikov wrote: >> Hello, >> Please review this fix for JDK-8282863. >> >> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. >> >> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: >> >> 1. `java.awt.Frame` is created and set as full-screen. >> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. >> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. >> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: >> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. >> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. >> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. >> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. >> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. >> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. >> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. >> >> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. >> >> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. > > Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java > > Comments clean-up > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Thank you for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From duke at openjdk.java.net Mon May 30 06:10:55 2022 From: duke at openjdk.java.net (Jeremy) Date: Mon, 30 May 2022 06:10:55 GMT Subject: Integrated: 8286093: java/awt/geom/Path2D/UnitTest.java failed with "RuntimeException: 2D bounds too small" In-Reply-To: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> References: <68tfxHsZFP9IWTZce5Bp6fYnyCO1-PR58HB6DPadBkU=.95fa5e53-9de2-44f8-8719-1c7e95d5b891@github.com> Message-ID: On Sun, 22 May 2022 09:08:03 GMT, Jeremy wrote: > This resolves an occasional unit test failure in Path2D.UnitTest. > > The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that didn't follow this expectation. > > This commit updates #getBounds2D(PathIterator) so it will move the cursor back to the (moveX, moveY) point for the sake of calculating future segments. This appears to resolve the unit test failures. > > This commit also modifies the unit test so it logs random seeds. This may help developers isolate/reproduce specific failures with more certainty. This pull request has now been integrated. Changeset: 5848a60c Author: jeremy Committer: Laurent Bourg?s URL: https://git.openjdk.java.net/jdk/commit/5848a60c01747728cbdde1e9d8a244079fd88c14 Stats: 68 lines in 2 files changed: 37 ins; 5 del; 26 mod 8286093: java/awt/geom/Path2D/UnitTest.java failed with "RuntimeException: 2D bounds too small" Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8828 From psadhukhan at openjdk.java.net Mon May 30 07:18:31 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 30 May 2022 07:18:31 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 In-Reply-To: References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Message-ID: On Wed, 25 May 2022 02:55:53 GMT, Prasanta Sadhukhan wrote: >> test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java line 64: >> >>> 62: >>> 63: public static void main(String[] args) throws Exception { >>> 64: if (!System.getProperty("os.name").toLowerCase().contains("os x")) { >> >> @prsadhuk Since the tag **@requires (os.family == "mac")** is added, is this check necessary or is it added for standalone testing purpose? > > Yes for standalone testing for which I also removed dependancy on jtreg Platform class Any reviewers please? ------------- PR: https://git.openjdk.java.net/jdk/pull/8864 From duke at openjdk.java.net Mon May 30 12:54:41 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 30 May 2022 12:54:41 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 In-Reply-To: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Message-ID: <6_Cxs_VvQ7iimLCWSItmThQkItcgcE67TD_A8mO8ico=.ec34463b-b857-40e7-9f40-7a16143b8fec@github.com> On Tue, 24 May 2022 08:28:57 GMT, Prasanta Sadhukhan wrote: > Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 > > x 13 y 0 refRGB ffeeeeee customRGB ffefeeee > x 0 y 0 refRGB ffefefef customRGB ffefeeef > > > so added color tolerance check. > Also, added other stability fixes.. > Several iteration of test passed in intended M1 and x64 system. _public void doStep() { try { Thread.sleep(timeout); } catch (InterruptedException e) { }_ Is it better to handle it by propagating it/print the stack trace/any other way, or leave it unhandled....? ------------- PR: https://git.openjdk.java.net/jdk/pull/8864 From aivanov at openjdk.java.net Mon May 30 13:16:43 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 30 May 2022 13:16:43 GMT Subject: RFR: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen [v4] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 05:55:38 GMT, Dmitry Kulikov wrote: >> Hello, >> Please review this fix for JDK-8282863. >> >> The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. >> >> The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: >> >> 1. `java.awt.Frame` is created and set as full-screen. >> 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. >> 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. >> 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: >> 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. >> 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. >> 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. >> 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. >> 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. >> 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. >> 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. >> >> Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. >> >> I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. > > Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java > > Comments clean-up > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From psadhukhan at openjdk.java.net Mon May 30 14:18:43 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 30 May 2022 14:18:43 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 In-Reply-To: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Message-ID: On Tue, 24 May 2022 08:28:57 GMT, Prasanta Sadhukhan wrote: > Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 > > x 13 y 0 refRGB ffeeeeee customRGB ffefeeee > x 0 y 0 refRGB ffefefef customRGB ffefeeef > > > so added color tolerance check. > Also, added other stability fixes.. > Several iteration of test passed in intended M1 and x64 system. Information is not needed for sleep interuption, it's not going to affect the test much ------------- PR: https://git.openjdk.java.net/jdk/pull/8864 From duke at openjdk.java.net Mon May 30 14:23:44 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 30 May 2022 14:23:44 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 In-Reply-To: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Message-ID: On Tue, 24 May 2022 08:28:57 GMT, Prasanta Sadhukhan wrote: > Test was failing intermiitently in iMac M1 system owing to minimalistic color difference of 1 > > x 13 y 0 refRGB ffeeeeee customRGB ffefeeee > x 0 y 0 refRGB ffefefef customRGB ffefeeef > > > so added color tolerance check. > Also, added other stability fixes.. > Several iteration of test passed in intended M1 and x64 system. Marked as reviewed by TejeshR13 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/8864 From duke at openjdk.java.net Mon May 30 14:23:46 2022 From: duke at openjdk.java.net (Tejesh R) Date: Mon, 30 May 2022 14:23:46 GMT Subject: RFR: 8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64 In-Reply-To: References: <8xjZ4XtQGlJMb8WL_9BnlcTd-r8sOLSlPShLoExEfVM=.72d1b3ae-697b-4695-b29f-f258805d18ef@github.com> Message-ID: On Mon, 30 May 2022 14:15:17 GMT, Prasanta Sadhukhan wrote: > Information is not needed for sleep interuption, it's not going to affect the test much Ok. The PR is fine, I have tested in mac. ------------- PR: https://git.openjdk.java.net/jdk/pull/8864 From aivanov at openjdk.java.net Mon May 30 15:42:52 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 30 May 2022 15:42:52 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v18] In-Reply-To: <8q4gy23hY9uJRNjZCAGRMWiHi92A7IaotUnUxtLSLY4=.4c7ac68b-d047-4804-8d27-739af962fb4f@github.com> References: <8q4gy23hY9uJRNjZCAGRMWiHi92A7IaotUnUxtLSLY4=.4c7ac68b-d047-4804-8d27-739af962fb4f@github.com> Message-ID: On Wed, 25 May 2022 20:32:54 GMT, Phil Race wrote: > so -showFrame is just for a person to use "standalone" to see the results, never used by jtreg Yes, it is for stand-alone during debugging, not for jtreg. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Mon May 30 15:51:16 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 30 May 2022 15:51:16 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: <9GznmzfE1DOcryOCsvUJ7LDFlBxGoVRxgp4lYdqEXhg=.02c64a2b-f209-4dbf-b1ad-68aee3f6a943@github.com> On Wed, 25 May 2022 21:37:07 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > changed test to headless Changes requested by aivanov (Reviewer). test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 56: > 54: public static JFrame frame; > 55: public static JPanel contentPanel; > 56: public static JPanel childPanel; None of these fields ? frame, contentPanel, childPanel ? are used outside of `createGUI` method. I propose to declare them as local variables where they're used. At this time, `frame` is used outside of `createGUI` but it shouldn't. test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 74: > 72: if (frame != null) { > 73: SwingUtilities.invokeAndWait(() -> frame.dispose()); > 74: } It doesn't make sense to dispose of the frame automatically: it's supposed to stay visible if `-show` is passed so that the user could interact with it. test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 201: > 199: } > 200: > 201: contentPanel.setSize(childSize.width, childSize.height * 4); `contentPanel.setSize` is to be called after the for-loop when all child panels are added. test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java line 228: > 226: frame.getContentPane().add(contentPanel, BorderLayout.CENTER); > 227: frame.pack(); > 228: frame.setLocationRelativeTo(null);frame.setVisible(true); Please move `setVisible` to its own line. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Mon May 30 15:54:10 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 30 May 2022 15:54:10 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 21:37:07 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > changed test to headless Are we going to address rotation under this issue or under a new one? ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Mon May 30 15:58:51 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 30 May 2022 15:58:51 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 21:37:07 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > changed test to headless `test/jdk/java/awt/EtchedBorder/ScaledEtchedBorderTest.java` should be removed, it's replaced with `test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From aivanov at openjdk.java.net Mon May 30 20:32:53 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 30 May 2022 20:32:53 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> References: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> Message-ID: <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> On Mon, 30 May 2022 06:04:03 GMT, Tejesh R wrote: >> _Header_ object not initialized/set when paint() method of `WindowTableHeaderUI` class is executed. The paint() event is executed through explicit call of `JTable.updateUI()` in the regression test. In order to set the _header_ to the _called_ JTable, it is set in the `getTableCellRendererComponent()` method, which in turn makes the _header_ object available during paint event without causing NPE. > > Tejesh R has updated the pull request incrementally with one additional commit since the last revision: > > Removal of White space Can't the test be automated? Can you paint the table to a BufferredImage and catch the NPE? test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 2: > 1: /* > 2: * Copyright (c) 2002, 2022, Oracle and/or its affiliates. All rights reserved. Why is it 2002, 2022 if it's a new test? You're taking the code from [JDK-6429812](https://bugs.openjdk.java.net/browse/JDK-6429812), it was created in 2006, so the first year can't be earlier than 2006. test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 50: > 48: = """ > 49: INSTRUCTIONS: > 50: 1. This is a Windows specific test. If you are not on Windows, press Pass. Since it is a Windows-specific test, you have to add * @requires (os.family == "windows") to the list of jtreg tags? ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Tue May 31 04:01:42 2022 From: duke at openjdk.java.net (Tejesh R) Date: Tue, 31 May 2022 04:01:42 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> References: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> Message-ID: On Mon, 30 May 2022 16:01:39 GMT, Alexey Ivanov wrote: >> Tejesh R has updated the pull request incrementally with one additional commit since the last revision: >> >> Removal of White space > > test/jdk/javax/swing/JTableHeader/TableRendererTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2002, 2022, Oracle and/or its affiliates. All rights reserved. > > Why is it 2002, 2022 if it's a new test? > > You're taking the code from [JDK-6429812](https://bugs.openjdk.java.net/browse/JDK-6429812), it was created in 2006, so the first year can't be earlier than 2006. > Can't the test be automated? > > Can you paint the table to a BufferredImage and catch the NPE? > > Alternatively, if the above can't be done, you can use [Thread.setUncaughtExceptionHandler](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Thread.html#setUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)) to set [UncaughtExceptionHandler](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Thread.UncaughtExceptionHandler.html) for the EDT and catch NPE. > > If NPE is thrown, the test fails. Yeah, wanted to change to automatic, but wasn't sure about whether its ok for NPE check or not. Actually if the current test executes then its a pass right......? Painting it to bufferedImage and then catching NPE is required........? ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Tue May 31 08:22:20 2022 From: duke at openjdk.java.net (Tejesh R) Date: Tue, 31 May 2022 08:22:20 GMT Subject: RFR: 8233477: : [Win LAF]The tooltip doesn't display correctly in Win LAF Message-ID: The tooltip displays accelerated string along with the toooltip string. The feature is implemented and applicable for Metal Look and Feel only. Hence the test is updated for Metal Look and Feel by hard wiring it in the code. Updated the test from manual to automatic. ------------- Commit messages: - Error print modifications - Modified Accelerator String check - Updated based on review comments - Updated based on review comments - Updated based on review comments - Updated based on review comments - Updated based on review comments - Create new regression test to check Accelerated Strings of ToolTip in Metal Look and Feel - Merge remote-tracking branch 'upstream/master' - Merge remote-tracking branch 'upstream/master' - ... and 7 more: https://git.openjdk.java.net/jdk/compare/e1f140d2...79f2d58f Changes: https://git.openjdk.java.net/jdk/pull/8952/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8952&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233477 Stats: 183 lines in 1 file changed: 183 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8952.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8952/head:pull/8952 PR: https://git.openjdk.java.net/jdk/pull/8952 From psadhukhan at openjdk.java.net Tue May 31 08:38:47 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Tue, 31 May 2022 08:38:47 GMT Subject: RFR: 8286159: Memory leak in getAllConfigs of awt_GraphicsEnv.c:585 In-Reply-To: <8kfUsrwVx96D8gvusJtwYwwFLW1WieMXeWlB7qMZpK0=.05cca9e8-9169-46e3-baef-aa46b02d5156@github.com> References: <8kfUsrwVx96D8gvusJtwYwwFLW1WieMXeWlB7qMZpK0=.05cca9e8-9169-46e3-baef-aa46b02d5156@github.com> Message-ID: On Mon, 23 May 2022 20:35:33 GMT, Phil Race wrote: > If we don't store the memory allocated for graphicsConfigs because we failed/bail, we need to free it. Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8857 From aivanov at openjdk.java.net Tue May 31 09:33:49 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 31 May 2022 09:33:49 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: References: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> Message-ID: On Tue, 31 May 2022 03:58:04 GMT, Tejesh R wrote: > Yeah, wanted to change to automatic, but wasn't sure about whether its ok for NPE check or not. What can be wrong with it? It's just a regular test. If you can automate the test, you should. > Actually if the current test executes then its a pass right......? I don't understand your question, sorry. What surprises me is that the test fails automatically without the fix. But I can't see how the NPE is re-thrown on the main thread. I thought the NPE would be just printed in the jtreg log file and the tester wouldn't even see it. So your test is already automated to some extent. What we want is to make it pass automatically if NPE isn't thrown. > Painting it to bufferedImage and then catching NPE is required........? No, it's not, however, I think it's a more effective way than showing UI. The exception occurs when `paint` is called. Painting to `BufferedImage` gives you control when and how `paint` is called: you do it _explicitly_. So you wrap the call to `paint` in a try-catch block, if the exception is thrown you re-throw it on main thread to fail the test; if the exception isn't thrown, the test completed successfully. Perhaps, try-catch block isn't necessary, just let the exception propagate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Tue May 31 09:43:05 2022 From: duke at openjdk.java.net (Tejesh R) Date: Tue, 31 May 2022 09:43:05 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: References: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> Message-ID: On Tue, 31 May 2022 09:29:59 GMT, Alexey Ivanov wrote: >>> Can't the test be automated? >>> >>> Can you paint the table to a BufferredImage and catch the NPE? >>> >>> Alternatively, if the above can't be done, you can use [Thread.setUncaughtExceptionHandler](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Thread.html#setUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)) to set [UncaughtExceptionHandler](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Thread.UncaughtExceptionHandler.html) for the EDT and catch NPE. >>> >>> If NPE is thrown, the test fails. >> >> Yeah, wanted to change to automatic, but wasn't sure about whether its ok for NPE check or not. Actually if the current test executes then its a pass right......? Painting it to bufferedImage and then catching NPE is required........? > >> Yeah, wanted to change to automatic, but wasn't sure about whether its ok for NPE check or not. > > What can be wrong with it? It's just a regular test. If you can automate the test, you should. > >> Actually if the current test executes then its a pass right......? > > I don't understand your question, sorry. What surprises me is that the test fails automatically without the fix. But I can't see how the NPE is re-thrown on the main thread. > > I thought the NPE would be just printed in the jtreg log file and the tester wouldn't even see it. > > So your test is already automated to some extent. What we want is to make it pass automatically if NPE isn't thrown. > >> Painting it to bufferedImage and then catching NPE is required........? > > No, it's not, however, I think it's a more effective way than showing UI. The exception occurs when `paint` is called. Painting to `BufferedImage` gives you control when and how `paint` is called: you do it _explicitly_. So you wrap the call to `paint` in a try-catch block, if the exception is thrown you re-throw it on main thread to fail the test; if the exception isn't thrown, the test completed successfully. Perhaps, try-catch block isn't necessary, just let the exception propagate. > _Actually if the current test executes then its a pass right......?_ This means, if there is no NPE raised then its a pass case right.......? Yeah to some extent it is automatic, I actually didn't get how to handle the caught NPE, so just left it so that the Test case will be failed by NPE. ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Tue May 31 09:43:06 2022 From: duke at openjdk.java.net (Tejesh R) Date: Tue, 31 May 2022 09:43:06 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: References: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> Message-ID: On Tue, 31 May 2022 09:37:57 GMT, Tejesh R wrote: >>> Yeah, wanted to change to automatic, but wasn't sure about whether its ok for NPE check or not. >> >> What can be wrong with it? It's just a regular test. If you can automate the test, you should. >> >>> Actually if the current test executes then its a pass right......? >> >> I don't understand your question, sorry. What surprises me is that the test fails automatically without the fix. But I can't see how the NPE is re-thrown on the main thread. >> >> I thought the NPE would be just printed in the jtreg log file and the tester wouldn't even see it. >> >> So your test is already automated to some extent. What we want is to make it pass automatically if NPE isn't thrown. >> >>> Painting it to bufferedImage and then catching NPE is required........? >> >> No, it's not, however, I think it's a more effective way than showing UI. The exception occurs when `paint` is called. Painting to `BufferedImage` gives you control when and how `paint` is called: you do it _explicitly_. So you wrap the call to `paint` in a try-catch block, if the exception is thrown you re-throw it on main thread to fail the test; if the exception isn't thrown, the test completed successfully. Perhaps, try-catch block isn't necessary, just let the exception propagate. > >> _Actually if the current test executes then its a pass right......?_ This means, if there is no NPE raised then its a pass case right.......? Yeah to some extent it is automatic, I actually didn't get how to handle the caught NPE, so just left it so that the Test case will be failed by NPE. Ok, then will try with the _bufferedImage paint_ logic, If I'm able to get the exception without it been handled by internal code then it'll be really helpful to make it automatic. ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From aivanov at openjdk.java.net Tue May 31 10:00:42 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 31 May 2022 10:00:42 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: References: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> Message-ID: On Tue, 31 May 2022 09:40:17 GMT, Tejesh R wrote: >>> _Actually if the current test executes then its a pass right......?_ This means, if there is no NPE raised then its a pass case right.......? Yeah to some extent it is automatic, I actually didn't get how to handle the caught NPE, so just left it so that the Test case will be failed by NPE. > > Ok, then will try with the _bufferedImage paint_ logic, If I'm able to get the exception without it been handled by internal code then it'll be really helpful to make it automatic. > > _Actually if the current test executes then its a pass right......?_ > This means, if there is no NPE raised then its a pass case right.......? Yes, no NPE means the test passes successfully. If NPE is thrown, the test fails. > Yeah to some extent it is automatic, I actually didn't get how to handle the caught NPE, so just left it so that the Test case will be failed by NPE. In the majority of cases, you don't want to catch exceptions in tests. No exceptions are usually expected. An exception thrown from main makes the test fail. Yet I can't see how it gets thrown from main in this particular case. It's not important, however. ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From duke at openjdk.java.net Tue May 31 10:05:41 2022 From: duke at openjdk.java.net (Tejesh R) Date: Tue, 31 May 2022 10:05:41 GMT Subject: RFR: 6429812: NPE after calling JTable.updateUI() when using a header renderer + XP L&F [v3] In-Reply-To: References: <4zGALz_ZZL-VDQAvm4U0cqGs6CpnaiySwb9eC5hU4kA=.88e16390-dc80-445c-a07e-0781cfdf2f48@github.com> <611P-1O2qRNO1h_6dE1X9g1PR1DDaJD5ayl_UDhNjCM=.4df77dc7-6d78-44fb-b461-df4855e41b55@github.com> Message-ID: On Tue, 31 May 2022 09:57:36 GMT, Alexey Ivanov wrote: >> Ok, then will try with the _bufferedImage paint_ logic, If I'm able to get the exception without it been handled by internal code then it'll be really helpful to make it automatic. > >> > _Actually if the current test executes then its a pass right......?_ >> This means, if there is no NPE raised then its a pass case right.......? > > Yes, no NPE means the test passes successfully. If NPE is thrown, the test fails. > >> Yeah to some extent it is automatic, I actually didn't get how to handle the caught NPE, so just left it so that the Test case will be failed by NPE. > > In the majority of cases, you don't want to catch exceptions in tests. No exceptions are usually expected. An exception thrown from main makes the test fail. > > Yet I can't see how it gets thrown from main in this particular case. It's not important, however. Its not thrown from main I guess, its from internal code when JTable.update is called....... As I can see, painting the table to `BufferedImage` might not raise an exception in this case...... So I think its better to handle it by not handling or re-catching the NPE. I'll just remove the passFailFrame and the test case would be fine with that I guess......? ------------- PR: https://git.openjdk.java.net/jdk/pull/8830 From aghaisas at openjdk.java.net Tue May 31 10:10:33 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 31 May 2022 10:10:33 GMT Subject: RFR: 8287453: RenderPerfTest incorrectly measures performance In-Reply-To: References: Message-ID: On Fri, 27 May 2022 18:58:12 GMT, Alexey Ushakov wrote: > Improved RenderPerfTest: > - removed RenderPerfLCD.java (we have LCD tests in RenderPerfTest.java) > - corrected and simplified test logic > - added timeout on low performant rendering > - used several markers to recover from missing frames > - protected measurements from multiple paint invocations Is it only a test stabilization fix? or were you able to uncover any performance issue (either with OpenGL or with Metal pipeline) with this change? Can you please provide before/after numbers? ------------- PR: https://git.openjdk.java.net/jdk/pull/8928 From duke at openjdk.java.net Tue May 31 10:18:43 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Tue, 31 May 2022 10:18:43 GMT Subject: Integrated: 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 07:39:21 GMT, Dmitry Kulikov wrote: > Hello, > Please review this fix for JDK-8282863. > > The failing `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test basically checks that full-screen window remains full-screen when a display mode change occurs. It has been introduced in JDK-8211999, which also contains numerous fixes for HiDPI displays. In particular, JDK-8211999 changed the code of `Win32GraphicsDevice.setDisplayMode()` so that it uses screen dimensions in user space instead of device space, which is correct. However, if the display mode change incurs display scaling change, as it has been observed on Windows 10 laptop with HiDPI screen, the method used for obtaining screen bounds in user space returns incorrect values under certain conditions. > > The issue is reproducible on Windows 10, when resolution of the primary screen is higher than 1024x768 with scaling greater than 100%. Resolution and scaling of secondary screen(s) is irrelevant. I used a laptop with 2160x1350 display resolution and scaling set to 150%. When the `java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java` test is run with these initial conditions, roughly the following happens: > > 1. `java.awt.Frame` is created and set as full-screen. > 2. `Win32GraphicsDevice.setDisplayMode()` is called to change screen resolution from 2160x1350 to 1024x768. > 3. `Win32GraphicsDevice.configDisplayMode()` call immediately changes the display resolution to 1024x768, which also incurs the immediate display scaling change from 150% to 100%. > 4. Inside the `Win32GraphicsDevice.setDisplayMode()` screen bounds in user space are obtained via `Win32GraphicsConfig.getBounds()`: > 5. In the native code of `Win32GraphicsConfig.getBounds()` new screen bounds in device space (1024x768) are correctly obtained via `MonitorBounds()`. > 6. Then screen bounds are converted to user space by applying **scaling factors, which are not yet updated and correspond to previous display mode**. In our case, 1024x768 is scaled down by 150% and becomes 683x512. > 7. Back in `Win32GraphicsDevice.setDisplayMode()` full-screen window bounds are set to incorrectly scaled 683x512 instead of 1024x768. > 8. After returning from `Win32GraphicsDevice.setDisplayMode()` the test waits 4 seconds. > 9. `WM_DISPLAYCHANGE` message is received and processed, followed by `WM_DPICHANGED`, which updates the scaling factors used by `Win32GraphicsConfig.getBounds()` to the correct value of 100%. > 10. After 4 seconds test wakes up and obtains screen bounds in user space by calling `Win32GraphicsConfig.getBounds()`, which now correctly returns 1024x768. > 11. Test compares full-screen window bounds with screen bounds, and fails with `java.lang.RuntimeException: width is wrong` as 683 is not equal to 1024 ? 30 pixels. > > Proposed fix adds a `Win32GraphicsDevice.initScaleFactors()` call to `Win32GraphicsDevice.setDisplayMode()` code, between calling `Win32GraphicsDevice.configDisplayMode()` and `Win32GraphicsConfig.getBounds()`. This updates the scaling factors without waiting for `WM_DISPLAYCHANGE` or `WM_DPICHANGED`, `Win32GraphicsConfig.getBounds()` returns correctly scaled screen bounds in user space, and full-screen window remains correctly sized after display mode change. > > I've run tests from `jdk_awt` group on Windows 10 using a laptop with the same settings that caused the issue (primary screen with 2160x1350 resolution and 150% scaling), and applying the fix did not introduce any new test failures. This pull request has now been integrated. Changeset: c6e04164 Author: Dmitry Kulikov Committer: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/c6e041649514b964f5baaa88880c4d146275db8d Stats: 29 lines in 2 files changed: 21 ins; 4 del; 4 mod 8282863: java/awt/FullScreen/FullscreenWindowProps/FullscreenWindowProps.java fails on Windows 10 with HiDPI screen Reviewed-by: serb, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/7835 From aivanov at openjdk.java.net Tue May 31 11:34:40 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 31 May 2022 11:34:40 GMT Subject: RFR: 8286620: Create regression test for verifying setMargin() of JRadioButton [v3] In-Reply-To: <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com> References: <1-qMJRwjJVXF7BSrl5NCpoR9KMRBirtjJY--Kr6JueU=.e4a087a3-a7bb-4a93-a6ad-4a26954de78e@github.com> Message-ID: On Fri, 27 May 2022 17:21:29 GMT, Tejesh R wrote: >> Added test for checking setMargin() of JRadioButton. > > Tejesh R has updated the pull request incrementally with two additional commits since the last revision: > > - Updated based on review comments > - Added headful key I wonder why the test is Windows-specific if it allows changing Look and Feels. The only Look and Feel which ignores the background is Nimbus, other L&Fs on Windows at least paint the yellow and green background. As such, the test can be run on other platforms. Was the original bug in Windows Look and Feel? If so, you may want to make it the default L&F. The instructions don't mention anything about other Look and Feels. Does the tester have to verify each presented L&F? test/jdk/javax/swing/JRadioButton/bug4380543.java line 65: > 63: static PassFailJFrame passFailJFrame; > 64: > 65: public static void main(String args[]) throws Exception { Suggestion: public static void main(String[] args) throws Exception { Avoid C-style array declarations. test/jdk/javax/swing/JRadioButton/bug4380543.java line 85: > 83: > 84: class testFrame extends JFrame implements ActionListener { > 85: JPanel buttonsPanel; `buttonsPanel` can be local variable, it's not used outside of `initComponents`. test/jdk/javax/swing/JRadioButton/bug4380543.java line 87: > 85: JPanel buttonsPanel; > 86: > 87: Map lookAndFeelMaps = new HashMap(); I think it should be `lookAndFeelMap`, in singular, it's one map. You can use diamond operator, that is drop type parameters on the right side. IDE usually suggests this. Consider making the map final. test/jdk/javax/swing/JRadioButton/bug4380543.java line 94: > 92: > 93: public void initMap() > 94: { The brace should be on the same line. test/jdk/javax/swing/JRadioButton/bug4380543.java line 106: > 104: > 105: lookAndFeelMaps.put(sMapKey, sLnF); > 106: } Suggestion: for (UIManager.LookAndFeelInfo look : lookAndFeel) { lookAndFeelMaps.put(look.getName(), look.getClassName()); } I guess I mentioned it earlier. I think this way is cleaner and more user-friendly: the user will see the name of the Look and Feel rather than part of its class name. The local variables `sLnF` and `sMapKey` declared above the look become unnecessary in this case. If you use `LinkedHashMap`, the order of the L&Fs will be preserved the map will be iterated for creating the buttons. test/jdk/javax/swing/JRadioButton/bug4380543.java line 109: > 107: } > 108: > 109: public void initComponents() throws InterruptedException { The `InterruptedException` is not thrown in the method, so the throws clause should be removed. test/jdk/javax/swing/JRadioButton/bug4380543.java line 128: > 126: getContentPane().add(buttonsPanel); > 127: > 128: for (Map.Entry mapElement : lookAndFeelMaps.entrySet()) { Suggestion: for (Map.Entry mapElement : lookAndFeelMaps.entrySet()) { Use parametrized `Map.Entry`. test/jdk/javax/swing/JRadioButton/bug4380543.java line 157: > 155: String val = lookAndFeelMaps.get(key); > 156: > 157: setLookAndFeel(val); Suggestion: setLookAndFeel(lookAndFeelMaps.get(e.getActionCommand())); It doesn't make the code harder to read. If you prefer local variables, give them more meaningful names: `val` should rather be `lafClass` and `key` is `lafName` ? that's what's stored in the map. test/jdk/javax/swing/JRadioButton/bug4380543.java line 160: > 158: SwingUtilities.updateComponentTreeUI(this); > 159: } > 160: } Usually, there should be a new line character in the end of the file. ------------- Changes requested by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8721 From avu at openjdk.java.net Tue May 31 15:32:35 2022 From: avu at openjdk.java.net (Alexey Ushakov) Date: Tue, 31 May 2022 15:32:35 GMT Subject: RFR: 8287453: RenderPerfTest incorrectly measures performance In-Reply-To: References: Message-ID: On Tue, 31 May 2022 10:06:51 GMT, Ajit Ghaisas wrote: > Is it only a test stabilization fix? or were you able to uncover any performance issue (either with OpenGL or with Metal pipeline) with this change? Can you please provide before/after numbers? Initially it was a stabilization fix. However, I've found couple of issues: missing frames (I have minimal test case and going to file an issue) and low performance in some test cases comparing with OGL. I've attached the results to this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8928 From smandalika at openjdk.java.net Tue May 31 19:39:53 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Tue, 31 May 2022 19:39:53 GMT Subject: Integrated: 8282857: Create a regression test for JDK-4702690 In-Reply-To: References: Message-ID: <7oibTCOloL33UXAGQU4yBzEVpNH3TCDJtX-oycIYOVY=.5f978b7e-d703-40ad-a872-35a64eadfaba@github.com> On Wed, 9 Mar 2022 08:13:55 GMT, Srinivas Mandalika wrote: > Create a regression test for [JDK-4702690](https://bugs.openjdk.java.net/browse/JDK-4702690) > > In many cases in Swing it is possible to easily programatically determine that a JScrollBar (or two) is scrolling some JPanel (the cannonical case is a JScrollPane). > In these cases, when accessibility support is instantiated (e.g. the AccessibleJScrollBar is created), a Controller_For and Controled_By relation should be instantiated between the AccessibleJScrollBar and the AccessibleJPanel that the JScrollBar and JPanel are associated with. > > This allows various assistive technologies, especially voice-recognition technologies, to better interact with scrolling items. > > The test put up validates that the target object for these properties(CONTROLLED_BY, CONTROLLED_FOR) are set appropriately for JScrollPane and JScrollBar. > This review is for migrating tests from a closed test suite to open. This pull request has now been integrated. Changeset: 8df5f105 Author: Srinivas Mandalika Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/8df5f1058fb7244b65fa67bff8fd5a5282d70594 Stats: 118 lines in 1 file changed: 118 ins; 0 del; 0 mod 8282857: Create a regression test for JDK-4702690 Reviewed-by: kizune, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/7753 From prr at openjdk.java.net Tue May 31 19:41:53 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 31 May 2022 19:41:53 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 19:11:47 GMT, Damon Nguyen wrote: >> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc. > > Damon Nguyen has updated the pull request incrementally with three additional commits since the last revision: > > - Updated java doc for clarity. Added test to show behavior. > - Merge branch '8012675/htmlTagParserDocChange' of github.com:DamonGuy/jdk into 8012675/htmlTagParserDocChange > - Added debugging statements to better trace handleComments You have several printlns I think you meant to remove. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7446 From smandalika at openjdk.java.net Tue May 31 19:42:49 2022 From: smandalika at openjdk.java.net (Srinivas Mandalika) Date: Tue, 31 May 2022 19:42:49 GMT Subject: Integrated: JDK-8282778: Create a regression test for JDK-4699544 In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 08:26:11 GMT, Srinivas Mandalika wrote: > Create a regression test for JDK-4699544 > > The subclass of javax.swing.JRootPane (AccessibleJRootPane) that implements the accessibility interface javax.accessibility.AccessibleComponent is derived from java.awt.AccessibleAWTComponent, which returns null for getAccessibleAt() because a component does not necessarily have childs. > > The root pane always has a content pane child, so getAccessibleAt() should be overwritten by AccessibleJRootPane appropriately. > The test added verifies the same. > This review is for migrating tests from a closed test suite to open. This pull request has now been integrated. Changeset: cfdbde11 Author: Srinivas Mandalika Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/cfdbde11f0bc2b61590eec2aaa9906f13c64e19e Stats: 58 lines in 1 file changed: 58 ins; 0 del; 0 mod 8282778: Create a regression test for JDK-4699544 Reviewed-by: kizune, serb ------------- PR: https://git.openjdk.java.net/jdk/pull/7739 From duke at openjdk.java.net Tue May 31 19:42:50 2022 From: duke at openjdk.java.net (lawrence.andrews) Date: Tue, 31 May 2022 19:42:50 GMT Subject: Integrated: 8282771 : Create test case for JDK-8262981 In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 23:31:54 GMT, lawrence.andrews wrote: > Following methods are covered in this testcase > getAccessibleAction() > getAccessibleActionCount() > doAccessibleAction(int direction) > > @shurymury This pull request has now been integrated. Changeset: 8db5247e Author: lawrence.andrews Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/8db5247ebc827bf4a428c2d46ebdda778be57860 Stats: 282 lines in 1 file changed: 282 ins; 0 del; 0 mod 8282771: Create test case for JDK-8262981 Reviewed-by: kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/7734 From aivanov at openjdk.java.net Tue May 31 19:44:42 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 31 May 2022 19:44:42 GMT Subject: RFR: 8286159: Memory leak in getAllConfigs of awt_GraphicsEnv.c:585 In-Reply-To: <8kfUsrwVx96D8gvusJtwYwwFLW1WieMXeWlB7qMZpK0=.05cca9e8-9169-46e3-baef-aa46b02d5156@github.com> References: <8kfUsrwVx96D8gvusJtwYwwFLW1WieMXeWlB7qMZpK0=.05cca9e8-9169-46e3-baef-aa46b02d5156@github.com> Message-ID: On Mon, 23 May 2022 20:35:33 GMT, Phil Race wrote: > If we don't store the memory allocated for graphicsConfigs because we failed/bail, we need to free it. Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8857 From achung at openjdk.java.net Tue May 31 20:04:14 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Tue, 31 May 2022 20:04:14 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 15:51:14 GMT, Alexey Ivanov wrote: > Are we going to address rotation under this issue or under a new one? I can fix rotation/skews in a new issue ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Tue May 31 20:06:43 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 31 May 2022 20:06:43 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 19:11:47 GMT, Damon Nguyen wrote: >> Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc. > > Damon Nguyen has updated the pull request incrementally with three additional commits since the last revision: > > - Updated java doc for clarity. Added test to show behavior. > - Merge branch '8012675/htmlTagParserDocChange' of github.com:DamonGuy/jdk into 8012675/htmlTagParserDocChange > - Added debugging statements to better trace handleComments src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java line 73: > 71: *

> 72: * Unsupported tags, such as script tags, will be handled by HiddenTagView. The > 73: * tags and its contents will be displayed as editable JTextFields and JTextAreas. HiddenTagView is a JDK internal class. It doesn't appear anywhere in the specification of Java SE. So, whatever it is you need to say, can't be written like this. Also I am not sure that the PARSER has any say in the display does it ? It just hands it off to something else to decide what to do .. doesn't it ? So can it be correct to mention JTextField here ? Furthermore, the mention of "editable" is pertinent. I think (haven't verified) that if you are viewing a document then comments etc are hidden, but when editing it, they are visible, and that is when handleComment() matters. Perhaps you want Unsupported tags, such as script tags, will be treated similarly to comments and so will be handled in the same way as these by the editor. For example it might be invisible when reviewing the document, and raw editable text when editing it. You need to fact check my assumptions .. ------------- PR: https://git.openjdk.java.net/jdk/pull/7446 From prr at openjdk.java.net Tue May 31 20:16:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 31 May 2022 20:16:57 GMT Subject: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v19] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 21:37:07 GMT, Alisen Chung wrote: >> Changed the drawing area to be increased by 0.5 on the left side to prevent clipping > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > changed test to headless It needs to be handled here as part of this PR before it can be pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7449 From prr at openjdk.java.net Tue May 31 20:18:48 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 31 May 2022 20:18:48 GMT Subject: Integrated: 8286159: Memory leak in getAllConfigs of awt_GraphicsEnv.c:585 In-Reply-To: <8kfUsrwVx96D8gvusJtwYwwFLW1WieMXeWlB7qMZpK0=.05cca9e8-9169-46e3-baef-aa46b02d5156@github.com> References: <8kfUsrwVx96D8gvusJtwYwwFLW1WieMXeWlB7qMZpK0=.05cca9e8-9169-46e3-baef-aa46b02d5156@github.com> Message-ID: On Mon, 23 May 2022 20:35:33 GMT, Phil Race wrote: > If we don't store the memory allocated for graphicsConfigs because we failed/bail, we need to free it. This pull request has now been integrated. Changeset: 97bd4c25 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/97bd4c255a319ce626a316ed211ef1fd7d0f1e14 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8286159: Memory leak in getAllConfigs of awt_GraphicsEnv.c:585 Reviewed-by: psadhukhan, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/8857 From prr at openjdk.java.net Tue May 31 20:20:49 2022 From: prr at openjdk.java.net (Phil Race) Date: Tue, 31 May 2022 20:20:49 GMT Subject: RFR: 8287453: RenderPerfTest incorrectly measures performance In-Reply-To: References: Message-ID: On Fri, 27 May 2022 18:58:12 GMT, Alexey Ushakov wrote: > Improved RenderPerfTest: > - removed RenderPerfLCD.java (we have LCD tests in RenderPerfTest.java) > - corrected and simplified test logic > - added timeout on low performant rendering > - used several markers to recover from missing frames > - protected measurements from multiple paint invocations Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8928 From aturbanov at openjdk.java.net Tue May 31 21:10:44 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 31 May 2022 21:10:44 GMT Subject: RFR: 8287603: Avoid redundant HashMap.containsKey calls in NimbusDefaults.getDerivedColor Message-ID: <1ZtsPAkTkwECdr79Ur1phMJ9EGFWPonyva_ddjimJJM=.c886adcc-6d97-4cc0-bd21-1487aa4df309@github.com> The method `javax.swing.plaf.nimbus.NimbusDefaults#getDerivedColor(String,String,float,float,float,int,boolean)` could be improved by usage of Map.putIfAbsent instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `javax.swing.plaf.nimbus.NimbusDefaults#derivedColors` can contain only non-null values. And to check if `putIfAbsent` was successful or not, we can just compare result with `null`. https://github.com/openjdk/jdk/blob/97bd4c255a319ce626a316ed211ef1fd7d0f1e14/src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template#L713-L720 It makes code a bit cleaner and faster. ------------- Commit messages: - [PATCH] Avoid redundant HashMap.containsKey calls in NimbusDefaults Changes: https://git.openjdk.java.net/jdk/pull/8482/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8482&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287603 Stats: 8 lines in 1 file changed: 1 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8482/head:pull/8482 PR: https://git.openjdk.java.net/jdk/pull/8482 From achung at openjdk.java.net Tue May 31 21:28:25 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Tue, 31 May 2022 21:28:25 GMT Subject: RFR: 8286481: Exception printed to stdout on Windows when storing transparent image in clipboard In-Reply-To: <5VOzdLxj1QvYShp_gm2dey0vMFUM0-wd85AmXLgsGjY=.9c56c8d1-d0ee-448c-8ff8-d1f429fc8cc7@github.com> References: <5VOzdLxj1QvYShp_gm2dey0vMFUM0-wd85AmXLgsGjY=.9c56c8d1-d0ee-448c-8ff8-d1f429fc8cc7@github.com> Message-ID: <7TdEodjxqCi9qHf1TxzuiuHn0yHICy3yhdXNhSsb4C8=.ee30a961-92aa-47bb-a2e6-c0ebb6547377@github.com> On Wed, 25 May 2022 06:08:54 GMT, Phil Race wrote: >> Removed stacktrace from WClipboard > > src/java.desktop/windows/classes/sun/awt/windows/WClipboard.java line 89: > >> 87: // javaJVMLocalObjectMimeType failed to serialize. >> 88: // May remove this if-check when 5078787 is fixed. >> 89: if (!(flavor.isMimeTypeEqual(DataFlavor.javaJVMLocalObjectMimeType) && > > https://bugs.openjdk.java.net/browse/JDK-5078787 is not fixed .. so .. ? I think printing the exception here isn't necessary because the code loops through all possible formats and checks if encoding is possible. If encoding isn't possible then it should skip the format and not print an error. ------------- PR: https://git.openjdk.java.net/jdk/pull/8871 From dnguyen at openjdk.java.net Tue May 31 22:08:23 2022 From: dnguyen at openjdk.java.net (Damon Nguyen) Date: Tue, 31 May 2022 22:08:23 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v4] In-Reply-To: References: Message-ID: > Updated Parser class doc by appending to the doc regarding lack of support for HTML script tags. Adding this information to the "parse" function did not seem as consistent for formatting as adding it to the Parser class doc. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Removed print statements. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7446/files - new: https://git.openjdk.java.net/jdk/pull/7446/files/c7030add..63a29983 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7446&range=02-03 Stats: 50 lines in 2 files changed: 31 ins; 10 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7446/head:pull/7446 PR: https://git.openjdk.java.net/jdk/pull/7446 From dnguyen at openjdk.java.net Tue May 31 22:56:29 2022 From: dnguyen at openjdk.java.net (Damon Nguyen) Date: Tue, 31 May 2022 22:56:29 GMT Subject: RFR: 8012675: Javadoc for javax.swing.text.html.parser.Parser.handleComment() needs to be updated [v3] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 20:03:25 GMT, Phil Race wrote: >> Damon Nguyen has updated the pull request incrementally with three additional commits since the last revision: >> >> - Updated java doc for clarity. Added test to show behavior. >> - Merge branch '8012675/htmlTagParserDocChange' of github.com:DamonGuy/jdk into 8012675/htmlTagParserDocChange >> - Added debugging statements to better trace handleComments > > src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java line 73: > >> 71: *

>> 72: * Unsupported tags, such as script tags, will be handled by HiddenTagView. The >> 73: * tags and its contents will be displayed as editable JTextFields and JTextAreas. > > HiddenTagView is a JDK internal class. > It doesn't appear anywhere in the specification of Java SE. > So, whatever it is you need to say, can't be written like this. > > Also I am not sure that the PARSER has any say in the display does it ? It just hands it off to something else to decide what to do .. doesn't it ? So can it be correct to mention JTextField here ? > > Furthermore, the mention of "editable" is pertinent. > I think (haven't verified) that if you are viewing a document then comments etc are hidden, but when editing it, they are visible, and that is when handleComment() matters. > > > Perhaps you want > Unsupported tags, such as script tags, will be treated similarly to comments and so will be handled in the same way as these by the editor. For example it might be invisible when reviewing the document, and raw editable text when editing it. > > You need to fact check my assumptions .. I see your points and agree that your points are valid. Parser has no part in the display and is fact handled elsewhere. I initially had to look through and learn what each class for HTML parsing is responsible for, and Parser is meant to handle reading chars and adding the chars to a buffer to be processed elsewhere. In this case, I found the HTML contents were routed to DocumentParser. And from there, I had to trace the stack and add debugging statements to find that hidden tags were responsible for the specialized text fields and text areas that appeared. I'll definitely iterate on the documentation to increase clarity and remove mention of HiddenTagView. ------------- PR: https://git.openjdk.java.net/jdk/pull/7446 From duke at openjdk.java.net Tue May 31 23:45:12 2022 From: duke at openjdk.java.net (Nikita Gubarkov) Date: Tue, 31 May 2022 23:45:12 GMT Subject: RFR: 8287609: Add null-check for tagsArray returned from CTFontCopyAvailableTables Message-ID: `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check. ------------- Commit messages: - 8287609: Add null-check for tagsArray returned from CTFontCopyAvailableTables Changes: https://git.openjdk.java.net/jdk/pull/8962/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8962&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287609 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8962.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8962/head:pull/8962 PR: https://git.openjdk.java.net/jdk/pull/8962